在 GitHub 上动手做一个开源项目，代码写完只是起点。开发者 lunrenyi 最近就遇到了一个尴尬场景：他把经典 RTS 游戏 Curse of War 用 Rust 重写后发布为仓库 lunrenyi/curseofwar-rs，可跑到 Google 上搜索相关词条时，首屏列出的全是别人的项目，自己的作品一点痕迹都没有。

他由此展开自查，试图弄清楚一个问题：一个新鲜出炉的 GitHub 仓库，究竟为什么得不到 Google 的注意，又该做些什么才能被搜索引擎“认出来”。按照他的梳理，导致搜索缺席的原因可以被归成五类。

原因一：仓库页面可能压根没进入 Google 索引

作者给出的第一手判断来自一次精确查询——他用 site:github.com/lunrenyi/curseofwar-rs 检索，返回结果数量是 0，至少在当时，Google 没有把这个仓库页面列入结果集。他推测这和 README 内容单薄有关，抓取程序可能因此没有把它当成有效页面处理。

原因二与原因三：资历不足、内容又不够差异化

第二个因素指向权威性。原版项目 a-nikolaev/curseofwar 已经存在十多年，Star 数量可观，站外博客、网站和项目引用也积累了很多；DM-Earth/curseofrust 同样在社区里攒下了基础。相比之下，curseofwar-rs 诞生时间极短，搜索引擎没有理由立刻给予信任。

第三个因素则是独特内容缺失。作者坦言自己的复刻版和既有项目高度相似——做的是同一款游戏，代码里也有不少重合的部分。README 里仅有一句“这是 Curse of War 的 Rust 版本”，这种描述无法让搜索引擎判断它比已有页面更值得推给用户。

原因四与原因五：站内关系断裂，关键词不匹配

作者还注意到一个细节：Google 能抓到他的 GitHub 个人主页，却没有把 lunrenyi 与 curseofwar-rs 这两者有效关联起来。换句话说，他的主页并没有醒目地传递出“此人维护了一个叫 curseofwar-rs 的 Rust 项目”这一信息，而这种关联本质上属于最基础的站内链接结构。

另一个问题出在项目自身的 SEO 信息完整度上。他发现排在前面的仓库标题直接含有明确关键词，例如“[MIRROR] Curseofwar ported to Rust”，用户搜 curseofwar rust 时，标题与搜索意图的匹配度极高。自己的仓库介绍则对 Curse of War 的着墨过于笼统，Repository Description、GitHub Topics、项目通常涵盖的 Curse of War、Real-time Strategy 等标签信息都没能充分填上，主题指向因此不够清晰。

实验设计：先补齐信息，再观察排名是否移动

与其继续猜测 Google 的排序逻辑，作者决定直接做一个小范围实验：先把 SEO 相关的信息填完整，随后观察搜索结果会不会出现改变。他把实验拆成五个步骤。

第一步是完善仓库基础信息。在 GitHub 仓库里补上 Repository Description，并加入更准确的 Topics，例如 rust、curseofwar、real-time-strategy、game。这些字段看似不起眼，却能让搜索引擎更清楚地理解仓库的性质。

第二步是重做 README。README 是搜索引擎理解项目的重要文本来源之一，他打算补充真正属于本项目自己的说明，比如“在原版 Curse of War 基础上用 Rust 重写，保留某某特性，并面向某某场景做了某某优化”。他特意强调，重点是回答“用户为什么要看到我的项目”，而不是把关键词硬堆上去。

把 GitHub 站内链接与站外入口都补上

第三步是把 GitHub 站内的链接关系打通。既然 Google 已经认识他的账号，就应该让它更容易顺藤摸瓜找到项目。为此他准备在个人主页把该项目 Pinned，并在主页 README 中加入明确指向“My Rust implementation of Curse of War”的链接，由此构成 GitHub 用户 → Curse of War → Rust 项目这条链路，比仓库孤立存在更容易被搜索引擎理解。

第四步是给项目寻找外部入口，这也是作者认为整个实验最有意思的环节。只有 GitHub 自己在介绍项目，外部信号就太稀少了。他计划到若干开发者社区分享：Reddit 的 r/rust、r/gamedev、r/linux_gaming，以及 Hacker News 和 X（Twitter）。这么做不只是为了宣传，更实际的目的在于，一旦其他网站生成了指向该仓库的链接，搜索引擎就可能顺着这些链接发现项目。

主动通知 Google，并用 GSC 复查 URL

第五步是主动告知 Google 这里出现了新项目。做法有两种：其一，发布一个 GitHub Release，让项目拥有正式的版本节点；其二，把链接提交到 Google Search Console（GSC）中做 URL 检查，确认 Google 是否已经发现这个仓库，如果条件允许还可以请求重新抓取。

作者在此提示了一个容易踩的坑：你没办法直接验证 github.com 这个整域名的所有权，所以并不存在把整个 GitHub 仓库当成完整网站属性直接添加进去的做法。更现实的路径，是通过 GSC 针对具体 URL 执行检查与重新抓取。

从关心 Star 到关心被发现

回顾心态变化，作者说以前参与别人的开源项目时，更在意的是“有没有人给 Star”。如今自己从零做一个项目，才发现让别人找到它可能是最关键的一环，对新建立的仓库尤其如此。代码写完之后还有三个待解的问题：搜索引擎要怎样才能发现它？别人为什么愿意引用它？Google 凭什么认为它该排在前面？

他打算把 curseofwar-rs 当成一个小型实验样本，先完整地做完这批 SEO 基础工作，过一段时间再回来重搜 curseofwar rust，看这个项目能不能从搜索结果的“不存在状态”里爬出来——原文这里还自嘲地回插了一句“黑名单”。若后续观察到变化，他准备把结果继续记录下来。

小结：新开源的同质化 Rust 复刻项目在搜索首屏缺席，通常不是单一原因，而是收录缺失、外部信任度不足、内容无差异、站内关系弱、SEO 信息不全共同作用的结果。作者给出的五项改进动作覆盖仓库描述、README 语义、GitHub 内链、站外分享与 GSC 复查，其中 GSC 只能按具体 URL 检查、无法验证整个 github.com 域名，是落地时最值得注意的技术边界。这套方法的效果目前尚未有结论，需要等待后续搜索验证。