technical-seo-audit

技术 SEO 审核

执行模块化技术 SEO 审核，将已确认的问题与产品检查、外部测量和分析师判断区分开来。缺少 meta description 与关键页面意外设置 noindex 并不等同。

规则来源

• Semrush 支持的指导原则： 可抓取性、可索引性、网站架构、HTTPS、重定向、移动端内容一致性、性能、规范化、元数据、结构化数据和渲染内容都是技术 SEO 的核心关注点。
• MCP 合约要求： 基于项目的发现来自官方 Semrush MCP 暴露的报告和字段。经过测试的合约以问题为基础；不提供具名的产品界面主题报告。
• 当前平台标准： 站点地图限制、Core Web Vitals 阈值、移动优先要求、爬虫控制和结构化数据资格，均以相关平台的主要文档为准。
• 行业经验法则： 业务优先级、预期影响和修复顺序属于判断，除非有第一方数据支持。
• 用户可配置的默认值： URL 样本、分页限制和模块深度取决于范围和可用证据。不要使用固定的网站规模或流量阈值。

输入信息

一次性询问：

• 根域名、确切 URL 或 URL 集合；
• 全站、模板级或页面级范围；
• 重要页面类型，以及已知的网站迁移、渲染或索引事件；
• 是否可以访问现有的 Semrush Site Audit 项目；
• 用户提供的 Search Console、Analytics、CMS、爬虫、性能或服务器日志证据。

不要索要 Semrush API 密钥。官方 MCP 使用 Semrush 身份验证。

官方 Semrush MCP 工作流

1. 调用 projects，发现 list_projects，获取其架构，然后执行。
2. 匹配用户要求的域名，并确认 siteaudit 已启用。
3. 调用 site_audit，然后发现并执行该项目的 snapshots。
4. 选择最新的已完成快照，并保留其 ID 和完成日期。
5. 执行 info，获取抓取状态、已抓取页面数、限制、问题总数、缺陷、重定向、受阻／失效计数、标记总数和深度分布。
6. 执行 meta_issues，获取当前的问题目录。定义不代表当前出现的问题。
7. 将 info.defects 与 meta_issues 关联。仅对当前计数相关的问题执行 issue_details，并使用项目 ID、快照 ID、问题 ID 和受控的限制。
8. 调查确切 URL 时，使用 page_list 获取已抓取页面的 ID，然后使用 page_info 检索该页面的问题行。

项目访问为只读。切勿承诺创建项目、更改抓取设置、连接集成或启动抓取。问题 ID 可能会变化；应重新发现 ID，而不是将其硬编码为永久列表。

证据与访问防护

• 告知用户，Semrush 查询可能会消耗 API 单位。先使用小批量诊断；用户要求全面覆盖时再分页。
• 说明抓取的配置覆盖范围。“完整审核”指在当前设置和限制内完成的抓取，并不能证明所有在线或已索引 URL 都已覆盖。
• 空的问题响应可以作为有效证据，表明该问题在该快照中没有返回的实例。
• 不要将 Semrush 的 Error／Warning／Notice 标签解读为 Google 处罚或排名保证。
• 将 Semrush 抓取数据、Search Console 证据、性能测量、直接 HTTP／浏览器观察结果和模型推断分别处理。
• Search Console Performance 没有“Last modified”维度。发布日期和修改日期必须来自 CMS、站点地图、页面元数据或其他用户提供的来源。
• site: 查询只是粗略观察，并非权威的索引数量。

降级方案

1. 现有 Semrush 项目及已完成的 Site Audit 快照。
2. 用户提供的 Semrush Site Audit 导出文件。
3. 提供的爬虫导出文件，以及 Search Console、性能、CMS 或日志数据。
4. 直接通过 HTTP 和渲染后的浏览器检查一组代表性 URL。
5. 用户提供的 URL 和证据。

如果提供的数据集无法证明覆盖完整，请将第 3–5 级标记为抽样结果。

审计模块

先检查可抓取性和可索引性。再运行用户范围内要求的其他模块，然后汇总调查结果。

1. 可抓取性和可索引性

检查：

• 重要 URL 的 HTTP 状态和重定向行为；
• robots.txt 语法，以及会影响重要页面或资源的规则；
• XML 站点地图是否可用、能否解析、规范 URL 格式，以及列出的 URL 是否应被编入索引；
• robots meta 和 X-Robots-Tag 指令；
• 规范目标及冲突；
• 用户提供的 Search Console 索引证据；
• Site Audit 返回的受阻、未抓取、4xx、5xx、站点地图、规范 URL 和重复内容问题。

robots.txt 屏蔽会阻止抓取，但不能保证页面从索引中移除。缺少 robots.txt 文件并不自动构成 SEO 问题。在 robots.txt 中引用站点地图很有用，但并非站点地图正常工作所必需。

Google 的 XML 站点地图限制是每个文件最多 50,000 个 URL，或未压缩时最多 50 MB。应将这些视为平台限制，而非 Semrush 启发式规则。

2. HTTP、HTTPS 和重定向

检查：

• 证书是否有效，以及主机名是否匹配；
• 首选 HTTPS／主机版本是否一致；
• 内部混合内容链接和资源；
• 4xx／5xx 出现情况，以及暴露这些问题的来源 URL；
• 重定向链、循环，以及可避免的内部重定向跳转；
• 永久重定向还是临时重定向的意图。

对于确属永久性的迁移，使用 301／308；对于临时迁移，使用 302／307。不要声称临时重定向本身无法传递链接权重。对于有意移除的内容，404 可能是正确的；当导航、业务重要性、反向链接或替代内容意图表明需要修复时，才应采取行动。

3. Core Web Vitals 和性能

如有可用数据，应使用当前 Chrome UX Report／PageSpeed 字段数据，并将其与 Lighthouse 实验室数据区分开。根据第 75 百分位应用 Google 当前的“良好”“需改进”和“较差”阈值：

指标	良好	需改进	较差
LCP	≤ 2.5 s	> 2.5 s to 4.0 s	> 4.0 s
INP	≤ 200 ms	> 200 ms to 500 ms	> 500 ms
CLS	≤ 0.1	> 0.1 to 0.25	> 0.25

不要仅凭指标猜测原因。在建议修复图片、JavaScript、字体、缓存或布局问题之前，应先查看诊断信息或实现证据。如果没有字段数据，请将实验室结果标记为合成数据，并注明其针对具体页面。

4. 移动端一致性和渲染

由于 Google 采用移动优先索引，请比较移动端和桌面端的：

• 主要内容；
• 标题和 meta 描述；
• robots 指令和规范标签；
• 内部链接；
• 图片和替代文本；
• 结构化数据；
• 可渲染资源和依赖交互的内容。

如果 JavaScript 提供关键内容或链接，请比较原始 HTML 与渲染后的 DOM。不要仅凭桌面截图推断两端一致。应将视口、资源屏蔽、JavaScript／CSS 和移动端可用性问题视为需要调查的证据，而非自动认定为排名惩罚。

5. 标题、描述、标题层级和规范链接

使用当前 Site Audit 问题条目以及页面级检查。

• 标题标签： Semrush 建议使用简洁、描述准确且符合搜索意图的标题，长度约为 550 像素或更短——通常为 50–60 个字符；同时指出，搜索系统和 AI 系统都没有强制规定最大长度。应将此视为显示方面的指导，而非排名保证或自动判定失败的标准。
• 元描述： Semrush 当前的编辑建议是尽量将长度控制在约 135 个字符以内，以降低被截断的风险。元描述不是直接排名因素，可能会被改写；评估时应关注准确性和实用性，而不能只看长度。
• H1/标题层级： 建议使用一个清晰的主标题，并采用逻辑清晰的 H1/H2/H3 层级。将只使用一个 H1 视为编辑惯例，而非普遍适用的排名要求。标题标签与 H1 应在页面目的上保持一致，但不必完全相同。
• 规范链接： 检查语法、目标状态、可索引性、主机名/协议一致性、重复内容处理意图，以及是否与重定向、站点地图、hreflang 或内部链接冲突。规范链接只是信号，并非指令。
• 图片： 信息性图片应提供有用的替代文本，装饰性图片应使用空替代文本。不要将所有空替代文本都标记为错误。

重复或长度相关的元数据问题值得检查，但它们本身并不能证明存在关键词蚕食、受到处罚或流量流失。

6. 结构化数据

使用 Site Audit 标记计数和当前结构化数据问题出现情况作为筛查证据。仅检查静态 HTML 可能会遗漏由 JavaScript 注入的标记。

将实体选择、渲染后标记检查、JSON-LD 起草和验证交由 schema-markup 技能处理。本次审计仅保留已确认问题的摘要及优先级。有效标记不保证获得富媒体搜索结果；无效或不匹配的标记也不会自动导致排名处罚。

7. 架构和内部链接

使用抓取深度分布以及当前有关孤立页面、失效内部链接、重定向、缺失/描述性不足的锚文本、nofollow 内部链接和内部链接不足页面的问题。

将详细的修复计划交由 internal-link-audit 处理。Semrush Site Audit 可能会标记点击三次以上才能到达的网址，但该产品检查并非普遍适用的排名定律。应根据页面重要性、用户旅程、抓取证据和提供的第一方效果数据确定架构调整的优先级，而不要使用固定的关键词搜索量或流量阈值。

8. AI 爬虫访问权限

阅读当前的 robots.txt 规则和主要爬虫文档。

• OAI-SearchBot 控制是否自动抓取内容以纳入 ChatGPT 搜索结果。
• GPTBot 控制内容是否可用于训练 OpenAI 的生成式 AI 基础模型。
• ChatGPT-User 由用户主动触发，并非控制内容是否纳入搜索结果的选项。
• Google-Extended 控制指定的 Gemini 训练和依据内容生成用途；它不会影响内容是否纳入 Google 搜索结果，也不会影响排名。

根据发布方的目标评估每个用户代理。不要将屏蔽训练爬虫标记为技术 SEO 缺陷。对于其他 AI 爬虫，在作出判断前应查阅最新的第一方文档。

优先级排序

按以下基于证据的顺序确定优先级：

1. 已确认会影响重要网址的访问、可索引性、安全性、重定向循环或服务器故障；
2. 已确认会造成明显用户影响或搜索影响的模板级问题；
3. 实地性能问题以及移动端/渲染一致性问题；
4. 元数据、结构化数据和内部链接改进；
5. 需要验证的抽样或推断结果。

如果没有用户提供的第一方基线数据和明确模型，不要估算流量、收入、恢复时间或排名影响。

输出

从覆盖范围开始：

证据类别	来源	范围	快照/日期	局限性

然后提供一张整改表：

优先级	模块	受影响的 URL 或模式	获取的证据	解读	操作	置信度

每一行都必须：

• 报告确切的返回值、问题 ID 或观察到的行为；
• 区分已确认缺陷、Semrush 产品检查、平台标准故障和分析师判断；
• 在可推断时注明修复负责人——工程、SEO、内容、设计或基础设施；
• 除非数据来源和测试范围确实支持，否则不要标注为“通过”。

结尾列出：

1. 立即修复： 高置信度的阻塞问题和异常行为。
2. 接下来修复： 已验证的模板或体验改进。
3. 委派： Schema Markup 或 Internal Link Audit 后续工作。
4. 验证： 抽样、推断或缺失的一方证据。
5. 不可用： 未测试的模块或字段。

来源

Semrush 方法论：

• 技术 SEO
• 技术 SEO 审核
• 技术 SEO 检查清单
• Core Web Vitals
• 标题标签
• 元描述
• 规范 URL
• Robots.txt

主要平台参考资料：

• Google Search Central
• Web Vitals
• OpenAI 爬虫
• Google 爬虫控制