当需要对网站做技术 SEO 与 GEO（AI…

对目标站点（首页 + 2-3 个关键内页）做技术 SEO 与生成式引擎优化（GEO）审计，覆盖抓取、索引、安全、URL、移动端、Core Web Vitals、SSR、页面速度 8 大类，并生成 GEO-TECHNICAL-AUDIT.md 报告。

适用场景

解决思路

1. 收集目标 URL（首页 + 2-3 个关键内页），用 curl/WebFetch 抓取每个页面的原始 HTML 与 HTTP 响应头，然后逐类跑完 8 个审计类别并按评分表打分，最终生成 GEO-TECHNICAL-AUDIT.md。
2. 抓取 https://[domain]/robots.txt，检查语法有效性（正确的 User-agent、Allow、Disallow 指令），排查常见错误：缺 User-agent、通配符挡住重要路径、Disallow: / 屏蔽整站；并确认已引用 XML sitemap（Sitemap: https://[domain]/sitemap.xml）。
3. 在 robots.txt 中逐条检查对 AI 爬虫的指令：GPTBot、Google-Extended、Googlebot、bingbot、PerplexityBot、ClaudeBot、Amazonbot、CCBot、FacebookExternalHit、Bytespider、Applebot-Extended；评分标准：全部主要 AI 爬虫放行 5 分，部分被屏蔽但 Googlebot + bingbot 放行 3 分，屏蔽 GPTBot 或 PerplexityBot 1 分，屏蔽 Googlebot 0 分（致命）。
4. 注意 Google-Extended 的语义差别：屏蔽它并不会屏蔽 Googlebot，它只控制 AI 训练数据使用；但屏蔽 Google-Extended 可能降低在 AI Overviews 中的出现，除有明确的数据授权顾虑外建议放行。
5. 抓取 XML sitemap（位置看 robots.txt，或试 /sitemap.xml、/sitemap_index.xml），校验 XML 语法、检查 <lastmod> 是否存在且准确、统计 URL 数并与预期可索引页数对比、大站使用 sitemap index（单个 sitemap 最多 50000 个 URL）、抽样验证 sitemap 中的 URL 都返回 200。
6. 检查抓取深度：首页为 depth 0，确保所有重要页面在 3 次点击内可达；depth 4+ 的页面抓取预算显著更少、被 AI 引用概率更低；检查内链，确认关键内容页从首页或主导航可达。
7. 检查 noindex 管理：找出本应被索引却带有 <meta name="robots" content="noindex"> 或 X-Robots-Tag: noindex 的页面；常见错误是分页页、分类页或关键落地页被 noindex。
8. 检查 canonical 标签：每个可索引页都必须有 <link rel="canonical" href="...">，权威版本应自引用，排查 HTML 与 HTTP 头 canonical 冲突，排查 canonical 链（A→B、B→C 应改为 A→C）。
9. 排查重复内容：www 与非 www 都要能解析但一个重定向到另一个、HTTP 重定向到 HTTPS、尾斜杠风格统一并重定向另一种、处理参数化重复（如 ?sort=price 产生的重复页）。
10. 处理分页：检查 rel="next"/rel="prev"（Google 自 2019 年起忽略，Bing 仍使用）；推荐在分页页用 rel="canonical" 指向 view-all 页或第一页；分页页含唯一内容时不要 noindex。
11. 国际化站点检查 hreflang：检查 <link rel="alternate" hreflang="xx"> 标签，验证互相指向（A 指向 B 则 B 必须指回 A）、存在 x-default 兜底、语言/地区码符合 ISO 639-1 / ISO 3166-1。
12. 检查 index bloat：估算已索引页数（看 sitemap 数量、用 site:domain.com 估算），与实际有价值内容页对比；若索引页数显著超出内容页，标记为薄内容/重复/参数页导致的索引膨胀。
13. HTTPS 强制检查：站点必须走 HTTPS 加载，HTTP 必须 301 重定向到 HTTPS，无混合内容告警，SSL/TLS 证书有效且未过期。
14. 检查安全响应头：Strict-Transport-Security: max-age=31536000; includeSubDomains、Content-Security-Policy、X-Content-Type-Options: nosniff、X-Frame-Options: DENY 或 SAMEORIGIN、Referrer-Policy: strict-origin-when-cross-origin 或更严、Permissions-Policy。
15. 检查 URL 是否整洁可读：如 /blog/seo-guide 而非 /blog?id=12345；URL 中无 session ID、全小写、用连字符而非下划线分词、无特殊字符或编码空格。
16. 检查 URL 逻辑层级：路径应反映站点架构 /category/subcategory/page，适当扁平化避免过深嵌套，全站模式一致。
17. 检查重定向链：排查链式重定向（A→B→C，建议最多 1 跳，直接 A→C）、排查重定向环；永久跳转应用 301 而非 302（除非有意临时）。
18. 处理 URL 参数：参数不应产生重复可索引页，用 canonical 标签或 robots.txt Disallow 处理参数变体，并在 Google Search Console 与 Bing Webmaster Tools 中配置参数处理。
19. 检查响应式设计：存在 <meta name="viewport" content="width=device-width, initial-scale=1">，移动端无横向滚动，无宽于视口的固定宽度布局（背景：2024 年 7 月起 Google 只用移动版 Googlebot 抓取所有站点）。
20. 检查点击目标：按钮、链接等交互元素至少 48x48 CSS 像素，间距至少 8px，导航在移动端可用。
21. 检查字号与对比度：基础字号至少 16px，文本无需缩放即可阅读，对比度达 WCAG AA（普通文本 4.5:1，大文本 3:1）。
22. 检查移动内容对等：桌面可见的所有内容移动端也可见，不要藏在 Googlebot 展不开的「read more」折叠后，图片与媒体在移动端正常加载。
23. 评估 Core Web Vitals：以真实用户数据（field data）的 75 分位为基准（lab 数据仅用于调试），目标 LCP < 2.5s、INP < 200ms、CLS < 0.1（INP 于 2024 年 3 月取代 FID，衡量全部交互而非仅首次）。
24. 无 CrUX 真实数据时按页面特征估算：LCP 看首屏最大元素（图片大小/格式、web 字体加载、服务端响应 TTFB）；INP 看重 JS、超过 50ms 的长任务、第三方脚本；CLS 看无显式宽高的图片、首屏动态插入内容、字体造成的 FOUT/FOIT。
25. 修复 LCP：hero 图改用 WebP/AVIF、尺寸正确、用 <link rel="preload"> 预加载；降低服务端响应时间（TTFB < 800ms）；消除阻塞渲染的 CSS/JS；对关键第三方源做 preconnect。
26. 修复 INP：用 requestIdleCallback 或 scheduler.yield() 把超过 50ms 的长任务切分；减少第三方 JavaScript；离屏内容用 content-visibility: auto；对事件处理做 debounce/throttle。
27. 修复 CLS：图片和视频始终写上 width 和 height 属性；用 CSS aspect-ratio 或显式尺寸为广告与嵌入预留空间；字体用 font-display: swap 配 size-adjusted 兜底字体；页面加载后不要在已有内容上方插入内容。
28. 检测 SSR：用 curl（不执行 JS）抓取页面，与浏览器渲染后的 DOM 对比；若标题、正文、产品信息、文章正文等关键内容在 curl 输出中缺失，说明站点依赖客户端渲染——AI 爬虫（GPTBot、PerplexityBot、ClaudeBot 等）完全不执行 JS，Googlebot 也会把 JS 渲染放进单独队列从而延迟索引数天到数周。
29. 在原始 HTML 中逐项检查：正文文本、H1/H2/H3 标题、主导航、JSON-LD 结构化数据、title/description/canonical/OG 等 meta 标签、导航与内容内链（内链对可抓取性至关重要）。
30. 给出 SSR 方案建议：React→Next.js（SSR/SSG）、Remix、Gatsby（SSG）；Vue→Nuxt.js（SSR/SSG）；Angular→Angular Universal；Svelte→SvelteKit；通用→Prerender.io（预渲染服务）、Rendertron。
31. SSR 评分：全部关键内容服务端渲染 15 分；正文服务端渲染但部分元素仅 JS 10 分；关键内容（产品信息、文章正文）需 JS 才能出 5 分；整页客户端渲染（原始 HTML body 为空）0 分。
32. 测量 TTFB：目标 < 800ms（最好 < 200ms），命令 curl -o /dev/null -s -w 'TTFB: %{time_starttransfer}s\n' [URL]；若超标则检查服务器位置、缓存、数据库查询、是否使用 CDN。
33. 优化资源体积：页面总重目标 < 2MB（关键页 < 1MB）；开启 gzip/brotli 压缩；压缩（minify）CSS 与 JavaScript；清理未使用的 CSS/JS（在许多站点上可占下载字节的 50% 以上）。
34. 优化图片：优先 WebP 或 AVIF 格式；排查尺寸大于显示尺寸的图片；首屏以下图片加 loading="lazy"；显式写 width/height 防 CLS；首屏图片不要懒加载（会伤害 LCP）。
35. 做代码分割与懒加载：JS 按页面拆分只加载所需部分，压缩后 JS bundle > 200KB 为警告、> 500KB 为严重；第三方脚本用 async 或 defer 异步加载；排查 <head> 中阻塞渲染的资源。
36. 配置缓存：静态资源（图片、CSS、JS）用长缓存 Cache-Control: max-age=31536000（1 年）配内容哈希文件名；HTML 页面用较短缓存或 no-cache 配 ETag/Last-Modified 校验。
37. 检查 CDN：判断静态资源是否由 CDN 提供（不同域名或 CDN 专属响应头）；面向全球受众时 CDN 对稳定性能至关重要；识别 CF-Ray（Cloudflare）、X-Cache（AWS CloudFront）、X-Served-By（Fastly）。
38. （非计分）RFC 8288 Link 头服务发现：从首页抓取的响应头中解析所有 Link: 头，解析 <url>; rel="relation-type" 对；关注高价值 rel 类型 api-catalog（RFC 9609）、describedby、service-doc、mcp-server-card；仅对 API-first 站点（导航含 API 文档、有 /api/ 或 /developers/ 路径、sitemap 含 swagger/OpenAPI）给建议，标准业务站缺失属正常，应完全省略该节。
39. （非计分）Markdown 内容协商：对首页发送带 Accept: text/markdown 的 GET（每次审计多一次请求）；若响应 Content-Type 为 text/markdown（或 text/markdown; charset=utf-8）则通过并记为前沿能力；否则作为前瞻性建议而非失败；请求报错或非 200 则跳过并记录错误，不扣分；Cloudflare Workers/Pages 站点可通过一行配置启用「Markdown for Agents」。
40. （非计分）IndexNow：检查是否存在 key 文件，如 https://[domain]/.well-known/indexnow-key.txt；检查 CMS 是否有 IndexNow 插件（WordPress 有 IndexNow 插件，许多现代 CMS 原生支持）；未实现则给出添加说明；Bing、Yandex、Seznam、Naver 支持该协议，Google 不支持但会监控；ChatGPT 与 Bing Copilot 都使用 Bing 索引，Bing 索引更快意味着 AI 曝光更快。
41. 按 100 分制汇总：Crawlability 15、Indexability 12、Security 10、URL Structure 8、Mobile Optimization 10、Core Web Vitals 15、Server-Side Rendering 15、Page Speed & Server 15；类别状态 Pass = 该类别 80%+、Warn = 50-79%、Fail = <50%；总分解释：90-100 优秀、70-89 良好、50-69 需改进、30-49 差、0-29 严重。
42. 生成 GEO-TECHNICAL-AUDIT.md，包含：技术总分、分数拆分表（各类得分与 Pass/Warn/Fail）、AI 爬虫访问表（爬虫 / User-Agent / 状态 / 建议）、Critical Issues（立即修复，含具体页面 URL 与问题）、Warnings（本月修复）、Recommendations（本季度优化）、Agent-Readiness Signals（非计分，放 Link 头与 Markdown 内容协商结果）、以及按类别的详细发现与证据。

适用边界 · 注意事项

• 目标不是有公开网页的站点时（纯 API 服务、本地应用、只有 PDF 资产）没有可抓取审计的 HTML 页面，不适用。
• 没有网络抓取能力（curl/WebFetch 或等价工具）时无法获取原始 HTML 与 HTTP 响应头，审计无法开展。
• Category 9（RFC 8288 Link 头、Markdown 内容协商）只应对 API-first 或 Cloudflare 站点给建议；标准业务站缺失属预期，不应据此判为缺陷或扣分。