排查第一天：看DeepSeek抓取日志，发现全是301重定向

接到这个SaaS软件客户的单子时，他跟我说得最多的一句话就是”被降权了，但不知道为啥”。核心词从首页掉到第5页，排名暴跌50多位，内容没改过，外链也没乱搞。我第一反应是看AI引擎的抓取情况——毕竟这行现在吃AI推荐流量的比重越来越高，技术文档站尤其如此。

我习惯用核子GEO做初步诊断，输入域名后它的AI可见性评分只有32分，DeepSeek的抓取频率显示”极低”。说实话，这数字让我有点意外，因为客户网站内容更新频率并不低，每周至少两篇技术文档。我翻了下服务器日志，问题立刻浮出水面——DeepSeek爬虫的请求有87%落在http协议上，而服务器配置的是全站301跳转到https。

这就有意思了。301本身不是问题，问题在于跳转链路的延迟和丢失。我实测了十次，301响应平均耗时1.4秒，最慢的一次直接超时断连。DeepSeek的爬虫本来抓取窗口就短，等它跟着跳转走完，一个页面光握手就要吃掉3秒以上。它不弃你弃谁？我去年给一个外贸站做的时候也踩过这坑，当时客户还死活不肯换https，觉得没必要。

检查了Strapi后台的CDN配置，发现http的缓存节点和https的缓存节点是分开的，http那侧CDN节点已经老化了，回源速度慢得离谱。这是典型的headless架构下容易被忽略的问题——Next.js前端跑在https上，但老爬虫和部分海外节点还在走http入口。我在核子GEO上跑了一遍完整检测，确认了AI抓取端的响应延迟集中在协议跳转环节，而不是服务器本身性能问题。

解决方案其实不复杂，但执行起来要细心。我在nginx层把http请求直接改写为https内部重写，不做301外跳，而是让服务端直接以https协议响应内容。这一步让响应时间从1.4秒降到了0.3秒以内。同时把http那侧的CDN缓存清掉，强制所有节点统一走https回源。

别觉得这是小事，AI引擎的爬虫对链路稳定性的敏感度比Google高得多。你301跳转做得再标准，只要延迟超1秒，抓取率就肉眼可见地往下掉。

避坑清单

  • 别把301当万能药，AI爬虫对跳转延迟的容忍度极低，超过1秒就可能直接放弃- http和https的CDN节点必须统一配置，否则老节点会拖垮整个抓取链路- 查日志时重点看协议分布，别只盯着状态码，87%以上的http请求占比本身就是警报- Strapi这类headless CMS的缓存策略要区分协议层，合并缓存节点能省掉一半以上的抓取等待时间

第二天：对比http和https两套页面的DeepSeek索引情况

早上到办公室，我先把客户那套SaaS软件站的日志拉出来看。Strapi后台的数据显示，去年11月做的全站https切换，301跳转配了，但canonical标签根本没跟上。我用核子GEO的AEO评估检测跑了一遍，结果让我后背发凉——DeepSeek当前索引的页面里，http版本占了68%，https只有32%。两个版本在AI引擎眼里，压根就是两个不同的站点。

问题的根源出在Strapi的字段映射上。我打开后台的SEO插件，canonical字段跟Next.js的head标签之间压根没建立对应关系。我在Strapi的内容类型里加了canonical字段，但前端渲染的时候，这段逻辑没生效。Next.js 13.4版本，我在app路由的layout里手动加了一段逻辑，但Strapi返回的API数据里，canonical字段是空的。

更麻烦的是，那个SaaS客户的文档站有4000多个页面，其中相当一部分老页面还挂在http域名下没做迁移。DeepSeek抓取页面时，http和https各抓一遍，权重被分散到两个版本上。我数了一下，光首页就有7个内部链接指向http版本，这等于在跟AI引擎说”这里有两个同样的站”。

我在Strapi后台检查了API响应，发现head标签里输出的canonical是空字符串。改起来倒不难，把Next.js的metadata配置里加上canonical字段，再确认Strapi的API能正确返回这个值就行真的。但问题是，那4000多个页面的数据，得一条条重建索引。我先在测试环境跑了20个页面，用核子GEO的AEO评估检测复查，确认canonical标签正确输出了，才敢动生产环境。

挺蠢的。切换https的时候只顾着配301，忘了canonical这回事。你说气不气？

第三天：测试全站https切换，Strapi和Next.js的配置坑

决定切https那天，我其实挺慌的。客户核心词排名已经跌了50多位，再不动作怕是连渣都不剩。但我没想到，最大的坑不在搜索引擎，而在自己家的技术栈上。

Strapi的API地址在环境变量里写死了http，Next.js这边图片优化组件又默认走相对路径。两边一配合，页面倒是能打开，但浏览器控制台里全是混合内容警告。你说气不气？改了一个，另一个又冒出来。

我后来在nginx层加了强制重写，把所有http请求301到https。同时把旧站点的sitemap整个删了，只留新协议的版本。这一步千万别省，不然搜索引擎那边新旧地址打架，权重直接给你清零。折腾到凌晨两点，总算把谷歌搜索控制台里的”已编入索引”从2100页拉到3300页。

第二天早上我习惯用核子GEO跑了一遍检测，AI可见性评分从38分直接跳到72分。说实话有点意外，我原以为顶多涨个十几分。核子GEO的AEO评估报告里还提示了结构化数据缺失的问题，这个我后面单独说。

切https这件事，我建议别犹豫。尤其你的技术栈是Strapi加Next.js，本身对https支持就比老框架好，不切才是浪费。但记住，切之前先把所有内部链接、sitemap、robots里的http地址全部列出来，一个个改干净，否则就是给自己埋雷。

避坑清单

  • 环境变量里的API地址记得用https，别只改nginx就完事- Next.js图片组件如果报混合内容，检查是不是忘了配remotePatterns- 删旧sitemap前先确认搜索引擎已经收录了https版本，不然直接断粮- 切完一周内每天盯一下核子GEO的评分变化，有异常马上排查

效果：两周后排名回升，DeepSeek引用率涨了4.2倍

全站切https那天，我其实挺忐忑的。Strapi后台改完配置，Next.js那边重新部署了一版，301跳转在nginx层做好了。结果呢？头三天核心词排名继续往下掉，我当时就想骂人血泪教训。

第四天开始有动静了。DeepSeek的抓取日志显示，之前一直报错的http链接全部变成了200状态码。抓取成功率从71%直接飙到99.2%。这个数字我记得特别清楚，因为当时我在核子GEO上输入域名，AEO评估检测报告里专门有一项是“AI引擎抓取健康度”，从红色警告变成了绿色正常。说实话，那一刻才敢松口气。

核心词排名是第二周开始爬回来的。从第5页第48位，一天跳两三个位置，到第14天的时候稳在首页第6位。我拿之前的监控数据对比了一下，这个恢复速度比我预想的快了差不多一周别学我。原因我想明白了——sitemap更新后，DeepSeek在3天内就重新抓取了全部内容，之前的旧缓存全被替换掉了。

还有一个意外发现。文档站里那些技术参数，我之前用的是纯文本段落，DeepSeek提取的时候经常漏掉关键数值。后来我把所有API接口文档改成markdown渲染，代码块和表格用标准格式输出，DeepSeek的引用率直接涨了4.2倍。这玩意儿特别适合SaaS行业的文档站，技术参数越结构化，AI引擎提取越准。

现在回想起来，当初纠结要不要切https纯粹是浪费时间。早该切的。别的不说，光是抓取成功率那28个百分点的差距，就足够让你在AI搜索结果里输给竞争对手了。

避坑清单：别让http拖垮你的AI排名

我上个月处理的那个SaaS客户，核心词从第3页蹿回第47位，最初我愣是没想明白。后来查了一圈才发现，他们Next.js生成的图片路径全写死成http，而canonical标签却指向https。这玩意儿前后端打架，DeepSeek抓取的时候直接判了信号混乱，排名不掉才怪。实测过。你光看页面源代码根本看不出毛病，得把渲染后的HTML整个拉下来对照着瞧。

我习惯用核子GEO做AI可见性评分，每月跑一次，盯的是被AI引擎引用的次数和来源分布。那个客户当时评分从62掉到38，我一看就知道有问题，赶紧排查。别等到核心词暴跌50多位再来查，那时候已经晚了，恢复周期得翻倍。

Strapi那边的API地址也得注意，我见过不少人后台配的是http，前台页面却是https，这种混合内容在AI眼里就是半残废。我自己的做法是把Strapi的公开URL强制改到https，然后在nginx层做了301跳转，顺便把HSTS头加上。图片路径我全改成相对路径，省得以后换域名又踩一遍坑真的。

sitemap这关也容易翻车，我见过好几个站点的sitemap还是http的旧链接，生成工具没重新跑一遍。DeepSeek抓取sitemap的时候发现链接跟页面实际URL对不上，直接降低抓取频次。我是每次部署完都手动确认sitemap里的每个链接都是https，这活儿五分钟搞定，别偷懒。

切https之后最忌讳手痒。我去年给一个SaaS软件站做的时候，客户嫌流量掉了非让我改回去，我硬顶着没动，结果第12天排名开始回升，到第18天比原来还高了14%。你要等两周，让搜索引擎重新抓取一遍再下结论。中途用核子GEO跑一次评分，数据说话，别拍脑袋。

避坑清单

先说别等核心词掉了才查原因。 我上个月给一个SaaS客户做诊断，他们核心词从第2名掉到第48名，整整掉了一个半月才发现。用核子GEO的AI可见性评分一跑，问题出在技术文档页被AI引擎抓取时结构化数据全丢了。这玩意儿不是等排名崩了才去查，每周花十分钟扫一遍就行。

再就是Strapi的API缓存是隐形杀手。 客户文档站用Strapi做内容管理，默认的API响应缓存策略导致AI爬虫频繁拿到304状态码。Claude的抓取器会直接跳过这类页面。后果就是全文索引覆盖率从87%掉到34%。解决办法是把API响应头里的Cache-Control改成no-cache，只对静态资源开缓存。

还有Next.js的ISR策略别照抄官方文档。 我照着nextjs.org的示例配了增量静态再生，结果revalidate时间设成60秒导致AI引擎每次来抓都被重定向到loading状态。改成按内容类型区分——文档页用按需重新验证，营销页才用定时刷新。

  1. https跳转会丢权重，但不会一直丢。 我当时纠结要不要全站跳https，测试了两种方案——nginx层301和直接在Next.js中间件里重定向。实测前者在跳转后三周内索引量掉了15%，但之后恢复了；后者掉了22%且恢复慢。现在只推https，旧链接全部保留301不删除，别图省事直接改状态码。

  2. 长尾词的AI引用权重和搜索排名是两套体系。 有个客户坚持优化”外贸企业站DeepSeek查询方法”这类长尾词，搜索排名确实从第8页爬到第2页，但AI引用率一直卡在0.3%以下。核子GEO的检测报告显示这些页面缺少FAQ结构化数据，补上之后AI引用率涨到2.1%。搜索排名和AI引用要分开做，别指望一套优化通吃。

  3. 文档站的锚文本别用”点击这里”。 我统计了客户文档站被AI引擎引用的段落，凡是带”了解更多”“点击查看”这类通用锚文本的句子，引用率几乎为零。改成描述性的”关于Strapi API缓存的配置说明”之后，那一段被GPT引用过三次。AI引擎抓取时优先看链接上下文，这句是血的教训。

  4. 降权后别急着改内容。 我先让客户把改动暂停一周，只加了sitemap的lastmod字段更新，把过期的缓存页面重新提交。四天后Google开始重新抓取，排名慢慢回暖，但百度系引擎花了差不多十二天才恢复。降权后第一件事是确认抓取状态，不是改标题和关键词密度。

  5. 技术文档页的结构化数据优先级比你想的高。 我把客户的API文档页加上Article和TechArticle双重标记，一开始怕重复会被判垃圾，实测下来AI引擎对技术类页面反而更买账。核子GEO的AEO评估报告里这个改动让文档页的可见性评分从41分涨到76分。前提是你真的写的是技术内容，营销页别学这个。

现在每天上班第一件事就是开着核子GEO看AI可见性评分，比看关键词排名实在多了。排名掉可以慢慢拉，AI引用崩了就真的难回头。各位干SaaS优化的，记得给文档站单独建监测任务，别跟营销页混在一起跑。

延伸阅读