Remove Site from Google Search Results: Google Page Removal Tool to Remove a Webpage or URL from Google

How long does it take to remove a page from Google?

The temporary route is fast. A Removals tool request is normally processed within about a day, and that speed is the entire reason the tool exists. When a page is leaking data or a legal team is asking questions this afternoon, nothing else works on that timescale.

The permanent route runs on Google's crawl schedule instead, and that is not something you can rush. A noindex tag or a 410 only takes effect when Googlebot next fetches the URL and sees it. For a well-linked page that might be days. For a deep page on a large site that Google visits rarely it can be weeks or longer. Google's own guidance on robots meta directives notes that revisits may take months.

This gap between the two speeds is why the recommended order is to do both. Apply the permanent signal to the page, then file the temporary removal to cover the crawl delay. The blackout hides the URL while Google gets around to recrawling it and discovering that the page now says no. By the time the six months lapse, the permanent signal has done its work and there is nothing left to bring back.

Why did my removed page come back to Google?

Because the removal was doing exactly what it was documented to do. Google states that requests made in the Removals tool last for about six months, and Search Console help spells out the consequence: the page can reappear in Search results after the blackout period, and the page will be recrawled before appearing in Search results again.

Read that second half carefully, because it contains the fix. Google recrawls before restoring. If the URL now returns 410, or carries a noindex tag, or sits behind authentication, that recrawl finds a page that no longer qualifies and the URL stays out. If the page is still sitting there serving 200 with the same content as before, Google finds nothing new and puts it back. The reappearance is not a bug or an expired setting. It is a recrawl of a page nobody changed.

The practical failure mode is organizational rather than technical. Someone files the removal during an incident, the URL disappears, the ticket closes, and the person who would have deleted the page moves on. Six months later, long after anyone is watching, it returns. Set a reminder for month five, or monitor the URL so its return is an alert rather than a discovery.

• Removals last about six months, by design, not by accident.
• Google recrawls the URL before restoring it to results.
• If the page still serves 200 with the old content, it comes back.
• If the page now returns 410, or has noindex, or requires a login, it does not.

How do I permanently remove a page from Google?

Google names three methods for keeping information out of Search for good, and ranks them. Removing or updating the content on the page is described as the most secure way to prevent your information from appearing in other search engines, and the phrasing matters: it is the only option on the list that also handles engines other than Google. Password-protecting the page is second, since limiting access lets the right users through while preventing Googlebot and other crawlers from reaching it. Adding a noindex tag is third, and Google flags its limitation directly, that a noindex tag only blocks your page from showing up in Google search results, so users and other search engines that do not support noindex can still access the page.

Where the content is genuinely being retired, deleting it and returning a proper status code is the cleanest answer. A 410 Gone states the removal is permanent and Google treats it as the stronger of the two signals. A 404 Not Found gets there as well, generally a little more slowly, because a 404 leaves open the possibility that the page is missing by mistake. Either beats the common shortcut of redirecting the dead page to your homepage, which Google is likely to treat as a soft 404 and which gives users a confusing landing.

Where the page must stay live for logged-in users, internal staff or a payment flow, noindex is the right tool. Serve it in the head as a meta robots tag or as an X-Robots-Tag HTTP header, which is the only workable option for PDFs, images and other non-HTML files. The one rule that cannot be broken is that the page has to stay crawlable for the tag to do anything at all.

Does robots.txt remove a page from Google search?

No, and Google says so on the removal page itself: do not use robots.txt as a way to block your page. This is the single most expensive mistake in this whole topic, because it feels like the strongest possible action and it produces the opposite of the intended result.

robots.txt controls crawling, not indexing. Google can and does index a URL it was never allowed to fetch, using signals like the anchor text of links pointing at it, and lists it without a description. That is the status Search Console reports as indexed though blocked by robots.txt. Worse, blocking the URL guarantees the page stays that way, because the noindex tag you carefully added lives inside a page Google is not permitted to read. The disallow rule you added to remove the page is the reason it can never be removed.

The order is what fixes it, and it is counterintuitive enough that it is worth writing down. Unblock the URL in robots.txt first. Add the noindex tag, or return 410, or add authentication. Wait for Google to recrawl and confirm the URL has dropped out. Only then, if you still want to save crawl budget on that path, put the disallow rule back.

• robots.txt blocks crawling. It does not remove anything from the index.
• A blocked URL can be indexed with no snippet, from external link signals alone.
• A noindex tag on a blocked page is never read, so the URL stays indexed indefinitely.
• Correct order: unblock, apply noindex or 410, confirm it dropped, then reblock if needed.

How do I remove my whole site from Google search results?

For an entire property, the Removals tool accepts a prefix rather than a single address. Choosing to remove all URLs with a given prefix covers everything beneath a path, which handles a retired section, a language folder nobody maintains, or an entire domain in one request. It carries the same six month expiry as any other removal, so it is a stopgap for the whole site exactly as it is for one page.

The situation that produces this request most often is a staging or development environment that got crawled and indexed. There the durable answer is not a removal request at all, it is HTTP authentication on the environment. A login prevents Googlebot from reaching any of it, permanently, and it also closes the door on the next staging site somebody spins up on the same host. Adding a noindex tag across a staging site works too, but only for as long as somebody remembers to strip it before that code reaches production, and that is a genuinely common way to accidentally deindex a live site.

For a real site being taken offline for good, serve 410 across the retired URLs and leave them that way through a few crawl cycles. Pulling the DNS record instead makes the whole site unreachable, which sounds decisive and actually slows removal down, because Google treats connection failures as a temporary problem and holds the URLs longer than a clean 410 would.

How do I check that a page was actually removed from Google?

The honest answer is that you have to look, and most teams never do. The Removals tool reports the status of your request, which is not the same thing as the status of the URL. A request can sit at Approved while the underlying page is perfectly indexed and waiting for the blackout to lift. Search Console also reports on a delay, so the coverage data you are reading describes the site as it was, not as it is right now.

A site query in Google is the usual first check and it is a rough instrument. Google describes site: results as an estimate, it excludes some content, and the counts move around for reasons unrelated to your removal. It will tell you a page is definitely still there. It is much less reliable at proving a page is gone.

What actually answers the question is checking the specific URL and then continuing to check it. The console at the top of this page reports whether Google currently holds each address you give it, handles a whole prefix at once for the staging site case, names the reason when a page is still indexed, and reports Bing separately so a removal that only ever applied to Google does not read as finished. The value is less in the first check than in the ones after it, because the risk with removals is entirely on the far side of that six month window when nobody is looking.

• A request marked Approved describes the request, not the URL.
• The site: operator is an estimate and is weak evidence that a page is gone.
• Check the exact URL, and check it again after the blackout window expires.
• Check Bing separately. A Google removal has no effect on any other engine.