打开 Search Console，在网址检查工具里输入要查的那个 URL，回车，点 View crawled page，看渲染后的 HTML 里有没有你的正文。这一步做完，页面是没被抓取、抓了没渲染、还是渲染了没索引，三个答案里总有一个对得上。Google 处理 JavaScript 网页分抓取、渲染、索引三个阶段；返回 200 的页面都会排进渲染队列，除非 robots meta 标签或 header 明确说不要索引这个页面。
对做出海站的人，这件事的分量在这里：前端选型直接决定收录速度。客户端渲染的站，内容写得再好也要在渲染队列里排着，等 Google 的资源空出来才跑 JS。看一个英文站，第一眼不看设计，看渲染后的 HTML 里有没有正文，这一步过不了，后面全是白费。猎者出海做英文独立站，建站第一道关就是这件事。
- 三步流程：抓取、渲染、索引，卡在哪一步决定你改什么。
- 方向选择：动态渲染是 workaround，Google 推荐服务端渲染、静态渲染或 hydration。
- 怎么查：网址检查工具或 Rich Results Test，看渲染后的 HTML 里有没有目标内容。
- 常见坑：URL fragment 加载内容、靠 Local Storage 存状态、用 JavaScript 改 canonical。
这篇把三步怎么走、几种渲染各自的问题、排查顺序、修复清单和几个会卡人的数字讲完，最后给几条能直接用的 AI 提示词。
本文目录
JavaScript SEO 是什么：Google 把 JS 网页分抓取、渲染、索引三步
JavaScript SEO 说的是让靠 JavaScript 生成内容的页面，能被搜索引擎完整抓到、渲染、索引的一整套动作。Google 把这件事拆成三个阶段：抓取（Crawling）、渲染（Rendering）、索引（Indexing）。三步串起来走，前一步没完成，后一步轮不到。
有个细节常被忽略：Googlebot 同时把页面排进抓取队列和渲染队列，页面到底在等抓取还是在等渲染，从外面看不出来。所以「提交了没反应」这种描述，先别急着下判断，去工具里看具体状态。技术 SEO 的范围比这宽，JavaScript SEO 只是里面的一块，技术SEO优化教程覆盖的是更完整的技术面。
Google SEO 的底子还是收录和排名那套，JavaScript 只是把收录这一环变复杂了。三步里第一步和第二步都在服务器和爬虫之间完成，你能控制的比想象中多。
抓取阶段：robots.txt 先读，disallowed 的页面和文件里的 JS 不会被渲染
Googlebot 发 HTTP 请求之前先读 robots.txt。URL 被标成 disallowed，它直接跳过这个 URL，连请求都不发。被屏蔽的页面、被屏蔽文件里的 JavaScript，都不会被渲染。
常见的一种自伤是这样：robots.txt 里把 /js/ 目录挡掉，理由是「不想让爬虫抓这些没用的文件」。页面在浏览器里一切正常，Google 那边拿到的是一个空壳。JS 文件都没拿到，渲染就无从谈起。
反过来的错也有：不想让某个页面被索引，拿 robots.txt 去挡。挡了抓取，页面上的 noindex 也读不到，URL 照样可能出现在结果里。不想被索引用 noindex，不想被抓取才用 robots.txt，这是两件事。
渲染阶段：200 的页面进渲染队列，等几秒也可能更久，由无头 Chromium 执行 JS
返回 200 的页面默认都会进渲染队列，除非 robots meta 标签或 header 告诉 Google 不要索引。进了队列以后，页面可能待几秒，也可能更久。等 Google 的资源允许，无头 Chromium 渲染页面并执行 JavaScript。Google Search 用的是常青版 Chromium，不是某个固定老版本。
HTTP 状态码不是 200 的时候，比如 404 错误页，渲染可能被跳过。这条对单页应用影响很大，后面讲软 404 会再说一次。渲染能不能跑完，还跟你依赖的接口快不快有关，接口在渲染时超时，页面就是半个。
索引阶段：非 200 的页面渲染可能被跳过；2xx 也不保证被索引
抓取成功不等于被索引。HTTP 2xx 是成功状态码，但不保证索引。索引这一步看的是渲染后的内容值不值得收、canonical 指向哪个 URL、有没有 noindex 拦着。这三项任何一项出问题，前面两步做得再好也白搭。
还有一句要记住：其他搜索引擎可能选择忽略 JavaScript，看不到 JS 生成的内容。Google 跑 JS，不代表所有爬虫都跑。你的页面可能被社交平台的预览抓取、被别的工具抓取，它们拿到的就是原始 HTML。
客户端渲染、SSR/SSG、动态渲染，各自会出什么问题
同一个页面，前端怎么渲染，决定了 Google 拿到手的是什么。客户端渲染、服务端渲染、静态渲染、动态渲染这四种经常被混着说，实际区别只有一个：HTML 到手的时候，正文在不在里面。
客户端渲染：Google 能看到渲染后的内容，但页面要等渲染队列，收录慢
客户端渲染是 JavaScript 在浏览器打开页面时加载额外内容。Google Search 能看到这些内容，也能看到 HTML 里的内容。这句话的意思是，纯客户端渲染不是死路，只要 JS 能跑完，内容就能被看到。
代价有两个。一是排队，页面要等渲染队列，收录慢是结构性的，光改配置改不动。二是错误页，单页应用用客户端 JS 处理错误时，常返回 200 而不是合适的状态码，结果错误页被索引，还可能出现在搜索结果里。
服务端渲染和静态渲染：Google 推荐的方向，对用户和爬虫都快
服务端渲染是请求到了服务器，服务器把 HTML 拼好再返回。静态渲染是构建的时候就把 HTML 生成好。两者对爬虫的意义一样：HTML 到手，正文就在里面，不用等 JS 跑一遍。
Google 推荐的方向就是这两个，加上 hydration。理由不复杂：对用户和爬虫都快，而且不是所有 bot 都能运行 JavaScript。你的站主要给 Google 看，但也会被别的爬虫碰到，能直接给 HTML 的，就别让它等。
动态渲染：Google 定性为 workaround，不是长期方案
动态渲染的做法是：服务器检测到可能处理不了 JS 内容的 bot，就返回一份不带 JS 的服务端渲染版本；普通用户拿到的还是客户端渲染版本。等于给两类访问者看两份 HTML。
Google 把动态渲染定性成 workaround，不是长期方案，因为它带来额外的复杂度和资源需求。官方给的替代方向是服务端渲染、静态渲染或 hydration。它能用，但不该是新站的起点。
会不会被当成 cloaking，看内容。产出相似内容，Googlebot 一般不把动态渲染视为 cloaking。给用户和爬虫完全不同的内容，就可能被算成 cloaking。设置期间站点产生错误页，Googlebot 不把这些错误页当成 cloaking，按普通错误页处理。
next.js seo 的差别，就在默认输出的是渲染后 HTML 还是空壳
框架层只举一个例子。next.js 这类框架做 SEO，差别就看它默认输出的是渲染后的 HTML 还是空壳，跟框架名字关系不大。配成静态生成或服务端渲染，HTML 里就有正文；全靠客户端拉数据，HTML 里就是空的。
判断方法跟别的站一样：看渲染后的 HTML。框架配置不用展开，这一步用网址检查工具就能验证，不需要读框架文档也能得出结论。
怎么排查：先看渲染后的 HTML，再倒查抓取和索引
遇到页面不进索引，工程那边的第一反应通常是代码写错了。多数时候代码没错，是渲染这一环没走完。这套排查顺序，就是从这个判断出发排的。
能同时看到 Google 拿到的版本和渲染后版本的入口不多，Rich Results Test 和 Search Console 的网址检查工具是两个。加载了哪些资源、JS 控制台报了什么错、渲染后的 DOM 长什么样，都在这里。下面六步按顺序走。
- 在网址检查工具里输入 URL，点 View crawled page，看返回的 HTML 和渲染后的 DOM。Google 拿到的版本和渲染后的版本都在这儿。链接是灰的、点不动，说明抓取这一步就失败了，鼠标悬停能看到原因。
- 看 Page indexing 里的 Crawl allowed? 和 Indexing allowed? 两栏。页面被 robots.txt 挡住的时候，Indexing allowed? 会一直显示 Yes，因为 Google 看不到也遵守不了 noindex 指令，页面照样可能出现在搜索结果里。要放行，用 robots.txt tester 找出那条屏蔽规则删掉。
- 看 Page fetch 是 Successful 还是 Failed，再看 Indexing status 是 The page is indexed 还是 The page is not indexed 加原因。抓取成功不代表被索引，后面还有关卡。原因就写在 Page indexing 的详情里，读那一段。
- 看 Last crawl 的时间和 Crawled as 的类型，决定是等下一次抓取还是先改代码。工具里所有信息都来自最近一次抓取的版本，不是线上当前的样子。要测线上这一版，按 Live Test。
- 用抓取统计报告盯 Googlebot 和 WRS 的活动。客户端统计拿不到完整数据，Googlebot 和 WRS 的行为在那边看不全。这个报告能看出抓取量有没有掉、哪些文件在被反复抓。
- 修完再用 Rich Results Test 或网址检查工具复测一次。修好了显示绿色对勾，没有错误。还有错，去 Search Central 帮助社区发帖。
排查时顺手看一眼 sitemap。较大或较新的站，提交一份 XML 站点地图给 Google 指路，比等它自己发现快。网址检查工具的 Sitemaps 一栏会列出通过 Sitemaps 报告提交或在 robots.txt 里列出的、指向这个 URL 的站点地图。
服务器日志能看到 Googlebot 实际抓了哪些 URL、抓了几次。网址检查工具一次只能查一个 URL，量大的时候两边对着看，Log File Analysis 就是干这个的。
修复清单：这 7 项按顺序过一遍
下面 7 项按顺序过，顺序有讲究。前面的项出问题，后面的检查基本白做。每项只写动作，为什么这么做放在下一节。
- 站内链接只用带 href 属性的 元素。JS 动态插入也可以，前提是插入的仍然是带 href 的 标记。单页应用要在不同视图之间路由，用 History API，不要用 URL fragment，AJAX-crawling 方案 2015 年就废弃了。
- canonical 写在 HTML 里。非要 JS 设置，就始终设成和原始 HTML 相同的值，页面上只能有一个 rel="canonical"。注入时容易创建多个，或者改掉已有的那个。canonical 的写法本身不复杂，Canonical标签的规则先弄清，再决定要不要用 JS 碰它。
- noindex 只写在确实不想被索引的页面上，位置在原始 HTML 里。想让页面进搜索结果，原始代码里就一个 noindex 都不要有。
- 单页应用的错误页不要返回 200。两种改法：重定向到服务器返回 404 的 URL，或者在错误页加上 <meta name="robots" content="noindex">。
- 内容不要靠 Local Storage、Session Storage、Cookie 提供。一律放在服务器返回的 HTML 里，或者由服务端渲染出来。
- JS 和 CSS 用内容指纹命名，像 main.2bb85551.js 这样，文件名跟着内容变。资源一改，文件名就变，缓存问题自动绕开。
- 懒加载要在内容进入视口时加载，不能靠滚动或点击触发。无限滚动给每个分块独立、持久的 URL，用 ?page=12 这类绝对页码，别用 ?date=yesterday 这种相对参数；新分块成为主要可见内容时，用 History API 更新地址栏的 URL。
数字和限制：2MB、15MB、10 次跳转，这几个数会影响抓取和渲染
这几个数字决定排查时的判断顺序。页面明明有内容却没进索引，先拿它们对一遍，再动手改代码。
| 项目 | 数值 | 对做这件事意味着什么 |
|---|---|---|
| Googlebot 抓取支持文件类型 | 前 2MB，PDF 前 64MB | HTML 里引用的每个 CSS 和 JS 单独抓取，各自受同一限制；超限只把已下载部分送去索引 |
| Google 爬虫默认抓取上限 | 前 15MB | 超出部分忽略，单个产品可能更小 |
| 重定向跳转 | 默认最多跟随 10 次 | 链路过长会断在中间 |
| 渲染队列等待 | 几秒，也可能更久 | 收录慢先别改代码，先确认是不是在排队 |
| 网址检查请求 | 每个自有属性每天有上限 | 批量排查要排优先级，别一次刷完 |
文件大小限制按未压缩数据算，压缩后的体积不算数。渲染队列那个「几秒，也可能更久」没有给出上限，所以页面上线两三天没进索引，先看是不是在排队，别急着推倒重来。
常见误区：这 5 个做法看着对，实际会挡收录
下面五个做法，出发点都是让页面更快或者更省事，结果都挡在收录这一环。每条的结论在前，依据在后。
- 用 URL fragment 加载不同内容。Googlebot 无法可靠解析这类 URL，靠它做分页或者切换栏目，等于把内容藏起来。
- 靠 Local Storage 或 Cookie 存状态，再按状态渲染内容。WRS 不跨页面加载保留状态，这些数据每次加载都会被清掉，爬虫看到的是没有状态的那一版。
- 用 JS 把 canonical 改成和原始 HTML 不同的值。Google 明确说不要这么做，冲突的或者多个 canonical 标签会带来意外结果。
- 用 JS 删掉 noindex，指望页面被收录。Google 遇到 noindex 标签时可能跳过渲染和 JavaScript 执行，JS 跑不到删的那一步。
- 给首屏可见内容加懒加载。用户打开页面第一眼要看到的东西被推迟加载，慢是能感觉到的。页面速度的衡量看 Core Web Vitals，指标怎么读那里讲得细。
结构化数据还有一条单独的：放了结构化数据的页面不要用 robots.txt 或 noindex 屏蔽。标记按 Rich Results Test 检查正确，也不保证一定出富媒体结果。
用 AI 整理渲染差异和排查顺序，这 3 步能省时间
这一节讲 AI 在排查里能接手的活，也讲哪几步必须自己动手。全自动做不到，把重复劳动交出去是真的。
第一步，把原始 HTML 和渲染后 HTML 交给 AI 对比，让它列出只在渲染后出现的内容块。两段 HTML 动辄几千行，眼睛扫一遍太慢，机器扫一遍再人工确认，省的是这个时间。
第二步，按清单逐项对照代码。canonical 设置、noindex 用法、History API 路由、懒加载、软 404、内容指纹缓存，一项一项过，让它标出不符合的地方。这一步的产出是一张可疑点清单，不是结论。
第三步，把网址检查结果整理成排查顺序表。Discovery、Crawl、Indexing、Enhancements 四段信息混在一起，理成一张表，先看哪一项就清楚了。
下面三条提示词是本文给的示例，不是官方模板，用之前按自己的代码改一下上下文。
「下面是一个页面的原始 HTML 和渲染后 HTML，请逐段对比，列出只在渲染后出现的内容块，以及可能影响 Googlebot 抓取的结构问题。」
「按 Google 官方 JavaScript SEO 清单（canonical 设置、noindex 使用、History API 路由、懒加载、软 404、内容指纹缓存），逐项检查下面这段代码，标出不符合项并给出改法。」
「下面是一份 Search Console 网址检查结果截图文字，请按 Discovery、Crawl、Indexing、Enhancements 四段整理成排查顺序，指出最可能的原因。」
必须人做的三个动作，AI 替不了：
- 在网址检查工具里输入要查的 URL，点 View crawled page，看渲染后的 HTML 里目标内容在不在。
- 在 Page indexing 的 Crawl allowed? 和 Indexing allowed? 两栏，确认 robots.txt 和 noindex 的实际状态。
- 看 Crawl 栏的 Last crawl 时间和 Crawled as 类型，决定是等下次抓取还是先改代码。
对着清单过代码这件事，猎者出海的AI Agent 里有技术 SEO 这一块，100+ 条 SEO 标准可以拿来当第二道检查。它挡住的坑里有一条跟这里对得上：站建好了永远不被收录也不报错，靠人肉翻代码很难发现，过一遍标准就露出来了。
常见问题
Google 到底会不会执行 JavaScript？
会。Google Search 用常青版 Chromium 跑 JS，返回 200 的页面默认都会进渲染队列。但排队要时间，部分资源可能不被抓取，跑完 JS 也不等于一定被索引。
用了动态渲染会不会被当成 cloaking？
产出相似内容，Googlebot 一般不把动态渲染视为 cloaking。给用户和爬虫完全不同内容，才可能被算成 cloaking。设置期间出现的错误页按普通错误页处理。
用 JavaScript 设置 canonical 和 meta description 可以吗？
meta description 和 title 用 JS 设置是可以的。canonical 最好写在 HTML 里，非用 JS 不可时要和原始 HTML 的值一致，并且页面上只能有一个。
网址检查显示 URL is on Google，是不是就一定会有排名？
不是。这个状态只说明页面被索引、可以出现在结果里，工具没检查出现在 Google 上的所有条件。要确认，直接在 Google 搜索这个 URL。
懒加载做完怎么验证生效了？
用网址检查工具看渲染后的 HTML。图片或视频的 URL 出现在 img 或 video 元素的 src 属性里，说明设置正确；不在渲染后的 HTML 里，等于没加载。
JS 站点收录慢，要不要找人做 javascript seo services？
先按排查顺序确认卡在哪一步，再决定花不花钱。渲染队列本身就要等，改代码改不动排队这件事。这几步自己查得出来，不需要外包也能定位。
页面能不能被搜到，看渲染后的 HTML 就够了，设计稿上什么都看不出来。把这套顺序走一遍，大多数问题自己就能定位。
发表评论