GEO 技术实战，检查 AI 搜索能否读到网页正文

企业网站做 GEO 时，可以先抽查一张真正承接业务的服务页。浏览器打开之后，公司名称、服务介绍和联系方式都在，接下来还要确认这些内容是怎样到达浏览器的。如果主要正文依赖 JavaScript 请求接口后才出现，直接下载页面的程序可能只拿到加载动画和脚本。

对照 Google 的 JavaScript SEO 文档，这个问题有很具体的技术依据。Google 将抓取、渲染和索引分成不同阶段，能够执行 JavaScript；文档也明确提醒，并非所有机器人都能执行脚本。因此，工程排查应当分别查看服务器返回的 HTML 和浏览器执行脚本后的页面。Google JavaScript SEO 文档

把最终响应和正文一起保存

挑选一个正式公开的服务页，使用它对外展示的完整网址。首页通常介绍整家公司，服务页更适合检查系统能否拿到某项业务的具体内容。

下面的示例适用于 Windows PowerShell。请把示例网址换成自己的页面，在一个新建的排查目录中运行，避免覆盖已有同名文件。

curl.exe -sS -L --max-redirs 5 --connect-timeout 10 --max-time 30 --compressed `
  -D geo-headers.txt -o geo-page.html `
  -w "final=%{url_effective} status=%{http_code} bytes=%{size_download}\n" `
  "https://www.example.com/services/ai-visibility/"

if ($LASTEXITCODE -ne 0) {
  throw "请求未完成，请先检查 curl 错误信息"
}

Get-Content -LiteralPath .\geo-headers.txt
Select-String -Path .\geo-page.html -Pattern '<h1', '实际公司名称', '实际服务名称'

这里直接使用 curl.exe，避免 PowerShell 环境中的同名命令差异。-L 跟随重定向，-D 保存响应头，-o 保存正文；输出中的 url_effective 是最终获取的地址。响应头文件可能包含多个重定向阶段，要结合最终地址和最后一组响应头阅读。curl 参数文档

先看请求有没有完成，再检查最终 HTTP 状态。返回 200 后，还应打开 HTML 文件，确认它确实是目标服务页。有些登录页、验证码页也会返回 200。字节数只能帮助发现异常，不能证明正文完整。只发 HEAD 请求也无法检查正文。

搜索公司名和服务名可以快速定位线索，但匹配到一个字符串仍然不够。它可能藏在脚本数据或 JSON-LD 里。顺着附近标签看下去，确认实际正文包含服务说明、服务对象、适用场景及咨询入口。纯文本工具还可能漏掉编码为字符实体的中文，此时需要查看源码或使用 HTML 解析器。

比较原始 HTML 和渲染后的页面

打开同一个网址，在浏览器开发者工具的 Network 面板找到页面文档请求，查看 Response；再到 Elements 面板查看执行脚本后的 DOM。两处分别回答服务器先发来了什么、浏览器后来补出了什么。

Chrome 还提供一个方便的辅助检查。保持开发者工具打开，按 Ctrl + Shift + P 调出命令菜单，运行 Disable JavaScript，然后刷新页面。完成后运行 Enable JavaScript 恢复。这个检查只能说明当前浏览器页面对脚本的依赖程度，不能模拟所有 AI 系统的抓取行为。Chrome 禁用 JavaScript 的操作说明

可以按下表记录观察结果。

前三种结果已经足够指导下一步修复。比如正文只存在于渲染后的 DOM，就可以让服务端渲染或静态生成承担核心业务内容，把交互控件继续留给客户端。Google 官方也建议考虑服务端渲染或预渲染，以降低对抓取程序执行脚本的依赖。Google 对渲染方式的说明

这里的目标是让公开页面的初始 HTML 就包含真实业务信息。需要同步更新的服务范围、价格或联系方式，应由可靠的数据来源生成，避免静态正文与交互组件显示不同内容。

抓取许可和索引指令分开查

取到完整 HTML 后，检查站点的 robots.txt，以及页面中的 robots meta 和响应头中的 X-Robots-Tag。它们解决的问题不同。Google 只有在允许抓取并实际取得页面时，才能发现页面上的索引指令；如果 URL 已被 robots.txt 阻止抓取，页面上的 noindex 可能无法被读到。Google robots meta 与响应头规则

面向 ChatGPT 搜索，还需要辨认具体爬虫。OpenAI 将用于搜索的 OAI-SearchBot 与用于模型训练的 GPTBot 分开配置，站点可以允许前者、限制后者。用户触发访问所用的 ChatGPT-User 又有不同用途，不能拿它的记录替代搜索爬虫记录。OpenAI 爬虫说明

如果企业决定允许 ChatGPT 搜索抓取，可以检查现有规则是否覆盖该服务页，再检查 CDN 是否放行官方公布的请求来源。修改前应保留管理后台、私有内容和其他路径原有的限制。

本地给 curl 换一个机器人 User-Agent，只能测试服务器是否按这个字符串返回不同内容。真实来源还要结合平台公布的 IP 信息核实，不能仅凭日志里的名字认定访问者身份。OpenAI 的说明页提供了搜索爬虫 IP 列表。OAI-SearchBot IP 列表

修复后复查同一个业务页

复查时继续使用原网址，并保存新的响应头和 HTML。先确认请求到达正确页面，主要正文已经进入初始 HTML，浏览器开启脚本后也没有出现另一套业务描述。

Google 的实际搜索状态还要到 Search Console 的 URL 检查工具里查看。实时测试可以帮助检查当前页面和渲染结果；索引状态需要结合已索引版本单独判断。Google JavaScript 排障文档

对于 Google AI Overviews 和 AI Mode，页面要进入索引并符合展示搜索摘要的条件，才有资格作为支持链接出现。Google 没有为它们增加另一套专用技术要求，满足要求也不保证页面一定被展示。Google AI 搜索功能与网站要求

后续如果观察 AI 回答，应记录原始问题、平台、测试时间和实际引用网址。一次技术修复可以让网页正文更容易被取得；是否出现品牌、是否引用这张服务页，需要在后续回答中继续观察。排查记录最后落到具体页面和具体缺陷，开发人员才知道下一次发布应当改哪里。

如果需要把这次技术排查与业务正文、发布后复查连接起来，可以继续读现有网页改进指南。

主要参考资料

• Google JavaScript SEO 基础
• OpenAI 爬虫说明
• Google AI 搜索功能与网站要求

资料核对日期为 2026 年 10 月 8 日。