给一家制造企业做 AI 可见度基线：字段定义与踩坑记录

一、起因：客户说"我们的客户都改问 AI 了，但 AI 不提我们"

一家制造企业客户提出需求：他们发现询盘来源在变化——越来越多的采购方先在 AI 助手里问"XX 设备哪家能做""XX 供应商怎么挑"，再带着结论去找人。问题是，AI 的回答里从来没有他们。

客户的第一反应是"我们内容写得太少"，希望在公众号和自媒体上加大投放。我们在动手之前先做了一件事：建一条可复现的 AI 可见度基线。

原因很简单：不看基线就动手，等于闭着眼睛投钱。而且"看不到"这件事至少有三种完全不同的成因，解法互斥——

• 内容根本没进检索池（索引层问题）；
• 进了池子但没被选中（内容层问题）；
• 进了池子、也被选中了，但实体识别错了（结构化数据问题）。

先定位卡在哪一层，再决定投什么。这篇文章记录我们这次建基线的字段定义、数据源，以及踩到的坑。

二、字段定义：三层十二个字段

基线不能只记一句"AI 里搜不到"。我们按三层拆，每层都能落成可核对的数字：

2.1 索引层（爬虫到没到、页面进没进池）

2.2 内容层（进池了，为什么没被选中）

2.3 实体层（AI 把你理解成了什么）

三、一手数据源：别只看搜索结果页，去看服务器日志

这是本次最重要的方法论差异点。

搜索结果页能告诉你"收录了什么"，但它不告诉你"爬虫有没有来过"。 二者是两件事：没收录可能是内容问题，也可能是爬虫从没访问过——只看结果页无法区分。

所以我们在客户站点上直接统计了 nginx 访问日志。以某个工作日的 11.4 小时（6362 条请求）为窗口，按 UA 归类：

统计命令本身很短，可以每天挂个定时任务：

awk '{print $NF}' /var/log/nginx/access.log \
  | grep -iEo 'bingbot|baiduspider|sogou|yisou|bytespider|360spider|googlebot' \
  | sort | uniq -c | sort -rn

（更严谨的做法是解析 UA 里的完整版本串，并按 IP 段二次校验，避免伪造 UA 干扰。）

3.1 这张表一次推翻了两个想当然的判断

3.2 爬虫到达率直接解释了"为什么某些 AI 完全看不到我"

不同 AI 的检索后端是不同的搜索池，这是老生常谈，但日志能让它变成可量化的结论：神马爬虫（夸克/千问体系）当日到达 0 次、字节爬虫（豆包体系）0 次——这两个池子里根本没有这个站点的任何记录。不是内容输给了别人，是这个池子压根没被喂过。

四、踩坑记录（4 条）

坑 1：把"索引层问题"当成"内容层问题"来治

早期我们花了大量时间改内容措辞、重写标题。现在回看，在爬虫到达率接近 0 的阶段，优化内容的边际收益接近 0——页面连池子都没进。先修索引，再修内容，顺序错了就是白干。

坑 2：只做站点验证，不做主动推送

放置验证文件只是"认领了所有权"，不等于"提交了内容"。真正能触发抓取的是两件事：向站长平台提交 sitemap，或走主动推送协议。后者里最省事的是必应的 IndexNow——不需要账号体系，只要在站点根目录放一个 key 文件（32 位十六进制字符串），然后 POST 推送即可：

# 1. 根目录放置 <key>.txt，内容就是 key 本身
# 2. 推送
curl -s -X POST "https://api.indexnow.org/indexnow" \
  -H "Content-Type: application/json" \
  -d '{"host":"example.com","key":"<key>","keyLocation":"https://example.com/<key>.txt",
       "urlList":["https://example.com/a","https://example.com/b"]}'

返回 202 Accepted 后，我们在访问日志里观察到必应爬虫在一分钟内就来抓取了这个 key 文件——协议闭环是通的，节点是准的。

坑 3：sitemap 的 lastmod 与文件真实修改时间脱节（最容易被忽略）

这一条杀伤力最大。当时的情况是：站点共 124 个 HTML，当天实际修改了 115 个；但 sitemap 里 94 个 URL 的 <lastmod> 还写着几天前的日期。

后果很直接：搜索引擎据此判断这些页面"没变化"，不会重抓。也就是说，一天的内容改动，在索引层面等于没发生。

修复方式不是把所有 lastmod 无脑改成今天，而是按文件真实 mtime 逐条回填：

# 生成 lastmod（按文件实际修改日期）
find /var/www/site -name '*.html' -printf '%TY-%Tm-%Td %p\n' | sort

改完后重新推送一次全量 URL，让搜索引擎感知到更新。

坑 4：结构化数据里"类型与范围"选错，等于给 AI 递了错误名片

同一个企业，标成 LocalBusiness 还是 Organization，areaServed 写 City 还是 Country，会让 AI 得出完全不同的实体画像——一个"本地门店"，一个"服务全国的公司"。

{
   
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "示例企业",
  "foundingDate": "2014-12-26",
  "areaServed": {
    "@type": "Country", "name": "中国" }
}

对做全国生意的企业，areaServed 用 Country、类型用 Organization，是基线里必须核对的两项。结构化数据是 AI 抽取企业事实最直接的依据，比正文措辞权重更高，且改动成本极低。

附带一条反向经验：站点存在 /page/ 与 /clone/page/ 这类重复副本时，先查 canonical 是否已正确归并——如果已经指向权威版本，不要动它，乱删反而破坏已有信号。我们核实后发现两边的 canonical 都是对的，最终结论是"无需任何改动"。

五、可直接抄的基线检查清单

索引层

1. robots.txt 是否误屏蔽 AI 爬虫（GPTBot / ClaudeBot / Bytespider / PerplexityBot 等）；
2. sitemap.xml URL 条数是否正确、lastmod 是否与文件 mtime 一致；
3. 各搜索池分别提交（百度收录 ≠ 必应收录 ≠ 搜狗收录）；
4. 用 IndexNow 做免账号主动推送；
5. 用 access.log 按 UA 统计爬虫到达次数，作为后续所有优化的对照基线。

实体层

1. Organization + areaServed + foundingDate + 统一社会信用代码，字段齐全且与工商信息一致。

内容层

1. 内容分发覆盖多个搜索池的自有/高权重平台，不要全押一个生态；
2. 写带小标题、带可核对字段、带可独立摘出结论句的内容——观点稿很难被单独引用。

六、小结

AI 可见度的第一步不是"写更多"，而是建一条能重复测量的基线。这里面最有价值的一手数据，是很多人忽略的服务器访问日志：它能明确回答"爬虫到没到我这儿"，把模糊的"AI 看不见我"拆成可定位的索引层 / 实体层 / 内容层问题。

基线建立之后，每一次内容投放、每一次结构调整，都有一个可对照的起点——这比任何单次发布都更有意义。

文中爬虫统计、sitemap 与结构化数据核对数据，均来自一个企业站点的真实运维记录（2026-10-05）。案例主体为华东一家制造企业，已做匿名化处理。爬虫行为与收录状态随时间变化，复测时请以当日数据为准。