先让重要页面能访问、正文能读取，再检查抓取规则、页面结构和 Schema，最后持续复查。
一、先把检查顺序排清楚
游客想了解一家酒店，可能会问：房间适合几个人？离景点远吗？怎么去、能不能退？如果官网只有漂亮大图，缺少这些说明，客户和 AI 都很难找到完整的信息。
技术上的第一步，是让需要公开的页面能访问、关键信息能读取；接着检查抓取与索引规则、页面结构和信息一致性，再考虑适合的结构化数据。
先从真实页面和真实问题入手：能访问、能读取、内容清楚、持续更新。
二、第一步：从几个重要页面开始
先列出官网已有的重要页面，例如首页、产品或服务页、联系页；酒店网站还可以选择已有的房型和交通页面。每种实际存在的页面类型抽查一两个，不必为了检查新建栏目。
- 记录页面地址和用途：这页想回答客户什么问题？
- 用浏览器打开页面，检查正文、图片、链接和移动端展示。
- 再检查实际返回的 HTML，确认主要标题、介绍和关键信息能否读取。
用两条命令检查公开页面
技术同事先把示例地址换成自己的公开页面，再执行两条检查命令：第一条查看 GET 响应和跳转，第二条在返回内容中查找关键词。
geo_url='https://example.com/room'
curl -sSL -D - \
-o /dev/null "$geo_url"
curl -sSL "$geo_url" | grep -E '房型|退改'
状态正常后，还要看返回的是否是目标页面，而不是验证码、登录页或错误提示。关键词没找到时，再查看完整 HTML 和浏览器渲染后的内容；文本编码、页面结构或脚本加载都可能影响匹配。
如果关键内容只在浏览器执行脚本后出现，可以根据实际架构评估服务端渲染、静态生成等方案。已经使用 SPA 的网站，也可以先从重要页面入手，不必因为使用某个框架就重做。
三、第二步：检查抓取、索引与安全策略
robots.txt：检查是否误拦公开内容
查看网站根目录的 robots.txt，确认需要公开的页面没有被目标爬虫规则意外限制。如果网站没有该文件，先了解目标平台的处理方式，不必为了凑清单新增一份。
User-agent: *
Disallow: /private/
User-agent: GooglebotDisallow: /private/
这是分组写法示例。按 Google 的规则，匹配到更具体的爬虫分组时，不会再叠加通用星号分组；需要保留的限制应写进相应分组。（来源：Google 抓取规则说明）
robots.txt 是抓取规则，不是访问权限。需要保护的后台、订单和内部资料，应使用登录与权限控制；不要依赖 robots.txt 隐藏敏感内容。
noindex：检查页面是否被要求不收录
需要公开的页面，还要检查 HTML 中的 meta robots 和 HTTP 响应头 X-Robots-Tag，确认是否误带 noindex。noindex 表达索引意图，robots.txt 则用于控制相应爬虫的抓取。
以 Google 为例，爬虫需要能够访问页面，才能读到 noindex；仅用 robots.txt 禁止抓取，也不等于页面网址绝不会出现在搜索结果中。（来源：Google 搜索中心）
区分搜索抓取与模型训练
不同爬虫的用途不一样。以 OpenAI 为例，OAI-SearchBot 用于 ChatGPT 搜索，GPTBot 用于可能被用来训练模型的内容采集，网站可以分别设置策略。（来源：OpenAI 官方爬虫说明）
目标平台、公开范围和内容使用策略应由企业确定。豆包等平台的实际抓取方式与数据来源，按各平台官方说明及可核实的记录判断，不把某个平台的规则套用到所有平台。
如果规则允许但页面仍无法读取，可以排查 CDN、WAF、验证码、登录要求或服务器错误；确认真实爬虫时，应结合平台提供的验证方法和日志，而不是只看 User-Agent 名称。
四、第三步：把页面结构和信息写清楚
用酒店页面回答真实问题
下面用虚构酒店示例说明页面结构；同样的方法也适用于景区、产品和服务页面。
- 酒店首页：介绍酒店位置、主要特色、适合人群，并提供房型和出行入口。
- 房型页面：写清房型名称、床型、入住人数、设施，以及对应预订方案的含早和退改规则。
- 出行与常见问题：说明交通方式、停车、入住时间与咨询方式，并及时维护变化的信息。
页面标题要能说明主题，正文按内容层次组织；产品信息、规则和问答尽量以可选择的文字呈现。图片用于展示场景，重要信息仍应在正文中说明；有实际信息用途的图片可补充准确的图片描述。
让页面容易被发现
从导航和正文中链接到重要页面；同一内容有多个网址时，检查规范网址和站内链接是否一致。官网改版时，把有对应关系的旧网址跳转到新页面，再抽查旧入口。
网站规模较大或内容持续更新时，站点地图可以帮助搜索引擎发现页面；如果使用 lastmod，应反映实际的重要更新。站点地图和 canonical 是辅助信号，不代表页面一定会被收录。
小型网站如果页面少、内部链接清楚，可以结合自身需要判断是否建设站点地图。不要为了技术清单，增加与业务无关的页面或栏目。
五、第四步：再按页面类型补充 Schema
Schema 结构化数据可以用规范的字段描述页面上的组织、酒店、产品或文章等信息。先核对页面现有事实，再选择适用类型；不需要追求标记数量。
例如，下方是虚构酒店的 JSON-LD 写法，只表达页面上已经公开的名称和网址：
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Hotel",
"name": "山居度假酒店",
"url": "https://example.com/"
}</script>
正式使用时，以真实的主体、页面和产品信息填写；没有的价格、评分、评价或资质不要为了补字段而编造。标记应与页面可见内容一致，并检查语法和对应平台的支持情况。
Schema 是补充信息的方式。正文是否完整、页面能否访问，仍然是更优先的工作。
Google 搜索的 AI 功能说明指出，不需要为这些功能额外添加专门的 AI 文件或特殊 Schema。其他 AI 平台的具体处理方式应分别核对。（来源：Google 搜索中心）
六、上线前后，怎么检查和复测？
- 上线前：抽查重要页面的响应、正文、抓取与索引规则、标题和内链。
- 改版时：检查旧网址跳转、规范网址和已有站点地图是否与实际页面一致。
- 更新时：同步检查产品介绍、规则、图片说明及相关页面，避免不同页面互相矛盾。
- 上线后：按相同问题和平台定期观察回答与引用来源，把发现的问题带回网站和内容维护。
能访问、能抓取、被索引、出现在 AI 回答中，是不同环节。可以先确认页面和内容是否正常，再结合真实平台的表现持续观察。
如果网站主要面向百度，可结合百度搜索资源平台查看已有的抓取诊断和收录信息；其他平台则使用其提供的工具和可核实的数据。
七、一份可以直接使用的检查清单
- 页面：重要网址能打开，返回的是目标页面。
- 正文：标题、业务介绍、关键参数和客户常问问题能以文字读取。
- 规则：robots.txt、noindex 和访问权限符合页面的公开策略。
- 结构：页面标题清楚、内部链接可用；改版时旧地址跳转正确。
- 信息：产品、服务、联系方式及规则与实际情况保持一致。
- 标记：按页面需要使用 Schema，字段与可见正文一致。
- 复查：上线和更新后抽查页面，并持续观察平台回答与来源。
八、几个常见问题
Q：网站用了 JavaScript，一定要重新开发吗？
不一定。先检查重要页面的初始 HTML 与实际展示，再按问题选择局部改进、服务端渲染或静态生成等方式。
Q：是否必须开放所有 AI 爬虫？
不必。先确定企业希望公开的内容、目标平台和数据使用策略，再按各平台的官方规则分别配置。
Q：要不要配置 llms.txt？
可以结合目标平台和实际需求评估；优先解决访问、正文、链接和信息更新。不要把它当成所有平台的必选项。
Q：Schema 越多，被 AI 推荐的机会就越大吗？
建议做。Schema 不是越多越好，但核心页面（首页、产品/房型页、FAQ、文章页）建议补上对应的结构化数据，帮助搜索引擎和 AI 更准确地识别页面主题、实体和关键信息，提升检索与信息抽取的准确度。先保证类型适用、字段与正文一致，再按页面逐步补充；没有的信息不要编造。