de-indexing: How to Remove URLs From Google and Bing

Quick Answer
de-indexing means removing a URL from a search engine's index or stopping it from being included. Use noindex to keep a page public but out of search. Use HTTP 404 or 410 for deleted pages. For urgent removal, use the search engine's temporary removal tool alongside a lasting change to the page.
Key Takeaways
The right removal method depends on what should happen to the page itself. These seven points cover the main choices and the mistakes most likely to delay removal.
- Use noindex when visitors should still access a page directly, but supported search engines should exclude it from results.
- Return a genuine HTTP 404 or 410 when content has been permanently deleted and no suitable replacement exists.
- Google's temporary removal requests generally last about six months, so permanent exclusion needs a separate technical change.
- Bing has its own temporary URL-blocking process, with a documented duration of up to 90 days.
- A robots.txt disallow can stop crawlers from seeing noindex, leaving an unwanted URL in search results.
- Protect private files through deletion or access controls because removing search results does not secure the underlying content.
- Check the actual server response and later index status before treating a removal request as complete.
Start with the result you need. A public page, a deleted file, and a private document call for different actions. Search tools can help with speed, but the lasting result comes from the state of the content.
Choose the right de-indexing method for your URL
The best removal method depends on one simple question: should people still be able to open the URL? If the answer is yes, noindex may fit. If the content no longer exists, a proper HTTP error response is often the right choice. If the page contains private data, access control comes first.
Speed is a separate concern. You may need a result hidden before Google or Bing next checks the page. That's where temporary removal tools help. They do not replace the change you make on your own website.
Use this decision matrix to match each situation to an action. It draws on Google's removal guidance and official search-engine controls. The matrix is a practical decision aid, not a formal rule issued by Google or Bing.
| Situation | Durable action | Urgent action | What to check | Mistake to avoid |
|---|---|---|---|---|
| Public page should stay online but leave search. | Add a crawl-accessible noindex directive. | Request temporary hiding if needed. | HTTP 200, noindex present, later index status. | Blocking the crawler before it sees noindex. |
| Old page is permanently deleted. | Return HTTP 404 or 410. | Usually none; request hiding if urgent. | Real HTTP response and later search status. | Showing an error message with HTTP 200. |
| Sensitive document was exposed. | Delete the file or restrict access. | Request eligible temporary removal. | Direct access, all known URLs, search results. | Treating noindex as data protection. |
| Public PDF should stay available but leave search. | Send X-Robots-Tag: noindex on the PDF response. | Use a removal tool if urgent. | PDF response headers and later index status. | Editing only the page linking to the PDF. |
| Content has moved to a relevant new URL. | Redirect to the real replacement. | Usually unnecessary. | Redirect target and search-selected URL. | Redirecting unrelated content to the homepage. |
| URL disappeared without permission. | Find and fix the cause of exclusion. | Do not request removal. | Crawl access, index status, directives, canonical. | Assuming every missing result is a penalty. |
| Deleted URL still appears in Bing. | Keep a genuine removal response. | Use Bing's eligible blocking tool. | HTTP status and later Bing visibility. | Assuming submission alone completes removal. |
Two cases deserve extra care. A public PDF can remain online with a resource-level noindex rule. A leaked private PDF should instead be removed or secured. Both may vanish from search, but only one approach addresses the exposure itself.
A redirect also serves a different purpose. It tells visitors and search engines where related content now lives. It is not a substitute for deleting sensitive content or hiding an unrelated page.
Before making changes, confirm that you control the website or have permission from its owner. Removal tools for verified properties cannot be used to delete arbitrary pages hosted by someone else.
Keep a page accessible with noindex
Use noindex when a page should remain online but should not appear in supported search results. The URL can still work for anyone who knows it. This makes noindex useful for certain campaign pages, internal reference pages, or public files that do not need search traffic.
Google's noindex documentation explains the core rule. Googlebot must be allowed to fetch the resource and read the directive. Once Google processes the rule, it can drop the URL from Google Search.
There are two common ways to add noindex. One works in an HTML document. The other works through the server's HTTP response headers.
Add an HTML robots meta tag
For an ordinary HTML page, place this tag inside its head section:
``html
<meta name="robots" content="noindex">
``
The instruction tells search engines that support the rule not to include the page in their indexes. It does not stop a visitor from opening the page. It also does not hide the page from people who follow a direct link.
Suppose a company has an old campaign page. The sales team still shares it with past customers, but the page should no longer attract search traffic. A noindex tag can serve that goal without deleting the page.
Make sure the tag reaches the crawler. Some website builders insert SEO settings into the final HTML, while others change templates or server rules. Check what the page actually serves instead of trusting a checkbox in the content system.
Also check for conflicting directives. A template, plugin, or response header may add indexing rules you did not expect. Fix those conflicts before waiting for a new crawl.
Use X-Robots-Tag for PDFs and other files
A PDF does not have the same HTML head section as a normal webpage. For these files, the server can send an indexing instruction in its HTTP response.
The Google robots meta and X-Robots-Tag reference documents this method. A suitable response header is:
``http
X-Robots-Tag: noindex
``
The header belongs on the response for the actual file. Adding a robots meta tag to a webpage that links to the PDF does not remove the PDF's own URL from search.
You can check the response headers with a browser's network tools or a command such as:
``bash
curl -I https://example.com/files/report.pdf
``
This illustrative command checks the headers returned for that request. If the server treats HEAD requests differently, inspect a normal GET response as well. The objective is to confirm what the crawler can receive.
Noindex is a search visibility rule, not a password. Anyone who can load the resource directly may still read or share it.
Remove deleted or private content permanently
A deleted URL should return a real status that tells crawlers the resource is gone. For confidential content, the priority is different: stop unauthorized access first. Search-result removal is useful, but it cannot replace that protection.
Choosing between these actions begins with the resource itself. Is there a genuine replacement? Does the old file still contain information that should not be public? Will direct visitors need to reach another page?
Decide between 404, 410 and a relevant redirect
HTTP 404 means the requested resource was not found. HTTP 410 means the resource is gone. Both can tell search engines that the old URL should no longer remain indexed once they process the response.
Bing's permanent content removal guidance includes 404, 410, and noindex among the relevant technical methods.
Use 404 when the file or page no longer exists and a standard not-found response fits. Use 410 when you want to state that the removal is intentional and the resource is gone. Do not assume either status guarantees instant removal.
What matters is the real response code. A webpage can display the words 'Page not found' while still returning HTTP 200. Search engines may treat that as a soft 404. Check the server response rather than judging only by how the page looks.
A redirect makes sense when a page has truly moved. For instance, a replaced product guide can send visitors to its relevant new version. Avoid sending every deleted URL to the homepage. An unrelated destination is not a meaningful replacement.
For more on ordinary deleted-page errors, see which Google crawl errors need fixing.
Protect sensitive material beyond search results
Imagine a customer report was placed in a public downloads folder by mistake. A search engine found the PDF, and its URL now appears in results. Adding noindex may hide it later, but the file remains open to anyone who has the address.
That is not a safe final state.
Google's guidance on controlling what you share separates search visibility from content access. Deleting the file or restricting access is the sounder approach when the information is private.
If the document must remain available to authorized staff, move it behind access controls. Check that unauthenticated visitors can no longer retrieve the original content. A login page that still exposes the file through another public path does not solve the problem.
Then address the search listing. Use the applicable removal tool when quick hiding is needed. Check alternate URLs, file copies, and accessible variants. Removing one listing does not erase all copies from the internet.
Use Google and Bing removal tools for urgent hiding
Temporary removal tools are for speed. They can hide an eligible result before the search engine has fully processed a lasting change. Use them when the result is causing a real problem, not as routine housekeeping for every old URL.
Google and Bing manage these requests through separate tools. A request sent to one search engine does not automatically remove the result from the other. Each engine must be checked on its own.
Google Search Console temporary removals
Google's Search Console Removals tool documentation says that temporary requests generally last about six months. The tool is intended for properties that the requester controls.
First, open the correct verified Search Console property. Go to the Removals area and choose the temporary removal option. Enter the URL you need to hide. Check the available matching choices before sending the request.
Google supports requests targeting a particular URL or a matching URL prefix. A prefix request can affect more than one address, so review its reach with care. Do not hide a whole folder when only one file is the problem.
Google says quick removal can occur within a day. Treat that as guidance, not a promise. Check the request status and search results afterward.
Most important, finish the permanent work. Delete the content, protect it, or apply a suitable noindex rule. Otherwise, an accessible and indexable URL may appear again after the temporary block ends.
You usually do not need an urgent removal request for every old 404. Google can drop deleted URLs as its crawler sees their status. Reserve urgent requests for cases where waiting has a clear cost or risk.
Bing URL blocking and permanent removal
Bing has a separate content removal tool for eligible requests. Its documented temporary blocking period can run up to 90 days. That is not the same as Google's roughly six-month period.
Use the correct verified site in Bing Webmaster Tools. Check which URLs or paths the request will affect. As with Google, blocking a result is not the same as deleting the page from your server.
For lasting removal, Bing needs to detect the source change. A 404 or 410 response, or a suitable noindex directive on an accessible resource, provides that signal.
Bing also supports IndexNow notifications for changed or removed URLs. A notification can help participating engines discover a change. It does not create the change or guarantee removal. Google Search Console removal remains a separate process.
Fix the robots.txt and noindex conflict
Do not use robots.txt disallow as the only method for removing an indexed page. It controls crawler access, not search-index inclusion. A blocked URL may still appear in results if the engine learns about it elsewhere.
The conflict is easy to create. An SEO manager adds noindex to an unwanted page. Then, hoping to speed up removal, they block the same path in robots.txt. Googlebot may no longer fetch the page, so it cannot read the noindex rule.
Consider this crawl restriction:
``text
User-agent: *
Disallow: /old-campaign/
``
If pages in that folder depend on HTML noindex, the restriction may stop Google from discovering the instruction. The correct approach for a public page that should leave search is usually to allow the crawl and make noindex readable.
This does not mean every blocked page should be opened to the public. A private document calls for actual access control, not a temporary relaxation that could expose private data. Use an eligible search removal process to address its listing.
There is also no supported Google noindex directive placed inside robots.txt. Keep crawl controls and indexing controls separate. Check both before deciding why a removal has not worked.
Verify the removal instead of trusting a request receipt
A successful removal request proves that the request was accepted or processed at that stage. It does not always prove the file is secure or permanently absent from search. Check the server state first, then the search-engine state.
These are two different observations. Your server may return 410 today while Google still displays an old listing. Or Google may hide a result temporarily while the original page remains public. Neither case should be reported as a fully completed permanent removal without further checks.
Inspect the live response and the stored search status
Start with the exact URL, including its path, case, query string, and relevant alternate forms. Record the desired outcome. Then inspect what that URL actually returns.
For noindex, confirm that the tag or header exists and the crawler can reach it. For deletion, check the real HTTP 404 or 410 response. For private resources, test whether an unauthorized visitor can still retrieve the content.
A basic header check can help:
``bash
curl -I https://example.com/old-report.pdf
``
The command output may show a status code, redirect location, and robots header. Check the final response if redirects are involved. Do not treat the example URL as a real tested resource.
Next, inspect the URL in Search Console. Compare the last known indexed state with live inspection results. Google's crawl troubleshooting guidance helps explain why fetching, indexing, and reporting can happen at different times.
A single failed search query is weak proof. So is a site: search. Search results vary, and absence from one query does not confirm a full index change. Use the available property tools and source checks together.
If you need a broader technical path, the IndexNowFast guide to diagnosing an indexing problem covers crawl access, directives, and other possible causes.
Worked example: a PDF published by mistake
Consider a fictional company that uploads a staff report to a public URL. The document contains information meant only for employees. Weeks later, someone notices its listing in Google.
The company controls the server and has a verified Search Console property. Its first job is to stop public access, not to change a meta tag. The team removes the file or places it behind access controls. It also checks whether the same document exists at another public address.
Next, the team submits an eligible temporary removal request for the exposed Google URL. If the resource also appears in Bing, the team uses Bing's own tools. The team records the requested URL and the request status.
The final review has two parts. An unauthenticated request must no longer expose the report. Separately, the team checks whether each search engine still displays the URL. A pending result is tracked rather than called a failure or a success too early.
This is a hypothetical walkthrough, not a measured removal case. It shows why protecting the resource and updating the search result must be treated as separate jobs.
Diagnose accidental de-indexing without assuming a penalty
An unexpected loss of search visibility does not prove that Google penalized a website. First find out whether the URL was actually removed from the index or simply stopped ranking for a search query.
Start with the affected URLs in Search Console. Check the index status, the live page response, robots rules, noindex instructions, and canonical selection. Look for changes made shortly before the loss. A staging setting copied into a live template can affect many pages at once.
A website can also lose indexed pages for other reasons, including site policy issues. Google's guidance on sites removed from its index explains that legal, policy, and other causes may apply. Do not claim a manual action without evidence from the relevant reports or messages.
If the page was excluded by mistake, fix the cause before requesting a new crawl. Removing a noindex directive is useful only if the remaining page is accessible and otherwise eligible for indexing.
For status-specific diagnosis, use the Google Search Console not-indexed guide. It covers exclusion categories in more depth.
If the problem is broader, the guide to why Google isn't indexing your pages can help narrow the cause. Once the source is fixed, the existing URL submission guide explains the available discovery options. A request for indexing is not a guarantee of inclusion.
Frequently asked questions about URL removal
These answers address the issues that remain after the first technical change. A removal request may be accepted while the file remains public. A file may also be secure while its old search listing is still visible. The right next step depends on the outcome you need, who controls the content, and which search engine shows it. Use these distinctions when reviewing the answers below.
How long does it take Google to remove a page?
Google may hide an eligible URL through its removal tool within a day, but the result is not guaranteed. Durable removal depends on Google processing the page's changed status, access rule, or noindex directive. There is no fixed deadline that applies to every URL.
Can a noindex page still be opened directly?
Yes. Noindex tells supporting search engines not to include the resource in their indexes. It does not stop visits through a direct URL or link. Use real access controls when the content must remain private.
Does robots.txt remove an indexed URL?
Not reliably. A robots.txt disallow restricts crawling. The URL may still be known through links or other signals. Worse, the crawler may be unable to read noindex on the blocked page. Use the control that matches the intended result.
Can IndexNow permanently delete a Google result?
No. IndexNow is a way to notify participating search engines about URL changes. It is not a Google Search removal command. For Google, apply a lasting source-level change and use Search Console's removal tools when urgent hiding is needed.
What if I do not control the website containing the URL?
You cannot use another owner's verified Search Console property to remove their content. Contact the publisher where possible. For outdated results, personal information, or certain harmful content, Google provides separate request paths based on the case. Removing a search listing also does not delete the content from the publisher's site.
Can a removed URL appear in results again?
Yes, if it was only hidden through a temporary tool and remains accessible and indexable. Google's temporary removal normally lasts about six months. Bing has a different blocking period. A durable technical change helps prevent the old page from returning.
Is 410 always faster than 404?
Do not rely on a fixed speed advantage. Both responses can tell a search engine that the content is unavailable. Choose the status that reflects the resource's state, then let the engine process it. An urgent removal tool may help when visibility cannot wait.
How do I restore a page after accidental noindex?
Remove the unintended directive and any conflicting access rule. Confirm the page returns a suitable response and can be crawled. Then inspect the URL in Search Console. You can request indexing if the page is eligible, but Google still decides whether to include it.
Put the permanent change before the removal request
The most reliable way to handle URL removal is to decide what should happen to the content itself. Keep a public page with noindex when direct access is still useful. Return 404 or 410 for content that has truly gone. Secure private material before worrying about search listings.
Use Google or Bing removal tools when a visible result needs prompt attention. Then check both the source and the search engine. A request receipt, a vanished search snippet, and a secure or permanently excluded URL are not the same result.
For site owners and SEO teams, this simple split makes removal work easier to audit. It also avoids the biggest risk: declaring success while the unwanted content remains available.