Should you really avoid redirects to remove AMP pages from Google's index?

Why does Google emphasize 404 instead of a redirect?

When removing a standard page, the typical SEO reflex is to set up a 301 redirect to preserve link juice and user experience. However, with AMP, Google explicitly asks for a 404. This is because AMP pages are often duplicated: there is a non-AMP canonical version and its AMP copy. If you redirect the AMP version to the canonical one, Google may interpret this as a signal of duplication or a change in architecture rather than a definitive removal.

The engine needs a clear instruction: this URL no longer exists, period. The 404 allows Googlebot to unmistakably understand that the resource is dead and should be removed from the index. A redirect, even if well-intentioned, adds an extra layer of interpretation that can slow down or complicate the process.

How long does it take for Google to remove AMP pages from its index?

Google refers to “a certain amount of time,” a vague phrase that reflects the reality of crawling: the delay depends on how often Googlebot visits your site, your crawl budget, and the depth of the URLs concerned. For a highly authoritative site with daily crawling, it takes a few days to two weeks. For a less prioritized site, it might take several weeks to even a month.

In practice, AMP pages need to be re-crawled for Google to register the 404 and then enter a deindexing cycle. During this period, they may still appear in search results with an error message or gradually disappear. This is not instantaneous, and there is no magic button to force immediate mass removal.

What happens if we still redirect to the canonical version?

If you redirect AMP pages to their non-AMP equivalents, Google will follow the redirect and index the canonical version (if it hasn't already). The issue is that the old AMP URLs will remain in the index longer, as Google must first determine that the redirect is permanent before deciding whether the old URL should be removed or simply replaced with the new one. This ambiguity introduces conflicting signals.

Moreover, if you have backlinks pointing to the AMP URLs, the 301 redirect would theoretically transfer link juice. However, in optimal AMP practice, these backlinks are often rare or nonexistent (most come from the Google AMP cache, not third-party sites). Therefore, the SEO benefit of the 301 is marginal, while the risk of confusion and slow deindexing is real.

• The 404 is a clear removal instruction: Google immediately knows that the resource no longer exists.
• The 301 redirect introduces ambiguity: is it a permanent move or a disguised removal?
• The deindexing delay depends on crawl budget and how often Googlebot visits the concerned URLs.
• AMP pages rarely have external backlinks: the loss of juice through 404 is minimal in most cases.
• Google prioritizes signal clarity for AMP pages, whose architecture is already complex with canonical and variant versions.

Is this recommendation consistent with real-world observations?

Yes, generally. It has been observed that sites that return a 404 for their old AMP pages see these URLs disappear from the index more quickly than those that redirect to the canonicals. The difference can range from a few days to several weeks, depending on the site. Google has clearly optimized its deindexing pipeline to prioritize AMP 404s, which makes sense given the volume of AMP pages created and then abandoned in recent years.

However, caution: this rule applies for intentional removals. If you return 404s by mistake (server bug, misconfiguration), Google will interpret them as removals and you will lose your rankings. No tolerance for error here: a 404 is a 404, and Google does not guess your intentions. Ensure that it is indeed intended before deploying.

What nuances should be added to this Google guidance?

First point: if your AMP pages have quality backlinks (which is rare but possible for viral content or resources linked from third-party sites), the 301 redirect retains some of the link juice. In this specific case, you might consider a temporary redirect while Google stabilizes the index of the canonical version, then switch to a 404. But this is a niche case. [To be confirmed]: Google has never published numerical data on the loss of PageRank via 404 vs 301 in a specific AMP context.

Second nuance: if you are still actively using AMP for certain content (news, high-traffic mobile blogs), do not remove those pages. This guidance applies only to sites transitioning post-AMP that are abandoning the framework. And even then, first check that the non-AMP canonical version performs just as well in Core Web Vitals and mobile-first, or you may risk a drop in rankings.

In which cases does this rule not apply?

If your site maintains a hybrid architecture (some pages in AMP, others not), do not touch the active AMP pages. Google’s guidance targets sites that are completely abandoning AMP or have orphaned AMP pages (created by mistake, automatically generated without a canonical equivalent, etc.). In these situations, the 404 is the cleanest route.

Another exception: if you have a massive volume of AMP pages (tens of thousands) and your crawl budget is limited, a sudden switch to 404 could overwhelm Googlebot with errors. In this case, consider a gradual batch removal, monitoring the Search Console for spikes in errors and adjusting the pace. No Google tool allows for mass deindexing: you are entirely dependent on the crawler's good will.

What should you do to remove AMP pages concretely?

Start by identifying all the AMP URLs on your site. If they follow a predictable pattern (ex: /amp/ or ?amp=1), it's simple. If not, extract them from the Search Console (Coverage tab, filter for indexed URLs with "amp" in the path). Once listed, configure your server to return a clean 404 code, not a custom error page that returns a 200 with a "page not found" message (Google would interpret it as valid content).

Next, remove all rel=amphtml tags from your canonical pages. If you leave these tags pointing to 404 URLs, Google will crawl dead links at each visit, which clutters your crawl budget. Also, clean up your XML sitemap: remove AMP URLs or update the sitemap to include only canonical versions. A clean sitemap speeds up deindexing because it sends a clear signal about the structure of the site.

What mistakes to avoid during this transition?

Classic mistake: redirecting AMP to canonicals by SEO reflex. As mentioned, this slows down deindexing and creates confusion. Another trap: removing AMP pages without checking that the canonical versions are indexed and performing well. If you cut out AMP and the canonical version has not yet been crawled or has issues (loading times, mobile usability), you risk a temporary drop in visibility.

A third mistake: forgetting to monitor the Search Console after deployment. The 404s will generate errors in the Coverage tab, which is normal. But if you see spikes in 5xx errors or soft 404s (pages that return 200 but look like errors), it's a sign of a configuration problem. Also monitor the index evolution: run site:yoursite.com/amp/ in Google to check that the URLs are gradually disappearing.

How to verify that the removal is working correctly?

Use the URL inspection tool in the Search Console to test a few representative AMP URLs. If Google crawls them and registers the 404, that’s a good sign. Also check the coverage report: AMP URLs should change from “Indexed” to “Excluded” with the status “Not Found (404)”. This process may take several weeks, so be patient.

At the same time, monitor your Core Web Vitals and mobile traffic. If AMP represented a significant portion of your mobile impressions, the transition may temporarily impact your rankings. Ensure that your non-AMP canonical pages are optimized (LCP <2.5s, CLS <0.1, FID <100ms) to compensate. Without solid mobile performance, abandoning AMP can cost you visibility.

• List all the AMP URLs via Search Console or server log extraction
• Configure the server to return a true 404 code (not a soft 404)
• Remove all rel=amphtml tags from canonical pages
• Clean the XML sitemap to remove AMP URLs
• Monitor the coverage report in the Search Console for 4-6 weeks
• Check that non-AMP canonical versions are indexed and performing well before removal