Google Stopped Sending Users to Its AMP Cache

The AMP documentation got shorter on 1 July 2026, and the deletions were the announcement. Google’s documentation changelog records that it “simplified our AMP documentation by removing outdated references to the AMP viewer, AMP Cache, and signed exchange”, and gives the reason in the same entry: “Starting today, Google Search is updating how it connects users to AMP pages, and will now take users directly to the publisher’s AMP host pages.” The AMP page itself now carries a last-updated date of 1 July 2026.

What left, and what remains

Three mechanisms went: the AMP viewer that wrapped your page in Google’s chrome, the AMP Cache that served a copy of it from Google’s infrastructure, and signed exchanges, the workaround that let a cached page display your own URL. Google’s stated benefit is reduced maintenance, since publishers no longer need to update the cache or configure signed exchanges. You can confirm the removals against the current AMP on Google Search documentation, which now covers rich result eligibility, Web Stories, the AMP HTML specification, URL scheme advice and validation, and nothing else.

One line in the surviving guidance has quietly changed meaning. Google advises hosting AMP at a sensible URL such as amp.example.com/giraffes because when users click a link to your AMP page from Search, the AMP URL is visible in the browser like any web page. Under the viewer it was not.

The ranking line, read precisely

The same changelog entry states that “AMP content will continue to rank just like any other web page”, and the documentation opens by saying Google Search indexes AMP pages just like other web pages and applies the same standard to all pages regardless of the technology used to build them. This is not a new position. What is new is that it can no longer be misread, because the cache that made AMP feel like a separate distribution channel is gone. AMP is now a page framework, assessed as a page.

Your origin carries what the cache used to

This is the part with a measurable consequence. A cached AMP page was served from Google’s infrastructure, frequently prefetched, and often painted before the user had finished tapping. Your AMP host pages are served by you. Time to first byte, connection setup and origin caching now belong to your stack on a template that was, for many publishers, the one page nobody had ever needed to optimise. If AMP is a meaningful share of your traffic, measure those templates before you assume nothing changed, starting with the work in LCP optimisation.

Keep it, retire it, or leave it alone

Three defensible positions exist, and the choice turns on why AMP is there in the first place:

• Keep it if you depend on a distribution channel that still requires valid AMP, which for most publishers means Web Stories or a partner feed.
• Leave it alone if the build is automated, cheap and stable. Nothing in the 1 July change forces removal, and a working AMP page is still an indexable page.
• Retire it if you are maintaining a parallel template, a second analytics implementation and a second set of structured data for a cache that no longer fronts anything.

The retirement sequence Google documents

If you retire, the removal guidance is specific and the order matters. Remove the rel="amphtml" link from the canonical non-AMP page. Configure the server to return an HTTP 301 or 302 for the removed AMP URL, and redirect it to the canonical non-AMP page. Do not empty the AMP file instead: documents that are empty and missing all markup are invalid, and when Google Search recognises an invalid document it continues serving the oldest valid version it has. Then watch the indexed AMP pages graph in the AMP status report for a falling trendline, which is the confirmation that the consolidation is being processed rather than assumed.

The redirect choice deserves a moment rather than a reflex, and the reasoning in getting migration redirects right applies directly. So does the canonical hygiene: a retired AMP URL that still self-canonicalises, or a canonical page still advertising an amphtml alternate, produces exactly the conflicting signals described in canonical tag mistakes. Google’s full documentation changelog is the place to check whether any of this has moved again.