今日网络技术热点：SSG 预渲染工具站 SEO 优化实践：从零收录

不少用静态站点生成器（SSG）搭建技术博客或文档站的工程师，都曾陷入一个困惑：站点结构清晰、内容质量不差，但上线数周后搜索引擎收录量依旧为“零”。当你的技术文档、故障复盘笔记无法被检索到，意味着你辛苦沉淀的排障经验无法触达同行，这不仅是流量问题，更是知识价值被埋没的隐患。

本文基于一篇SSG预渲染工具站的实际SEO优化复盘，为你拆解从“零收录”到“全面修复”的排查逻辑与操作步骤。我们不看玄学，只看抓取、渲染、索引这三个环节到底卡在了哪里。

问题判断：先分清是“不被抓”还是“不被索引”

很多工程师一看到“收录为零”就急着加关键词、堆外链，这是方向性错误。根据该案例的复盘，问题往往出在技术链路而非内容质量。你需要先通过两个基础工具定位：

• 站点地图（Sitemap）提交状态：在Google Search Console（GSC）或百度搜索资源平台查看Sitemap的“已发现”与“已编入索引”数量。若“已发现”持续为0，说明爬虫根本没找到你的链接入口。
• 抓取统计：查看“抓取”报告中的状态码分布。若出现大量500或404，说明服务器响应异常；若显示“已抓取但未编入索引”，则问题出在内容质量或渲染结果上。

该案例中，作者最初面临的是站点上线后长时间无任何页面被收录，甚至手动提交URL也毫无反应——这属于典型的“爬虫无法有效遍历”问题。

技术原理：SSG的“伪静态”陷阱

SSG在构建时确实会为每个路由生成独立HTML文件，理论上无需JS即可获取完整内容。但这里有个容易被忽略的细节：你的部署环境是否真的以静态文件形式服务了这些HTML？

示例场景：某团队将SSG构建产物部署在Nginx上，但配置了错误的try_files指令，导致所有请求都被重写到index.html，由前端路由接管。此时爬虫访问/post/2024/network-troubleshooting.html，服务器返回的是SPA入口文件而非真实HTML。虽然浏览器地址栏看起来正常，但爬虫拿到的DOM是空的——这就是“伪静态”陷阱。

排查过程：三步定位抓取异常

1. 模拟爬虫抓取：使用curl -A "Googlebot" -I https://你的域名/某篇文章.html，检查响应头中的Content-Type。若返回text/html但内容长度异常小（比如小于几KB），大概率是返回了SPA入口而非完整页面。
2. 检查渲染结果：使用Google的“网址检查”工具或百度“抓取诊断”，查看Googlebot看到的实际HTML源码。重点确认<article>标签内是否包含正文文本，而非只有<div id="root"></div>空壳。
3. 审查内部链接结构：查看已发布页面的HTML源码，确认所有文章链接是<a href="/post/xxx.html">这样的静态地址，而非<a href="/post/xxx">依赖JS路由的“伪链接”。后者会导致爬虫无法提取有效URL。

该案例中，作者通过逐一排查发现了7个独立问题，其中包括动态渲染参数被错误继承、Sitemap中混入带查询参数的URL等。这些细节单看都不致命，但叠加起来就让爬虫彻底迷失。

根因分析：三个高频“隐形杀手”

• Sitemap与实际路由不一致：SSG框架（如Docusaurus、VitePress）生成的Sitemap默认基于构建时路由，但如果你在部署后通过Nginx重写了URL规则（如去除.html后缀），Sitemap中的地址与真实可访问地址就会产生偏差。爬虫按图索骥却屡屡碰壁，最终降低抓取频次。
• robots.txt误伤：检查是否在robots.txt中错误地Disallow: /*?*，这会导致所有带参数的URL（包括部分框架的预渲染链接）被屏蔽。案例中作者发现，某次安全扫描后遗留的规则直接阻断了整个/tags/路径。
• 托管平台缓存策略：若使用CDN或对象存储，注意Cache-Control头是否设置了过长的max-age。爬虫可能拿到的是旧版本Sitemap或旧HTML，导致反复抓取失败。

解决方案：从提交到验证的完整闭环

1. 统一URL规范：在SSG配置中强制生成“干净链接”（即无.html后缀），并在Nginx中配置try_files $uri $uri.html =404;确保内部跳转一致。同时，Sitemap生成插件需基于最终部署路径输出，而非本地构建路径。
2. 清洗Sitemap：用脚本遍历Sitemap中所有URL，剔除带?、#或包含localhost的条目。案例中作者专门写了一个Python脚本，用urllib.parse解析并过滤无效URL，最终将Sitemap从几百条精简到核心文章列表。
3. 验证渲染完整性：在CI/CD流水线中加入“HTML内容检查”步骤。例如使用grep -c "article" dist/index.html确认构建产物包含正文容器，若为0则直接终止部署。这能从源头杜绝“空壳页面”上线。
4. 主动提交与观察：修复后，在GSC中提交新的Sitemap，并使用“网址检查”工具手动请求几个核心页面，确认“抓取”与“编入索引”状态均为绿色。此后每天观察“网页索引编制”报告，若“已抓取但未编入索引”数量上升，需检查内容质量或是否存在重复页面。

风险与适用边界

上述方案适用于以内容分发为核心的SSG站点（如技术博客、产品文档）。若你的站点是高度交互的Web应用（如在线工具、控制台），SSG仅能预渲染首屏，此时需结合CSR或混合渲染，并依赖Google的“动态渲染”方案——但该方案已逐渐被弃用，建议谨慎评估。此外，百度对JS渲染的支持弱于Google，若主要受众在国内，务必保证服务端返回完整HTML。

行动清单（本周可执行）

1. 用curl -A "Googlebot"抽查你站点的3篇核心文章，确认响应内容包含正文文本而非空壳。
2. 下载当前Sitemap，用Excel或脚本检查是否有超过10%的URL包含查询参数或非标准协议头。
3. 在GSC或百度站长平台提交最新Sitemap，并设置每日监控“抓取统计”中的5xx状态码数量。