大多数”SEO 审计”Prompt 给的都是网上搜一搜就有的通用清单。下面这 12 条命中内容站真正翻车的点——重复 title、孤儿页、hreflang 错配、薄页面、关键词同食——每条都带可量化阈值和一个具体修复动作，而不是空泛建议。
一句话总结
- 把真实数据（slug、字数、标题、JSON-LD、Lighthouse 数字）粘进每条 Prompt。没数据的审计只会还你一份清单，不会还你发现。
- 每条 Prompt 都带精确阈值（
title >60 字符、LCP >2.5s、字数 <600），并要求每个发现给一个动作：扩写、合并、noindex 或 301。 - 用 1M token 的模型跑，整站一次粘进去：Claude Opus 4.7 / Sonnet 4.6 或 Gemini 3.1 Pro（截至 2026 年 6 月均为 1M token）。ChatGPT Plus 应用内大约只到 320 页上限。
- 发送前把每个
[paste]占位符换成你的数据。
这套 Prompt 适合用在哪
- 上线前 QA
- 季度内容刷新
- 双语 / 多 locale 站
- 迁移后的一致性检查
- 程序化 SEO 站 QA
该用哪个模型跑
这些 Prompt 在任何前沿模型上都能用，但成败取决于上下文长度——因为你想把整站的 slug、标题或 JSON-LD 一次粘进去。截至 2026 年 6 月：
| 模型 | 上下文 | 备注 |
|---|---|---|
| Claude Opus 4.7 / Sonnet 4.6 | 1M token | 最擅长”输出修复表”这类结构化活；1M 为标准窗口，无额外加价 |
| Gemini 3.1 Pro | 1M token | Google AI Pro（$19.99/月）即 1M；适合超长 URL 列表 |
| ChatGPT Plus（GPT-5.5） | 应用内约 320 页 | 一次审一节没问题；完整 1M 仅 $200 的 Pro 档 |
一个 1,000 篇的站，把 slug + metadata 表一次性塞进一条 Prompt，而不要分页——模型能跨整套集合抓出重复 title，这正是逐页审会漏掉的。数据真的特别大时，按板块分别审（一次一个子目录），让模型在它能看到的范围内还能连贯推理。
1. Metadata 审计
下面是 50 条文章 slug + title + meta description。请按 slug 标出：(a) title >60 字符（接近谷歌桌面端约 600px 上限会被截断）、(b) title <30 字符（多半太弱）、(c) description >160 或 <120 字符、(d) 重复或近似 title、(e) 标题没包含主关键词、(f) 标题党或全大写。输出"待修复"表，含"当前值"与"建议值"。
数据：
[paste]2. 内链审计
下面是文章列表，含 slug、H2 标题、tag。每篇请给出：(a) 推荐 3 条到列表内其他文章的出站内链，附建议锚文本、(b) 若该篇在列表内没有任何入站链接，标为孤儿、(c) 入站链接 >40 的标为中枢页、需要剪枝。输出表格。
文章：
[paste]3. Hreflang 与翻译对审计
下面是 en + zh 的 slug 列表，含各自的 translationKey。请识别：(a) 只在一种语言出现的 translationKey、(b) 配对存在但两侧 slug 差异过大（给出推荐的正确配对）、(c) 拼写错或近似的 translationKey 应当合并、(d) hreflang 指向 404 或 301。输出按严重度分组的行动清单。
数据：
[paste]4. 薄内容检测（带阈值）
下面是 slug + 字数 + H2 数 + 内链数 + 最后更新日期。按"字数 <600 且 H2 不超过 2 且内链不超过 1 且 6 个月未更新"标薄内容。每个被标记的 slug 推荐一个动作：扩写（值得救）、合并到某个指定目标 slug（指出最佳合并目标）、noindex、或 301 删除。每个判断都给理由。
数据：
[paste]5. Title 唯一性与同食检查
下面是文章 title 列表 + 各自的主目标关键词。请识别：(a) token 重合 >70% 的近似 title、(b) title 不同但锁同一主关键词（cannibalization）、(c) 标题里根本没出现主关键词的文章。每个冲突对给出：留哪个、合并或脱锚哪个、活下来那个的新标题。
Title + 关键词：
[paste]6. Canonical 与重复内容审计
下面是 URL 模式 + canonical 标签 + 现有 301。请识别：(a) 缺自指 canonical 的页面、(b) 多页 canonical 指向同一目标（合并候选）、(c) canonical 与实际渲染 URL 的尾斜杠不一致、(d) 跨语言 canonical 指错方向、(e) canonical 接 301 再接最终 URL 的链式跳转。每条给出修复。
数据：
[paste]7. 结构化数据 / JSON-LD 审计
下面是某文章的 JSON-LD。请审：(a) 所选 schema.org 类型的必需字段是否都齐且非空、(b) 数据类型是否符合 spec（日期是否 ISO 8601、author 是否 Person/Organization）、(c) 能解锁 rich results 但缺失的推荐字段（FAQPage、BreadcrumbList、image 尺寸）、(d) 类型选得是否合适（Article vs BlogPosting vs HowTo）。输出修复后的 JSON。
JSON-LD：
[paste]8. Sitemap 与抓取预算审计
下面是 sitemap.xml（或一份 URL 列表）。请识别：(a) sitemap 里返回非 200 的 URL、(b) sitemap 里却被 noindex 或被别处 canonical 的 URL（浪费抓取）、(c) 应该被排除的带参数 URL、(d) 没收进 sitemap 的高优先级页、(e) lastmod 看起来不对或太旧。输出 sitemap 清理 diff。
Sitemap：
[paste]9. 标题层级与内容结构审计
下面是 10 篇文章的 H1-H4 大纲。每篇标出：(a) 多个 H1、(b) H2 后直接出现 H4（跳级）、(c) 一篇里 >8 个 H2 且 H2 下没有 H3（多半要重构）、(d) 标题写成完整句而不是可扫读短语。被标记的篇给出修正后的大纲。
大纲：
[paste]10. 搜索意图 vs 页面形式错配
下面是页面 + 目标关键词 + 当前页面形式（列表 / how-to / 对比 / 定义 / 商业）。请判断每个关键词的主导意图（信息型、商业型、交易型、导航型），并标出错配的——比如商业意图关键词指向一个薄薄的定义页。每个错配给出建议的正确形式。
页面 + 关键词：
[paste]11. Core Web Vitals 与内容页性能审计
下面是 10 个文章页的 Lighthouse / CrUX 数据：LCP、INP、CLS。请识别：(a) 哪些没过谷歌阈值（LCP >2.5s、INP >200ms、CLS >0.1）、(b) 内容页场景下最可能的根因（大首图、JS 注入广告、布局抖动的 embed、render-blocking 字体）、(c) 每页性价比最高的一个修复。按流量排序，把高影响修复排到前面。
数据：
[paste]喂给模型的阈值（谷歌的”良好”线，截至 2026 年 6 月未变）：
| 指标 | 良好 | 需改进 | 内容页常见根因 |
|---|---|---|---|
| LCP | < 2.5s | 2.5-4.0s | 首图未优化、render-blocking 字体 |
| INP | < 200ms | 200-500ms | 主线程上的重广告 / 统计 JS |
| CLS | < 0.1 | 0.1-0.25 | 广告或 embed 没预留空间就插入 |
只有当真实访问中至少 75% 同时过三项时，Search Console 才会显示”良好”。INP 是大多数内容站最容易挂的一项。
12. 关键词集群重叠与合并规划
下面是 20 篇文章的主关键词 + 来自 Search Console 的 Top 5 排名词。请识别：(a) 2 篇及以上排同一查询（cannibalization）、(b) 一篇文章排了应当被拆成两个 intent 的词。每个集群给出建议：合并（保留哪个 slug）、拆分（给出新大纲）、或保留但用更明确的差异点区分。
数据：
[paste]容易踩的坑
- “做个 SEO 审计”——没数据，也没可量化阈值
- 发现里没动作——“你的 meta description 太短”却没说怎么改
- 只审 meta，不审内容本身的质量
- 看见薄内容就一刀切”扩写”——有时合并或删才是对的
- 跳过双语站的 hreflang / translationKey 一致性
- 粘报告截图而不是原始表格——模型只能审它读得到的数据
常见问题
AI 能取代 Ahrefs 或 Screaming Frog 吗？ 不能。爬虫负责采数据（状态码、canonical、字数、CrUX 数字），模型负责解读并排优先级。从爬虫导出，粘进第 2、6 或 8 条 Prompt，让模型把一份 5,000 行的 CSV 变成一份排好序的行动清单。
哪个模型能一次粘进最大的站？ 截至 2026 年 6 月，Claude Opus 4.7、Sonnet 4.6 和 Gemini 3.1 Pro 都是 1M token 上下文，足够装下几千条带 metadata 的 slug。ChatGPT Plus 应用内大约只到 320 页，所以要按板块分批审。
怎么防止模型在修复里编造 slug？ 明确告诉它：“只引用上面数据里出现过的 slug；如果没有合适的合并目标，就直说没有。“薄内容（第 4 条）和同食（第 5、12 条）这几条最容易混进编造的目标，所以执行前务必核对每个建议合并。
这些阈值现在还准吗？ 截至 2026 年 6 月仍然准。Title 截断在约 600px（约 60 字符）、meta description 约 120-160 字符、Core Web Vitals 三条线（LCP 2.5s、INP 200ms、CLS 0.1）都没变。日后再读，可在 web.dev 复核 CWV 数字。
每次都要把 12 条全跑一遍吗？ 不用。上线前：跑 1、3、6、7。季度刷新：4、5、12。迁移之后：3、6、8。性能投诉：11。按症状选，别按日历选。