事情本身不复杂，线索都在日志里。标签页每页只放 3 条，一个只有 8 篇文章的标签被翻到第 40 页，page/40 和 page/41 返回同一批内容，状态码都是 200。日志里这个标签的分页地址一天被蜘蛛抓了 600 次。
第一反应是「深分页没有 noindex 也没有 canonical」，验证下来不成立。
真正麻烦的地方在于，几个原因的现象几乎一样。分页参数没有上限校验 超出总页数仍然返回 200。另一种情况是标签页每页条数太少 总页数被放大。
不容易想到的是，标签云和归档链接把深分页暴露给蜘蛛。
请求超出范围的分页地址
curl -s -o /dev/null -w '%{http_code}\n' https://www.example.com/tag/php/page/40超过总页数直接返回 404
if ($page > $max_page) { status_header(404); exit; }给第二页之后加 noindex
add_filter('wp_robots', 'noindex_deep_pagination');等前面都确认过，再统计该标签的抓取次数
grep -c '/tag/php/page/' access.log怎么算真的好了，看的是同一批现象。第 40 页返回 404，日志里深分页的抓取量降到个位数，索引里只剩第一页。
分页上限要在服务端判断，模板里藏掉翻页按钮挡不住直接拼地址的请求。拖得越久，排查成本越高，因为现场状态会被后续操作覆盖。