Google SEO审计服务采购指南：范围界定、证据核对与验收标准

审计要回答的业务问题

在比较报价之前，先写下这次审计要支持什么决策。审计不是一份越厚越好的报告，而是一组用来回答具体问题的证据。如果用途不清，范围会自然膨胀到“什么都查一点”，最终每一项都无法核对。

常见的审计用途有三类：一是判断当前站点是否存在阻碍收录与抓取的结构性问题；二是评估内容资产与目标搜索意图之间的差距，为后续内容规划提供依据；三是为改版、迁移或更换服务商提供基线记录。三类用途对模块取舍不同：第一类以技术、索引为主，第二类以内容、内链为主，第三类需要五个模块都留下可对比的基线数据。

把用途写成三个可回答的问题，例如“哪些页面因技术原因无法被正常抓取”“哪些主题存在内容缺口”“站内链接是否让重要页面获得足够入口”。这三个问题会直接决定后面每个模块需要交付什么证据，也决定报告需要多深。

同时要明确使用方：是内部技术团队执行修复，还是由外部团队接手。使用方不同，报告对问题定位的精度要求不同——给执行团队的报告需要能定位到具体 URL 与具体配置，给管理层的摘要只需要结论与优先级。

本节产出：一页审计目标说明，包含用途类型、三个待回答问题、报告使用方。这份说明是后续所有模块取舍的判断输入。

技术审计交付什么证据

技术模块的证据必须能追溯到具体 URL 和具体检查动作，而不是一句“技术健康度良好”。采购时可以直接要求服务商按下列证据项交付，缺项即为范围缺项。

抓取与索引状态方面，应交付可复核的抓取记录与索引状态清单，标明哪些 URL 被抓取、哪些被排除，以及排除原因的分类统计。数据来源应说明是来自站点自身的服务器日志、搜索引擎提供的站长工具数据，还是第三方爬虫模拟结果——三者结论可能不同，来源必须写明。

页面性能与移动适配方面，应交付按模板或页面类型分组的性能测量结果，并注明测量工具、测量时间与网络条件。单次测量不足以作为验收依据，应要求同一组页面在相近条件下的重复测量记录。

结构化数据与规范标签方面，应交付逐项检查结果：哪些页面部署了结构化数据、类型是否与页面内容一致、规范标签指向是否自洽、是否存在互相冲突的规范声明。每一项都要给出可复核的页面样本，而不是只给通过率。

Google 在其搜索文档中说明，标准 SEO 基础适用于各类搜索呈现形式，且符合条件并不保证出现。这意味着技术审计的交付边界是“问题定位与证据”，不是“修复后必然获得某种展示”。验收时应按证据完整性判断，而不是按展示结果判断。

本节产出：技术审计证据清单，每项包含检查对象、数据来源、样本 URL、测量条件。

内容审计交付什么证据

内容模块最容易变成主观评价，因此必须把判断依据写成可复核的形式。

内容覆盖盘点应交付一份页面清单，按主题聚类，标明每个主题下已有页面数量与更新状态。数据来源可以是站点地图、内部链接图谱或内容管理系统导出，需注明导出时间。

意图匹配判断应交付逐页的判断记录：该页面面向什么查询意图、页面实际提供的信息类型是什么、两者是否一致。判断依据要写明，例如标题与首段表达的主题、页面主体是否直接回答该主题。Google 的搜索文档建议提供原创信息或分析、清晰的来源说明，以及能帮助目标读者完成任务的內容；审计可以据此逐页记录差距，但不应把这条建议表述为效果保证。

重复与薄弱内容方面，应交付相似页面分组清单与判定阈值说明。阈值是服务商设定的，采购者有权要求写明，否则同一批页面在不同服务商手里会得出不同结论。

本节产出：内容审计证据清单，每项包含页面样本、判断依据、阈值说明。

索引审计交付什么证据

索引模块回答的是“搜索引擎能看到什么”，证据必须来自可追溯的数据源。

索引覆盖状态应交付按目录或模板分组的收录与未收录清单，并标注未收录的可能原因分类。数据来源需写明是站长工具报告、日志分析还是两者交叉验证。

抓取预算与日志分析应交付日志解析结果，包含抓取频次分布、抓取最多的路径、返回状态码分布。若站点规模较小、日志量不足，服务商应说明样本局限，而不是用第三方估算替代并当作事实。

站点地图与 robots 配置应交付当前配置的逐条检查记录，标明哪些规则可能阻挡了本应被抓取的路径。这类检查必须给出配置原文片段与对应 URL，便于复核。

本节产出：索引审计证据清单，每项包含数据源、时间范围、样本与局限说明。

内链审计交付什么证据

内链模块的证据形式是图谱与统计，而不是零散建议。

链接结构应交付可复核的链接图谱或至少一份入链数量分布表，标明哪些页面入链为零或极少。孤岛页面识别必须给出完整 URL 列表，而不是举例说明。

锚文本分布应交付统计结果，包含锚文本类型分布与过度重复的锚文本清单。统计口径需写明：是否包含导航与页脚链接、是否区分站内与站外。口径不同，结论会显著不同。

层级深度检查应交付从首页到各主要页面的点击深度分布，标明超出预期深度的页面。

本节产出：内链审计证据清单，每项包含图谱或统计口径、样本、异常清单。

外链审计交付什么证据

下表用于逐项核对审计交付物。空白字段由你在收到报告后填写，通过条件与不通过条件在签约前与服务商确认。

优先级排序依据：先处理影响抓取与收录的问题，再处理影响页面理解的问题，最后处理结构与体验类问题。同一优先级内，按受影响页面数量排序。排序依据应在报告中写明，而不是由服务商口头给出。

范围边界：审计不包含修复执行、内容撰写、外链建设与效果承诺。若报价中混入这些项目，应要求拆分列示，避免用审计费用购买无法验收的承诺。

采购前需准备：站长工具或同类平台的只读访问权限、服务器日志导出权限、内容管理系统导出权限、当前站点地图与 robots 配置副本、以及一份现有报告（如有）用于对比基线。

验收标准如何写成可勾选条目

外链模块最容易出现“只给结论、不给依据”的情况。采购时要把外链审计拆成四类可复核的证据，每一类都要能追溯到具体数据源，而不是一句“外链质量一般”。

引用域统计证据。 应交付的是引用域清单，而不是链接总数。清单至少包含引用域、指向的目标页面、首次发现时间、链接类型（dofollow/nofollow）。数据来源应写明是第三方外链数据库导出，还是 Search Console 的链接报告导出。两者口径不同：第三方数据库是抓取估算，Search Console 是 Google 实际记录的链接样本，采购时要确认服务商用的是哪一种，并接受该口径的局限。

链接质量判断证据。 质量判断必须给出判断维度，而不是一个分数。可复核的做法是列出判断所用的维度（例如引用域自身的内容主题、页面是否可索引、链接是否位于正文区域），并说明每个维度如何取值。如果服务商给出的是单一“权威度分数”，要追问该分数的来源与计算方式；无法说明来源的分数不能作为验收依据。

锚文本分布证据。 应交付锚文本的分布统计，包含锚文本样本、出现次数、指向的目标页面。验收时关注的是分布是否可解释，而不是是否符合某个预设比例。任何“锚文本比例必须达到某个数值”的说法，都需要服务商说明该数值的来源，否则只能作为观察项而非通过条件。

风险链接证据。 风险判断必须逐条给出理由。可复核的形式是：链接地址、判定为风险的依据（例如页面已无法访问、页面主题与目标页面无关、链接出现在明显非编辑性区域）、以及建议动作（保留观察、联系删除、提交拒绝）。只给一份“风险链接列表”而不给判定依据，无法验收。

外链模块的常见缺项是：只给汇总数字不给清单、只给分数不给维度、只给风险名单不给判定理由。这三类缺项都可以在验收阶段直接判为不通过。

修复优先级如何排序

验收标准的作用是让“合格”变成可判定的动作。写法上，每个模块对应一组条目，每条包含通过条件、不通过条件和复核方式三部分。复核方式要写明由谁、用什么数据、在什么时间点核对。

下面这份清单覆盖五个模块，可直接用于核对报价或已交付的审计报告。表中留空的单元格由读者在核对时填写，不预填任何结论。

使用这份清单时，先逐行核对“应交付证据”是否齐全，再核对“数据来源”是否写明，最后用“复核方式”做抽样验证。任何一行在“通过条件”上无法满足，就记为不通过，并在优先级列标注该问题的影响面。

需要特别区分的是：证据齐全不等于结论正确。验收判定的是交付物是否达到约定的证据标准，而不是审计结论是否与预期一致。如果服务商的结论与你的判断不同，但证据可追溯、推理可复核，这仍属于通过验收的范围，分歧应通过追问和补充分析解决，而不是直接判为不合格。

审计边界与不包含项

审计发现通常有几十条，全部并列等于没有优先级。排序需要三个可解释的判断依据，且每个依据都要能说清取值理由。

影响面判断。 影响面指该问题波及的页面数量与页面重要性。波及首页、核心栏目页的问题，影响面高于波及单个长尾页面的问题。判断时要写明受影响的 URL 数量，以及这些 URL 在站内承担的角色。影响面判断不涉及流量预测，只描述波及范围。

修复成本判断。 成本指完成修复所需的人力、时间与协调方。模板层的一次修改可能覆盖大量页面，成本低而影响面大；单页内容重写成本高而影响面小。成本判断要写明依赖方，例如是否需要开发排期、是否需要内容团队配合。

依赖关系判断。 有些问题必须先修，否则后续修复无法生效。典型情况是：索引问题未解决前，内容层面的调整无法被观察到；重定向链未清理前，内链调整的效果无法判断。依赖关系决定了排序中的先后约束，不能仅按影响面大小排列。

把三个依据合并成排序规则时，建议采用如下顺序：先处理阻塞其他修复的依赖项，再处理影响面大且成本可控的项，最后处理影响面小或成本高的项。每条发现都应标注它属于哪一类，以及它阻塞了哪些后续项。

排序结果应形成一张表，包含发现编号、所属模块、影响面描述、成本描述、依赖项、建议顺序。这张表的价值在于可讨论：如果服务商的排序与你的判断不同，可以逐条追问依据，而不是接受一个无法解释的顺序。

需要避免的排序方式是：按模块顺序排列（技术在前、外链在后），或按发现数量排列。这两种方式都不反映修复的实际约束，会让执行阶段反复返工。

采购前需准备的权限与数据

审计与优化是两件事。审计的产出是发现、证据与建议；优化是执行修改。报价中如果出现“审计包含修复”，要确认修复的范围、由谁执行、是否另行计费。

审计与代运营的边界同样需要写明。代运营通常包含持续的内容生产、外链建设与日常调整，其交付节奏与审计的一次性交付不同。如果报价把审计与代运营打包，要分别列出两部分的范围与交付物，避免用审计的价格购买代运营的承诺，或反之。

审计不包含效果承诺。审计报告可以指出问题、给出修复建议与优先级，但不能承诺修复后的排名、流量或转化结果。任何把审计结论与效果挂钩的表述，都属于超出审计范围的承诺，采购时应要求从范围说明中删除或明确标注为不包含项。

请直接使用本文内嵌的检查表。

边界写入合同时，建议采用“包含 / 不包含”两栏对照的写法，而不是只在包含栏罗列。只写包含项的范围说明，在争议时无法界定责任。

审计启动前的前置条件不齐，会直接导致审计中断或结论不完整。需要准备的项分为三类。

平台访问权限。 需要确认可提供的权限包括：Search Console 的相应权限级别、站点分析工具的访问权限、以及站点后台的只读访问权限。权限级别要提前确认，只读权限通常足以完成审计，涉及修改的权限不在审计范围内。如果服务商要求写入权限，应追问具体用途。

数据导出范围。 需要明确导出哪些数据、覆盖多长时间窗口。常见需要的是：页面索引状态报告、抓取统计、站点地图、站内页面清单、以及外链数据。时间窗口要与审计目标匹配，例如判断索引问题需要覆盖足够长的观察期，窗口过短会得出片面结论。导出范围应在启动前书面确认，避免审计中途反复补数据。

对接人与时间窗口。 需要指定一名对接人负责权限开通、数据导出与问题澄清，并约定审计的起止时间与中期沟通节点。对接人缺位是审计延期最常见的原因。时间窗口还要考虑站点自身的变更节奏，如果审计期间正在进行改版或迁移，结论的适用范围会受影响，应提前说明。

把这三类准备项整理成一张启动前核对表，逐项确认后再开始计时。核对表应包含：权限项、当前状态、负责人、确认时间。任何一项未确认，都不建议进入正式审计阶段。

完成以上准备后，读者可以用前文的验收清单核对已收到的报价或审计报告，标出缺失的证据项，再与服务商确认范围与补充交付。

核验来源：Google: Creating helpful, reliable, people-first content。