JavaScript SEO 听起来像只有开发人员才需要理解的主题，但最先要问的问题其实很普通：这个页面应该帮助访客完成什么？哪些内容和链接必须可用？服务器返回了什么？页面运行之后出现了什么？还有哪些事实是我们不知道的？
Hermes Agent 很适合用于这类工作，因为 JavaScript SEO 调查包含多项不应混在一起的任务。一个角色可以记录初始响应，另一个角色检查已提供的渲染证据，第三个角色再把两份报告整理成决策卡。至于是否修改代码，仍然必须由人类负责人决定。
完成这套流程后，你会得到： 一份针对单个重要 URL 的一页式案例文件。每项发现都有明确的证据来源，未知事项被清楚标记，下一步则限制在一个具体范围内。这套流程不会证明 Google 已收录页面，不承诺排名，也不授权 Agent 修改生产环境。
第一部分：给不写JavaScript的人的JavaScript SEO入门
网页是分阶段交付的
打开传统 HTML 页面时，许多有用内容可能已经存在于服务器响应中。但对于高度依赖 JavaScript 的网站，第一次响应可能只是起点。浏览器还会下载脚本、请求额外数据、创建商品卡和导航，并在初始 HTML 到达后更新元数据。
这并不意味着页面的 SEO 一定有问题。Google 能处理 JavaScript，许多现代网站也成功使用它。实际风险在于“不一致”：访客最终可能看到完整页面，但重要内容、URL 或页面信号在初始响应中不存在，被延迟到交互之后，卡在失败的请求后面，或以不容易被发现的方式呈现。
可以把页面理解为四个可观察的层级：
层级 | 初学者要问的问题 | 有用的证据 |
|---|---|---|
URL 与响应 | 请求的 URL 是否返回预期页面 | 状态码、重定向、响应标头 |
源 HTML | 浏览器运行应用之前已经有哪些内容 | 保存的响应或“查看源代码” |
渲染后页面 | 脚本和数据请求完成后出现了什么 | 渲染后 DOM、截图、浏览器捕获 |
搜索证据 | 获得授权的搜索工具实际报告了什么 | URL 检查、抓取导出、日志、Search Console |
这些层级回答不同的问题。截图显示的是某个浏览器呈现的画面，不是服务器返回的内容。200 响应只表示成功交付，不代表已经被收录。渲染后 DOM 中出现稳定链接，也无法证明搜索引擎已经选择该 URL 进入索引。
优先检查六项信号
初学者不必先学完整套前端框架，才能检查页面。从与发现和理解直接相关的六项信号开始即可。
- 状态码和重定向。 有效页面应返回符合用途的状态。不存在的商品不应伪装成成功的空白页面，重定向则应避免混乱链路，并在正确目的地结束。
- 主要内容。 页面标题、核心说明、商品或文章信息，以及其他定义页面目的的内容，都应在相关页面状态中可用。如果必须点击或依赖不稳定请求才会出现，请记录这种依赖。
- 可抓取链接。 重要目的地通常应使用具有稳定 URL 的真正链接，例如带有
href的a元素。只依靠事件处理器运行的可点击卡片，对访客可能有用，但发现路径比较脆弱。 - canonical 和 robots 指令。 canonical URL、robots meta、响应状态、站点地图和内部链接应表达一致的信息。canonical 是提示，不是命令，也不应被用于掩盖网站本来可以防止的 URL 重复。
- 渐进式加载。 延迟加载图片、无限滚动、前端分页不应让有价值的条目只能通过滚动、点击，或没有稳定 URL 的浏览器状态才能访问。
- 元数据和结构化数据。 由 JavaScript 生成的 title、description、canonical 和结构化数据，必须准确反映可见页面。结构化数据能帮助理解，但不保证产生富媒体搜索结果。
渲染不等于收录
弄清这种差异可以避免许多错误工单。渲染问的是系统能否处理页面并取得预期内容。收录问的是搜索引擎是否选择存储该 URL，让它有机会出现在搜索结果。排名则关注它在何时、针对哪个查询、出现在什么位置。
一次浏览器操作无法证明这三件事。如果唯一证据是一张截图，诚实的结论可能是：“内容在这个浏览器状态中出现；服务器响应、搜索引擎渲染和索引选择仍然未知。”这比“Google 看不到页面”更有用，因为它直接指出团队还缺少哪些证据。
检查前先写页面故事
Agent 可以生成很长的检查清单，却仍然错过页面的业务目标。因此要先写一个简短的页面故事：
字段 | 示例 |
|---|---|
页面 |
|
访客任务 | 比较商品并前往商品页面 |
必须出现的内容 | 分类标题、商品名称、价格、商品链接 |
应保持一致的信号 | 200 响应、canonical URL、可收录的 robots 指令、标题 |
可用证据 | 响应捕获和渲染后 DOM |
不可用证据 | Search Console 和服务器日志 |
不在范围内 | 平台迁移、发布、robots.txt 变更、批量编辑 |
这个页面故事会成为所有 Hermes 角色共享的任务说明。人类负责人也可以用一个简单标准判断：如果某项发现不影响访客任务或页面信号，它可能不应放入这个案例。
第二部分：把调查变成Hermes Agent团队执行手册
Hermes Agent 的公开文档介绍了 agents、tools、skills、memory、automation 和 subagents 等概念，但实际工具和权限仍取决于部署环境。因此，这份手册只定义输出和边界，不假设每个 Hermes 环境都能浏览 URL、执行命令、读取代码库或创建工单。
让三个角色负责不同的证据工作
不要创建一个名为“修复 JavaScript SEO”的大型任务。把收集和解释分开，再把解释和行动分开。
角色 | 读取内容 | 产出 | 禁止操作 |
|---|---|---|---|
响应侦察员 | 已提供的响应、标头、源代码、重定向 | 响应事实和信号冲突 | 推测 Google 收录状态 |
渲染侦察员 | 渲染后 DOM、浏览器捕获或批准的页面证据 | 内容、链接和加载观察 | 修改组件或路由 |
分流编辑员 | 两份报告和获得授权的导出 | 案例文件、优先级、负责人问题 | 把假设改写成事实 |
你可以使用三个 subagent、三个按顺序执行的任务，或者让同一个 Agent 进行明确分隔的三个阶段。重点不是增加 Agent 数量，而是让每一次交接都可以被检查。
案例文件会在技术决策之前，持续分开显示证据来源和不确定状态。
建立共享的证据约定
侦察员开始前，先定义可以使用的数据源。如果缺少输入，必须标记为不可用，而不是用看似合理的答案填补。
你正在处理一个 JavaScript SEO 案例。
目标页面：[URL 或已提供的页面证据]
访客任务：[一句话]
必要页面元素：[列表]
允许的证据：[响应 HTML、渲染后 DOM、HAR、截图、抓取导出，
或代码库文件]
不可用证据：[列表]
保持只读。不得编辑文件、发布内容、提交 URL、修改 CMS、发送消息、
创建工单，或访问未被明确授权的账号。
每项观察都要记录证据来源，并使用其中一种状态：
CONFIRMED、PLAUSIBLE RISK、UNKNOWN、OWNER DECISION。
没有来自授权来源的特定证据时，不得声称搜索引擎已经收录、渲染
或让页面获得排名。预期输出： 简短的证据台账。质量检查： 每项观察都有来源。恢复方式： 如果报告中出现无来源结论，删除这些行，并只使用已批准的证据列表重新运行该角色。
运行响应侦察员
响应侦察员描述页面应用运行前收到的内容。根据批准的工具，它可以检查保存的响应、抓取导出或公开 URL。它应记录以下事实：
- 已知重定向之后的最终 URL
- 可以取得时的 HTTP 状态
- 响应中的 title、canonical、robots 指令和语言信号
- 定义页面目的的内容是否存在
- 前往必要目的地的普通链接
- 从已提供源代码中能看到的脚本和数据依赖
- 例如可收录页面 canonical 到其他 URL 的冲突
使用简单表格输出：
观察 | 证据 | 状态 | 重要原因 | 下一项检查 |
|---|---|---|---|---|
已提供响应中没有分类标题 | 响应捕获和行号 | Confirmed | 初始响应缺少定义页面目的的文字 | 与渲染后 DOM 比较 |
canonical 指向请求 URL | 响应捕获 | Confirmed | 信号内部一致 | 渲染后再次确认 |
Google 选择的 canonical | 没有授权来源 | Unknown | 无法从页面标记推断 | 合适时请求 URL 检查 |
侦察员不能因为内容不在响应中，就直接建议服务器端渲染。它发现的是一个条件，还不是原因或必要解决方案。
运行渲染侦察员
渲染侦察员检查团队实际能提供的完成页面状态，并与页面故事和响应台账比较。请它确认：
- 主要内容是否无需任意用户操作就会出现
- 重要目的地是否以稳定链接表示
- 渲染后元数据或 canonical 是否改变
- 延迟加载条目是否需要滚动或交互
- 无限滚动是否提供稳定且可访问的页面路径
- 错误、空白或不可用状态是否仍然有意义
- 必要数据请求失败时，内容如何变化
如果团队只有截图，侦察员无法检查链接标记或元数据。有渲染后 DOM 却没有网络捕获，也无法解释请求为什么失败。输出必须写明这些限制。
让分流编辑员保留不确定性
分流编辑员会合并两份报告，但它的工作不是让报告听起来更确定，而是保留观察、可能机制和缺少来源之间的差异。
状态 | 含义 | 示例 |
|---|---|---|
Confirmed | 已提供证据直接显示该条件 | 渲染后 DOM 捕获中没有商品链接 |
Plausible risk | 证据暗示失败路径，但没有确定影响 | 链接可能依赖点击处理器 |
Unknown | 没有提供必要证据 | 搜索引擎选择的 canonical |
Owner decision | 多种实现都可能合理 | 在卡片或主要操作上添加链接 |
优先级应根据页面影响和证据强度，而不是一项发现听起来有多技术。营收模板缺少主要商品链接，可能需要立即审查；没有证据支持的框架偏好则不需要。
把一项发现做成批准卡
分流后，只选择一项已确认或有充分支持的发现。不要把整份审计直接送去实施。
发现 ID：JS-01
页面和访客任务：[URL 和一句话]
证据：[具体的响应、DOM 或代码观察]
状态：[CONFIRMED / PLAUSIBLE RISK]
访客影响：[哪些内容可能难以访问或理解]
建议的最小行动：[一项范围明确的变更或调查]
受影响模板或系统：[KNOWN / UNKNOWN]
验收检查：[本地行为、响应、渲染后 DOM、功能链接]
回滚：[如何恢复之前的行为]
决策负责人：[姓名或角色]
实施状态：WAITING FOR APPROVAL
范围明确的批准卡，能把 Agent 的发现变成由指定负责人检查的决策。
Hermes 能准备卡片，但不能拥有业务或工程决策。memory 和 automation 功能本身，也不会让重大变更自动变得安全。
批准后使用独立实施任务
负责人批准行动，而且 Hermes 环境具备适当工具时，创建只包含批准范围的新任务。不要悄悄把审计任务变成写入任务。
只实施案例 JS-01 中已批准的行动。
变更前，重新说明：
1. 受影响文件或系统
2. 验收检查
3. 仍被禁止的操作
4. 回滚条件
变更后显示准确 diff 或变更记录，并只执行已批准测试。
不得部署、发布、提交 URL、修改无关文件或扩大范围。
如果实际文件或机制与批准说明不同，请停止并把新证据交还负责人。预期输出： 一份可审查的变更记录。质量检查： 不包含无关文件和操作。恢复方式： 测试失败或机制不同时，按照批准方式还原并重新打开案例。
分层验证结果
Agent 声称任务成功，不代表实施已经完成。按照页面交付顺序验证：
- 本地行为： 页面或组件可以构建，访客流程正常，而且无障碍和分析行为没有被破坏。
- 响应层： 状态、重定向、title、canonical、robots 指令和重要源内容符合批准目标。
- 渲染层： 必要内容和链接在相关页面状态中出现，并且不依赖隐藏交互。
- 搜索证据： 获得授权的数据可用时，记录 URL 检查、抓取、日志或 Search Console 实际报告的内容。不要用本地渲染替代。
- 决策记录： 保存日期、证据、批准行动、测试结果、负责人和回滚参考。
任何一层失败时，不要用自信的总结掩盖。把失败的检查和最小的下一项调查交还负责人。
可持续执行的Hermes每周流程
每周选择一个具有代表性且高价值的模板，而不是把大量 Agent 投入整个网站。
日程或阶段 | 活动 | 产出 |
|---|---|---|
收件 | 选择一个 URL 并编写页面故事 | 共享说明 |
证据 | 运行响应和渲染侦察员 | 两份台账 |
分流 | 合并事实、风险和未知项 | 一份案例文件 |
审查 | 选择一项范围明确的行动 | 已签署的批准卡 |
验证 | 测试已批准的变更或调查 | 分层结果记录 |
当多个页面出现同一个已确认机制时，再为受影响模板创建新的范围案例。不要因为一个 URL 就宣布全站缺陷。
常见失败和恢复方法
Agent生成重复报告
它们的任务重叠了。为每个角色提供不同的来源列表和输出约定。响应侦察员不解释渲染行为，渲染侦察员也不重写响应事实。
缺少数据时分流报告仍然过度肯定
强制使用四种状态标签，拒绝没有证据来源的行。Unknown 是有用结果，因为它告诉负责人下一步要索取什么。
还没找出错误就开始争论SSR
回到页面故事和已确认症状。SSR、prerendering、hydration 调整和 client-only rendering 都是架构选项，不是通用答案。
定时任务开始制造噪音
把范围缩小到单个模板或已提供的 URL 列表。定时任务应生成包含日期、失败和负责人的审查队列；除非另行批准，否则不应修改内容或发送外部消息。
响应和渲染报告彼此不一致
这种差异常常正是调查重点。保留两项观察，不要选择看起来更好的版本。例如源代码没有商品信息，渲染 DOM 却有；下一个问题就是渲染路径是否可靠，以及结果是否仍然提供稳定目的地。请索取最小的额外来源，例如已知响应捕获或批准的抓取结果，不要把不一致直接当成失败证明。
审查者想从一个页面推断整个网站
单个 URL 可以提出模板假设，却无法证明适用范围。第一个案例找出可能共享的机制之后，再增加第二个代表页面。如果第二页不同，就拆成不同案例。这比宣布全面缺陷更慢，但能避免为单个边缘情况启动昂贵项目。
第一个完整案例示例
假设某个分类页面有自然搜索访问，但 SEO 同事发现商品卡很难审计。页面故事说明访客必须能比较商品并前往详情页。响应侦察员在已提供捕获中找到 200 响应和自引用 canonical，但初始源代码中没有商品名称。渲染侦察员看到渲染后的名称和价格，却因为捕获不完整而无法确认主要卡片操作是否是标准链接。
分流编辑员不应写“Google 无法收录商品”。有证据支持的案例要小得多：
项目 | 状态 | 下一步 |
|---|---|---|
请求 URL 成功响应 | Confirmed | 保留为基准 |
商品内容在渲染后出现 | Confirmed | 记录渲染依赖 |
商品目的地使用标准链接 | Unknown | 请求渲染标记或代码负责人检查 |
搜索引擎索引选择 | Unknown | 必要时请求获得授权的 URL 检查 |
第一个决策可能只是批准检查代码库。如果代码负责人之后确认卡片只使用点击处理器，没有稳定的主要目的地，第二个决策再批准小型且可测试的组件变更。即使排名数据尚未变化，团队已经从焦虑式说法前进到可验证机制，这就是成功的 Hermes 流程。
常见问题
多个Hermes Agent可以并行检查同一个页面吗？
可以，前提是它们拥有不同的只读角色、不重叠的证据来源和共享案例格式。不要让多个 Agent 编辑同一个实施区域。
Hermes可以判断Google是否收录我的JavaScript页面吗？
不能只依靠源代码或浏览器画面判断。请提供获得授权的 URL 检查、抓取、日志或 Search Console 证据，否则把收录问题标记为 Unknown。
响应侦察员一定要浏览生产URL吗？
不一定。只使用可用且已批准的工具和来源。在受限环境中，保存的响应或抓取导出可能才是正确输入。
源代码缺少元素就一定需要服务器端渲染吗？
不一定。真正的解决方案可能是稳定链接、正确状态、可用数据路径、一致元数据，或其他小型模板变更。先诊断机制。
初学者最适合的第一个Hermes任务是什么？
针对一个重要 URL 运行一个响应侦察员，要求提供带来源的事实表，再判断是否需要渲染页面证据。
作者：Julian Mercer，Auspia 的技术 SEO 从业者，拥有 14 年经验。他专注于可抓取性、渲染、网站架构，以及让 AI 更容易读取内容的技术基础。
