// 指南
如何在自己的网站上实际做 GEO？
更新于: 2026-08-03
// 简短答案
技术侧的 GEO 是卫生习惯，不是魔法。在 get-geo.ai，半天工作让所有信号指向同一主机，让 AI 抓取器第一次请求就能拿到内容，把 Search Console 换成域名资源，并把完整指南语料写入按语言分拆、与页面同源自动更新的 llms-full 文件。内容决定你会不会被引用；工程决定有没有人读得到足以引用你。
起点：一个看起来没毛病的网站
我们以 GEO 为业——所以我们自己的网站必须是标杆实现。这份指南不是理论，而是真实一个工作日的操作实录：发现了什么、怎么修的、验证了什么。所有例子都来自这个网站本身。
get-geo.ai 从第一天起就「照教科书」搭建：服务端渲染、带 hreflang 的 8 种语言、Schema.org JSON-LD、answer-first 结构、llms.txt。还能有什么可修的？审计找到了一个肉眼看不见的问题。
发现一：apex 与 www 的冲突
网站实际运行在 www.get-geo.ai 上，而所有信号——canonical、sitemap、hreflang、JSON-LD、llms.txt——都指向 get-geo.ai（apex，即不带子域名的裸域名）。与此同时，apex 又用 308 重定向跳回 www。
结果形成了一个环：「规范版本是 apex」→ apex 重定向到 www → www 又声明「规范版本是 apex」。传统的 Google 爬虫扛得住这一套，只是白白消耗抓取预算。而 AI 抓取器往往扛不住：许多抓取器每页只有一两次请求的预算，有些穿不过重定向，根本到不了内容。对 GEO 来说这是致命的：抓取器看不见的文件，就等于不存在的文件。
修复：在托管平台（Vercel）把 apex 设为主域名，www 改为 308 指向 apex。一个开关——所有信号立刻一致了：实际地址、canonical、内链、sitemap 和 llms.txt 现在都指向同一处。
经验：选 apex 还是 www 并不重要。重要的是网站只运行在其中一个上，另一个坚决重定向过去。「网站住在哪」和「信号指向哪」之间的任何偏差，都是每次爬虫来访都要缴的税。
发现二：AI 智能体的过时建议
诊断由一个 AI 智能体执行，它的清单里有一条：「确认 apex 的 A 记录指向 76.76.21.21」。查询真实 DNS 却显示另一番景象：域名解析到 216.198.79.1——Vercel 的新基础设施，托管商是在模型训练数据截止之后迁移过去的。
这条建议无害——只是过期了。模型在自信地引用过去。
经验：没有验证工具的 AI 智能体是记忆，不是知识。模型给出的任何技术建议，都要和系统的实时状态核对：一次 DNS 查询只花一秒，就能了结疑问。顺带说一句，这也正是 GEO 本身的核心原则：模型只能根据它读到的东西作答——这正是我们要把内容做成可读的原因。
第三步：Google Search Console——域名资源
切换主域名后，GSC 里旧的资源（https://www.get-geo.ai/ 的 URL 前缀资源）失去了意义：它只覆盖 www，而页面正在迁往 apex。
正确的配置是域名资源（get-geo.ai，不带协议和子域名）：它一次性覆盖 apex、www、http、https 和所有子域名。它只能通过 DNS TXT 记录验证——这里有个愉快的细节：google-site-verification 令牌绑定的是账号，而不是验证方式，所以早前加进 DNS 的那条记录让验证瞬间通过。然后——用 apex 地址提交 sitemap：https://get-geo.ai/sitemap.xml。
经验：刚提交的 sitemap 在 GSC 里经常挂着红色的「无法获取」状态和零个页面。这不是错误，而是首次处理前的占位符——处理是异步的，可能需要一两天。慌张之前先查三件事：文件能否通过直接 URL 打开；里面每个 <loc> 是否指向正确的主机；robots.txt 里是否有 Sitemap: 一行。三条都没问题——那就只管等。
第四步：把 sitemap 当 GEO 工具，而不是走过场
我们的 sitemap 不只包含页面。它列出了 llms.txt、llms-full.txt 以及所有语言版本的 llms-full/{locale}——带 lastmod 日期和优先级。
原因：AI 爬虫（GPTBot、ClaudeBot、PerplexityBot）已被观察到会读取 sitemap，显式列出 LLM 文件等于给它们一条直达网站机器可读版本的路线——而不用指望抓取器知道 /llms.txt 这个约定。
经验：把 sitemap 当成给机器看的菜单，而不是待勾选的复选框。你想让 AI 系统看到的一切，都应该列在里面，配上诚实的 lastmod 日期。
第五步：llms-full——完整内容，而不是目录
按照约定，两个文件分工不同：llms.txt 是带链接的目录；llms-full.txt 是给不点链接的系统准备的完整内容。我们的 full 版本起初只有着陆页：指南——我们最值得被引用的资产——只能一页一页地访问。
我们做了什么：
- 按语言分文件。指南全文放进 llms-full/{locale}，每个文件完整地使用一种语言。把 8 种语言塞进一个文件，等于把任何具体查询的有效信息密度稀释八倍。
- 每个标题下放 URL。文件内每篇指南以标题开头，规范 URL 紧随其下——这样模型引用文本时可以指向页面，而不是 txt 文件本身。
- 从统一注册表自动生成。这些文件与指南页面出自同一数据源。新指南一次操作就同时进入网站、sitemap 和 llms-full。手工同步一个月内必死——我们干脆没开这个头。
- 带体面降级的上限。文件有大小上限；超限时不做无声截断，而是附上未收录指南的清单和链接。
- 来自意外之处的一课：最初 100 KB 的上限差点被一种文字撑破。Devanagari（印地语）在 UTF-8 中每字符占 3 字节，拉丁字母只占 1 字节——印地语文件冲到 85 KB 时，英语文件才一半重。我们把上限提到了 200 KB。如果你的网站是多语言的，做预算时要把文字系统算进去：CJK 和印度系文字要重好几倍。
一天的收成
半天的工作，没有新增一页内容——但是：
- 网站的每个信号都指向同一个主机，没有环路和多余的重定向；
- 预算只有一次请求的 AI 抓取器第一次尝试就能拿到内容；
- GSC 收集整个域名的数据，而不是单个子域名；
- 8 种语言的完整指南语料，机器每种语言读一个文件即可；
- 发布新指南会自动更新网站、sitemap 和 llms-full。
卫生习惯，不是魔法
这就是 GEO 的技术部分：不是魔法，是卫生习惯。内容决定你会不会被引用，技术决定有没有人能读到你的内容。
相关问题
apex 与 www 对 GEO 重要吗？
选择本身并不重要。重要的是网站只运行在一个主机上，且所有信号——canonical、sitemap、hreflang、JSON-LD、llms.txt——都指向那里，另一个主机名做硬重定向。apex 与 www 之间的环路会消耗抓取预算，也常常拦住只发一两次请求的 AI 抓取器。
应该在 Google Search Console 使用域名资源吗？
是的，如果你同时关心 apex 和 www（或 http 和 https）。域名资源一次性覆盖全部，并通过 DNS TXT 验证。只挂在 www 上的 URL 前缀资源，一旦主域名迁到 apex 就会失明。
为什么要把 llms.txt 写进 sitemap？
AI 爬虫已被观察到会读取 sitemap。列出 llms.txt 和按语言分拆的 llms-full 文件，等于给它们直达机器可读语料的路线，而不必指望每个抓取器都知道 /llms.txt 约定。
为什么用按语言的 llms-full，而不是一个多语言大文件？
把八种语言塞进一个文件，会把任何具体查询的有效密度稀释八倍。每种语言一个文件能保持语料密度，在每篇指南标题下放入规范 URL，并且可以从与 HTML 页面相同的注册表生成。