# Googlebot 因页码导致 404 错误
**URL:** https://meta.discourse.org/t/googlebot-404-errors-due-to-page-numbers/96337
**Category:** Support
**Created:** [2018年九月4日 15:46 UTC](https://meta.discourse.org/t/googlebot-404-errors-due-to-page-numbers/96337 "2018-09-04T15:46:41Z")
**Posts on this page:** 1
**Showing post:** 16
### Author:  [@zogstrip](https://meta.discourse.org/u/zogstrip)
#### Post date: [2026年五月21日 14:48 UTC](https://meta.discourse.org/t/googlebot-404-errors-due-to-page-numbers/96337/16 "2026-05-21T14:48:16Z")
希望这能解决问题，而不会引入新问题 😅
>
>
> Requesting \`/t/slug/id?page=N\` with a page number beyond the topic's last valid …page raised \`Discourse::NotFound\` and returned 404. This produced a long-running stream of "increase in 404 errors" reports in Google Search Console, because crawlers (and our own \`sitemap\_recent.xml\`) hold cached page URLs that become stale when a topic shrinks — most often after deleted posts or topic splits.
>
> The 404 also masked a latent bug for staff: the original check compared the requested page against \`topic.posts\_count\`, a cached column that excludes whispers and ignores active filters (\`username\_filters\`, \`replies\_to\_post\_number\`, etc.). A staff user navigating to \`?page=N\` covering whisper posts could be 404'd even though the page contained content they were entitled to see.
>
> Replace the 404 with a 301 redirect to the last valid page (or the unparameterized topic URL if the topic fits in one page), using \`@topic\_view.filtered\_posts.count\` — the count of posts visible to the current viewer — so the math respects whispers, deletions visible to staff, and active filters. The COUNT query is gated behind \`page \> 1\` so the common case (no \`?page=\` param) pays nothing extra.
>
> Negative pages still raise 404; only the over-range case becomes a redirect.
>
> https://meta.discourse.org/t/96337
---
_[View the full topic](https://meta.discourse.org/t/googlebot-404-errors-due-to-page-numbers/96337)._