技术 SEO 完整审计手册：从 Sitemap 到 Core
一份能让开发外包"无处可推"的可勾选清单
内容做得再好，技术地基烂了 SEO 也跑不动。本手册按"抓取、索引、性能、Schema、安全、移动、国际化"7 个层面给出 35 项可勾选检查
核心要点
- 1.技术 SEO 不是"做完一次"的工作，是"每月体检"的工作
- 2.90% 的本地企业网站在 7 层中至少有 3 层存在系统性问题
- 3.修复优先级 = 影响范围 × 修复难度的反比——先做"影响大、好修"的
- 4.不要被工具的报告分数迷惑——分数低的页面未必排名差，分数高的也未必排名好
- 5.把审计 checklist 制度化，比依赖任何工具都重要
引言：为什么技术 SEO 是"看不见的地基"
我们做过的 SEO 审计里，约 75% 的本地企业网站在技术层面存在系统性问题——Sitemap 不完整、Canonical 配错、移动端慢、Schema 缺失。这些问题用户看不到、销售也不会提，但 Google 的爬虫天天在面对它们。
技术 SEO 是 SEO 工作的地基。地基有裂，无论你的内容多优秀、外链多权威，整体表现都会被压在某个上限之下。这份手册的目标是给一份"按层级组织、按优先级排序、可勾选执行"的完整审计清单。
使用建议
这份手册分 7 个层级、共 35 项。建议每季度做一次完整审计，每月做一次"红线项"巡检（每层第 1 项）。把审计结果存档，看趋势比看单次结果更重要。
第一层：抓取（Crawlability）— 让 Google 能找到所有重要页面
1.1 XML Sitemap 完整且自动更新
验证方法：打开 yoursite.com/sitemap.xml，对比站点实际页面数。差异 > 10% 就有问题。
常见坑：CMS 的 Sitemap 默认配置可能漏掉某些 post type、taxonomy 或新建页面。
1.2 robots.txt 没屏蔽关键内容
验证方法：yoursite.com/robots.txt，检查 Disallow 规则。CSS / JS / image 路径绝对不能被屏蔽。
1.3 Google Search Console 的"Pages"报告里"Indexed"率 > 80%
如果"Discovered but not indexed"或"Crawled but not indexed"占比过高，说明 Google 觉得这些页面价值低。
1.4 抓取预算分配合理
大站点（5000+ 页）必须管理抓取预算。Search Console "Crawl stats" 里如果 Googlebot 抓取的多数是"低价值页"（参数 URL、过滤页），就要用 robots.txt / canonical / noindex 引导。
1.5 没有死链 / 4xx / 5xx 大规模错误
用 Screaming Frog 全站抓取，导出所有 4xx / 5xx 状态码 URL。任何 5xx 必须立刻修，4xx 选择性 301 重定向或保留。
第二层：索引（Indexation）— 让 Google 把对的页面收进索引
2.1 Canonical 标签每页都有且指向正确版本
验证：用 GSC URL Inspection 抽检 5–10 个页面，对比"User-declared canonical"与"Google-selected canonical"是否一致。不一致 = canonical 没被采纳，需要修。
2.2 noindex 不应该出现在主要内容页
常见错误：开发上线时忘了移除测试期间加的 noindex 标签。任何"应该被索引"的页面如果带了 noindex，立刻是 SEO 灾难。
2.3 重复内容被合理处理
过滤参数页、翻页、打印版、移动版（若是分离架构）—— 这些重复内容必须通过 canonical 或 noindex 或参数处理工具明确告知 Google。
2.4 hreflang（多语言站点）配置正确
验证：用 Screaming Frog 的 hreflang 报告，确认每个语言版本都互相 reference。错配的 hreflang 不会立刻让站点崩溃，但会让 Google 在不同地区错误选择展示版本。
2.5 已下架内容用 410 而不是 404
永久下架的页面（如已下架产品）用 410 Gone 比 404 Not Found 更精准——告诉 Google "永远不要再来抓这个 URL"。404 Google 还会继续抓几个月。
第三层：性能（Performance）— Core Web Vitals 全绿
3.1 LCP（Largest Contentful Paint）≤ 2.5s
验证：PageSpeed Insights 移动端测试。LCP 慢的常见原因：未压缩 hero 图、阻塞渲染的 CSS / JS、第三方脚本（live chat、analytics）加载顺序错。
3.2 CLS（Cumulative Layout Shift）< 0.1
验证：同上。CLS 高的常见原因：图片 / 视频未设 width/height、字体加载导致字号跳变、Ads 容器没预留位置。
3.3 INP（Interaction to Next Paint）< 200ms
INP 是 2024 年取代 FID 的指标。慢的常见原因：第三方脚本阻塞主线程、未优化的 React / Vue 组件 reflow。
3.4 图片用 WebP / AVIF 且懒加载
验证：Chrome DevTools Network 面板，过滤 Img。所有非首屏图片必须 lazy load（loading="lazy"），所有图片必须有 width / height 防止 CLS。
3.5 CDN 启用且配置合理
本地企业网站推荐 Cloudflare 免费版起步。CDN 必须开启 Brotli 压缩 + 静态资源缓存（CSS / JS / 图片至少缓存 1 年）。
第四层：结构化数据（Schema）
4.1 部署所有必需的 Schema 类型
本地企业必备：Organization / LocalBusiness / Service / BreadcrumbList。电商加：Product / Review / FAQPage。医疗加：MedicalClinic / Physician。
4.2 用 Rich Results Test 验证无错误
验证：search.google.com/test/rich-results 跑首页 + 关键服务页 + 至少 1 个产品页 / 文章页。Errors 必须修，Warnings 可选。
4.3 多个 Schema 来源不冲突
插件 + 手工 + 代码三种来源不能同时存在。Rich Results Test 报"重复属性"错误意味着冲突。
4.4 Schema 内容与页面可见内容一致
FAQ Schema 里的问题答案必须在页面上可见，否则违反 Google 政策。隐藏在 Schema 但不显示在页面 = 可能受手动惩罚。
4.5 GSC "Enhancements" 报告里所有部署的 Schema 都被识别
部署后 2–4 周打开 GSC → Enhancements，确认你部署的每种 Schema 都出现在那里。没出现 = Google 没识别，要查实施问题。
第五层：安全（Security）
5.1 全站 HTTPS，无 mixed content
验证：Chrome DevTools Console 面板，看是否有"Mixed Content"警告。任何 HTTP 资源加载到 HTTPS 页面都会触发。
5.2 HSTS 头部已设置
Strict-Transport-Security 头部强制浏览器只通过 HTTPS 访问。验证：securityheaders.com 跑首页，A 或 A+ 评级即可。
5.3 SSL 证书未过期且配置正确
验证：ssllabs.com/ssltest 跑首页，目标 A+ 评级。证书过期前 30 天就要安排更新。
第六层：移动端（Mobile）
6.1 通过 Google Mobile-Friendly Test
所有页面必须通过移动端友好测试。任何"Text too small"、"Clickable elements too close"都要修。
6.2 移动端没有"interstitial"侵入式弹窗
Google 2017 起对移动端首屏阻挡内容的弹窗有专门的排名惩罚。"订阅邮件列表"或"接受 cookie"的全屏弹窗都要避免。
6.3 移动端核心 CTA 在首屏
本地企业的拨号按钮 / 主表单必须在 100vh 内可见。用 Chrome DevTools 切到 iPhone 视口验证。
6.4 viewport meta 配置正确
是必备。少了或写错会让整个移动端排版崩溃。
第七层：国际化与本地化（International）
如果你只服务一个市场 / 一种语言，这一层可以跳过。多市场企业必查。
7.1 hreflang 双向 reference
每个语言版本都必须 reference 其它所有版本（含自己）。单向 reference 会让 Google 怀疑配置错误。
7.2 x-default 指向语言无法识别时的 fallback 版本
通常是英文版作为 x-default。这是 Google 在用户语言不在你支持范围时的兜底展示。
7.3 URL 结构清晰反映语言 / 地区
/en/、/zh/、/de/ 这种子目录结构比 ?lang=en 参数好。子域名（en.example.com）次之。
附加：每月红线项巡检（5 分钟）
完整 35 项每季度做一次。但下面 7 条是"每月必查"——任何一项出错都是急性问题：
- Sitemap 是否还能访问 + 包含所有重要页
- robots.txt 是否仍然允许重要内容抓取
- 首页 + 3 个关键服务页是否在 GSC 显示 "Indexed"
- 核心页 PageSpeed Insights 移动端分数是否 > 70
- 是否有 5xx 错误或大规模 4xx 错误
- SSL 证书是否在 30 天内过期
- GSC "Manual Actions" 是否有警告
修复优先级矩阵
按"影响范围 × 修复难度"分级
| 优先级 | 示例问题 | 建议响应时间 |
|---|---|---|
| P0 紧急 | 整站 noindex / 大规模 5xx / 证书过期 | < 4 小时 |
| P1 严重 | Sitemap 漏掉关键内容 / Canonical 大量错配 / LCP > 4s | < 1 周 |
| P2 重要 | Schema 缺失 / 移动端 CTA 不显眼 | < 1 月 |
| P3 优化 | CLS 微调 / hreflang 细节 / 图片格式优化 | < 1 季度 |
结论与下一步
本文的核心要点：每一条不是孤立技巧，而是要嵌入到「内容更新节奏 + 数据回看 + 内外部信号一致性」的系统里持续运行。延伸阅读：Google Business Profile Help。
可执行行动（建议按时间窗口推进）
执行节奏对照表
| 时间窗口 | 目标动作 | 关键产出 |
|---|---|---|
| 第 1 周 | 按本文清单完成自检 + 修复明显问题 | 一份现状与差距清单 |
| 第 2 - 4 周 | 按优先级落地高 ROI 项 + 设置追踪 | 基线数据 + 监控仪表盘 |
| 第 30 - 90 天 | 持续优化 + 月度复盘 + 案例沉淀 | 排名 / 流量 / 线索数据回看 |
SeoMata 服务交付节奏（行业基准）
立刻可执行的下一步
- 1本周完成一次完整 35 项审计，按优先级矩阵分级
- 2把月度红线 7 项加入团队日历，每月固定时间巡检
- 3修复所有 P0 / P1 级别问题，安排 P2 / P3 进入产品 roadmap
- 4建立审计结果存档机制，每季度对比看趋势