事情本身不复杂，线索都在日志里。产品要求列表页一屏展示更多内容，每页条数从 20 改成 50，分页总数从 500 页变成 200 页。改完之后第 201 页之后的分页地址全部 404，索引里那批地址在两周内变成死链，栏目页的收录也掉了一截。
第一反应是「sitemap 里的分页总量没跟着更新 仍提交已不存在的页码」，验证下来不成立。
这类报错背后常见的原因有几处，逐个排除就行。分页地址按页码生成 总页数减少后超出的页码没有兜底处理。少数情况下是旧分页地址没有做 301 或返回空列表 直接落到 404。
少数情况下是列表页缓存未失效 部分节点还在按 20 条渲染。
动手时先确认超出范围的页码返回什么
curl -s -o /dev/null -w '%{http_code}\n' 'https://www.example.com/list?page=400'给越界页码返回 301 到最后一页
if ($arg_page ~ '^[0-9]+$') { return 301 /list?page=200; }然后把旧分页地址批量提交死链处理
curl -s 'https://www.example.com/api/gone?prefix=/list?page=' -d 'from=201&to=500'剩下的就是重新生成 sitemap 并确认页数
curl -s https://www.example.com/sitemap.xml | grep -c '/list?page='恢复的判定其实很直接。加上越界跳转并把旧地址提交死链后，两周内 GSC 里的 404 数量回落，栏目页收录恢复到改动前的九成以上。
这里还有个坑。分页参数改动会牵动一整批已收录地址，改之前先想好旧页码怎么处理，别让它们直接掉进 404。这类问题最好一次改到位，反复小改反而容易把原因搅混。