技术 SEO 与 GEO：打造快速、可被搜索和 AI 发现网站的完整指南

请根据本文中的每一项相关检查，对我的网站进行一次技术 SEO 和 GEO 审计。
每一项请标记为“通过”“未通过”或“无法验证”，附上判断依据，
并按照影响大小排列需要修复的问题。暂时不要修改任何内容。

这份技术 SEO 清单，来自我们搭建 WeBreeze 的过程。WeBreeze 是一个 AI 智能体平台，它把过去 SEO 和 GEO 机构要做的大量工作自动化了：研究、内容创作、优化、发布和衡量。我们起初把这些设置用在了客户的博客上，但其实它适用于几乎所有公开网站。最后一节会专门讲博客特有的几个选择。

过去大约十年里，“被找到”只意味着一件事：在 Google 上排名。这依然成立，但已经不是全部了。越来越多的人提问之后，得到的是一份由 AI 综合出来的答案，而不是一串蓝色链接。如果你的网站没有准备好，让这些系统能抓取、理解并信任它，那在这个几年前几乎还不存在的发现渠道里，你就是完全隐形的。

这项工作有好几个高度重叠的名字：AI 搜索优化；GEO，即生成式引擎优化（Generative Engine Optimization）；AEO，即答案引擎优化（Answer Engine Optimization）；有时也叫 LLMO，即大语言模型优化（Large Language Model Optimization）。在本指南里，技术 GEO 指的是让你的网站能被 AI 答案引擎访问和理解，然后衡量它们会不会提到并引用你。

好消息是，大部分技术 SEO 和 GEO 的设置是共通的。Google 确认了，面向搜索的基础 SEO 指南同样适用于它的生成式 AI 搜索功能。同一套干净的基础，往往也能帮到其他答案引擎——而且很多东西（更快的页面、清晰的标题、可访问的标记）本身就能让网站对访客更友好。这些工作大多一次搞定：好好配置一次，之后发布的每个页面都会自动继承。

目录

我们会逐项展开：先讲大白话，再在需要的地方给出代码，并且把“有文档依据的做法”和“仍属于实验范畴的 GEO 押注”分清楚。WeBreeze 会自动把这套基础应用到它智能体发布的内容上，不过这份清单同样适用于产品站、企业官网、文档、目录以及其他公开网站。

第 1 步 — 先把每个页面的基础做好

Canonical URL

每个页面应该只有一个首选地址。如果没有 canonical，尾部的斜杠、www 变体、跟踪参数都可能被当成不同页面，信号就分散了。Google 的 canonical 指南把重定向和 rel="canonical" 都看成强信号。

选一个主机名，让裸域名和 www 域名都能解析，然后把重复的那个用重定向导到主版本上。此外，在每个可索引页面里输出一个绝对地址的 canonical。WeBreeze 会自动为智能体发布的内容生成这些 canonical。

<h1> 标签

每个页面都应该有一个清晰的 <h1>。这不是 Google 的硬性要求，而是一个便于维护的约定，但它能消除歧义。CMS 里有个常见问题：模板中的标题和正文开头的 Markdown 标题都可能被渲染成 <h1>；WeBreeze 在渲染时会自动检测，并把正文里那个标题降级。

Title 与 Meta Description

为每个重要页面设置一个独立的 <title> 和 meta description。记得检查最终渲染出的 HTML，不要只盯着 CMS 后台填写的字段。Google 会用算法生成标题链接，也可能改写摘要，所以把这两者看成强信号，不要指望它们在搜索结果里原样出现。

语义化 HTML

按标签本来的用途去用 <main>、<nav> 和各级标题，当页面确实包含文章内容时，就用 <article>。这么做最直接也最确切的收益是更好的无障碍访问。Google 的 AI 指南也建议尽量使用语义化 HTML；一个完全靠 <div> 堆砌的页面，无论对人还是机器来说，都更难理解。

第 2 步 — 正确支持多语言

Google 官方推荐每种语言使用独立的 URL，比如 /en/services 和 /zh/services，并用 hreflang 把它们关联起来。带跳转的语言切换菜单没问题；但如果在同一个 URL 上用 JavaScript 实时替换文字内容，爬虫很可能抓不到所有翻译版本。

你可以把默认语言放在根路径，其他语言用子目录前缀，也可以每种语言都加前缀。两种做法都行。WeBreeze 选择给每种语言加前缀，因为这样 URL 结构、canonical、sitemap 和 hreflang 的逻辑更统一，维护起来也更省事。

<link rel="alternate" hreflang="en"        href="https://example.com/en/services">
<link rel="alternate" hreflang="zh"        href="https://example.com/zh/services">
<link rel="alternate" hreflang="x-default" href="https://example.com/en/services">

第 3 步 — 帮助机器理解页面（结构化数据）

到目前为止，我们做的都是在帮机器读懂页面。结构化数据则能让它理解页面里的实体：这是一个网站、这是背后的公司，这个页面到底是产品、文章、活动、本地商家，还是其他类型。

你需要把这些信息以 JSON-LD 的格式放进页面的 head。访客看不见它。Google 推荐 JSON-LD，并且说明了结构化数据如何带来富媒体搜索结果；对 AI 答案引擎来说，这么做应该有好处，但尚未证实。请选用最贴合页面实际情况的 Schema.org 类型，并遵守 Google 的规则：标记出来的声明必须有可见内容来支撑。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "WebSite",
      "@id": "https://example.com/#website",
      "url": "https://example.com/",
      "name": "Example Co"
    },
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Example Co",
      "url": "https://example.com/"
    }
  ]
}
</script>

可选：用 sameAs 连接你的资料页

sameAs 用来列出你机构的官方资料页，帮助搜索引擎把你的品牌和名字相似的其他品牌区分开。只添加你确实掌控的那些资料页，最好是会反过来链回你网站的那种。这件事成本不高，但优先级也比较低：它不会凭空创造出权威度或 Knowledge Panel。如果你还没有成熟的外部资料页，完全可以先不写。

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "Example Co",
  "url": "https://example.com",
  "sameAs": [
    "https://www.linkedin.com/company/example",
    "https://www.crunchbase.com/organization/example"
  ]
}

第 4 步 — 让 AI 答案引擎找到你的网站

这一节将 GEO（AI 爬虫访问）和经典 SEO（Bing、Google、IndexNow）整合在一起讨论，因为两者之间仍有不少交叉。

AI 爬虫与 robots.txt

robots.txt 用来告诉爬虫哪些内容允许抓取。按用途看，这些机器人可以分成几类：

• 答案爬虫：OAI-SearchBot、PerplexityBot、Claude-SearchBot。要是希望内容直接出现在 AI 答案里，就放行它们。
• 用户触发的抓取器：ChatGPT-User、Claude-User。它们只有在用户主动请求时，才会去抓取某个页面。
• 训练爬虫：GPTBot、ClaudeBot、CCBot。是否允许它们用于模型训练，是一个独立的政策选项；它不会影响你当前的内容能否被引用。

以上机器人的名称和用途，引自各发布方当前的文档：OpenAI、Anthropic 和 Perplexity。请定期检查，爬虫政策可能会调整。

WeBreeze 对于智能体发布的公开内容，会放行答案爬虫；同时，是否允许训练爬虫，会作为独立的选项单独控制。

User-agent: *
Allow: /

# AI 答案引擎
User-agent: OAI-SearchBot
User-agent: PerplexityBot
User-agent: Claude-SearchBot
Allow: /

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

llms.txt

llms.txt 是放在网站根目录的纯文本文件，以 AI 友好的方式列出你的重要页面——你可以把它当成写给语言模型看的 Sitemap。

# Example Co
> 面向 X 的软件与服务。

## 重要页面
- [Product](https://example.com/product)：它做什么、面向谁
- [Documentation](https://example.com/docs)：安装与参考文档

llms.txt 还是一份仍在发展中的约定，并非已被验证的排名因素。Google 明确表示，在搜索可见性和排名方面会忽略 llms.txt。WeBreeze 之所以会提供，是因为维护成本极低，且其他系统未来可能会采用；不妨把它当作一次实验。

Google 与 Bing 的提交方式（IndexNow）

Bing 依然是扩大 AI 发现机会的一个低成本对冲，因为微软提到 Copilot Search 基于 Bing 的搜索结果。它的发布流程与 Google 有所不同：

• Bing 和参与的引擎：当公开 URL 发生变化时，通过 IndexNow 主动通知它们。这只是一种发现请求，不保证一定会被收录。
• Google：验证 Search Console 并提交 Sitemap。Google 的 Indexing API 仅适用于符合资格的职位招聘和直播页面，不能用于普通页面。

WeBreeze 在智能体创建或更新符合条件的内容时，会发布 Sitemap 并发送 IndexNow 通知。客户可以自行连接 Search Console 来查看 Google 的数据。

第 5 步 — 让网站真正快起来（速度与缓存）

页面一慢，访客、转化、Core Web Vitals 和爬虫抓取都会受拖累。速度算不上什么排名旋钮，可过不了速度这一关，就进不了竞争的场子。

边缘缓存

边缘缓存是把公开页面的现成副本放在离访客更近的地方，而不是每次都回到源站重新构建。这样一来就消除了服务器延迟，不过图片、脚本和页面体积依然会拖慢体验。

WeBreeze 会对智能体发布的公开内容做边缘缓存，每次更新后就清掉。我们靠验证行为来保证效果，而不是靠信任配置：

想要这个收益，并不需要把网站改成静态生成器。动态网站只要把边缘缓存配对了，缓存命中时拿到的就是同一份现成响应。

绝不能缓存什么

只缓存那些对所有人公开且完全相同的内容。只要响应会因登录、Session 或 Token 而变化，就必须保持动态。

光看一个 200 状态码还不够：个性化页面和 soft 404 都可能返回 200。WeBreeze 还会让答案爬虫绕过缓存，确保爬虫统计准确；机器人和真人拿到的 HTML 完全一样。

把图片放到 CDN

把较大的上传图片或生成图片交给 CDN，并按访客实际需要的尺寸缩放。那些已经很快、带指纹的品牌素材就别动了；搬动它们只会增加复杂度，解决不了任何瓶颈。

第 6 步 — Sitemap、错误页面与 Search Console

XML Sitemap

Sitemap 是一份机器可读的页面清单，列出你希望被找到的页面，这样爬虫就不用靠运气来发现它们了。每个公开网站都应该有一份，并且要自动保持最新。Google 的 Sitemap 指南里也讲了多语言网站该怎么处理语言替代版本。

<url>
  <loc>https://example.com/en/services</loc>
  <lastmod>2026-07-01</lastmod>
  <xhtml:link rel="alternate" hreflang="en" href="https://example.com/en/services"/>
  <xhtml:link rel="alternate" hreflang="zh" href="https://example.com/zh/services"/>
  <xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/en/services"/>
</url>

正确处理 404

对于不存在的页面，应该返回 404（如果确定已经永久删除了，就用 410）。如果表面上显示“页面找不到”，但 HTTP 状态码却是 200，这就是 soft 404，这类页面会像幽灵一样赖在索引里不走；而 403 会让人误以为页面存在，只是你没权限访问。检查时一定要看真实的 HTTP 状态码，不能光看页面上显示了什么。

Search Console 与 Bing Webmaster

这两个免费平台能让你看到搜索词、索引状态和抓取问题：

• Google Search Console：验证网站、提交 Sitemap，然后重点看索引覆盖和搜索查询。
• Bing Webmaster Tools：同样验证网站，并结合 IndexNow 一起用。

WeBreeze 会自动搞定技术配置和报告接入，如果客户想直接看原始搜索数据，再把自有资源绑定上去就行。

第 7 步 — 衡量你的 AI 搜索可见性

1. 手工检查 AI 对话

先想想潜在客户真的会在 ChatGPT、Perplexity 或 Gemini 里问什么。用中立、探索式的问题，比如“做 X 最好的工具有哪些？”或者“一家公司要怎么解决 Y？”。别提自己的品牌、别贴链接，也别问引擎“为什么没有推荐我们”——这类问题会诱导答案。

消费者端的结果每次都可能不一样。比如 ChatGPT Search 在生成回答时可能会用到记忆和位置信息，别的产品也各有各的个性化方式。为了让对比更干净：

• 每次测试都用全新或临时对话；能关掉记忆或个性化就关掉。
• 在每个引擎里用完全一样的提示词，记下日期、答案、引用来源、竞争对手，以及你的品牌出现在哪里、怎么出现的。
• 经验之谈：每个提示词在每个引擎至少跑三次。想要更可靠的基线，就用五个互不相关的对话。
• 定期重复——小网站每月一次，竞争激烈或变化快的话题每周一次。

一次给力的回答算不上可见性，那只是一个样本。真正要看的是在不同引擎、多次运行后，有没有被反复提到、反复引用。

2. 查看 Google 的免费归因与可见性报告

被引用当然好，但被点击才是更强的信号。GA4 默认的 AI Assistants 渠道会把来自 ChatGPT、Gemini、DeepSeek、Copilot、Grok 等来源的访问归到一起。你进入 Acquisition → Traffic acquisition，选择 AI Assistants 渠道，再叠加上 session source、landing page 这些维度，就能看到是哪个助手把人带到了哪篇文章。

把这个数当成一个底线。有些 AI 点击没有 referrer，会归到 Direct 里；Google 自家的 AI Overviews 和 AI Mode 则会被归入 Organic Search。Google 还在逐步上线 Search Console 里独立的 Generative AI performance 报告，用来展示 AI Overviews 和 AI Mode 带来的展现量。GA4 衡量的是访问，而 Search Console、手工检查和监测工具是从不同角度来评估可见性。

3. 订阅自动化的可见性监测

需要跟踪的关键词一旦超过几个，手工检查就太繁琐了。付费的 AI 可见性服务能自动跑查询、保存回答，并按时间线展示提及、引用和变化趋势。截至 2026 年 7 月，本指南看到的自助套餐价格大概在每月 29–489 美元之间，具体取决于关键词数量和覆盖的引擎（Otterly 定价；Semrush 定价）。企业套餐可能会更贵。

在订阅之前，先弄清楚：这个工具调的是模型 API，还是普通用户用的聊天产品？API 的结果适合做稳定的趋势追踪，但不一定和带个性化设置的聊天结果一模一样。你要比的是长期的大方向，而不是把某一个数值当成绝对事实。

WeBreeze 为每一位客户提供引用监测。它每周在 Perplexity、OpenAI 和 Gemini 上做检查，在客户的 Reports 区域展示结果，并把引用空白反馈给内容智能体，让它们判断接下来应该去调研、更新还是创建内容。这套监测也开放成独立产品，适合只想追踪可见性、暂时还不需要整套 WeBreeze 平台的团队。

第 8 步 — 博客特有的额外设置

这一节的内容，源于我们搭建 WeBreeze 内容智能体时实际用到的博客发布层。你可以把它当作全站 SEO 清单的一个补充，而不是一套独立的体系。

博客放在哪里：子目录还是子域名？

两个常见选择是 yourdomain.com/blog（子目录）和 blog.yourdomain.com（子域名）。这两种结构都能被搜索引擎正常索引。Google 说过，它的站点多样性系统通常会把子域名视为根域名的一部分，但这并不等于承诺哪一种结构能获得排名优势。很多有经验的 SEO 从业者，还是更倾向于为新博客选子目录，因为它直接挂在已经成熟的根域名下面。不过，目前的证据还不够清晰，谈不上有保障的优势。

我常用的判断标准：如果你是从零开始，可以自由选择，那直接用子目录。要是你已经在子域名上运营着一个表现还不错的博客，那就保持现状。迁移博客，意味着要把每个 URL 都做一次 301 一对一重定向。为了那一点可能的微小收益，去折腾一个已经有排名的博客，通常划不来。

至于你现在读的 WeBreeze 官方博客，我特意选了子域名（blog.webreeze.ai）而不是子目录，就是想“吃自家的狗粮”，让这个博客跑在跟我们交付给客户一模一样的平台上。

文章页面使用 BlogPosting

文章页面可以在第 3 步所做的全站结构化数据基础上，再用 BlogPosting 进一步补充。需要包含标题、真实的发布日期和修改日期、语言、主图、作者、发布方，以及页面的 canonical URL。记得引用跟站内其他地方一样的 organization ID。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "How Virtual Doctor Visits Work",
  "datePublished": "2026-07-01",
  "dateModified": "2026-07-01",
  "inLanguage": "en",
  "image": "https://example.com/hero.jpg",
  "author": {
    "@type": "Person",
    "name": "Dr. Jane Smith",
    "url": "https://example.com/authors/jane-smith"
  },
  "publisher": {
    "@id": "https://example.com/#organization"
  },
  "mainEntityOfPage": "https://example.com/en/post"
}
</script>

在需要信任的领域，署上真实作者

对医疗、金融、法律这类对准确性要求很高的领域，要用真实的署名，以及一个展示相关资历的真实作者页面。如果文章确实经过了人工审核，就加上“审核人”这一行。Google 的《以人为本内容指南》指出，E-E-A-T 不是一个单一的排名因素，但清晰的出处和可验证的专业背景，仍然能帮助读者决定是否信任你。

FAQ 标记是可选项

如果一篇文章确实逐一回答了一组独立的问题，FAQPage 标记可以把这种结构明确地表达出来。Google 从 2026 年 5 月起，就不再在搜索结果中展示 FAQ 富媒体结果了，所以它不再能换来那种可展开的问答。它现在仅剩的价值，是让 AI 更容易抓取和提取信息。这个想法在逻辑上说得通，但目前还没有数据能证实。只在页面上本来就以可见形式呈现了问答时，才去加这个标记。千万不要为了 Schema 而硬造问题。

我踩过的一个坑：单独的 Markdown 副本

我们之前试过，在每篇 HTML 文章旁边再放一个干净的 .md 版本，方便那些喜欢纯文本的机器来读取。为了避免重复内容，就给这个副本加了 noindex——当时觉得这是个挺巧的办法。但 OpenAI 和 Anthropic 的文档里，都把 noindex 也当作一种屏蔽 AI 搜索的手段。结果就是：这个副本很可能对那几家我们原本想帮到的引擎来说，反而是不可见的。

最稳妥的办法，是干脆别提供重复的 Markdown 页面。如果你还是想留着，别随手加 noindex；改用 HTTP canonical header 来处理重复，并切实测试一下，你关心的那些爬虫到底会怎么响应。

接下来：Part II，内容篇

上面这些技术 SEO 和 GEO 的工作，大部分都属于基础设施：配置一次，后续所有页面都能自动继承。我们把这一整套检查内置到了 WeBreeze 里，这样它的 AI 智能体就可以把研究、创作、优化、发布和衡量串成一个连续的系统来完成。

Part II 要难得多：内容。光靠上面那些，并不能让一个单薄的产品页、千篇一律的服务页或内容质量不高的文章获得排名或被引用。技术配置只是给了你参赛资格；真正让你胜出的，是内容和体验——能证明你是原创，观点值得别人引用，满足搜索背后真实的意图，内部链接清晰，信息及时更新，以及让读者信任的专业能力。

除此之外，还有一个层面，比前两者都更高：来自你网站之外的权威——有其他可靠的网站链接到你、提到你。这个你没办法花一个下午就“搭”出来，它需要长期积累。它是见效最慢的杠杆之一，也往往是最有力量的。

那么，你到底该做什么？

把上面的一切变成一份待办清单，按谁负责来划分：

我们把这份清单开源成了工具。上面每一项检查都打包成了一个开源 agent skill——把它指向任意网站，它会跑完 44 项检查，输出一张表：哪些通过、哪些没过、证据是什么、怎么修。它会用 OAI-SearchBot、PerplexityBot、Claude-SearchBot 的身份去抓你的页面，所以你看到的就是答案引擎真正拿到的东西。MIT 协议，免费，不用注册。

如果你要的不只是一次性的技术 SEO 和 GEO 审计，而是想把它变成一套持续运转的内容系统，WeBreeze 就是你的 AI 智能体团队。它能把过去分散在传统 SEO 和 GEO 机构里的研究、创作、优化、发布和衡量工作全部自动化。

看一下你的网站目前处于什么水平。做一次免费扫描——输入你的网址，我们会根据这些指标给你出一份报告。或者预约一次咨询，我们一块儿梳理一下你的网站。

WeBreeze · 技术 SEO 与 GEO 完整指南：让网站更快，更易被搜索和 AI 发现 · 第一部分 · 参考资料核对日期：2026 年 7 月