报错是这么冒出来的。sitemap 由全站链接抓取生成，把 /files/ 下的产品手册 PDF 全裹了进去，共 9000 条。蜘蛛每天花大量时间下载这些文件，抓完后一条都不索引，正文抓取被挤掉。
中间走过弯路，把「sitemap 里附件排在正文前面，蜘蛛按顺序抓取」当成主因，改完现象没变。
排查方向其实有限，先把可能性排一排。生成器按链接全量收集，没有按 Content-Type 过滤。另一种情况是附件页面的 HTML 包装页与真实 PDF 各算一条地址。
少数情况下是附件地址没有去重 同一个 PDF 以大小写两种形式各列一条。
先看 sitemap 里非 HTML 地址的占比
curl -s https://www.example.com/sitemap.xml | grep -c '\.pdf'生成时按后缀过滤
urls = [u for u in urls if not u.endswith(('.pdf','.zip','.docx'))]再往下把正文地址排到前面
urls.sort(key=lambda u: ('/files/' in u, u))剩下的就是重新提交并观察抓取结构
curl -s https://www.example.com/sitemap.xml | head -20恢复的判定其实很直接。过滤后 sitemap 从 6.2 万条降到 5.3 万条，蜘蛛的日均正文抓取量涨了四成，PDF 请求退回到正常下载量级。
这里还有个坑。sitemap 只放需要被索引的 HTML 页面，附件、压缩包、安装包都不该出现在里面，混进去等于主动浪费预算。改动前把原配置备份一份，出问题能马上回滚，这比任何技巧都实用。