网站 SEO 审计清单:按阻断、增长和改善顺序检查

按风险整理抓取、索引、内容、内链、性能、结构化数据和转化测量问题。

LumoHero 网站 SEO 审计清单封面
00

CONCLUSION FIRST
结论先行

结论放在前面。

一份真正有用的 SEO 审计,不以发现问题数量最多为目标,也不以第三方工具的总分作为结论。它应该告诉团队:哪些问题会阻断搜索,哪些问题限制增长,哪些只是改善;谁负责、怎样修、如何回滚、用什么证据验收。完成自查后,可以在联系页留下 P0/P1 问题、主要 URL、Search Console 状态和可用联系方式。我们会先确认问题范围与实施责任;清单不能替代针对真实网站的诊断,也不代表已经承诺修改。

USE / BOUNDARY

看看这篇文章是不是当前需要的。

适合这些情况
  • 接手旧站、建立 SEO/GEO 基线或排查搜索异常
  • 需要把发现按 P0、P1、P2 转成责任与验收队列
  • 希望同时检查技术、内容、内链、结构化数据和测量
01

审计不是工具分数清单

审计的价值,是把问题排成能执行、能验收的顺序。

工具可以发现很多问题,但标题过长和全站 noindex 不能放在同一优先级。团队需要知道影响、责任人、修复顺序和验收方式。

一次可执行的网站 SEO 审计,应该按依赖关系进行:先确认页面能访问和被正确处理,再检查页面职责、内容与内部链接,之后处理体验、结构化数据和测量。每个问题都要包含证据、风险、责任人、验收条件和下一次复查。

这份清单适合网站当前状态诊断、接手旧站和建立 SEO/GEO 基线。如果正在更换域名、URL 或整站改版,还需要单独使用迁移清单,因为迁移涉及旧新 URL 映射、重定向和上线窗口。

02

保存基线、范围与访问权限

不要在没有基线时直接改网站。

先保存:

初次外部审计通常先提供必要的只读访问。需要实施时,再按具体任务授予最小权限,并记录变更与回滚方式。

CHECKLIST / 检查清单
  • 主要域名、语言、国家和网站环境。
  • 当前页面清单、Sitemap、robots.txt 和主要模板。
  • Search Console 的页面索引、Sitemap、效果和人工处置状态。
  • Analytics 的自然访问、主要落地页和真实关键行动。
  • 已知的业务重点页面、不能删除的 URL 和近期改动。
  • 代码、CMS、托管、域名和分析账号分别由谁控制。
  • 审计日期、抓取工具版本、设备和用户代理。
03

P0:检查抓取、状态码与索引阻断

P0 是会让重要页面无法访问、无法处理或大范围错误归属的问题,应优先确认。

完成下方技术检查时,还需区分“可抓取、可索引、已索引、可排名”四种状态。

Google 官方说明,即使页面符合技术要求,也不能保证一定被抓取、索引或展示。因此验收时先证明配置正确,再记录外部处理状态。

01

HTTP 状态

常见异常与风险:重要页 4xx/5xx、软 404、循环重定向;建议责任人:开发/运维;验收条件:关键 URL 返回预期状态,重定向单跳到最终页

02

robots.txt

常见异常与风险:错误阻止页面或关键资源;把 robots 当成 noindex;建议责任人:SEO + 开发;验收条件:抓取规则与公开/私有边界一致,并用测试工具验证

03

noindex / X-Robots-Tag

常见异常与风险:模板把重要页面设为 noindex;建议责任人:开发;验收条件:需要收录的页面没有阻断指令;私有页继续受保护

04

Sitemap

常见异常与风险:包含重定向、404、noindex、重复或非 canonical URL;建议责任人:开发/SEO;验收条件:只列希望被搜索的规范 URL,返回成功且可解析

05

canonical

常见异常与风险:重要页面指向首页、错误语言或其他内容;建议责任人:SEO + 开发;验收条件:每个页面的 canonical 与内容主版本一致

06

渲染与资源

常见异常与风险:主要内容依赖失败脚本,抓取时为空;建议责任人:前端;验收条件:渲染后可见主要文字、链接和 metadata

07

安全与人工处置

常见异常与风险:被入侵、恶意内容或收到人工处置;建议责任人:安全/负责人;验收条件:问题已处理并通过相应复核流程

CHECKLIST / 检查清单
  • 可抓取:爬虫能请求页面。
  • 可索引:页面没有阻止索引,但仍不代表一定进入索引。
  • 已索引:搜索系统已经将其作为可用页面处理。
  • 可排名:页面还需要与查询和其他结果竞争。
04

P0/P1:检查规范版本、重复页与语言关系

Canonical 是规范版本信号,不是删除工具;Sitemap 也只是辅助信号。

需要移除页面、合并内容或阻止索引时,要根据目标分别选择状态码、重定向、noindex 或访问控制。

01

URL 版本

需要回答的问题:HTTP/HTTPS、www/非 www、尾斜杠和参数是否产生重复版本;验收条件:所有非主版本稳定跳转或正确规范化

02

Canonical

需要回答的问题:自引用是否合理;分页、筛选和重复页是否指向正确主版本;验收条件:canonical 可访问、可索引且内容等价

03

重定向

需要回答的问题:是否存在链、环、临时重定向误用或全部指向首页;验收条件:旧 URL 直接到最相关新 URL

04

参数与筛选

需要回答的问题:是否生成大量近重复、空结果或无价值组合;验收条件:重要组合有独立价值;任意组合不制造索引膨胀

05

语言版本

需要回答的问题:每种语言是否有独立可读内容和稳定 URL;验收条件:页面语言、URL、canonical 与 hreflang 关系一致

05

P1:检查标题、H1、内容职责与搜索意图

页面可以技术正常,但仍然没有清楚回答任何问题。

逐页检查:

验收不应只是“关键词出现了几次”。更合理的标准是:页面主题明确、与目标意图匹配、事实可核验、没有与站内其他页面严重重复,并能引导自然下一步。

CHECKLIST / 检查清单
  • Title 是否准确说明页面主题,并在站内保持区别。
  • H1 是否与页面主体一致,而不是只写品牌口号。
  • 首屏是否让目标读者知道适用对象、问题和下一步。
  • 一个页面是否承担一个主要搜索意图。
  • 同主题的服务页、文章和案例是否各自提供不同价值。
  • 内容是否包含可核对的事实、作者、来源和更新责任。
  • 过期页面是否应该更新、合并、重定向或保留历史说明。
  • 图片 alt 是否描述图片作用,而不是堆关键词。
06

P1:检查站点架构、内部链接与孤立页面

确认重要页面能从清楚、相关的入口被发现。

从首页、导航、服务总览、主题页和 Sitemap 分别出发,确认重要页面是否能被发现。

内部链接不是为了机械传递“权重”而添加。它首先应该帮助用户继续理解,并让搜索系统识别页面之间的主题和层级。

01

导航职责

异常示例:所有内容都挤进一级导航;重要服务没有入口;验收条件:导航反映用户选择,而不是内部部门

02

点击路径

异常示例:重要页面只能通过站内搜索访问;验收条件:关键页面从相关上级或主题页可到达

03

上下文内链

异常示例:锚文本泛化为“点击这里”,或跨语言乱链;验收条件:锚文本说明目标,链接与当前问题相关

04

孤立页面

异常示例:Sitemap 有 URL,但站内没有任何链接;验收条件:每个可索引重要页至少有合理站内入口

05

断链

异常示例:内容长期指向 404 或错误语言;验收条件:内部链接到最终有效 URL

06

页面深度

异常示例:大量高价值页被埋在筛选或多层目录;验收条件:结构与业务优先级和主题关系一致

07

P1/P2:检查性能、移动端、渲染与可访问性

检查真实用户最重要的路径,而不是只测首页一次:

性能分数是诊断信号,不是单独的排名保证。验收应同时记录实验室测试、真实用户数据(如有)和关键任务是否可完成。

CHECKLIST / 检查清单
  • 手机和电脑上的导航、表单、筛选、购买或联系是否可用。
  • 主要内容是否需要长时间等待脚本后才出现。
  • 图片、字体和第三方脚本是否拖慢首屏。
  • 布局是否在加载时明显移动。
  • 点击和输入是否有迟滞或被弹窗遮挡。
  • 键盘能否操作关键功能,焦点是否可见。
  • 标题层级、表单标签、错误提示和颜色对比是否清楚。
  • Cookie 与同意界面是否阻挡内容或产生重复标签。
08

P1:检查结构化数据是否与可见事实一致

结构化数据帮助搜索系统理解页面,但不能用来添加页面上不存在的内容。

即使结构化数据通过测试,Google 也不保证展示富媒体结果。正确验收是“数据有效且真实反映页面”,不是“保证出现某种搜索样式”。

CHECKLIST / 检查清单
  • Organization、WebSite、WebPage、Article、Breadcrumb 等实体 @id 是否一致。
  • 名称、作者、发布日期、图片、价格、库存或评论是否与页面可见内容一致。
  • 页面类型是否选择正确,而不是所有页面都套同一种 Schema。
  • JSON-LD 是否语法有效,引用 URL 是否可访问。
  • 重复页面和语言页面上的结构化数据是否对应各自内容。
  • 不使用虚构评分、评论、客户、服务范围或 FAQ。
09

P1:检查 Search Console、Analytics 与业务测量

先回答搜索前、进入网站后、业务结果三层问题,再核对测量配置。

Google 官方将 Search Console 视为搜索表现的事实来源,将 Analytics 视为站内行为的事实来源。点击与会话不会完全一致,重点是理解口径并观察趋势。

CHECKLIST / 检查清单
  • 搜索前:哪些查询、页面、国家和设备产生展示与点击?
  • 进入网站后:访客阅读了什么、完成了哪些真实关键行动?
  • 业务结果:这些行动中哪些成为有效联系、报价或成交?
  • Search Console 属性、Sitemap 和主要页面是否正确覆盖。
  • Analytics 是否在得到适用同意后工作,且没有重复标签。
  • pageview、联系点击和真实成功提交是否使用清楚事件名。
  • 事件参数是否避免姓名、邮箱、电话、正文等个人资料。
  • 关键事件是否只在真正成功后触发,而不是点击按钮就算线索。
  • Search Console 与 Analytics 使用不同口径时是否有解释。
  • 业务数据是否保留匿名聚合和质量分类,而不是只数表单数量。
10

把发现转成 P0、P1、P2 队列

每个发现至少记录以下字段:

01

P0:阻断项

影响访问、抓取、索引、规范版本、安全或关键业务功能。应先修并立即做技术复验。

02

P1:增长项

页面职责、内容缺口、内部链接、国际化、结构化数据和测量问题。基础正常后按业务价值排序实施。

03

P2:改善项

不会阻断主要路径,但能改善可读性、维护效率、次要体验或长期扩展。不要让 P2 占用 P0 的资源。

CHECKLIST / 检查清单
  • 问题名称和影响页面。
  • 证据与观察时间。
  • 风险:阻断、增长限制还是体验改善。
  • 建议动作和不建议动作。
  • 责任人、审批人和依赖。
  • 实施前快照与回滚方式。
  • 验收标准和复验方法。
  • 实施状态、验证状态和效果观察状态。
11

一页可复制的验收清单

用这份清单确认基线、技术处理、内容职责、体验、测量与验收是否完整。

每一项都应有负责人、证据和复验状态。

CHECKLIST / 检查清单
  • [ ] 已保存审计范围、日期、账号和主要页面基线
  • [ ] 关键页面状态码、robots、noindex 与 canonical 正确
  • [ ] Sitemap 只包含希望被搜索的规范 URL
  • [ ] 重定向无环、无长链,并指向最相关页面
  • [ ] 多语言 URL、页面语言、canonical 与 hreflang 一致
  • [ ] Title、H1、主体内容和搜索意图一致
  • [ ] 服务页、文章和案例没有互相复制职责
  • [ ] 重要页面有相关入口,没有孤立页和内部断链
  • [ ] 手机关键路径、渲染、性能和可访问性通过检查
  • [ ] 结构化数据有效且只描述可见真实事实
  • [ ] Search Console、Analytics 与业务结果口径已分开
  • [ ] 每个问题都有优先级、责任人、验收和下一步
  • [ ] 实施完成、技术复验和效果验证使用不同状态
KEY TAKEAWAYS / 关键结论

如果只记住几件事,就记住这 4 点。

  1. 01

    先修影响访问、抓取、索引和关键功能的阻断项。

  2. 02

    每个发现都要有证据、风险、责任人、验收和复查。

  3. 03

    页面职责、内容、内链与测量应在技术资格后分层检查。

  4. 04

    审计产物是可执行队列,不是一个无法解释的总分。

准备把这套方法用到实际项目?

发来网址或当前资料,我们会按同一框架指出最需要处理的一步。

提交审计问题
FAQ / 常见问题

常见问题,一次说清。

01 SEO 审计多久做一次?

没有固定频率。改版、迁移、模板更换、流量异常或新增市场时应触发审计;平时可以持续监测关键技术和数据状态,再按周期做较完整复盘。

02 robots.txt 允许抓取是否代表一定会被索引?

不代表。robots.txt 主要管理抓取;页面还要经过访问、渲染、索引与规范版本判断。需要阻止 HTML 页面进入索引时,应使用 noindex 或访问控制,而不是只依赖 robots.txt。

03 canonical、重定向和 noindex 怎样区分?

Canonical 表示相似页面中的首选版本;重定向把用户和爬虫送到另一个 URL;noindex 表示不希望当前页面进入索引。三者解决的问题不同。

04 技术、内容和测量应该先修哪一个?

先修访问、抓取、索引和关键功能阻断,再处理页面职责与内容,测量基础也应尽早建立。没有测量时,后续很难判断改动效果。

05 什么情况需要开发人员参与?

模板 metadata、状态码、重定向、渲染、性能、结构化数据、分析事件、国际化和大规模 URL 规则通常需要开发人员。单纯改文案无法解决这些问题。

METHOD NOTE / 写作与使用说明

这套方法可以帮助准备项目;真正执行时,还需结合实际网站和目标确认范围。

我们基于公开来源和已确认的服务边界整理;AI 用于结构化与自检,业务事实、服务范围和发布责任由人工确认。

SOURCES / 资料来源

想核对依据,可以查看这些公开资料。

外部页面会更新,真正使用前记得确认最新版本。

  1. 01
    Google 抓取与索引文档

    Google Search Central

    查看 Google Search Central《Google 抓取与索引文档》(新窗口打开)
  2. 02
    Google 搜索工作原理

    Google Search Central

    查看 Google Search Central《Google 搜索工作原理》(新窗口打开)
  3. 03
    Google robots.txt 说明

    Google Search Central

    查看 Google Search Central《Google robots.txt 说明》(新窗口打开)
  4. 04
    Google canonical 说明

    Google Search Central

    查看 Google Search Central《Google canonical 说明》(新窗口打开)
  5. 05
    Google 结构化数据通用规范

    Google Search Central

    查看 Google Search Central《Google 结构化数据通用规范》(新窗口打开)
  6. 06
    Google 关于 Search Console 与 Analytics 数据分工

    Google Search Central

    查看 Google Search Central《Google 关于 Search Console 与 Analytics 数据分工》(新窗口打开)
  7. 07
    LumoHero 网站改版 SEO 迁移清单

    LumoHero

    查看 LumoHero《LumoHero 网站改版 SEO 迁移清单》(新窗口打开)
NEXT / 下一步

把最重要的 URL 和问题发来,我们整理可执行队列。

在联系页说明最重要的 URL、已知问题和 Search Console 状态,并填写可回复邮箱;我们会确认审计范围与实施责任。

提交审计问题