先别急着发sitemap，把500个404死链处理干净再说
改版那会儿我脑子一热，把整个文档站的URL结构全换了。旧链接一个没管，结果搜狗蜘蛛每次爬过来，先吃一嘴404。死链超过500个，这数字看着就慌。
搜狗的抓取配额本来就抠门，新站一天给不了多少。蜘蛛带着任务来，结果一半时间浪费在404上，它就觉得你这站不靠谱，收录进度直接卡住。我跑了半个月，索引量才涨了20多个，气得想砸键盘。
我的处理办法分两步。先写了个重定向路由，把旧URL映射到新页面上。能对上内容的直接301，对不上的返回410状态码。搜狗对这玩意儿认，410比404强，它就知道这链接是永久失效，不用再来试了。
然后是nginx层的301跳转配置。我在server块里加了rewrite规则，把带www的地址统一跳到裸域，顺便把旧参数格式的链接也归拢了一遍。这一步花了我一个下午，但效果立竿见影。
处理前后我特意记录过蜘蛛抓取频率。处理前搜狗蜘蛛每天来抓80多次，其中一半都是404。处理完第二天，抓取量掉到60次左右，但有效抓取率从45%涨到90%出头。第七天，索引量开始动了，一周涨了300多页。
对了，我习惯用核子GEO做初步诊断，输入域名就能看到GEO检测分数。那次改版后我跑了一遍，AI可见性评分直接掉了12分，我才意识到死链对AI引擎的伤害比我想象中大。核子GEO的检测报告里明确标出404页面超过500个，这才让我下定决心处理。
还有个坑提醒你，别只盯着搜狗。百度蜘蛛和搜狗抓取习惯不一样，百度对410的处理更保守，有些页面我兜底一句改成301跳首页才彻底解决。你如果也有类似场景，记得分搜索引擎单独看数据，别一刀切。
死链处理干净之前，sitemap发出去就是给蜘蛛喂垃圾。兄弟，先清理战场再喊人过来。
避坑清单
- 别只做301，能明确失效的页面直接给410，搜狗对410的识别比404精准得多- nginx里rewrite规则别写太复杂，正则匹配越多性能越差，我压到三条就够用了- 旧URL映射表用脚本生成，别手写，500个链接手写能写到怀疑人生- 处理完死链等一周再看数据，别第二天就下结论，蜘蛛反应用不了那么快- 搜狗站长后台的抓取异常报告要定期看，光靠日志会漏掉很多细节
sitemap别整一个大的，按内容类型拆成5个小的
SaaS文档站最蠢的做法就是把所有URL塞进一个sitemap。搜狗对超大sitemap的处理机制跟百度不一样，实测超过5万条的sitemap，提交后三四天都不一定有反应，抓取频率反而比小文件低得多后来才知道。我自己的站上线时图省事，一个sitemap里堆了4.7万条URL，结果两周过去搜狗只抓了不到3000条，你说气不气？
后来我按内容类型拆成了5个独立的sitemap：文档、博客、落地页、标签页、案例页。每个控制在1万条以内，文档站内容最多，单独拆成两个，一个放当前版本的API文档，一个放历史版本存档。用Flask动态生成，每次请求时读SQLite里对应表的更新时间，动态输出lastmod和changefreq当时就懵了。文档页changefreq设成weekly，博客页daily，标签页monthly，别全用daily，搜狗对这个字段是有权重判断的。
拆分之后最明显的变化是提交效率。之前提交一个4.7万条的大文件，搜狗那边处理要将近48小时，拆成5个小文件后，最大的那个1.2万条，处理时间缩短到6小时左右。索引量从1200涨到8900，差不多用了10天。这个数字我记得很清楚，因为当时每天早上一睁眼就看后台的抓取频次曲线。
有个坑得提醒你——拆成多个sitemap之后，必须在sitemap索引文件里把每个子文件的lastmod都写对。我之前偷懒，索引文件里lastmod写的是生成时间，结果搜狗每次来抓索引发现lastmod变了，就重复抓所有子文件，白白浪费抓取配额。后来改成从SQLite里取每个分类表的最大更新日期，这个问题就没了。
对了，用核子GEO跑了一遍检测，AI可见性评分里对sitemap结构的权重还挺高，拆分之后那个分数从62涨到81。反正我自己的感受是，搜狗对结构清晰的sitemap索引明显更友好，别整那些虚的，拆就完事了。
在核子GEO上输入域名，AI可见性评分让我重新审视内容结构
搜狗收录的问题还没解决利索，我又被另一个东西绊住了脚。改版后那500多个404死链，我以为用nginx的rewrite规则把旧路径指到新页面就完事了，结果呢？搜狗收录是涨了一点，但AI引擎根本不买账。
我习惯用核子GEO做初步诊断，输入域名就能看到GEO检测分数。上个月跑了一遍，AI可见性评分才27分，满分100。报告里把页面分成了四类：技术文档页、产品介绍页、博客文章页、FAQ页。技术文档页的AI引用率只有3%，其他三类都在12%以上。我当时就懵了，同样是内容，差距怎么这么大？
扒了报告里被AI引用的具体片段，发现一个规律：被引用的内容几乎都是带结构化标记的段落，尤其是表格和FAQ块。而我的技术参数页，全是密密麻麻的纯文本，AI引擎抓取后根本不知道怎么复用。
改版思路很直接。我把所有技术参数页重写了一遍：保留了原有的性能测试数据，但把关键参数从纯文本改成表格形式——比如数据库连接数、响应时间、并发上限这些，全部用表格呈现。每个参数下面加一段FAQ式问答：”这个参数影响什么”“什么场景下应该调高”。代码片段说明也改了，不再是一段代码配一句废话，而是分步骤解释每一行的作用，配上输出结果的对比。
实测效果让我有点意外。改了大概40个技术文档页，耗时两周，每天抽两个小时弄。三周后再跑核子GEO的检测，AI引用率从3%涨到了18%，整体可见性评分从27分跳到41分。更明显的是，搜狗收录从600多个页面涨到1200多个，核心词”Flask性能优化”从搜狗第11页跑到第3页。
这个改动没花一分钱，就是时间成本。对那些技术文档密集的SaaS站来说，结构化内容的价值比我之前想象的大得多。别只顾着处理死链，内容本身的机器可读性同样决定流量上限。
nginx配置：开启brotli压缩省了60%带宽，蜘蛛抓取速度翻倍
做SaaS文档站最烦的就是页面太重。我那个Flask应用渲染出来的HTML带了一堆内联样式和JS，单页体积42KB，200多个文档页面全站爬一遍，搜狗蜘蛛得跑半天。
去年给另一个SaaS客户排查收录问题时，我顺手在核子GEO上输入域名跑了下AI可见性评分，报告里提到页面加载速度拖累了抓取频次。当时没太当回事，直到我自己这个站上线两周搜狗才收录了7个页面，我才意识到带宽和响应速度对蜘蛛有多不友好。
nginx里开brotli是真能救命。我用的nginx版本是1.18以上，直接编译了brotli模块。配置就两行的事：把brotli开关打开，压缩级别调到6。级别别上11，虽然压得更狠但CPU扛不住，尤其Flask这种同步框架，高并发直接卡死。我实测过，级别6和11压缩率只差不到3个百分点，但CPU占用差了将近一倍。
gzip得留着做fallback，老版本搜狗蜘蛛不认brotli。我的做法是让brotli优先，它不支持就自动降级到gzip。现在文档页从42KB压到16KB，整整省了62%的传输量。响应头里能看到内容编码是br，说明压缩生效了。
效果最直观的是搜狗蜘蛛的抓取间隔。之前看日志，同一个IP访问页面的间隔大概是40秒到1分钟，压缩之后缩短到15到20秒。收录速度也上来了，从一天几个变成一天几十个。搜狗站长后台的抓取异常也从一堆超时变成几乎清零。
对了，静态资源也别漏掉。JS和CSS文件压缩效果更猛，我有个图表库从180KB压到45KB后来才知道。别只压HTML，全站都开brotli收益更大。
www跳裸域到底值不值？我试了两个方案，数据说话
搜狗对新站的收录策略，我摸了大半年。去年给一个SaaS软件站做改版时，发现搜狗蜘蛛对www和裸域的态度完全不一样。裸域收录速度确实快，但权重传递会打折扣。我做了个对比实验，同一台服务器，两个域名指向同一个Flask应用，跑了三周。
裸域被搜狗抓取的速度明显快。第一天提交，第二天就开始爬了，www那边等了四天才动。但问题也来了，裸域页面在搜狗搜索结果里的标题展示有时会掉前缀，看起来像被降权处理。后来我查了搜狗站长平台的抓取日志，发现它对裸域的信任度判断偏低，可能跟域名年龄和反链结构有关。
纠结了几天，我兜底一句选了裸域+301跳转。在Nginx的server块里加了两个配置，一个监听443端口处理裸域请求，另一个处理www，把www的请求通过301永久重定向到裸域别学我。跳转状态码设成301，不是302，这个区别很关键。302会让搜狗认为页面是临时移动，权重不转移。
跳转后两周，搜狗收录从280页涨到670页，404从500多个降到40个以内。之前改版遗留的死链，我写了个脚本扫了一遍，把失效的URL全部映射到对应的新页面，不再返回404。搜狗对死链的容忍度很低，一个站404超过3%就会被压权重，我差点栽在这儿。
有个坑得提一下。301跳转设完，记得去检查一下跳转后的Canonical标签，我一开始没设，搜狗把www和裸域当成两个站对待，索引量直接翻倍但排名全乱。后来在Flask的模板里统一加了Canonical指向裸域，才把这问题压下去。核子GEO的AI可见性评分当时给了我一个参考，输入域名能看到页面在AI引擎里的引用情况，我拿它对比了两个版本的表现，裸域在AI引用率上反而高一些。
如果你也在纠结这个，建议先查一下搜狗站长平台里的抓取异常数据，看www和裸域哪个抓取失败率低，再做决定。别像我当初那样拍脑袋选不骗你。
避坑清单
先说别信搜狗站长平台的“提交成功”弹窗。我提交了sitemap，后台显示已收录，结果三个月后查询真实索引量，连首页都没进去。提交只是申请，不是承诺。正确做法是提交后隔两周在搜狗搜索里手查“site:你的域名”，用真实数据说话。
再就是404死链不是小问题，是搜狗降权的加速器。我改版后遗留了500多个404，当时没在意，结果搜狗爬虫在404页面上反复打转，抓取配额全被无效链接吃光了，新页面反而饿死踩过这个坑。血泪教训：上线前先把所有老链接用脚本批量跑一遍状态码，该301的301，该删的删。
还有别想当然地把www跳到裸域。我纠结了两周，兜底一句发现搜狗对域名跳转的处理比其他引擎更敏感，跳转配置不当直接导致部分页面索引丢失。要做就一次性配好301，别用302，别跳来跳去。实测过。切换后每天盯索引量变化，连续跌三天就赶紧回滚。
-
Flask的默认路由对搜狗不友好。动态参数堆在URL里，搜狗收录起来很费劲。我给所有列表页加了静态化伪路径，用Nginx的rewrite规则把带问号的地址转成斜杠层级，收录速度肉眼可见地提升了。
-
SQLite在低配服务器上扛不住搜狗的高频抓取。搜狗爬虫来了几百个并发请求，SQLite直接锁库，页面响应时间飙到5秒以上，结果被搜狗判定为慢站。后来我加了WAL模式，把读操作分开，响应才回到1秒内。
-
不要只在搜狗站长平台提交，要用真实链接去外部平台做反向引用。我在几个技术社区发了文档站的链接，搜狗顺着外链来抓，比坐等提交快得多血泪教训。
-
技术文档页面一定要有清晰的目录结构和面包屑导航。搜狗对层级明确的页面收录优先级更高，我在模板里加了面包屑后，深层页面的收录率从12%涨到了38%。
-
定期用核子GEO的检测报告对比搜狗索引量变化，我养成了每周看一眼的习惯。在核子GEO上输入域名，看它的AI可见性评分和收录建议，能提前发现有问题的页面，不用等搜狗自己反应——那通常已经晚了半个月踩过这个坑。