geo-technical

GEO 技术 SEO 审计

目的

技术 SEO 是传统搜索可见度和 AI 搜索引用的基础。技术存在问题的网站无法被任何平台抓取、编入索引或引用。本技能会审计技术健康状况的 8 个类别，并特别关注 GEO 要求——其中最关键的是服务器端渲染（AI 爬虫不会执行 JavaScript）和AI 爬虫访问权限（许多网站会在 robots.txt 中无意间屏蔽 AI 爬虫）。

如何使用此技能

1. 收集目标 URL（首页 + 2-3 个关键内页）
2. 使用 curl/WebFetch 获取每个页面的原始 HTML 和 HTTP 标头
3. 按照以下 8 个审计类别逐项检查
4. 根据评分标准为每个类别打分
5. 生成包含审计结果的 GEO-TECHNICAL-AUDIT.md

---

类别 1：可抓取性（15 分）

1.1 robots.txt 有效性

• 获取 https://[domain]/robots.txt
• 检查语法是否有效：User-agent、Allow、Disallow 指令是否正确
• 检查常见错误：缺少 User-agent、通配符屏蔽重要路径、Disallow: / 屏蔽整个网站
• 确认其中引用了 XML 站点地图：Sitemap: https://[domain]/sitemap.xml

1.2 AI 爬虫访问权限（对 GEO 至关重要）

检查 robots.txt 中是否有针对以下 AI 爬虫的指令：

爬虫	User-Agent	平台
GPTBot	GPTBot	ChatGPT / OpenAI
Google-Extended	Google-Extended	Gemini / Google AI 训练
Googlebot	Googlebot	Google 搜索 + AI Overviews
Bingbot	bingbot	Bing Copilot + ChatGPT（通过 Bing）
PerplexityBot	PerplexityBot	Perplexity AI
ClaudeBot	ClaudeBot	Anthropic Claude
Amazonbot	Amazonbot	Alexa / Amazon AI
CCBot	CCBot	Common Crawl（许多 AI 模型使用）
FacebookBot	FacebookExternalHit	Meta AI
Bytespider	Bytespider	TikTok / ByteDance AI
Applebot-Extended	Applebot-Extended	Apple Intelligence

AI 爬虫访问权限评分：

• 允许所有主要 AI 爬虫：5 分
• 屏蔽部分爬虫，但允许 Googlebot + Bingbot：3 分
• 屏蔽 GPTBot 或 PerplexityBot：1 分（对 GEO 有显著影响）
• 屏蔽 Googlebot：0 分（致命问题）

重要说明：屏蔽 Google-Extended 并不会屏蔽 Googlebot。Google-Extended 仅控制 AI 训练数据的使用，不影响搜索索引。不过，屏蔽 Google-Extended 可能会降低网站出现在 AI Overviews 中的机会。除非存在具体的数据许可顾虑，否则建议允许 Google-Extended。

1.3 XML 站点地图

• 获取站点地图（检查 robots.txt 中的位置，或尝试 /sitemap.xml、/sitemap_index.xml）
• 验证 XML 语法
• 检查是否包含 <lastmod> 日期（应存在且准确）
• 统计 URL 数量，并与预期可编入索引的页面数量比较
• 对大型网站，检查是否有站点地图索引（每个站点地图最多 50,000 个 URL）
• 确认所有站点地图 URL 均返回 200 状态码（抽样检查）

1.4 抓取深度

• 首页 = 深度 0。检查所有重要页面是否都能在 3 次点击内到达（深度 3）
• 深度为 4 及以上的页面获得的抓取预算会显著减少，也更不容易被 AI 引用
• 检查内部链接：关键内容页面是否从首页或主导航链接到？

1.5 Noindex 管理

• 检查应该编入索引的页面上是否存在 <meta name="robots" content="noindex">
• 检查 HTTP 标头中是否存在 X-Robots-Tag: noindex
• 常见错误：在分页页面、分类页面或关键落地页上设置 noindex

类别评分：

检查项	分数
robots.txt 有效且完整	3
允许 AI 爬虫访问	5
存在有效的 XML 站点地图	3
抓取深度不超过 3 次点击	2
不存在错误的 noindex 指令	2

---

类别 2：可编入索引性（12 分）

2.1 规范标签

• 每个可编入索引的页面都必须包含 <link rel="canonical" href="..."> 标签
• 对于权威版本，规范 URL 必须指向页面自身（自引用）
• 检查是否存在相互冲突的规范 URL（HTML 中的规范 URL 与 HTTP 标头中的规范 URL）
• 检查是否存在规范 URL 链（A 的规范 URL 指向 B，B 的规范 URL 指向 C——应让 A 直接指向 C）

2.2 重复内容

• 检查是否同时存在 www 和非 www 版本（两者都应可访问，其中一个应重定向）
• 检查 HTTP 和 HTTPS 版本（HTTP 应重定向到 HTTPS）
• 检查尾部斜杠是否一致（选择一种格式，并将另一种格式重定向）
• 检查是否存在基于参数的重复页面（?sort=price 创建重复页面）

2.3 分页

• 如果内容存在分页，检查是否使用 rel="next" / rel="prev"（注意：Google 自 2019 年起已忽略这些标记，但 Bing 仍会使用）
• 建议：在分页页面上使用 rel="canonical"，指向“查看全部”页面或第一页
• 如果分页页面包含独特内容，确保这些页面未设置为 noindex

2.4 Hreflang（国际化网站）

• 检查是否存在 <link rel="alternate" hreflang="xx"> 标签
• 验证：hreflang 是否互为指向（如果页面 A 指向页面 B，B 也必须指回 A）
• 验证：是否存在 x-default 回退项
• 检查语言/地区代码是否有效（ISO 639-1 / ISO 3166-1）

2.5 索引膨胀

• 估算已编入索引的页面数量（检查站点地图中的数量，使用 site:domain.com 估算）
• 将已编入索引的页面与实际有价值的内容页面进行比较
• 如果已编入索引的页面数量远超内容页面数量，则标记为索引膨胀（由内容单薄、重复或参数页面造成）

类别评分：

检查项	分数
所有页面的规范标签均正确	3
无重复内容问题	3
分页处理正确	2
Hreflang 正确（如适用）	2
无索引膨胀	2

---

类别 3：安全性（10 分）

3.1 强制使用 HTTPS

• 网站必须通过 HTTPS 加载
• HTTP 必须重定向到 HTTPS（301 重定向）
• 不得出现混合内容警告（HTTPS 页面中包含 HTTP 资源）
• SSL/TLS 证书必须有效且未过期

3.2 安全标头

检查 HTTP 响应标头：

标头	必需值	用途
Strict-Transport-Security	max-age=31536000; includeSubDomains	强制使用 HTTPS
Content-Security-Policy	合适的策略	防止 XSS
X-Content-Type-Options	nosniff	防止 MIME 嗅探
X-Frame-Options	DENY 或 SAMEORIGIN	防止点击劫持
Referrer-Policy	strict-origin-when-cross-origin 或更严格的策略	控制引荐来源数据
Permissions-Policy	合适的限制	控制浏览器功能

类别评分：

检查项	分数
已强制使用 HTTPS，且证书有效	4
存在 HSTS 标头	2
X-Content-Type-Options	1
X-Frame-Options	1
Referrer-Policy	1
Content-Security-Policy	1

---

类别 4：URL 结构（8 分）

4.1 简洁 URL

• URL 应易于阅读：使用 /blog/seo-guide，而非 /blog?id=12345
• URL 中不得包含会话 ID
• 仅使用小写字母（不得混用大小写）
• 使用连字符分隔单词（而非下划线）
• 不得包含特殊字符或经过编码的空格

4.2 合理的层级结构

• URL 路径应体现网站架构：/category/subcategory/page
• 适当采用扁平结构——避免不必要的深层嵌套
• 整个网站应采用一致的格式

4.3 重定向链

• 检查是否存在重定向链（A 重定向到 B，B 再重定向到 C）
• 建议最多重定向 1 次（让 A 直接重定向到 C）
• 检查是否存在重定向循环
• 除非明确需要临时重定向，否则所有重定向都应使用 301（永久），而非 302（临时）

4.4 参数处理

• URL 参数不应创建重复的可索引页面
• 对参数变体使用规范标签或在 robots.txt 中设置 Disallow
• 在 Google Search Console 和 Bing Webmaster Tools 中配置参数处理

类别评分：

检查项	分数
URL 简洁易读	2
层级结构合理	2
无重定向链（最多 1 次跳转）	2
已配置参数处理	2

---

类别 5：移动设备优化（10 分）

关键背景

截至 2024 年 7 月，Google 仅使用移动版 Googlebot 抓取所有网站，不再进行桌面版抓取。如果你的网站无法在移动设备上正常运行，对 Google 来说它就无法正常运行。就是这样。

5.1 响应式设计

• 检查是否包含 <meta name="viewport" content="width=device-width, initial-scale=1">
• 内容不得要求用户在移动设备上水平滚动
• 不得使用宽于视口的固定宽度布局

5.2 点击目标

• 交互元素（按钮、链接）至少为 48x48 CSS 像素
• 点击目标之间至少间隔 8px
• 检查导航是否能在移动设备上正常使用

5.3 字号

• 基础字号应至少为 16px
• 不得有需要缩放才能阅读的文本
• 对比度应足够（WCAG AA：普通文本为 4.5:1，大号文本为 3:1）

5.4 移动版内容一致性

• 桌面版上可见的所有内容在移动版上也必须可见
• 不得将内容隐藏在 Googlebot 无法展开的“阅读更多”切换项后面（不过截至 2025 年，Google 已改进了展开此类内容的能力）
• 图片和媒体必须能在移动设备上加载

类别评分：

检查项	分数
视口 meta 标签正确	3
响应式布局（无水平滚动）	3
点击目标尺寸合适	2
字号易于阅读	2

---

类别 6：Core Web Vitals（15 分）

2026 年指标和阈值

Core Web Vitals 以真实用户数据（现场数据）的第 75 百分位数作为基准。实验室数据有助于调试，但排名信号取决于现场数据。

指标	良好	需要改进	较差	备注
LCP（最大内容绘制）	< 2.5s	2.5s - 4.0s	> 4.0s	衡量加载情况——最大可见元素完成渲染所需的时间
INP（交互到下一次绘制）	< 200ms	200ms - 500ms	> 500ms	于 2024 年 3 月取代 FID。衡量所有交互，而不仅是首次交互
CLS（累积布局偏移）	< 0.1	0.1 - 0.25	> 0.25	衡量视觉稳定性——意外的布局移动

没有 CrUX 数据时如何评估

无法获取真实用户数据时，可根据页面特征估算：

• LCP：检查首屏最大元素。它是图片吗（检查尺寸和格式）？是文本吗（检查 Web 字体加载）？服务器响应时间（TTFB）如何？
• INP：检查页面是否包含繁重的 JavaScript。长任务（>50ms）会阻塞交互。检查第三方脚本。
• CLS：检查图片是否缺少明确的宽度/高度。检查首屏是否有动态插入的内容。检查 Web 字体是否会导致布局偏移（FOUT/FOIT）。

常见的 LCP 修复方法

1. 优化主视觉图片：使用 WebP/AVIF 格式，设置合适的尺寸，并使用 <link rel="preload"> 预加载
2. 缩短服务器响应时间（TTFB < 800ms）
3. 消除阻塞渲染的 CSS/JS
4. 预连接到关键的第三方源

常见的 INP 修复方法

1. 使用 requestIdleCallback 或 scheduler.yield()，将长任务（>50ms）拆分成更小的任务块
2. 减少第三方 JavaScript
3. 对屏幕外内容使用 content-visibility: auto
4. 对事件处理程序进行防抖/节流

常见的 CLS 修复方法

1. 始终为图片和视频添加 width 和 height 属性
2. 使用 CSS aspect-ratio 或明确尺寸为广告和嵌入内容预留空间
3. 使用 font-display: swap，并搭配经过尺寸调整的后备字体
4. 避免在页面加载后于现有内容上方插入内容

类别评分：

检查项	分数
LCP < 2.5s	5
INP < 200ms	5
CLS < 0.1	5

---

类别 7：服务器端渲染（15 分）——对 GEO 至关重要

为什么 SSR 对 AI 可见性至关重要

AI 爬虫（GPTBot、PerplexityBot、ClaudeBot 等）不会执行 JavaScript。它们会获取原始 HTML 并进行解析。如果你的内容由 React、Vue、Angular 或任何其他 JavaScript 框架在客户端渲染，AI 爬虫看到的将是空白页面。

即使是会执行 JavaScript 的 Googlebot，也会降低 JS 渲染内容的优先级，因为这需要额外的爬取预算。Google 会在单独的“渲染队列”中处理 JS 渲染，这可能导致索引延迟数天或数周。

检测方法

1. 使用 curl 获取页面（不执行 JavaScript）：curl -s [URL]
2. 将原始 HTML 与渲染后的 DOM（通过浏览器）进行比较
3. 如果 curl 输出中缺少关键内容（标题、段落、产品信息、文章文本），则该网站依赖客户端渲染

检查内容

• 主要内容文本：原始 HTML 中是否包含文章正文／产品描述／页面内容？
• 标题：原始 HTML 中是否包含 H1、H2、H3 标签？
• 导航：主导航是否由服务端渲染？
• 结构化数据：原始 HTML 中是否包含 JSON-LD，还是由 JavaScript 注入？
• Meta 标签：原始 HTML 中是否包含 title、description、canonical、OG 标签？
• 内部链接：原始 HTML 中是否包含导航链接和内容链接？（这对可爬取性至关重要）

建议的 SSR 解决方案

框架	SSR 解决方案
React	Next.js（SSR/SSG）、Remix、Gatsby（SSG）
Vue	Nuxt.js（SSR/SSG）
Angular	Angular Universal
Svelte	SvelteKit
通用	Prerender.io（预渲染服务）、Rendertron

评分详情

• 所有关键内容均由服务端渲染：15 分
• 主要内容由服务端渲染，但部分元素仅由 JS 渲染：10 分
• 关键内容需要 JS（产品信息、文章文本）：5 分
• 整个页面均由客户端渲染（原始 HTML 中正文为空）：0 分

类别评分：

检查项	分数
原始 HTML 中的主要内容	8
原始 HTML 中的 Meta 标签和结构化数据	4
原始 HTML 中的内部链接	3

---

类别 8：页面速度与服务端性能（15 分）

8.1 首字节时间（TTFB）

• 目标：< 800ms（理想情况下 < 200ms）
• 使用 curl 测量：curl -o /dev/null -s -w 'TTFB: %{time_starttransfer}s\n' [URL]
• 如果 TTFB > 800ms：检查服务端位置、缓存、数据库查询和 CDN 使用情况

8.2 资源优化

• 页面总大小目标：< 2MB（关键页面 < 1MB）
• 检查是否存在未压缩的资源（应启用 gzip/brotli 压缩）
• 检查是否存在未压缩的 CSS 和 JavaScript
• 检查是否存在未使用的 CSS/JS（在许多网站中，这可能占下载字节数的 50% 以上）

8.3 图片优化

• 检查图片格式：优先使用 WebP 或 AVIF，而非 JPEG/PNG
• 检查图片尺寸是否过大（图片尺寸大于显示尺寸）
• 检查是否启用了延迟加载：首屏以下的图片应设置 loading="lazy"
• 检查是否指定了尺寸（width/height 属性可防止 CLS）
• 首屏图片不应启用延迟加载（这会损害 LCP）

8.4 代码拆分与延迟加载

• 应拆分 JavaScript 代码，使每个页面只加载所需内容
• 检查是否存在较大的 JavaScript 包（压缩后 > 200KB 需警惕，> 500KB 则为严重问题）
• 第三方脚本应异步加载（async 或 defer）
• 检查 <head> 中是否存在阻塞渲染的资源

8.5 缓存

• 检查静态资源（图片、CSS、JS）的 Cache-Control 标头
• 静态资源应设置较长的缓存时间：max-age=31536000（1 年），并使用包含内容哈希的文件名
• HTML 页面应设置较短的缓存时间，或使用 no-cache 并进行验证（ETag 或 Last-Modified）

8.6 CDN 使用情况

• 检查静态资源是否通过 CDN 提供（域名不同或具有 CDN 专属标头）
• 面向全球受众时，CDN 对保持性能稳定至关重要
• 检查 CDN 专属标头：CF-Ray（Cloudflare）、X-Cache（AWS CloudFront）、X-Served-By（Fastly）

类别评分：

检查项	分数
TTFB < 800ms	3
页面大小 < 2MB	2
图片已优化（格式、大小、延迟加载）	3
JS 包大小合理（压缩后 < 200KB）	2
已启用压缩（gzip/brotli）	2
静态资源设有缓存标头	2
正在使用 CDN	1

---

类别 9：Agent 就绪度信号（不计分）

这些检查用于发现新兴的 AI Agent 兼容性信号。它们均不计入数值评分，只会给出通过结果或建议。相关标准目前仍处于 IETF 草案阶段或早期采用阶段；因缺少这些功能而扣分并不公平。

9.1 RFC 8288 Link 标头（服务发现）

RFC 8288（Web Linking）定义了 HTTP Link: 响应标头。服务器可以使用它以机器可读的方式公布相关资源（例如 API 目录、服务文档、MCP 服务卡片），而无需解析 HTML。

检查方法： 从标准首页请求中捕获所有 Link: 响应标头（无需额外请求）。

检查内容：

• 解析 <url>; rel="relation-type" 对。
• 高价值 rel 类型：api-catalog（RFC 9609）、describedby、service-doc、mcp-server-card。

何时显示建议： 仅针对 API 优先型网站（导航中链接了 API 文档，使用 /api/ 或 /developers/ 路径，或网站地图中包含 swagger/OpenAPI）。对于普通商业网站，应完全省略此部分——缺少此功能是预期情况，并不值得特别指出。

状态	处理方式
存在 Link: 标头，且包含已知 rel 类型	提供信息——记录发现的内容
存在 Link: 标头，但 rel 类型未知	提供信息——注明并说明
不存在，且为 API 优先型网站	给出建议——说明原因并建议实施
不存在，且为普通商业网站	省略——不予展示

9.2 Markdown 内容协商

检查服务器是否会对 Accept: text/markdown 请求返回 Content-Type: text/markdown。Cloudflare 的“Markdown for Agents”功能支持此能力——AI Agent 会收到简洁的 Markdown，而非 HTML，从而无需剔除模板内容，并提高内容提取准确性。

检查方法： 向首页发送带有 Accept: text/markdown 的 GET 请求。每次审计会额外发送一个 HTTP 请求。

评估：

• 如果响应的 Content-Type 为 text/markdown（或 text/markdown; charset=utf-8）：通过——注明这是一项前沿能力。
• 否则：给出前瞻性建议，不视为失败。
• 如果请求出错或返回非 200 状态码：跳过并注明错误。不要扣分。

状态	处理方式
返回 text/markdown	加分——注明这是一项前沿能力
返回标准 HTML	给出前瞻性建议
请求出错／返回非 200 状态码	跳过，注明错误，不扣分

---

IndexNow 协议

简介

IndexNow 是一项开放协议，可让网站在内容创建、更新或删除时立即通知搜索引擎。Bing、Yandex、Seznam 和 Naver 均支持此协议。Google 不支持 IndexNow，但会监测该协议。

对 GEO 的重要性

ChatGPT 使用 Bing 的索引。Bing Copilot 使用 Bing 的索引。Bing 索引速度越快，内容在两个主要平台上的 AI 可见度就越早提升。

实施检查

1. 检查是否存在 IndexNow 密钥文件：https://[domain]/.well-known/indexnow-key.txt 或类似文件
2. 检查 CMS 是否安装了 IndexNow 插件（WordPress：IndexNow 插件；许多现代 CMS 平台原生支持该功能）
3. 如果尚未实施，建议添加并提供相关说明

---

总体评分

类别	最高分	权重
可抓取性	15	核心基础
可索引性	12	核心基础
安全性	10	信任信号
URL 结构	8	抓取效率
移动端优化	10	Google 要求
核心网页指标	15	排名信号
服务端渲染	15	GEO 关键因素
页面速度与服务端	15	性能
总计	100

非评分检查项（类别 9）会显示在输出的“Agent 就绪度信号”部分，不影响总分。

评分说明

• 90-100：优秀——技术层面完善，适用于传统 SEO 和 GEO
• 70-89：良好——有少量问题需要处理，但整体基础扎实
• 50-69：需要改进——存在影响可见度的重大技术债务
• 30-49：较差——存在阻碍抓取、索引或 AI 可见度的重大问题
• 0-29：严重——存在需要立即处理的根本性技术故障

---

输出格式

生成 GEO-TECHNICAL-AUDIT.md，其中包含：

# GEO Technical SEO Audit — [Domain]
Date: [Date]

## Technical Score: XX/100

## Score Breakdown
| Category | Score | Status |
|---|---|---|
| Crawlability | XX/15 | Pass/Warn/Fail |
| Indexability | XX/12 | Pass/Warn/Fail |
| Security | XX/10 | Pass/Warn/Fail |
| URL Structure | XX/8 | Pass/Warn/Fail |
| Mobile Optimization | XX/10 | Pass/Warn/Fail |
| Core Web Vitals | XX/15 | Pass/Warn/Fail |
| Server-Side Rendering | XX/15 | Pass/Warn/Fail |
| Page Speed & Server | XX/15 | Pass/Warn/Fail |

Status: Pass = 80%+ of category points, Warn = 50-79%, Fail = <50%

## AI Crawler Access
| Crawler | User-Agent | Status | Recommendation |
|---|---|---|---|
| GPTBot | GPTBot | Allowed/Blocked | [Action] |
| Googlebot | Googlebot | Allowed/Blocked | [Action] |
[Continue for all AI crawlers]

## Critical Issues (fix immediately)
[List with specific page URLs and what is wrong]

## Warnings (fix this month)
[List with details]

## Recommendations (optimize this quarter)
[List with details]

## Agent-Readiness Signals (non-scoring)

### RFC 8288 Link Headers (Service Discovery)

**Status:** Present / Absent / Not Applicable


| Relation Type | URL | Meaning |
|---|---|---|
| api-catalog | /.well-known/api-catalog | Machine-readable index of available APIs |
| mcp-server-card | /.well-known/mcp.json | MCP server capability declaration |

AI agents and API clients can discover your services without parsing HTML.


**Informational Recommendation:** This site has API/developer-oriented content but no `Link:` headers advertising discoverable services.

Example: `Link: </.well-known/api-catalog>; rel="api-catalog"`

Relevant for: sites with public APIs, OpenAPI docs, or MCP server integrations.
Reference: RFC 8288, RFC 9609.



### Markdown Content Negotiation

**Status:** Supported / Not Supported
**Test:** GET [url] with `Accept: text/markdown`
**Response Content-Type:** [value]


This site serves clean Markdown to AI agents on request. AI crawlers that support content negotiation receive formatted text without HTML boilerplate.


**Forward-Looking Recommendation:** Cloudflare Workers/Pages sites can enable Markdown content negotiation with a one-line configuration change. When an AI agent sends `Accept: text/markdown`, the server responds with clean Markdown instead of HTML.

- Currently Cloudflare-specific
- Relevant for: sites already on Cloudflare infrastructure
- Other CDNs and frameworks expected to adopt this pattern as AI agent traffic grows

## Detailed Findings
[Per-category breakdown with evidence]