Remove Many URLs From Google at Once: inurl:post and Prefixes

Imagine hundreds of pages you never meant to show in search, all with the same word in the address: /post/, /tag/, /print/, ?sessionid=. Typing inurl:post into Google finds them, so it is natural to look for a button that removes "everything that contains post". There is no such button. This guide explains what Google's tools do accept, why inurl: is only a way to look, and how to remove a whole group of URLs for good.

The short version has three parts. Use a search operator or a report to find the URLs. Use the Search Console Removals tool, with its "Remove all URLs with this prefix" option, to hide them quickly and temporarily. Then use a permanent method that matches the situation: noindex, a 404 or 410 status, a redirect, or a login. This guide covers the bulk side of the job; the single-URL basics are in Remove a URL From Google Search. Nothing here promises a date by which Google will drop the pages.

Before you begin

Own the property. The Removals tool only works for sites verified in Google Search Console. See Search Console setup.
Write down the pattern. Is the word at the start of the path (/post/...), somewhere in the middle (/blog/post/...), or in a query string (?post=12)? The answer decides which tool fits.
Know what should stay. List nearby URLs that must remain, such as /postcards/ when you are removing /post/.
Back up anything you will delete, and check that the pages are not linked from important navigation.
Time: the work takes an hour or two. The main risk is a pattern broad enough to catch pages you wanted to keep.

What the Removals tool can and cannot do

Search Console has a Removals tool with a Temporary Removals tab. A new request offers two choices:

Remove this URL only: one exact address.
Remove all URLs with this prefix: every URL that begins with the address you enter.

A prefix is the beginning of a URL, so https://example.com/post/ covers https://example.com/post/first and https://example.com/post/2026/second. The prefix has to fall inside the property you selected, and it is worth checking http, https, www and non-www variants of your pattern. The tool does not accept a "contains" pattern, a wildcard in the middle, or a list of URLs. It cannot take *post*, and it does not understand inurl:. To remove URLs where the word sits later in the address, you submit a separate prefix for each location where it begins.

The effect is also limited. A removal request hides matching URLs from Google Search results for about six months. It does not delete the pages and does not remove them from the index, and Google keeps crawling them. When the request lapses, any URL that is still crawlable and indexable can return. That is why the permanent steps below matter more than the request itself.

Why inurl: is only a search operator

inurl: is one of the search operators described in Google's help article on refining web searches. Typing site:example.com inurl:post asks Google to show results from your site whose address contains the word. It is a way to find URLs, in the same family as intitle: and filetype:. It changes nothing in Google's index.

Two cautions when using it to build your list:

Operator results are a sample, not a complete inventory. Google does not promise that site: queries list every indexed URL, and counts can look odd.
A word match may include URLs you did not intend, because Google may treat the word as a token rather than an exact string. Read the results before assuming they match your pattern.

So treat inurl: as step one of a project, never as a command.

Step-by-step instructions

Step 1: Build the list of affected URLs

Use several sources, because each misses something.

Search operator. Search site:example.com inurl:post, and look at several pages of results. Switch to a different spelling, such as inurl:/post/, if the word is common.
Performance report. In Search Console's performance report, add a Page filter set to "URLs containing" /post/, or use the custom (regex) option. This lists pages that earned impressions in the date range, and it is the closest thing Search Console has to a "contains" search. See the performance report guide.
Your own data. Export URLs from your CMS, your XML sitemap or your server logs and filter them in a spreadsheet or with a command such as grep "/post/" urls.txt.
Index status. The page indexing report shows which URLs Google has indexed and why others were left out.

Record each URL's pattern, status and whether anyone should still reach it.

What success looks like: A list that includes every address family with the word, plus the exceptions that must stay.

Step 2: Choose the permanent fix for each group

Google's documentation lists the durable options. Match each group to one:

Situation	Permanent fix
Pages are gone with no replacement	Return 404 or 410. See 410 vs 404 for removed pages
Pages moved or have a close replacement	301 redirect to the replacement
Pages should stay available but out of search	`noindex` meta tag or `X-Robots-Tag: noindex` header
Pages are private	Login or HTTP authentication

What success looks like: Every group on your list has one named fix.

Step 3: Apply the fix to the whole pattern at once

On your own server, a rule can match a pattern, which is exactly the "contains" behavior Google's tool lacks. Examples below are samples; adapt them and test on a staging copy first. The directory-level noindex example in nginx:

location ^~ /post/ {
    add_header X-Robots-Tag "noindex" always;
    # keep your normal handling here, such as try_files or proxy_pass
}

In Apache with mod_headers:

<LocationMatch "^/post/">
    Header set X-Robots-Tag "noindex"
</LocationMatch>

To answer with 410 Gone instead, nginx uses return 410; inside the location block, and Apache can use RedirectMatch gone "^/post/". To match the word anywhere in the path, use a regular expression instead of a prefix, for example location ~ /post/ { ... } in nginx, and check that it does not catch /postcards/ or other siblings. More examples are in redirects in nginx and Apache and the X-Robots-Tag guide. For pages built by a CMS, look for a setting or plugin that adds noindex to a content type, and read meta robots directives.

If the URLs contain the word only in a query string, a path rule will not match them. A noindex sent for those parameters, or a canonical tag, is usually the fix; see URL parameters and faceted navigation.

What success looks like: Requesting a sample of the pattern shows the new status or header, and a URL that should stay does not.

Step 4: Do not block the pattern in robots.txt yet

It is tempting to add Disallow: /post/ to robots.txt. Do not do that first. A blocked URL cannot be crawled, so Google never sees the noindex or the 404, and a disallowed URL can stay in the index if other pages link to it. Google's documentation says robots.txt is not a way to remove a page from the index. Leave the pattern crawlable until the pages have dropped out. The reasoning is explained in noindex vs robots.txt.

What success looks like: robots.txt does not mention the pattern, and Googlebot can fetch the pages.

Step 5: Hide them quickly with a prefix request

If the pages must disappear from results sooner than a recrawl would allow, open the Removals tool and:

Select the correct property at the top of Search Console.
Choose New request on the Temporary Removals tab.
Choose "Remove all URLs with this prefix".
Enter the full URL prefix, including https:// and a trailing slash, such as https://example.com/post/.
Read the preview text, then submit.

The trailing slash matters. Google describes the option as covering every URL that begins with the text you enter, so https://example.com/post without a slash would also match /postcards/ and /post-office/. Never enter your site root, because the prefix would cover the whole site. If the word begins at several places, such as /post/ and /blog/post/, submit one request for each prefix.

Google says a request can take effect within about a day, though approval is not assured. Put a reminder in your calendar a few weeks before the six-month mark to confirm the permanent fix is still in place.

What success looks like: Each request shows in the history table with an accepted status.

Step 6: Take the URLs out of sitemaps and links

A sitemap should list only the pages you want indexed. Remove the pattern from your XML sitemap, and fix navigation, related-post lists and internal links that point to it. Otherwise you keep inviting crawlers back to pages you want gone. See sitemap 404 and 500 errors and internal linking strategy. If an entire group was removed on purpose, content pruning covers how to decide what to merge, redirect or retire.

What success looks like: The sitemap and navigation no longer mention the pattern.

Step 7: Verify and monitor

Inspect a few URLs with the URL Inspection tool and confirm it reports your new status or noindex. The live test guide shows what to read.
Watch the page indexing report. A noindexed page appears as "Excluded by 'noindex' tag" (see that status explained), and a removed page as "Not found (404)".
Repeat site:example.com inurl:post after a few weeks as a rough check only.
Make sure the rule did not catch pages you wanted. Crawvix's scan checks "No accidental noindex" across sampled pages, which helps catch a rule that is too broad.

Google decides when to recrawl, and it can take months for less important URLs. Be patient, and never treat a single search as proof.

What success looks like: The count of indexed URLs for the pattern falls over time, and pages you kept are still indexed.

Final verification checklist

The list of URLs and their pattern is saved.
Each group has a permanent fix: noindex, 404 or 410, redirect, or login.
The fix is live and tested on sample URLs, including one that should stay.
robots.txt does not block the pattern while you wait for removal.
The prefix request, if used, has a trailing slash and is not the site root.
The sitemap and internal links no longer point at the pattern.
URL Inspection confirms what Google last saw.
A reminder is set before the temporary request lapses.

Common mistakes to avoid

Expecting a "contains" option. The Removals tool takes a single URL or a prefix.
Entering a prefix without a trailing slash. It can hide neighboring pages.
Entering the site root. That hides everything.
Relying on the temporary request alone. After about six months the URLs can return.
Blocking in robots.txt first. Google cannot read the noindex, and the URLs can stay indexed.
Treating inurl: results as the full list. It is a sample.
Using noindex for private data. It only affects search results; use a login for private pages.
Leaving the pattern in the sitemap. It sends crawlers back.

Troubleshooting

The Removals tool says the prefix is not in my property

The prefix must belong to the property you selected. A URL-prefix property for https://www.example.com/ cannot remove https://example.com/post/. Select a matching property, or use a domain property, described in domain property vs URL prefix.

Pages came back after six months

The temporary request ended and the pages were still crawlable and indexable. Apply a permanent method from Step 3.

The URLs are still indexed after I added noindex

Check that the tag or header is really served for those URLs and not blocked by robots.txt. Then wait for a recrawl. Request one for a sample page as described in requesting indexing the right way.

The pages are spam I did not create

If the URLs were created by an intruder, removal does not fix the cause. Follow hacked site spam page cleanup before requesting removal.

Frequently asked questions

Can I remove all URLs containing a word in Google Search Console?

Not with the Removals tool. It accepts one exact URL or a prefix that starts at the beginning of the address. To handle a word in the middle of an address, submit separate prefixes, or apply noindex or a 404 or 410 with a server rule that matches the pattern.

What does inurl: do in Google?

It is a search operator that finds results whose address contains a word. It helps you build a list of URLs. It does not remove anything.

How long does a Removals tool request last?

About six months. After that, URLs that remain crawlable and indexable can reappear, so combine the request with noindex, a 404 or 410, or authentication.

Does robots.txt remove a page from Google?

No. It controls crawling. A disallowed URL can remain indexed, and Google cannot read a noindex on a page it is not allowed to fetch.

Should I use 404 or 410?

Both tell Google the page does not exist. Use 410 when you want to say the removal is deliberate; see the 410 vs 404 guide.

Can I submit a list of URLs for removal?

The Removals tool in Search Console does not offer an upload of a list. Use a prefix for groups, or a server rule that applies a permanent fix to the whole pattern.

Official references

Want to see how a site is checked from the outside? Try the free website sample. This guide provides technical information, not a promise about when pages leave search results.