用 Workbubby 实施 JavaScript SEO：能力优先的安全页面调查工作流

AI 智能体可以帮助你处理 JavaScript SEO，但前提是先弄清楚它实际上能做什么。Workbubby 能读取本地文件吗？能浏览公开页面吗？能检查原始 HTML，或使用完成渲染的浏览器吗？能运行命令吗？能访问已连接的抓取导出数据吗？能创建工单、发送消息或安排定时任务吗？这些答案会决定什么样的工作流才是安全的。

仅凭智能体产品的名称，无法判断它拥有哪些权限。相似的智能体产品可能采用完全不同的部署模式、工具、审批节点、数据访问范围和日志记录方式。对于 SEO 工作，这一点尤其重要，因为看似很小的操作也可能改动 CMS、robots 指令、站点地图、部署内容或公开页面。

学完本指南后，你会得到： 一张符合实际 Workbubby 环境的能力卡、一份针对重要页面的只读证据矩阵，以及一份经过负责人批准的交接文档。本文不会假设 Workbubby 拥有终端、浏览器自动化、Git checkout、连接器、调度器或发布功能。

第一部分：不靠猜测理解 JavaScript SEO

为什么页面看起来完整，仍然可能存在 SEO 问题

在 JavaScript 网站中，服务器返回初始响应后，可能还会继续执行脚本、数据请求、客户端路由和 UI 更新。浏览器会把这些部分组合成一个看似完整的页面。搜索系统仍然需要发现 URL、发起请求、处理可以访问的资源、理解链接和内容，然后决定将哪些信息编入索引。

JavaScript 本身并不是问题。真正的风险是：决定页面用途的内容、稳定的目标地址或页面信号依赖了尚未验证的步骤。商品网格可能依赖某些状态下会失败的请求；卡片可能只通过事件处理程序进行跳转；无限列表较深位置的页面可能没有稳定 URL；不可用的商品也可能在客户端显示错误，而服务器仍然返回成功状态。

工作的重点是确认真实情况，而不是责怪所使用的技术。

四层证据

“未知”是不可缺少的答案。如果 Workbubby 只能读取附加的截图，它就无法检查原始 HTML。如果它能浏览公开页面，却不能使用渲染后的浏览器，就无法验证动态内容。如果它能读取代码库文件，却没有生产环境证据，也不能声称今天的线上 URL 实际返回了什么。

首次检查的七个 JavaScript SEO 项目

URL 与响应行为

URL 是否到达预期的最终页面？是否返回合适的状态？重定向是否直接且合理？客户端重定向也许对访客有效，但不应该掩盖响应层的问题。

主要内容是否可用

先确定页面上最重要的内容。商品分类页可能是标题、商品、价格和目标地址；文章页可能是标题和正文。记录这些内容是已经存在于提供的响应中、仅在渲染后出现、仅在交互后出现，还是根本不在现有证据里。

可抓取的目标地址

重要目标地址通常应该用具有稳定 URL 的普通链接表示。能够点击的卡片不一定是可以抓取的链接。这并不意味着智能体应该直接改写标记，而是意味着负责人应该检查当前的实现方式。

Canonical 与 robots 是否一致

Canonical 和 robots 信号应该与页面预期的 URL 及可用状态一致。Canonical 只是一项提示，不能修复重复或损坏的路由。Robots 指令和 robots.txt 都可能带来大范围影响，因此不要自动修改其中任何一项。

片段导航与客户端路由

当目标页面需要被单独发现时，#details 之类仅包含片段的路径不能代替页面 URL。History API 路由可以正常工作，但必须提供稳定、可路由的 URL，并让服务器正确处理直接请求。

延迟加载与无限滚动

延迟加载不一定有害。关键问题是：重要内容能否在不依赖随意滚动或点击的情况下到达。对于长列表，稳定分页或其他可抓取路径通常比假设滚动事件已经足够更安全。

元数据与结构化数据

Title、meta description、canonical、robots 和结构化数据应该准确描述用户看到的页面。结构化数据只是辅助信息，并不保证 Google 会显示富媒体搜索结果或提高页面排名。

用页面故事划定范围

在要求智能体开始调查前，先用几句话说明页面原本要完成的任务。

这样做能让 SEO 新手得到一个比“检查 SEO”更明确的起点，也会告诉智能体哪些事情绝对不能做。

第二部分：先建立 Workbubby 能力卡

使用准确的产品名称进行公开搜索后，我们仍未找到能够说明你的环境中已启用 Workbubby 功能的权威文档。因此，安全的方法是能力优先：在交付任务前，先让 Workbubby 说明当前实际存在的工具、信息源和审批边界。

只要求能力卡，不让它采取行动

针对这项 JavaScript SEO 工作，只报告你目前可以使用的能力。

请为每个项目标记：允许、不可用，或需要我的批准。
- 读取本地项目文件
- 浏览公开 URL
- 检查原始 HTML
- 检查渲染后的页面
- 运行命令
- 访问已连接的工具或数据
- 创建或编辑文件
- 创建工单或发送消息
- 发布、部署、提交 URL 或更改设置
- 安排重复任务

对于每项允许的能力，用一句话说明信息源或工具边界。
不要采取任何行动。不要根据产品名称推断能力。不要索要凭据，
也不要打开未列出的连接器。

把回答与案例一起保存。能力卡不是多余的行政程序。它可以避免把终端智能体使用的提示词交给只能处理附件的助手，也能防止具备浏览能力的智能体在不知不觉中跨入可写操作。

分配任务前，请先记录你的 Workbubby 环境中哪些能力已获允许、不可用或必须经过审批。

选择与能力卡相符的调查路线

如果某项能力不存在，就修改工作流，而不是要求智能体绕过限制。例如，无法浏览时附上响应捕获；没有连接器时，向数据负责人索取导出文件。

在任务本身写明访问边界

能力卡只是某一时刻的快照。每条提示词都要重复关键边界，避免旧任务或记忆扩大访问范围。

已批准的信息源：[列表]
这项任务允许的能力：[列表]
不可用的能力：[列表]
禁止的操作：编辑、发送、发布、定时、部署、提交 URL、更改设置，
或访问未列出的连接器。

如果答案依赖不可用的信息源，请标记“未知”，并指出负责人可以批准的
最小下一步检查。不要尝试绕过边界。

第三部分：执行只读 JavaScript SEO 调查

一个页面、一项访客任务、一份证据清单

从小处开始。选择一个有代表性的分类页、商品页、文章页或地点页，就足以测试模板机制。

只使用已批准的信息源，执行只读 JavaScript SEO 调查。

页面：[URL 或页面文件]
访客任务：[一句话]
必需内容和目标地址：[列表]
已批准的信息源：[列表]
不可用的信息源：[列表]

有证据时，检查以下项目：
- 最终 URL、状态、重定向、canonical 和 robots 是否一致；
- 主要内容和页面 title；
- 指向重要目标地址的普通链接；
- 片段导航和客户端重定向；
- 延迟加载和无限滚动；
- 元数据和结构化数据是否一致。

针对每个项目，返回证据、状态（已观察 / 可能风险 / 未知）、
它对访客任务的重要性，以及最小下一步检查。

不要编辑、发送、发布、定时、部署、提交 URL，也不要访问未列出的连接器。
不要编造索引、排名、抓取数据或效果数据。

预期输出： 一份观察矩阵。质量检查： 每一行都要列出信息源，不能把无法进行的检查写成结论。恢复方法： 删除没有依据的行；如果获得允许，附上缺少的信息源，只重新执行受到影响的检查。

从新手角度阅读矩阵

即使读者不了解任何框架，也应该能够读懂智能体的说明。对比以下示例：

更好的报告会告诉负责人目前知道什么、哪些部分仍不确定，以及下一步应该问什么。

把确认的观察结果转成负责人简报

不要让首次检查直接造成无人监督的修改。当观察结果重要到需要升级处理时，准备一份简洁的交接文档：

“Workbubby 也许能够创建工单”并不代表已经获得授权。负责人必须决定是否创建、创建到哪里，以及可以包含哪些内容。

第四部分：让自动化先通知，而不是直接修复

如果你的环境确认 Workbubby 可以安排定时任务，请从只读提醒或审核队列开始。不要从修改 robots、部署、更改站点地图、发布或提交 URL 开始。

安全的每周任务设计

按照已批准的时间，只审核提供的高价值 URL 列表和已批准的证据导出数据。
为每个 URL 记录运行日期、信息源列表、观察状态和负责人。只有在这项任务
明确获得写入权限时，才能在已批准的目标位置创建审核队列。

不要编辑代码、更改设置、发布、部署、提交 URL、发送外部消息，
也不要推断索引状态。将缺失或过期的证据标记为“未知”。

理想的输出应该是一个问题，而不是一次修复：

两个分类 URL 的渲染证据中看不到商品目标地址。请确认 DOM 捕获内容，并指定前端负责人。

第一次自动化应该生成可供审核的问题，绝不能直接在无人监督的情况下更改网站。

加入升级审批节点

智能体任务遇到以下情况时，应该停止并向指定人员申请批准：

• 要求编辑代码、CMS 内容、robots、站点地图或设置；
• 在已批准位置以外创建工单、消息或分享内容；
• 需要凭据、客户数据或新的连接器；
• 发现与原始页面故事不同的机制；
• 发现会影响示例页面以外的模板；
• 测试失败或缺少回滚路径。

升级内容应该包含证据和选项，而不是把建议包装成已经完成的操作。

维护一个小型审核队列

这个队列能够让责任和不确定性清晰可见，因此比塞满未排序警告的仪表盘更有用。

第五部分：验证经过人工批准的修改

如果负责人批准代码或设置修改，请使用符合实际环境的独立实施工作流。Workbubby 只能在能力卡和明确审批所确认的范围内提供协助。

按顺序验证

1. 必需的访客行为： 用户能否完成页面故事中的任务？
2. 响应行为： 最终 URL、状态、重定向、canonical 和 robots 信号是否符合批准的目标？
3. 渲染输出： 必需内容和目标地址是否出现在相关状态？
4. 保留的行为： 键盘导航、视觉状态、分析和错误状态是否仍然正常？
5. 已批准的搜索证据： 后续的检查、抓取、日志或 Search Console 信息源显示了什么？

任何单项测试都不能代替全部五项。浏览器测试不是索引证据，干净的源响应也不能证明渲染数据一定会成功。

在外部操作前定义回滚方式

对于经过批准的修改，要记录准确的撤销条件。条件可能是功能测试失败、分析事件中断、无法访问的导航路径、错误的状态，或超出预期的模板影响范围。如果无法说明回滚方法和负责人，这项操作就不适合无人监督的自动化。

记录决定

保存证据列表、负责人的决定、修改记录、测试结果、日期和仍然未知的项目。未来的智能体应该从这份记录开始，而不是重新生成没有依据的诊断。

绝对不要假设 Workbubby 能做的事情

由于研究期间未能确认这个特定产品配置的权威文档，因此不要假设 Workbubby 能够：

• 运行终端命令；
• 浏览或渲染公开网站；
• 读取 Git 代码库；
• 访问 Search Console、分析数据或抓取数据；
• 创建任务、工单或消息；
• 安排重复任务；
• 部署或发布；
• 以某种特定方式保护你的数据。

请在自己的环境中直接确认能力。这不是对产品的批评，而是安全使用任何可能因团队而采用不同配置的智能体所必需的做法。

常见错误

把终端智能体提示词复制到未知环境

智能体可能没有提示词预设的工具，也可能拥有你不打算使用的写入工具。请从能力卡开始。

让智能体自行决定权限

智能体可以报告可用工具，但在具体任务中哪些工具和数据获得批准，必须由人类负责人决定。

把浏览器截图当成完整技术审计

截图是有用的证据，但无法确定响应状态、源 HTML、代码原因或索引状态。请明确说明它能够显示和不能显示的内容。

把定时任务变成静默运行的自动修复系统

先从观察和审核队列开始。只有在访问范围、审批行为、测试、负责人和回滚方式都写清楚后，才能加入写入操作。

把 Workbubby 称为与 OpenClaw 相同的产品

除非你自己的文档确认两者存在关系，否则应该把它们视为不同产品。模式相似并不能证明工具、数据处理方式或权限相同。

常见问题

Workbubby 与 OpenClaw 是同一个产品吗？

除非你的部署文档另有说明，否则请把它们视为不同产品。智能体模式相似，不代表功能或安全行为相同。

我可以在 Workbubby 中复用 Codex 或 Claude Code 的 skill 吗？

应该复用的是决策逻辑，而不是安装前提。先确认你的环境能够访问和批准什么，再将流程转换成 Workbubby 文档所描述的配置。

最安全的第一项 Workbubby 任务是什么？

先要求能力卡，然后让它仅使用你提供的信息源，为一个重要页面建立只读证据矩阵。

Workbubby 能判断 Google 是否已经将页面编入索引吗？

只有当你的环境中获得授权的搜索信息源提供这项信息时才可以。单凭浏览器画面、HTML 文件或代码库 checkout 无法确定。

最安全的第一次自动化是什么？

使用已批准输入生成负责人审核队列的只读提醒。第一次不要自动执行部署、发布、robots 修改或 URL 提交。

作者：Martin Hayes，Auspia 的 GEO Playbook Builder，已制作 200 多份执行检查清单。Martin 专注撰写分步工作流、实战指南和运营检查清单。