骨架屏看着很快，爬虫看到的可能是空的：目录站的加载状态和它对收录的影响

骨架屏是个好东西。列表页数据没回来之前先显示一排灰色占位块，用户知道页面在加载，心理等待时间明显缩短。但做目录站的人要清楚一件事：爬虫读到的往往不是那个填好数据的页面，而是骨架本身。

图片来源：网络，版权归原作者所有，侵权请联系删除

渲染不是同步发生的

谷歌抓取一个页面的过程分两阶段。第一阶段拿到服务器返回的原始 HTML，能读到什么就先记什么；第二阶段把页面放进渲染队列，用无头浏览器执行 JavaScript，再更新索引。

关键点在第二阶段的延迟。官方对渲染队列的说法一直是「可能几秒，也可能更久」。业界实测的规模更大：有研究分析了十万次抓取，渲染延迟的中位数约 10 秒，75 分位 26 秒，90 分位接近 3 小时，99 分位约 18 小时。

也就是说，如果你把条目列表放在客户端渲染，谷歌可能要等到几小时后才能看到你的内容。而很多 AI 爬虫压根不执行 JavaScript，它们读到的就是你那个空壳。

骨架屏该用在哪，不该用在哪

位置	用骨架屏	原因
首屏条目列表	不该	这是页面的主体内容
首屏之外的推荐模块	可以	即使不渲染也不影响主体
交互后才出现的筛选结果	可以	本来就不该被索引
分页的后续页	可以	靠点击加载，不靠爬虫

判断标准很简单：这个模块的内容需要被收录吗？需要就不能用骨架屏，必须服务端直出。

目录站的条目列表恰恰是必须被收录的那部分。所以服务端渲染列表、客户端只做交互增强，是这类站点的基本配置。骨架屏留给下面的推荐模块和评论区。

流式输出是个更好的折中

如果整页服务端渲染确实慢（比如要查几张表），可以用流式输出：先把 HTML 的头部和骨架发出去，然后分批把内容片段推给浏览器，用一个小的内联脚本把片段放到正确位置。

这种方式的好处是两边的等待都短了。用户很快看到页面框架（TTFB 低），内容陆续出现；爬虫拿到的 HTML 流里也确实包含了全部文本，只是它在文档末尾而不是原位。

实现上有三个要注意的点：

• 片段必须在原始 HTML 里，不能是「先发一个占位，再由 JS 去请求数据」。后者又回到了客户端渲染。
• 重要的元数据放在流的开头。标题、canonical、结构化数据要在头部就发出去，不要等最后补。
• canonical 在渲染前后必须一致。谷歌在 2025 年底的文档更新里明确要求原始 HTML 和渲染后的 canonical 是同一个，不一致会导致索引异常。这条对用前端路由注入 canonical 的站点是硬约束。

另外两个容易踩的坑

第一个是加载态被当成内容收录。有些站的首屏 HTML 里写死了「正在加载...」几个字，数据靠 JS 替换。爬虫第一阶段读到的就是这几个字，如果第二阶段一直没排上，索引里存的就是它。检查方法：在 Search Console 里用网址检查看抓取到的 HTML，或者直接用 curl 拿一次，看里面有没有条目内容。

第二个是错误页返回了 200。单页应用常见的问题是所有路由都返回 200，然后用 JS 渲染「页面不存在」。谷歌文档也在 2025 年底更新过：非 200 状态码的页面可能完全跳过渲染。反过来讲，返回 200 的错误页会被正常渲染并可能收录。所以 404 必须是服务端返回的真 404。

三个自检动作

做完改造之后，用这三个方法验证，按顺序做：

第一步，curl 你的列表页，在返回的 HTML 里搜索一个你知道应该在的站点名称。搜不到说明内容是客户端渲染的，需要改。

第二步，浏览器禁用 JavaScript，打开页面。主体条目还在的话，说明爬虫的第一阶段也能看到。

第三步，Search Console 的网址检查里看「已抓取的 HTML」和「屏幕截图」两处。截图是渲染后的样子，HTML 是原始数据，两者差异过大就要警惕。

第三步里还有个细节值得看：如果显示「页面资源无法加载」，说明有 CSS 或 JS 被 robots 屏蔽了。屏蔽这些资源会让渲染结果跟用户看到的完全不同，这是很多莫名索引问题的根源。

该不该为了爬虫放弃交互体验

不用。目录站的交互需求本来就不重——筛选、排序、翻页都可以做成服务端渲染加少量 JS 增强。真正需要重交互的部分（比如拖拽式的自定义导航页）本来也不该被收录。

把这两类页面分开处理：需要流量的页面走服务端渲染，交互优先的页面加 noindex 或者直接不放进站点地图。分清楚了，骨架屏该用就用，不影响什么。