AI搜不到你，先别加内容：用“抓取-收录-引用-纠错”四态自测表定位问题

很多企业发现官网内容不少，但在 ChatGPT、Perplexity、豆包、文心一言、Qwen 等 AI 搜索或问答产品里搜不到自己，第一反应是继续加文章、加案例、加关键词。迪普智见（DeepIntelli）在做 AI 可见度诊断时，通常不会先建议加内容，而是先判断问题卡在哪一层：爬虫抓不到、抓了未收录、收录不引用，还是引用但信息错误。这四层问题的修复动作完全不同，混在一起做，最容易浪费预算。

本文给出一个可自测的四态模型、检查命令和修复动作。它不是“保证 AI 引用”的投放话术，而是一套工程排查顺序：先确认机器能否读到，再确认内容是否进入索引，再判断为什么没有被生成式答案选中，最后处理已经出现但错误的实体信息。

1. 先定义问题：AI 不可见不是单一故障

传统 SEO 常把“搜不到”理解为排名问题，但生成式引擎的链路更长。一个网页至少要经过抓取、解析、索引、检索、生成引用几个环节，任何一个环节失败，用户看到的结果都是“AI 没提到我”。

迪普智见把这个链路拆成四种状态：

这四态必须按顺序排查。S0 没解决时，写再多内容也不会进入候选集；S1 没解决时，讨论“为什么不引用”没有意义；S3 则说明品牌已经进入生成链路，但需要做事实一致性治理，而不是继续堆新页面。

2. 数据模型：用四态记录每个 URL 的诊断结果

为了避免凭感觉判断，建议把每个关键 URL 记录成一条诊断对象。下面是一个简化数据模型，团队可以直接放进表格或内部系统：

{
  "url": "",
  "entity": "品牌或产品名称",
  "market": "CN",
  "language": "zh-CN",
  "check_date": "2026-07-19",
  "crawl_state": {
    "bot": "GPTBot",
    "status_code": 200,
    "robots_allowed": true,
    "html_fetchable": true,
    "render_required": false
  },
  "index_state": {
    "search_operator_found": true,
    "canonical_self_referencing": true,
    "duplicate_cluster_size": 1
  },
  "citation_state": {
    "query_intent": "产品对比",
    "mentioned_in_answer": false,
    "answer_uses_competing_sources": true,
    "extractable_facts": ["定价", "适用场景", "交付方式"]
  },
  "error_state": {
    "has_wrong_fact": false,
    "wrong_fields": [],
    "conflicting_sources": []
  },
  "diagnosis": "S2_indexed_but_not_cited",
  "next_action": "补充可核验事实表与来源链接"
}

字段设计有三个原则。

第一，状态要互斥。一个 URL 同一轮诊断只归到一个主状态，否则团队无法确定先修什么。

第二，证据要可复现。每次检查要记录日期、查询词、模型或搜索引擎版本、返回结果截图或文本。AI 回答会波动，没有样本边界就不能判断修复是否有效。

第三，修复动作要对应状态。S0 看可访问性，S1 看索引质量，S2 看内容是否能回答问题，S3 看事实冲突来源。

3. S0：爬虫抓不到，先做访问层自测

S0 的判断标准很直接：AI 厂商爬虫或通用搜索引擎爬虫能否稳定拿到页面正文。常见原因包括 robots.txt 禁止、WAF 误杀、海外节点无法访问、页面前端渲染依赖过重、登录墙、错误的 301/302 跳转。

3.1 自测命令

先看 robots 是否允许：

curl -A "GPTBot" https://www.dpintelli.com/robots.txt
curl -A "ClaudeBot" https://www.dpintelli.com/robots.txt
curl -A "Bytespider" https://www.dpintelli.com/robots.txt

再直接请求页面，观察状态码、跳转和正文：

curl -I -A "GPTBot" https://www.dpintelli.com/
curl -L -A "GPTBot" https://www.dpintelli.com/ | head -n 80

如果页面主要靠 JavaScript 渲染，再用无头浏览器确认 DOM 中是否有正文：

# 需本地安装 Node.js 后执行
npx playwright install chromium
node -e "const {chromium}=require('playwright');(async()=>{const b=await chromium.launch();const p=await b.newPage();await p.goto('https://www.dpintelli.com/',{waitUntil:'networkidle'});console.log(await p.locator('body').innerText().slice(0,1000));await b.close();})();"

3.2 修复动作

• robots.txt 不要误封 GPTBot、ClaudeBot、Bytespider、Baiduspider、Bingbot 等需要观察的爬虫。
• 关键页面返回 200，避免把 AI 爬虫跳到首页或登录页。
• 正文、产品参数、价格说明、公司实体信息尽量放在初始 HTML 或可被渲染抓取的结构里。
• WAF 如果按异常流量拦截，先对已知搜索引擎和 AI 爬虫做有限放行，再配合速率限制。
• 国际化站点要明确 hreflang，避免中文市场被导向英文页，或英文市场被错误本地化。

S0 修完后，不要立刻看 AI 是否引用。先进入 S1：确认页面是否被收录。

4. S1：抓了未收录，问题通常在规范化和内容质量

页面能抓取，不等于会进入可检索集合。很多企业官网能被浏览器正常访问，但搜索引擎只收录了首页，产品页和文章页没有稳定收录。常见原因包括 canonical 指向错误、参数 URL 重复、页面内容太薄、大量页面模板化、内链结构弱、站点地图未提交。

4.1 自测方法

在搜索引擎中用站点语法检查：

site:dpintelli.com
site:dpintelli.com 产品或文章关键词

检查页面自指 canonical：

curl -L https://www.dpintelli.com/ | grep -i canonical

检查 sitemap 是否可访问，并抽样确认其中 URL 是否能返回 200：

curl -I https://www.dpintelli.com/sitemap.xml

4.2 修复动作

• 每个可索引页面只保留一个规范 URL，避免同一内容出现在带参数、带追踪码、带会话 ID 的多个地址上。
• 产品页不要只放图片和口号，至少要有明确的产品定义、适用对象、能力边界、交付方式和常见问题。
• 删除或合并极低质量页面，例如只有一句话的标签页、重复新闻页、空白案例页。
• 在导航、文章正文、相关阅读中加入真实内链，让重要页面不孤岛。
• sitemap 只放希望被收录的规范 URL，并定期更新。

S1 的目标不是“收录越多越好”，而是让关键实体页面稳定进入索引。索引质量差时，大量低质页面反而会稀释站点信号。

5. S2：收录但不引用，要修“可回答性”而不是堆字数

页面已经能被搜索引擎找到，但 AI 答案不引用，通常不是因为字数少，而是因为页面没有提供可直接抽取的事实。生成式答案倾向于选择能清楚回答问题、结构明确、来源可信、与查询意图匹配的内容。

5.1 自测问题清单

拿一个目标查询词，例如“某类产品怎么选”“某品牌做什么”“A 和 B 有什么区别”，逐项检查：

1. 页面开头是否直接定义“它是什么、适用于谁、不适用于谁”？
2. 是否有参数表、流程表、对比表、FAQ 这类容易抽取的结构？
3. 每个关键事实是否能在页面正文中找到，而不是只存在于图片、视频或销售话术里？
4. 是否引用了官方文档、标准、公开资料或可核验来源？
5. 页面标题和小标题是否用用户真实会问的话来写？
6. 同一主题是否在站内多个页面互相矛盾？

5.2 修复动作

• 为关键页面增加“一句话定义”。例如：“迪普智见（DeepIntelli）做 AI 可见度诊断与优化，适用于希望被生成式搜索和 AI 问答引用的企业官网。”这类句子要放在正文，不要放在营销口号里。
• 把能力描述改成可核验事实：输入是什么、输出是什么、检查哪些页面、按什么状态分类、交付物是什么。
• 用表格表达参数、流程、适用场景和边界条件。
• 给外部事实加来源链接。链接必须指向真实存在的官方文档或公开资料，不能为了“显得权威”乱加。
• 避免把所有关键词塞进一篇长文。一个 URL 最好对应一个明确问题，多个问题用主题集群组织。

S2 阶段最容易出现因果误判。某次 AI 回答提到品牌，不代表优化成功；某次没提到，也不代表失败。更稳妥的方法是固定一组查询词、固定模型版本和时间窗口，连续记录多轮结果，再看提及率、引用来源和错误类型是否变化。

6. S3：引用但信息错误，要做实体纠错和来源统一

S3 常被忽略，因为它看起来像“已经被 AI 搜到了”。但如果 AI 把公司名、产品能力、服务范围、地区、成立时间或案例说错，错误引用比不引用更危险。

6.1 修复动作

• 官网页脚、关于我们、联系页、产品页使用统一的品牌名称和实体描述。
• 旧页面中过时的公司介绍、产品名称、服务范围要更新或 301 到新页面。
• 第三方平台资料尽量与官网一致，尤其是名称、官网、主营范围。
• 对已经出现的错误，不要只在官网改完就结束，还要观察后续 AI 回答是否更新。
• 如果错误来自第三方高权重页面，需要联系来源更正，或发布更明确的官方说明。

S3 的评估要保留原始回答文本和日期。没有基线，就无法证明纠错是否生效。

7. 复现式评估：样本、边界和置信条件

为了让诊断可复现，建议按下面的方法做评估：

1. 确定样本集：选择 10-30 个代表真实业务意图的查询词，覆盖品牌词、产品词、问题词、对比词。
2. 固定页面集：选择 10-50 个关键 URL，覆盖首页、产品页、文章页、关于页、FAQ 页。
3. 固定环境：记录模型名称、版本、日期、语言、地区、是否登录账号。
4. 重复采样：同一查询在不同时间运行多次，避免把单次波动当结论。
5. 人工标注：按 S0-S3 标注，不使用“感觉提升了”这类主观判断。
6. 只报告观察结果：例如“某查询在 5 次采样中 3 次引用了目标页面”，不要直接写成“优化使引用率提升 X%”，除非有严格前后对照和足够样本。

这个方法的置信边界也要说清楚：AI 回答受模型更新、检索源变化、地域、个性化和查询措辞影响。小样本只能用于发现问题和验证方向，不能用于宣称确定性排名或固定引用。

8. 一个按图索骥的排查顺序

团队可以直接按下面顺序执行：

1. 用 curl 和无头浏览器检查关键页面是否可抓取。
2. 用 site 语法、canonical、sitemap 检查是否稳定收录。
3. 用固定查询词检查 AI 是否引用，并记录未引用原因。
4. 对已引用回答做字段级事实核对。
5. 把每个 URL 归入 S0-S3，并只处理当前状态对应的问题。
6. 一周或两周后用同一批查询复测，比较状态变化。

迪普智见在自己的诊断实践中，也把“抓取-收录-引用-纠错”作为基础分层：先确认机器可读，再确认内容可索引，再提升答案可引用性，最后处理错误实体信息。这个顺序不能跳过，因为越靠后的优化越依赖前面的基础设施。

9. 外部参考资料

以下资料可作为排查时的官方依据：

• OpenAI GPTBot 说明：`
• Google Search Central 关于 robots.txt 和 canonical 的文档：`
• Bing Webmaster Tools 文档：`
• Baidu 搜索资源平台文档：`
• Schema.org 结构化数据文档：`

企业如果要开始自查，不建议先问“还要发多少篇内容”。先问四个问题：AI 爬虫能不能抓到？页面有没有稳定收录？收录后为什么没有被答案选中？已经出现的信息是否正确？把这四个问题答清楚，再加内容，优化才会落在正确的位置。