Google Buries the AMP Cache: How Vebs Lost Their google.com Loophole — and What Replaces It in 2026

For ten years AMP was two things at once. To some, a way to speed up mobile search results. To others, a quiet side door through which traffic slipped into locked GEOs under the clean white flag of google.com. In the summer of 2026, Google pulled the plug: the cache is off, and the google.com/amp wrapper is no longer served from the corporation's own servers.

For big publishers, this is an obituary for a technology they forgot about years ago. For iGaming vebs, it's the loss of a working tool with no direct equivalent — yet. Let's break down what actually broke, how much it hurts, and what can realistically take its place, without kidding ourselves.

Where AMP came from and why it mattered

Rewind to 2015. Mobile internet was noticeably slower than it is now: pages loaded sluggishly, and a good half of users closed the tab before the content ever appeared. Google offered a cure — Accelerated Mobile Pages. The idea was simple: stripped-down HTML with no heavy scripts, content served from Google's CDN, pages opening almost instantly.

For a while, AMP was effectively the entry ticket to Top Stories — the news block sitting right at the top of the results page. Without an AMP version, a publication simply dropped out of that block, so everyone who cared about news traffic churned out mobile pages. The technology went from "nice-to-have" to a condition of entry.

Did AMP actually pump traffic?

The early numbers looked convincing. WompMobile ran an analysis across roughly 9 million AMP pages on 26 domains: about 77% of sites saw organic mobile traffic grow, with an average lift of around 27%. Japan's Asahi Shimbun reported something even louder — +240% pageviews and +344% ad revenue.

But AMP was never a magic pill, and that part matters. Chartbeat's first serious study of the effect painted a sobering picture: only about one publisher in three got a lasting boost. The reason was economics — AMP pages held less advertising, and just to break even on money, a version had to make up roughly +23% in traffic on top. Only the strongest pages cleared that bar, a handful of percent of the whole.

The big players drew their conclusions first. Future plc, Vox, and BuzzFeed quietly began switching AMP off. And in 2021 Google itself dropped the AMP requirement for Top Stories and pulled the signature "lightning bolt" from results. Most publishers exhaled and forgot the technology like a bad dream. But one niche remained where AMP kept generating real money — iGaming.

Why the cache was gold specifically for affiliates

While the media were winding AMP down, vebs in regulated GEOs were building entire funnels on it. The logic was elegant to the point of being cheeky.

Picture a working domain blocked in Turkey or India. A user taps a link — and hits the ISP's block page. But google.com is blocked by almost no one: too expensive in collateral damage. That's exactly where the AMP page opened. The address looked like google.com/amp/s/yoursite.com, and from the ISP's point of view the user was visiting Google, not a banned casino.

Why this worked at all is worth explaining a little deeper, because it's the key to the whole story. In most GEOs, ISP blocking lives on two levels: DNS tampering and filtering by the SNI field in the TLS handshake. SNI is the domain name that, until recently, the browser sent in plaintext at the very start of a connection; it's what the filter reads to see where you're heading, even when everything else is encrypted. With the AMP cache, the connection technically went to Google's domain, the content was served from Google's edge — and the filter saw only google.com in the SNI. The banned domain never appeared in the clear on the wire.

For Android, this worked almost perfectly — and that's 60–80% of mobile traffic in most top GEOs. On top of that came a fat bonus: instant re-gluing. All you had to do was swap the URL inside the AMP wrapper — no redirects, no warming up fresh domains. A tool that saved vebs both money and nerves.

What exactly broke on July 1, 2026

Starting July 1, Google began gradually shutting down the cache-serving path. From the documentation changelog, mentions of the AMP viewer, AMP Cache, and signed exchanges disappeared — the whole apparatus that substituted the google.com address for the publisher's domain. Now a click on an AMP result leads straight to the AMP page hosted on the site's own domain, and the real URL is visible in the address bar.

An important nuance: AMP as a format hasn't gone anywhere. Pages are still indexed and rank alongside the rest of the web — what changes is delivery, not ranking. Google simply stopped serving these pages from its servers. In practice this finishes off a trend that had been running since 2021: first the Top Stories requirement was dropped, then Google News on mobile started sending traffic straight to domains, and now the same direct routing has reached ordinary Search. The era of working through is officially closed.

How much it hurts — a concrete example

To grasp the scale, just look at the traffic mix of a typical project living on this scheme. In post-mortems you'll find sites where AMP carried something like 80% of all traffic — roughly 113,000 clicks out of 143,000 over three months. For a project like that, killing the cache isn't a "dip," it's a slow death: the user hits the ISP block page again, conversions collapse, and the funnel stops feeding.

And you can't replace this with a single switch — that's the core of the problem.

Why there's no drop-in replacement

A direct analogue for the combo of "someone else's clean white google.com domain + instant re-gluing + free" simply doesn't exist today. Vebs who spent years bypassing geoblocks through Google's directory will have to accept the loss and rebuild their infrastructure.

PWA keeps surfacing across various sources as a "replacement," but that's a bait-and-switch. Web apps really do load fast on mobile — except speed was never the issue here; we never had a speed problem. We had a domain problem. A PWA doesn't hand you someone else's clean SNI, and that SNI was exactly what made the scheme work.

It's also worth remembering that some browsers had been chipping away at AMP long before Google. Brave learned to unwrap AMP links and take the user straight to the original domain back in 2022, and DuckDuckGo added AMP-tracking protection that same year. In other words, the audience browsing through those tools had been falling out of the scheme for several years already.

What can realistically be tried in 2026

There's no magic button, but there are directions the industry will keep digging into one way or another. Let's go through them honestly, without promises.

Your own edge cache. Cloudflare and other CDNs solve exactly the task AMP was originally built for: serve HTML from the edge nearest the user in tens of milliseconds. It's a good answer for speed and Core Web Vitals — but again, speed was never what we needed. It doesn't put someone else's domain in front of the ISP, and it doesn't defeat a geoblock.

ECH (Encrypted Client Hello) is the most interesting topic of 2026 and the closest spiritual heir to the google.com trick. ECH encrypts the very SNI that ISPs used to catch banned domains: what goes out is only a "cover" domain (often the shared domain of a CDN), while the real site name is hidden inside the encrypted part of the handshake. In spirit, this is exactly what the AMP cache did — just without Google as the middleman. But don't celebrate yet. First, ECH degrades "gracefully": if an ISP cuts the HTTPS/SVCB DNS records that deliver the ECH keys to the browser, the connection simply falls back to an ordinary handshake with SNI in plaintext — and there goes your cover. That's precisely how it gets jammed: Russia, for instance, started blocking the service domain cloudflare-ech.com itself. Second, the stars have to align on the user's side — ECH enabled, encrypted DNS (DoH/DoT), browser support. Third, self-hosted ECH is still raw as of 2026: in practice you're once again tied to a big CDN that manages the keys and records for you. ECH isn't "set it and forget it" — it's a fragile construct that depends on both infrastructure and on-device settings.

Domain fronting. The historical version of the same idea: the SNI points at one domain while the HTTP Host header points at another. This is how a blocked Signal once survived. The catch is that the major CDNs methodically shut fronting down on their end, so as a mass tool it's mostly dead.

App / WebView traffic. The logical answer to killing browser-level loopholes is to move the funnel into an app. An offer packed into an APK or WebView plays by different rules: a chunk of ISP filters tuned for browser traffic won't catch it as easily, and an installed app survives domain swaps almost painlessly. It's a direction iGaming has been drifting toward heavily over the past couple of years anyway.

Cloaking, mirrors, and domain rotation. The eternal cat-and-mouse hasn't gone anywhere. Fresh domains, server-side redirects, cloaking layers, reverse proxies on "trusted" infrastructure — all of it still works, but it demands constant upkeep and a budget for consumables. In effect it's a return to manual labor in the place where AMP handed you automation for free, for years.

None of these options reproduces the old combo in full. The realistic scenario for 2026 isn't "we found a new google.com" — it's "we assembled a stack of several tools for a specific GEO and keep patching it."

The real lesson: don't build a funnel on someone else's kill switch

Behind this story sits a conclusion bigger than one disabled cache. A scheme that brought in 80% of traffic rested entirely on infrastructure controlled by Google — infrastructure it could shut off at any moment, which it did, without asking anyone. That's a textbook single point of failure.

Google deprecates its own products with enviable regularity, and pinning your monetization to them means waking up one day at zero. Diversifying traffic sources and delivery methods stops being a pretty word from a deck and becomes a question of survival for the project. Anyone who already had app traffic, their own domains, and backup stacks running alongside AMP will barely notice the loss. Anyone sitting on a single pipe is counting losses.

The SEO angle: AMP isn't dead, Core Web Vitals now rule

A separate note for those working whiter. AMP pages aren't disappearing from the index and rank like ordinary content — Google stresses this explicitly. But now you compete on a level field, without the handicap of Google's edge. Which means speed on your own domain moves to the front: Core Web Vitals, clean CSS and JS delivery, edge caching, light images.

If a project lived on AMP only for Top Stories and the wrapper, now's the time to soberly decide whether those pages are needed at all. Many take the simple route: switch off the AMP versions and set 301 redirects from the old AMP URLs to the regular pages, keeping one codebase instead of two. For whitehat projects, that's a relief. For scheme traffic — sadly, not a way out.

Bottom line

For most publishers, killing the AMP cache changes precisely nothing — they'd long since forgotten the technology anyway. For vebs who built funnels on google.com, it's a painful hit: there's no drop-in replacement, and everything that exists works worse, costs more, and needs hands-on maintenance.

Those who want to stay in the game will have to accept the new reality and assemble their workaround from stacks — ECH where it holds, apps, cloaking, their own domains. There won't be a universal solution. What there will be is the thing this industry prizes above any loophole: the ability to adapt fast when the next switch gets flipped, no warning given.