一句话总结
通用 100 点 SEO 清单纯属浪费时间：一半项目不适用你的栈，另一半模糊到根本没法验证。换个做法——把你技术栈的精确描述喂给一个能读代码的 AI（Claude Code、Cursor 或 Codex），让它生成一份 30-60 项、分成六组的清单，每项标 P0/P1/P2，并配一条你能真正跑起来的验证命令。手动剪掉不适用的项，提交成 SEO_CHECKLIST.md，每季度重生一次。首次约 20 分钟。每个阈值都对齐当前数字：截至 2026 年 6 月，Core Web Vitals 目标是 LCP 低于 2.5 秒、INP 低于 200 毫秒、CLS 低于 0.1，按真实用户数据的 75 分位测量。
通用清单为什么坑你
痛点很具体。你从某篇博客抓来一份 100 项技术 SEO 清单。三分之一对你的栈是死重量：AMP 配置、jQuery 延迟加载、Magento 分层导航，你一样都没用。又有三分之一措辞模糊到（“优化抓取预算""改善站点结构”）你根本判断不了自己做没做。剩下真正有用的几项埋在噪声里，而且半年后你没法证明它们还成立。
一份栈定制、每项带验证命令的清单同时解决这两个问题。它也是外包真正会用的东西。你给人一份通用 PDF，它就躺着没人看；你给人 curl -I https://example.com/sitemap.xml 配上 “sitemap 返回 200 且 content-type 正确”，他就会去跑。
这篇适合谁看
- 独立开发者：跑内容站、不想请代理就要一条基线。
- 小 SEO 团队：支持单个产品时，一份贴合栈的清单胜过共用模板。
- 加入新项目的 IC：动手修之前得先评估 SEO 基线。
- 要把站交给外包的人：清单加验证命令才是能撑过交接的交付物。
什么时候适合用
上线前、栈迁移后（Next 13 转 15、WordPress 转 Astro、任何动到路由或渲染的迁移）、新 SEO 外包入场，或者流量掉了但分不清是技术还是内容问题时跑一次。Google 出了有据可查的变化时也要刷一次——比如 INP 替代 FID、或结构化数据指南更新——让清单把变化捕捉进来，而不是悄悄漏掉。
选对 AI 工具
这个任务奖励那种能读你真实仓库、而不只是在对话框里凭空回答的模型。截至 2026 年 6 月：
| 工具 | 最适合 | 可用模型 | 价格（2026 年 6 月） |
|---|---|---|---|
| Claude Code | 通读整个仓库、跨多文件生成并验证 | Claude Opus 4.7、Sonnet 4.6（仅 Anthropic 模型） | 含在 Claude Pro $20/月；Max $100/$200 |
| Cursor | 在编辑器里边审边改每一项 | Sonnet 4.6、Opus 4.7、GPT-5.5、Gemini 3.1 Pro、Composer 2.5 | Pro $20/月（年付约 $16） |
| Codex | 终端驱动、可脚本化重生清单 | GPT-5.5 | 含在 ChatGPT Plus $20/月 |
| ChatGPT / Gemini 网页版 | 手动粘贴栈描述快速出草稿 | GPT-5.5 / Gemini 3.1 Pro | Plus $20 / Google AI Pro $19.99 |
清单要贴合你的代码，就优先选能打开仓库的工具。Claude Code 会通读并推理整个项目，所以生成的不适用项更少——它能看到你的页面是静态的，而不是靠猜。如果你常驻编辑器，Cursor 的 Sonnet 4.6 能覆盖同样的范围，由你逐行审查。无论哪种，都用前沿模型（Opus 4.7 或 Sonnet 4.6）；小模型会编出更多并不存在的验证命令。
想做更深入的代码感知审计，见Claude Code SEO 审计教程。
具体步骤
- 一段话描述你的栈。 包含框架 + 版本、托管商、渲染模式（SSR / SSG / ISR / 混合）、CDN、图像策略、sitemap 来源、i18n 方案。描述越具体，后面要删的错误项越少。
- 要求分六组。 让 AI 把清单分成抓取、渲染、性能、Schema、国际化、监控。六组刚好：再少缺类，再多重叠。
- 强制显式的优先级标准。 每项标 P0（阻塞上线或修线上回归）/ P1（30 天内）/ P2（可选）。在 prompt 里写清标准，模型才会一致地套用。
- 每项都要一条验证命令。 一条
curl、一次view-source搜索、一个 Lighthouse 目标，或一份 Search Console 报告。例：curl -I https://example.com/sitemap.xml、在view-source里搜rel="canonical"、Lighthouse Performance 大于 90、Core Web Vitals 报告里 INP 低于 200 毫秒。 - 对照真实栈裁剪。 逐条走 P0，问自己：这条适用我的配置吗？Astro SSG 不需要 ISR 缓存头，SSR 的 Next 路由需要。删掉不合的。
- 存档并提交。 存成
SEO_CHECKLIST.md，带日期和一行栈快照。未来的你需要知道清单针对的是哪个版本的栈。 - 季度重生。 Search Console 信号会变、框架会出新功能、schema 词汇会演化。
一段可直接复制的 prompt
打开仓库，把下面这段粘进 Claude Code、Cursor 或 Codex，替换方括号部分：
你是一名技术 SEO 工程师。读取这个仓库，生成一份贴合其真实技术栈的
技术 SEO 清单——不要包含你在代码里看不到、并不适用的项目。
技术栈：[Astro 5 SSG、Firebase Hosting、@astrojs/sitemap、用内容集
做 EN/ZH、无客户端路由]。
输出一份 markdown 清单，正好分成六组：
1. 抓取 2. 渲染 3. 性能 4. Schema 5. 国际化 6. 监控
每一项都要：
- 标 P0（阻塞上线 / 修线上回归）、P1（30 天内）或 P2（可选），严格套用此标准。
- 配一条我能自己跑的验证命令、URL 模式或可量化目标（curl、view-source
搜索、Lighthouse 指标，或某份具体的 Search Console 报告）。不要编造 flag，
只用真实存在的命令。
- 尽量注明它对应仓库里的哪个文件或路由。
剪掉所有不适用项后，控制在 30-60 项。“注明对应文件或路由”这条指令是让模型不撒谎的关键——如果它指不出某项适用在哪里，那一项通常就是幻觉，可以直接砍掉。
好的输出长什么样
给一个 Astro SSG 内容站，截取三项作为示例：
| 分组 | 项目 | 优先级 | 验证 |
|---|---|---|---|
| 抓取 | robots.txt 放行 Googlebot 并链接 sitemap | P0 | curl https://example.com/robots.txt 显示 Sitemap: 行 |
| 渲染 | 每篇文章输出自引用的 rel="canonical" | P0 | 对文章 view-source，搜 rel="canonical" |
| 性能 | 流量最高的文章 LCP 低于 2.5 秒 | P1 | Search Console Core Web Vitals 报告，75 分位 |
注意每一行都点名了具体文件或页面，外加一条命令。如果你的 AI 输出里出现 “改善可抓取性” 这种没有验证列的行，打回去重做。
不同栈会出现哪些项目
Astro（SSG）： hydration 边界（首屏静态块别用 client:load）、@astrojs/sitemap 集成、跨语言集互相对应的 hreflang、只在真实内容变化时才更新 lastmod。sitemap 那条可以配合用 Codex 审查 sitemap 教程。
Next.js： 按路由的渲染模式（SSG / SSR / ISR）、Metadata API 与 generateMetadata、用 next/og（opengraph-image.js）做动态 OG 图像路由、redirect middleware，以及明确的 ISR revalidate 策略。动态 OG 路由仅 App Router 有，所以在 Pages Router 项目上要标 N/A。
WordPress： 在栈描述里列出活跃插件，AI 会叠进插件特定项——Yoast 与 RankMath 的 canonical 冲突、两个插件同时输出重复的 Article/FAQ schema、以及某些会剥掉 Vary 头的缓存插件。
Hugo： sitemap.xml 模板、canonifyURLs 行为，以及你确实在用的任何 AMP/RSS 变体对应的 outputs 配置。
提交前的质量门
- 每项都有验证命令、URL 或可量化目标。验不了就不能标已完成。
- 每个 P0 项都是你自己代码里能修的。托管商相关项（CDN 的 TTFB、边缘缓存规则）另起一组。
- 没有任何项引用了你框架版本不存在的功能。“用 Next.js 动态 OG 图像路由” 只适用 App Router（Next 13+）。
- 分组之间没有重复项。AI 特别爱把 canonical 检查同时塞进抓取和渲染——保留一份。
- 整份清单熟手 60 分钟内跑完。再长就拆成 “P0 快查” 和 “P1+P2 深审” 两份。
第一次实操怎么跑
先在单页跑，别全站跑。挑首页或你流量最高的一篇文章。生成清单后，逐条对这一页验证 P0。实际跑下来，模型会输出几项不适用的（它把 SSG 页当成了 SSR）和几条查了不存在属性的验证命令。把这些标进清单文件，下次季度刷新就不会重犯，再把栈描述按你学到的精化，然后重生。
容易踩的坑
- 用通用清单起步，而不为你的栈生成。花在删的时间比验的还多。
- 跳过验证命令字段。 没有它，项目会烂掉，谁都没法证明还成立。
- 把清单当永恒。 Google 和框架在变，12 个月前的清单会悄悄漏掉真问题。
- 多站共用一份大清单。 栈差异让它比每站一份还糟。staging（noindex）和生产规则不同。
- 让 AI 编命令。 模型会自信地生成
curl --google-bot这种不存在的 flag。每条命令都先实跑再信。 - 把内容任务塞进技术清单。 “更新 CMS""改进内容” 属于别处；这份清单是技术 SEO。
FAQ
- 应该有多少项？ 剪后 30 到 60，对比通用模板的 80 到 150。明显更大的清单通常意味着重复，或越界到了内容 SEO。
- 当前 Core Web Vitals 阈值是多少？ 截至 2026 年 6 月，LCP 低于 2.5 秒、INP 低于 200 毫秒、CLS 低于 0.1，都按 Search Console 现场数据的 75 分位测量。三项里 INP 最常不达标，所以交互页要优先盯它。
- 该用哪个 AI 工具？ 选能读代码的那种。Claude Code 通读整个仓库，生成的不适用项更少；如果你想在编辑器里逐项审查，Cursor 更顺手。两者都跑前沿模型（Opus 4.7 / Sonnet 4.6），比小模型少编命令。
- 能让 AI 替我跑清单吗？ 它能起草和辅助验证，但验证命令最终是你跑。别相信模型自报某项通过——用命令确认。
- 只适用内容站还是 SaaS 落地页也行？ 都行。六个分类不变，P0 重心会偏向渲染模式和 Product/Organization 结构化数据。
- 2026 年结构化数据有什么不同？ 结构化数据仍不是直接排名因素，但有效的 schema 喂给富结果和 AI Overview 引用。值得检查的 schema 类型是 Organization、Article/BlogPosting、FAQPage、Product 和 LocalBusiness——每个都在 Rich Results Test 里验一遍。
相关阅读
- Claude Code SEO 审计教程
- AI Astro 内容审计教程
- canonical 是什么——该设什么、不该设什么
- 新网站提交 Google：2026 四步法和真实等待时间
- 用 Codex 审查 sitemap 教程
标签: #教程 #SEO #AI 编程 #Technical SEO #清单