Is it necessary to redirect your AMP URLs during a change?

Why does Google differentiate between AMP URLs and standard URLs?

The distinction lies in the very architecture of the AMP cache. Unlike standard URLs that depend on Google's traditional crawling, AMP pages are served from the Google cache (cdn.ampproject.org). This cache operates under a much more aggressive refresh logic.

When you change a standard URL without a 301 redirect, Google must rediscover the new page, understand that it replaces the old one, and transfer historical signals. This process generally takes several weeks, if not months, depending on the site's authority and crawl frequency. For AMP, the system detects and refreshes content in just a few days — hence this increased tolerance.

What does this few-day delay actually mean?

Mueller mentions a delay between discovery and update of just a few days. However, this does not mean that the transition is instantaneous. During this time, your old AMP URL will likely return a 404 error if you have removed it, which diminishes user experience.

Visitors coming from Search or Google Discover will encounter a broken page until the cache updates. This is tolerable for a blog with little AMP traffic, but far less so for a media outlet that generates thousands of daily clicks from Google surfaces. The risk is a temporary but measurable loss of traffic.

In what cases does this rule really apply?

This statement specifically concerns changes to AMP URLs made by the publisher — structural redesign, domain migration, slug modification. It does not apply to AMP validation errors, caching issues, or de-indexing for quality reasons.

It is also important to understand that even though Google refreshes quickly, other players in the AMP ecosystem (Twitter, LinkedIn, third-party aggregators) may not follow the same pace. Hence, you risk broken links in environments outside of Google if you do not redirect properly.

• The AMP cache refreshes automatically within a few days during a URL change, unlike standard crawling which takes weeks.
• Failing to redirect creates a temporary but real 404 window, impacting user experience and traffic.
• Google still recommends redirecting — signaling that this technical tolerance does not exempt good practices.
• Third-party platforms (social networks, aggregators) do not benefit from the same rapid refresh system.
• This rule only covers URL changes, not AMP validation or indexing issues.

Is this statement consistent with practical observations?

Yes, experience confirms that the AMP cache reacts much faster than a classic crawl. On AMP migrations I've supervised, new URLs indeed appeared in Google's cache within 48-96 hours without redirection. But — and this is a significant but — this speed does not offset collateral damage.

During these few days, old URLs generate 404s in the Search Console, users encounter errors, and most importantly you lose the benefit of continuity in signals. A 301 redirect instantly transfers authority and engagement metrics. Without it, even if Google quickly finds the new page, it treats it as a new entity — at least temporarily.

What risks does this tolerant approach pose?

The first risk is purely business-related: a few days of 404 errors on a high-traffic AMP site can result in thousands of lost sessions. For an ad-driven media outlet or e-commerce that generates revenue with each visit, this loss is tangible and measurable. [To verify] if Google really compensates for this delay by speeding up ranking transfer — no official data on that.

The second risk concerns user signals. Pages generating 404s for several days see their Core Web Vitals metrics degrade (since visitors immediately bounce), which can impact ranking even after the cache updates. And unlike a standard URL where you manage the redirect, with AMP you depend on Google's cache system's goodwill.

In what cases does this rule absolutely not apply?

This tolerance only works if Google can quickly discover the new URL via the AMP sitemap, RSS feed, or natural crawl. If your new structure is not properly flagged, the delay can extend considerably — and there, you lose the benefit of fast refresh.

It also does not apply to complex AMP domain migrations involving a change of host or CDN. In such cases, even with a fast cache, server-side redirections are needed to avoid DNS resolution conflicts and HTTPS errors. Let's be honest: forgoing redirects during an AMP migration remains a risky practice, even if Google can technically cope with it.

What should you do concretely when changing AMP URLs?

Even if Google tolerates the absence of redirects, set up 301 redirects server-side for all your modified AMP URLs. This is the only way to ensure a seamless transition for users and bots while preserving link equity and historical signals. Configure these redirects at the Apache, Nginx, or via your CDN.

Simultaneously, submit your updated AMP sitemap through Search Console immediately after the change. This accelerates the discovery of new URLs and reduces the latency window mentioned by Mueller. If you use an RSS feed for AMP, update it simultaneously. And especially, manually purge the AMP cache via Google's tool if you need an almost instant update.

What errors should you absolutely avoid?

Do not rely on technical tolerance to neglect post-migration monitoring. Many sites change their AMP URLs, notice that Google does indeed find them in a few days, and conclude that everything is fine — when in fact, their AMP traffic metrics have dropped by 20-30% during this period. This loss is not always recovered afterwards.

Avoid also treating AMP and non-AMP differently during a migration. If you redirect your standard URLs but not the AMP ones under the pretext that "Google refreshes quickly", you create a structural inconsistency that complicates analytical tracking and may generate conflicting signals for algorithms. Standardize your approach: a URL that changes must be redirected, period.

How can you verify that the transition went well?

Monitor your server logs and the AMP Search Console for 7 days following the change. You should see a gradual decline in requests to the old URLs (if you redirected) or temporary 404s (if you did not redirect). In any case, the new URLs should appear in the coverage report within 72 hours.

Manually test the AMP cache by visiting https:\/\/cdn.ampproject.org\/c\/s\/yoursite.com\/new-url to verify that the cached version corresponds to your new page. If not, after 96 hours, there is a discovery or validation issue that needs investigation. And of course, compare your AMP traffic week by week to detect any prolonged anomalies.

• Set up 301 redirects for all modified AMP URLs, even if Google tolerates their absence.
• Submit the updated AMP sitemap immediately through Search Console.
• Manually purge the AMP cache for critical URLs via Google's tool.
• Monitor server logs and the AMP Search Console report for at least 7 days.
• Manually verify the AMP cache (cdn.ampproject.org) to confirm the update.
• Compare AMP traffic metrics before/after to detect any abnormal loss.
  If Google tolerates the absence of redirection for AMP URLs due to its fast cache, this does not mean it is the best practice. Redirections remain essential to avoid temporary traffic losses, preserve historical signals, and ensure a consistent user experience. These AMP optimizations, coupled with a solid technical migration strategy, can quickly become complex to orchestrate alone — especially during large-scale redesigns. Engaging a specialized SEO agency allows you to benefit from personalized support that anticipates these risks and secures each step of the process.