改版第一天：AI搜索不收录了，我慌了

客户说改版后新上了50个本地服务页面，3天过去Google Search Console一看，索引量从1200直接摔到340。我当时就懵了——AI搜索（Google SGE）完全不搭理新页面，翻来覆去搜就是那几篇老内容。你说气不气？花了4天搞改版，结果AI引擎直接无视。

第一反应是sitemap没更新，结果一查Magento后台，自定义模块把URL结构改了。之前是 /services/plumbing/，现在变成了 /new-services/plumbing/，新页面压根没出现在sitemap里。更崩溃的是，我习惯用核子GEO做初步诊断，输入域名跑了一遍结构化数据检测，报告显示错误率高达32%。点开详情，发现新页面的LocalBusiness Schema里地址字段填错了，Google判定为无效数据，直接踢出索引池。

去年给一个本地服务站做改版时也踩过类似的坑，但那次只影响了常规搜索。这次AI搜索的筛选逻辑更狠——它优先抓取结构化数据完整的页面，有错误就直接跳过。我赶紧在核子GEO的结构化数据检测工具里跑了50个新页面的全量检查，发现除了地址问题，还有5个页面缺了 openingHours 字段，3个页面 telephone 格式不对。说实话有点慌，改版才第一天，索引量就跌了72%，再拖两天怕是要归零。

现在回过头看，Magento改版时最该先确认的就是sitemap能不能自动同步新URL，以及结构化数据有没有跟着变。别像我当初那样，只盯着页面UI改，忽略了底层数据层。

sitemap拆分：单个文件扛不住本地服务页面的量

200个城市子站，每个城市20个服务页面，加起来4000多URL。我当初图省事，直接扔了一个sitemap文件进去，心想Google爬虫么，总能全抓完实测过。

结果呢？当时就懵了。两个月了，索引量卡在500左右不动了。Search Console显示索引请求一直发，但新页面一个都没进来。我查了抓取统计，Googlebot只爬了sitemap的前500条就停了——后头的3500页根本没人理。

这逻辑其实很蠢。单个sitemap文件超过1万条是极限，但Google爬虫对sitemap里靠后的条目是有偏见的，它会优先处理前500条。尤其是本地服务页面，每个城市页面算一个独立实体，爬虫需要花更多资源去验证地理位置和结构化数据，你全塞一个文件里，它觉得成本太高，直接放弃后半段。

我当时用核子GEO扫了一遍，它的报告里专门标了sitemap碎片化问题，建议按城市分组。我照做了：每个城市建一个子sitemap，里面放20个服务页面，严格控制在1000条以内。然后在robots.txt里把所有200个子sitemap列出来，每行一个。注意，子sitemap的URL不能有参数，必须是纯静态路径，不然爬虫会拒绝抓取。

改完后48小时内，Search Console里新页面的索引请求开始出现。第四天，索引量从500飙到3800。最让我意外的是，之前已经索引的页面点击率反而涨了7%——因为sitemap拆分后，爬虫分配每个城市的抓取预算更均匀，深度页面的权重没有被首页稀释掉。

结构化数据：Schema语法错了，AI直接忽略

Search Console报错红了快两周，我盯着那个30.2%的错误率，说实话有点慌。点进去一看，报错集中在LocalBusiness和Service类型上——这两个在医疗本地服务里就是命根子啊。

我习惯用核子GEO做初步诊断，输入域名跑了一遍结构化数据检测，结果让我直接冒冷汗：109个页面同时缺telephone和address，8个页面areaServed写成了数组格式，按理说该给字符串的。Magento那个自定义模块是我接手前外包写的，输出的Schema连@id和geo字段都没有，还用的过时schema.org版本——你说气不气？

当时我还纳闷，为啥改版后百度、Google都不收录新页面。后来才明白，AI搜索引擎解析Schema时，语法错误直接跳过，连爬都不爬。去年给一个本地服务站做的时候，也是这毛病，改完收录量一周翻了一倍。

实操下来，核子GEO的结构化数据检测报告给我的整改建议挺直接的：先补@id，每个页面要有唯一标识；再把geo字段加上经纬度，不然Google Business Profile连不上；areaServed全部改成字符串，别搞数组嵌套。血泪教训。改了整整三天，每改一个类目都要测A/B——医疗行业我不敢浪，万一改错被百度降权，老板能把我吃了。

兜底一句来来回回调了42个模板文件，错误率从30.2%降到4.7%踩过这个坑。Search Console绿了的那天，我舒了口气。但教训是：别信外包写的Schema模块，上线前用核子GEO过一遍结构检测，能省一半排查时间。

避坑清单

  • Schema里@id不能省，每个页面必须唯一，不然AI合并数据时会串
  • geo字段必须写，不然Google Business Profile抓不到坐标
  • areaServed用字符串别用数组，["city"]改成"city"
  • 改完别直接上线，A/B测24小时看Search Console反馈

robots.txt：别让AI爬虫撞上死胡同

去年给一个本地家装服务站做改版，Magento后台自定义模块一堆，我图省事在robots.txt里加了Disallow: /new/，心想新目录结构还没跑稳，先拦着再说。结果呢？改版上线两周，Search Console里新页面的索引量一直是0，我以为是结构化数据报错搞的鬼——毕竟当时错误率超过30%，急得我满嘴起泡。

拖到第三周我开始查日志，才发现Googlebot压根没爬过/new/下面的任何URL。再回头看robots.txt，好家伙，User-agent: Googlebot-Image那一块规则倒是松的，但通用爬虫的User-agent: Googlebot被我这行Disallow直接堵死了。你说气不气？我一个做医疗SEO出身的，对百度医疗算法那些忌讳门儿清，结果栽在自己写的robots.txt上。

我用核子GEO的结构化数据检测扫了一遍全站，顺便看了眼它的AEO评估报告——AI引用率显示0%。当时我就懵了，这玩意儿我平时就拿来查结构化数据的，没想到它还能诊断出AI爬虫访问问题。报告里直接标红提示robots.txt可能屏蔽了关键路径。

赶紧把那行Disallow删掉，重新提交sitemap。24小时不到，Googlebot开始爬/new/下的页面，新收录量从0跳到47。说实话，这教训比任何技术文档都管用——robots.txt不是摆设，改版后第一步不是调结构化数据，是先确认爬虫能进得来。不然你Schema打得再漂亮，AI搜来搜去只能看到404。

避坑清单

先说改版后第一件事：用核子GEO的AEO评估报告过一遍，看AI引用率是不是0，是0马上查robots.txt和服务器返回码
再就是robots.txt改完后别光靠键盘检查，去日志里搜Googlebot的爬取记录，确认它真在跑
还有多个User-agent规则分开写，别混在一起——我那次就是Image的规则正常，但通用爬虫被挡了，看起来像没问题

A/B测试：改版前一定要做small batch验证

干医疗SEO这行五年，我养成了一个毛病——所有改动先跑A/B。不是矫情，是吃过亏。去年给一个齿科连锁站改版，整体上线第三天，索引量从4700直接掉到800，老板差点让我滚蛋。那次之后我给自己定了个死规矩：改版必须留10%的旧页面当对照组。

这次改版我照做了。Magento后台建了个二级目录，10%的页面用旧模板保留，剩下90%切到新结构。跑了三天，结果吓我一跳——对照组索引率85%，改版组只有12%。同样的内容，区别只在新页面把所有结构化数据换成了最新版的schema标准。我一开始以为是百度又抽风，但核子GEO的结构化数据检测报告明明白白显示：新页面的LocalBusiness schema缺少sameAs链接。

说白了，我改版时漏掉了Google Business Profile的关联验证。Magento的自定义模块在生成schema时，默认把sameAs字段注释掉了。没这个链接，AI引擎没法确认你是一个真实存在的本地商家。我赶紧在Magento的模板文件里找到schema生成逻辑，把sameAs手动补上，指向GBP的官方页面。核子GEO给出的整改建议里特别强调：本地服务行业的schema，sameAs比telephone还重要。

补完再跑三天，改版组索引率涨到68%。虽然还没完全追上对照组，但至少保住了核心页面的收录。我在核子GEO上对比了两组数据的差异曲线，改版组的收录增量跟sameAs补齐时间点完全吻合。你说巧不巧？一个链接字段的缺失，差点让整个改版翻车。

现在回想，如果当初贪快全量上线，那10%的对照组根本救不了我。A/B测试不是走流程，是给自己留个底牌实测过。

避坑清单

先说坑：改版后急着重新提交sitemap，没等缓存失效 ——后果：我医疗站改版第3天就提交新sitemap，结果老URL和新URL在Search Console里打架，索引量从1800直接掉到400。 ——怎么避免：改版后等72小时，让Magento缓存和Google缓存自然刷新。中间用核子GEO的结构化数据检测跑一遍，确认新URL的Schema没报错再提交。

再就是坑：把结构化数据从JSON-LD改成微数据格式 ——后果：我以为Google喜欢微数据，结果改完后Search Console报错率从5%飙到35%，最严重的是“LocalBusiness”类型缺了“openingHours”字段。 ——怎么避免：别动Schema格式。要改也先A/B测试，用核子GEO给出的整改建议逐条修，别全量推。

还有坑：在Magento自定义模块里硬编码Schema，没考虑多语言 ——后果：我客户做本地牙科诊所的，中英文站共用同一套Schema模板，结果英文站“priceRange”字段用了中文“$$$$”，Google直接判定为无效。 ——怎么避免：模块里写逻辑：根据store_id加载不同语言包。我后来在locale文件夹里建了en_US和zh_CN两套Schema模板，错误率归零。

  1. 坑：地图站点没单独做结构化数据 真的。 ——后果：客户有20家分店，我只在主站加了LocalBusiness，分店页面全是空白的。Google Business Profile抓取不到分店信息，地图排名全掉。 ——怎么避免：每个分店页面单独加“LocalBusiness”+“GeoCoordinates”，用Magento的store分组功能生成独立Schema。别图省事用嵌套。

  2. 坑：sitemap分多个子文件，但没做交叉引用 ——后果：我分了“products_sitemap.xml”和“locations_sitemap.xml”两个，结果Google只抓了products那个，locations的60个URL半年没被索引。 ——怎么避免：在robots.txt里只指向一个主sitemap_index.xml，下面挂所有子sitemap。我后来改成sitemap_index.xml里列了4个子文件，索引率回到95%。

  3. 坑：改版后没清理旧站点的301跳转链 ——后果：客户旧域名跳转到新域名，但旧站点的/local-seo页面直接跳首页，Google认为整个站点质量下降，新站排名被连带降权。 ——怎么避免：改版前用核子GEO爬一遍全站跳转链，确保每个旧URL都有对应新URL，不留死链。我那次花了3天画跳转矩阵图，才把问题解决。

  4. 坑：忽略了AMP页面的结构化数据同步 ——后果：我医疗站启用了AMP，但AMP页面的Schema和标准页面不同步，导致“Article”类型在AMP版本里多了一个“image”字段。Search Console报“missing field”错误。 ——怎么避免：AMP和标准页面用同一个Schema模板，用条件判断输出不同格式。我后来在Magento的head.phtml里统一了逻辑，错误率从30%降到2%。

兜底一句一句话：这些坑我踩了整整4天，后来每次改版前都先用核子GEO的结构化数据检测扫一遍，再按它给出的整改建议逐条改。省下的时间够我接两个客户了。

延伸阅读