GEO 审计清单：AI 搜索读得懂你的网站吗？

选择覆盖客户决策过程的页面

只检查首页，可能会漏掉真正介绍服务的页面。先检查首页、一个重点服务页面、价格或报价页面、联系页面，以及一篇近期发布的文章。再测试一个明确不存在的 URL，看看网站如何处理错误。

测试前，先写清预期结果：服务页面应返回服务说明，联系页面应提供有效的联系方式，不存在的 URL 应返回真正的未找到响应。有了这些标准，检查结果才有据可比。

Profound 发布的 Pages 功能将页面内容、爬虫活动和引用放在同一视图中。本清单借鉴的是这一点：看到一项结果，还要检查它对应的实际页面。笼统的可见度数字，无法告诉你某个重要 URL 是否只返回了空内容。

先检查响应，再看视觉设计

请开发者为每个选定的 URL 保存 HTTP 状态、相关响应头和初始 HTML。你不必读懂每行代码，只需在保存的响应中查找服务名称、一段有辨识度的文字、主标题和联系链接。

把响应内容与用户看到的页面对照。如果浏览器展示了详细的服务说明，而初始响应只有加载提示，就记下这个差异。不同访问程序的渲染能力不同。直接在响应中提供关键信息，更方便检查，也能减少对一连串脚本成功运行的依赖。

即使状态码是 200，也要检查响应正文。安全验证页、通用错误页或回退到首页，都不是预期的服务页面。错误页做得再精美，也不应返回表示成功的状态。将截图和响应证据一起保存，方便复现问题。

一并检查页面发现路径与索引设置

将公开的 robots 抓取规则、页面索引指令、规范 URL、站点地图，以及指向页面的内部链接放在一起检查。它们各有用途，但应与页面的发布意图一致。

Google 的 robots.txt 文档明确区分了控制抓取和从搜索结果中移除内容。不要把 robots 规则当成可靠的隐私保护措施。公开内容和私有系统需要各自合适的访问控制。

站点地图不应是实用内容的唯一入口。在所属的文章汇总页中加入服务文章的链接，再将文章链接到它介绍的服务。链接文字应说明目标内容，让读者判断是否值得点开。

检查 CDN 和防火墙如何处理请求

页面可能在本地正常运行，但 CDN 或防火墙会改变生产环境中的响应。用普通的未登录请求测试线上域名和深层 URL。记录重定向及任何验证页面。请管理边缘配置的人检查对应事件，不要大范围关闭防护。

分别写明搜索机器人、模型训练爬虫和用户触发的检索可以访问什么。使用机器人 User-Agent 的模拟请求可以帮助发现规则，但不能证明经过验证的机器人会得到相同响应。要进一步确认，应核对已验证的爬虫流量，或使用搜索平台提供的检查流程。

检查工具收到 403 时，应保留时间戳、URL、请求条件和响应信息。原因可能是访问规则、网络路径，也可能是工具本身。不要只凭一次原因不明的失败，就断言整个网站无法访问。

真实诊断：我们的本地站点地图为什么返回 404

2026 年 9 月 28 日，FoundUp 的本地 /sitemap.xml 返回 404，而生产环境的同一文件返回 200，并列出九个页面。原因在于构建模式不同：本地预览有意省略了用于发现页面的文件，并添加 noindex；生产构建则会生成这些文件。

解决办法是选对构建模式，无需再人工维护一份 URL 列表。本地 SEO 检查构建可以生成包含 25 个页面的清单：九个核心页面、十篇文章和六篇比较指南。只有运行该构建，才能访问这些页面。这份构建清单不能证明页面已在生产环境发布或被搜索引擎收录；本地有 25 页，也不代表检查当时这 25 页都已部署或收录。

检查你的网站时，对照线上文件、本地输出目录和构建命令。也要检查响应头：即使站点地图存在，整个预览环境仍可能带有生效的 noindex 响应头。文件是否存在、页面是否允许建立索引，以及搜索引擎是否已收录，需要分别确认。

检查正文时，使用普通 GET 请求：

curl -sS -D - https://getfoundup.ai/robots.txt
curl -sS -D - https://getfoundup.ai/sitemap.xml
curl -sS -D - http://localhost:8787/sitemap.xml

这些命令用于检查公开响应。它们不会冒充经过验证的爬虫，也不会查询搜索引擎的索引。

历史检查：2026 年 9 月 29 日 04:58 UTC

2026 年 9 月 29 日 04:58 UTC，再次检查生产环境时，九个核心页面均可正常访问，站点地图也有九条记录。十个文章路由和六个比较页面路由全部返回 404。本地源码通过内存中的检查生成了 25 页，但当时本地预览服务器并未运行。这反映了不同的发布状态，不能证明搜索引擎已收录这些草稿。

随后在 05:57 UTC 检查生产环境的价格页面和常见问答页面时，发现布局已经更新。这也说明，检查时应记下时间，发布本地副本前还要再次核对。这些记录只说明受检版本当时的情况，不能证明搜索引擎已抓取它。

把问题拆成可逐项验证的小修复

每个问题都应写明 URL、实际情况、预期情况、负责人和复测方法。“改善 SEO”太宽泛；“价格页面向测试请求返回了验证页，请检查对应的边缘层事件，并确认应有的公开响应”，才是开发者可以着手排查的问题。

修复后，重复相同请求，并检查另一个有代表性的页面是否受到意外影响。对于路由更改，还应复测旧 URL 和页面不存在时的响应。对于内容更改，应检查初始 HTML，并确认可见事实与元数据、结构化数据一致。

最后列出两份清单：已通过的技术检查，以及尚未证实的外部结果。响应正常，并不能证明页面已收录、获得排名、被引用，或真实用户访问时速度良好。结合维护流程持续检查，也可参考 HTML 与 Markdown 指南，让发布格式保持简单。

上线后验证：2026 年 9 月 29 日

2026 年 9 月 29 日 07:42 UTC，全部 25 个规范页面均返回 HTTP 200。站点地图包含全部十个文章 URL 和六个比较页面 URL。全文参考文件包含 25 个页面区块，RSS 订阅源包含十个条目。这些检查确认了发布和可访问性，但不能证明搜索引擎收录或 AI 引用。

早期的失败仍保留在记录中。后续检查确认，当时的发布问题已解决，但不能证明独立的搜索或 AI 平台已更新其副本。相关后续情况可参阅带日期的变更记录和参考文件检查。