学 GEO 需要懂编程或技术基础吗？

先给答案，四句话

第一，学 GEO 不需要会编程。你不需要写出一个能跑的程序，也不需要读懂框架源码。

第二，你必须会五个技术动作：看服务器返回的原始 HTML、改 robots.txt 和 meta 指令、看状态码、校验结构化数据、读得懂两张报表和一份日志。这五件事全都不用写代码，一天能学会，一周能练熟。

第三，编程是放大器，不是入场券。它把「检查 10 个页面」变成「检查 1000 个页面」，把「这个月跑一次」变成「每天跑一次」。它不替你判断哪句话值得被引用。

第四，真正的门槛是判断力，不是语法。知道哪段内容该删、哪个数字必须带来源、哪次改动其实没起作用——这些东西，会写 Python 也教不了你。

一、学 GEO 需要懂编程吗？先把两个词拆开

这两个词经常被混着用，一混，问题就问不清了。如果你在搜索框里敲的是「学 GEO 需要懂编程吗」，下面这两段就是给你的答案。

会编程，指的是你能写出可运行的程序。比如写一个脚本，批量抓取 200 个页面，检查每页的标题、字数、有没有结构化数据，最后输出一张 CSV。这需要你懂变量、循环、函数、异常处理，大概几十个小时的投入。

懂技术基础，指的是你知道一个网页从服务器到模型嘴里，中间要经过哪几道关，以及每道关出问题时会有什么症状。你不需要自己修，但你要能指着症状说：「这是渲染问题，不是内容问题。」

打个比方。开车不需要会造发动机，但你必须知道仪表盘上那个红色的油壶灯亮起来代表什么。你知道了，就会靠边停车；你不知道，就会继续开，直到发动机报废。GEO 的技术基础，就是这块仪表盘。

我之所以要先拆这两个词，是因为市面上有两种说法，方向相反，但都在卖东西。

一种说：「GEO 就是内容活，会写字就行，技术不用管。」说这话的人，通常卖的是写作课或者内容代运营。另一种说：「GEO 是技术活，不会 Python 别来。」说这话的人，通常卖的是工具、爬虫或者技术顾问服务。

两种说法都只说对了一半。内容当然重要，但如果爬虫根本没读到你的页面，内容好坏没有意义；技术当然重要，但技术只能保证「有资格被引用」，不能保证「被引用」。

二、为什么 GEO 的技术错误，比 SEO 时代更隐蔽

这是整篇文章最想讲清楚的一件事。

先看这件事为什么值得讲。中国互联网络信息中心在 2026 年 9 月发布的《生成式人工智能应用发展报告（2026）》里有一组数字：截至 2026 年上半年，我国生成式人工智能用户规模突破 7 亿人，普及率超过 50%，其中 76.0% 的用户会让人工智能替自己回答问题。七亿人把「搜一下」换成了「问一句」，意味着你的页面多了一个读者，而这个读者不点链接、不看图片、只读文本。它读不到，你就等于没写过。

SEO 时代，技术问题是有反馈的。Googlebot 会执行 JavaScript，Google Search Console 会告诉你抓取了多少、索引了多少、哪些查询带来了展示。页面出了问题，报表上能看见。你不需要懂技术，也能从「已发现但未编入索引」这行字里猜到大方向。

GEO 时代，这套反馈机制断了大半。

第一，多数 AI 爬虫不执行 JavaScript。Vercel 和 MERJ 在 2024 年 12 月发布过一份实测，分析了自家网络上的爬虫流量：一个月内 GPTBot 抓了 5.69 亿次，Claude 抓了 3.7 亿次，Googlebot 是 45 亿次，前两家加起来大约是 Googlebot 的两成。

同一份数据里，最关键的一条是：这些 AI 爬虫都不渲染 JavaScript。GPTBot 有 11.50% 的请求下载了 JS 文件，Claude 是 23.84%，但它们只是把 JS 当文本存下来，不执行。能完整渲染的是 Google 系和 Apple：Gemini 复用 Googlebot 的渲染服务，Applebot 也有自己的浏览器渲染；而 GPTBot、ClaudeBot、PerplexityBot、Meta-ExternalAgent、Bytespider 都不执行。

这里要纠正一个流传很广的错误。2026 年不少文章把这份数据写成「2026 年最新研究」，但它发布于 2024 年 12 月 17 日，样本是 Vercel 网络和 nextjs.org 等站点。数据本身仍然是我查到的最扎实的一份，但它是 2024 年的，不是 2026 年的。引擎行为会变，所以我建议你每季度自己复测一次。复测方法不复杂：打开页面源代码，搜一句正文；搜不到，就说明不执行 JS 的爬虫也读不到。

第二，AI 引擎没有统一的站长后台。ChatGPT 没有 Search Console，Claude 没有，Perplexity 也没有。你没法像看 Google 那样，看到「它来了几次、读了哪几页、把哪段话当成了答案」。Google 在 2026 年 8 月 31 日向全球开放了 Search Console 的生成式 AI 效果报告，这是一大进步，但它只覆盖 Google 自己的 AI 概览和 AI 模式，而且只有展示次数，没有点击，也没有查询词。

第三，错误的表现形式变了。SEO 时代，技术出错的表现是「排名靠后」，你还有机会在第 3 页找到自己。GEO 时代，技术出错的表现是「完全不在答案里」，而你分不清原因：是内容不够好，还是整页没被读到，还是被 CDN 挡在门外。

技术盲区、反馈缺失、症状模糊，这三件事叠在一起，结论很清楚：在 GEO 里，技术基础的首要作用不是加分，是排除假阴性。

所谓假阴性，就是你其实做对了，但因为没有测到，误判成没做对。一个 React 站，页面在浏览器里漂漂亮亮，排名也不错，但 GPTBot 拿到的 HTML 是个空壳。你以为是内容不行，于是反复改文案，改了三个月，问题一点没动。真实原因在第一道关，而你手上没有仪表盘。

三、机器读一个页面，只做三件事

把链路简化到不能再简化，就是三步：取、渲、抽。（这条链路每一步的判定标准，我在《AI 是怎么决定引用哪个网站的》里拆得更细，这里只讲技术侧。）

这三步是串联的。第一步失败，后两步归零；第二步失败，第三步无从谈起。所以排查顺序永远是：先确认「取到了」，再确认「取到的是有内容的」，最后才谈「内容好不好」。

很多人一上来就改内容，改的是第三步，但问题在第一步。这就像餐厅菜不好吃，你先换了厨师，后来发现是送菜的门被锁了。

四、五个必须会的动作，全都不用写代码

下面这五个动作，是我认为「做 GEO 的最低技术配置」。它们不需要你写程序，但需要你动手。

动作一：看服务器第一次给你的那份 HTML

为什么：因为那才是 AI 爬虫看到的东西。浏览器里你看到的是执行完 JavaScript 之后的 DOM，两者可能差出一整篇文章。

怎么做：打开页面，右键「查看网页源代码」，或者按 Ctrl+U。然后在源码里搜一句你正文里的话。搜得到，说明爬虫能读到；搜不到，只在「元素」面板里能搜到，说明这段内容是 JS 渲染出来的。

更严谨的办法是用命令行，模拟爬虫的 User-Agent：

curl -s -A "Mozilla/5.0 (compatible; GPTBot/1.2; +https://openai.com/gptbot)" \
  https://example.com/your-page | grep -c "你想验证的那句话"

返回 0，就是没有。返回大于 0，就是有。

验收标准：你能对任意一个页面，在 30 秒内回答「这句正文在不在原始 HTML 里」。

依据：Google 的 JavaScript SEO 文档把抓取、渲染、索引写成三个阶段，渲染是单独的、可能延迟的一步。对不执行 JS 的爬虫来说，没有这个延迟的第二步，第一次抓取就是唯一一次。

动作二：改 robots.txt 和 meta，并知道每条指令的后果

为什么：robots.txt 是准入，meta 指令是展示权限。这两样东西写错，后面全白做。

怎么做：先认清几个常见的 UA 各管什么。下面是各家官方文档里的说法，不是我猜的。

一个常见的需求是「要露出，但不想被拿去训练」。写法是允许搜索型、禁止训练型：

User-agent: OAI-SearchBot
Allow: /

User-agent: GPTBot
Disallow: /

User-agent: Claude-SearchBot
Allow: /

User-agent: ClaudeBot
Disallow: /

写完之后要验证，不要凭感觉。站内的 AI 爬虫验证工具 可以用真实 UA 逐个访问，看是不是被 CDN 或防火墙挡了。

这里有一条最容易被搞错的对应关系，单独说一遍：想进入 ChatGPT 搜索的答案，要放行的是 OAI-SearchBot，不是 GPTBot。GPTBot 管的是训练，挡了它不影响搜索露出；OAI-SearchBot 管的是搜索索引，挡了它就等于从 ChatGPT 的答案里消失。很多站点只写了 GPTBot 的规则，然后以为自己已经「允许 ChatGPT 了」，其实关键的那一条根本没写。

meta 指令这边，Bing 的站长指南把后果写得很具体：NOARCHIVE 会让内容完全无法进入 Copilot 的回答与 grounding 结果（grounding 指把网页内容当作事实依据来支撑回答）；NOCACHE 只允许使用网址、标题和摘要，引用深度会变浅；NOSNIPPET 和 DATA-NOSNIPPET 会限制可展示的文字，可能降低引用质量。这些不是「优化建议」，是直接掐断管道。

验收标准：给你一个站点，你能说出「它现在允许谁、禁止谁、有没有误伤搜索型爬虫」，并写出修改后的文件。

动作三：看状态码，别让 404 吃掉抓取

为什么：AI 爬虫的抓取预算不是无限的。它把大量请求打在死链上，来你正常页面的次数就少了。

怎么做：打开浏览器开发者工具的 Network 面板，或者用 curl -I 看响应头。记住几个关键码：

Vercel 那份实测里有个数字很值得看：ChatGPT 的爬虫有 34.82% 的请求打在 404 上，Claude 是 34.16%，而 Googlebot 只有 8.22%。这个差距说明两件事：一是 AI 爬虫的 URL 选择还不够聪明，二是你的站点如果死链多，被浪费的比例会更高。

验收标准：你能拉出一张表，列出站点里返回 404 和 403 的 URL，并判断哪些是该修、哪些是该放。

动作四：结构化数据，会复制、会改、会校验

为什么：先把话说清楚。Google 的生成式 AI 优化指南明确写了，生成式 AI 搜索不需要结构化数据，也没有专门的 schema.org 标记。所以它不是 GEO 的必需品。

但它仍然值得做，原因有两个：一是它能帮你拿到传统搜索的富媒体结果，这是实打实的流量；二是写的过程会逼你把「这是什么、谁写的、什么时候发的、回答了什么问题」讲清楚，这个梳理本身对内容有帮助。

怎么做：不用从零写。找一个同类页面，复制它的 JSON-LD，改字段，跑校验。最小可用的一套是 Article 加 FAQPage：

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "文章标题",
  "datePublished": "2026-11-06",
  "dateModified": "2026-11-06",
  "author": { "@type": "Person", "name": "作者名" },
  "mainEntityOfPage": "https://example.com/page.html"
}
</script>

一条铁律：标记里的内容，必须和页面上看得见的文字一致。标记里有、页面上没有，叫误导性结构化数据，Bing 把它归进滥用类别，Google 也有对应的垃圾内容政策。

验收标准：你能给一个页面补上 Article 和 FAQPage，校验通过，且逐条对得上页面文字。

动作五：读得懂两张报表和一份日志

为什么：没有度量，就没有迭代。GEO 的度量比 SEO 窄，但不是没有。

怎么做：三个入口。

第一，Google Search Console 的生成式 AI 效果报告。Google 在 2026 年 6 月 3 日宣布上线，2026 年 8 月 31 日向全球所有站点开放。它覆盖 AI 概览和 AI 模式，维度是网页、国家/地区、日期、设备。它只有展示次数，没有点击，也没有查询词。所以它只能回答「我有没有出现在 AI 回答里」，回答不了「带来了多少生意」。

第二，Bing Webmaster Tools 的 AI Performance。颗粒度更细，能看到引用与 grounding 相关的查询。缺点是只覆盖微软生态。

第三，服务器日志。这是最原始也最可靠的一份。用一条命令就能看出谁来过：

grep -iE "GPTBot|OAI-SearchBot|ClaudeBot|Claude-SearchBot|PerplexityBot" access.log \
  | awk '{print $1, $7, $9}' | sort | uniq -c | sort -rn | head -30

它能告诉你：哪个 UA 来得最多、命中哪些 URL、返回了什么状态码。如果某个 UA 一次都没出现，先别怀疑内容，去看看它是不是在门口就被挡了。

验收标准：你能用日志回答「过去 7 天，哪个 AI 爬虫来过、抓了多少次、有没有被 403」。这套记录表的字段设计与三指标加权方法，我写在《AI 可见度诊断：企业自查的完整流程》里，可以直接拿去用。

五、三个半技术动作，外加两个正在成形的新层

下面这三件事，通常要开发或运维配合。你不需要自己改代码，但你要能把问题描述到对方能动手的程度。

1. 把正文放进初始 HTML

这是最重要的一条。做法有三种：服务端渲染（SSR）、静态生成（SSG）、预渲染。对内容站来说，SSG 最省事；对电商和 SaaS，SSR 或增量静态生成更合适。

和开发沟通时，不要讲「GEO 需要 SSR」这种概念，直接给他看对比：同一个 URL，浏览器里有什么，curl 回来有什么。差距摆出来，比讲十分钟原理有用。

2. 检查 CDN 和 WAF 有没有误伤

Cloudflare 在 2026 年 9 月 15 日的公告里给了一组数据：混合用途爬虫（同时为搜索索引和 AI 训练抓取）占其网络上已验证爬虫流量的 36.6%，是最大的一类；不到 1% 的站点屏蔽搜索型爬虫，17% 的站点限制 AI 训练。这说明大部分站点并不想彻底关门，但「不想被训练」和「不想被引用」经常被同一条规则一起干掉。

常见误伤是这样的：站点为防采集，在 WAF 里加了一条「非浏览器 UA 一律挑战」，结果 OAI-SearchBot 和 ClaudeBot 一起被挡。你在后台看流量正常，因为人还能进；但 AI 那边，你等于不存在。

3. 把新鲜度信号补齐

Bing 的站长指南把 sitemap 的 lastmod、HTTP 的 ETag 和 IndexNow 都写进了 grounding 相关的建议里。逻辑不难理解：AI 回答最怕的是引到过期信息，所以它偏好能证明「这是最新的」的页面。

具体做法不复杂：sitemap 里的 lastmod 要真实，不要每次部署都全站刷新；内容改动后主动推 IndexNow；重要页面不要设置过长的缓存头。

4. 两个正在成形的新层：使用偏好与智能体访问

这一段讲的是 2026 年新出现的东西。它们还不是必做项，但决定了你未来两年的技术判断力。

第一个是使用偏好信号。过去 robots.txt 只回答「你能来吗」，回答不了「你拿去干什么」。IETF 的 AIPREF 工作组正在做一件事：把「允许搜索、不允许训练」这种偏好写成机器能读的标准字段，形式是 HTTP 的 Content-Usage 头，或者 robots.txt 里的 Content-Usage 指令。截至 2026 年 11 月，它仍然是草案，没有成为正式标准，语法还可能变。所以我的建议是「盯着，别急着上线」——现在写进 robots.txt 也只能算实验。

第二个是智能体访问。Google 在自己的生成式 AI 指南里已经把 AI 智能体单列出来，并指向一份「智能体友好型网站」的最佳实践：智能体会看渲染后的视觉效果、检查 DOM、解析无障碍树，而不只是读文本。Cloudflare 在 2026 年 9 月 15 日也把原来的「屏蔽 AI 机器人」一个开关，拆成了搜索、训练、智能体三个独立开关。

这两件事合起来，说明技术基础的定义正在扩一层：从「让爬虫读到你的 HTML」，扩到「让智能体看懂你的页面并能完成任务」。但对绝大多数内容站来说，这一层现在还是二阶问题——先把取、渲、抽三步做对，再谈智能体。

如果你想系统看这条链路的全貌，我在《零基础怎么学习 GEO 优化？》里给了四阶段路径；这一篇只解决其中一个问题：技术这一关，到底要过到什么程度。

六、编程到底能换来什么：三个收益和一个脚本

如果你已经会一点编程，或者正在犹豫要不要学，我把它能带来的东西拆成三条，都是实打实的，不吹。

第一，批量。手工检查 10 个页面的原始 HTML，大概要半小时；检查 1000 个，手工做不到。一个几十行的脚本，几分钟跑完。

第二，可复现。你今天改了一版，三个月后想对比，手工记录很难保持一致。脚本每次跑同样的规则，输出同样的表，差异才看得见。

第三，归因。日志几十万行，肉眼看不出模式。脚本能聚合出「哪个 UA 偏好哪类页面」「改版后哪类 URL 的抓取掉了」。

下面这个脚本，是我给非技术背景的同行用的最小版本。它不执行 JavaScript，只做一件事：检查原始 HTML 里有没有你指定的关键句，同时记录状态码和页面大小。

import csv
import urllib.request
import urllib.error

URLS = [
    "https://example.com/page-1.html",
    "https://example.com/page-2.html",
]
KEY_PHRASES = ["核心结论那句话", "另一个必须出现的事实"]
UA = "Mozilla/5.0 (compatible; GEO-Audit/1.0)"

def fetch(url):
    req = urllib.request.Request(url, headers={"User-Agent": UA})
    try:
        with urllib.request.urlopen(req, timeout=15) as resp:
            body = resp.read().decode("utf-8", errors="ignore")
            return resp.status, len(body), body
    except urllib.error.HTTPError as e:
        return e.code, 0, ""
    except Exception:
        return "ERR", 0, ""

rows = []
for url in URLS:
    status, size, html = fetch(url)
    hit = sum(1 for p in KEY_PHRASES if p in html)
    rows.append([url, status, size, hit, len(KEY_PHRASES)])

with open("geo-audit.csv", "w", newline="", encoding="utf-8-sig") as f:
    w = csv.writer(f)
    w.writerow(["url", "status", "bytes", "phrase_hit", "phrase_total"])
    w.writerows(rows)

print("done:", len(rows), "urls")

跑法：装上 Python，把 URL 和关键句换成你自己的，保存成 audit.py，在命令行里执行 python audit.py，同目录下会多出一个 geo-audit.csv。

它的局限也要说清楚：它不执行 JS，所以它看到的就是「不渲染的爬虫看到的」；它不解析 DOM，所以不能判断标题层级；它不做频率控制，URL 多了会被限速。它解决的是「有没有」，不是「好不好」。

要不要专门去学编程？我的判断是：如果你只做内容型 GEO，不学也够；如果你想服务多个客户、做持续监测，学一点脚本会明显省时间；如果你想进技术团队做平台级优化，那就不是「学一点」的问题，是另一条职业路径。

按我带人的经验估，从零到「能看懂并改这个脚本」，大约 20 到 30 小时；到「能独立写出带重试、并发、结果入库的监测脚本」，大约 60 到 100 小时。这两个数字是我的经验值，不是统计结论。

七、能力分级：从 L0 到 L4，你在哪一级

这张表是我按「能不能独立交付」分的，不是按职位分的。

大多数招聘方要的是 L1 到 L2。我看过的 GEO 优化师岗位描述里，技术栏写的多半是「懂 robots.txt、看得懂日志、能和开发对齐」，而不是「会写 Python」。L3 是自由职业者的规模杠杆——它让你一个人能服务五个客户，而不是两个。L4 是大站和平台的需求，人数少，但稀缺。

这张表最重要的信息在最后一行：L1 和 L2 之间隔的不是编程，是「能不能带人落地」。很多人卡在这里，不是因为不会写代码，是因为说不清要开发改什么。

八、七天补课表：每天 1.5 小时

如果你现在完全不懂技术，按这个顺序走一遍，一周后你就能独立做基础诊断。每天都有验收，验收不过就重做，不要往后赶。

第 7 天的报告不用长，一页就够。写清楚三件事：哪几项不合格、每项的证据是什么、先修哪三个。这份东西就是你接第一个客户的样品。

九、四个误区，每个都有出处

误区一：不会 Python 就做不了 GEO。

不对。GEO 的核心动作是判断「哪句话值得被抽走」，这跟编程无关。Vercel 的数据说明的是「爬虫不执行 JS」，不是「优化师必须会写代码」。把技术事实偷换成能力门槛，是卖课常见的话术。

误区二：结构化数据是 GEO 的核心。

不对。Google 的生成式 AI 优化指南明确说，生成式 AI 搜索不需要结构化数据，也没有专门的 schema.org 标记。它仍然值得做，但理由是富媒体结果和内容梳理，不是「AI 靠它认你」。

误区三：技术改完就会被引用。

不对。Bing 的站长指南里写得很直白：GEO 不保证 grounding 或引用，就像 SEO 不保证排名。技术只解决「有资格」，解不了「被选中」。

误区四：llms.txt 是技术门槛。

不对。Google 的指南明确说不需要创建这类 AI 专用文件。本站自己也放了一份，那是顺手做的，从来没有写进验收指标。判断一个服务商专不专业，看它敢不敢说「这个不做也行」。

十、非技术背景怎么补：一张翻译对照表

文科生、运营、编辑转过来，最难受的不是学不会，是听不懂开发在说什么。下面这张表，把常见的术语翻成人话。

这张表不用背，遇到时查一下就行。真正的能力是：开发说「这个是 CSR 的，爬虫读不到」，你能立刻反应过来「那我让他在构建时预渲染这几类页面」。

十一、怎么证明你会：三份交付物

面试也好，接单也好，不要拿证书。拿三样东西。

第一份，原始 HTML 的前后对比。同一个 URL，改前 curl 回来是空壳，改后有正文。截两张图，标出那句关键话。这比任何简历描述都硬。

第二份，robots.txt 与爬虫日志的对照。改前哪个 UA 被挡、改后哪个 UA 进来了、状态码从 403 变成 200。一条时间线，三行证据。

第三份，四周的监测表。20 条问题、4 个引擎、每周一次，记三列：有没有提到品牌、有没有给出链接、事实有没有说错。第四周写一段结论：哪些变了、哪些没变、我判断原因是什么。

再加一句很多人不愿写的话：「这次改动我没能影响到的是什么。」敢写这句的人，反而更容易被信任。因为它说明你知道边界在哪。

十二、写在最后

回到最初的问题：学 GEO 需要懂编程或技术基础吗？

我的答案是：不需要懂编程，但必须懂技术基础。这两件事被混为一谈太久了，以至于很多人要么被吓退，要么花了几个月学了一门用不上的手艺。

技术基础的最小集，其实只有五个动作。它们不难，但它们有一个共同点：都需要你亲自去看一眼机器看到的东西。不是看报表的总结，不是听别人说「应该没问题」，是自己打开源文件，搜那句话，看它在不在。

这件事没人能替你做。开发能帮你改，但不能替你判断「该不该改」；工具能帮你测，但不能替你解释「为什么测不到」。

GEO 这个行当，现在最吵的是「怎么让 AI 推荐我」，最缺的是「怎么确认 AI 到底读到了什么」。前者是话术，后者是手艺。手艺长得慢，但它不会因为一次算法更新就归零。

十三、常见问题

十四、参考来源

以下条目按 MLA 第 9 版网络资源格式著录，核对日期均为 2026-11-06。凡二手转引，均在条目末尾注明转引环节。

搜索引擎官方文档

1. Google Search Central. "Optimizing Your Website for Generative AI Features on Google Search." Google for Developers, 15 May 2026, developers.google.com/search/docs/fundamentals/ai-optimization-guide. 核心立场：为生成式 AI 搜索优化仍属 SEO；生成式 AI 搜索不需要结构化数据，也没有专门的 schema.org 标记；不需要创建 AI 专用文件、不需要把内容切块、不需要为 AI 改语气；技术基础仍是可抓取、可索引、语义化 HTML 与 JavaScript SEO 最佳实践。
2. Google Search Central. "A New Resource for Optimizing for Generative AI in Google Search." Google Search Central Blog, 15 May 2026, developers.google.com/search/blog/2026/05/a-new-resource-for-optimizing. 说明指南覆盖非同质化内容、本地/购物/图片/视频内容、AEO/GEO 常见误解、AI 智能体，以及 SEO 最佳实践为何仍是基础。
3. Microsoft. "Bing Webmaster Guidelines." Bing Webmaster Tools, rewritten Feb. 2026, bing.com/webmaster/help/webmaster-guidelines-30fba23a. 首次在官方站长指南中定义 GEO 为「内容获得在 AI 回答中被 grounding 与引用的资格」，并声明 GEO 不保证引用；给出四条 grounding 规则（直接陈述事实、实体名称一致、一 URL 一主题、关键信息靠上）；说明 NOARCHIVE、NOCACHE、NOSNIPPET、DATA-NOSNIPPET 对 Copilot 与 grounding 的影响；将 sitemap 的 lastmod、ETag、IndexNow 与新鲜度、grounding 资格关联。
4. Schwartz, Barry. "Bing Adds GEO To Official Guidelines, Expands AI Abuse Definitions." Search Engine Journal, Feb. 2026, www.searchenginejournal.com/bing-adds-geo-to-official-guidelines-expands-ai-abuse-definitions/568442. 对 Bing 指南重写的第三方核对，含 GEO 定义、meta 指令后果、grounding 规则与滥用类别变更。
5. Google. "Generative AI Performance Report (Search)." Search Console Help, support.google.com/webmasters/answer/16984139. 自 2026 年 8 月 31 日起向全球所有站点开放；覆盖 AI 概览与 AI 模式；维度为网页、国家/地区、日期、设备；仅有展示次数。
6. Google Search Central. "JavaScript SEO Basics." Google for Developers, developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics. 说明抓取、渲染、索引三阶段，渲染由独立的渲染服务完成，页面可能在队列中等待。

实测与研究

7. Zecchini, Giacomo, et al. "The Rise of the AI Crawler." Vercel, 17 Dec. 2024, vercel.com/blog/the-rise-of-the-ai-crawler. 与 MERJ 联合分析 Vercel 网络流量：一个月内 GPTBot 5.69 亿次、Claude 3.7 亿次、Googlebot 45 亿次；GPTBot 与 Claude 合计约为 Googlebot 的 20%；GPTBot 11.50%、Claude 23.84% 的请求下载 JavaScript 但不执行；Gemini 复用 Googlebot 渲染能力；ChatGPT 34.82%、Claude 34.16%、Googlebot 8.22% 的请求命中 404。
8. 王思北. 《我国生成式人工智能用户规模突破 7 亿人》. 新华社, 2026 年 9 月 29 日, www.news.cn/sci-tech/20261013/19bd6dfe8bb140c7881f9a69e999a1ec/c.html. 引用中国互联网络信息中心《生成式人工智能应用发展报告（2026）》：截至 2026 年上半年，我国生成式人工智能用户规模突破 7 亿人，普及率超 50%；76.0% 的用户会让生成式人工智能回答问题。

平台与标准文件

9. OpenAI. "Overview of OpenAI Crawlers." OpenAI Platform, platform.openai.com/docs/bots. 说明 GPTBot 用于训练、OAI-SearchBot 用于 ChatGPT 搜索、ChatGPT-User 用于用户主动触发的访问；OAI-SearchBot 的 robots.txt 设置独立于 GPTBot；ChatGPT-User 的请求由用户发起，robots.txt 规则可能不适用。
10. Anthropic. "Claude Bot and Crawler Documentation." Anthropic Support, support.anthropic.com. 说明 ClaudeBot 用于训练、Claude-SearchBot 用于搜索质量、Claude-User 用于用户主动访问，三者可分别通过 robots.txt 控制。
11. Cloudflare. "Cloudflare Helps End the Search-or-AI-Training Tradeoff." Cloudflare Press Releases, 15 Sept. 2026, www.cloudflare.com/press/press-releases/2026/cloudflare-helps-end-the-search-or-ai-training-tradeoff/. 混合用途爬虫占其网络已验证爬虫流量的 36.6%；不到 1% 的站点屏蔽搜索型爬虫；17% 的站点限制 AI 训练。
12. Internet Engineering Task Force. "Associating AI Usage Preferences with Content in HTTP." IETF, draft-ietf-aipref-attach-04, www.ietf.org/archive/id/draft-ietf-aipref-attach-04.html. AIPREF 工作组草案，定义 Content-Usage 头与 robots.txt 中的 Content-Usage 指令，用于表达训练与搜索的使用偏好；截至核对日期仍为草案，尚未成为正式标准。