游民星空 SEO 实测：44 万条资讯，首页只给出 273 个入口

游民星空的问题不在页面写得怎么样，而在内容发现链断在第二格：站方自己的分页控件报出 44.2 万条资讯，可抓取的入口只有首页 1,285 条链接里的 273 条，XML sitemap 一个都没有。

分页按钮的 href 是 javascript:void(0)。本文按 8 类页面实测，把断点位置、模板缺陷和修复优先级逐条列出来。

一、结论与实测口径

三组数字可以概括这次体检的结果。

• 442,691：资讯列表页分页控件自报的条目总量（data-count），按每页 50 条算是 8,854 页。
• 273：首页上指向资讯详情页的链接数，占首页 1,285 个唯一链接的 21%。
• 0：站点 XML sitemap 的数量。六个常见路径全部返回 404。

把 273 除以 442,691，首页能直接触达的资讯比例是 0.062%。剩下 99.94% 只能靠站内其他路径被发现，而这条路径恰好是断的。

实测覆盖的页面与观测点如下，全部为公开 GET 请求，未使用登录态或后台接口。

UA 侧用四种身份复测：桌面 Chrome、百度蜘蛛、Googlebot、Android 移动端。四种身份对同一 URL 返回的字节数完全一致（首页 389,417 字节，资讯详情 74,264 字节），说明站点没有按 UA 做内容分流。这一点合格，也让后面的结论可以放心外推。

二、发现链断在第一页

2.1 分页是一段脚本，不是一组链接

资讯列表页底部的分页控件长这样：

<a href="javascript:void(0)" class="p1 nexe">下一页</a>

上一页那一行同样如此，只是多带了 data-count="442691" 和 data-pagesize="50" 两个属性。

href 是 javascript:void(0)，翻页靠 data-count 与 data-pagesize 交给脚本去算。整个 HTML 里没有任何一条指向第 2 页的真实 URL，也没有 rel="prev" 或 rel="next"。

直接后果有三层。

第一，第 2 页到第 8,854 页对爬虫不存在——抓取路径必须在 HTML 里有链接才算存在，脚本事件不算。

第二，/news/ 页面头部没有任何 canonical 声明，而它又是全站被链接最多的聚合入口之一。

第三，参数分页是软重复：手工构造 /news/?page=2 返回 200，但与第 1 页的链接重合度是 98.8%（315 条文章链接里 160 条重合，只多插了一条最新稿），同样没有 canonical 兜底。

同样的模式在多个栏目重复出现。列表页 8 组分页控件各自带一个 data-count，数值分别是 442,691、292,751、52,359、29,192、28,470、21,681、3,262、555，合计 870,961。

按各自分页尺寸折算，资讯 8,854 页、攻略 14,638 页，其余栏目数百到数千页不等。

2.2 robots.txt 只有 33 字节，sitemap 一个都没有

这是全站最容易被忽略的文件。https://www.gamersky.com/robots.txt 返回 200，内容类型 text/plain，全文 33 字节：

User-agent: newsai
Disallow: /

只有一条规则，只针对一个 UA（newsai），对百度、Google、必应没有任何指令，也没有 Sitemap: 声明。

这里要区分两件事。没有规则不等于禁止抓取，robots 缺省是允许，所以这不是封禁事故。真正的问题在于它什么也没做：既没把 sitemap 交出去，也没对 /search/、/activity/、带参数的筛选页这类低价值路径做约束。

配套的 sitemap 情况更直接：

六个常见路径、一个目录，全部不通。一个自报 87 万条内容的站点没有任何 sitemap，等于把发现权全押在首页那 1,285 条链接上。

2.3 被这段脚本挡住的是 8,853 个列表页

把两个栏目摊开算：资讯 8,854 页，攻略 14,638 页，合计 23,492 个列表页。这些页面承载着按时间倒序排列的全部历史稿件，是长尾内容最主要的发现入口。

对用户侧的影响略小，但也不是没有：翻页依赖脚本，脚本失败或被拦截时，列表就停在第一屏 50 条。这个机制和抓取 117 万次只收录 4 条里那种「预算被空转消耗」的情形不同——那里是抓得到但没用，这里是根本抓不到。

三、模板层与移动端

3.1 七个模板，五个没有 H1

H1 是最便宜的相关性信号，也是最容易被模板批量漏掉的。逐个模板数了一遍：

六个列表与聚合模板里，五个没有 H1，只有两个详情模板各自输出了一个正确的 H1。专区页的问题尤其明显：/z/eldenring/ 有 9,048 个汉字、1,553 个唯一链接、460 KB 体积，却没有一个 H1 告诉搜索引擎这页在讲哪款游戏，全靠 <title> 硬撑。

3.2 结构化数据：桌面 0 条，移动端一条失效格式

七个模板的桌面端 JSON-LD 全部为 0 条。移动端反而有一条，但内容是：

"@context": "https://zhanzhang.baidu.com/contexts/cambrian.jsonld"

这是百度熊掌号时期的专用格式，@context 指向百度而非 schema.org。熊掌号服务早已停止，Google、必应都不识别这个上下文，因此在非百度引擎侧，移动端同样等于 0 条结构化数据。

3.3 配图 alt 与标题后缀

资讯详情的 4 张正文配图，alt 全部是「游民星空」四个字，没有一张描述图片内容。首页 265 张图里 152 张没有 alt 属性、12 张是空值，合计 62% 的图片对图片搜索没有信息量。

标题模板则相反，太长。资讯详情页 <title> 是 57 个字符，其中 20 个字符是固定的品牌后缀「 _ 游民星空 GamerSky.com」。搜索结果页大约只显示 30 个汉字，后缀占掉三分之一，正文关键词被挤到后面。

3.4 移动端：服务端不判断 UA，适配押在一个脚本上

用 Android UA 请求首页，返回的是和桌面完全相同的 389,417 字节 HTML——没有 302 跳转，没有 Vary: User-Agent 分流，页面里没有 viewport 声明。

移动适配的信号只有两条，都在 <head> 里：

<link rel="alternate" media="only screen and (max-width:640px)" href="https://wap.gamersky.com/" />

这是 2015 年前后分域移动站的标准写法。Google 自移动优先索引推行后就不再依赖 rel="alternate" 的 media 条件，这条声明现在的实际作用更接近给老爬虫的注释。

真正起作用的跳转在 mobileesp.js 里——它被打包进 j.gamersky.com 的合并脚本，靠前端检测 UA 后跳转。脚本一旦失败，移动用户就停在一个没有 viewport、389 KB 的桌面页上。

移动站自身有做得对的地方：wap.gamersky.com/news/Content-2245722.html 的 canonical 正确指向对应桌面 URL，这是跨域移动站的标准做法，避免了两个版本互相竞争。它的配图 18 张全部带 alt，正文也不比桌面版少。

剩下两个小缺口：http://wap.gamersky.com 返回 200 而不是 301 到 https，移动子域 http 与 https 双开；主站 http:// 到 https:// 的 301 是正常的，两处策略不一致。

3.5 停更栏目与首页权重错配

首页 1,781 个链接按去向拆开：指向专区 /z/ 的 811 条，指向资讯 /news/ 的 273 条，专题 65 条，攻略手册 44 条，评测 12 条。首页把近一半链接预算给了专区聚合页，而这些专区页本身又没有 H1。

更值得说的是内容时效。评测频道列表页 /review/ 最新一篇是 2023 年 2 月，栏目页仍挂着「游戏评分评测专题」的定位，但已经 45 个月没有新稿。首页「试玩评测」位置挂的文章是 2022 年 1 月的《CF：幽灵计划》评测。

资讯详情页底部的相关推荐也没有时间衰减。以 2026-11-13 这条资讯为例，同页混排的推荐里有 2024-12、2025-07、2025-12 的旧稿，时间跨度 23 个月，与当天新闻并列展示。对资讯类内容来说，这会稀释页面的时效信号。

四、修复清单与优先级

4.1 十条建议，按优先级排列

4.2 为什么这样排序

前三条排在 P0，是因为它们的分母最大：一条分页修复影响 8,853 个列表页，一份 sitemap 覆盖 87 万条 URL，一个 H1 修复覆盖五个模板下的全部页面。相比之下，写新稿的边际收益要小得多。

第 4 条容易被低估。结构化数据在资讯类站点上主要影响两件事：搜索结果里的时间与来源展示，以及被聚合产品抽取时的字段完整度。桌面端 0 条、移动端只有一条失效格式，等于把这块展示位全部让出去了。

第 8 条需要说明取舍。改响应式是长期正确解，但 460 KB 的专区页和 389 KB 的首页在移动网络下成本很高；短期更现实的做法是服务端 302 加 wap 站继续承接，同时给主站补 viewport 兜底。

顺序也有依赖关系：分页与 sitemap 修好之前，补 H1、补结构化数据都是在给一条不通的水管加装龙头。

4.3 这份体检的边界

三点限制必须写清楚，否则结论会被过度使用。

第一，没有拿到第三方收录与流量数据。爱站等平台的查询页在本次请求中返回 404 或验证页，因此本文不引用任何「收录量」「日均 IP」「关键词数」数字，全部结论来自站内可复现的实测。这也意味着无法判断这 44 万条里到底被收录了多少——只能确认发现路径是断的。

第二，蜘蛛 UA 返回一致，只能证明没有 UA 分流。四种 UA 拿到完全相同的字节数，说明服务端不做 cloaking，真实蜘蛛大概率拿到同样的 HTML。但这不等于蜘蛛一定被放行，CDN 层的 IP 级策略从外部无法观测。

第三，分页是否为纯前端渲染，只验证到 HTML 层。HTML 里没有真实分页链接这一点是确定的，但各栏目脚本是否走 AJAX 拉取没有逐一验证。若走 AJAX，搜索引擎仍可能通过渲染发现部分内容，只是抓取预算消耗会显著高于静态链接；精确判定需要服务端日志。

顺带说一句对照：这几天拆过的途虎养车官网是另一种极端——整站被换成一个 25 个路由的壳，任何路径都返回同一份 2,013 字节的 HTML。

古文岛则是哈希式 URL 导致关键词全丢。游民星空的问题比这两者都轻，页面是实打实的静态内容，标题、canonical、404 都做对了，缺的只是把已经存在的 87 万个页面接上电。