热点

AI SCORE

技术实践2026-08-03 16:39

AI 搜索优化框架：审计 360 站点的四层模型

dev.to · AI#SEO#AI搜索#框架方法

Editor brief · 编辑速览

基于 360 域名审计的 AI 搜索引擎优化框架（Access/Orientation/Understanding/Quotability），帮助开发者评估网站对生成式搜索的就绪度。

文章思维导图

Knowledge map

拖拽缩放

Full translation

完整中文译文

我审查了 360 个网站后总结的四层 AI 搜索就绪模型

我对 360 个域名进行了一份结构化的 AI 搜索就绪框架审查。平均得分是 100 分中的 54.1 分。只有 24.7% 达到了"良好"或以上。第一个完美的 100/100 直到 2026 年 7 月才出现。

这篇文章介绍了我使用的四层模型——Access（可达性）、Orientation（定向）、Understanding（理解）、Quotability（可引用性）——每层都有真实代码示例、基准数据和我反复看到的基础架构错误。

如果你是开发人员或技术负责人，这是在市场团队问为什么 ChatGPT 不引用你的文档之前，需要操作化实施的框架。

核心论点：AI 搜索是选择问题，不是排名问题

传统 SEO 是排名问题：优化页面、爬升位置、竞争搜索结果页上的插槽。

生成式搜索——ChatGPT、Perplexity、Google AI Overviews——是一个选择问题。模型接收查询，决定咨询哪些源，提取段落，要么引用源，要么改写而不署名。没有第二页。你要么被引用，要么隐形不见。

被选中需要四件事按顺序工作：

Access——AI 爬虫可以到达你的内容

Orientation——它能在你的网站上找到重要的东西

Understanding——它能解析你的组织和页面讲的是什么

Quotability——它能提取一个独立的段落来引用

关键原则：先修复可达性再修复 schema，先修复 schema 再修复内容。顺序错误 = 白费功夫。我反复看到这个模式——团队在重写内容以"AI 优化"的同时，他们的 robots.txt 却封禁了 GPTBot。

下面逐层来看，附带代码。

第 1 层：可达性——AI 爬虫能到达你吗？

可达性是 robots.txt、静态 HTML 交付、服务器响应行为和渲染。这是最不起眼的层，也是最常见的故障点。

至少有 11 个 AI 爬虫在主动索引网络。每个都有不同的 user-agent 令牌：

基准测试发现每个网站允许平均 23.2 个机器人——但这个平均数掩盖了大量网站恰好封禁他们需要的爬虫的现象。

robots.txt：允许 AI 爬虫访问

这是一个最小化的 robots.txt，显式允许主要 AI 爬虫访问公开内容，同时锁定你的私有路径：

# Allow major AI crawlers access to public content
User-agent: GPTBot
Allow: /

User-agent: OAI-SearchBot
Allow: /

User-agent: PerplexityBot
Allow: /

User-agent: ClaudeBot
Allow: /

User-agent: Claude-SearchBot
Allow: /

User-agent: Googlebot
Allow: /

User-agent: Google-Extended
Allow: /

User-agent: Applebot
Allow: /

User-agent: CCBot
Allow: /

User-agent: Bytespider
Allow: /

User-agent: Diffbot
Allow: /

# Block private/admin paths from all crawlers
User-agent: *
Disallow: /admin/
Disallow: /private/
Disallow: /api/internal/

# Sitemap
Sitemap: https://example.com/sitemap.xml

一个更微妙的可达性问题：客户端渲染。如果你的网站是一个 SPA，在初始 HTML 响应时返回空的 <div id="root"></div>，许多 AI 爬虫会看到什么都没有。GPTBot 和 PerplexityBot 不可靠地执行 JavaScript。他们读的是静态 HTML。

如果你的内容藏在 React/Vue/Svelte 水合步骤后面，你需要：

SSR（服务端渲染）或 SSG（静态站点生成），这样 HTML 包含内容，或
一个预渲染层，向机器人 user-agent 提供缓存的 HTML

检查爬虫实际看到的东西：

curl -A "GPTBot" https://example.com | grep -i "your main heading"

如果什么都没有返回，你的内容对爬虫是隐形的。在其他一切之前修复这个。

第 2 层：定向——它能找到重要的东西吗？

一旦爬虫到达你的网站，它需要知道什么是重要的。定向涵盖 llms.txt、sitemap、RSS 提要和优先级 URL 信号。

这是整个审查中表现最差的类别：

AI Discovery adoption（AI 发现采用率）：17.5%

AI Discovery efficiency（AI 发现效率）：10%

llms.txt 的数字讲述了一个具体的故事：

llms.txt adoption（采用率）：54.2%——但从 6 月的 58.3% 下降。网站在移除它。

Full llms.txt（完整 llms.txt）：仅 26.9%——其余的是部分或格式错误的。

一个破损的 llms.txt 比没有更糟。它向模型发送了一份缺少街道的地图。

llms.txt 最小化示例

llms.txt 标准是你网站根目录下的纯文本文件，给 AI 爬虫提供结构化的内容摘要：

# Example Company

> Example Company builds developer infrastructure for AI-powered search.

## Docs
- [Getting Started](https://example.com/docs/getting-started): Quick start guide
- [API Reference](https://example.com/docs/api): Full REST API documentation
- [SDK Guide](https://example.com/docs/sdk): SDK installation and usage

## Product
- [Features](https://example.com/features): Feature overview and comparison
- [Pricing](https://example.com/pricing): Pricing tiers and FAQ

## Blog
- [Blog Index](https://example.com/blog): Engineering and product blog

## Optional
- [About](https://example.com/about): Company background and team
- [Contact](https://example.com/contact): Contact information

# 行是网站标题
> 行是一句话摘要
## 分节组织链接
每个链接是 - [Title](URL): Description ——描述很重要，它给模型关于那个 URL 是什么的上下文
不要列出所有博文。列出回答"这个网站是什么？"和"它做什么？"的页面。

第 3 层：理解——它能解析你是什么吗？

爬虫已经到达你的网站并找到了你的优先内容。现在它需要结构化数据来理解实体：你是谁、你的网站做什么、你的页面回答什么问题。

理解是 Schema.org JSON-LD、元标签和实体信号。

Schema adoption（Schema 采用）：75.6%——从 6 月的 70.1% 上升。趋势向好。

Organization schema（组织 schema）：52.2%——勉强一半的网站告诉爬虫他们是谁。

WebSite schema：58.9%

FAQ schema：18.1%——从 13.2% 上升，但对于一个直接为问答提取设计的 schema 类型来说，采用率仍然低得惊人。

"有一些 schema"（75.6%）和"有对 AI 引用重要的 schema 类型"（52% / 59% / 18%）之间的差距是大多数网站失利的地方。

Organization + WebSite JSON-LD 模板

把这个放在你主页的 <head> 中。用你的真实数据替换这些值。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Example Company",
      "url": "https://example.com",
      "logo": "https://example.com/logo.png",
      "description": "Example Company builds developer infrastructure for AI-powered search.",
      "sameAs": [
        "https://github.com/example",
        "https://x.com/example",
        "https://www.linkedin.com/company/example"
      ],
      "contactPoint": {
        "@type": "ContactPoint",
        "contactType": "support",
        "email": "support@example.com",
        "url": "https://example.com/contact"
      }
    },
    {
      "@type": "WebSite",
      "@id": "https://example.com/#website",
      "url": "https://example.com",
      "name": "Example Company",
      "description": "Developer infrastructure for AI-powered search.",
      "publisher": { "@id": "https://example.com/#organization" },
      "potentialAction": {
        "@type": "SearchAction",
        "target": {
          "@type": "EntryPoint",
          "urlTemplate": "https://example.com/search?q={search_term_string}"
        },
        "query-input": "required name=search_term_string"
      }
    }
  ]
}
</script>

@graph 结构让你在一个块中声明多个实体（Organization + WebSite）并用 @id 交叉引用它们。这是你告诉模型"这个组织发布这个网站"的方式——对实体消歧来说很重要的关系。

对于 FAQ 页面，在相关页面上添加：

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "What is AI search readiness?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "AI search readiness is the degree to which a website can be discovered, understood, and cited by generative AI systems like ChatGPT, Perplexity, and Google AI Overviews."
      }
    },
    {
      "@type": "Question",
      "name": "How is GEO different from SEO?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "SEO optimizes for ranking positions on a search results page. GEO optimizes for selection and citation by generative models that synthesize answers from multiple sources."
      }
    }
  ]
}
</script>

FAQ schema 是你通向问答提取的直接途径。当模型看到 FAQPage 和 Question、acceptedAnswer 对时，它可以逐字拉出那些答案。这就是为什么 18.1% 的采用率数字这么令人沮丧——它是最直接关系到被引用的 schema 类型，而 82% 的网站没有它。

第 4 层：可引用性——它能提取自包含的段落吗？

最后一层是内容架构。模型只有在你的内容结构化为可引用时才能干净地引用你：直接答案、底线优先（BLUF）、短自包含段落。

这是大多数团队跳过的层——他们修复 robots.txt、添加 llms.txt、实施 schema，然后让他们的内容保持为埋藏答案在第五段的 2,000 字叙述。

之前：叙述结构（难以引用）

# How Our API Handles Rate Limiting

When we first launched our API in 2023, we didn't have any rate limiting
in place. After a few incidents where a single client overwhelmed the
auth service, we realized we needed a more robust approach. We
experimented with token bucket algorithms, considered sliding window
loggers, and eventually settled on a fixed window counter approach
combined with exponential backoff. Here's how it works...

[800 more words of context, history, and implementation details]

读这个的模型必须从散乱的句子中合成答案。它很可能不署名改写，或为了更干净的源而跳过这个源。

之后：BLUF 结构（易于引用）

# How Our API Handles Rate Limiting

Our API enforces rate limiting using a **fixed window counter** with
exponential backoff. The default limit is **100 requests per minute**
per API key. When the limit is exceeded, the API returns HTTP 429 with
a `Retry-After` header indicating the wait time in seconds.

## How It Works

Rate limits are calculated per API key, not per IP address. Each
request increments a counter that resets at the start of each
60-second window. When the counter exceeds 100, subsequent requests
receive a 429 response until the window resets.

## Handling 429 Responses

Clients should implement exponential backoff: wait 1 second before
the first retry, then double the wait on each subsequent retry, up to
a maximum of 60 seconds. The `Retry-After` header provides the exact
wait time for the current window.

第一段是自包含的。模型可以将它作为直接引用提取："Our API enforces rate limiting using a fixed window counter with exponential backoff. The default limit is 100 requests per minute per API key."（我们的 API 使用固定时间窗口计数器加指数退避强制速率限制。默认限制是每个 API key 每分钟 100 个请求。）它在完整页面的背景之外也有意义。这就是可引用性。

规则：每个页面都应该以其核心问题的独立答案开始。细节在下方。答案先来。

关联数据：什么真正推动分数

审查不仅测量了采用，还测量了影响。关联性是四层模型最强有力的证据：

有 llms.txt 的网站比没有的网站高 20 分。有 schema 的网站高 28 分。这些不是魔法——llms.txt 文件不会修复你的服务器。但他们表明投资于定向和理解信号的网站是那些在整个委会表现良好的网站。这些层复合效应。

常见基础架构错误

意外在 robots.txt 中封禁 AI 爬虫。一个 CMS、安全插件或样板模板为 GPTBot 添加了 Disallow: /，没人审查。用 curl https://example.com/robots.txt 检查你的 robots.txt——实际读一遍。
客户端渲染无预渲染后备。你的 SPA 返回一个空壳。AI 爬虫看不到任何东西。要么使用 SSR/SSG，要么向机器人 user-agent 提供预渲染的 HTML。用 curl -A "GPTBot" https://example.com 验证。
部分 llms.txt。带有破损链接、缺失部分或仅列出主页的 llms.txt 比没有 llms.txt 更糟。采用率（54.2%）和完整实现（26.9%）之间的 27 点差距意味着那里一半的 llms.txt 文件是破损的地图。
仅使用通用 schema。博文上的 Article schema 是起点。驱动 AI 引用的 schema 类型是 Organization（你是谁？）、WebSite（这个网站是什么？）和 FAQPage（答案是什么？）。大多数网站没有这些。
在可达性之前修复内容。我看到团队花费数周为"AI 优化"重写内容，同时他们的 robots.txt 封禁了所有 AI 爬虫。顺序是不可协商的：Access → Orientation → Understanding → Quotability。跳过往前，你在破损的基础上构建。

基准数据的现状

360 个域名审查。平均得分 54.1/100。75.3% 处于基础或关键水平。第一个 100/100 在 7 月出现。

传统 SEO 和 GEO 之间的差距是可测量的和结构性的。这不是关于关键词或反向链接——这是关于 AI 爬虫是否能到达你的内容、定向自己、理解你的实体和提取干净的段落。四层，按顺序，每一层使能下一层。

对开发人员来说好消息：每一层都可以通过基础架构改变来修复。robots.txt 是一个文本文件。llms.txt 是一个文本文件。JSON-LD 是一个脚本标签。BLUF 是一个编辑模式。这些都不需要市场营销机构。它需要一个了解框架的工程师。

完整的手册是 160 页——15 章深入覆盖所有四层、11 个 AI 爬虫及其 user-agent 令牌、12 个 schema 类型及其 JSON-LD 模板、8 个提示注入攻击向量和一个引用测量工作流。免费下载地址：geoready.dev/geo-readiness-manual/