三种情况要分开看

很多人把这几件事混在一起，于是处理方式也就不对了。先分类：

第一种是你想要的，所以别把它和侵权混为一谈——有人因为 AI 回答里的引用而找到你，这是引用的价值所在。

无出处的改写为什么最难处理

这是最常见的形态：内容被重新组织、换了措辞，观点和结论还是你的，但没有任何指向你的线索。

它的特点是：

• 难以举证：改写过后的文字不构成逐字复制
• 数量庞大：可能是模型生成的答案，也可能是其他站点二次加工
• 无处投诉：内容可能出现在你无法触达的渠道里

在这种情况下，追求"阻止它发生"是不现实的，能改变的是"它发生后别人能否找到你"。

让溯源变容易，比防止被抄有效

核心思路是：当有人看到被改写的内容、想确认原始出处时，能不能顺利找到你。

能做到这一点的内容，即使被大量改写，也会有一部分读者最终回流到源头。具体可以做四件事：

前三项的做法分别见《结构化数据怎么做才对 GEO 有用》与《llms.txt 完全指南》。

**一个反直觉但重要的判断：被改写传播本身不完全是坏事。**它意味着你的观点进入了更大的流通范围。真正让你损失的是"流通了但没人知道是你"——所以重点在于降低这种匿名流通的比例。

许可声明要说清楚，但别指望它能拦住谁

在页脚或文章末尾声明许可方式（比如 CC BY-NC-SA、或"转载请注明出处"）是标准做法：

• 它能让愿意遵守规则的人明确知道该怎么做
• 它不能拦住不打算遵守的人

所以值得写，但不要把它当成保护手段。声明的真正价值在于降低"善意使用者"的犯错概率，而不是威慑恶意搬运。

现实中的边界，要提前知道

这一部分需要诚实说明，避免预期错位：

• 识别与举证成本高：改写后的内容很难自动匹配到原文，靠人力搜索覆盖面有限
• 跨平台投诉效率不一：不同渠道的处理速度与标准差别很大
• 法律途径成本高：适合处理影响大、证据明确的个案，不适合日常纠纷
• AI 生成的答案无处投诉：模型输出不是可投诉的对象，能做的只有影响它的检索来源

**结论是：把主要精力放在"可被溯源"，而不是"追究责任"。**涉及严重侵权、商业损失的情况，建议咨询专业人士，而不是自己耗在投诉流程里。

一个更实际的判断标准

遇到内容被改写传播时，先问自己一个问题：

读者如果想核实这段话，能不能在三步之内找到我？

如果答案是"能"，那这件事的危害有限。如果答案是"不能"，那么真正要修的是溯源链路，而不是去追那一个改写者。

常见问题（FAQ）

被 AI 回答引用但没给链接，算侵权吗？

通常不算，但也没达到你想要的效果。**模型提到你的观点却不给出处，属于"提及"，价值低于"引用"。**能改善的方向是让归属信息更容易被读取——结构化数据和作者页就是为此服务的。

要不要用技术手段禁止内容被采集？

代价通常高于收益。加固反爬、限制访问会影响正常读者和搜索引擎，而这些渠道恰恰是引用的来源。除非内容本身有商业独占要求，否则不建议以牺牲可抓取性为代价做防护。

需要给每篇文章加水印或指纹吗？

可以有，但要理解它的作用边界：水印能帮助事后举证，不能阻止改写。对大多数内容站点来说，把同样的精力用在结构化数据与作者页上，实际收益更直接。

读者把内容转发到别的平台，要处理吗？

转发通常有利于传播，只要不冒充原创、不篡改结论，一般不必处理。可以提前在文末写清转载规则，让愿意遵守的人有章可循，比事后沟通省事。

小结

• 分清引用、改写、搬运三种情况，它们的目标完全不同。
• 有出处的引用是正向结果，不要和侵权混为一谈。
• 无出处改写难以追责，能改变的是让溯源更简单。
• 四项措施：结构化数据、作者页、文末署名、llms.txt。
• 判断标准：读者想在三步之内核实一段话，能不能找到你。

如果对这些概念的来龙去脉还不熟，建议先看《什么是 GEO》。

如果你遇到过内容被改写传播的情况，欢迎到留言板说说你是怎么处理的，这类经验对其他人很有参考价值。

差异一：大量中文内容根本不在可抓取范围里

这是三个差异中最容易被忽略、也最容易验证的一个。

中文互联网的优质内容很大一部分沉淀在需要登录或明确禁止抓取的产品里。实测几个平台的 robots.txt（2026 年 9 月 17 日）：

对比英文互联网：个人站点和独立博客是主流形态，绝大多数默认允许抓取。所以中文内容"表现差"的第一层原因不是质量问题，而是可检索的供给量本来就少。

这一项恰恰是个人可以改变的：把内容放在自有域名上，而不是只沉淀在禁止抓取的平台里。平台策略的完整实测见《博客、公众号、知乎，哪个更容易被 AI 引用》。

差异二：中文检索对术语一致性更敏感

检索系统处理英文时按词切分，处理中文时要先分词——这一步会放大术语变体带来的损耗。

英文里"GEO"和"generative engine optimization"是两个明确的字符串；中文里同一个概念可能是：

• GEO
• 生成式引擎优化
• 生成式引擎优化（GEO）
• AI 搜索优化
• 大模型优化

不同作者各用各的写法，读者的提问又是第六种说法。分词之后，这些变体之间并不天然等价，命中率因此下降。

还有一层：中文没有空格，切分歧义更多。"生成式引擎优化"可能被切成"生成/式/引擎/优化"或"生成式/引擎/优化"，不同切法对应的语义略有差别。

可执行的对策有两条：

1. 标题用最主流的叫法，正文第一段补上括注的同义解释。比如"GEO（生成式引擎优化，也叫 AI 搜索优化）"。
2. 在整篇文章里保持术语统一，不要同义词交替使用。同义词对读者友好，对检索不友好。

差异三：语料分布确实不均衡，但它不是决定因素

训练语料里英文占比高于中文，这是公开可观察的事实。但我没有可靠的中文占比统计数据，所以不在这里给具体数字——网上流传的比例多有引用错误，不适合当作依据。

需要理解的是这个差异的实际影响边界：

• 它影响的是模型对中文内容的"熟悉度"，以及某些领域中文资料是否足够
• 它不影响你的内容能否被检索、能否被切分、能否被归属
• 引用发生在检索环节，决定因素是内容与问题的匹配度，而不是语言的先天权重

换句话说：**语料分布是背景条件，不是你能操作的变量。**把注意力放在能改变的部分更实际。

三个差异里，你能改变两个

把三件事分开看，优先级就清楚了：

**结论是：中文内容做 GEO 的可行空间并没有想象中那么小。**真正的瓶颈通常在第一项——内容放错了地方。

怎么验证自己的情况

与其相信概括性结论，不如测自己的题材。方法很简单：

1. 选 5 个你关心的真实问题
2. 每个问题准备中英文两个版本
3. 在 3 到 4 个平台各问一遍，记录是否引用、引用了哪个来源、来源是中文还是英文
4. 两周后重复一次

这样得到的是你自己领域里的实际差异，比任何通用结论都有参考价值。记录方式可以沿用《怎么衡量 GEO 有没有效果》里的采样表。

一个常见的实测结果是：技术类问题里，英文来源的引用占比确实更高；但如果中文侧存在结构清晰、术语统一的独立站点内容，被引用的概率会明显高于平台内容。

常见问题（FAQ）

中文站点是不是应该改成英文？

不建议。语言选择应该由读者决定，而不是由检索偏好决定——**你的内容是写给谁看的，比它能不能被某个模型引用更重要。**中英双版本是可行方案，但要确保两个版本各自完整、不要互相稀释。

中文术语一定要用英文缩写吗？

建议中英并列而不是只写缩写。首次出现时写"GEO（生成式引擎优化）"，之后统一用其中一个。读者里既有搜英文缩写的，也有搜中文全称的，两者都覆盖到最稳妥。

把内容翻译成英文发布，会有额外收益吗？

可能有，但要权衡成本。翻译版本要能被正确归属、要指向原作者、地址要稳定，否则容易被当成重复内容。如果精力有限，把中文内容的质量和结构做好，收益通常高于多语言扩张。

中文内容要多久才能看到引用？

与新站被引用的周期一致，通常是被正常抓取之后的两周到几个月。语言本身不会显著拉长这个周期，决定因素仍然是抓取、索引与内容增量。

小结

• 中文内容的劣势可以拆成三个具体差异，而不是一个笼统印象。
• 最大的一项差异是可抓取供给少——大量优质内容被关在禁止抓取的平台里。
• 中文检索依赖分词，术语保持统一能明显降低损耗。
• 语料分布不均属于背景条件，不可控，也不该成为放弃的理由。
• 三个差异里有两个可以自己改变，先做这两件。

想从整体上理解这套机制，可以从《什么是 GEO》读起。

如果你测过中英文内容在你领域里的引用差异，欢迎到留言板分享结果，这类样本目前很缺。

为什么第一个月不要盯着引用率

引用率的反馈周期是几周到几个月。如果第一个月就拿它当指标，你会得到一堆噪声，然后开始乱改。

这一个月真正要拿到的是两样东西：

• 一条确认畅通的链路（抓得到、进得了索引、切得出片段）
• 一份基线数据（现在被引用了几次、哪些问题命中）

有了基线，之后的每一点变化才有参照。

第一周：确认抓取与索引是通的

这一周不做内容，只做检查。因为后面所有工作都建立在这条链路之上。

如果日志里从来没有出现过 AI 爬虫，先解决这一层，别急着写新内容。具体排查顺序见《为什么 AI 从来不提我的网站》。

第二周：把内容结构改成"可切分"的

这一周做改造，不写新内容——优先改那些已经有人访问、主题明确的旧文章。

四个动作，按重要性排序：

1. 每篇文章开头加一句"直接回答"。把最核心的结论压缩成两三句放在最前面，这是最容易被摘取的片段。
2. 把 h2 改成判断句。片段脱离上下文时，标题是它唯一的语义锚点。对比一下："优化建议"和"标题用主流叫法，正文补同义解释"。
3. 单节控制在 200 到 500 字，超过就拆。切分粒度太粗会让片段语义混杂。
4. 补齐 FAQ 小节。用 ### 问题 加一段答案的形式，写成真实会被问到的问题。

验收标准很简单：随便挑一节单独摘出来，看它能不能不依赖上下文独立成立。

第三周：补上信任信号

模型在挑选来源时会判断可信度。这一周补的是"这段内容由谁负责"的信息。

• 写一个真实的作者页：在做什么、关注什么方向，不要写成简历
• 给文章加结构化数据，至少要有 BlogPosting 和作者信息
• 统一全站的站点名、简介、头像，各平台说法保持一致
• 检查每个页面能否明确看出所属站点

结构化数据的落地方式见《结构化数据怎么做才对 GEO 有用》，加完不生效的排查见《结构化数据加了但没效果？先检查这四处》。

第四周：建立采样机制，留下基线

最后一周不做优化，做度量。没有基线，后面所有判断都是感觉。

具体做法：

1. 准备 20 到 30 个真实用户会问的问题，覆盖三层：品牌类（"某某是谁"）、主题类（"什么是 GEO"）、长尾类（"小网站值得做吗"）
2. 在 4 到 5 个平台各问一遍：ChatGPT、Perplexity、豆包、元宝、Kimi
3. 记录三列信息：是否被引用、是否被提及、引用的是哪一篇
4. 之后每两周重复一次，看趋势不看单点

指标设计可以参考《怎么衡量 GEO 有没有效果》。第一轮记录下来的就是基线，它的价值在第两次采样之后才显现。

第一个月不要做的三件事

**不要为了"优化"改 URL 结构。**地址变动的代价是几周内的引用失效，而结构调整带来的收益远小于这个损失。

**不要批量生成内容。**一个月产出几十篇同质文章，只会稀释站点的整体可信度。四到八篇有信息增量的内容，效果更好。

**不要只看流量。**AI 引用带来的很大一部分是零点击曝光——用户在答案里看到了你的名字就离开了，这不会出现在流量统计里。

常见问题（FAQ）

一个月能看到效果吗？

看不到引用率明显上升是正常的，反馈周期通常要两三个月。第一个月的产出是确认链路通畅和拿到基线数据，这两件事决定了后面几个月有没有优化空间。

没有技术人员能做吗？

可以。第一周和第四周主要是检查与记录，第二周和第三周是写内容与填信息，都不需要写代码。唯一涉及配置的是结构化数据，静态博客和主流 CMS 都有现成的插件或模板可用。

需要买监测工具吗？

第一个月不需要。手动在四五个平台采样 20 多个问题，半小时能完成一轮，信息量比工具生成的报告更贴合你的实际情况。等采样变成负担了，再考虑自动化——本站的监测模块就是这么演变来的，见《自建 GEO 平台的收录监测模块》。

团队里应该由谁负责这件事？

第一个月建议由一个人统筹，避免职责分散导致没人真正推进。内容结构改造需要写作者参与，抓取与索引的检查需要能接触服务器或站点后台的人。两边沟通成本不高，但必须有明确的负责人。

小结

• 第一个月的目标是打通链路加上拿到基线，不是提升引用率。
• 第一周查抓取与索引，问题在这一层时后面都白做。
• 第二周改造旧文章的结构，比写新内容见效更快。
• 第三周补作者页与结构化数据，解决"由谁负责"的问题。
• 第四周建立 20 条问题集与双周采样，后续所有判断都依赖这份基线。

如果你正准备开始，欢迎到留言板说说你的站点类型和现状，可以一起看看第一个月该从哪一步入手。

模型不会去检测"这段是不是 AI 写的"

先澄清一个常见误解：AI 搜索在挑选引用来源时，并不执行"AI 内容检测"这一步。

它做的事情可以概括成三件：

1. 这段内容是否回答了当前问题
2. 这段内容是否可靠（有没有来源、作者、上下文）
3. 这段内容是否提供了别处没有的信息

所谓"AI 检测工具"是另一套技术，用于判断文本的生成特征，它既不在检索链路上，也不影响引用决策。

所以**"我用 AI 写的内容会不会被识别出来然后被降权"这个担心，方向是错的。**真正让你被忽略的，是第三个问题——你没有提供增量。

真正的障碍是同质化

AI 生成内容的典型特征是：结构工整、措辞得体、但可以替换。

比如问"怎么做 GEO"，AI 通常会给出这样一套答案：优化内容质量、提升权威性、建立外链、做好结构化数据。正确，但没有区分度——这段话能出现在一万个站点上。

当检索系统面对一万篇内容相同的页面时，它只需要引用一篇，选择哪一篇带有随机性。你被引用的概率就是万分之一。

反过来，如果某篇文章写着：

我们在 12 个站点上测试了 robots.txt 配置，其中 3 个站点的 CDN 在 robots 允许的情况下仍然返回 403，原因是 WAF 把不带 cookie 的请求判定为爬虫。

**这段话只有这一个出处。**它不可替换，因此更容易成为被引用的那一个。

所以判断标准很清晰：你的文章里，有多少句子是"只有你能写"的？

AI 写不出来的四类信息

不需要文笔，只需要有别人拿不到的东西。四类最容易积累的：

这四类的共同点是：**AI 可以推理，但无法替你去做。**它们必须来自真实的操作、观察和记录。

务实的用法：AI 起草，人工注入

完全拒绝 AI 不现实，完全交给 AI 也写不出有增量的内容。可执行的组合是：

**第一步：用 AI 搭骨架。**让它列出这个主题应该覆盖哪些方面、常见的误解是什么。这一步能省下大量时间。

**第二步：逐节填入自己的东西。**每一节至少要有一处来自你实测、你的环境、或你的失败记录的具体信息。这是文章有没有价值的决定性环节。

**第三步：让 AI 挑毛病，而不是替你下结论。**用它检查逻辑漏洞、术语不一致、表述歧义；不要用它来"把内容说得更漂亮"——那正是同质化的来源。

**第四步：把无法验证的说法删掉。**AI 生成的文字里常有一些听起来合理但没有依据的判断，比如"研究表明大多数站点……"。没有出处就删，别留着。

怎么判断自己的内容有没有信息增量

写完一篇文章，用四个问题自查：

最后一个问题最有效：如果任何人都能写出完全相同的文章，它就不具备被引用的价值。

常见问题（FAQ）

用 AI 生成的内容会被搜索引擎惩罚吗？

主流平台的态度是惩罚低质量内容，而不是惩罚生成方式。判断依据是内容是否对读者有价值、是否提供了独特信息。所以问题不在于"用没用 AI"，而在于产出内容是否只是既有信息的重组。

我把 AI 写的内容改一改再发，可以吗？

改措辞不解决问题。同质化的本质是信息相同，不是表达相同——换一套说法，内容对检索系统来说依然是重复的。有效的做法是补充 AI 拿不到的信息，而不是替换表达方式。

完全人工写的内容就一定能被引用吗？

不一定。人工写的内容同样可能同质化——如果只是复述别人已有的观点，处境和 AI 生成内容一样。决定因素是信息增量，不是写作主体。

怎么积累"只有我能写"的素材？

养成两个习惯就够了：做事的时候顺手记下数字和异常，以及把走不通的尝试也记下来。多数人只记录成功的结论，而失败路径、环境细节和具体数字恰好是最稀缺的内容。这些素材积累起来后，写作速度会明显变快，因为可写的东西变多了。

小结

• 模型不检测"是否 AI 生成"，它判断内容的可用性、可靠性与增量。
• 同质化才是根本障碍：能出现在一万个站点上的内容，被引用的概率极低。
• AI 写不出来的四类信息：一手实测、失败路径、环境细节、时间敏感观察。
• 务实做法是 AI 搭骨架、人工注入一手信息、AI 挑毛病而非代下结论。
• 最有效的自查问题：换个人能不能写出完全一样的内容？

如果还没弄清 GEO 的整体思路，可以先看《什么是 GEO》。

如果你在琢磨怎么给自己的内容加上一手信息，欢迎到留言板聊聊你的领域，也许能一起找出几个可写的角度。

平台之间的差别，先看 robots.txt

robots.txt 是站点对爬虫的公开声明，可以直接读到。如果一个平台在文件里写了 Disallow: /，那么无论内容多好，主流爬虫都不会去抓。

以下是 2026 年 9 月 17 日实测的结果：

这张表解释了一个常见困惑：**为什么在知乎写了很多，AI 却从来没提过你。**不是内容不行，是内容根本没进入可检索的范围。

需要说明的是，平台的策略会调整，上面的结论有明确的时间点。判断方法比结论更重要，可以自己复核：

1

curl -s https://www.zhihu.com/robots.txt | head -20

robots.txt 允许不等于内容一定能被抓到

过了第一道门还有第二道：技术上允许抓取，不代表抓取会成功。

常见的额外阻力：

• 登录墙：不登录看不到正文，爬虫自然拿不到
• 频率限制：短时间内请求多了会被降速或拒绝
• 反爬识别：验证码、JS 挑战、UA 校验
• 内容异步加载：正文靠前端渲染，抓到的 HTML 是空的

可以用爬虫身份请求一次，看返回的是正文还是验证页：

1
2
3

curl -s -o /dev/null -w "%{http_code}\n" \
  -A "Mozilla/5.0 (compatible; Googlebot/2.1)" \
  https://example.com/some-article/

返回 200 只是第一步，还要看返回内容里有没有正文，而不是只有"请登录后查看"。

即使都能抓取，可归属性也完全不同

第三个差别更隐蔽，但影响最大：内容能不能明确归属到你。

对 AI 引用来说，**"这是谁写的、在哪个站点"是可信度判断的一部分。**平台内容往往缺少作者实体信息，即使被抓到，模型也更难把它归到某个可靠来源上。

一个务实的组合策略

基于上面三点，建议这样分配精力：

**主阵地放在自有域名。**内容首发在自己站点，拥有完整控制权：地址稳定、结构化数据完整、可以在文章里建立主题聚类和内链。

平台账号做分发，不做存档。把文章的核心结论摘出来发平台，引导感兴趣的人回到原站看完整版。这样做有两个好处：平台带来曝光和外部链接，而引用归因落回你自己的域名。

**不要只在一个禁止抓取的平台积累内容。**如果某天想搬到自有域名，你会发现所有历史内容的权重和引用都没法迁移——平台的域名不属于你。

怎么判断一个平台值不值得投入

四个问题，按顺序问：

四个都是"是"，就值得投入；前两个是"否"，写再多也很难被 AI 引用。

常见问题（FAQ）

在知乎写内容完全没有意义吗？

不是。知乎的价值在于读者获取和领域影响力——有人看到、有人讨论、有人因此找到你的站点。它只是不适合作为"被 AI 引用"的载体。把知乎当分发渠道，而不是唯一阵地。

公众号文章为什么很难被 AI 引用？

公众号内容主要被设计为在微信生态内流转，mp.weixin.qq.com 的 robots.txt 对绝大多数路径声明了禁止抓取。也就是说，主流搜索引擎和 AI 爬虫按规则不会抓取这些页面，内容自然不会出现在它们的检索结果里。

自有域名没有流量，写在那里有人看吗？

短期确实不如平台。但 AI 引用依赖的是被抓取、被索引、被归属，这三件事自有域名都占优。更实际的路径是：平台负责让人看到，自有域名负责被长期引用，两边内容有取舍地同步。

平台上的内容可以搬到自己的站点吗？

可以，而且建议做。关键是搬运后在自己的域名上要有独立价值：补充更完整的版本、更新数据、加上内链。如果只是复制粘贴，两处内容高度重复，反而会分散权重。

小结

• 平台能不能被引用，第一道门槛是 robots.txt，不是内容质量。
• 实测：知乎与公众号基本禁止抓取，CSDN、博客园、掘金、简书允许。
• robots.txt 允许只是及格线，登录墙、反爬、异步渲染仍会拦住抓取。
• 自有域名在作者实体、地址稳定性、内容结构上都有明显优势。
• 务实策略：自有域名做阵地，平台做分发，不要只押注在禁止抓取的平台上。

如果你在纠结内容该放在哪个平台，欢迎到留言板说说你的场景，可以一起判断值不值得投入。

平台选定之后，中文内容在检索环节的额外差异见《中文内容在 AI 搜索里的表现比英文差吗》。

伤害是滞后的，所以最容易误判

改完 URL 的当天，你去看 AI 搜索，往往会发现引用还在——因为索引里存的还是旧地址。真正的下滑出现在之后的两到六周，那时爬虫重新访问旧地址，发现是 404，才把记录清掉。

这种滞后带来一个典型误判：改完没出问题，就以为不用管了，等发现问题时已经过去一个月，旧地址的外部链接和引用记录都失效了。

所以判断标准很简单：改 URL 之后，旧地址必须永远有效，只是把用户和爬虫送到新地方。

301 是唯一正确的迁移手段

几种常见做法的差别：

**只有 301 是明确告诉对方"这个地址永久搬走了"的信号。**其他方式要么不传递权重，要么在抓取环节就直接断掉。

第五种情况值得单独说：把新旧两个地址都保留、都返回 200，看起来"两边都能访问"，实际是让两个地址争夺同一份内容，最终两个都受损。

旧地址映射要写进配置文件，长期保留

在 nginx 里做逐条映射是最直接的方式：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

# 旧文章地址 → 新地址
location = /old-post-title.html {
    return 301 /posts/new-post-title/;
}

# 整段路径迁移
location ^~ /blog/ {
    return 301 /posts/$1;
}

# 分类页结构变化
location = /category/geo/ {
    return 301 /categories/geo/;
}

地址多的时候，用 map 集中管理更清晰：

1
2
3
4
5
6
7
8
9
10
11
12

map $request_uri $redirect_target {
    default            "";
    /old-a/            /posts/a/;
    /old-b/            /posts/b/;
    /old-c/            /posts/c/;
}

server {
    if ($redirect_target != "") {
        return 301 $redirect_target;
    }
}

几个要点：

• 用 location = 做精确匹配，避免规则互相干扰
• 映射表放在配置文件里，不要放在数据库或脚本里——它需要长期存在
• 改完必须实际请求一遍旧地址，看返回的 Location 是否正确

跳转链必须控制在一次以内

A → B → C 这种多级跳转是常见的隐性损耗：每多一跳，抓取预算和权重传递都会被削弱，部分爬虫在第二跳就放弃了。

自查方法：

1

curl -sI https://example.com/old-url/ | grep -iE "^(HTTP|location)"

如果返回的 Location 指向的地址还会再跳一次，就把映射直接改成指向最终地址，把中间那一环删掉。

内部改写会让跳转规则陷入死循环

本站做过一次地址规范化：把 /topic/index.html 这类带文件名的地址统一跳到目录形式 /topic/。第一版配置是这样写的：

1
2
3
4

# ❌ 有问题的写法
location ~ ^(?<dir>/.*)/index\.html$ {
    return 301 $dir/;
}

上线后除首页外全站瘫痪——访问 /topic/ 会无限跳转。

原因是 nginx 在处理目录请求时，会在内部把 /topic/ 改写成 /topic/index.html，改写后的地址又匹配了这条 location 规则，于是 /topic/ 被要求跳到 /topic/，形成死循环。

正确的做法是判断客户端原始请求，而不是内部改写后的地址：

1
2
3
4

# ✅ 正确写法
if ($request_uri ~ ^(/(?:[^?]*/)?)index\.html(?:\?|$)) {
    return 301 $1;
}

$request_uri 保存的是浏览器实际请求的地址，不受内部改写影响，因此不会自我循环。

这个坑靠本地静态预览完全看不出来——静态服务器没有内部改写行为。涉及跳转规则时，一定要在真实 nginx 环境（哪怕是临时实例）验证，而不是只在本地看页面能不能打开。

迁移完成后有四件事必须做

另外注意：**已经发布过的地址尽量不要再改。**迁移本身是有成本的，规划阶段多想一步，比事后修补省事得多。

常见问题（FAQ）

换了域名，旧域名的 301 要保留多久？

建议长期保留，至少一年，有条件就一直保留。旧域名的外部链接不会因为你换了域名就消失，只要旧域名还在解析，就应该继续把访问者送到新站。域名到期前记得续费——域名过期是唯一无法用 301 挽回的情况。

用 JavaScript 跳转能替代 301 吗？

不能。搜索引擎和 AI 爬虫在抓取阶段经常不执行 JavaScript，看到的是一个内容为空的页面；即使执行了，权重传递效果也远不如 301。JS 跳转只适合作为辅助手段，不能作为迁移方案。

只改文件名不改目录结构，也需要 301 吗？

需要。任何已发布地址的变化都算迁移，哪怕只是去掉了结尾的 .html。判断标准是"这个地址之前有没有对外出现过"，而不是"改动大不大"。

迁移后引用掉了，还能恢复吗？

如果旧地址返回 301 并且新地址内容一致，引用通常会随着重新抓取逐步恢复，周期几周到几个月。如果旧地址返回 404，或者新地址内容被大改，恢复就很困难——这也说明迁移时要尽量保持内容主体不变。

小结

• URL 变更的伤害滞后 2–6 周出现，别因为当天没问题就放心。
• 每一条旧地址都要有 301，跳转链控制在一跳以内。
• 新旧地址同时返回 200 是收益最差的做法。
• nginx 里判断跳转要看 $request_uri，否则可能被内部改写拖进死循环。
• 迁移后同步更新 sitemap、内链与 robots.txt，并把 301 保留一年以上。

迁移只是 GEO 工作里的一环，整体思路见《什么是 GEO》。

如果你正在做站点迁移，拿不准某条跳转规则会不会出问题，欢迎到留言板贴出配置，一起看看。

结构化数据不负责"被收录"，先确认页面能被抓到

一个前提要先说清楚：结构化数据的作用是把页面里已经存在的信息表达得更明确，它不会让一个没被收录的页面变得可检索。

所以排查的第一步不是看代码，而是确认：

• 页面能被爬虫抓取（返回 200，没有被 robots.txt 或 CDN 拦）
• 页面已经进入索引（搜 site:域名 能找到）
• 内容本身回答了某个真实问题

**这三条不成立时，结构化数据写得再标准也没有意义。**前两条的验证方法见《为什么 AI 从来不提我的网站》。

检查点一：格式错误的 JSON-LD 会被静默忽略

格式错误的 JSON-LD 会被解析器直接忽略，而且不会在页面上显示任何异常——这是最容易被漏掉的一类问题。

常见错误：

1
2
3
4
5
6
7
8
9
10
11
12

<!-- 错误一：多了一段多余的花括号，JSON 不合法 -->
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting"
}}
</script>

<!-- 错误二：引号被模板转义，输出成了 &quot; -->
<script type="application/ld+json">
{&quot;@type&quot;: &quot;BlogPosting&quot;}
</script>

第二种情况在静态站点生成器里很常见：模板引擎对字符串做了 HTML 转义，结果 " 变成了 "，JSON 直接失效。

验证方式：直接查看页面源码，把 <script type="application/ld+json"> 里的内容复制出来跑一次解析：

1
2
3
4
5
6
7
8
9
10
11
12

curl -s https://example.com/posts/hello/ \
  | python3 -c "
import sys, re, json
html = sys.stdin.read()
blocks = re.findall(r'<script type=\"application/ld\+json\"[^>]*>(.*?)</script>', html, re.S)
print('找到', len(blocks), '个 JSON-LD 块')
for i, b in enumerate(blocks, 1):
    try:
        json.loads(b); print(f'  第 {i} 个：合法')
    except Exception as e:
        print(f'  第 {i} 个：解析失败 →', e)
"

输出里有任何一个"解析失败"，就先修这个，别的都不用看。

检查点二：@id 和 url 必须是真实的绝对地址

这是从教程里复制代码时最容易埋下的坑。

大多数示例代码用 example.com 占位，直接复制就会得到这样的输出：

1
2
3
4

{
  "@type": "WebPage",
  "@id": "https://example.com/posts/structured-data/"
}

后果是实体标识指向了别人的域名：模型在理解"这篇文章属于谁"时拿到的是错误信息，等于白写。更隐蔽的情况是同一页面里混用相对路径和绝对路径，导致同一个实体有两个标识。

规则很简单：

• @id 和 url 一律写完整的绝对地址，包含 https:// 和域名
• 所有出现的地方必须完全一致，包括结尾有没有斜杠
• 上线前全局搜一次 example.com，确保没有残留

1
2

# 在构建产物里搜占位域名
grep -rn "example.com" public/ | head

检查点三：数据只能声明页面上真实存在的信息

结构化数据有一条硬规则：它只能声明页面上真实存在的信息。

声明了页面上没有的内容，属于误导性标记，轻则被忽略，重则影响整个站点的可信度。常见的不一致：

验证方式：把 JSON-LD 里的字段和页面上肉眼可见的内容逐项对一遍，尤其是标题、日期、作者、图片这四项。图片地址还要单独确认能打开。

检查点四：单条数据不够，要声明实体之间的关系

单打独斗的一条 BlogPosting 信息量有限。让模型理解"这篇文章属于哪个站点、由谁写的、在什么位置"，需要多条数据互相引用。

四种最有价值的关系（详细写法见《结构化数据怎么做才对 GEO 有用》）：

如果只加了 BlogPosting 就发现没效果，问题往往在这里——不是数据错了，而是信息量不够支撑一次"引用决策"。

用工具验证，别靠肉眼判断

排查完上面四项后，用官方工具做一次确认：

注意工具的作用边界：**它们能验证"数据是否合法"，不能验证"是否会被 AI 引用"。**后者只能通过在多个平台上用固定问题采样来观察，方法见《怎么衡量 GEO 有没有效果》。

常见问题（FAQ）

结构化数据加完多久能看到变化？

没有固定周期，取决于页面是否被重新抓取。通常几周到一两个月。如果页面本身没被索引，等多久都不会有变化——这也是为什么排查要从抓取和索引开始。

加了 FAQPage 但搜索结果里没显示问答，是失败了吗？

不一定。FAQPage 结构化数据对 GEO 的价值在于让模型更容易提取问答对，而不仅仅是搜索结果的富摘要展示。两个平台的展示策略也各不相同，不展示不代表数据没被使用。

多个 JSON-LD 块放在同一个页面会不会冲突？

不会。解析器会把同一页面里的多个块合并理解。实践中更推荐用 @graph 把相关内容组织在一个块里，便于维护，但分开放多个块同样有效。真正的问题不是块的数量，而是实体之间有没有互相引用、标识是否一致。

用了 WordPress 或 Hexo 的插件，还需要自己检查吗？

需要。插件保证的是"输出格式"，不保证"内容正确"——尤其是 @id 指向的域名、作者页地址、日期格式这些需要结合站点实际情况调整的字段。插件装完必须抽查两三个页面的源码。

小结

• 结构化数据不负责收录，先确认页面能被抓取和索引。
• JSON-LD 格式错误会被静默忽略，上线前跑一次解析验证。
• @id 和 url 必须是真实绝对地址，且全局统一。
• 数据只能声明页面上真实存在的信息。
• 单条 BlogPosting 信息量不足，需要多条数据互相引用。

如果你加了结构化数据还是不生效，欢迎到留言板贴出页面地址和 JSON-LD 片段，一起看看卡在哪一项。

默认放行，除非你有明确理由

先说一个前提：robots.txt 是君子协定，靠爬虫自行遵守，没有强制力。它拦不住不守规矩的采集者，也拦不住已经部署在 CDN 层的拦截规则。

它真正的作用是表达意图：告诉守规矩的爬虫"这里欢迎你，那里请不要来"。

对一个以内容为主的站点，合理的默认姿态是放行。理由有三个：

• 你希望内容被引用，而引用依赖检索，检索依赖抓取
• 训练类抓取即使拦掉，也无法验证效果，收益不明确
• 规则越多，写错的机会越大——一条写错的规则可能同时挡掉好几个爬虫

**只有当你有明确诉求时，才需要精确屏蔽。**比如站点包含内部文档、付费内容目录，或者公司对内容用途有明确规定。

爬虫要先按用途分类，再决定放不放

同样叫"AI 爬虫"，职责差别很大。三类爬虫的作用范围见《AI 引用和 AI 训练是两件事》，这里只给配置结论：

**判断顺序是：先问"拦掉它我会损失什么"，再问"拦掉它我能得到什么"。**如果损失是确定的、收益是不确定的，就不要拦。

一份可以照抄的配置

下面这份配置可以做起点，把域名换成你自己的：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

# 站点地图写在这里，方便爬虫一次找到
Sitemap: https://example.com/sitemap.xml

# 默认全站放行
User-agent: *
Allow: /

# 只屏蔽确实不该被索引的路径
Disallow: /search/
Disallow: /preview/

# ---- 明确放行 AI 相关爬虫 ----

# OpenAI
User-agent: GPTBot
Allow: /
User-agent: OAI-SearchBot
Allow: /
User-agent: ChatGPT-User
Allow: /

# Anthropic
User-agent: ClaudeBot
Allow: /
User-agent: Claude-User
Allow: /

# Perplexity
User-agent: PerplexityBot
Allow: /
User-agent: Perplexity-User
Allow: /

# 传统搜索爬虫：AI 检索层常常依赖它们的索引
User-agent: Googlebot
Allow: /
User-agent: Bingbot
Allow: /

几点说明：

• Sitemap: 是唯一写绝对地址的指令，其他规则写路径即可
• 路径区分大小写，/Search/ 和 /search/ 是两条规则
• 每条 User-agent 后面跟的规则属于这一组，组之间要有明确的空行分隔（严格来说是靠 User-agent 行划分，空行只是可读性）
• 想屏蔽某个爬虫，把 Allow: / 换成 Disallow: / 即可，其他组不受影响

本站的配置就是按这个思路生成的，完整内容可以直接访问 /robots.txt 对照。

五条最容易写错的规则

第一，User-agent: * 里的 Disallow: / 会误伤一大片。 通配组是所有没被单独列出的爬虫的默认行为。你只想屏蔽某个采集者，却让几十个爬虫一起出局，这是最常见的事故。

**第二，匹配规则是"最长匹配优先"，不是"先写先算"。**同一组里有多条规则时，路径匹配最长的那条生效；长度相同时 Allow 优先。所以 Allow: /blog/ 和 Disallow: /blog/draft/ 同时存在时，草稿目录仍然会被挡住——这符合直觉，但很多人以为后面的规则会覆盖前面的。

第三，robots.txt 必须放在域名根目录。 https://example.com/robots.txt 有效，https://example.com/blog/robots.txt 对主站无效。子目录站点（比如托管在二级路径下的博客）没有独立的 robots.txt 可用。

第四，规则是路径前缀匹配，不是正则。* 是通配符、$ 表示结尾，这两个的支持比较普遍，但更复杂的表达式（比如带括号、量词的写法）各爬虫支持程度不一，不要依赖。

第五，爬虫名拼错等于没写。PerplexityBot 写成 Perplexity-Bot、ClaudeBot 写成 Claude-Bot，规则就不会被匹配。名称大小写不敏感，但拼写必须准确。

配置写完，一定要验证

写完不验证，等于没写。三步走：

第一步，确认文件本身可访问、内容正确：

1

curl -s https://example.com/robots.txt | head -40

返回 404 或返回了 HTML，说明文件位置或服务器配置有问题。

第二步，用爬虫身份请求一个内容页，确认没有被服务器层拦住：

1
2
3

curl -s -o /dev/null -w "%{http_code}\n" \
  -A "Mozilla/5.0 (compatible; OAI-SearchBot/1.0)" \
  https://example.com/posts/hello/

返回 200 才算真正放行。robots.txt 允许不代表能访问——CDN 的防机器人模式、WAF 规则、限速配置都可能在这一层把请求挡下来。

**第三步，过一段时间回来看日志。**只有日志里出现真实的爬虫访问，才说明整条链路是通的：

1
2
3

# 统计最近访问过的 AI 爬虫与次数
grep -ioE "GPTBot|OAI-SearchBot|ChatGPT-User|ClaudeBot|PerplexityBot|Bytespider" \
  /var/log/nginx/access.log | sort | uniq -c | sort -rn

如果某个爬虫一次都没出现，回到第一步重新验证，别急着改内容。

常见问题（FAQ）

不写 robots.txt 会怎样？

等同于默认全部允许。搜索引擎和多数 AI 爬虫在没有该文件时按"可以抓取"处理。所以不写文件本身没有风险，但你会失去表达意图的能力——比如声明站点地图、屏蔽搜索结果页这类不该被索引的地址。

我想屏蔽 AI 训练，应该只加一条 Disallow: GPTBot 吗？

只针对你想屏蔽的对象配置，别用通配规则。需要注意训练语料来源不止一家：CCBot（Common Crawl）的数据常被多个模型复用，屏蔽了 OpenAI 却放行 CCBot，内容仍可能间接进入训练集。如果你的诉求是"尽量不被用于训练"，需要把这一类别里的主要爬虫逐条列出。

robots.txt 能阻止内容被抓取吗？

只能阻止愿意遵守规则的爬虫。它没有技术强制力，对不守规矩的采集者无效。如果你的诉求是"技术上不被抓"，需要靠服务器层的鉴权、频次限制或访问控制，而那些手段同样会影响正常读者和搜索引擎。

改了 robots.txt 多久生效？

爬虫通常会在下次抓取时重新读取该文件，时间从几小时到几天不等。如果之前已经被屏蔽，恢复抓取往往还需要额外几周——这也是不要随意屏蔽的原因：一次误操作的成本可能是一个月。

小结

• 默认放行、按用途分类、只精确屏蔽必要的对象，是稳妥的默认姿态。
• 检索类爬虫直接决定能否被引用，用户触发类代表真实读者，这两类都别拦。
• 通配组里的 Disallow: / 是误伤重灾区，精确屏蔽优于一刀切。
• 规则是路径前缀匹配、最长匹配优先，且必须放在域名根目录。
• 写完必须验证：文件可访问、爬虫 UA 能拿到 200、日志里能看到真实访问。

如果你的 robots.txt 配置完还是不见爬虫来，欢迎到留言板贴出配置和日志片段，一起看看卡在哪一层。

两条链路的机制完全不同

先看一张对照表，这是后面所有判断的基础：

一句话概括：训练影响的是模型的"记忆"，引用影响的是用户的"当下决策"。

你真正想要的通常是后者——有人因为 AI 的回答而知道你的站点。但很多人把力气全花在了前者上。

混淆会让你做出相反的错误决策

两种典型错误，方向正好相反：

错误一：想被推荐，却把所有 AI 爬虫都拦了。

有人担心内容被拿去训练，于是在 robots.txt 里写下 User-agent: * + Disallow: /，或者逐个屏蔽带 AI 字样的爬虫。结果连负责检索的爬虫一起挡在门外，AI 搜索再也看不到这个站点。

错误二：以为被训练了就会被推荐。

另一种常见误解是"我的文章被模型学过了，那它应该会推荐我"。实际上训练数据里的内容是没有署名、没有链接的——模型只是"知道"了这件事，回答时不会说这是谁写的。没有引用链路，就没有归属。

判断标准很简单：

• 想要有人看到你 → 要的是引用，重点是抓取、索引、结构、信任
• 想要模型记住这件事 → 要的是训练，但收益不可控、不可度量

大多数做内容的人，目标都是前者。

AI 爬虫至少分三类，用途各不相同

把爬虫按用途分开看，配置才不会出错：

三点需要特别注意：

第一，Google-Extended 不影响 Google 搜索排名。 它只控制内容是否用于 Gemini 的训练与相关用途，屏蔽它不会让站点在搜索里消失。这是个常见误解。

第二，传统搜索爬虫仍然重要。 很多 AI 检索层依赖已有的网页索引，把 Googlebot、Bingbot 挡住，等于同时放弃了大部分引用机会。

第三，用户触发类的爬虫最好放行。 它代表的是一个真实的人在读你的页面，拦住它没有任何好处。

具体到每个爬虫该怎么写配置，见《robots.txt 里的 AI 爬虫该怎么配》。

引用可以优化，训练只能选择给不给

这是两个机制最本质的差别，也决定了该把精力放在哪。

引用是可以被工程化的。 你能做的事情包括：

• 让页面被抓到、进索引（前提）
• 把内容切成语义完整的片段
• 让标题的用词和真实提问对齐
• 补齐作者与站点信息，提高可信度
• 用固定问题集定期采样，看引用率的变化

这几件事都有明确的动作和可观察的结果，属于可以迭代的工作。

训练则基本是单向开关。 你能决定的只有"给不给"，给完之后：内容怎么被用、用多少次、有没有影响到具体回答，都无从得知。中间的反馈是断的。

所以从投入产出看，做内容的人应该把引用链路当成主战场，训练当成顺带的结果。

引用可以验证，训练几乎无法验证

验证手段的差别，进一步说明了该关注哪一个：

最后一行是关键：训练这件事无法验证，也就无法优化。 一个既不能度量、也不能迭代的方向，不适合作为主要目标。

引用侧的采样方法，可以照搬《怎么衡量 GEO 有没有效果》里的那套指标设计。

常见问题（FAQ）

我的文章被模型学过了，为什么它不推荐我？

因为训练数据进入模型后不再携带出处。模型可能"知道"这个知识点，但回答时不会说出作者或链接。要被推荐，需要的是引用链路——模型在回答时实时检索到你的页面并标注来源，这与训练是两条独立的路径。

屏蔽 GPTBot 会影响 ChatGPT 引用我的网站吗？

这两个爬虫的职责不同，理论上可以分别配置。但在实际操作中，很多人用一条通配规则把所有 AI 爬虫一起拦掉，结果连带影响检索与用户触发的抓取。如果你担心的是训练用途，就精确地只针对训练类爬虫配置，不要用一刀切规则。

怎么确认自己的内容有没有被用于训练？

没有可靠办法。你能观察到的只是模型输出是否表现出相关知识，但无法证明来源是你的页面，也无法确认具体版本。这也是"训练不可度量"的直接体现——把精力放在可验证的引用链路上更划算。

那还需要在意训练吗？

值得在意的只有一件事：你是否有明确的理由不希望内容被用于训练。 如果没有特别诉求，放行训练类爬虫的成本很低，而它可能带来的长期曝光是有价值的。有诉求时，也建议只做精确屏蔽，不动检索链路。

小结

• 训练进参数、滞后、不可追踪；引用在实时检索里发生，可优化、可度量。
• 混淆会同时导致两种反向错误：该放行的拦了，或者以为被学会就会被推荐。
• AI 爬虫至少分训练、检索、用户触发三类，要分开对待。
• Google-Extended 不影响搜索排名，这是最容易搞错的一条。
• 想要有人找到你，主战场是引用链路，不是训练。

如果你在配置爬虫时拿不准某个 UA 该不该放行，欢迎到留言板说说你的场景，一起判断。

排查要按链路顺序来，别从改文章开始

一个页面被 AI 引用，要依次经过六个环节。任何一环断掉，后面做得再好都不起作用：

1
2
3

① 能被抓取    →  ② 进入索引    →  ③ 切成片段
                                        ↓
⑥ 有对应需求  ←  ⑤ 通过信任判断  ←  ④ 语义匹配提问

多数人一发现问题就回去改文章，等于只盯着最后一步。先确认前面五步有没有断，再决定要不要动内容。

下面逐条展开。

原因一：爬虫被 robots.txt 或服务器挡在门外

这是最容易验证、也最常见的一条。 内容再好，抓不到就等于不存在。

三种典型情况：

• robots.txt 里写了 Disallow: /，或者把 AI 相关爬虫单独屏蔽了
• 服务器或 CDN 拦截了不认识的 User-Agent，直接返回 403
• 站点挂了 WAF 的"防机器人"模式，把正常抓取一并拦掉

验证方法很直接，用爬虫自己的身份请求一次：

1
2
3
4

# 换成你自己域名，观察返回码
curl -s -o /dev/null -w "%{http_code}\n" \
  -A "Mozilla/5.0 AppleWebKit/537.36; compatible; GPTBot/1.2" \
  https://example.com/

返回 200 说明放行，403 或 503 就是被拦了。同样的方法可以依次测试其他爬虫。

再看一眼服务器访问日志里有没有这些 UA——如果日志里从来没有出现过它们，问题就在这一层：

1

grep -iE "GPTBot|ClaudeBot|PerplexityBot|Bytespider" /var/log/nginx/access.log | tail -20

关于哪些爬虫该放、哪些可以拦，见《robots.txt 里的 AI 爬虫该怎么配》。

原因二：页面没有进入索引，AI 根本搜不到

抓取不等于收录。AI 搜索的检索层通常依赖一套网页索引，页面进不去索引，就等于没被写过。

常见原因：

• 新域名，还没有任何外部链接指向你
• sitemap.xml 没提交，或者里面的地址和实际地址不一致
• 页面头部误加了 noindex，或者被 robots.txt 屏蔽后又忘了恢复
• 站点用了大量 JavaScript 渲染，抓取到的正文是空的

验证与处理：

1. 用搜索引擎的 site:你的域名 查一下有没有页面被收录
2. 在搜索平台的后台提交 sitemap.xml，观察抓取量的变化
3. 确认页面源码里能看到完整正文，而不是只有一句"正在加载"

分类页、标签页也别忘。 这些聚合页往往是模型理解"这个站点在讲什么主题"的重要入口。

原因三：内容被切成了没有主语的碎片

索引会把页面切成若干片段再向量化。如果你的文章是一整坨没有小标题的长段落，每个片段都会语义混杂，跟任何具体问题的相似度都不高。

判断标准很朴素：把任意一段单独摘出来，它还成立吗？

不成立的反例：

综上所述，前面提到的这些方法在实践中都很重要，具体使用时还需要结合实际情况来判断。

成立的正例：

每个 h2 都写成一个判断句。片段脱离上下文时，标题是它唯一的语义锚点。

可执行的做法：

• 用 h2 / h3 切分语义，单节控制在 200 到 500 字
• 每节第一句就是这一节的结论，不要用"话不多说""众所周知"开场
• 一节只讲一件事，混装两个主题会让片段向量变得"平均"

原因四：你用的词和用户问的话对不上

检索的第一步是把用户的口语问题改写成多个检索式。如果你的用词和改写结果不一致，内容根本进不了候选集。

同一个概念，用户可能说：

• GEO
• 生成式引擎优化
• AI 搜索优化
• 让 AI 推荐我的网站

如果你的文章标题只用其中一种，正文里也只出现一次，命中概率就只剩一份。

处理方式是统一但不生造：**标题用最主流的叫法，正文开头补上同义解释。**比如"GEO（生成式引擎优化，也叫 AI 搜索优化）"。别为了显得专业自创术语——除非你打算同时把定义写清楚。

原因五：缺少可验证的身份和一致性

模型在生成答案时倾向于选择来源明确、可核查的内容。匿名站点不是不能引用，但需要更强的其他信号。

最低配的三件事：

• 一个作者页，写清楚你是谁、在做什么
• 页面上的结构化数据，把文章、作者、站点关系显式声明
• 全站的名称、简介、头像保持一致，别每个平台一个说法

三件事都不需要技术门槛，但很多人一个都没做。具体做法见《结构化数据怎么做才对 GEO 有用》。

原因六：时间不够，抓取和索引都需要周期

**新域名从上线到稳定被抓取，通常要 2 到 6 周。**更新后的内容重新进入索引，也常常需要几天到几周。

这一点上最常见的错误是频繁改版：地址结构改了、标题改了、内容大改，等于让之前的抓取记录全部作废，周期从头开始。

如果前面五条都排查过没问题，剩下的通常就是等。稳定输出会比反复修改更快见效。

一张可以照着走的排查清单

常见问题（FAQ）

屏蔽了 GPTBot，会影响 ChatGPT 引用我的网站吗？

会，而且这是最常见的自伤操作。GPTBot 与 ChatGPT 的搜索抓取是两回事，用一条 Disallow 把整个 OpenAI 的爬虫拦掉，等于同时放弃了被引用的机会。正确做法是分开配置，只拦你确实不想被用于训练的那一类。

内容质量明明不错，为什么还是不被引用？

先看抓取和索引，再看结构。实际排查中，卡在"抓不到"和"进不了索引"的比例远高于卡在"写得不好"。内容质量只有在前面几步都通了之后才会成为决定性因素。

我的网站被引用过，但引用的是旧版本内容，怎么办？

说明链路是通的，只是索引还没更新。更新文章时保留原地址、在显著位置标注更新时间，比新建一篇替换它更容易让索引快速刷新——新建地址会让已有引用断掉。

需要多久才能看到效果？

新域名给自己 6 到 8 周，期间保持稳定输出、不要改地址结构。已有一定抓取量的站点，更新内容通常几天到两周内会反映在引用结果里。想系统跟踪这件事，可以参考《怎么衡量 GEO 有没有效果》。

小结

• 排查顺序是抓取 → 索引 → 切片 → 术语 → 信任 → 需求，别从改文章开始。
• 前两条能用命令直接验证，先验证再动手。
• 内容结构决定片段质量，单节 200–500 字、首句给结论。
• 用词跟主流叫法对齐，比自创术语更容易被检索到。
• 前面都通的情况下，剩余变量是时间。

如果你在自己站点上排查时卡在某一步，欢迎到留言板把现象和已经试过的方法写出来，一起看看更可能是哪一环断了。

准备工作

开始之前需要确认四件事：

备案是最容易被忽略的时间成本。 如果还没备案，建议先去走流程，等备案通过期间可以先把博客搭起来。

一、域名解析

在域名管理后台为博客添加一条记录：

生效后本机验证：

1
2

dig +short devnotes.cuiyuehui.cn
# 应该输出你的服务器 IP

二、服务器初始化

1
2
3
4
5
6
7
8
9
10
11

# 安装 Nginx 与同步工具
sudo apt update
sudo apt install -y nginx rsync

# 创建站点目录
sudo mkdir -p /var/www/devnotes
sudo chown -R $USER:$USER /var/www/devnotes

# 放行防火墙端口
sudo ufw allow 'Nginx Full'
sudo ufw allow OpenSSH

阿里云还需要在控制台的安全组里放行 80 / 443，只配服务器内的防火墙是不够的。

三、Nginx 配置

创建 /etc/nginx/conf.d/devnotes.conf：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

server {
    listen 80;
    server_name devnotes.cuiyuehui.cn;

    root /var/www/devnotes;
    index index.html;

    # 静态资源压缩，减少传输体积
    gzip on;
    gzip_vary on;
    gzip_min_length 1024;
    gzip_types text/plain text/css application/javascript application/json
               application/xml image/svg+xml;

    location / {
        try_files $uri $uri/ $uri/index.html =404;
    }

    # 带指纹的静态资源长期缓存，HTML 不缓存
    location ~* \.(css|js|woff2?|png|jpg|jpeg|gif|svg|webp|ico)$ {
        expires 30d;
        add_header Cache-Control "public, immutable";
    }

    location ~* \.html$ {
        add_header Cache-Control "no-cache";
    }

    # 评论服务反向代理（可选，见第六节）
    location /comments/ {
        proxy_pass http://127.0.0.1:8360/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

检查并生效：

1
2

sudo nginx -t
sudo systemctl reload nginx

关于缓存的一个教训

我一开始给所有文件都加了长缓存，结果每次发布新文章，读者看到的还是旧的首页。HTML 必须不缓存，带指纹的资源才应该长缓存。 上面配置里把 .html 单独设成 no-cache，就是踩了这个坑之后加上去的。

四、申请 HTTPS 证书

用 Certbot 自动申请并配置续期：

1
2

sudo apt install -y certbot python3-certbot-nginx
sudo certbot --nginx -d devnotes.cuiyuehui.cn

Certbot 会自动改写 Nginx 配置、加上跳转，并注册一个定时续期任务。验证续期是否正常：

1

sudo certbot renew --dry-run

也可以使用阿里云签发的免费证书，在控制台下载后手动配置 ssl_certificate 与 ssl_certificate_key，效果相同。

五、部署脚本

在博客目录创建 tools/deploy.sh：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

#!/usr/bin/env bash
set -euo pipefail

SERVER="root@your-server-ip"
TARGET="/var/www/devnotes/"

echo "==> 本地构建"
npm run clean
npm run build

echo "==> 同步到服务器"
rsync -avz --delete \
  --exclude '.DS_Store' \
  public/ "${SERVER}:${TARGET}"

echo "==> 完成，访问 https://devnotes.cuiyuehui.cn"

几个关键参数：

第一次部署前先做一次空跑确认删除范围：

1

rsync -avz --delete --dry-run public/ "${SERVER}:${TARGET}"

--dry-run 会列出所有将被删除的文件。在没有确认之前不要去掉这个参数——路径写错一个字符，可能删光整个目录。

六、评论服务（可选）

如果希望读者能直接留言，可以在同一台服务器上用 Docker 跑一套 Waline + MySQL。一份 docker-compose.yml 同时拉起两个容器，MySQL 不对外暴露端口：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

# docker-compose.yml
services:
  db:
    image: mysql:8.0
    restart: always
    command:
      - --character-set-server=utf8mb4
      - --collation-server=utf8mb4_unicode_ci
      # Waline 的 MySQL 驱动不支持 MySQL 8 默认的 caching_sha2_password 认证，
      # 不加这一行会报 ER_NOT_SUPPORTED_AUTH_MODE
      - --default-authentication-plugin=mysql_native_password
    environment:
      MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD}
      MYSQL_DATABASE: waline
      MYSQL_USER: waline
      MYSQL_PASSWORD: ${MYSQL_PASSWORD}
    volumes:
      - ./mysql-data:/var/lib/mysql
      # 首次启动自动导入表结构
      - ./waline.sql:/docker-entrypoint-initdb.d/10-waline.sql:ro

  waline:
    image: lizheming/waline:latest
    restart: always
    depends_on:
      db:
        condition: service_healthy
    ports:
      - "127.0.0.1:8360:8360"
    environment:
      SITE_NAME: DevNotes
      SITE_URL: https://devnotes.cuiyuehui.cn
      MYSQL_HOST: db
      MYSQL_PORT: "3306"
      MYSQL_DB: waline
      MYSQL_USER: waline
      MYSQL_PASSWORD: ${MYSQL_PASSWORD}
      # 必填，否则容器起不来。生成方式：openssl rand -hex 24
      JWT_TOKEN: ${JWT_TOKEN}
      SECURE_DOMAINS: devnotes.cuiyuehui.cn

密码不要写在 compose 文件里，放在同目录的 .env（记得加进 .gitignore）：

1
2
3

MYSQL_ROOT_PASSWORD=随机串
MYSQL_PASSWORD=另一个随机串
JWT_TOKEN=随机串

Waline 自己不会建表。 需要把官方的 waline.sql放在 compose 同目录，MySQL 首次初始化时会自动导入，建出wl_Comment / wl_Counter / wl_Users 三张表。少了它，接口会直接返回500 no such table: wl_Comment——这是我在本地实测时踩到的第一个坑。

配合前面 Nginx 里的 /comments/ 反代，前端配置只需要填：

1
2
3
4

comments:
  provider: waline
  waline:
    serverURL: https://devnotes.cuiyuehui.cn/comments

同域反代的好处是不用处理跨域，也不需要再申请一个子域名和证书。

部署完记得打开 https://devnotes.cuiyuehui.cn/comments/ui/register 注册管理员账号——第一个注册的账号自动成为管理员，注册后建议关闭注册入口。

七、备份

静态站点本身不需要备份（源文件在 Git 里），但有两样东西要定期备份：评论数据库、Nginx 与证书配置。

留言在 MySQL 里，用 mysqldump 导出成压缩文件，每天备份一次并只保留最近 14 天。--single-transaction 保证备份期间不锁表，服务不用停：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

#!/usr/bin/env bash
set -euo pipefail

source /opt/waline/.env          # 读取 MYSQL_USER / MYSQL_PASSWORD / MYSQL_DB
BACKUP_DIR="/backup/waline"
mkdir -p "${BACKUP_DIR}"

TARGET="${BACKUP_DIR}/waline-$(date +%F_%H%M).sql.gz"
docker exec devnotes-waline-mysql \
  mysqldump -u"${MYSQL_USER}" -p"${MYSQL_PASSWORD}" \
  --single-transaction --default-character-set=utf8mb4 "${MYSQL_DB}" \
  | gzip > "${TARGET}"

find "${BACKUP_DIR}" -type f -name 'waline-*.sql.gz' -mtime +14 -delete

恢复时把备份解开灌回去即可：

1
2

gunzip -c /backup/waline/waline-2026-09-20_0300.sql.gz \
  | docker exec -i devnotes-waline-mysql mysql -uwaline -p你的密码 waline

waline.sql、docker-compose.yml、backup-waline.sh 这几个文件在仓库的 deploy/waline/ 目录里都有现成的，不用自己敲。

踩坑记录

常见问题（FAQ）

静态博客需要多大配置的服务器？

1 核 2G 足够。Nginx 服务静态文件的资源消耗极低，一台最低配的 ECS 可以轻松支撑每天数千次访问。真正吃资源的是评论服务，如果需要自建 Waline 并启用数据库，建议 2 核 4G 起步。

为什么要用 rsync 而不是直接覆盖目录？

rsync 只传输变化过的文件，一次增量发布通常只需要几秒，而且不会把没在本地生成的文件误删。直接覆盖目录在文件多的时候会明显变慢，也容易留下旧文件。

部署后访问出现 403 或 404 是什么原因？

绝大多数是 Nginx 的 root 路径指向错误，或者文件权限不对。先确认 root 指向的目录里确实有 index.html，再确认 Nginx 运行用户对该目录有读取权限。

小结

• 顺序是：解析 → 装 Nginx → 同步文件 → 上证书。
• 缓存策略记住一条：HTML 不缓存，带指纹的资源长缓存。
• 用 rsync 增量同步，改动后用 --dry-run 确认。
• 同域反代评论服务，省掉跨域和第二个证书。

完整的配置文件和脚本都在本站的 deploy/ 与 tools/ 目录里，可以直接取用。部署过程中卡在哪一步，欢迎到留言板说说具体报错。

如果站点还没搭起来，先看《用 Hexo + Stellar 搭一个对 AI 友好的技术博客》；如果之后要改地址结构，注意看《站点改版后 URL 变了，怎么保住已有的引用》。

为什么是 Hexo + Stellar

选型理由其实很简单：

我不需要 CMS，也不需要在线编辑。写作流程应该只有一件事：新建一个 Markdown 文件，写完推送。

目录结构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

blog/
├── _config.yml              站点配置（网址、链接格式、插件）
├── _config.stellar.yml      主题配置（布局、颜色、评论、注入）
├── scripts/
│   └── geo.js               GEO 生成器：robots.txt / llms.txt / 结构化数据
├── source/
│   ├── _posts/              文章
│   ├── _data/
│   │   ├── authors.yml      作者档案
│   │   ├── widgets.yml      自定义侧栏组件
│   │   └── topic/           专栏定义
│   ├── about/index.md       关于页
│   ├── message/index.md     留言板
│   └── images/              图片资源
└── tools/                   部署与辅助脚本

把内容、配置、脚本分开放，是长期维护的前提。 主题升级时只需要替换 node_modules 里的包，自己的内容一点不受影响。

三处对 GEO 真正有影响的设置

一、固定链接改成英文路径

1
2
3
4
5

# _config.yml
permalink: posts/:title/
pretty_urls:
  trailing_index: false
  trailing_html: false

文章文件名用英文，标题仍写中文：

1

source/_posts/what-is-geo.md   → https://devnotes.cuiyuehui.cn/posts/what-is-geo/

这样做的好处：

• URL 里没有中文编码，复制、分享、被引用时不会出错。
• 去掉 index.html 和 .html 后缀，链接更短。
• 路径稳定，已发布的 URL 不再改动，避免丢失已有的引用积累。

二、用脚本自动生成 llms.txt

手工维护 llms.txt 一定会忘记更新。本站的做法是在 scripts/geo.js 里注册一个生成器：

1
2
3
4
5

hexo.extend.generator.register("geo_llms_txt", function (locals) {
  const posts = locals.posts.sort("-date").toArray();
  // ... 组装标题、简介、分组链接
  return { path: "llms.txt", data: lines.join("\n") };
});

每次构建都会重新生成，同时输出完整正文版的 llms-full.txt。效果可以直接查看 llms.txt。

三、结构化数据自动注入

主题已经输出了 BlogPosting。我在 scripts/geo.js 里补了两类：

• BreadcrumbList：让机器知道这篇文章属于哪个分类。
• FAQPage：文章的问答对直接写在前面的 front matter 里。

1
2
3

faq:
  - q: 为什么用静态博客而不是 WordPress？
    a: 静态博客输出纯 HTML，不依赖后端渲染，抓取时不会出现空壳页面。

站点结构：为 GEO 设计的信息架构

内容组织方式对 GEO 的影响经常被忽略。本站的结构是：

1
2
3
4
5
6
7
8
9
10

/                       首页（文章列表）
/categories/            分类
/tags/                  标签
/topic/                 专栏索引
/topic/geo/             GEO 方法论专栏
/topic/geo-platform/    GEO 平台搭建专栏
/about/                 关于作者
/message/               留言板
/llms.txt               给模型的站点导览
/sitemap.xml            站点地图

三个设计考量：

1. 专栏承担主题聚类。 同类文章聚在一个专栏下，比散落在时间线里更容易被识别为完整主题。
2. 作者页负责说清楚"这是谁写的"。 读者看完一篇有用的文章，通常会想确认作者靠不靠谱，作者页要能正面回答这件事。
3. 留言板是唯一的交流入口。 不加复杂的表单，减少放弃率。

内容写作规范（本站自用）

写每篇文章时遵守这几条，已经固化成模板：

常见问题（FAQ）

为什么用静态博客而不是 WordPress？

静态博客的输出就是纯 HTML，不依赖后端渲染和数据库，抓取时不会出现空壳页面，正好满足 GEO 的第一层要求。同时部署简单、成本低、几乎没有被打穿的风险，对个人技术博客足够。

Stellar 主题需要改很多代码吗？

基本不需要。它提供了完整的配置项，布局、颜色、侧栏组件都可以用 YAML 配置完成。本站只额外写了一个构建脚本用来生成 llms.txt 和注入结构化数据，没有修改主题源码，这样主题升级时不会有冲突。

文章链接该用什么形式？

用英文文件名的固定链接，例如 /posts/what-is-geo/。中文标题不变但路径保持 ASCII，既避免编码问题，也让链接更短、更容易被引用。已发布文章的路径不要改动。

下一篇

站点生成好之后，就该放到服务器上了：《把 Hexo 博客部署到阿里云 ECS：Nginx + HTTPS 完整流程》。

为什么这件事必须自己建

搜索引擎有 Search Console 这类工具告诉你"被展示了多少次、被点击了多少次"。AI 搜索目前没有等价物。

这意味着两件事：

1. 你无法直接知道自己的内容有没有进过 AI 的答案。
2. 唯一的办法是站到用户的位置去提问，然后看模型回答里有没有你。

这本质上是抽样统计。抽样就要接受误差，所以设计上必须保证：样本固定、周期固定、判定规则固定。

监测链路

1
2
3
4
5
6
7
8
9
10

问题集（固定 20-50 条）
        ↓
任务调度（多平台 × 多问题）
        ↓
答案与来源解析
        ↓
引用判定 ──→ 命中：记录文章、位置、上下文
        └→ 提及：记录品牌名、无链接
        ↓
趋势看板 + 报告

一、问题集怎么设计

问题集是整个监测系统的基准，改一次就要重新累计趋势，所以要慎重。

三类问题配比

写作要求

• 用完整自然语言问句，模拟真实提问，而不是关键词堆叠。
• 一个问题只问一件事，避免"GEO 是什么、怎么做、多久见效"这种复合问题。
• 至少保留 5 个长期不变的问题，作为跨年的基线。

二、任务调度

调度层要解决三件事：别把平台的额度打爆、别被限流、失败要能重试。

1
2
3
4
5
6
7
8
9
10

# 伪代码：多平台采样调度
for question in question_set:
    for platform in platforms:
        task = enqueue(
            platform=platform,
            question=question,
            priority=question.weight,      # 品牌类优先
            timeout=90,
            retries=2,
        )

几个实际参数：

"未采样"和"未引用"必须分开记录。 早期版本我把超时直接算作未引用，导致趋势图上出现大量虚假下跌。

三、引用判定

这是整套系统里最容易做错的部分。判定分成三级：

判定规则要处理几种边界情况：

1
2
3
4

① 域名匹配要区分主域与子域      → 用 eTLD+1 比较，避免误判
② 短域名容易误伤                → 长度小于 5 的域名要求同时匹配标题
③ 品牌名可能有别名              → 维护别名表，如 "DevNotes" / "Dev Notes"
④ 同一答案引用多篇              → 每篇分别计数，不做去重

抽检机制

再好的自动规则也会有误差。我的做法是每次采样后人工抽检 10%：如果抽检发现误判率超过 5%，就调整规则并重新计算历史数据。

四、趋势看板

看板只放几个真正会用来做决策的指标，避免变成一个没人看的仪表盘：

"失守页面"这个指标特别有用。 它通常意味着对应内容已经不够新，或者被更完整的竞品内容替代了，是最直接的更新信号。

实测成本与准确率

跑了一个季度的实际数据：

准确率的关键在于承认不确定性。 报告里我始终同时给出采样量和置信提示，而不是把抽样结果包装成精确数字。

这份数据接下来怎么用

监测本身不产生价值，由监测驱动的动作才产生价值：

1. 某个问题从没被引用 → 说明缺少对应内容，补一篇。
2. 某篇文章被引用但内容过时 → 更新，并修改 dateModified。
3. 某个平台完全没引用 → 检查该平台更偏好什么类型的内容。
4. 竞品被引用而你没有 → 对比它在同一问题下的内容结构。

常见问题（FAQ）

为什么不能用接口直接拿到引用数据？

因为主流 AI 搜索产品都没有面向第三方的引用统计接口。要判断某篇文章是否被引用，只能主动提交问题、解析返回的答案与来源列表。这套方法本质上是抽样统计，所以在报告里必须同时给出采样量和置信区间。

采样成本大概是多少？

以 50 个问题、5 个平台、每两周一次为例，单次采样约 250 次查询。如果用带联网检索的 API，单次成本在几元到几十元量级，一年下来通常在几百元以内，远低于人工检查的时间成本。

引用判定怎么做得更准？

分三步：先用域名匹配判断是否指向目标站点，再用标题和关键句相似度确认引用的是哪一篇，最后人工抽检 10% 的结果修正规则。纯域名匹配会漏掉品牌提及，纯文本匹配会误判。

专栏小结

三篇文章覆盖了自建 GEO 平台的完整路径：

• 架构与技术选型：先确定边界，再选组件。
• 内容采集与结构化：把网页变成可检索的片段。
• 本文：把"有没有被引用"变成可追踪的指标。

如果你自己也在做收录监测，欢迎到留言板聊聊你的判定规则——"什么算被引用"这件事目前没有标准答案，多几个样本会更有意思。

流水线全貌

五个环节里，"标题切分"是对最终效果影响最大的一步，也是最容易被草率处理的一步。下面逐个说明。

一、抓取：先解决"能不能进得来"

抓取环节的关键约束不是速度，而是不被封、不浪费时间。

我用的是这套参数：

关于 robots.txt：平台默认遵守，不提供绕过选项。 这是底线——一个能"绕过规则"的工具，最后往往会把麻烦留给你自己。

二、正文提取：通用算法 + 定向规则

中文站点的正文提取有两个坑：

1. 部分页面正文在 div 里而不是 article 标签里，通用算法会漏。
2. 有些站点把推荐阅读、作者简介混在正文区域，通用算法会多。

我的处理策略是分层的：

1
2
3

第一层：通用算法（可读性打分）        → 覆盖约 80% 的站点
第二层：站点专用选择器（按域名配置）  → 覆盖高频目标站点
第三层：人工复核队列                  → 处理前两层都失败的页面

专用选择器配置化，不用改代码：

1
2
3

example.com:
  content: "article.post-content"
  remove: [".ad", ".related-posts", ".author-box"]

实测下来，加上第二层之后，正文提取的准确率从 78% 提升到 96%，而需要人工复核的比例从 22% 降到 4%。

三、标题切分：决定检索质量的一步

为什么按标题切

固定长度切分的最大问题是会把一个完整论证切成两半，或把两个不相关的主题拼在一起。按 h2 / h3 切分则天然尊重作者组织内容的边界。

实测的粒度对比

我在同一批 1200 篇文章上做了对比，用"能否在检索时找回原文对应段落"作为评价标准：

结论很明确：按标题切分并给超长小节做二次切分，是性价比最高的方案。

具体规则

1
2
3
4

1. 以 h2 / h3 为边界切分，标题作为该片段的 caption
2. 片段超过 700 字时，按句子边界二次切分，重叠 80 字
3. 片段小于 120 字时，与前一个片段合并
4. 每个片段保留：所属文章标题、URL、发布时间、h1-h3 路径

第 4 条特别重要。片段单独被检索出来时，只有带上"它来自哪篇文章的哪一节"，才有可解释性。

四、质量打分：筛掉脏数据

抓来的内容不都需要入库。我用了一个简单的加权打分：

总分低于 0.4 的片段进人工复核队列，高于 0.75 的直接入库并提高检索权重。

这一步的价值在排查问题时特别明显。 没有质量分层，检索结果不准确时你无法判断是算法问题还是数据问题，只能盲调参数。

五、入库：结构化与向量并存

每个片段在数据库里存两份信息：

1
2
3
4
5

-- 结构化字段：用于过滤和排序
article_url, article_title, heading_path, published_at, updated_at, source_type

-- 向量字段：用于语义检索
embedding vector(1024)

检索时先按结构化条件过滤（例如"只查近一年、只查技术类"），再做向量相似度排序。先过滤再检索，比全量检索快一个数量级，也更准。

失败与降级

流水线必须假设每一步都会失败：

1
2
3
4

抓取失败  → 重试 3 次 → 仍然失败则记录并跳过，不阻塞队列
提取失败  → 尝试站点专用规则 → 仍失败进入人工队列
切分异常  → 退化为按段落切分，并标记低置信度
向量化失败 → 保留结构化数据，标记待补向量，可事后重跑

原则是：任何一环失败都不应该让整批任务停住。 我早期的版本就是因为一条坏数据让整个队列卡了 6 小时。

常见问题（FAQ）

片段切多大比较合适？

实测 300 到 700 个中文字符是较优区间。太小会丢失上下文，太大则一段里混杂多个主题，向量表示被平均掉，检索准确率反而下降。按标题层级切分、再对超长小节做二次切分，是稳定可用的做法。

正文提取用现成库还是自己写规则？

先上现成库处理 80% 的常规页面，再针对高频目标站点补专用规则。完全自己写规则的成本远高于预期，而完全依赖通用库在部分中文站点上会丢掉正文。

质量打分有什么用？

它决定了哪些内容进入检索库、哪些需要人工复核。没有打分，低质量页面会稀释检索结果，让你在排查问题时误以为是检索算法不准，实际上是数据脏。

下一篇

数据进来之后，最有价值的一层是它到底有没有被 AI 引用：《自建 GEO 平台（三）：AI 收录监测与效果度量》。

你的流水线里如果遇到类似的坑，欢迎到留言板说说，也许有更省事的做法。

先明确要解决的问题

我在动手之前列了一张需求清单，按优先级排：

1. 给定一批主题词和问题集，能自动检查目标站点是否被 AI 引用。
2. 能抓取并解析目标站点的内容，判断它是否具备被引用的条件。
3. 能把我自己的内容资产结构化，方便复用和改写。
4. 能定期出报告，告诉我"哪些页面被引用了、哪些没有、原因是什么"。
5. 全流程跑在一台服务器上，不引入需要专职运维的组件。

第 5 条是硬约束。它直接决定了后面所有的技术选型。

整体架构

四层各自的职责：

关键选型一：为什么是 pgvector 而不是专用向量库

这是被问得最多的一个问题。先看数据：

在 100 万条以内，两者的延迟差距对交互式体验没有实质影响。而省掉一套独立集群，意味着少一套备份策略、少一套监控告警、少一个半夜可能挂掉的组件。

真正需要专用向量库的临界点，通常是千万级向量加上高并发检索。 中小型 GEO 平台很难触达这个量级。

性能够用的判断也可以量化：单次检索延迟在 100 ms 以内、写入吞吐能跟上增量更新、备份和恢复流程能在半小时内跑完——三条都满足，就没有换的必要。

关键选型二：服务层怎么切

服务层我切成三个独立进程，而不是做成一个大单体：

1
2
3

geo-diagnose   无状态 HTTP 服务   ← 接收 URL / 站点，返回诊断结果
geo-scheduler  定时任务           ← 抓取、采样、生成报告
geo-reporter   事件驱动           ← 监听采样结果，产出报告与通知

切分的依据是变更频率：诊断逻辑每周都在调，调度周期很稳定，报告格式经常改。放在一起会导致每次改报告都要重启整个服务。

三者通过数据库和消息表通信，不引入独立的消息队列——对当前规模来说，一个带状态的表加轮询完全够用，而且更容易排查问题。

关键选型三：抓取环节的取舍

抓取是整个平台最不可控的部分。我的处理方式：

一个实测数据：在 4 核 8G 的 ECS 上，单进程抓取 200 个站点的首页与核心页面，总耗时约 12 分钟，峰值内存 900 MB。瓶颈在网络带宽而不是 CPU。

存储与运维

1
2
3
4
5

PostgreSQL 16 + pgvector   结构化数据 + 向量索引
对象存储                    抓取快照、报告附件
Redis                       缓存与限流计数
Docker Compose              全部服务的编排
Nginx                       反向代理与 HTTPS

整套东西用一份 docker-compose.yml 管起来，docker compose up -d 就能跑。备份用一个 nightly 的 pg_dump 加对象存储同步，恢复演练每季度做一次。

这套架构的边界

坦白说，这套设计有几处明确的取舍，如果规模变化需要重新考虑：

• 数据量超过 500 万片段，需要把向量检索拆出去，或者对数据分片。
• 同时监测的站点超过 20 个，需要把调度从单进程改为分布式队列，否则任务会排队。
• 需要实时反馈（用户点一下等 3 秒出结果），需要给诊断接口单独做缓存层，当前是分钟级。

写清楚边界比写清楚优势更有用——知道什么情况下它会失效，才能判断它适不适合你的场景。

常见问题（FAQ）

为什么不用专用的向量数据库？

在数据量小于 100 万条片段时，pgvector 的性能和专用向量库差距不明显，但省掉了一整套运维成本。真正需要专用向量库的临界点通常是千万级向量加上高并发检索，中小型 GEO 平台很难触达。

一台 4 核 8G 的服务器能撑住吗？

能。本站的平台在 4 核 8G 的阿里云 ECS 上运行，覆盖约 200 个站点的抓取与 50 万条片段的检索，日常 CPU 占用在 20% 以下。瓶颈通常出现在抓取阶段的网络带宽，而不是计算。

平台需要接入多少个大模型？

建议至少两个。一个用于便宜、量大的内容分析任务，另一个用于质量要求高的判断任务。同时接入多个平台用于引用采样，也能避免单一模型的偏差。

下一篇

架构确定之后，最难的部分是内容采集与结构化流水线：《自建 GEO 平台（二）：内容采集与结构化流水线》。

如果你也在搭类似的东西，或者在选型上纠结，欢迎到留言板聊聊——我很想知道别人是怎么权衡的。

第一层：抓取健康度

这是前提层。如果抓取不正常，后面所有指标都没有意义。

统计 AI 爬虫的访问量，用一条命令就能看到大致情况：

1
2
3

# 统计最近日志里各 AI 爬虫的访问次数
grep -iE "GPTBot|ClaudeBot|PerplexityBot|Bytespider|CCBot|Google-Extended" /var/log/nginx/access.log \
  | awk '{print $NF}' | sort | uniq -c | sort -rn

如果一台跑了一个月的博客没有任何 AI 爬虫访问记录，先别急着优化内容，去检查 robots.txt、CDN 拦截规则和防火墙。

第二层：引用与提及率

这一层是 GEO 的核心。麻烦之处在于，主流 AI 搜索没有提供公开的引用统计接口，只能用采样方式估算。

采样方法

1. 固定问题集。 挑 20 到 50 个目标用户会问的问题，写成完整自然语言句子。
   • 例如："GEO 和 SEO 有什么区别"
   • 而不是："GEO SEO 区别"
2. 固定工具。 至少在 2 到 3 个 AI 搜索产品里跑同一组问题，比如 Perplexity、ChatGPT 联网搜索、豆包、元宝。
3. 记录三个字段。 每次采样记下：是否被引用（有链接）、是否被提及（有名字但无链接）、答案与你原文的观点是否一致。
4. 固定周期。 每两周一次，把结果记进表格。

记录表结构

跑上两三个月，趋势就出来了。重点不是单次结果，而是引用比例的变化。

两个容易忽略的指标

• 零点击曝光。 用户看完答案就离开，但已经记住了你的名字。这类曝光不会出现在流量统计里，却会带来后续的直接访问和品牌搜索。
• 引用一致性。 如果你的观点被引用后发生了明显变形，说明原文的表述还不够明确，需要把结论写得更"抗误读"。

第三层：业务结果

对本站来说，这才是最终指标——有没有人因为看到内容而联系我。

可以追踪的信号：

最后一条需要特别说明：很多 AI 产品跳转过来的流量会被识别为直接访问。 所以不要因为"referrer 里没有 AI 来源"就认为 GEO 没用。

一套组合起来看的看板

别做的事

最后列几条我踩过的坑：

1. 别用单次 AI 回答下结论。 模型输出有随机性，一次没被引用说明不了任何问题。
2. 别为了引用率去迎合模型。 内容如果对人不友好，长期一定失败。
3. 别忽略抓取层。 我见过太多"内容很好但从未被抓取"的站点，所有后续优化都是空转。
4. 别只看自己。 采样时同时记录竞争对手被引用的次数，才知道自己处于什么位置。

常见问题（FAQ）

为什么不能只看流量来判断 GEO 效果？

因为 AI 搜索的价值很大一部分不在点击上。用户看完模型生成的答案就离开了，但他已经看到了你的品牌或作者名。这种"零点击曝光"不会出现在分析工具里，却会显著影响后续的搜索和主动访问。

多久采样一次比较合适？

建议每两周一次，每次固定一组 20 到 50 个问题。频率太低看不出趋势，太高会被模型输出的随机性干扰。

新站多久能看到引用？

如果是新域名，先等收录和抓取正常（通常 2 到 6 周），再谈引用。在没被正常抓取之前，做任何引用监测都没有意义。

小结

• 抓取健康度是前提，引用率是核心，业务结果是终点。
• 引用率靠固定问题集定期采样，看趋势不看单点。
• 零点击曝光和直接访问里藏着 GEO 的收益。
• 下一步可以看《自建 GEO 平台的收录监测模块》，那里把这套采样做成了可自动化的系统。

如果你也在搭监测，欢迎到留言板聊聊你的指标设计和采样方式——这块没有标准答案，多几个样本会更有意思。

模板骨架

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

# 标题：包含核心概念 + 明确价值

**直接回答**：用 2-3 句话给出完整结论，不铺垫。

<!-- more -->

## 这个问题的背景
一段话说清为什么值得解决，控制在 3-5 行。

## 核心方法（可拆多个小节）

### 小节一：先给结论，再给理由
### 小节二：同上

## 边界与例外
这个方法在什么情况下不适用。

## 常见问题（FAQ）
### 问题一？
答案。

## 小结
- 3 到 5 条要点

## 参考资料
- 可核查的外部来源

下面逐段解释为什么这样排。

一、标题：用一个概念说清一件事

标题要做三件事：包含核心术语、包含读者会搜的表达、承诺一个具体结果。

一个实用技巧：把标题写成用户会问 AI 的那句话。 用户问什么，AI 就来检索什么。

二、结论区：前 100 字决定成败

开头的 2 到 3 句话必须自成一体，即使被单独摘出来也能回答标题提出的问题。原因很直接：模型在做片段匹配时，开头段落是最容易被选中的片段之一。

1
2

**直接回答**：GEO 优化的最小单位是段落，不是页面。
一段包含明确事实和结论的话，比八段含糊的铺垫更容易被引用。

不要把结论留到最后。学术写作习惯"先论证后总结"，这在 GEO 下是反向的。

三、问题定位：给内容设定边界

一段话说明"这篇文章解决谁的什么问题、在什么前提下"。它的作用是过滤掉不相关的检索，让真正匹配的问题更容易命中。

1
2
3
4

## 这个问题的背景

如果你已经有稳定的内容产出，但发现 AI 回答相关问题时从不引用你的站点，
那么问题通常不在内容质量，而在内容的可解析性。本文讨论后者。

四、方法主体：每个小节自带结论

这是最关键的一段。写法上遵循三条规则：

1. 每个 h2 / h3 都是一个可以独立成立的判断，而不是"第一部分""接下来"这类空标签。
2. 小节的第一句话就是结论，后面再展开理由和细节。
3. 一节讲一件事，控制在 200 到 500 字。

对比一下：

❌ ## 三、具体操作 / "首先我们需要做一些准备工作，然后……"

✅ ## 先修 robots.txt，再动内容 / "顺序反了会让后面所有优化都白做，因为爬虫根本进不来。具体做法是……"

后者的每个小节，都在为模型提供一段可以直接复用的答案素材。

五、边界说明：把可信度补上

明确写出"不适用"的情形，有三个好处：避免误导读者、提高被引用的准确性、在重排阶段体现出内容的严谨性。

六、FAQ：把问答对显式化

FAQ 不只是给读者看的，也是给机器看的。写成问答对之后，它可以被直接提取为一组独立的问题与答案。

建议放在文章末尾，和正文的小节内容呼应但不重复。每篇 3 到 5 个问题，答案 40 到 120 字。

如果站点支持结构化数据，把这些问题同步到 FAQPage 的 JSON-LD 里，效果更好——本站就是这么做的。

七、参考资料：给结论装上路标

引用论文、官方文档、规范原文，能同时提升可信度和可核查性。

1
2
3
4

## 参考资料

- [GEO: Generative Engine Optimization（KDD 2024）](https://arxiv.org/abs/2311.09735)
- [llms.txt 规范](https://llmstxt.org/)

不要引用无法访问的链接，也不要用二手转述代替原文——被引用来源的可核查性会传递到你的页面上。

改写前后对比

改写前（典型的"自嗨型"技术文）：

关于 GEO，最近有很多讨论。随着大模型的发展，越来越多的公司开始关注这一领域。我们在实践中也做了一些探索，这里分享一下经验。

改写后：

直接回答：GEO 优化的最小单位是段落，不是页面。原因是模型在检索时会把网页切分成片段做匹配，只有片段本身语义完整、包含明确结论，才可能进入最终答案。本文给出可复用的段落写法。

同样的信息量，改写后的版本在被检索、被引用上都更有优势，因为它第一句就回答了问题。

常见问题（FAQ）

套用模板会不会让文章看起来千篇一律？

结构统一不等于内容雷同。模板固定的是信息的排列顺序，不是观点本身。读者和模型都更偏好稳定的结构，因为找信息更快。真正需要个性化的是判断、数据和案例。

文章写多长比较合适？

以"能不能完整回答一个问题"为标准，而不是字数。多数技术问题在 1200 到 3000 字之间可以讲透。如果超过 4000 字还在展开，通常说明应该拆成多篇互相链接的文章。

为什么要在文章里写适用边界？

边界是可信度的一部分。写明"这个方法适合什么规模、什么前提"，会让结论更可核查，也避免被误用。模型在重排时也会偏好带有明确前提条件的内容。

小结

• 标题写成用户会问 AI 的那句话。
• 开头 100 字给出完整结论，不要铺垫。
• 每个小节自带结论，一节只讲一件事。
• 用边界说明补充可信度。
• FAQ 显式写成问答对，并同步到结构化数据。

下一篇：《怎么衡量 GEO 到底有没有效果》。

把这套写法用到你自己的文章上时，改完如果效果和预期不一样，欢迎到留言板说说你观察到的差异。

写完之后想确认内容有没有信息增量，可以用《用 AI 写的内容能不能被 AI 引用》里的四个问题自查。

为什么结构化数据对 GEO 特别重要

回到检索链路：模型会把页面切成片段再做相似度匹配。片段一旦脱离上下文，"这段文字在讲什么"就变得模糊。

结构化数据在这里提供的是页面级的确定性：

• 这篇内容是什么类型（文章？问答？产品页？）
• 标题、摘要、发布时间、更新时间分别是多少
• 作者是谁，有什么身份背景
• 文中的问答对可以被拆成独立的问题与答案

对模型来说，这些字段是已经解析好的结构化输入，不需要从 HTML 里猜。同等内容质量下，解析成本更低的一方通常更容易被选中。

优先级排序

一、BlogPosting：最基础也最容易被做错

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "结构化数据怎么做才对 GEO 有用",
  "description": "按投入产出比排出四种最值得加的结构化数据。",
  "datePublished": "2026-08-11",
  "dateModified": "2026-08-11",
  "author": {
    "@type": "Person",
    "name": "张三",
    "url": "https://example.com/about/"
  },
  "publisher": {
    "@type": "Organization",
    "name": "示例站点"
  },
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://example.com/posts/structured-data-for-geo/"
  },
  "keywords": "结构化数据, JSON-LD, Schema.org",
  "inLanguage": "zh-CN"
}

最常见的三个错误：

1. dateModified 和 datePublished 永远相同。 文章更新过就应该改 dateModified，它是最直接的新鲜度信号。
2. author 只写一个字符串。 "author": "张三" 是合法但信息量极低的写法，用对象并带上 url 和 sameAs 才能建立实体。
3. mainEntityOfPage 与 canonical 不一致。 两个地址指向同一内容时，模型无法确定哪个才是原文。

二、BreadcrumbList：让模型知道你的内容归属

1
2
3
4
5
6
7
8
9

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    { "@type": "ListItem", "position": 1, "name": "首页", "item": "https://example.com/" },
    { "@type": "ListItem", "position": 2, "name": "GEO 工具箱", "item": "https://example.com/categories/geo-tools/" },
    { "@type": "ListItem", "position": 3, "name": "结构化数据怎么做才对 GEO 有用", "item": "https://example.com/posts/structured-data-for-geo/" }
  ]
}

它的隐性价值是主题聚类。当模型看到十几篇文章都挂在同一个分类下，会更容易把它们识别成一个完整主题体系，这对建立领域权威很有帮助——而领域权威正是被优先引用的重要条件。

三、FAQPage：把问答对直接喂给模型

这是对 GEO 最"对症"的一种类型，因为 AI 搜索要回答的正是问题。

1
2
3
4
5
6
7
8
9
10
11
12
13
14

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "结构化数据会直接提升 AI 引用率吗？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "不会立竿见影。它解决的是机器能不能准确理解这段内容是什么。"
      }
    }
  ]
}

两个实践建议：

• 问答必须真的出现在正文里。 只在 JSON-LD 里写、页面上看不到，属于垃圾标记，有被判定作弊的风险。
• 答案控制在 40 到 120 字。 太短没有信息量，太长会被截断，反而失去作为独立答案的价值。

四、Person：让"你是谁"变成可检索的实体

1
2
3
4
5
6
7
8
9
10
11
12

{
  "@context": "https://schema.org",
  "@type": "Person",
  "name": "张三",
  "url": "https://example.com/about/",
  "jobTitle": "技术博主",
  "knowsAbout": ["生成式引擎优化", "AI 搜索", "结构化数据"],
  "sameAs": [
    "https://github.com/your-account",
    "https://x.com/your-account"
  ]
}

sameAs 的作用是跨平台身份对齐。当模型发现同一个名字在多个可信平台上指向同一个人，作者的可信度会显著上升。这直接服务于 GEO 的第三层——可信任。

怎么落地到静态博客

本站用 Hexo + Stellar，落地方式分两部分：

1. 文章级数据由主题生成：BlogPosting 由主题自动输出，包含标题、描述、时间、作者、标签。
2. 额外数据由构建脚本注入：scripts/geo.js 在页面渲染完成后，把 BreadcrumbList 和 FAQPage 插入 </head> 之前。FAQ 数据直接写在文章的 front matter 里：

1
2
3

faq:
  - q: 结构化数据会直接提升 AI 引用率吗？
    a: 不会立竿见影。它解决的是机器能不能准确理解这段内容是什么。

这样写作者只需要在文章的 front matter 里维护问答，JSON-LD 会自动生成，不会出现"页面改了但结构化数据忘了改"的情况。

自检清单

• 每篇文章都有 BlogPosting，且 dateModified 是真实更新时间
• mainEntityOfPage 的地址与 canonical 完全一致
• author 是对象而不是字符串，且指向可访问的作者页
• 有分类结构的站点输出 BreadcrumbList
• 有 FAQ 的文章输出 FAQPage，且问答在正文可见
• Person 的 sameAs 填的是真实存在的外部主页
• 用 Schema Markup Validator 校验过，没有报错

常见问题（FAQ）

结构化数据会直接提升 AI 引用率吗？

不会立竿见影。它解决的是机器能不能准确理解这段内容是什么，属于必要条件而不是充分条件。没有结构化数据，模型仍可能读懂；有了它，解析成本更低、出错更少，在同等内容质量下更容易被选中。

JSON-LD、Microdata、RDFa 该选哪个？

首选 JSON-LD。它写在 script 标签里，与页面视觉结构解耦，改动排版不会破坏数据，也是搜索引擎官方推荐的形式。

一篇技术文章需要加多少种结构化数据？

三种就够：BlogPosting 说明这是篇文章，BreadcrumbList 说明它在站点里的位置，FAQPage 在文中有问答时补充。作者信息作为 Person 挂在 BlogPosting 里即可。

下一篇：《GEO 内容写作模板：让 AI 一眼看懂你的文章》。

加完之后建议用 Google 的富结果测试工具自查一遍，最容易出错的是图片地址、作者信息和日期格式。结果对不上，欢迎到留言板贴出来一起看。

内容被转载或改写之后怎么让溯源更容易，见《内容被 AI 改写后传播，该如何处理》。

llms.txt 想解决什么问题

传统抓取面对一个网站时，看到的是几百个 HTML 文件。爬虫只能靠链接结构和页面元信息猜测"哪些内容重要"。

llms.txt 提供了一个人也能读、模型也能读的入口：

1
2
3
4

https://example.com/
├── robots.txt      给爬虫的规则
├── sitemap.xml     给搜索引擎的 URL 清单
└── llms.txt        给大模型的内容导览  ← 本文的主角

它的设计意图很明确：在模型做检索之前，先给它一份结构化的目录和摘要。

文件结构：四个部分

按照 llmstxt.org 的约定，文件由四部分组成：

关键约束是：链接必须是 Markdown 列表格式，这样解析器可以稳定提取。

一份可直接套用的模板

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

# 你的站点名

> 这是给大模型看的站点说明书：记录 XXX 领域的技术原理与落地实践。

本站作者是 XXX，有 N 年 XXX 经验。内容面向……
引用请注明出处：https://example.com/

## 站点资源

- 首页：https://example.com/
- 归档：https://example.com/archives/
- 关于作者：https://example.com/about/
- RSS：https://example.com/atom.xml
- 许可证：CC BY-NC-SA 4.0

## 入门系列

- [文章标题](https://example.com/posts/xxx/)：一句话说明这篇文章解决了什么问题
- [文章标题](https://example.com/posts/yyy/)：一句话说明这篇文章解决了什么问题

## 实战系列

- [文章标题](https://example.com/posts/zzz/)：一句话说明这篇文章解决了什么问题

几个写作要点：

1. 一句话简介要包含领域关键词。 写"记录 GEO 的技术原理与落地方法"，不要写"记录生活点滴"。
2. 每篇文章后面跟一句摘要。 这句话会直接影响模型判断这篇文章是否值得读。
3. 按主题分组，而不是按时间排序。 目录的价值在于结构，不在于时间线。
4. 写清许可协议。 明确"可以引用但需注明出处"，比含糊其辞更有利于传播。

llms-full.txt 要不要一起做

llms.txt 只给目录，模型仍需要逐个抓取页面。llms-full.txt 则把全部正文放进一个文件里，一次读完。

两者的取舍很直接：

我的建议是：中文技术博客同时提供两份。 如果内容涉及付费产品或核心竞争力，只提供 llms.txt 即可。

怎么实现：让它自动生成

手工维护 llms.txt 最大的问题是会忘记更新。正确做法是让它在构建时自动生成。以 Hexo 为例，在 scripts/ 目录下注册一个生成器即可：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

// scripts/llms.js
hexo.extend.generator.register("llms_txt", function (locals) {
  const posts = locals.posts.sort("-date").toArray();
  const lines = [
    `# ${hexo.config.title}`,
    "",
    `> ${hexo.config.description}`,
    "",
    "## 文章",
    ""
  ];
  posts.forEach(post => {
    lines.push(`- [${post.title}](${post.permalink})：${post.description || ""}`);
  });
  return { path: "llms.txt", data: lines.join("\n") };
});

这样每次构建，llms.txt 都会跟着文章列表自动更新。本站就是这么做的，可以直接查看实际的 llms.txt 和 llms-full.txt。

同时更新 robots.txt

在 robots.txt 里显式说明它的存在，让爬虫更容易发现：

1
2

# AI 摘要入口： https://example.com/llms.txt
Sitemap: https://example.com/sitemap.xml

现在是投入的好时机吗

坦白说，llms.txt 目前的实际采用率远低于它在技术社区的讨论热度。判断它值不值得做，我建议用这个标准：

一个更务实的判断是：llms.txt 的投入成本大约是半小时，而且不会带来任何负面影响。 在这种投入产出比下，"等等看"通常不是最优策略。

常见问题（FAQ）

llms.txt 现在真的被使用了吗？

还没有成为统一标准。Anthropic 等厂商公开支持该约定，但主流大模型的实时检索仍以传统爬虫和网页解析为主。它更像低成本的基础设施投资：写了不一定立刻生效，不写则没有任何机会，而且文件本身无害。

llms.txt 和 sitemap.xml 有什么区别？

sitemap.xml 只告诉爬虫有哪些 URL，不表达重要性和内容摘要；llms.txt 是 Markdown 格式，可以写清楚每篇文章讲什么、哪些是重点、许可协议是什么。前者服务于索引，后者服务于理解。

llms-full.txt 会不会导致内容被无偿使用？

有这个可能，所以建议在文件开头明确写出许可协议与引用要求。对希望内容被更多人读到的技术博客来说，被引用通常比被保护更有价值；如果内容涉及付费产品，可以只输出摘要而不输出全文。

小结

• llms.txt 是给模型的内容导览，不是搜索引擎的替代品。
• 结构简单：标题 + 一句话简介 + 分组链接列表。
• 关键是自动生成，否则一定会过期。
• 中小技术博客可以再加一份 llms-full.txt。

本站 GEO 工具链的其余几篇：《结构化数据怎么做才对 GEO 有用》、《robots.txt 里的 AI 爬虫该怎么配》、《怎么衡量 GEO 有没有效果》。

如果你想给自己的站点加上这份文件，遇到问题欢迎到留言板一起看看。

先看完整链路

1
2
3
4
5
6
7
8
9
10
11

用户提问
   ↓
① 查询改写     把口语问题改写成多个检索式
   ↓
② 召回检索     从索引里捞出几十到几百个候选片段
   ↓
③ 重排排序     用更贵的模型给候选打分，留下最相关的几个
   ↓
④ 正文读取     抓取或读取完整页面，补充上下文
   ↓
⑤ 生成答案     综合片段写答案，标注引用来源

下面逐段说明每一层在淘汰什么，以及你能做什么。

第 ① 步：查询改写

用户问的是"我们公司想做 GEO，从哪下手"，系统会改写成若干检索式，例如：

• GEO 落地步骤
• 生成式引擎优化 实施清单
• 企业 GEO 从哪里开始

这一层淘汰的是"术语不一致"的内容。 如果你的文章只写"生成式引擎优化"，而用户和改写结果用的是"GEO"或"AI 搜索优化"，可能根本进不了候选集。

可执行动作：

• 标题用主流叫法，正文开头补上同义解释。例如："GEO（生成式引擎优化，也叫 AI 搜索优化）……"
• 在站点上建立统一的术语表页面，让同一个概念有稳定的名称。
• 别为了显得专业而自创术语，除非你打算同时定义清楚。

第 ② 步：召回检索

系统把网页切分成片段（常见粒度是几百字），做向量化后存起来。提问时做相似度检索，捞出候选。

这一层淘汰的是"切不出好片段"的内容。

切分通常沿着标题层级和段落边界进行。如果你的文章是一整坨没有小标题的长段落，切分后每个片段都语意混杂，向量表示会变得"平均"，反而跟任何具体问题都不够像。

可执行动作：

• 用 h2 / h3 把文章切成语义完整的小节，每节 200 到 500 字为宜。
• 每个小节的第一句就是这个结论本身，别用"众所周知""话不多说"开场。
• 关键事实、数字、步骤写在正文里，不要只放在图片或代码注释中。

第 ③ 步：重排排序

召回结果通常是过量的，系统会用更精细的模型打分，只留下几个最相关的片段。打分时常见的偏好是：

1. 与问题的直接相关性
2. 是否包含明确的事实、数字、步骤
3. 来源的可信度（作者、站点声誉、是否有引用来源）
4. 信息的新鲜度

这一层淘汰的是"没有信息量"的内容。 含糊其辞、通篇铺垫、观点没有依据的段落，在这个阶段会被同领域的硬核内容挤掉。

可执行动作：

• 把结论、数字、前提条件写清楚，例如"在 4 核 8G 的 ECS 上，构建耗时约 40 秒"。
• 给出适用边界："这个方法适合日更不超过 3 篇的站点，超过就需要增量构建。"
• 标注真实更新时间，让系统知道这不是 2019 年的老文。

第 ④ 步：正文读取

进入这一层的页面会被实际抓取读取。这一层淘汰的是"抓不到、解析不了"的内容。

常见问题：

第 ⑤ 步：生成答案与标注来源

模型综合片段写答案，并给出引用。这里有两个细节值得注意：

第一，引用往往指向片段所在的页面，而不是你期望的首页。 所以每一篇文章都应该被当成独立入口来写，标题和描述要能独立成立。

第二，模型会回避不确定的来源。 一个没有任何作者信息、没有发布日期、没有任何外部引用的页面，即使内容不错，也更难被选为引用对象。

可执行动作：

• 每篇文章配一个能独立说明问题的标题和描述。
• 建立作者页面，写清身份、经验范围和联系方式。
• 关键结论给出可核查的外部来源（论文、官方文档、规范）。
• 用 JSON-LD 补充 BlogPosting、BreadcrumbList、FAQPage 等结构化数据。

把五步映射成一张检查表

常见问题（FAQ）

大模型是怎么"看到"我的网页的？

大多数 AI 搜索用的是检索增强生成（RAG）。系统先把你的网页抓取并切分成片段，存进向量数据库；用户提问时，用问题去检索最相关的片段，把它们拼进提示词交给模型，模型再根据这些片段组织答案。所以模型看到的往往不是你的整个页面，而是被切分后的若干片段。

为什么不设置 robots 也可能被引用？

训练语料和检索索引是两个不同的通道。有些模型的知识来自早期训练数据，即使你现在屏蔽爬虫，历史知识仍可能被复述。但实时检索通道会尊重 robots.txt 与访问限制，屏蔽之后新内容就很难被引用。

页面被切成片段后，标题还有用吗？

有用，而且比传统 SEO 更重要。片段在检索和重排时经常脱离上下文单独参与计算，段落自己的小标题往往就是它唯一的语义锚点。写清楚每个 h2 / h3，等于给每个片段贴了标签。

小结

理解这条链路之后，GEO 就不再是玄学：它是在为"片段"而不是"页面"做优化。 具体到写作上，就是让每一小段都能独立地被读懂、被复用、被核查。

接下来可以看两篇偏工具的：《llms.txt 完全指南》和《结构化数据怎么做才对 GEO 有用》。

如果你的内容始终没被引用过，欢迎到留言板说说具体情况，可以一起看是卡在抓取、理解还是信任这一层。

最本质的一个差异

传统搜索返回的是链接，AI 搜索返回的是答案。

这导致评估单位变了：

• SEO 的最小竞争单位是一个页面。页面整体质量高，就有机会排上去。
• GEO 的最小竞争单位是一个段落。模型在生成答案时，会把检索到的内容切成片段做相似度比较，最终只有少数片段进入上下文并被引用。

所以 GEO 的一个反直觉结论是：你的整篇文章可能不如你的某一段话有价值。 一段能被独立理解、包含明确事实和结论的话，比一篇结构松散的长文更容易被引用。

完整对照表

两者并不冲突，而是分层的

我习惯把两者的关系画成这样：

1
2
3
4

SEO 负责：让页面能被找到   → 抓取、索引、URL、速度、内链
GEO 负责：让内容能被引用   → 结构、事实、来源、作者、更新
─────────────────────────────────────────────
共同前提：内容本身解决真实问题

SEO 是地板，GEO 是天花板。 一个页面如果连收录都没有，谈不上被 AI 引用；但如果只做到收录，也未必进入任何一次 AI 回答。

实践中的分工建议：

1. 先补齐 SEO 基础：站点地图、canonical、移动端体验、内链、页面速度。
2. 再做 GEO 增量：结构化数据、llms.txt、问答式小节、作者可信度建设。
3. 最后统一度量：SEO 看流量，GEO 看引用和品牌提及，两者不能互相替代。

一个具体的例子

假设你写了一篇《阿里云 ECS 部署静态博客的完整流程》。

面向 SEO 的写法是这样组织的：

标题包含"阿里云 ECS 静态博客部署"；正文分章节覆盖购买服务器、安装 Nginx、配置 HTTPS、上传文件、常见问题；关键词自然出现若干次。

面向 GEO 的写法在此基础上多做三件事：

1. 每一节第一句话就是结论。 例如："先装 Nginx，再配证书，最后上传静态文件——顺序反了会出现证书校验失败。"模型需要的正是这句可以直接搬走的结论。
2. 把踩坑写成问答对。 "为什么上传后访问是 404？因为 root 指向的目录和 public/ 不是同一个路径。"这种句子几乎可以直接成为 AI 答案的一部分。
3. 给出可核查的版本与命令。 "Nginx 1.24 + Ubuntu 22.04 实测通过"比"Nginx 环境"更有引用价值。

同一篇内容，两套写法的工作量差别不大，但后者被引用的概率明显更高。

常见问题（FAQ）

SEO 还有必要做吗？

有必要，而且优先级通常更高。抓取、索引、站点地图、页面速度、canonical 这些 SEO 基本功是 GEO 的前提，一页不被收录的页面不可能被 AI 引用。区别在于做完基本功之后，SEO 继续优化的边际收益在下降，而 GEO 的边际收益在上升。

做 GEO 会不会伤害 SEO？

正常做法不会。GEO 强调的结构清晰、结论先行、来源可核查，同时也是搜索引擎喜欢的特征。唯一需要注意的是别为了"被引用"而把正文拆成碎片化短句堆砌，那会同时伤害两边。

关键词研究在 GEO 里还适用吗？

部分适用。关键词仍然反映需求，但 GEO 更关心"用户会怎么向 AI 提问"，也就是完整的自然语言问题。把关键词升级成问题句，再围绕问题组织小节，是更实用的做法。

小结

• 把 GEO 当成 SEO 的上层建筑，不要当成替代品。
• 优化颗粒度从"页面"下沉到"段落"和"问答对"。
• 每一节先给结论，再给论证；每个踩坑都写成可被直接引用的问答。
• 度量上分开看：流量归 SEO，引用归 GEO。

下一篇：《AI 搜索是怎么挑选内容的》，我们从检索链路讲起，看看模型到底在"读"你页面的哪一部分。

如果你分不清自己的站点卡在哪一层，欢迎到留言板把现象写出来，一起看看更可能是哪类问题。

一句话理解 GEO

传统搜索的流程是：用户输入关键词 → 搜索引擎返回十条蓝色链接 → 用户自己点开比较。

AI 搜索的流程是：用户提出一个问题 → 模型检索若干网页 → 模型读完之后直接给出答案 → 用户看到的是答案，而不是你的网站。

这个变化带来一个残酷但清晰的事实：在 AI 搜索里，"被点开"的机会变少了，但"被引用"的价值变高了。 你的内容不需要排在第一位，只需要成为模型用来组织答案的那几段素材之一。

GEO 要解决的就是后面这件事。

GEO 和 SEO 到底差在哪

几个容易踩的认知误区：

• 误区一：GEO 就是给 AI 写内容。 实际上模型更偏好"人写给人的、结构清楚的、能被验证的"内容。为了讨好模型而堆砌关键词，反而会因为可读性差被淘汰。
• 误区二：做完结构化数据就够了。 结构化数据解决的是"机器能不能解析"，解决不了"内容值不值得引用"。后者才是决定性的。
• 误区三：GEO 是一次性工作。 模型的知识与检索结果会持续更新，GEO 更接近一项需要按月维护的工程。

为什么现在值得投入

1. 流量入口正在迁移。 越来越多的人把"查资料"这个动作交给 AI 助手，而不是搜索引擎。入口走了，流量自然跟着走。
2. AI 回答天然只引用极少数来源。 一次回答通常只综合 3 到 8 个来源，这意味着进入这个名单的收益被显著放大。
3. 被引用自带信任背书。 用户看到"据某某站点的分析"，这比广告或搜索结果排名更有说服力。对个人博客尤其有价值：它让一个没有品牌背书的站点，也能成为别人眼里的可信来源。
4. 窗口期仍然存在。 大部分中文站点还没有系统性做 GEO，先做的站点更容易成为某个细分问题的默认信源。

GEO 的四个作用层

我把 GEO 拆成一个自下而上的四层模型，这个模型也是本站所有方法论的基础：

1
2
3
4

第 4 层  可引用  ← 结论明确、数据可靠、来源可追溯
第 3 层  可信任  ← 作者身份、真实经验、更新记录、引用来源
第 2 层  可理解  ← 标题层级、结构化数据、术语统一、语义完整
第 1 层  可抓取  ← robots.txt、站点地图、页面可访问、内容不依赖 JS

最常见的失败方式是跳级。 很多人直接去做第 4 层的内容技巧，却忽略了第 1 层——页面根本不被 AI 爬虫抓取，或者正文完全由 JavaScript 渲染，那么后面几层做得再好也没有意义。

反过来，如果你的站是静态站、正文在 HTML 里、有站点地图、允许 AI 爬虫访问，那么第 1 层基本已经达标，可以直接往上做。

一份可以直接执行的检查清单

下面这 12 条覆盖了四层模型里性价比最高的动作，按优先级排列。你可以拿它当自查表：

可抓取

1. robots.txt 里显式允许 GPTBot、ClaudeBot、PerplexityBot、Bytespider 等 AI 爬虫。
2. 提供 sitemap.xml 并在 robots.txt 中声明。
3. 正文内容在服务端就存在于 HTML 中，不依赖前端渲染。
4. 页面有稳定的、不带参数的永久链接。

可理解

5. 每篇文章只用一个 h1，用 h2 / h3 构成清晰的小节结构。
6. 输出 JSON-LD 结构化数据（BlogPosting、BreadcrumbList、FAQPage）。
7. 需求明确时提供 llms.txt 与 llms-full.txt。
8. 页面设置 canonical，避免同一内容有多个地址。

可信任

9. 有明确的作者页面，写清楚身份、经验和联系方式。
10. 文章标注真实发布与更新时间，更新过的内容同步修改 updated。
11. 关键结论引用可核查的外部来源（论文、官方文档、规范）。

可引用

12. 每个小节先给结论再展开；重要问题用"问题 → 答案"的问答结构写。

第 9 到 12 条经常被低估。模型在选择引用来源时，作者可信度和内容的可核查性权重很高——一个匿名站点声称"某方法有效"，远不如一个有署名、有实测数据、有代码的站点有说服力。

常见问题（FAQ）

GEO 和 SEO 是替代关系吗？

不是。GEO 是在 SEO 基础上的增量工作。抓取、收录、页面速度这些基础仍然由 SEO 负责，GEO 额外解决"内容能不能被模型选中并作为答案引用"的问题。两者共用同一套内容资产。

小站做 GEO 有意义吗？

有意义，而且在某些垂直领域反而更容易见效。大模型在回答具体、长尾、需要一手经验的问题时，会优先检索小体量的专业站点。只要你的内容在某个细分问题上比大站更具体，就有机会被引用。

GEO 多久能见效？

需要分两层看。站内技术层面的改造（结构化数据、llms.txt、可抓取性）通常在重新抓取后 1 到 4 周体现；内容被稳定引用一般需要 2 到 6 个月，取决于领域竞争度和内容更新频率。

下一步

理解概念之后，建议按这个顺序继续：

• 先看《GEO 和 SEO 有什么区别》，把两者的边界划清；
• 再看《AI 搜索是怎么挑选内容的》，理解模型的检索与引用链路；
• 然后看《AI 引用和 AI 训练是两件事》，分清这两条链路；
• 接着照着《GEO 内容写作模板》改一篇你自己的旧文章；
• 如果内容始终没被引用过，按《为什么 AI 从来不提我的网站》的六个环节排查；
• 准备系统推进时，照《小团队做 GEO 的第一个月该做什么》的四周计划走。

如果你想在自己站点上试试这张清单，从改一篇文章开始就够。过程中遇到问题，欢迎到留言板聊聊。