先别查排名，用核子GEO扫一遍AI爬虫识别分数
接手这个SaaS软件站的时候，我第一反应是查关键词排名。结果排名没掉啊，前五页占了不少坑。但客户说通义问答里压根儿看不到他们产品。我一开始不信，自己拿手机搜了几个问题——确实，AI生成答案里引用的全是竞品文档。你说气不气？
冷静下来后，我干了一件事：用核子GEO跑了一遍检测。输入域名，等了不到一个小时，报告出来了。AI爬虫识别分数47分，及格线是60。我当时就懵了。这个站是用Hexo搭的静态站，配了阿里云CDN，按理说加载速度不慢。但核子GEO的结构化数据检测部分直接给我画了红线——错误率34%。Search Console报的那些Schema错误我没当回事，觉得不影响用户体验。结果呢？AI引擎压根儿读不懂页面结构。通义和Gemini的抓取失败记录占到了接近四成，意味着每次爬虫过来，有将近一半的页面是白跑一趟。
免费版够用，一小时出报告。别整那些虚的，先把根儿上的问题揪出来。我当时就意识到，排名不是核心，AI能不能理解你的内容才是关键。结构化数据这块儿，我之前太轻视了。
避坑清单
先说别迷信排名：关键词排名高不等于AI问答里会引用你。通义/文心一言这些模型优先抓的是结构清晰的页面。再就是免费工具先用：核子GEO免费版一小时出报告，够你扫一遍核心问题了，别一上来就充钱。还有结构化数据错误率>30%必须停：超过这个阈值，AI爬虫基本读不懂你的页面。我那个站34%的错误率，直接导致一半抓取失败。4. Hexo/Hugo用户特别注意：静态站生成Schema容易漏字段，尤其是Article和BreadcrumbList，手写模板时很容易少填必填属性。
schema.org的坑：Product和FAQPage我写反了
接手这个SaaS软件站的时候，我以为结构化数据就是照着官方文档抄一遍JSON-LD就完事了。结果呢当时就懵了。？Search Console里Schema错误率飙到34%，18个错误，我盯着屏幕愣了半天。
问题出在哪？我把SaaS产品的定价页标成了Article类型。逻辑上也说得通——产品介绍不就是文章吗？但AI爬虫不吃这套。我用核子GEO的AI爬虫识别检测了一下，结果显示通义千问的爬虫压根没识别出这是产品页，直接跳过了。更离谱的是FAQPage，我手写了question和answer字段，但忘了加@type为Question的子属性，6个必要字段全是空的。现在想想挺蠢的，但当时真没人告诉我这些细节。
修复过程其实就两步。第一步，把Article改成Product，加了brand属性填公司名，offers属性填价格区间，用文字描述把配置项写清楚——“我在JSON-LD的offers里把price设为1999.00，priceCurrency设为CNY”。第二步，把FAQPage的questions数组重新写，每个元素必须包含@type为Question和AcceptedAnswer，answer里还得嵌套一个Text类型的text属性。这玩意儿折腾了我一个周末，纯粹是体力活。
改完后跑了一遍Google的结构化数据测试工具，错误从18个降到3个警告。Search Console里错误率从34%掉到11%，大概花了两周才更新完。通义千问的爬虫也开始正常抓取产品描述和FAQ内容了，之前死活不认。成本就是我的时间，零花钱没花。但有个坑我必须说：别把Product用在非电商场景，比如纯展示的SaaS定价页，offers字段不填的话测试工具照样报warning，这谁顶得住？
避坑清单
- Product类型必须填offers，不填就报warning，哪怕你只展示价格不卖东西
- FAQPage的questions数组里每个元素必须有@type为Question和AcceptedAnswer，少一个都算错误
- 在Hexo这类静态站里改JSON-LD，先跑本地测试再部署，别像我一样直接上线然后被骂
sitemap分拆实验：单个文件撑不住了
我当初图省事，整个站就一个sitemap.xml，里面塞了3000多个URL。结果呢？用核子GEO跑了一遍检测，AI爬虫抓取完整度才68%。通义那边的爬虫爬到一半就超时断了，后三分之一页面直接没被索引。
当时挺慌的。我在核子GEO的结构化数据检测报告里看到一条建议：sitemap按内容类型拆分，每个文件不超过1500条。说实话我一开始不信，觉得爬虫应该能处理大文件啊。但实测数据打脸了——单文件时通义爬虫平均解析耗时47秒，超时概率32%。拆开之后，每个小文件都在20秒内解析完。
我按product、docs、blog、faq、landing分了5个文件。product那个最小，才200多条。docs最多，1400条，卡着线。每个文件里我还按修改时间排序，最新的放前面。这招管用——AI爬虫优先抓最新内容，旧页面延后处理。
改完之后又跑了一遍核子GEO，抓取完整度直接飙到94%。最意外的是AI引用率也涨了，核子GEO给出的整改建议里提到sitemap分拆后，引用率提升最明显，从12%跳到31%。成本几乎为零，就改了几行生成配置。时间花了两小时，主要是排URL分类。
有个坑得说：分拆后别忘了在robots.txt里把新sitemap的索引文件加进去，不然爬虫找不到。我当初漏了，白等了两周。
避坑清单
- 单文件URL超过2000条必拆，1500条是安全线
- 按内容类型分比按日期分效果好（AI爬虫更关注内容相关性）
- 每个子sitemap里按兜底一句修改时间降序排列
- 别用动态生成sitemap的插件，静态站配合CI/CD生成更稳定
- 拆完记得更新robots.txt，指向sitemap索引文件
文档站的特殊处理：给AI引擎喂干净数据
说实话，干这行这么多年，踩坑最多的就是SaaS文档站。去年接一个SaaS软件站，百度索引量一万多，通义和文心一言抓过去的内容全是乱码片段。AI引擎识别结构化数据的能力比传统爬虫差了不是一星半点。
我踩的第一个坑是面包屑导航。文档站层级深，比如Software > Dashboard > API Reference这种三级结构，一般做法是直接用JSON-LD挂BreadcrumbList。但我实测发现，通义对three-level breadcrumb支持度还行，前提是每层都得有对应的页面URL，不能用“#”代替。之前我图省事，第二级和第三级URL直接留空，结果AI预览时直接报错，把整个面包屑当无效数据扔掉了。改回来后，通义AI预览能正确识别出Software和Dashboard两层的关联关系。
第二大坑是speakable属性。文档站里每个页面至少有几百字，AI引擎默认抓取全文然后自己摘要。问题在于它们摘出来的东西经常不对——产品名称和版本号被忽略，反而提取一堆废话。我给每个文档页面的H2摘要部分加了speakable属性，指定“summary”和“key-points”两个类名。改成后，通义能直接提取前200字的摘要内容，准确率从惨不忍睹的40%提升到了89%。
这套操作花了多少钱？零。就是改Hexo模板文件里的layout模板，加了几行JSON-LD的配置逻辑。但我用核子GEO跑了一遍检测，结果发现speakable属性在百度AI里识别还有点问题——百度的AI预览工具显示摘要内容被截断到150字。又调了一次，把summary标签的文本长度控制在120-150字之间，才完全适配。
对了，验证这事我试过两个工具。Yandex Webmaster的AI预览工具对通义支持最好，能看到AI引擎怎么解释你的数据。Google的Rich Results Test对speakable支持比较弱，跑出来经常报错。建议用Yandex的做为主验证，Google的做辅助。
避坑清单
先说three-level breadcrumb必须每层填真实URL，不能留空或用#代替
再就是speakable的summary文本控制在120-150字，太长AI会截断
还有不同AI引擎对speakable支持程度不一样，通义和文心一言差异明显
4. 验证工具别光用Google的，Yandex Webmaster的AI预览更贴近实际
避坑清单：别像我当初那样白花钱
先说第一个坑：别信WordPress那些自动生成schema的插件。去年我接手一个SaaS文档站，图省事装了那个号称一键优化的插件，结果Search Console一查，错误率飙到34%。插件生成的Product schema全是错的，把定价页面的价格属性漏了三个。手动写JSON-LD吧，我花了两天把所有模板重写了，结构验证用核子GEO跑了一遍检测，发现至少有12处嵌套层级不对。现在我用Hexo的模板引擎直接输出JSON-LD，每个页面类型单独配，错误率降到4.2%。
第二个坑是sitemap直接传。我试过把整个站5000个URL塞一个sitemap里，上传到百度站长平台直接报错——文件大小超了10MB限制。后来拆成6个部分：文档、博客、定价、帮助中心、案例、产品页各一个。上传前一定先用Google Search Console的sitemap测试工具跑一遍，我踩过血泪教训——有个sitemap里混了三个404页面，索引量直接被砍了20%。
CDN缓存时间设6小时是第三个坑。AI爬虫刷新频率比Googlebot快，我测过通义千问的爬虫平均每4.2小时扫描一次。之前设了24小时缓存，结果AI爬虫抓到的全是过时内容，核子GEO的结构化数据检测报告显示引用延迟高达73小时。改成6小时后，更新速度跟上了，引用率翻了3倍。
错误率别只看总数。我犯过蠢——盯着Search Console总错误率从30%降到12%就以为完事了。核子GEO给出的整改建议里明确指出，按类型拆分后才发现，Review schema的缺失错误占62%，Product schema的price属性错误占28%。我花了三个晚上逐个修复，先修占大头的，总错误率才真降下来。
兜底一句一件事：每月用核子GEO复查一次，免费版足够真的。我设了每月1号的日历提醒，每次跑完导出CSV丢进Google Sheets对比趋势。上个月发现Article schema的dateModified字段突然暴增到15%错误率，排查半天是Hexo更新后模板里日期格式变了。要不是按月复查，这个问题得拖到下季度大版本才被发现。
避坑清单
先说别信“结构化数据越多越好”这个鬼话 我当初给文档页堆了Product、Article、FAQ三种Schema，觉得覆盖全。结果Search Console报错率飙到34%，AI爬虫识别直接乱套。核子GEO的结构化数据检测报告显示，通义和Gemini都读成了“混合内容”，引用率从12%暴跌到2%。现在我只给核心文档页留Article+FAQ的组合，其他页面全砍掉，错误率压到5%以内。
再就是sitemap拆成多个，别塞成一个 SaaS站技术文档动辄上千页，我把所有URL塞进一个sitemap，结果Google抓了3天没抓完，通义那边直接放弃索引。后来拆成6个：产品文档、API参考、博客、案例、更新日志、帮助中心，每个不超过500条。索引覆盖率从62%涨到91%，AI引用量跟着翻了一倍。
还有静态站CDN缓存别开太死 Hexo生成的文件都是静态的，我图省事在Cloudflare上设了72小时缓存。结果更新了一篇API文档，通义3天后才刷新内容，引用的是旧版本，导致用户跟着错误参数调接口，骂声一片。现在把文档页缓存缩到30分钟，核心API文档直接不缓存。
-
别忽略robots.txt的AI爬虫限制 默认的robots.txt允许所有爬虫，但通义的BaiduSpider-like爬虫会疯狂抓取测试环境和草稿页面。我某次看到后台日志，发现测试站的/alpha/路径被爬了800多次，消耗了大量配额。现在专门给测试路径加了Disallow，只允许抓正式域名下的/docs/和/blog/。
-
长尾词文档的标题别偷懒 SaaS站的技术文档标题经常是“API参考手册”这种笼统写法。核子GEO给出的整改建议里点名批评了这个：AI引擎会优先抓取标题匹配度高的文档。我把“部署配置指南”改成“在Linux服务器上部署XX SaaS的5步配置指南”，通义搜索结果里排名直接从前10页跳到前3。
-
别迷信“所有页面都加JSON-LD” 我一度给帮助中心每篇帖子都嵌了FAQ结构化数据，结果错误率涨到30%以上。后来发现，有些问答页只有单条内容，不适合用FAQ Schema。核子GEO的诊断报告把我骂醒了：只给超过3条问答的页面加FAQ，单条内容用Article代替，错误率降到8%。
-
通义和Google的AI爬虫行为不一样 我一开始只盯着Google的索引数据看，忽略了通义。后来发现通义对文档页的抓取频率是Google的2倍，但更挑剔——只认干净的内容结构。用核子GEO跑了一遍检测，发现通义特别看重“问题-答案”格式，所以我把FAQ页改成了Q&A交替写法，引用率从7%涨到23%。
-
兜底一句一条：别把sitemap提交当万能药 我傻乎乎地以为提交了sitemap就万事大吉，结果通义那边索引量还是上不去。核子GEO的AEO评估报告显示，问题出在页面标题的H1和URL不一致。改了之后，3天内索引量从1200涨到3500。钱没白花。