如何在自己的网站上实际做 GEO？

我们为客户做 GEO，也在自己的网站上使用同样的方法。这篇指南记录一次实际工作中的发现、修改与验证，所有例子都来自本站。

get-geo.ai 从上线起就采用服务端渲染，配置了带 hreflang 的 9 种语言版本、Schema.org JSON-LD、先回答问题再展开的页面结构，以及 llms.txt。不过，检查仍发现了一个从页面外观上看不出来的问题。

网站实际运行在 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 本身并不重要。关键是只保留一个主版本，另一个重定向到它。网站实际地址与 canonical、内链等信号保持一致，可以减少爬虫的额外请求。

诊断由一个 AI 智能体执行，它的清单里有一条：“确认 apex 的 A 记录指向 76.76.21.21”。查询真实 DNS 却显示另一番景象：域名解析到 216.198.79.1——Vercel 的新基础设施，托管商是在模型训练数据截止之后迁移过去的。

这条建议已经过时，模型引用的仍是旧配置。

这个例子提醒我们，模型给出的技术建议需要用系统的当前状态来核对。一次 DNS 查询只需一秒，就能发现配置已经变化。对 GEO 来说，道理相同：只有提供可访问、及时更新的内容，模型才有机会读取正确的信息。

切换主域名后，GSC 里旧的资源（https://www.get-geo.ai/ 的 URL 前缀资源）失去了意义：它只覆盖 www，而页面正在迁往 apex。

我们改用域名资源（get-geo.ai，不带协议和子域名），一次覆盖 apex、www、http、https 和所有子域名。域名资源需要通过 DNS TXT 记录验证。此前加入 DNS 的 google-site-verification 令牌与账号关联，因此这次验证直接通过。随后，我们提交了使用 apex 地址的 sitemap：https://get-geo.ai/sitemap.xml。

经验：刚提交的 sitemap 在 GSC 里经常挂着红色的“无法获取”状态和零个页面。这不是错误，而是首次处理前的占位符——处理是异步的，可能需要一两天。慌张之前先查三件事：文件能否通过直接 URL 打开；里面每个 <loc> 是否指向正确的主机；robots.txt 里是否有 Sitemap: 一行。三条都没问题——那就只管等。

我们的 sitemap 不只包含页面。它列出了 llms.txt、llms-full.txt 以及所有语言版本的 llms-full/{locale}——带 lastmod 日期和优先级。

原因：AI 爬虫（GPTBot、ClaudeBot、PerplexityBot）已被观察到会读取 sitemap，显式列出 LLM 文件等于给它们一条直达网站机器可读版本的路线——而不用指望抓取器知道 /llms.txt 这个约定。

sitemap 应准确列出希望机器发现的内容，并使用反映实际更新情况的 lastmod 日期。

按照约定，两个文件分工不同：llms.txt 是带链接的目录；llms-full.txt 是给不点链接的系统准备的完整内容。我们的 full 版本起初只有着陆页：指南——我们最值得被引用的资产——只能一页一页地访问。

我们做了什么：

半天的工作，没有新增一页内容——但是：

GEO 的技术工作首先要让内容能够被发现和读取。至于是否值得引用，仍取决于内容本身。