排查 JavaScript 问题有点像给你的网站看病：除非能看到明显损坏的地方，否则它们通常不会以明显的方式呈现。
相反，这通常是一个从症状开始，然后将它们与最可能的原因联系起来的过程。
多年来，在优化不同框架下由 JavaScript 驱动的网站的 SEO 过程中，我们已经熟悉了各种症状以及它们所指示的问题。
我们学到的最重要的一点是什么？虽然 JavaScript 和 SEO 并非总能和谐共存，但你不需要成为开发者也能做出诊断。
我们将帮助你将网站正在经历的症状与我们见过的每种症状背后最常见的问题对应起来。然后，我们将向你展示如何验证哪些问题正在起作用，理解这些根本原因是什么，以及如何根据具体情况让你的 JavaScript 对 SEO 友好。
但首先，只有一个问题：你是否非常熟悉搜索引擎如何抓取 URL 和渲染 JavaScript？
- 是的，我们来诊断问题吧。
- 我不介意复习一下。
JavaScript 如何影响 SEO？
若不了解搜索引擎如何与 JS 交互，就无法成功执行 JavaScript SEO 审计或实施最佳实践。
要让 Google 解析含 JavaScript 的页面，必须先进行页面渲染。爬虫无法自行执行 JavaScript，因此需调用渲染服务协助。
尽管渲染过程复杂且充满细节差异，但通过以下高度简化的流程解析，您能掌握排查 JS 错误所需的核心知识：
- 爬虫发起服务器请求（类似用户通过浏览器访问页面），可快速获取响应中返回的页面内容/代码（即 “response” HTML）。
- 当页面中被检测到 JavaScript、API 等需额外解析处理的代码时，该 URL 会被送入渲染队列。
- 渲染过程中，JavaScript 及其他代码被解析。此过程可能为爬虫揭示更多可抓取内容，或引发其他页面变更（下文将详述）。
SEO关键要点
渲染是需要额外时间、资源和整体投入的附加步骤。
根据网站配置方式，渲染发生在不同环节，其”成本”由不同服务方承担——这可能意味着需由您的品牌承担。
不同网站如何处理渲染？
最主流的两种渲染方案实际上代表了广泛光谱的两端：
- 服务端渲染 (SSR)
若网站采用服务端渲染，爬虫可直接从服务器响应（response HTML）中获取大部分或全部内容。渲染成本由品牌方预先承担，无需Google（或其他爬虫）额外处理。 - 客户端渲染 (CSR)
若网站采用客户端渲染，大部分或全部内容仅在渲染后生成（rendered HTML）。渲染成本由Google承担，但可能导致索引效率和搜索可见性下降。
在这两个极端之间，还存在其他配置方案，能更均衡地分担JavaScript的渲染成本。
此处我们暂不深入探讨 JavaScript 渲染如何影响索引的细节，因为就本文目标而言，上述解释已足够。
若您想全面了解渲染机制，可参阅 Google 官方文档获取更详尽的说明。
请谨记：渲染并非搜索引擎的义务！
搜索引擎资源并非无限。当 Google 的网页渲染服务（Web Rendering Service）无法确认”投入产出比”时，将会主动节省宝贵资源。
这意味着：若网站未建立页面价值信号（如优质内容、内部链接、外链等），URL 进入渲染队列的频率将显著降低。
当 URL 无法进入渲染队列时——且关键内容均依赖渲染生成——搜索引擎将失去评估页面的上下文依据。因此，该页面极可能无法被有效索引和排名。
在后续解决常见 JavaScript 问题时，请始终牢记这一核心原则！
排查JavaScript问题需从症状入手
记录异常症状是锁定网站核心JavaScript问题的第一步。那么您观察到哪些现象？
“诊断问题无需开发者身份”
症状1：部分/全部页面未出现在Google中
目标页面未被索引（Search Console验证），且未出现在搜索结果页（SERP）
→ 检查以下JS问题
- Google无法发现URL
- JS篡改关键索引信号
- 上下文<head>元素缺失或错位，迫使搜索引擎承担额外渲染成本
症状2：网站/页面表现下滑
核心页面性能低下，或全站加载延迟
→ 检查以下JS问题
- Google无法获取部分/全部内容
- 无效链接导致权重传递中断
- 过度依赖JS渲染，增加Google处理负担
- 初始HTML与渲染HTML存在显著差异
- 致命JS错误阻断HTML渲染
- 前述索引问题同样影响性能
症状3：无效URL出现在搜索结果
Search Console显示索引了垃圾页面（如规范指向重复的URL、空白页/错误页）
→ 检查以下JS问题
- 关键索引信号缺失/错位/矛盾
- JS动态生成无效页面
- 404状态码失效导致索引膨胀
症状4：网站抓取异常
第三方爬虫手动抓取时出现：
→ 检查以下JS问题
- 结果中缺失部分/全部URL
- 抓取结果遗漏重要标签/页面信息
- URL变体无效或不可抓取
- 缺少XML网站地图
- 存在无效链接
症状5：图片未展示/表现不佳
Search Console显示部分/全部图片未索引，或已索引图片排名低下
→ 检查以下JS问题
- 图片目录被屏蔽
- 图片配置错误
症状6：Search Console大量软404报告
页面实际失效却未返回404状态码
→ 检查以下JS问题
- 平台配置生成无效页面
- 页面未返回真实404状态码
症状7：网站迁移后性能下降
前端框架改版或重构后
→ 检查以下JS问题
⚠️ 需执行完整JS SEO审计，迁移往往引发多维度变更
症状8：浏览器页面加载失败
访问有效URL显示空白页
→ 检查以下JS问题
- 网站依赖JS渲染但浏览器禁用JS
串联症状与常见JS SEO问题
解决网站性能与索引问题的核心在于实施针对性JS SEO最佳实践。下面深入解析八大问题成因、验证方法及优化方案：
问题1：Google无法发现URL
爬虫通过链接发现新页面。若无法跟踪站内链接，则无法抓取未知页面。
无内链时，URL发现依赖：
✅ 实时更新的网站地图
✅ 外链（但不可控）
常见成因包括：
（下文将展开具体技术原因）
成因：唯一URL不存在或无效
若浏览器中URL未变化，或页面路由使用 # 符号，则该页面无法被独立索引。搜索引擎既无法将用户精准导向站内目标位置，亦无法理解页面上下文。
解决方案
👉 为您的JS技术栈配置专用路由插件（如Vue Router或ReactRouter）
技术背景解析
# 符号的URL（哈希URL）技术术语为 片段标识符URL，传统用于同页面内容定位（如跳转到章节标题），常被称为”跳转链接”或”锚点链接”。
⚠️ 但部分JS框架会利用哈希加载异于当前页的内容（如 #! 哈希惊叹URL即为早期方案）。
✅ 用户端虽可正常访问，Google却无法处理此类URL
Google官方建议
🚫 避免使用哈希URL
✅ 采用 History API
✅ 路由应通过目录结构/slug/参数生成独立URL
成因：锚点链接编码错误
<a> 标签的 href属性 和 锚点链接 是HTML中最主流的内链结构。原因在于：
🔍 Googlebot（及多数搜索引擎爬虫）仅支持标准<a>标签格式，无法识别以下形式：
- Router组件生成的虚拟链接
<span>等包裹的伪链接onClick事件触发的JS跳转
✅ 链接必须为含 href属性 的 <a> 元素方能被Google发现
成因：分页机制配置错误
分页问题是SEO领域的常见痛点，通常由现成的JS插件/库实现。三种主流形式包括：
- “加载更多”按钮
- 无限滚动
- 参数化分页（如
?page=3）
⚠️ 核心矛盾：
这些插件的默认功能往往违反Google分页最佳实践。典型问题表现为：
- 用户点击”下一页”时 URL保持不变
- 或存在独立分页URL，但存在以下缺陷：
→ 未通过标准<a href>标签实现链接
→ 因meta robots/canonical设置导致变体不可索引
成因：XML网站地图缺失或不全
除链接外，XML网站地图是辅助搜索引擎发现页面的核心工具。主流JavaScript前端框架均内置或支持插件实现：
✅ 动态生成网站地图
✅ 自动同步有效URL
问题：Google 无法抓取页面上的某些元素
抓取并非一蹴而就。通常情况下，Google 能够渲染页面，但某些通过 JavaScript 加载的内容仍然无法抓取。这意味着文本、图片和链接等元素可能会在抓取时丢失。
大多数 JavaScript 工具都能帮助查找响应和渲染后的 HTML 之间的差异。它们可以提供诸如字数和内部链接数等信息，但它们本身并不能告诉你具体缺少了什么。
这就是为什么手动抽查非常有益。这应该是每个人在进行 JavaScript SEO 审计时都应该包含的一个步骤。
从网站的每个主要页面模板（主页、服务/产品页、集合页、博客页等）中选择一个 URL。通过 Search Console 中的“测试实际网址”工具运行该页面，并使用搜索功能在渲染后的 HTML 中查找重要的图片、链接、文本和媒体。
图片：通过 Search Console 网址检查工具中的“查看已测试页面”功能，在渲染后的 HTML 中搜索规范标签。
如果发现缺少元素：
- 确定是哪些页面元素导致的问题。 常见的原因包括选项卡和手风琴菜单、分页中的链接或下拉导航模块中的链接。
- 这些元素通常在整个网站中以相同的方式实现，因此可能需要在多个地方进行修复。
- 考虑缺失内容对于当前页面，甚至对于整个网站的重要性。然后，根据需要与您的开发团队合作，使其可供抓取。
问题：内容在用户交互后动态加载
请记住，抓取工具无法点击、滚动、悬停等。因此，如果链接或文本在用户交互发生之前不存在于 HTML 中，那么它们对抓取工具来说是不可用的。
例如，手风琴下拉菜单通常是组织产品页面信息的用户界面元素。然而，抓取工具无法点击展开手风琴。
如果你在点击展开手风琴之前，在 HTML 中（你可以使用 Chrome 检查工具）看到“隐藏”内容，那么你的手风琴内容就没有使用 JavaScript 来填充内容。这是个好消息！
如果该内容在你点击之后才出现在 HTML 中，那么它对抓取工具来说是不可用的。
问题：网站依赖渲染
如果你的网站依赖于客户端渲染（或倾向于客户端渲染）来提供内容，那么“有意义的”响应 HTML 将很少或根本没有。这本身并不是一个问题，但值得注意的是，在渲染之前内容可用的网站通常会看到 25-35% 的流量提升。
首先深入了解并确定：
- 渲染完成后，搜索引擎是否可以访问所有重要的页面内容。
- 关键的
<head>元素在渲染之前是否可用——如 Google 建议的那样——以确保关键的页面上下文和索引信号存在于响应 HTML 中。
关键的：
- 标题
- 元描述
- 元 robots
- 规范 URL
重要的：
- 导航链接
- 分页链接
- H1 及其他标题
理想的：
- 页面内容
- 内容中的
<a href> - 图片和 alt 文本
如果你的页面只包含关键信号（例如，没有重要或理想的信号），但仍然没有被索引和/或排名不佳，那么很可能是渲染导致了性能问题。
有几种方法可以检查，但最快速和最简单的方法可能是使用 View Rendered Source。这个方便的 Chrome 扩展程序会显示响应（原始）HTML 与渲染的 HTML，并突出显示任何差异。
无论网站使用哪种 JavaScript 框架构建，在实施时它很可能默认采用客户端渲染（Client-Side Rendering, CSR）或水合（Hydration，类似 CSR）。
为什么它们默认使用 CSR，如果它会导致 SEO 问题？ 嗯，因为它具有性能优势。CSR 允许开发人员创建更具交互性的网站（页面转换、动画等），同时将运行这些网站的成本转移到用户及其浏览器上。
通常，在开发方面需要做一些努力来确保：
- 搜索引擎能够发现和抓取网站上独特、有效的 URL。
- 关键的权威信号（如内部链接）是可抓取的。
- 我们营销人员定义为页面“关键”或“理想”的内容可供搜索引擎抓取。
这也是为什么能够向开发人员解释问题及其影响如此重要的原因。他们从一个完全不同的角度来看待渲染。
此外，开发团队的这些更改通常与配置有关。你越早沟通这些需求，更改的“负担”就越轻。
原因：权威信号不足
提高 Web 渲染服务处理 URL 队列的几率的最佳方法是表明该 URL 很重要。
我们可以通过帮助 URL 获得良好排名的相同元素来做到这一点：权威域、自引用规范标签、显示相关性的元数据，以及来自网站内外其他重要页面的链接。
问题：抓取工具无法访问页面构建资源
为了渲染页面，Google 需要能够发现并解包关键的构建模块，例如媒体和脚本。当存在阻碍这种情况发生的问题时，就无法完整准确地渲染页面。
原因：关键目录被 robots.txt 阻止
脚本（CSS、JS）和图像文件通常嵌套在专门的子域名或子文件夹中。这些类型的目录最终出现在 robots.txt 的禁止规则中并不少见，这意味着大量资源对抓取工具不可用。这可不太妙！
同时，在客户端浏览器中，你不会注意到任何异常。
如果你知道文件所在的目录，那么跳过工具，直接检查 robots.txt 是相当容易的。（如果不知道，开发团队肯定会知道！）
原因：关键的 JS 错误导致解析问题
在页面上使用 JavaScript 时，你经常会在 Chrome 控制台中看到错误日志。无论是完全支持 JS 的平台，还是仅仅在页面上加载一些交互元素，都是如此。
许多这些错误——甚至可以说大多数错误——不会给用户和搜索引擎带来问题。事实上，在开发社区中，许多这些与 JavaScript 相关的错误可以被忽略，这已经是一个被普遍接受的观点。
然而，有些错误会导致页面无法解析。渲染服务无法分离单个 HTML 元素，也无法在 JavaScript 中构建 SEO 内容或识别它们之间的关系。在这种情况下，你通常会在实际页面上看到某种视觉影响。
在“测试实际网址”工具中，你可以通过“查看已测试页面”报告的“更多信息”选项卡下的“JavaScript 控制台消息”来检查错误。话虽如此，了解错误是否导致问题的最佳方法是与开发人员沟通。
图片：Google Search Console 网址检查工具中“实际测试”的“更多信息”选项卡
请不要以“看看这些错误，它们正在损害我们的 SEO”作为开场白。（当然，你也不会这么说！）解释你看到的渲染问题，说明其重要性，并向专家咨询是否存在关联。
原因：图片配置不当
与链接类似，图片也必须经过适当的配置和编码才能对 SEO 友好。首先检查 Google 是否能够抓取图片所在的目录。
如果抓取权限正常，那么很可能是图片在 CSS 中被调用，而不是在 HTML 中。为了能够被索引，图片必须使用 <img src> 标签。
注意： 并非所有图片都对索引很重要。例如，在 CSS 中实现的装饰性图片保持原样即可。
问题：响应 HTML 和渲染 HTML 之间存在显著差异
JavaScript 可以在页面渲染（或在客户端浏览器中构建）后添加、删除、移动或更改内容。这包括所有重要元素，例如：
- Meta robots 标签
- 规范 URL
- 标题
- 元描述
- 页面文案
- 媒体，如图片和视频
- 页面正文中的内部和外部链接
- 导航元素
在页面层面，这意味着重要的指令、信号或上下文可能不正确。从大规模来看，响应 HTML 和渲染 HTML 之间的许多不一致会使得搜索引擎的工作量比它们预期的要大。我们知道，这对于 SEO 来说绝不是好事。
就 JavaScript SEO 工具而言，爬虫是您最好的朋友。由于它们具有渲染能力，使得检查两组 HTML 之间的差异变得容易得多。
Sitebulb 是发现任何差异的首选工具。如果您正在使用 Sitebulb 抓取一个 JavaScript 网站，“渲染与响应”报告会为您指出所有差异。
或者，在 Screaming Frog 中，你需要启用 JavaScript 渲染来运行抓取。
图片：Screaming Frog Spider 配置中的 JavaScript 渲染设置。
无论使用哪种工具，你都可以将其连接到 Google 的 URL Inspection API，以获取诸如上次页面抓取日期、Google 选择的规范网址与用户选择的规范网址，以及索引状态等信息。
原因：JavaScript 正在改变索引信号
我们前面提到的关键信号，比其他信号更重要的是包含在响应 HTML 中。Meta robots 和规范标签是其中最重要的两个，因为它们指示了页面是否应该被索引。
出现 JavaScript 中提供的信号与响应 HTML 中提供的信号不同的情况并不少见。这可能会导致混淆和索引问题，因为存在冲突的信息。
问题：关键的 <head> 元素缺失或错位
<head> 是 HTML 中提供索引关键标签的地方，包括元数据、meta robots 和规范 URL。
抓取工具总是会首先查看 <head> 来判断是否应该抓取和索引页面。不在 <head> 中的指令可能无法被找到或正确使用。
原因：索引指令通过 JavaScript 提供
如果 Googlebot 在响应 HTML 的 <head> 中找到了 meta robots 标签——这是正确标签应该放置的位置——它可能会接受该指令并照此执行。如果该标签设置为 noindex，它通常就不会再将页面放入渲染队列。如果 meta robots 在渲染后又设置为 index，Google 可能永远也看不到它。
尽管如此，当渲染前和渲染后的 HTML 存在冲突的规范和索引信号时，情况并非总是像“Google 会遵循初始指令”那么简单。此时一切皆有可能发生！
为了获得可预测且准确的结果，meta robots 和规范标签应在响应 HTML 中准确设置，并在渲染 HTML 中保持不变。
原因：没有元数据
JS 框架通常使用插件或其他库来创建页面的 <head> 元素并包含元数据。如果你发现你的网站缺少你期望看到的元数据，这里有一个方法可以帮助你识别潜在的解决方案并将这些信息传递给你的开发人员：
- 确定你的网站正在使用哪个平台或 JS 框架。 我们建议使用名为 Wappalyzer 的浏览器扩展程序来帮助识别。如果你无法判断，你需要询问你的开发团队。
- 研究适用于你特定平台的元数据处理工具（例如，React 通常使用名为 Helmet 的库）。
- 一旦选定，创建关于你希望这些元标签如何出现的文档，以便开发团队可以正确配置。（这是考虑全局回退与 CMS 中所需的自定义字段的好时机！）
问题：JavaScript 正在生成不需要的页面
网站使用 JavaScript 的最强大原因之一是其动态创建页面的能力。这对于分页结果或筛选结果页面等元素尤其方便。但如果没有正确的限制，这些动态功能可能会导致问题。
原因：Google 正在抓取构建（build）URL
一些前端框架使用静态站点生成 (SSG) 作为渲染解决方案。静态站点生成器获取原始数据和一组模板，并使用它们为网站上的 URL 创建静态 HTML 页面。
这意味着什么？通常，大部分或全部内容都在响应 HTML 中，而无需服务器端渲染的成本。（这是一个很棒的解决方案，但请注意，它不适用于需要高度交互的页面。）
在经历这个“构建”过程时，SSG 会在每次运行构建时（通常是每天或每周）在站点服务器上创建一个新文件夹。页面在嵌套在该文件夹中的 URL 上构建（/build 很常见）。
构建完成后，该内容会移动到公共 HTML 文件（也就是您的网站）。但是，如果构建被中断，该移植过程就不会发生。
结果是一个包含垃圾、重复页面的“构建文件夹”——通常数量很多——这些页面可供搜索引擎访问。
使用静态站点生成器时，定期清理构建文件夹是一个好主意。考虑要求开发人员设置一个 cron 作业（例如，按指定计划运行的自动化任务），每天清理它们，这应该相对容易实现。
附言：如果您没有看到任何构建 URL 显示在 Google Search Console 中，请考虑在您的 robots.txt 中禁止构建文件夹。（但如果 Google 已经找到了一些这些 URL，则不要这样做，因为抓取和索引的一个有趣的细微差别是它们将保留在索引中）
原因：分页 URL 未受限制
分页的一个常见问题是 URL 变体没有结束。例如，一个网站可能链接到第 34 页，即使只有 10 页结果。
当搜索引擎发现这些类型的 URL 时，它们通常会报告为软 404，因为它们不提供 404 状态并且不提供任何内容。
这通常是由于格式错误的分页链接造成的：系列中的最后一页（或几页）链接到后续页面，而没有“检查”是否需要更多页面。
简单的解决方案是在分页逻辑中内置在没有更多结果时停止添加链接。
原因：页面不提供真实的 404 状态码
这是您在使用单页应用程序 (SPA) 的开箱即用配置时经常会遇到的另一个问题。
默认情况下，每个页面都会返回“200 成功”HTTP 状态码——无论是否准确。
重要的是，您能够与开发人员分享理想的最终状态，以便他们可以进行适当的调整，以在 SPA 上正确提供 404 状态码。
或者，我们看到许多网站将无效页面重定向到专门的 404 页面，而该页面也不提供 404 状态码。在这种情况下，404 URL 很有可能最终也会出现在 Google 搜索结果中。（所有这些重定向都在将权重传递给 404 URL！）
请记住，问题不总是 JavaScript 错误。
在 SEO 领域，“这取决于具体情况”这句话经常被提及——因为 SEO 是多层次、细致入微且不总是容易诊断的。从网站权威性到内容质量再到技术 SEO，许多因素都可能单独或共同导致当今品牌的索引和性能问题。
此外，JavaScript 并非新生事物。Google、SEO 专业人员和开发人员都在不断发展和改进他们处理 JS 网站的方式。如今，许多由 JavaScript 驱动的网站在自然搜索中表现出色。
当网站出现性能问题时，准确理解整个情况可能会感到复杂和令人困惑。这就是为什么我们 SEO 专业人员有时需要退后一步，进行更全面的调查，以阐明为什么自然流量下降了。
所以请记住，当你深入挖掘时——你正在寻找的问题可能与 JavaScript 无关——甚至可能与技术 SEO 都无关！
清楚地沟通问题以推动进展
找到问题只是优化 JavaScript SEO 的第一步。下一步是让业务部门——尤其是产品和工程团队——认可这项工作的价值和必要性。
既然你对渲染过程和常见的 JavaScript SEO 问题有了扎实的理解，那么接下来就是用相同的语言进行沟通。这归结为你如何记录问题。
让每个人从相同的角度看待问题的最佳方式是创建一个阐述清晰的 SEO 商业案例。
Leave a Reply