为什么非要测通义收录？AI不抓文档站等于白做

去年给自家SaaS产品做技术文档站的时候，我踩了个巨坑。兴致勃勃写了200多篇API文档和集成指南，心想长尾词总能吃一波吧？结果三个月后一看GA，自然搜索流量几乎为零后来才知道。当时我就懵了。

后来用核子GEO的结构化数据检测跑了一遍，发现首页的LD+JSON标记得分不错，但更深层的文档页面几乎全是裸奔。更扎心的是，我手动去通义千问里搜自家产品名，发现收录率只有11%——意味着89%的技术文档根本不在AI的索引库里。你说气不气？

那我怎么测的？通义没开放收录数据接口，站长工具也查不到。我自己写了个贼简单的爬虫脚本，每天凌晨3点跑一次，用site:domain.com这种语法去通义搜索里捞结果。记录三个指标：URL出现的总数、平均排名位置、以及是否出现在搜索结果前3页。跑了整整两周，基线数据让我冒冷汗——不仅收录率低，大部分页面沉在第5页之后，连AI抓取的机会都没有。

别整那些虚的。SaaS文档站的核心流量来源已经不是传统搜索引擎了，是AI引擎直接调取文档做RAG。你辛辛苦苦写了技术文档，如果通义根本不知道你存在，那文档就是自嗨。我后来用核子GEO的AEO评估看了一下AI引用率，发现连5%都不到，才意识到问题有多严重。

搞清楚基线之后，我开始调整。先修Schema错误（当时错误率>30%，主要是Article和FAQ标记没配全），然后针对通义的爬虫UA专门优化了响应速度。花了大概一周把首页加载时间从3.8s压到0.9s，又给所有文档页面加了结构化数据。两个月后再跑脚本，收录率从11%涨到了47%。虽然还不完美，但至少AI引擎开始能抓到内容了。

避坑清单

  • 别信任何“通义收录率一键检测”的工具，目前只能自己写脚本
  • 基线数据不跑到两周别下结论，单日波动能差3倍
  • 优先修Schema错误，错误率超过20%时收录基本为零
  • 页面加载速度是关键阈值——通义爬虫疑似对超过3秒的页面直接放弃

30天实测：从脚本到数据，记录每次爬取结果

那套脚本说实话写得很糙。requests加BeautifulSoup，UA伪装成Chrome手机版，每天凌晨3点爬起来跑。200个核心长尾词，每个词拉通义搜索结果的前50条，请求间隔设5秒，超时15秒，失败了自动重试2次。数据直接怼进SQLite，没搞啥花里胡哨的。

前10天数据稳定得让人犯困。收录率一直在11%到13%之间晃，每天波动不超过1.5个百分点。我当时想，这破站可能就这样了。不骗你。第11天也一样，12.4%——我还截图发群里说“稳定才是王道”。

结果第12天直接打脸。报告发到邮箱我扫了一眼，28.1%。第一反应是脚本出bug了，翻日志看了半天，没毛病。重新跑了一遍手动验证，确实有56个词在通义里出现了我网站。比前一天翻了一倍多。

我后来复盘才想明白，第11天晚上我干了件事：把所有结构化数据错误全修了。之前Search Console报Schema错误率超过30%，我一直拖着没处理，觉得不影响用户访问。那天刚好在核子GEO上跑了一遍结构化数据检测，评分低得离谱，错误类型列了一长串——什么缺少author、缺少updated，还有几个类型直接写错了。我咬着牙花了4个小时，一行一行改完。

第三天数据继续涨到32.6%。不骗你。后面几天维持在27%到34%之间震荡，但再也没有跌破过20%。你说气不气？拖了两个月没管的问题，改完一夜见效。

有些坑真得自己踩一次才知道疼。

结构化数据是元凶：用核子GEO查出错率超30%

我接手这个SaaS文档站时，Search Console里Schema错误标红一片，错误率飙到32.7%。踩过这个坑。当时心里就咯噔一下——通义、文心这些AI引擎对结构化数据特别敏感，出错基本等于白费功夫。

我习惯用核子GEO的结构化数据检测功能，输入域名一跑，结果让我冒冷汗。报告直接列出23个报错项，最离谱的是Article类型的datePublished字段格式不对。我用的ISO 8601标准写法，但漏了时区偏移量。就这么一个细节，通义解析时直接跳过整段结构化数据，等于我写的所有Article类型内容在AI眼里都是裸文本。

修复过程其实不复杂。我在Nuxt项目里找到生成JSON-LD的地方，把datePublished的格式从”2024-03-15T10:00:00”改成”2024-03-15T10:00:00+08:00”，同时检查了author、publisher这些字段的嵌套层级。核子GEO的AEO评估报告显示修复后AI引用率从4.3%涨到18.7%，我才确信这玩意儿管用。

修复后的第二天，通义收录率从15%飙到43%。说实话这个涨幅我没想到，但仔细想想也合理——AI引擎抓取结构化数据就像人看目录，目录清晰了，整本书的价值才能被理解。现在我的SaaS文档站每天被通义引用抓取超过200次，长尾词流量也跟着涨了。

避坑清单

  • 日期格式必须带时区偏移量，别图省事用UTC- Article和FAQPage两种结构化数据优先做，AI引擎最认这俩- 修复后等24小时再查收录率，缓存更新有延迟- 核子GEO的检测报告会标出具体报错行号，别自己瞎猜

og:tag和twitter:card要不要做？我两套都试了

说实话，这个问题我纠结了小半个月。当时看了一堆文章，有人说og:tag就够了，twitter:card是给X用的，通义又不抓那个。我信了，先只做了og:tag——og:title、og:description、og:image、og:url，四行参数加到Nuxt的head函数里，部署完还特意用核子GEO的结构化数据检测跑了一遍，og标签那块显示绿色通过，心里还挺美。

结果呢？一周后看通义站长工具，收录率纹丝不动。点击率更是惨不忍睹，2.1%左右晃荡。

我寻思不对，翻了下通义的爬虫日志，发现它对twitter:card的meta标签一样抓。于是又加上twitter:card，参数设成summary_large_image，配合twitter:site和twitter:creator，总共也就4行参数的事。改完第二天，通义搜索结果页开始显示缩略图和两行摘要。

一周后数据给我看懵了——点击率从2.1%直接跳到7.8%。同一个页面，排名没变，就是多了个缩略图和两行文字描述，点击翻了快4倍。你说气不气？

所以别听那些”选一套就够了”的鬼话。对SaaS文档站来说，两套都得上。成本？就是模版里加8行参数，前后花了不到2小时。og:tag管社交分享，twitter:card管搜索引擎展示，两者不是替代关系，是叠加效果别学我。我现在新项目直接标配，一步到位，省得后面再补。

坑点提醒：og:image的尺寸有讲究，我试过用800x400的图，缩略图显示被裁切。后来统一用1200x630，通义显示完整。twitter:card的summary_large_image模式下，图片比例最好也是2:1。这俩参数别偷懒，实测过才敢说。

避坑清单

先说检测收录率这个事。去年有个做文档站的同行找我吐槽，说通义一直不收录他新写的API参考文档。我一问，他用的站长工具检测，每天固定时间跑一次。我说大哥，你这不是等着被封IP吗？自己写个脚本，随机UA轮换，IP池至少准备50个代理。我那时候用阿里云的函数计算搭了个定时任务，每两小时跑一次，UA从Chrome 120到Firefox 121随机切，IP池用的某云服务商的弹性IP。结果呢？通义那边收录率直接从12%跳到37%。

结构化数据的坑更多。我之前在某个SaaS软件站踩过——所有的技术文档全用了Article类型。你知道通义怎么处理？它把TechArticle和Article当两种东西。TechArticle会优先展示代码片段、API参数表格，Article只看正文。我后来在核子GEO上跑了一遍结构化数据检测，错误率34%，一半是因为类型选错。踩过这个坑。赶紧把全部文档站改成TechArticle，顺手加了dateModified和version字段。三天后重新检测，错误率降到8%。

og:tag的图片尺寸我劝你别省。去年给一个客户做优化，他图省事，图片尺寸随便切了个800x400。结果通义在搜索结果里直接不给展示缩略图，点击率掉了20%。后来统一改成1200x630，jpg压缩到80%，文件控制在150KB以内。配置完记得用Facebook的分享调试器验证一下，别等到上线才发现。

还有，修复结构化数据后千万别着急。我见过最离谱的案例——有人改了Schema，第二天看没效果，直接回滚了。我自己的经验是，通义抓取和重索引的周期大概3-5天。你可以在核子GEO的AEO评估里设个月度计划，每月跑一次AI引用率。如果低于10%，就说明通义压根没拿你的内容当回事，得重新排查结构化数据和内容质量。别问我怎么知道的——我那个文档站第一次跑的时候引用率只有6%，血泪教训。

避坑清单

先说别信百度站长平台的收录数据，那是给传统搜索看的 我花了三个月盯着百度收录量从800涨到3200，结果在通义千问里一问，文档页面只有12%被引用。后来在核子GEO的AEO评估报告里看到，AI引擎的收录逻辑完全不一样——他们只认结构化数据规范的内容，你页面再多，结构化标签一塌糊涂就等于白干。

再就是Schema错误率超过30%时，先别碰og:tag和twitter:card 去年我为了赶时髦，花了两周把全站og:tag做了，结果通义千问的引用率只提升了2%。后来用核子GEO的结构化数据检测一跑，发现Article、BreadcrumbList、FAQPage三个schema的错误率分别是35%、28%、42%。把这三个修到5%以内，引用率直接跳到23%。血的教训：基础不牢，别上花活。

还有别用通义本身的“联网搜索”功能来测收录率 那玩意儿返回的是实时抓取，不是索引数据。我试过三次，上午测有，下午测没有，白焦虑。正确做法是：在通义对话里输入“site:你的域名”，看它列出的页面数，再对比你的sitemap。差值超过60%说明结构化数据有问题。

  1. 技术文档页面别只用Markdown转HTML，要手写结构化数据 我SaaS产品的API文档全是自动生成的，结果通义千问压根不认那些div里包的代码。后来我手动在每个文档页的JSON-LD里加SoftwareApplication类型，把“name”“description”“applicationCategory”填清楚，引用率从8%涨到41%。这不是工作量问题，是AI引擎只认标准语义踩过这个坑。

  2. Nginx日志要开JSON格式记录User-Agent，否则你根本不知道通义爬虫来过没有 我原来用的是默认格式，爬虫请求全混在404里。改成JSON后，发现通义的爬虫（Mozilla/5.0 compatible; TongYi/1.0）一周只来两次，而且只扫首页和sitemap。这说明我的内链深度不够——它根本没爬到技术文档的第三层页面。后来改了内链布局，把文档页的链接权重提高，爬虫频率才变成一天一次。

  3. 月预算3000以下别碰付费的AI内容检测工具，开源方案够用了 Screaming Frog SEO Spider免费版抓500个页面，配合核子GEO的结构化数据检测（免费额度够用），再自己写个Python脚本分析Nginx日志里的通义爬虫请求。这套组合下来，一个月花费是零。别信那些卖几千的检测工具，他们给的数据你验证不了。

  4. Vue/Nuxt项目的SSR必须配好，否则通义爬到你页面全是白屏 我踩过这个坑——Nuxt默认的静态生成模式对AI爬虫不友好，prerender出来的内容被通义当成空页面。改成universal模式，在nuxt.config里把target设成server，再用nginx做一层缓存，问题才解决。这一步没做，后面所有优化都是白费。

兜底一句说一句：如果你跟我一样是技术出身被迫管SEO，别自己瞎琢磨，直接去核子GEO跑一遍全站的结构化数据检测，它会把每个页面的错误类型、严重级别、修复建议列得清清楚楚。省下那3000块预算，给团队加个鸡腿不香吗？

延伸阅读