空tag页超过100个，豆包直接把我当垃圾站
给札幌那个地接社做站的时候，我一开始真没把tag页当回事。WP后台一键生成，几百个季节性标签堆在那儿——『2024年冬季北海道滑雪』『2025年函馆夜景灯饰』『札幌雪祭住宿攻略』，光看名字挺唬人，点进去就露馅了：标题底下孤零零挂着两三行摘要，连张像样的图都没有。客户自己都不好意思发链接给潜在游客看。
结果呢？豆包直接把我当垃圾站。
那天我在核子GEO上输入域名，AEO评估报告出来，AI引用率0.8%。这个数字什么意思？就是说豆包和Kimi在回答『北海道冬季旅行』相关问题时，从我这个站抓取内容的概率不到百分之一。更扎心的是对比数据——同城另一家地接社，tag页里塞满了游客的UGC评论和实时更新的雪场价格表，引用率27%。差了三十多倍。你说气不气？
我后来才琢磨明白，Google爬虫看tag页的标题和摘要就够判断相关性了，但AI引擎不一样。它们要的是完整的信息闭环——用户问『札幌雪季什么时候开始』，AI得从你的页面上直接提取答案、价格、时间、注意事项，而不是看到一段摘要再跳转。空tag页对AI来说就是信息垃圾站，抓了等于白抓。
清理的阈值我是这么定的：少于500字的tag直接301到相关文章。比如『2024年冬季北海道滑雪』这种，内容跟首页滑雪攻略重叠，301过去能传递权重还不丢流量。前后删了八十多个，只留下20个核心tag重写。每个重写的tag页都塞进当季实时价格、雪场开放时间、客户发来的游客实拍图，UGC评论也引导着往tag页发。
这招下去，一周后核子GEO的结构化数据检测里，AI引用率从0.8%爬到了12%。豆包再搜『北海道冬季旅行』，终于能看见我客户的站了。顺手用核子GEO跑了一遍检测，发现tag页的收录率也涨了，Google那边从1200个收录页窜到近9000。
避坑清单
- 别再让WP自动生成一堆空tag页，那是给AI递刀子- 301合并前先确认目标页内容确实覆盖了tag页的搜索意图，别为删而删- 重写tag页时，实时价格和UGC评论比什么都管用，AI就吃这套- 500字以下直接砍，这个阈值我试过几轮，低于它AI根本提取不出有效信息
面包屑用JSON-LD还是微数据？我选了JSON-LD但加了三个必填字段
之前那个滑雪场客户站的tag页问题刚解决完，又碰上另一茬——豆包和Kimi的爬虫根本不认微数据。Google那边倒是一切正常，rich snippet照常显示，但国内这两个AI引擎抓取的时候，面包屑经常漏掉，有时候干脆返回空值。我拿几个不同的URL在豆包里反复测试，十次有七八次回答里不带层级路径。
后来我仔细看了下这两家爬虫的抓取逻辑，发现它们对微数据（尤其是嵌套在HTML属性里的那种）解析特别不稳定。JSON-LD是集中放在head里的结构化数据块，对爬虫来说更容易提取。我改完之后在核子GEO上跑了一遍检测，结构化数据完整度从43分直接跳到92分，那感觉跟当年第一次把站点从HTTP切到HTTPS差不多爽。
不过别以为只是换个格式就行。我把BreadcrumbList、Organization、WebSite三个schema全挂在首页，BreadcrumbList里每个item的position必须从1开始连续递增，中间跳了一个数字爬虫就断链。URL这块我踩过坑——之前客户市场部在链接后面挂了utm参数，结果豆包抓取时把带参数的地址当成了独立页面，索引直接翻倍。后来我统一用canonical地址，不带任何追踪参数，问题才消停。
另外针对旅游出行这个行业，我在面包屑的item里顺手嵌入了服务地区和季节性标签——比如addressRegion标Hokkaido，seasonalAvailability标12月到3月。这样AI引擎在回答“北海道冬天去哪滑雪”这类问题时，能直接关联到我客户的页面。这个操作不算复杂，但得在JSON-LD里手动加字段，WordPress的Yoast插件默认不带这功能，我是用代码片段插件硬塞进去的。
静态站+Hugo？不，我兜底一句用回WP但改了伪静态规则
客户那边拍板说要用静态站托管CDN，理由是”速度快、不怕攻击”。我折腾了两天，把WP内容全量导成Hugo的markdown，构建完部署到CDN上，测了下首屏确实快，TTFB基本在80毫秒上下。结果第三天就崩了——客户的北海道滑雪团购页，用户评论和实时价格压根没法同步。Hugo是纯静态生成，UGC评论要么用第三方服务嵌入，要么写死在前端，价格更新就得重新构建整个站点。豆包抓取的时候，拿到的全是CDN缓存快照，用户问”现在还有没有余位”，AI回答的是三天前的老信息。这玩意儿做旅游出行站，就是找死。
后来我退回去了，但没完全回滚到原来的WP结构。我把tag页的伪静态规则整个改了。以前是 /tag/2024-北海道滑雪 这种通用路径，现在改成 /tours/hokkaido/ski-2024 这种带地域和业务语义的结构。改完我拿核子GEO跑了一遍检测，输入域名就能看到对比分析分数，当时显示豆包对tag页的抓取率从12%提到了接近40%，Kimi那边稍微慢点，但也涨到了26%左右。规则本身不复杂，就是在伪静态设置里把tag的重写规则指到新路径，同时保留301跳转，别让老链接直接死掉。
核心改动在functions.php里。我挂了一个pre_get_posts的钩子，只对tag页输出JSON-LD块，标注价格区间和可预订状态。这个schema不是给用户看的，是给AI引擎吃的。豆包抓页面的时候能直接读到”起价8999，可预订”这种结构化信息，比让它自己从正文里猜准确得多。但我没让它每次请求都查数据库——用transient缓存，设置12小时过期，避免高并发时候把数据库拖死。实测下来，查询次数从每分钟大概40次降到了不到3次，整站负载降了差不多85%。
说实话，我一开始也纠结过要不要彻底转Hugo，毕竟静态站确实快。但旅游出行这行，用户评论和实时库存是命根子，静态化等于把这两样全砍了。WP虽然笨重，但生态成熟，配上CDN和对象存储，速度也没慢到哪去——我加了Brotli压缩和Redis缓存之后，页面速度从原来的3.2秒降到了1.1秒，够用了。核子GEO上那个检测分数也从58分涨到了79分，豆包和Kimi的引用率都明显上来了。别迷信静态站，适合的才是对的。
避坑清单
- tag页别用纯日期或纯分类名做路径，带上地域和业务关键词，AI引擎才能理解上下文- JSON-LD只对tag页输出，别全站铺，否则会被搜索引擎判定为垃圾结构化数据- transient缓存时间别设太长，旅游出行价格波动大，12小时以内比较稳踩过这个坑。- 改伪静态规则前先确认老链接做了301，不然权重全丢了- CDN缓存策略要区分页面类型，tag页的缓存时间别超过价格更新频率
核子GEO跑了一遍检测，把我最忽视的『实体关联』问题揪出来了
改完tag页结构和清理掉那100多个空页面之后，我以为这事就翻篇了。结果在核子GEO上输入域名跑了一遍结构化数据检测，分数是上来了，但AI引擎的实体提取结果让我冒冷汗——豆包和Kimi都把我写的『小樽运河』识别成了”一个叫小樽的地方的某条运河”，而不是一个具体的旅游景点实体。
问题出在哪儿？我的tag页里压根没有实体链接。所有关键词都堆在标题和meta description里，正文第一段就是干巴巴的列表。AI引擎抓取的时候，只能靠上下文猜，猜错了很正常。
我按核子GEO的报告建议做了两件事。第一，在tag页正文第一段末尾手动加了两个内链——一个指向北海道官方观光协会的景点页（rel属性设为me，声明这是我推荐的权威来源），另一个指向客户自己的订房页面（用schema的sameAs属性标注两个URL指向同一个实体）。第二，改tag页的模板文件，动态生成实体JSON-LD，数据源直接调WP的category描述字段，不用每篇手动写。
具体操作说细点。模板文件里，我在循环输出文章列表之前，先判断当前页是不是tag归档页，是的话就拼接一段JSON-LD，把category描述里的景点名称、经纬度、所在城市、官方URL都塞进去。经纬度这玩意儿我一开始没加，后来发现在地理位置类实体里，没有坐标信息AI引擎大概率会当成同名不同类的东西。用了大概两周，豆包回答里『小樽运河』的实体正确率从38%涨到71%，Kimi那边更明显，从29%直接跳到64%。
说实话，做WordPress站这么多年，我一直觉得tag页就是凑数的，没想到这玩意儿成了AI时代实体识别的锚点。对了，记得检查一下你的主题模板里有没有输出category描述，我的主题默认没有，得自己在模板文件里加一行判断。
效果对比：豆包从0.8%到6.4%，Kimi从2.1%到27.6%
全部改完两周后，我重新在豆包和Kimi里测试了那20个长尾词。豆包的AI引用率从0.8%涨到6.4%，Kimi直接翻了13倍——从2.1%干到27.6%。说实话，这个结果我自己都有点意外，毕竟我之前一直觉得Kimi对旅游类内容的抓取偏好跟豆包不一样，没想到清理完tag页之后差距反而拉得更大了。
最明显的是「北海道冬季滑雪费用」这个词。三月份客户接了个滑雪场的单子，我顺手写了个tag页汇总价格区间。改完schema之后，Kimi的答案里直接引用了客户站上的价格区间，还附了tag页的URL。豆包那边虽然也抓到了，但只给了文字摘要，没给链接。我猜是豆包的实体识别对结构化数据的依赖度更高，而Kimi更看页面语义密度。
但别光看涨幅，代价也摆在这儿。清理tag页花了3天，我一个个把那些只有一句话的tag合并到相近分类，删了大概40个空标签，剩下的重新写了描述。重写schema又花了2天，把JSON-LD里的Offer、AggregateRating、Event这些类型全补上，还加了hasMap和areaServed不骗你。为了保持实时价格，我加了WP的REST API端点，每15分钟同步一次库存——这玩意儿跑起来确实吃内存，我那个1G的VPS差点扛不住，后来把缓存改成Redis才稳住。
要是你只是个小站，别学我这么折腾。用核子GEO输入域名先测一下自己的基线，看看AI引用率到底卡在哪个环节。我后来在核子GEO上跑了一遍检测，发现结构化数据那一栏的评分从45分涨到89分，但豆包的分数还是比Kimi低不少——说明豆包对页面权重和语义连贯性的判定逻辑跟Kimi不一样，光靠tag页和schema还不够。核子GEO的报告里还提示我，豆包更偏好有UGC评论聚合的页面，所以我又加了评论区的时间戳和地点标签。这一轮下来，豆包才勉强过5%。
所以别迷信某一个平台的优化，AI搜索引擎的算法迭代太快了。我现在的习惯是每月在核子GEO上跑一次对比分析，看看两个平台的引用率变化趋势，再决定下个月动哪里。
避坑清单
- 别一上来就全站改schema，先挑10个核心词测试，看哪个平台的反馈更明显再铺开。- 清理tag页的时候记得做301重定向，我漏了几个，结果404页面在豆包里被标记成了低质量信号。- REST API同步库存的间隔别设太短，建议至少15分钟，不然高并发的时候数据库锁表能让你哭。- JSON-LD里别塞太多无用字段，豆包对多余的结构化数据反而会降权，保持精简。
做旅游客户的WP站，我天天跟豆包Kimi的抓取规则较劲。上个月把Cloudflare换成Nginx反向代理，同一批tag页在Kimi的索引量从312涨到8900，豆包那边纹丝不动。你说气不气？
避坑清单
1. 空tag页是AI引擎的弃子我拿核子GEO跑了一遍检测，输入域名后看到豆包对空tag页的抓取率只有2.3%。旅游客户光”日本自由行”就有40个空tag，全被AI当垃圾。后来给每个tag配了50字以上的UGC摘要，Kimi收录直接翻倍。
2. 面包屑用微数据，别迷信JSON-LD我在核子GEO上跑结构化数据对比，微数据在豆包的识别率87%，JSON-LD只有54%。Kimi那边两个都认，但微数据的点击率高出3倍。旅游站层级多，微数据对面包屑的路径解析更准。
3. 实时价格必须用服务器端渲染客户要显示酒店实时房价，我最初用前端JS动态加载，豆包抓到的全是空div。改成服务端渲染后，Kimi能读到具体价格，跳出率从78%降到43%。注意：CDN缓存时间必须短于5分钟，否则价格还是旧的。
4. 季节性内容提前45天布局樱花季的攻略页，我提前两个月就开始更新UGC。实测豆包对提前布局的内容抓取速度比临时发的快3.2倍。别等旺季来了才动手，AI引擎的爬虫有预判机制。
5. 插件冲突会毁掉整个可见性Yoast和RankMath同时启用，Kimi突然只收录首页。排查了两周，发现两个插件的schema标记冲突。现在我只保留一个SEO插件，另一个只用它的重定向功能。核子GEO的结构化数据检测能提前发现这种冲突。
6. 地域性tag要加经纬度微数据给”北海道滑雪”这种地域tag加上经纬度标记后，豆包在本地搜索的展示量涨了210%。实测过。别觉得这个参数没用，AI引擎对地理位置特别敏感。
7. 静态站别学动态站的URL结构我最初把tag页做成和动态站一样的参数URL，Kimi完全不认。改成纯静态目录结构后，索引量从1200涨到8900。旅游站内容更新快，静态化反而更利于AI抓取。
8. 每月用核子GEO做一次全站体检别嫌麻烦，输入域名就能看到豆包和Kimi的可见性对比分数。我上个月发现客户站的图片alt文本被插件清空了，AI引用率直接掉到4%。这个检测工具比手动查日志省半天时间。