How do I remove a URL from Google with the Removals tool?
The tool hides a result, and that's all it does. Before I open it I decide whether the page should leave Google at all, the same call I make in my content audit service, because plenty of pages people want gone are worth more fixed than hidden.
The request itself is short. In Search Console I open Removals, choose New request, then Temporarily remove URL, and pick Remove this URL only or Remove all URLs with this prefix. Google's help page says the request usually takes up to a day, isn't guaranteed to be accepted, and blocks the URL for about six months. The URL has to sit in a property you own, and one request covers http and https, www and non-www. Other subdomains, like m. or amp., need their own.
The part owners miss is on Google's own help page for the tool: blocking a URL doesn't stop Google crawling the page, only showing it, and the tool is only one step in removing a URL permanently. It also matches the exact address. Google treats /dragon and /Dragon as two URLs, and says to include the parameters a page needs and leave out optional ones, so I file one request per address the result actually shows.
| Request | What it does | How long it lasts |
|---|---|---|
| One exact URL | Hides that URL from Google's results while Google keeps crawling it | About six months, then it can reappear |
| Every URL under a prefix | Hides every URL that starts with the prefix, www and non-www | About six months, the same as a single URL |
| Clear snippet | Wipes the description under the result but leaves the result showing | Until Google indexes the page again |
That's why I think of it as an emergency brake. It's the right tool when something's showing that shouldn't be, today: a staging copy that got indexed, a private file, a page with details that are plainly wrong. It's the wrong tool when it's the only thing you do.
Blocking the page in robots.txt isn't a removal. Google's guide says not to use robots.txt to block a page, and its noindex documentation adds that a noindex rule only works when the page isn't blocked by robots.txt. Disallow it and Google can't read the very tag you added to get it out.
How do I remove a URL from Google permanently?
The signal has to live on the page itself. On a WordPress site the permanent signal goes live first and the temporary request comes last, so the six months are spent waiting for something that's already true. Here's the full run.
- Step 01
Confirm the page is actually in Google
I run the URL through URL Inspection in Search Console before anything else. If it isn't indexed, there's nothing to remove.
- Step 02
Pick one permanent signal
Google names three. If the page is gone for good, the server returns a 404 or 410. If visitors still need it but searchers don't, it gets a noindex tag. If only some people should see it, it goes behind a login.
- Step 03
Put the signal on the server
A noindex goes in the page head as
<meta name="robots" content="noindex">, usually through the SEO plugin's per-page setting, or as anX-Robots-Tag: noindexheader for PDFs and other files. A deleted page has to return a real 404 or 410 status, not a friendly page that answers 200. - Step 04
Check it the way Googlebot sees it
I fetch the URL logged out and read the status code and the page source, not the WordPress dashboard. Caching plugins and CDNs can keep serving yesterday's version, and a login has to keep the content out of the response, not just out of view.
- Step 05
Keep robots.txt open for that URL
Google has to crawl the page to see the noindex or the 404, so no Disallow rule can cover it. A Disallow added in a hurry quietly undoes every step above it.
- Step 06
Take it out of the sitemap and the links
A URL that's leaving shouldn't still sit in the XML sitemap or in menus and posts. Those send Google back to a page I'm asking it to drop.
- Step 07
File the temporary removal if it's urgent
Only now do I open the Removals tool, and only when the page has to vanish before Google next crawls it. One catch from Google's help: if the URL already returns a 404 or 410 when you file, Google treats the page as gone and the block expires, so the 404 has to do the work.
- Step 08
Check again before the block runs out
I look at the URL in URL Inspection and the Pages report, where a noindexed page shows as excluded by the tag and a deleted one as not found. If a noindexed or login-gated page is still indexed near the end of the six months, the permanent signal isn't working, and that's what I fix.
Google's guide points out that a noindex tag only keeps a page out of Google. Search engines that don't support the tag can still show it, while removing or updating the content keeps it out of them too. So for anything private I'd rather delete it or lock it than just tag it.
What if the page is on someone else's site, or it's about you?
Then the Removals tool is out, because it only accepts URLs in a property you own. Google's route for other people's pages is the Refresh Outdated Content tool, and it only works after the page has changed or disappeared. If the page is gone, the result stops appearing. If the text has changed, the old snippet clears until Google's crawler visits again. If the information's still on the live page, Google says plainly that the tool isn't for you.
So the order never changes: get the page changed or taken down at the source first, then ask Google to catch up. If you own a site, requests like these also show up in the outdated content tab of your own Removals report, which tells you someone outside cared enough to file one.
Where the content is personal information about you, Google's help page on removing your private info from Google Search is the route, and that isn't work I do. For results showing your address, phone number or email, the same page points to Google's Results about you feature. Getting reviews, news stories or anyone else's content about a business taken down isn't my work either. I work on pages on sites you control.
Rather have me do this? One person, whole job.
Book a call on UpworkHow do I remove an image, a PDF or a whole site from Google?
Images are the one case where robots.txt is Google's own answer. Google's image removal guide gives two permanent methods, a robots.txt disallow rule or a noindex X-Robots-Tag header, says they have the same effect, and says using both makes no sense because Googlebot has to crawl the URL to read the header. The Removals tool covers the emergency.
For a PDF or another file, Google's Removals help says non-HTML files should be completely removed from the server, or they get the noindex header. For a whole site, the prefix request takes the homepage URL, and Google's help adds that a staging subdomain is blocked separately from the main domain. The permanent part is the same as for one page: delete it or put it behind a login.
Should I remove a thin page or improve it?
Usually improve it, if it's showing up at all. A thin page that still earns impressions in Search Console is telling you Google finds it relevant to something, and removing it throws that away. Removal's the right call for pages with no reason to exist: no clicks, no links, nobody who'd miss them.
The clearest removals are the accidental ones. On one UK site, a location page template went live by accident with its placeholder tags where the title and heading should be. Nobody meant that page to exist, so it needs a 404 or a 410, not a rewrite. A page with backlinks or enquiries keeps its value through a redirect to its closest replacement, and anything still earning impressions gets read by a person before anyone deletes it.
What shouldn't the Removals tool be used for?
Google's help page lists the jobs the tool isn't built for. These are the ones people reach for it anyway, and what I do instead.
- i.
Old pages that already return a 404
Google says there's no need to request an urgent update for them. A page that returns 404 drops out as Google recrawls it, so filing a request only adds a task.
- ii.
Crawl errors in Search Console
The tool hides URLs from search results, not from your Search Console account, so the errors stay listed. They need fixing at the source, where Google can't crawl or index the page.
- iii.
Moving a site
Google's help page says the tool won't remove old content or URLs in a move. Hiding the old URLs throws away whatever they've earned, which is why a move gets a one to one 301 map instead.
- iv.
Cleaning up after a hack
Google says to block only the new URLs the hacker created, not the whole site. Hiding every page takes the real content down with the spam, and the hack still has to be cleaned off the server.
- v.
Picking the right version of a page
Google warns that the tool won't keep your favourite version of a duplicate and could remove every version of the URL. Duplicates need a canonical or a redirect instead.
- vi.
Making a removal permanent
On its own it can't. After about six months the page can come back, which is why every request I file sits on top of a noindex, a 404 or 410, or a login.
If there's a page in Google you need gone and you aren't sure whether it should be removed, redirected or improved, that decision and the work behind it is what I do, remotely, on WordPress sites.
Book a call on Upwork
