The short version: the removals tool in Google Search Console hides a URL from Google’s results for about six months, it does not delete the page from Google’s index or from the internet, and it only works long term if you pair it with a real fix like a 301 redirect, a noindex tag, or taking the page down. If you’ve got a verified property, you’ll find it under Index in the left sidebar, and you can request a single URL, a whole prefix, or use the separate outdated content tool for pages Google hasn’t recrawled yet.
What the removals tool does (and doesn’t do)
I want to get this out of the way early because it’s the bit most guides gloss over. The removals tool doesn’t remove anything. It hides. Google still crawls the page, still has it in the index, and after roughly six months, if nothing else has changed, it can quietly reappear in search results.
I found this out the expensive way with a client back in 2023. We’d migrated a home services company from an old WordPress build to a new stack, and a batch of category pages kept showing up in search with stale prices and a phone number that had been disconnected for two years. I used the removals tool thinking job done. Five and a half months later, three of those pages were back, sitting in position 4 for a branded search term, showing the same wrong phone number. The client was not thrilled, and rightly so.
The lesson: the removals tool is a plaster, not stitches. It buys you time. What solves the problem is a 301 redirect, a noindex meta tag, deleting the page and returning a proper 404 or 410, or blocking it in robots.txt if it should never be crawled again. Use removals to stop the bleeding immediately, then fix the wound within that six month window.
Where to find it and how to submit a request
Log into Google Search Console with a verified property (you need to be a verified owner or full user, not just a restricted user, to use this ). In the left sidebar, look under the “Index” section for “Removals.” Google has moved this menu around a few times over the years, so if you can’t see it, check under “Index” first before assuming it’s gone.
- Click “New Request”
- Paste in the exact URL you want hidden
- Choose one of three options: “Remove this URL only,” “Remove all URLs with this prefix,” or “Clear cached URL”
- Confirm, and Google typically actions it within a few hours, though it can take up to a day
“Remove this URL only” does exactly that, one page, one URL. “Remove all URLs with this prefix” is the option to use when an entire folder needs to disappear, say /old-blog/ or /staging/, and it will hide every URL that starts with that path. This is the one I used for a client who’d accidentally left a staging subdirectory crawlable for four months. We caught 340 indexed URLs in one prefix request rather than submitting them one by one.
“Clear cached URL” is different again. It doesn’t hide the page from results, it just wipes Google’s stored snapshot of the content and forces a fresh crawl next time the bot visits, so the search snippet updates faster. Useful if you’ve fixed a typo, a wrong price, or an embarrassing bit of placeholder text (“Lorem ipsum” made it live on a client’s services page once, true story) and you want the old wording gone from Google’s cache without waiting for a natural recrawl.
The outdated content tool: a separate, underused option
There’s a second tool that sits alongside removals and gets far less attention: the outdated content tool. This one is designed specifically for pages where the live content has already changed but Google’s search snippet still shows the old version, like a title, price, or description that used to be true.
You can access it two ways. Inside Search Console, from a specific removals request, or independently at Google’s public outdated content submission page, which doesn’t even require you to be a verified site owner. You paste in the URL and, if relevant, the exact outdated text you saw in the search result. Google checks the live page, confirms the content has changed, and updates the snippet, sometimes within a day or two.
I use this one a lot more than the full removal request now, honestly, because it fixes the actual visible problem (wrong info in the search snippet) rather than just hiding the page and creating a ticking six-month clock. If a client’s phone number changes or a “starting from £299” offer becomes £399, this is the faster, less blunt tool.
SafeSearch filtering and sensitive personal information
There’s a third category inside the removals tool worth knowing about even if you never touch it: requests to filter content under SafeSearch, and requests to remove pages showing personal information like a home address, a national insurance number, or an explicit image posted without consent. These follow a different, stricter Google review process and aren’t something you’d use for ordinary SEO housekeeping. If a client ever comes to you panicking because an old team member’s personal phone number is showing in a cached page, this is the route, but be honest with them that it goes through manual review and can take longer than a standard removal.
A real six-step process I follow
Here’s the exact sequence I run through whenever a removal request comes up, whether it’s my own site or a client’s:
- 1. Confirm the actual problem first. Is the page outdated, embarrassing, duplicate, or harmful? Each needs a different fix, not all of them need removal at all.
- 2. Fix the root cause on the site itself before touching Search Console. Redirect it, noindex it, or delete it.
- 3. Submit the removal request as a stopgap for immediate visibility, especially if the page is live and indexed right now while your permanent fix propagates.
- 4. Use “Clear cached URL” instead of a full removal if the page still needs to exist and just needs its snippet refreshed.
- 5. Check back in Search Console after roughly six months (I set a calendar reminder, not a Search Console alert, because there isn’t a native one) to confirm the underlying fix has held and the page hasn’t crept back.
- 6. Recrawl and validate using the URL Inspection tool to confirm Google now sees the corrected version, whatever that is: redirect, noindex, or 404.
That six-month reminder in step five is the step people skip most often, and it’s the one that bit my client. If your fix isn’t solid, the page comes back and you’re right where you started, except now the client thinks the tool doesn’t work.
Request limits and how they trip people up
Google doesn’t publish an exact daily cap that’s guaranteed to stay fixed forever, but in practice most verified properties can submit up to around 1,000 individual URL removal requests in a rolling period before you’ll hit a limit or get flagged for review. For prefix removals covering whole folders, that number of individual URLs inside the prefix doesn’t count against you the same way, since it’s one request covering many pages. I mention this because I’ve seen agencies try to bulk-submit thousands of thin, low-value URLs at once after a site migration, assuming removals is a substitute for proper redirect mapping. It isn’t, and Google’s system will start rejecting or delaying requests once it looks like abuse rather than genuine cleanup.
If you’re dealing with a large-scale migration involving thousands of URLs, the removals tool is the wrong primary tool entirely. Redirect mapping, an updated XML sitemap, and patience with natural recrawl speed will do more than any batch of manual removal requests ever will.
When removals is the wrong tool
A few situations where I’d actively steer someone away from the removals tool:
- Trying to remove a competitor’s page. It doesn’t work that way. Removals only apply to properties you’ve verified ownership of.
- Trying to fix duplicate content across your own domain. That’s a canonical tag job, not a removal job.
- Trying to “clean up” thin content at scale ahead of an algorithm update. Improve or consolidate the content instead; hiding it doesn’t improve site quality signals, it just creates gaps.
- Assuming it removes a page from other search engines. It doesn’t touch Bing, DuckDuckGo, or anything outside Google’s own index.
That last point catches people out constantly. I’ve had clients assume that because a page vanished from Google, the problem was solved everywhere. Bing Webmaster Tools has its own separate removal request process, and if brand reputation is the concern, you need to submit there too.
Where this fits into a wider technical SEO habit
None of this replaces good site hygiene. If you’re regularly finding pages that need emergency removal, that’s usually a sign of a bigger process gap, like no review step before staging environments go live, or no redirect plan built into your migration checklist. I keep a running list of free tools I lean on for exactly this kind of technical checking, which I wrote up in the free tools I use instead of expensive marketing software, and Search Console itself sits right at the top of that list because so much of it, including removals, costs nothing and gets underused.
If you’re evaluating an existing site or app before buying it, by the way, checking its Search Console history for a pattern of frequent emergency removals is a useful due diligence step, it tells you something about how the previous owner managed content quality. I cover more of that angle in how to buy a profitable app, where indexing history is one of the checks I recommend before any money changes hands.
The uncomfortable bit nobody puts in the tutorial
Here’s the part that doesn’t get said often enough: most people reach for the removals tool because it feels like control. You click a button, the scary page disappears from search, panic subsides. But the tool is designed to buy you exactly six months of breathing room, not to solve anything permanently, and Google is fairly open about that if you read their own documentation rather than skimming a tutorial. If your fix isn’t done by the time that window closes, you haven’t solved the problem, you’ve just delayed the awkward conversation with your client or your boss. I’d rather tell a client honestly “this will hide it for six months while we fix the redirect” than let them believe it’s gone for good, because the second version always ends in an uncomfortable follow-up call.
I have written more around this on the site: The Free Tools I Use Instead of Expensive Marketing Software, How to Buy a Profitable App: Complete Guide.
Frequently asked questions
Does the removals tool delete my page from Google forever?
No. It hides the URL from search results for roughly six months and does not remove it from Google’s index or delete the actual page. For a permanent fix you need a 301 redirect, a noindex tag, or genuine deletion of the page itself.
How long does a URL stay hidden after I submit a removal request?
Around six months by default. After that window, if the underlying issue hasn’t been fixed on the site, the URL can be recrawled, reindexed, and reappear in search results exactly as it was before.
Can I use the removals tool on a website I don’t own?
Not through standard Search Console removals, which requires verified site ownership. For sensitive personal information on a site you don’t control, Google has a separate public request process, and for outdated snippet content there’s a public outdated content submission page that doesn’t require ownership verification.
What’s the difference between using the removals tool and adding a noindex tag?
The removals tool is a temporary hide requested through Search Console that lasts about six months, while a noindex tag is a permanent instruction added to the page’s HTML telling Google not to index it at all. The removals tool is the fast, temporary fix, and noindex is the actual permanent solution, they work best used together.
