官网 GEO 的讨论常常直接跳到内容,跳过了一个更前置的问题:模型到底能不能拿到这个页面。
这件事的麻烦是它不报错。页面在浏览器里打开一切正常,爬虫拿到的却是一份几乎没有文字的框架。没有任何提示告诉你这件事正在发生,内容团队照常产出,几个月后发现毫无变化。
所以清单的顺序是有意义的:先确认能不能进来,再确认读不读得懂,最后才是内容值不值得引用。
AI 爬虫抓不到官网,通常卡在哪
公开样本里的基础失误比预期的多。HTTP Archive 对 2024 年的网页做过大规模审计,8.43% 的桌面页面和 7.40% 的移动页面没有通过 robots.txt 有效性检查。另一项检查显示 10.6% 的桌面页面和 10.9% 的移动页面,在页面头部区域存在无效的 HTML 元素,这类问题会直接导致规范链接、多语言标注、标题这些声明被丢掉。
还有一个数字值得单独看:98% 的桌面页面有标题元素,但只有 66.7% 有 meta description。也就是说三分之一的页面连一句自己写的摘要都没有,摘要由引擎自行截取。
第一组:可抓取性,五项
这五项是开关性质的。不过关,后面十项的工作量全部作废。
| # | 检查项 | 不过关的表现 |
|---|---|---|
| 1 | robots.txt 明确放行主流 AI 抓取器 | 日志里有该标识的请求但返回 403 |
| 2 | 首屏主要文字出现在服务端返回的 HTML 里 | 取源码后正文为空,只有脚本 |
| 3 | sitemap.xml 可访问且地址与规范链接一致 | sitemap 里带 www,页面规范链接不带 |
| 4 | 关键页面返回 200 且无连环跳转 | 一次请求经过三次以上重定向 |
| 5 | 服务器不按 UA 区别对待抓取请求 | 浏览器正常,抓取器收到验证页 |
第二项是最常见的死因。验证方法只有一个:把页面源码直接取下来看,不要在浏览器的开发者工具里看元素树,那里显示的是脚本执行之后的结果,看不出问题。
第一项需要分路径判断。屏蔽用于训练的抓取和屏蔽回答时的实时检索是两件不同的事,一条规则全拒会连带断掉被引用的通道。robots.txt 的语法规范本身有正式标准可依,拿不准时按标准写,不要照抄网上的模板。
第二组:机器可读,五项
这一组决定机器能不能把页面上的事实对应到字段上。
| # | 检查项 | 不过关的表现 |
|---|---|---|
| 6 | 声明 Organization,名称与第三方口径一致 | 官网全称与目录里的简称对不上 |
| 7 | 常见问题页带 FAQPage 标记且与可见内容一致 | 标记里有五条,页面上只有三条 |
| 8 | 页面头部的规范链接与多语言标注完整 | 同一内容有多个可访问地址 |
| 9 | 每页有自己写的标题与摘要,不复用模板 | 几十个页面摘要完全相同 |
| 10 | 内容带发布与更新时间,并且是真实的 | 日期每天自动刷新成当天 |
第十项要特别说。把更新时间做成自动刷新,看起来是让内容显得新,实际效果相反:一个每天都在更新却内容从不变化的页面,可信度是被削弱的。
第六项不需要技术投入,但需要有人把口径定下来。国内站点还有一个现成的可核验锚点容易被忽略,ICP 备案号在工信部公开系统里可查,对应主体名称是确定的,把它和机构全名一起写进标识字段,比任何自我描述都有分量。
多个域名形式与多语言站点容易多出来的坑
上面第 3 项和第 8 项的分歧,根子通常是同一个:站点同时存在好几种可访问的形式,而各处声明的那一种不一致。
带 www 和不带 www 是两套地址。带尾斜杠和不带尾斜杠也是两套。http 和 https 再乘一遍。理论上有多种组合,实际上团队往往只在一处定了口径,别处沿用了默认值。于是出现这种局面:规范链接写的是不带 www 的形式,sitemap 里是带 www 的,而站点验证又是在另一种形式下完成的。
这件事在国内尤其值得提前确认,因为百度把带 www 和不带 www 视为两个独立站点,提交接口会按站点校验。我们自己接入时就踩过:平台里验证的是带 www 的形式,而站点声明的主机是不带 www 的,结果用声明的那种形式调推送接口直接被拒,换成验证过的那种又和 sitemap 对不上,两边都不成立。
多语言站点要多加一项。每个语种页面都要指向该语种真实存在的对应页面,并且互相指回。常见的错误是把所有语种都指向中文首页,这等于告诉机器这些页面没有对应关系。
处理顺序上,先定主机形式与尾斜杠这一个口径,然后让规范链接、多语言标注、sitemap、站内链接四处统一引用它。四处口径一致之后,第 3 项和第 8 项会同时通过。
第三组:可引用性,五项
前两组解决能不能读到,这一组决定读到之后要不要用。
| # | 检查项 | 不过关的表现 |
|---|---|---|
| 11 | 结论写在段首,不藏在铺垫后面 | 前三段都在讲行业背景 |
| 12 | 关键事实有具体数值、范围或条件 | 通篇「根据客户需求灵活安排」 |
| 13 | 每段能脱离上下文独立成立 | 频繁出现「如前所述」「见上文」 |
| 14 | 对外说法有可核验的出处或编号 | 所有依据都只能回到自己官网 |
| 15 | 明确写出不适用的情况与边界 | 只有优势,没有任何限制条件 |
第十五项最反直觉,也最有效。把不适用的情况写出来,页面被引用的机会反而更高。原因是模型组织答案时要给判断依据,一份只有优点的材料会和其他来源冲突,冲突时它倾向于避开。
第十一项和第十三项是一回事的两面。生成式回答通常只摘走一两段,上下文不跟着走。一段读起来很完整但依赖前文的话,被摘出来就是残句。
做完这 15 项之后不会发生什么
不会立刻出现在 AI 的回答里。这份清单解决的是资格问题,不是竞争问题。抓得到、读得懂、有可引用的内容,是进入候选范围的条件,不是被选中的理由。被选中还要看材料的具体程度和第三方印证的密度。
也不会有任何通知告知你生效了。搜索端还能看富结果报告,生成式回答这边没有后台、没有提交入口、没有回执。唯一的办法是固定一份问题集重复测量,比较前后差异。
这十五项的逐项判定标准与常见修法写在官网基础配置指南里。不想自己逐项核的,官网 AI 可读性体检按同一份清单出书面报告,包含每项的实测证据与修复优先级。
参考来源
- HTTP Archive (2024). Web Almanac 2024: SEO. HTTP Archive.
- HTTP Archive (2024). Web Almanac 2024: Structured Data. HTTP Archive.
- Koster, M., Illyes, G., Zeller, H., & Sassman, L. (2022). RFC 9309: Robots Exclusion Protocol. IETF.
- OpenAI. Overview of OpenAI crawlers. OpenAI Developer Documentation.
- Google. Intro to how structured data markup works. Google Search Central.