JavaScript SEO 的目标，是让 JavaScript 网站可以稳定地被发现、抓取、渲染和索引。Google 能用 Evergreen Chromium 执行 JavaScript，但这不保证每个 Route、API Response 或 Client State 都会成为索引页面。
JavaScript 网站可以排名。更稳妥的做法是：每个有价值页面都有稳定 URL、可抓取的 <a href>、有用 HTML、准确 Status 与索引信号，而且最终内容不依赖 Click、Login 或不稳定 API。
Google 如何处理 JavaScript
Google 官方说明三个主要阶段：Crawling、Rendering 和 Indexing。处理中会先从 Initial Response 提取链接，把合适页面放进 Rendering Queue，由 Web Rendering Service 执行 JavaScript，再处理 Rendered HTML。
Rendering 需要排队；Google 没有公布每个 URL 保证多久完成，也没有公开固定“Rendering Budget”。应先找出失败阶段，不要把所有问题都归因于所谓第二波延迟。如果证据不只与 JavaScript 有关，使用抓取与索引指南继续诊断。
| 阶段 | 所需证据 | 常见失败 | 验证方法 |
|---|---|---|---|
| 发现 | Crawlable Link 或 Sitemap 中的持久 URL | Button、Hash Route、孤立页面 | 内部抓取与 Link Graph |
| 抓取 | HTML 与必要资源可访问 | robots、权限、4xx/5xx、Blocked API | HTTP Response、Log、URL Inspection |
| 渲染 | Script 完成并产生有意义 DOM | Runtime Error、过期 Bundle、API/CORS Failure | Rendered HTML、Screenshot、Console、Resources |
| 索引选择 | 有用内容与一致指令 | Noindex、重复页、错误 Canonical、Soft 404 | Page Indexing 与 URL Inspection |
| 提供结果 | 与查询相关的已索引 Document | Intent、质量或更强页面 | Query/Page 数据，不只 Render Test |
Initial HTML、Rendered HTML 与已索引内容不同
HTTP Response 是 Server 最初传送的内容；Rendered DOM 是 Script 执行后的结果；Indexed Document 是 Google 最终选择的版本。只看浏览器无法证明 Google 索引了什么。
关闭 JavaScript 适合检查 Initial Response 和韧性，不等于模拟 Google。比较三个层次，并记录具体 URL、User Agent、时间与 Release。
| 层次 | 回答的问题 | 工具 | 限制 |
|---|---|---|---|
| Response HTML | JS 前收到什么？ | curl、View Source、Non-rendered Crawler | 看不到 Final DOM |
| Rendered DOM | 这个 Browser/Test 渲染什么？ | Dev工具、Rendered Crawler、Rich Results Test | 本地成功不代表已索引 |
| Google Live Render | Google 现在能否访问和渲染？ | URL Inspection Live Test | 不保证会索引 |
| Indexed State | Google 选择了什么？ | Indexed URL Inspection、Search Console | 不保证某个 Query 排名 |
根据页面需求选择 Rendering 方式
不存在唯一“SEO 认证”的 Framework。应选择最稳定交付页面主要用途的方法，再衡量 Freshness、Cache、Server Reliability 与 Interaction Cost。
Google 说明 Server-side 或 Pre-rendering 对速度和不执行 JavaScript 的 Crawler 仍然有帮助；web.dev 也通常建议在内容允许时优先考虑 Static 或 Server Rendering，而不是完整 Client Rehydration。
| 模式 | 首次回应 | 适合 | 主要风险 |
|---|---|---|---|
| Static Generation (SSG) | Build-time 完整 HTML | 文章、服务、Docs、已知 Route | Build 过期或漏生成 Route |
| Server-side Rendering (SSR) | Request-time HTML | 经常改变的公开页面 | Origin 慢、Cache 复杂、Server Failure |
| Streaming SSR | 分段传送 HTML | 分阶段取得资料的动态页面 | 重点内容仍可能延迟 |
| Hybrid/Islands | HTML + 局部互动 Component | 内容为主、少量 Tool/Widget | Component 规则不一致 |
| Client-side Rendering (CSR) | App Shell 后由 Browser Render | 登录工具与复杂互动状态 | 重点内容依赖 JS/API |
| Prerender Snapshot | 预先生成 HTML Snapshot | 有限 Route、过渡系统 | 覆盖和更新漂移 |
Dynamic Rendering 是临时方案，不是默认架构
Dynamic Rendering 会向特定 Crawler 提供 Rendered Version，用户则收到 Client-rendered Version。只要内容等效，Google 不把它视为 Cloaking；但官方把它定义为临时 Workaround，长期仍建议 Server Rendering、Static Rendering 或 Hydration。
只有现有系统短期不能修改时才使用，并记录 Crawler Detection、Content Parity、Cache Freshness 与退出计划。两版的声明、链接或 Structured Data 不同，会产生质量与政策风险。
用可靠 HTML 提供核心答案
公开 Landing Page、文章、Category 或产品页，稳妥默认是把 Main Title、Core Copy、Primary Links 和有用 Media 放在 Initial 或可靠 Rendered HTML，再用 JavaScript 加强互动，而不是让核心答案依赖 Click。
Hydration 也可能出错：资料不一致会替换 Server DOM、清空内容、重复 Component，或让页面看似完成但控制还不能用。需要测试慢速网络、API 失败与直接打开 Deep URL。
- 渲染前后 Primary Topic 与 Claims 相同。
- H1、重点正文和 Primary Action 保留。
- Navigation 与正文链接有真实 Destination。
- User-specific 内容与公开可索引内容分开。
- API Failure 显示有用 Fallback，不是 Empty Shell。
- Hydration 不移除或重复重要 DOM。
- Mobile Render 包含同样索引重点。
建立可抓取链接与持久 Route
Google 通常只抓取带有可解析 href 的 <a>。JavaScript 可以插入这种 Anchor；但只有 Event Handler 的 div、span 或 Anchor 不是同等的发现路径。
Client Routing 使用真实 Path 与 History API。直接请求、Refresh、复制链接和 Browser Back 都应回到正确 View。Google 通常不支持用 URL Fragment 代表不同页面内容。
| 组件 | 建议 | 避免 |
|---|---|---|
| Navigation/Card | <a href="zh-cn/services/seo-geo/"> | div onclick 或无 href 的 routerLink |
| SPA Route | Clean URL + History API | /#/products 代表可索引内容 |
| Deep URL | Server 返回对应 Route Page | 返回通用 首页 Shell 或 404 |
| 分页 | 顺序可抓取 Page URL | 没有持久页的 Infinite 滚动 |
| Filter | 只索引稳定且有价值组合 | 每个短暂 State 都产生参数 |
| Modal/Tab | 若不是独立 Landing Page 就共用 URL | 把隐藏状态当成完整页面 |
保持 Metadata 与索引信号稳定
Google 能处理 JavaScript 写入的 Title、Description 与 Canonical，但 Initial HTML 正确时更容易控制。不要先输出一个 Canonical，再在渲染后换成冲突值。Canonical 与跳转指南进一步说明重复合并和迁移处理。
尤其要小心 noindex：Google 表示发现 noindex 后可能跳过 Rendering，因此依赖 JavaScript 移除它可能不会生效。
- 清楚 Title 与有用 Meta Description。
- 一个一致 Canonical 指向首选 URL。
- 明确 Robots Meta 或 X-Robots-Tag。
- 正确语言、Localized Link 与 Hreflang。
- XML Sitemap 只列首选 200 URL。
- Structured Data 描述当前可见 Route。
- Metadata 不泄露 Environment、Tenant 或 User State。
- Server Response 与 Rendered Page State 一致。
让 API 与 Hydration 能应对失败
如果核心页面依赖 API，要确认 Endpoint 可匿名访问、使用合适 Web Protocol、CORS 正确、Response 足够可靠，而且页面能处理部分或失败资料。带有缓存登录的 Browser Session 不是有效 Crawl Test。
不要只靠 Client Analytics 判断 Googlebot Rendering。Google 说明 Web Rendering Service 可能省略与核心内容无关的 Request；应结合 Server、CDN、API Log 与 Rendered Output。
| 失败 | 收到的结果 | 较稳妥回应 |
|---|---|---|
| API Timeout | 永远显示 Spinner | Server-render 重点资料或稳定 Fallback |
| 权限泄漏 | Blank/401 Panel | 公开资料使用 Anonymous Endpoint |
| Hydration Mismatch | Server 内容被移除或重复 | 统一 Server/Client Data 并监控 Error |
| 过期 Cached Bundle | Markup 与 Runtime 不一致 | Content-hashed Asset + Compatible Deploy |
| CORS/CSP Issue | Request 或 Script 被挡 | 测试 Production Header 与 Origin |
| Third-party Outage | 核心内容消失 | 第三方功能保持 Noncritical |
Lazy-load 时不要隐藏可索引内容
Google 不会通过 滚动 或 Click 与页面互动。官方建议是：当相关内容出现在 Viewport 时就加载。Native Lazy Loading 或 IntersectionObserver 可以不依赖用户动作完成。
不要 Lazy-load 主 LCP Image。Infinite 滚动 必须让每个 Chunk 有持久 URL、该 URL 内容稳定、前后页可顺序链接、可以直接打开，并在主要可见 Chunk 改变时使用 History API 更新地址。
| 内容 | 可靠模式 | 测试 |
|---|---|---|
| Hero/LCP Image | 可发现 src/srcset；适合时 Eager | Initial Viewport 与 Rendered HTML 已加载 |
| Below-fold Image | Native Lazy + Width/Height | URL 出现在 Rendered Element |
| 文章/产品 Batch | 分页 URL + Infinite 滚动 增强 | 每页可独立打开和链接 |
| Accordion | 文字已在 DOM，Control 只改变显示 | Click 后不需再 Fetch 答案 |
| Video/Embed | 稳定 Poster/Fallback + 预留尺寸 | Provider 失败仍保留页面含义 |
返回有意义的 Status 与 Redirect
Client Router 不能修复所有错误的 Server Response。有效 Document 应返回 200；永久移动通常用 Server-side 301/308；不存在页面返回 404/410；临时故障不应伪装成 Empty 200。
对于无法直接返回 Missing Route Status 的 CSR SPA，Google 记录了两种 Soft 404 Workaround：跳转到 Server 返回 404 的 URL，或为 Client Error Page 加 noindex。实际可行时仍应修复 Server Routing。
| 状态 | 建议回应 | 原因 |
|---|---|---|
| 有效公开 Route | 200 + 有意义内容 | 进入正常处理 |
| 永久移动 | 301/308 到最相关 URL | 明确 Destination 与 Consolidation |
| 临时移动 | 真正临时时用 302/307 | 保留 Temporary Intent |
| 删除且无替代 | 404/410 + 有用 Error Page | 避免 Soft 404 |
| Application/Server Failure | 合适 5xx | 提示重试，不是薄弱内容 |
| Private Route | Authentication + 合适控制 | 避免意外公开索引 |
把 Image、Structured Data 与语言当作 Route Data
JavaScript 生成 JSON-LD 可以被处理，前提是 Final Rendered Markup 有效且符合可见内容。应测试代表性 Production URL 的 Rich Results Test 与 URL Inspection，而不只测试开发 Component，并用结构化数据指南核对声明。
Image 需要可抓取 Source URL 和有用 Alt；多语言 Route 需要翻译正文、Localized Metadata、一致 Canonical 与 Hreflang。不要在同一可索引 URL 先渲染一种语言，再按 Browser Location 或 Cookie 切换。
- 可见标题与 Metadata 来自同一资料记录。
- Canonical/Hreflang 使用最终公开 URL。
- Structured Data ID 与 Breadcrumb URL 符合 Route。
- Image URL 不需要 Session Token。
- Currency、Availability、Date 保持一致。
- 每种语言通过 Crawlable Link 到达。
- Placeholder 不进入 Production。
控制资源、Cache 与性能
不要阻挡理解页面所需的 JS 或 CSS。Google Rendering 会缓存资源，因此应使用 app.[hash].js 这类 Content Fingerprint，并确保 HTML 与 Asset 相容。把 CDN、CSP、CORS 与 API 当作 Production Dependency 监控。
JavaScript 也会影响Core Web Vitals。过度 Hydration、Long Task 与 Third-party Script 可能在内容可索引的同时拖慢互动。应追踪真实瓶颈，而不是只看 Bundle Size。
先诊断现象，再决定是否换 Framework
| 现象 | 第一份证据 | 调查方向 |
|---|---|---|
| URL 没被发现 | Internal Crawl/Link Graph | href、Orphan Route、分页 |
| 已抓取但内容缺失 | Response vs Rendered DOM | JS/API Error、Blocked Resource、Interaction |
| 索引错误 URL | Google-selected Canonical | Canonical Conflict、Parameter、Internal Link |
| 被排除为 Soft 404 | HTTP Status + Rendered Copy | Generic Shell、Missing API、Client Error |
| 错误 Title/Snippet | Initial/Rendered Head + H1 | Shared Template、Stale Route State |
| Image 缺失 | Rendered img Source + Fetch | Lazy Loading、Placeholder、Permission |
| 部分语言没索引 | Localized Render + Hreflang | Same-URL Switching、Missing Link |
| 已索引但没流量 | Query Relevance + Quality | 不一定是 JavaScript 问题 |
可重复执行的 JavaScript SEO 审核
把 Finding、Evidence、Owner 与验证结果记录进SEO 审核流程，让渲染现象成为有负责人和验收标准的 Release Task。
- 列出公开可索引 Template、Route Pattern 与 Rendering Mode。
- 抽样高价值、新、深层、分页、多语言、Redirect 与 Missing URL。
- 记录 Status、Header、Raw HTML 与 Resource Access。
- 分别 Non-rendered 与 Rendered Crawl，比较 URL、Link、Copy 与 Metadata。
- Desktop/Mobile 直接打开并 Refresh 每个 Deep URL。
- 检查 Console、Network、CORS、CSP、Hydration 与 API Failure。
- 验证 Canonical、Robots、Hreflang、Schema 与 Sitemap。
- 对代表页面运行 Rich Results Test 与 URL Inspection Live。
- 比较 Live Render、Indexed State 与 Search Console Exclusion。
- 查看 Server/CDN/API Log 中的代表性 Googlebot Fetch。
- 按受影响 Template、Business Value 与证据强度排序。
- Staging 复测、受控发布并在上线后监控。
JavaScript Migration 上线 QA
| 关卡 | 通过条件 | 保留证据 |
|---|---|---|
| Route Parity | 每个有价值旧 URL 对应正常 Final URL | URL Inventory + Redirect Map |
| HTML Parity | 核心答案和链接不因 Rendering 改变而消失 | Raw/Rendered Comparison |
| Signal Parity | Title、Canonical、Robots、Hreflang、Schema 正确 | 自动 Export + Manual Sample |
| Error Behavior | Missing/Moved/Failed State 回应正确 | Status Test Set |
| Performance | Mobile 重点 Journey 仍可用 | Field Baseline + Lab Trace |
| Analytics | Consent、Event、Conversion 无重复 | Debug + Production Check |
| Rollback | 上一版本与资料可恢复 | Release Note + Owner |
JavaScript SEO 常见误解
- “Google 会执行 JavaScript，所以实现方式不重要。”
- “每个页面都会在保证的第二波索引。”
- “Google 公布每个 URL 的固定 Render Budget。”
- “CSR 一定不利于 SEO。”
- “SSR 自动解决 Discovery、Canonical 与内容质量。”
- “Sitemap 可以取代内部链接。”
- “用户能滑到底，所以 Infinite 滚动 一定能索引。”
- “Browser 成功渲染就证明已经索引。”
- “Dynamic Rendering 应永久作为默认。”
- “只要换 Framework 就会提升排名。”
常见问题
Google 能索引 Client-rendered React、Vue 或 Angular 吗？
可以，只要 URL 可发现、资源可访问、内容可渲染，并且页面最终被选择索引。Framework 本身既不保证也不阻止索引。
SEO 一定需要 SSR 吗？
不一定。SSR、SSG、Hybrid 与 CSR 都能工作。公开搜索 Landing Page 通常受益于可靠 HTML；登录后的 Application State 通常不需要索引。
Google 会立即渲染每个 200 页面吗？
合适的 200 页面会进入 Rendering Queue，但 Google 没有保证时间。Live Render 成功也不等于一定索引或排名。
应该关闭 JavaScript 测试吗？
可用来检查 Initial Response 与韧性，但不是 Googlebot 的复制。还要测试 Rendered Output、Google Live 与 Indexed Information。
JavaScript Redirect 安全吗？
Google 可以在 Rendering 时处理，但永久移动通常用 Server-side 301/308 更直接。
JavaScript 可以修改 Canonical 吗？
可以被处理，但不应与 Original HTML 冲突。最好由 Route Source of Truth 产生一个稳定值。
JavaScript 可以加载后移除 noindex 吗？
不要依赖这种做法。Google 发现 noindex 后可能跳过 Rendering，因此移除动作可能不会执行。
Dynamic Rendering 属于 Cloaking 吗？
用户和 Crawler 收到等效内容时，Google 不把它视为 Cloaking，但官方把它定义为临时 Workaround。
SPA 需要 XML Sitemap 吗？
公开可索引 Route 可以放进干净 Sitemap，但每个 Route 仍需 Direct Access、正确 Status、Crawlable Link 与有用内容。
如何证明索引下降由 JavaScript 引起？
找出 Raw、Rendered、Live-tested 与 Indexed Output 的可重复差异，再连接受影响 Template 与日期。流量下降本身不是证明。
官方参考资料
- Google 搜索 Central: JavaScript SEO basics
- Google 搜索 Central: fix JavaScript search problems
- Google 搜索 Central: crawlable links
- Google 搜索 Central: URL structure
- Google 搜索 Central: lazy-loaded content and infinite scroll
- Google 搜索 Central: dynamic rendering as a workaround
- Google 搜索 Central: HTTP status codes
- Google 搜索 Central: redirects
- Google 搜索 Central: JavaScript-generated structured data
- web.dev: rendering on the web
- web.dev: client-side rendering and interactivity
- MDN: History API pushState()
- Ahrefs: JavaScript SEO issues and best practices
- Semrush: JavaScript SEO guide
分享 Framework、Route Inventory 与受影响 URL。我们可以比较 Response/Rendered HTML、Crawl Path、Directives、Log 与 Indexed State，再定义最小可靠修复。
Google 排名如何演变：从 PageRank 到现代搜索系统2026年9月2日
Google AI 内容与 SEO：什么被允许、什么是垃圾内容，以及怎样安全发布2026年9月2日
Google Florida Update 2003：事实、理论与 SEO 教训2026年9月2日