发布前SEO检查清单

发布前质量保证（QA）是SEO流程 中的最终发布关卡。这里是三个契约的交汇点：文章类型合规、元素使用正确，以及先前研究、证据、实施和审核工作的完成。任何适用项目未通过的页面将返回进行修正。

关卡： 最终发布前质量检查。时间盒： 标准页面60–90分钟；对于涉及监管、安全、金融、医疗或技术重大影响的声明，需增加专家时间。负责人： 一位编辑、内容负责人或SEO负责人（非最终实施者），并拥有阻止发布的权限。

软性检查清单不是真正的检查清单，因为"大致完成"没有稳定的含义。在截止日期压力下，可选的表述会变成记忆辅助工具，困难的检查项会被忽略。在质量检查开始前明确发布授权人。质量检查负责人可以判定通过或失败；只有指定的内容主管、SEO负责人或同等人员才能批准书面例外或判定某项不适用的规则。他们不能为了赶工期而放弃虚假声明、缺失的必填元素、占位资源、损坏的规范URL或受阻的可索引性。

为什么存在这个关卡，以及为什么在这里执行

本关卡使用已批准的文章类型规范、元素契约、来源记录、最终文案、已实施的候选页面和专家批准。这些输入冻结后才执行检查，因为质量检查无法验证持续变动的目标；而在发布前执行是因为一旦URL上线，缺陷就可能被复制传播。

早期质量检查验证的是可能变更的草稿。跳过它会使得后续审核人员无法区分页面漂移、规范变更和从未检查过的页面。发布后的质量检查会将廉价修正变成公开缺陷。

输入与输出

输出是一份契约，而不是一条聊天消息。发布者必须能够依据它采取行动，而无需重建审核过程。

检查清单

以下每个项目都包含行动、理由、方法、工具和可观察的完成条件。“已检查SEO"或"看起来不错"绝不是可接受的证据。

1. 文章类型合规

确认所选文章类型和范围。 是什么： 将候选页面与文章类型库 中的某一项匹配，并移除属于其他类型的材料。为什么： 页面类型决定意图、结构、证据和转化行为。怎么做： 用读者决策为每个章节打标签，并与该类型的用途和排除项进行比较。工具： 已批准的简报、主题地图和文章类型页面。完成条件： 恰好记录了一个主要类型，开头、正文和CTA服务于该类型，且没有任何章节仅服务于其他类型的功能。

追溯所需结构和字数范围。 是什么： 将每个必需章节映射到渲染后的候选页面，并计算其字数是否在指定范围内。为什么： 缺失章节会产生未解答的问题，而不受控制的长度会用数量掩盖漏洞。怎么做： 使用需求-标题矩阵和自动化计数，然后手动检查边界情况。工具： 文章类型规范、源代码和渲染页面。完成条件： 没有缺少任何必需章节，且每个章节都在其规定的最小值和最大值范围内。

2. 元素合规

验证元素、位置和参数。 是什么： 将元素映射表与源代码和渲染结果进行比较。为什么： 位置和字段是功能的一部分；埋入深处的直接答案不再能优先回答问题，格式错误的参数可能破坏输出。怎么做： 从上到下检查，并验证允许的字段、值、嵌套和语法。工具： 元素规范、验证器和浏览器。完成条件： 每个必需元素都在其要求的位置上，每个参数都有效，且没有未解释的重复项。

强制执行类型化元素优先级。 是什么： 在每段有已注册用途的文字上应用元素编写规则 。为什么： 自由文本可能看起来相似，但无法承载组件标识、字段、可访问性行为或结构化输出。怎么做： 将每个区块的功能表述为动词——定义、警告、比较、指导、总结——并检查是否有匹配的元素。工具： 元素库和源代码检查器。完成条件： 没有任何段落在需要使用类型化元素时使用了自由文本。

3. 内容质量

独立测试答案。 是什么： 不带标题或周围段落阅读直接答案块 。为什么： 搜索和AI检索系统可能只提取这一段。怎么做： 检查它是否指明主题、回答问题、包含必要的限定条件，且不依赖"这”、“它"或"如上所述”。工具： 隔离文本视图和人工审核员。完成条件： 当该元素为必需时，答案独立自洽、准确，且在其指定的40–60字范围内。

验证声明、语言和唯一性。 是什么： 将实质性声明追溯到证据，首次使用时解释术语，并将候选页面与服务于相同意图的页面进行比较。为什么： 无依据的声明损害信任，而高度相似的内容会相互竞争并产生漂移。怎么做： 标记名称、日期、数字、因果声明、产品行为和相似候选内容；支持、限定、合并或移除它们。工具： 证据登记表、原始来源、站内搜索和相似度报告。完成条件： 没有任何实质性声明缺乏支持，没有任何专业术语未得到解释，且没有现有页面在没有合并计划的情况下服务于相同的意图和范围。

4. 前置元数据

验证标识和预览字段。 是什么： 将前置元数据规范 应用于标题、描述、关键词、entity和文章类型连接。为什么： 这些字段驱动路由、预览、架构和关系，无需读取正文。怎么做： 运行字段和长度验证，然后将含义与可见页面进行比较。工具： 前置元数据检查工具和人工预览。完成条件： 标题唯一且准确，描述为150–160字符，关键词包含6–8个相关条目，且entity与文章类型契约匹配。

验证治理和FAQ字段。 是什么： 检查日期、作者、审核人、所有权和可见的FAQ结构 是否与前置元数据一致。为什么： 匿名记录使问责无法实现，而FAQ漂移会导致可见答案与结构化答案不一致。怎么做： 将字段与发布轨迹及标准化后的可见文本进行比较。工具： 源代码解析器、追踪器和渲染页面。完成条件： 必需的日期和负责人有效，需要时人工审核人已命名，FAQ数量满足类型最低要求，每一对都匹配，且没有隐藏或空条目残留。

5. 结构化数据

要求正确的架构。 是什么： 确认页面及其可见元素存在适用的架构标记 。为什么： 缺失或通用的标记丢弃了内容模型已提供的机器可读含义。怎么做： 将输出的类型和属性与文章类型和元素契约进行比较。工具： 渲染后的HTML和架构验证器。完成条件： 每个必需的架构类型出现一次，必需属性已填充，且没有输出不适用类型。

验证一致性，而不仅仅是语法。 是什么： 将架构中的名称、日期、作者、实体、FAQ、步骤和声明与可见内容进行比较。为什么： 有效的语法仍然可能描述不可见或相互矛盾的信息。怎么做： 验证JSON-LD，然后将值与页面进行比较。工具： 结构化数据测试和人工审核。完成条件： 零错误，且架构中没有任何事实与可见内容相矛盾或超出可见内容。

6. 内部链接

向上和向外链接。 是什么： 提供指向相关支柱页面的路径，以及指向相关节点的上下文路径。为什么： 层级结构帮助读者和爬虫理解页面所属位置，而横向链接延续读者的任务。怎么做： 将每个内部链接映射到一个真实的后续问题，而不是填充配额。工具： 链接图谱和渲染页面。完成条件： 页面至少有一个指向其支柱页面的链接，至少有一个指向相关节点的相关横向链接（当存在相关节点时），并且在发布前或发布时有至少一个现有页面链接到该页面，使其不被孤立。

检查目标和锚文本。 是什么： 打开每个目标并检查其锚文本 。为什么： 看似合理的URL可能缺失、已被重定向或不相关，而通用标签隐藏了目标的目的。怎么做： 运行内部链接检查器，然后在句子上下文中手动检查锚文本。工具： 爬虫和浏览器。完成条件： 没有内部链接返回错误，每个目标都支持其周围声明的上下文，且没有独立的"点击此处"、原始URL或误导性的精确匹配锚文本残留。

7. 媒体

验证资源、替代文本和时效性。 是什么： 确认每张图片都存在、具有有意义的替代文本 或合理的空替代，并反映当前界面。为什么： 损坏、模糊、占位或过时的媒体会移除信息，并可能使操作说明无法使用。怎么做： 禁用图片、检查路径、复现产品操作步骤，并比较标签、数值、裁剪和脱敏处理。工具： 资源检查器、可访问性审计、实际产品和浏览器。完成条件： 没有缺失资源或占位符，替代文本准确，且每张截图代表当前步骤。

8. 技术发布

验证路由、可索引性和替换。 是什么： 检查slug、一个自引用的规范URL 、状态码、robots行为、可索引性 和重定向。为什么： 内容在错误的路由、在noindex后面或旧URL被遗弃时无法发挥作用。怎么做： 检查渲染后的页面头部和响应、比较注册信息、并追踪每个被替换的路由。工具： 头部检查器、重定向映射、源代码检查器和URL检查。完成条件： 批准的URL返回200状态码，带有一个预期的规范URL且无屏蔽；每个被替换的URL通过一次永久跳转到达最近的可用替换。

测试移动端稳定性。 是什么： 检查窄宽度的阅读、交互、溢出和累积布局偏移 。为什么： 在桌面上正常工作的组件可能隐藏控件、裁剪表格或在媒体加载时移动内容。怎么做： 测试代表性移动宽度，并在限速条件下加载页面。工具： 浏览器设备模式和性能报告。完成条件： 所有内容和控件保持可用，无水平页面溢出，测量的CLS为0.1或更低。

9. AI就绪度

测试提取和初始HTML。 是什么： 检查服务器提供的HTML中的答案、定义、关键事实、比较和结论是否作为独立段落存在。为什么： 检索系统可能只选取一段，且可能不执行客户端代码。怎么做： 获取初始HTML，移除周围上下文，检查实体名称、限定词、单位和代词。工具： HTML获取、段落提取器、浏览器和AmICited审计。完成条件： 每个优先事实在无JavaScript的情况下存在，且单独保留其主题、含义和限制。

暴露程序性结构。 是什么： 验证FAQ对和有顺序的步骤是否编码为可识别字段并保持可见。为什么： 标题和样式框可能看起来正确，但机器接收到的却是非结构化散文。怎么做： 将元素输出、可访问结构、架构与可见顺序进行比较。工具： 可访问性树和结构化数据验证器。完成条件： 每个必需的FAQ作为问答对是机器可读的，每个必需的程序在可见和结构化输出中保留有序步骤。

AmICited中的工具

使用产品检查候选页面并建立交接证据；它不能替代人工判断。

1. 配合AI可访问性与智能体就绪度 打开智能体就绪度审计 ，检查可访问性、爬虫可达性、站点地图覆盖范围和智能体可读内容。
2. 配合URL检查 使用检查候选URL 工具，验证索引状态、移动端可用性和富媒体结果判定。对于新URL，在交接中分配在线检查任务。
3. 配合内容新鲜度 打开新鲜度审计 ，为时效性页面设置维护信号和下次审核日期。历史记录从追踪开始时建立；没有历史记录并不意味着没有变化。
4. 通过工作区连接使用SEO MCP 进行可重复的只读URL、新鲜度、Web Vitals和可访问性检查。保存输出结果或运行标识符。

自动化：将确定性检查脚本化，保留人工决策

可以脚本化但仍保持手动操作的检查项，在压力下会被跳过。对稳定的、机器可观察的结果进行自动化；需要人工判断目的、真实性和上下文。

自动化生成的是证据，而非批准。失败阻止关卡通过；通过的脚本不能代替人工列的内容。

决策规则

“不合格"必须是可观察的。除非所选文章类型或元素定义了更严格的标准，否则使用以下阈值；更具体的契约优先。

“N/A"不是更宽松的通过。它仅在项目确实不适用时有效——例如，无需重定向因为没有URL被替换——且记录中说明了原因。例外必须说明被更改的规则、业务理由、风险、批准人、修正负责人和有效期。发布授权人签署例外；质量检查审核人不能自我批准。

交付物：通过记录

为确切候选版本附加一份不可更改的记录。后续审核必须能够区分"从未检查"和"已通过规范版本1检查”。存储结构化字段，而不是绿色勾号的截图。

页面路径 / 规范URL：
发布候选版本ID或内容哈希：
文章类型和实体：
规范版本：
质量检查负责人：
发布授权人：
开始 / 完成时间（时间戳）：

检查项：
- 分组 / 项目：
- 结果：通过 | 失败 | 不适用
- 证据：验证器输出、来源位置、目标地址或观察结果
- 检查人 / 检查时间：

例外：
- 规则和范围：
- 理由和风险：
- 批准人：
- 修正负责人 / 有效期：

决策：通过 — 发布 | 失败 — 保留
在线验证负责人和截止时间：
下次维护审核日期：

通过记录只能追加。规范或候选版本发生变化时，需要新的审计，而非重写历史。

失败后的处理

失败启动的是修正循环，而非审核线程中的协商。

1. 质量检查负责人将候选页面标记为失败 — 保留，记录证据，并在继续测试肯定会变更的版本时停止。
2. 内容负责人修复文章类型、元素、文案、元数据和证据方面的失败。实施负责人修复架构、链接、媒体、路由、渲染和自动化方面的失败。专家重新检查其领域内的声明。
3. 修正者识别每个变更的表面。质量检查负责人重新运行失败的项目、其依赖项目以及受变更影响的所有分组。例如，重写的答案将重新触发对声明、元素合规、架构一致性和AI提取的检查。
4. 质量检查负责人创建带有新时间戳的结果。发布保持阻止状态，直到每个适用项目通过，且每个N/A或例外具有有效的授权依据。

作者不认证自己的修正。质量检查负责人拥有记录，生产团队拥有修正，专家拥有领域批准，发布授权人拥有例外。

常见问题

• 将关卡当作校对。 语法可以完美无缺，但页面可能使用了错误的文章类型、与架构矛盾或无法被索引。
• 测试源代码而非发布候选版本。 有效的Markdown不能证明模板输出了预期的规范URL、可访问结构或响应式布局。
• 让每个项目都手动操作。 审核人员反复点击确定性检查项，直到截止日期教会他们跳过清单。
• 让每个项目都自动化。 绿色验证器无法判断证据是否支持因果声明，或比较是否回答了读者的决策。
• 接受"上线后再修复”。 这将发布前关卡变成了未记录的后备清单，并抹去了"通过"的意义。
• 允许同一个人既实施又批准。 自我审查会遗漏假设，因为审核人记住的是预期行为而非观察实际输出。

交接

下一阶段是发布和在线验证。质量检查交接内容包括：批准的候选版本、通过记录、规范路由、重定向映射、发布窗口和批准的例外。发布者返回在线URL和部署时间；在线验证负责人重复检查状态码、规范URL、可索引性、重定向、架构、链接、媒体、移动端和CTA。

如果生产环境不同，受影响的检查项重新开启。如果一致，则添加在线URL和证据，但不覆盖候选版本结果。后续审核使用存储的规范版本来区分漂移和标准变更。

常见问题

常见问题

通过意味着候选页面以可检查的证据符合当前契约。任何其他情况都是保留。学院布局的结尾CTA跟随此FAQ部分。