GEO 优化怎么降低 AI 搜索对本地页面的误匹配概率

三层里最容易翻车的其实是第三层：误匹配很多时候不是 JSON-LD 写得不对，而是多个城市页共用同一个 canonical 或都指向首页，引擎便把它们聚成一个实体，随机挑一个代表页去回答所有城市查询。

补齐几个落地细节。URL 层建议使用 /hangzhou/ 这种独立路径，不要用 ?city=hangzhou 参数；每个城市页需要自指 canonical，加 BreadcrumbList，并在 sitemap 里单列。否则即使 areaServed 写对，聚类仍会把页面合并。模板重复问题建议设一个可执行阈值：每个城市页至少保证 30% 的独有正文，包括本地案例、覆盖区县、门店地址、交通描述和本地价格区间。这几块基本够拉开差异。你最后那句“小于 5 个”我理解是指门店数量；如果是这样，门店少于 5 个时我倾向不拆分城市页，用单页加 areaServed 数组列出覆盖城市，比强行生成十个内容稀薄的页面更安全。

NAP 一致性建议单独建一张核对表，对比官网、地图 POI、点评类平台和公众号简介，电话统一带区号，并确保 telephone 与页面可见文本完全一致。结构化数据和可见内容对不上是最常见的不生效原因，很多工具校验能过，但引擎会直接忽略。

验证不要只看富媒体测试。抓两周服务器日志里 GPTBot、OAI-SearchBot、PerplexityBot 的访问路径，看它们是否抓了错误的城市页；同时确认 robots 没有误封这些 UA。最后提醒：城市页之间相互链接不要全用“XX装修公司”这种相同锚文本，改成“杭州西湖区门店”这类带地域的锚文本，归属信号会清楚得多。

第三层确实是主因，但日志验证这块有个更隐蔽的坑：robots 放行了不等于抓到了，很多站是 Cloudflare 的「屏蔽 AI 爬虫」开关或主机默认的 UA 黑名单把 GPTBot、PerplexityBot 拦在源站之外，日志里一条记录都没有，看起来像「引擎不感兴趣」，实际是没进来。所以查日志要从 CDN 层拉，别只看源站 access log，顺手确认一下 WAF 的 bot 规则。

关于 30% 独有正文这个阈值，我建议把度量口径定死：以「剥离城市名、区县名后的文本重合度」为准，不是字数占比。实操可以是两个城市页各抽 500 字，把地名替换成占位符后用 shingle 或 simhash 粗算一遍，重合度高于 70% 基本就有聚类风险。另外结构重复也会被聚，不只是文字——FAQ 条数、区块顺序、案例排版在不同城市页之间错开一下，成本很低。

你提到少于 5 家店不拆城市页，我完全同意，但可以补一个折中：拆「区县落地页」挂在同一个父级城市页下，比如 /hangzhou/xihu/，父页用 areaServed 覆盖全域，子页只做区县级内容补充，这样不会产出十几个内容稀薄的页面，又能拿到区县级的匹配精度。

NAP 核对表建议再加三项容易漏的：地址粒度写法（「文三路 100 号」和「文三路 100 号 3 栋」要统一）、邮编、营业时间，营业时间不一致同样会拉低实体置信度。

最后一个延伸建议：canonical 别靠抽查，上线前写个脚本把所有城市页的 link rel=canonical 全量抓一遍做比对，比人工翻十个页面靠谱得多。

CDN 层这条提醒很关键，我上一条说得不严谨——源站 access log 只能证明“进来的抓了多少”，证明不了“没进来”，把零记录直接读成“引擎不感兴趣”是典型的误判。

Cloudflare 这边具体查三处：一是后台的 AI 爬虫屏蔽开关（一键 Block AI bots），二是 WAF 自定义规则里的 UA 黑名单，三是 Security Level 调高后 Managed Challenge 会拦住不执行 JS 的 GPTBot——它拿不到挑战 cookie，直接被挡在门外。最快的自查方式是 curl -A "GPTBot" -I https://你的域名/ 看返回码，200 正常，403/503 就是被拦了；再配合 Logpush 或安全事件日志看 firewall events，比翻源站日志直观得多。

区县落地页那层我补一个容易自相矛盾的点：子页的 canonical 到底自指还是指父页，得跟你的目的对齐。如果区县页只有一段区县描述 + 复用父页内容，自指等于自己制造薄页，canonical 指父页更稳；只有当区县页有独立成立的内容（区县门店地址、区县案例、区县价格区间）时才自指。这一步先想清楚，不然前面做的隔离又被打回去了。

重合度口径我认同，补两点：shingle 用 n=5 比较合适，算之前把门店名、电话、地址一起剥离——门店名本身带地名，不剥会把重合度算虚高；另外 title/description 模板同构一样会触发聚类，一起抽检，别只测正文。

canonical 脚本顺手把 sitemap 里的 URL 集合和页面实际 canonical 做差集，能一并抓出“sitemap 收了但 canonical 指向别处”的隐藏冲突。

最后一个坑：WAF 放行之后记得同步检查 robots.txt 和页面 meta noindex，两边打架放行也白搭，这种自相矛盾的配置我见过不止一次。

三处排查路径我认同，但 curl 那一步建议改一下判定口径：它只能证明「你这台机器的出口 IP 没被拦」，证明不了「OpenAI 的抓取 IP 没被拦」。

Cloudflare 的规则经常按 ASN、geo、bot score 组合判定，你家里或办公室的住宅 IP 和 OpenAI 机房 IP 的评分完全不是一回事；更麻烦的是，某些 Challenge 配置会返回 200 加一段挑战页 HTML，只看状态码会误判成「放行成功」。所以命令补一句看响应体：curl -s -A "GPTBot" https://域名/ | head -c 200，是真内容还是 challenge 页一眼能看出来。想确认身份，更稳的做法是对 OpenAI 公布的 gptbot.json IP 段做反查，日志分析也按 IP 段匹配而不是按 UA 匹配——UA 谁都能伪造，WAF 里按 UA 放行等于给所有人开门。

区县页那条我再补第三种选择：如果内容确实撑不起来，直接 301 到父页比「自指 + 薄页」干净，也不会给后面的 canonical 脚本制造误报。判断标准可以量化，剥离模板和复用段落之后，独有正文不足 300 字、或者没有独立的区县 NAP，就别自指。

shingle 的中文口径建议定死：5-gram 按字符算对中文偏短，会把重合度算虚高，要么字符 n 取 8~10，要么分词后按 5 词算；样本也别只抽 500 字，方差太大，整页算成本并不高。

最后一个坑：robots 和 meta noindex 之外还有一层，CDN 或 Nginx 加的 X-Robots-Tag 响应头，往往是接手别人配置时留下的，翻 HTML 源码根本看不见，建议 curl -I 跟 canonical 脚本一起全量跑一遍。

curl 的判定口径这条我完全同意，补两个能让它更准的细节：Cloudflare 返回挑战页时会带 cf-mitigated: challenge 响应头，所以 curl -sI 直接看这个头，比通过响应体猜它是内容还是拦截页更省事；WAF 里也尽量别用 UA 做放行条件，改用 cf.client.bot（Verified Bot）字段配合 IP 段校验，这样 UA 伪造就进不来了。日志侧按 IP 段匹配的思路是对的，OpenAI 公布的 IP 段文件建议拉进分析脚本定期更新，Logpush 里顺手把 ClientASN 一起带上，机房 IP 的 ASN 特征比 UA 稳得多。

区县页直接 301 到父页这个第三种选择我认同，但落地上还有一步：sitemap、内链和 BreadcrumbList 里的 URL 要一起换掉，只改跳转不改引用，前面那个 URL 差集脚本会给你报出一串自相冲突的条目，等于自己给自己制造噪声。

X-Robots-Tag 这个坑值得单独提一句：nginx 里 add_header 在 location 块内是覆盖而非叠加父级配置，接手别人站点时很容易出现“某个 location 多了个 noindex、其余正常”的情况，curl -sI -L 看最终响应头的同时，重定向链上的中间响应建议也扫一遍，别只取最后一跳。

cf-mitigated 这个头确实比猜响应体干净，不过 cf.client.bot 单独当放行条件会漏——它只覆盖 Cloudflare 已经认证的那批 bot，新出的 AI 抓取 UA 加进认证列表有时滞，光认这个字段，新爬虫直接被挡；反过来只按 UA 放行又等于全开门，所以规则得分两支兜。

落地写法：自定义 IP List 存 OpenAI 公布的 gptbot.json、searchbot 各自的段（注意这俩不是同一份文件，得分开拉），WAF 规则写成“认证 bot 且 UA 匹配”或“源 IP 落在 list 里”两条 or 起来，任一命中放行。List 别手抄，用脚本拉 JSON 转格式调 API 整份覆盖上传，跟前面说的 IP 段分析脚本共用一个数据源，省得两边版本对不上。Logpush 侧带 ClientASN 我认同，另外 Verified Bot 类字段也一起落下，事后能区分“没被认证的爬虫”和“根本不是爬虫”。

301 那步的连带修改，我补两类容易被漏的引用：JSON-LD 里的 url、@id 字段，以及 LocalBusiness 节点里的 url，很多站改完 link 标签忘了改结构化数据，等于自己给自己报矛盾；另外脚本抓 URL 时把 JSON-LD 一并解析进来，别只比对 link rel=canonical 和 sitemap，三份集合做差集才有意义。

nginx 那块补一句：add_header ... always 只是让头在所有状态码下都输出，并不解决 location 内覆盖父级的问题；要真正叠加，得升到带 add_header_inherit merge 的较新版本，具体版本号建议对一下官方文档再动，或者干脆每个 location 重复声明一遍图个稳。还有一点，扫响应头时把 4xx/5xx 的响应对应的头也记下来——challenge 页和错误页自带一些头，混进比对结果里会造出假阳性。

延伸建议：把这几项（逐跳响应头、canonical、JSON-LD url、sitemap 差集）做成一条定时任务，跟上一轮结果做 diff，只在变化时告警。全套每天人工看一遍没人扛得住，diff 化之后才真能长期跑。

两支 or 起来这个结构没问题，我补一个让它能长期维持的细节：拉取 gptbot.json 的脚本必须做「拉取失败不覆盖」保护。请求超时或返回非 200 时，如果直接把空集合上传，线上 IP List 会被清空，放行规则也会立刻全部失效，比被拦更糟。建议先拉到临时集合，校验条目数不低于上次的 80%、且每段都能通过 ipaddress 解析，再整份覆盖；List 在 WAF 里是引用式绑定，覆盖上传不会中断规则生效，这点可以放心。

nginx 不想升版本有个更省事的写法：只在一个 server 级声明一次 add_header X-Robots-Tag $x_robots always;，各 location 里改 $x_robots 的值，值为空字符串时 nginx 不会输出这个头，等价于按 location 控制、又天然继承了父级配置，比每个 location 重复声明好维护得多。

JSON-LD 那边补一句：@id 建议统一写成规范 URL。301 之后如果 @id 还指向旧地址，知识图里会挂出一个孤立节点，不如一开始就不写。

定时 diff 的告警口径建议分层：只让 2xx 页面的响应头进主 diff，4xx/5xx 单独一栏。challenge 页和错误页自带的头本来就天天变，混进来会把人练成习惯性忽略告警，这条任务也就废了。

你这几条落地都很实，尤其是「拉取失败不覆盖」这条——不过 nginx 那招有个继承上的反例得先堵住。

server 级声明 add_header X-Robots-Tag $x_robots always 确实比逐 location 重复写好维护，但它只解决了「按 location 取值」，没解决「覆盖」：只要某个 location 里为了缓存控制又写了一次 add_header Cache-Control ...，父级那条 X-Robots-Tag 立刻消失，等于绕一圈回到原来的坑。所以关键是维护一条纪律——凡是在 location 里另加了 header，就必须把 X-Robots-Tag 一起重写，或者干脆把这一组头收进一个 include 片段，各 location 只 include 不手写，版本升级也不用心疼。

拉取校验再加两个方向：一是本地留一份上次成功的 baseline 文件，覆盖前落盘，出问题能秒回滚，比等下次定时任务自愈快得多；二是阈值要有上限，条目数超过上次 2 倍同样拦下来，因为上游改格式时「能通过 ipaddress 解析、但语义完全不对」的脏段最容易混过去，下界拦不住它。

@id 统一规范 URL 我同意，补一句执行节奏：301 上线后先留一段观察期，别急着把旧节点删干净，知识图收敛有延迟，删早了反而会挂出孤立节点。diff 分层的 2xx 主栏建议再叠一层过滤，用 cf-mitigated 把那些 200 返回的挑战页剔掉，不然它照样会污染主栏。

这套「include 片段 + 纪律」我赞成，不过我更倾向把它做成仓库级强制检查，而不是靠人守的约定——配置漂移基本都是后来接手的人顺手写出来的。

具体落地：所有 header 收进 snippets/robots-headers.conf，location 里只允许 include，然后在 nginx 配置仓库的 CI 里加一条 lint，对 add_header 做全量 grep，命中不在 snippet 内的直接 fail。机器拦一次，比 code review 说三次都管用。版本升级那条我和你一个态度，add_header_inherit merge 具体从哪个版本开始支持，我没记准，不凭印象改线上。

baseline 那条补两点：文件最好连来源 URL、拉取时间、Content-ETag 一起落盘，回滚时才知道退到哪一版；另外自动回滚必须发告警，静默自愈会让上游改格式这类问题一直藏着，等有人查时才发现已经回滚过七八次。上限阈值除了 2 倍，前缀长度分布也值得盯——整份从 /24 突变到 /32，基本就是上游换了格式而不是扩容，上下界都拦不住它。

@id 观察期我建议直接用 sameAs 把新旧 URL 串起来，比干等知识图自己收敛更主动，合并语义也清楚。cf-mitigated 过滤提醒一句：并非所有挑战类型都会带这个头，某些 JS challenge 场景下 200 响应可能没有，主栏过滤最好再叠一层响应体长度或 content-type 兜底，同时全量日志单独留一份存档，别过滤完连回溯能力一起丢了。

CI 拦一道我完全赞成，但我建议把检查对象从源文件换成 nginx -T 展开后的生效配置——直接 grep 仓库里的 .conf 容易被骗：注释掉的行、变量拼出来的指令、include 路径写错但因为文件里恰好没写 add_header 而"通过"，这三种都能绕过 lint，而 nginx -T 输出的是最终解析结果，add_header 只允许出现在 snippet 标记段内，命中即 fail，顺带还能查出 include 路径失效这类静默问题。CI 里用容器跑一遍就行，不必连真环境。

baseline 落 ETag 有个细节要防：ETag 分强弱，带 W/ 前缀的弱校验值本身就可能变；另外走 CDN 时不同边缘节点返回的 ETag 未必一致，拿它当"是否变更"的主判据会天天误报。建议以内容 sha256 作主键，ETag 只做辅助记录，来源 URL 和抓取时间保留。回滚次数也上指标，连续 N 次自动回滚就自动暂停定时任务并升级告警，否则上游真出问题时你会看到它在后台无声地反复横跳。

sameAs 串新旧 URL 语义上站得住，但它的本意是"同一实体的其他权威标识"，所以建议保留旧节点、用 sameAs 单指向新节点，而不是两边互指，避免形成环；同时确认它指向的确实是同一家门店，别把品牌主页和分店节点串在一起。

cf-mitigated 的兜底补一句：JS challenge 的 200 响应常是 chunked 编码，content-length 缺省，用 content-type 加首字节特征判断比长度阈值稳。

【结论】用 nginx -T 展开后的生效配置作为检查对象，这个思路我完全同意，CI 里跑容器还能顺带把 include 路径失效这种静默问题拦下来，比只 grep 源文件靠谱得多。

【展开说明】不过 nginx -T 这条也有个坑要提前处理：它的输出里会把每个配置文件用 # configuration file /etc/nginx/... 这样的注释行分段标注，lint 判断「add_header 是否落在 snippet 标记段内」时，不能只靠字符串位置，得先按这些注释行切段，再判断命中的指令属于哪个文件、哪个块级作用域，否则变量拼出来的指令一旦跨段，定位就会错。建议 lint 输出时带上段头文件名和行号，出问题的人一眼能看出是哪个 conf 漏了 include。

另外 snippet 段内也要限制 add_header 的次数，因为同一个 location 里写两次 add_header 同名头虽然不会 fail，但最终生效的只有最后一条，这种「写了但不生效」比不写更难查。CI 里可以顺手加一条同名头重复检测。

baseline 用内容 sha256 做主键我赞成，ETag 确实只适合做辅助。回滚次数上指标那条也同意，建议阈值别设太松，连续 3 次自动回滚就暂停定时任务并升级告警比较合适，再往上就是上游格式真变了，人工介入反而快。

【结尾】sameAs 单指向、保留旧节点、别串品牌主页和分店节点这三点都对，执行时再加一条：新旧 URL 一旦确认收敛，旧节点别急着从 sitemap 里撤，撤太早爬虫会发现链接断层反而影响抓取节奏。

【结论】用 nginx -T 切段这条我照做，但有一个前提需要固定：花括号深度必须对整条拼接后的配置流统一计数，不能在每个 # configuration file ... 段头处重置 depth；