Removing a Page: 404, 410, Redirect or Noindex Compared

There are five ways to take a page out of Google Search, and the right one depends on a question most people skip: do you want the URL gone, moved, or merely hidden? A 404 or 410 says gone. A permanent redirect says moved, and passes the page's signals to its destination. A noindex says keep crawling this but stop showing it. The Removals tool in Search Console hides a URL for about six months and nothing more. Robots.txt, which many people reach for first, does none of these.

This guide compares the five using Google's Search Central documentation, read on October 9, 2026, and the HTTP standard, RFC 9110. Timing is stated only where Google states it. Whether to retire a page at all is a different decision, covered in our guide to which old posts to keep, rewrite or retire; this post is the mechanics once you have decided.

Every removal method answers one of three intentions. The first is that the page no longer exists and nothing replaces it: an expired event, a product you will never sell again, a post that was wrong. The second is that the page's content now lives somewhere else, and you want visitors and search signals to follow it there. The third is that the page should stay reachable by people and crawlers but should not appear in results: a thin tag archive, a thank-you page, a staging duplicate.

The failure case is picking a tool from a different intention. A site that 404s a page with a close replacement throws away the links pointing at it. A site that redirects an expired product to the homepage sends Google a signal that the homepage is the canonical version of a product page, which it is not; our note on expired offers in Google covers that case in detail. A site that noindexes a page and then blocks it in robots.txt has made the noindex invisible.

The two codes mean different things in the HTTP standard. RFC 9110, published in June 2022, says a 404 "does not indicate whether this lack of representation is temporary or permanent" and that "the 410 (Gone) status code is preferred over 404 if the origin server knows… that the condition is likely to be permanent." Of 410 it says the response is intended to notify the recipient "that the resource is intentionally unavailable and that the server owners desire that remote links to that resource be removed."

That is the semantic argument for 410: it tells every client, including crawlers, that you mean it. Google's documentation, however, draws no distinction. Its page on how HTTP status codes affect Search, last updated February 4, 2026, groups both under 4xx and says: "All 4xx errors, except 429, are treated the same: Google crawlers inform the next processing system that the content doesn't exist. In the case of Google Search, the indexing pipeline removes the URL from the index if it was previously indexed. Newly encountered 404 pages aren't processed. The crawling frequency gradually decreases." Elsewhere on the page: "Google systems will stop using the URL over time."

So the honest comparison is this. Serve a 410 where you know the removal is permanent, because the standard asks you to and other clients may act on it. Do not expect Google to remove a 410 faster than a 404; Google's own page gives no such difference and no timeframe beyond "over time". Either code forfeits whatever the URL's inbound links were passing, which is the price of saying gone.

A worked example. A conference site has a page for its 2024 event, with a handful of links from speakers' sites. The 2026 event has its own page; the 2024 page lists a venue, a date and a schedule that no longer apply. Nothing on the site replaces it, because the 2026 page answers a different question. The right response is a 410: the removal is known to be permanent, and the standard's wording about server owners wanting remote links removed is exactly the situation. The wrong response is a redirect to the 2026 page, which would tell Google the two are the same document; a speaker's link about a 2024 talk would land on an agenda that does not contain it.

The failure case runs the other way. A publisher 404s a product review because the product was renamed, when the renamed product's review exists and covers the same model. The links the old review had earned now point at nothing, and the new review starts from zero. That is a moved page, not a gone one, and the next section is its tool.

Google's redirects documentation, last updated April 14, 2026, separates permanent from temporary by what the indexing pipeline does with them. For a permanent redirect, "the indexing pipeline uses the redirect as a signal that the redirect target should be canonical." For a temporary one, it "doesn't use the redirect as a signal that the redirect target should be canonical." The HTTP status page puts the same thing as strength: a 301 is "a strong signal that the redirect target should be processed", a 302 "a weak signal", and 308 and 307 are equivalent to 301 and 302 respectively.

Two non-HTTP forms are documented too. Google "interprets instant meta refresh redirects as permanent redirects" and "delayed meta refresh redirects as temporary redirects". JavaScript redirects are a last resort: "Only use JavaScript redirects if you can't do server-side or meta refresh redirects", because "Google might never see it if rendering of the content failed."

The example that goes wrong most often is the fallback 302. A platform that cannot be configured for a 301 ships a temporary redirect for a page that has permanently moved. Visitors arrive at the new page; Google keeps the old URL as canonical and does not consolidate signals. Google advises the permanent form "when you're sure that the redirect won't be reverted", and a page retirement is exactly that case. Checking that old redirects did what you intended is its own job; our redirect audit guide covers it.

A noindex is a meta tag in the page's HTML or an X-Robots-Tag HTTP header with the value noindex, which also works for files that have no HTML, such as PDFs and images. Google's documentation, last updated December 10, 2025, says that once its crawler extracts the tag or header, "Google will drop that page entirely from Google Search results", including when other sites link to it. The page itself stays live for anyone who has the address.

Two conditions govern it. First, the page must be crawlable: Google says the page "must not be blocked by a robots.txt file", because a blocked crawler never sees the directive and the URL can still show up in results when other pages link to it. Second, nothing happens until the next crawl. Google gives no fixed period and says a revisit "may take months" depending on the page's importance; it suggests requesting a recrawl with the URL Inspection tool to speed it up.

Noindex is the right tool for pages that must exist but should not rank: internal search results, filtered listings, thank-you pages, archives that duplicate other pages. It is the wrong tool for a page you want gone, because the URL keeps being crawled and keeps serving content, and the wrong tool for a page that has moved, because it passes nothing anywhere.

Search Console's Removals tool is the only method with a short documented timeframe. Google's removals guidance says a site owner can use it to remove a page "from Google's search results within a day". The tool's own help page is equally clear about the limit: "A successful request lasts only about six months", and "The Removals tool provides only a temporary removal of about six months."

It offers two actions. "Temporarily remove URL" blocks the URL from results for about six months and clears the snippet. "Clear snippet in search" removes the page's description until Google re-indexes it, while the page can still appear for matching terms. A separate "Outdated content" tab lists requests made by people who do not own the site, through the public Refresh Outdated Content tool.

The help page says what the tool is for: "Using the tool alone won't work." For permanent removal it directs you to remove or update the content and return a 404 or 410, to block access with a password, or to add a noindex. The tool buys the time for Google to see one of those. The failure case is a page hidden with the tool and otherwise untouched; six months later it reappears, often after the person who hid it has forgotten why.

Each of these is used as a removal method somewhere, and Google's documentation says each one is not. Robots.txt is the common case. Google's introduction to robots.txt says it "is not a mechanism for keeping a web page out of Google" and that "a page that's disallowed in robots.txt can still be indexed if linked to from other sites"; to keep a page out, "block indexing with noindex or password-protect the page."

The others are status codes used for the wrong job. A temporary redirect leaves the old URL canonical. A 401 or 403 is in the 4xx group, so Google does remove a previously indexed URL that returns one, but Google says not to use them to limit crawling, and they tell visitors nothing useful about where the content went; if the page is private, password protection with a proper login is the documented route. A 5xx looks like removal from the outside and is the opposite: Google's crawlers "temporarily slow down" on server errors, "already indexed URLs are preserved in the index, but eventually dropped", and only URLs that "persistently return a server error" are removed.

Eight situations cover most of what a site owner meets when pruning. The route is our reading of the documentation above; the quoted behaviour behind each is in the sections it points to.

Three checks close the job. First, confirm the server is actually returning what you configured: request the URL and read the status line and headers yourself, because platforms sometimes serve a 200 with an error message, which Google's documentation says Search Console reports as a soft 404 rather than a removal. Second, use URL Inspection in Search Console to see what Google last saw and to request a recrawl where speed matters. Third, record what you did and when, so that in six months, when a Removals request expires or a redirect is questioned, the decision is a lookup rather than an argument.

A verification log needs only five columns: the URL, the intention (gone, moved or hidden), the method served, the date, and the status line you observed on your own request. For a redirect, add the destination; for a Removals request, add the expiry month so someone sees it coming. A spreadsheet is enough. What it prevents is the common failure in which a redirect is later removed by a platform migration, a 410 is quietly replaced by a 200 soft error after a theme change, or a Removals request expires and the page returns with nobody noticing until a customer finds it.

Expectations on timing should match the documentation, which gives only the phrases below. Anything more precise is a guess. If you want help pruning an archive at scale with the right method per URL and the verification recorded, that is work our SEO team does; the editorial side of the same decision is in our note on when a post earns a new date.