技术 SEO 最让我警惕的一类建议，是只给动作，不交代诊断：不收录就换 SSR，流量下降就改标题。读完 iCanvas 的实验和 Vercel、MERJ 的研究，我更愿意先问：到底是哪一步出了问题？这一篇把案例放回实际排查过程，比较 HTML、渲染和索引证据，再决定哪些代码值得改，哪些框架没必要换。
独立开发者 SEO 实战 · 第一篇。依据公开案例整理，资料核对于 2026 年 9 月。
两份看似矛盾的 JavaScript SEO 证据
SearchPilot 在 2017 年公布过 iCanvas 的分类页实验。当时部分商品内容和链接依赖 JavaScript，关闭脚本后便不可见，但 GSC 的抓取与渲染检查可以正常显示页面。
团队只在一半分类页上消除这部分依赖，另一半保留原样。实验报告的自然搜索表现提升超过 6%。一个容易被忽略的细节是：具体改动主要在 CSS，并不是把整个网站迁移到另一个框架。iCanvas 实验原文
我觉得这个案例值得读，不是因为它证明了“SSR 能涨 6%”，而是它把两个问题分开了：
页面在一次检查中能显示，不代表交付方式已经没有改善空间；改善一处内容可见性，也不意味着必须重构整个应用。
但如果只读到这里，就容易拿九年前的实验指导今天的架构。
2024 年 Vercel 与 MERJ 的研究分析了超过十万次 Googlebot 抓取，主要样本来自 nextjs.org，另有两个站点的补充数据。在排除错误状态和不可索引页面后，他们观察到样本 HTML 的完整渲染，也验证了异步内容和 RSC 流式内容的处理能力。研究方法与结果
我的理解是：这足以反驳“Google 看不见 JavaScript”的笼统说法，却不能保证任意网站的 API、权限、超时和页面状态都没问题。它也不是所有框架之间的排名对照实验。
一份研究观察渲染能力，一份实验测量特定页面改动的搜索效果。年代、样本和指标都不同，没必要选一边当信仰。
我会先比较三份页面，而不是先查框架配置
如果一个公开产品页没有被收录，我会留下三份证据：
第一份是服务器返回的 HTML。它说明第一次请求交付了什么。
第二份是没有登录、没有历史状态的浏览器最终页面。它说明普通访问者经过脚本执行后能拿到什么。
第三份是 GSC URL Inspection 中的抓取或测试结果。它说明 Google 在那个时间点看到了什么。
Google 官方仍然把 JavaScript 页面处理区分为抓取、渲染和索引，并提醒：被阻止的资源不会正常参与渲染，服务端输出或预渲染也能帮助用户及不能执行脚本的爬虫。Google JavaScript SEO 文档
下面是我会用的基础命令，域名和正文关键词需要替换。它是检查方法，不是某个客户的故障记录：
curl --compressed -sS -L -D /tmp/seo-page-headers.txt -o /tmp/seo-page.html https://example.com/features/export
rg -n 'HTTP/|[Ll]ocation:|[Xx]-[Rr]obots-[Tt]ag:' /tmp/seo-page-headers.txt
rg -n '<title|canonical|name="robots"|导出功能' /tmp/seo-page.html
我会实际发 GET，不只发 HEAD，因为最终需要检查正文。跟随重定向时，也要看中间状态，而不是只看到末尾的 200 就结束。
还有个细节：在 HTML 文件里搜到产品文案，不代表它一定是可见正文。文案也可能只是脚本中的序列化数据。要再看它位于哪个元素，以及渲染后的 DOM。
这三份证据不一致时，排查方向才开始清楚。
| 观察结果 | 我优先怀疑什么 | 下一步 |
|---|---|---|
| 原始 HTML 没正文，浏览器和 Google 都有 | 有脚本依赖，但尚不能判定故障 | 看稳定性和实际索引状态，不急着迁移 |
| 浏览器有正文，Google 没有 | 资源访问、会话状态、交互依赖或执行失败 | 对照网络请求和服务器日志 |
| 三份都有正文，仍未索引 | 规范化、重复内容或页面价值 | 检查 Google 选定的规范 URL |
| 整个目录突然失败，其他目录正常 | 共用模板或部署变更 | 抽查同模板页面，再对部署时间 |
这张表的意义是减少试错范围。最后一种情况如果去逐篇补关键词，基本没有碰到问题。
“抓过但没收录”不能直接翻译成内容差
我会先找三个同模板页面：一个正常收录的，一个长期未收录的，一个最近发布的。比较它们通常比盯着全站未索引数量有效。
假设一个虚构的模板网站有这些地址：
/templates/invoice
/templates/invoice?color=blue
/templates/invoice?sort=popular
/templates/invoice-for-freelancers
颜色和排序参数可能只是同一内容的视图；面向自由职业者的模板则可能有不同字段、示例和使用说明。两者不该机械地用同一条 Canonical 规则处理。
Google 把重定向、canonical 和 Sitemap 视为强弱不同的规范化信号，站点自己的信号应保持一致；声明 canonical 也不等于强制搜索引擎接受。Google 规范 URL 指南
我的操作顺序会是：
先看 GSC 的用户声明与 Google 选定的规范 URL 是否相同。不同，就把被选中的页面打开，比较真实内容。
再看 Sitemap 与站内链接是否都在推荐同一个版本。若站点一边声明 A 正式，一边处处链接 B，就先修这个冲突。
最后才判断页面有没有独立价值。自由职业者页面如果只是替换标题，其余与通用页完全相同，我不会因为它有一组关键词就坚持保留。反过来，若字段、示例和任务确实不同，也不该为了“集中权重”把它并回首页。
至于 noindex 和 robots.txt，我只记住一个排错原则：阻止抓取之后，不能再指望爬虫读取页面内的 noindex。访问限制、索引意愿和规范化是三件事。Google noindex 说明
修复优先级，取决于损失范围
假如只有一个周末处理 SEO，我不会照审计工具的错误数量排序。
一个全站公开页误带 noindex 的问题，只有一条规则，却影响所有入口。两百个旧文章描述重复的问题，看起来数量大，未必比它紧急。
我会先处理重要页面无法访问、错误规范化、核心正文缺失这类阻断问题；再处理关键页面难以从导航或正文发现的问题；最后才是标题表达、图片和性能细节。
性能也一样。页面卡到用户无法完成注册，值得立即修；单纯为了让实验室分数从 95 变成 100，要先比较工程时间与实际收益。Google 也明确表示，良好 Core Web Vitals 不保证排名靠前。Google 页面体验说明
这并不是说细节没有用，而是小团队承担不起“所有建议同时做”。
我会把修复写成验收条件
“优化 JavaScript SEO”很难验收。我更愿意把任务写成：
问题：
产品分类页的核心商品链接依赖一次容易失败的客户端请求。
本次修改：
让当前分类的基础商品列表和详情链接在首次 HTML 中可用。
保留客户端筛选，不更换 URL，不同时改标题。
工程验收：
匿名 GET 可以取得正文和真实 href。
空分类与不存在分类的状态码符合设计。
浏览器交互与原来一致。
搜索观察：
记录上线时间。
检查 Google 重新抓取后的页面版本。
按分类页观察曝光、点击及后续产品使用。
这里必须区分“修复上线了”和“搜索效果证明了”。
服务器返回正确内容，是可以立即验证的工程结果。收录和搜索表现要等后续数据；单页上线前后增长，也可能受到季节、竞争和其他变更影响。没拿到后者时，不能把前者包装成增长实验。
我从这些案例里真正愿意带走的，就是这种工作方式：先留下能解释故障的证据，再做尽可能局部的修改。很多技术 SEO 问题需要的是一个准确补丁，不是一轮框架迁移。