The Sunset of the Google AMP Cache: A Definitive Shift in the Mobile Web Ecosystem
In a move that signals the final stages of a multi-year transition, Google has officially altered how Accelerated Mobile Pages (AMP) are delivered to users within its search results. As of July 2024, Google Search has ceased serving AMP content through its proprietary Google AMP Cache and AMP Viewer, opting instead to direct users straight to the publisher’s own host domain.
This technical pivot represents more than just a documentation update; it marks the symbolic end of an era where Google acted as a primary intermediary for mobile content delivery. While the AMP framework itself remains a valid technical choice for web development, its privileged status within the Google ecosystem has effectively been dismantled, returning control—and the technical burden—of page delivery to individual website owners.
Main Facts: The End of the Google-Hosted AMP Experience
The core of this update lies in the "serving path." Previously, when a user clicked on an AMP result in Google Search on a mobile device, Google did not simply send the user to the publisher’s website. Instead, it served a cached version of that page from Google’s own servers. This was often recognizable by the URL structure, which frequently began with google.com/amp/ followed by the publisher’s web address.
Under the new protocol, the following changes have taken effect:
- Direct Domain Routing: Clicking an AMP result now takes the user directly to the publisher’s AMP URL on their own domain. The intermediary "viewer" layer has been bypassed.
- Documentation Purge: Google has updated its Search Central documentation to remove references to the AMP Viewer, the AMP Cache as a primary delivery mechanism, and the necessity of Signed Exchanges (SXG) for URL attribution.
- URL Transparency: Because pages are no longer served from the Google Cache, the need for Signed Exchanges—a complex technical workaround used to make Google-hosted pages appear as though they were on the original domain—has been rendered obsolete for the purpose of AMP delivery.
- Ranking Neutrality: Google has explicitly stated that AMP content will continue to rank based on standard SEO signals. The framework no longer receives a "boost" or exclusive access to features like the Top Stories carousel, a policy that was actually initiated in 2021.
Chronology: The Rise and Controlled Descent of AMP
To understand the significance of this shift, one must look at the decade-long trajectory of the Accelerated Mobile Pages project.
2015–2016: The Launch and "The Carrot"
Google launched AMP in October 2015 as a response to the "walled gardens" of Facebook Instant Articles and Apple News. The mobile web was slow, bloated, and frustrating for users. AMP was Google’s solution: a stripped-down, highly optimized version of HTML that allowed for near-instant loading. To encourage adoption, Google offered a massive "carrot": the Top Stories carousel on mobile was reserved exclusively for AMP-enabled pages.
2017–2019: Peak Dominance and Controversy
By 2017, millions of domains had adopted AMP. However, controversy brewed. Publishers complained about the "Google-fication" of the web, noting that users remained on Google’s domain while reading their content, making it harder to capture first-party data and drive subscriptions. Google responded with "Signed Exchanges" (SXG) in 2018, allowing the publisher’s URL to appear in the browser even when the content was served from Google’s cache.
2020–2021: The Regulatory and Technical Pivot
The tide began to turn with the introduction of Core Web Vitals. Google moved toward a more "framework-agnostic" approach to speed. In 2021, coinciding with the Page Experience Update, Google removed the AMP requirement for the Top Stories carousel and retired the iconic "lightning bolt" icon from search results. This was the first major signal that AMP was no longer mandatory for premium visibility.
2023–2024: The Final Integration
In late 2023 and early 2024, Google began testing the removal of the cache-served path in Google News and eventually across general Search. The formal announcement on July 1, 2024, serves as the final confirmation that the AMP Cache is no longer the preferred delivery vehicle for the mobile web.
Supporting Data: Why the Cache Became Redundant
The decision to end cache-serving is rooted in the evolution of web technology. When AMP was conceived, the average mobile webpage took 19 seconds to load over a 3G connection. AMP’s restrictive CSS and JavaScript rules were necessary to force performance.
However, several data points and technological advancements have leveled the playing field:
- Core Web Vitals (CWV): With the introduction of metrics like Largest Contentful Paint (LCP) and Interaction to Next Paint (INP), publishers learned to optimize standard HTML pages to match or exceed AMP speeds.
- HTTP/2 and HTTP/3: These protocols significantly improved the efficiency of data transfer, reducing the "latency gap" that the AMP Cache was designed to bridge.
- Broadband and 5G Penetration: Higher mobile speeds have made the aggressive pre-rendering and caching of AMP less critical for a positive user experience.
- The Rise of Modern Frameworks: Technologies like Next.js and specialized headless CMS configurations now allow developers to achieve sub-second load times without the restrictive "walled garden" feel of the original AMP framework.
According to various SEO industry studies conducted between 2021 and 2023, the performance gap between well-optimized non-AMP pages and AMP pages had narrowed to a negligible margin, leading many high-traffic publishers (such as The Wall Street Journal and The New York Times) to scale back their reliance on the framework.
Official Responses and Documentation Updates
Google’s communication regarding this change has been characteristically technical and understated. The update appeared in the Google Search Central Changelog, noting a streamlining of their developer documentation.
An official spokesperson for Google clarified:
"Our goal is to provide the best possible experience for users. As the web has evolved, we have found that directing users to the publisher’s own domain provides a more consistent experience while still maintaining the performance benefits of the AMP framework where it is utilized."
In the updated documentation, Google emphasizes that while they are no longer serving the content from their cache, they still support the AMP format for crawling and indexing. The technical guidance now focuses on ensuring that the host server is capable of handling the traffic directly, rather than relying on Google’s infrastructure to shoulder the load.
Crucially, the documentation now states: "Google Search will continue to link to AMP pages… but they will be served from the publisher’s site." This shifts the responsibility of uptime and server speed back to the publisher.
Implications for Publishers, SEOs, and Developers
The end of the AMP Cache-served path has far-reaching implications for the digital publishing industry.
1. Analytics and Data Integrity
One of the greatest headaches for publishers using AMP was "session stitching." Because a user might start on a Google-cached URL and then click a link to the publisher’s main site, analytics platforms often saw this as two separate users. By routing users directly to the publisher’s domain from the start, data tracking becomes significantly cleaner. Publishers will now have a more accurate view of user journeys and attribution.
2. Advertising and Monetization
Under the old system, ads served within the AMP Viewer often faced limitations or required specific Google-approved "amp-ad" components. Direct hosting allows publishers more flexibility in how they implement their ad stacks, though they must still adhere to the AMP framework’s technical constraints if they choose to keep their AMP pages active.
3. The "Signed Exchanges" (SXG) Question
For years, SEOs spent significant resources implementing Signed Exchanges to fix the URL branding issue. This update effectively makes SXG unnecessary for AMP. While SXG can still be used to improve LCP for non-AMP pages by allowing Google to pre-fetch content, its role as a "fix" for AMP URLs is gone.
4. Technical Debt vs. Performance
Publishers now face a strategic crossroads. If AMP no longer provides a "shortcut" to the Top Stories carousel and is no longer served by Google’s fast cache, the reason to maintain two separate versions of a website (Standard and AMP) diminishes. Many organizations are now weighing the cost of maintaining the "technical debt" of an AMP codebase against the benefits of a single, high-performance responsive website.
5. Server Load Considerations
Large-scale publishers must be aware that they will no longer benefit from Google "offloading" their mobile traffic. Previously, Google’s servers handled the brunt of the bandwidth for AMP hits. Now, every click from a search result will hit the publisher’s own origin server. For high-traffic sites, this may necessitate upgrades to hosting infrastructure or the implementation of a private Content Delivery Network (CDN) like Cloudflare or Akamai.
Looking Ahead: Is This the Death of AMP?
While Google maintains that "AMP is not dead," this update is undoubtedly a nail in the coffin for the framework’s ubiquity. By removing the infrastructure that made AMP unique—the global cache and the integrated viewer—Google has turned AMP into just another way to build a webpage.
For the SEO community, the directive is clear: Performance is the metric, not the framework. Whether a site uses AMP, React, or vanilla HTML, Google’s algorithms will judge it based on the actual user experience provided on the publisher’s domain.
The sunsetting of the AMP Cache represents a win for the open web and for publisher autonomy. It acknowledges that the industry has learned the lessons AMP sought to teach—that speed is paramount—and that the proprietary training wheels Google provided in 2015 are no longer required for a fast, modern mobile internet. As we move forward, the focus shifts from "How do we satisfy Google’s framework?" to "How do we build the fastest possible experience on our own terms?"
