Google Stops Serving AMP From Its Cache: What Actually Changes (And What You Should Do Now)
Google Search is no longer routing AMP clicks through Google’s AMP viewer/cache. Users now land on your domain’s AMP host page directly. Here’s why that matters for tracking, speed, control, ads, and SEO—and the practical plan to modernize without breaking revenue.
Google just made a quiet but meaningful change to how AMP traffic lands on your site: when someone taps an AMP result in Google Search, Google will now send them directly to your domain’s AMP host page—rather than loading a version served through Google’s AMP viewer/cache.
On paper, this sounds like a small implementation detail. In practice, it’s one more step in the long shift away from Google acting as the “middleman” for page delivery—and it changes the operational checklist for anyone still running AMP: tracking, consent, ads, performance, error Monitoring, and (most importantly) ownership of the user experience.
This editorial unpacks what changed, why it matters to businesses (not just SEOs), what can break, and how to decide whether to keep AMP at all. I’ll also explain how an execution system like AYSA fits into the reality that the hardest part isn’t understanding Google updates—it’s safely implementing the right changes across templates and pages.
Concise summary (for busy operators)
- What changed: Google Search is no longer serving AMP clicks from Google’s AMP cache/viewer. Clicks now go to your domain’s AMP URL directly.
- What didn’t change: Google says AMP pages rank like any other web page. This is about delivery, not a Ranking boost or penalty.
- Why it matters: More control and cleaner URLs—but also more responsibility for speed, reliability, consent, analytics, and monetization.
- What to do: Audit your AMP setup (canonicals, Structured data, ads, analytics, consent), verify tracking and performance, and decide whether AMP is still worth maintaining.
Table of contents
- What Google changed: from AMP viewer/cached delivery to your domain
- Why this matters now: control, trust, measurement, and performance
- How we got here: the slow unwind of AMP as a special program
- Does AMP still matter for rankings?
- Who benefits most—and who feels the pain
- The hidden risks: what can break when Google stops being the middleman
- Keep AMP, retire AMP, or rebuild: a decision framework
- Technical checklist: what to verify in the next 30 days
- Concrete SME scenario: a local clinic and an appointment funnel
- Agency ops: what to change in SOPs and reporting
- Where AYSA fits: monitoring + approved execution (not more dashboards)
- What to do next (action list)
- Sources and further reading
What Google changed: from AMP viewer/cached delivery to your domain
Historically, AMP (Accelerated Mobile Pages) was not just “a fast page format.” It was also a distribution mechanism. When a user clicked an AMP result, Google often served the page through Google’s own infrastructure:
- The content could be served from the Google AMP Cache.
- The user experience might appear inside the AMP viewer, with a Google URL in the address bar.
- Some publishers used signed exchanges to show the publisher’s URL while still using Google’s cached delivery path.
According to reporting from Search Engine Journal, Google has now ended that cached viewer/caching serving path in Google Search. As of July 1, clicking an AMP result routes users directly to the site’s own AMP host page, and Google removed references to the AMP viewer, AMP Cache, and signed exchanges from its AMP documentation.
Primary impact: the URL visible to users is your AMP URL on your domain when they click from Search. The user is no longer “inside Google” for the click experience.
This matters because the delivery path influences:
- Who controls performance and caching behavior
- How analytics sessions start and attribute
- How consent and scripts execute
- How ads and paywalls behave
- What the user perceives as the “source” of the content
Why this matters now: control, trust, measurement, and performance
If you run a business site (not just a publishing operation), the core question is simple:
When Google stops being the delivery layer, are your pages and systems ready to receive that traffic cleanly?
1) You regain URL and brand control—without special plumbing
In the AMP era, it was common for users to see a Google URL (or at least a Google-influenced experience) when opening an AMP result. This caused brand friction:
- Users copy/paste a Google URL instead of your URL
- Some users distrust “not really your site” experiences
- Sharing behavior and bookmarking can get weird
Direct-to-domain is simpler: the user lands on your page, on your origin, on your URL.
2) Analytics and attribution should get cleaner—but only if your setup is sane
When a platform changes routing, analytics is where confusion shows up first. The biggest winners here are organizations that already have:
- Consistent tracking across AMP and non-AMP templates
- Clear canonical relationships (AMP alternate + canonical)
- Server-side stability and predictable redirects
The biggest losers are sites that relied (knowingly or not) on Google’s cache behavior to paper over origin problems—slow servers, flaky CDNs, fragile consent flows, and heavy scripts.
3) Performance responsibility shifts further back to you
AMP’s promise was speed. But speed isn’t a checkbox; it’s an operating system:
- Image optimization
- Cache headers
- Edge/CDN configuration
- JavaScript discipline
- Template governance (not “one plugin per request”)
With direct routing, performance becomes more directly tied to your infrastructure and your release process. The more your business depends on Organic traffic and mobile conversion, the more this matters.
How we got here: the slow unwind of AMP as a special program
This update didn’t come out of nowhere. Google has been gradually de-emphasizing AMP as a privileged track in Search for years.
Search Engine Journal’s reporting notes key milestones that signaled the direction:
- Google dropped AMP as a requirement for Top Stories (starting in 2021)
- Google retired the AMP lightning-bolt icon from results
- Google News on mobile began sending traffic directly to domains, bypassing AMP URLs in some cases
Stepping back, Google’s mobile search evolution has been consistent: reward the experience, not the implementation. If your pages are fast, stable, and usable, you can compete—whether you built them with AMP, a modern framework, or a well-optimized CMS theme.
So the most useful way to interpret this change is:
- AMP is no longer a “special delivery program” inside Google Search.
- AMP is now just a page format hosted by you.
Does AMP still matter for rankings?
Google’s message (as relayed in the SEJ report) is direct: AMP pages will continue to rank like any other web page. That’s an important line because it reframes how to think about AMP:
- Not as an SEO cheat code
- Not as a requirement for visibility
- Not as a “must-have to get into feature X”
Instead, AMP becomes a normal technical decision—similar to deciding whether to run separate mobile templates, whether to use SSR vs. CSR, whether to adopt a new CMS, or whether to consolidate duplicate URLs.
My opinion: if you still maintain AMP primarily because “Google likes it,” you’re operating on outdated incentives. The modern incentive is measurable business outcomes: conversion rate, lead quality, revenue per visit, and operational cost of ownership.
Who benefits most—and who feels the pain
Not every site will feel this change equally. Here’s the practical segmentation.
Publishers with large AMP footprints
Publishers often built parallel content pipelines: one for canonical pages and one for AMP. Direct-to-domain can be a win if:
- You want the user to land on your brand URL consistently
- Your paywall/subscription logic works better on your origin
- Your ad stack is more predictable without viewer constraints
But it can also expose issues you didn’t have to solve when caching was in the middle: origin latency, capacity spikes, and inconsistent JS behavior.
Ecommerce sites that still have AMP product pages
Ecommerce AMP is often a relic of a particular era: “make product pages fast on mobile.” But ecommerce today is about:
- Variant selection, add-to-cart reliability, and checkout UX
- Trust elements and returns/shipping clarity
- Personalization, inventory messaging, and promotions
If your AMP template is a stripped-down version that doesn’t match the canonical experience, you may have been quietly leaking revenue. Direct-to-domain doesn’t fix that; it makes it more visible and easier to attribute.
Local and SMB sites using AMP via plugins (often unknowingly)
Many small businesses “have AMP” because a plugin or theme created AMP versions automatically. These sites may not even monitor AMP URLs in Search Console. This change is a good forcing function to audit:
- Whether AMP URLs are indexed
- Whether they include the right conversion actions (calls, forms, bookings)
- Whether they’re duplicating content and diluting internal signals
Organizations with strict compliance/consent needs
Healthcare clinics, financial services, and any business operating in regulated environments should pay close attention. When the user lands directly on your origin, your consent and compliance stack becomes the first line of defense—not a platform viewer. That’s good for control, but risky if your consent logic is brittle.
The hidden risks: what can break when Google stops being the middleman
From a technical SEO standpoint, this is where the real work is. A routing change can surface problems you’ve had for years.
1) Canonical/AMP pairing mistakes become more expensive
AMP setups typically rely on correct relationships:
- Canonical page references AMP via
rel="amphtml" - AMP page references canonical via
rel="canonical"
If these are wrong, you can create indexation confusion, duplicate URLs, or inconsistent rich result eligibility. Even if rankings don’t “tank,” you can end up with unpredictable landing pages and inconsistent measurement.
2) Redirect chains, geo-routing, and app interstitials
When Google’s cache was in the path, some redirect and routing behaviors didn’t manifest the same way for users. Now, direct-to-domain means your full routing stack executes in real time:
- HTTP → HTTPS redirects
- Trailing slash normalization
- Locale detection and country redirects
- “Open in app” banners/interstitials
If AMP URLs route differently than canonicals, you can accidentally degrade UX and conversion.
3) Ad delivery and viewability assumptions
Publishers and ad-supported sites need to re-check:
- Whether ad scripts load as expected on origin-hosted AMP
- Whether consent gating affects fill rate
- Whether measurement tags fire consistently
Even if the code didn’t change, the environment did. Expect edge cases.
4) Consent, privacy, and script governance
This update increases the importance of consistent, testable consent behavior on AMP pages. If your AMP template has different script execution rules than your canonical template, you can create:
- Analytics discrepancies (sessions/events not firing)
- Broken conversion tracking
- Non-compliant script loads (depending on your region and policy)
I’m deliberately avoiding jurisdiction-specific legal claims here, because compliance depends on context. The operational takeaway is universal: treat AMP as a first-class template in your consent and tag governance.
5) Origin performance under newsy or viral spikes
If you’re a publisher or have content that can spike, Google cache delivery could soften load. With more direct routing, you may see origin pressure. That’s not inherently bad—it’s “real traffic”—but it requires:
- CDN and caching strategy
- Server capacity planning
- Alerting and monitoring that notices regressions quickly
If your business relies on organic traffic, monitoring isn’t optional; it’s the insurance policy.
Keep AMP, retire AMP, or rebuild: a decision framework
Most teams need a decision framework that’s not ideological. Here’s the one I recommend.
Option A: Keep AMP (but treat it as a product, not a checkbox)
Keep AMP if all of these are true:
- AMP pages drive meaningful organic sessions
- AMP pages convert (leads, purchases, bookings) at an acceptable rate
- You can maintain AMP without constantly breaking parity with canonical pages
- Your engineering/content team can support two templates sustainably
Keeping AMP is defensible when it’s part of a disciplined publishing stack and when the business outcomes are there.
Option B: Retire AMP (and consolidate signals to canonicals)
Retire AMP if you see these patterns:
- AMP pages are thin/stripped-down and hurt conversion
- AMP pages create duplicated content and operational overhead
- Your canonical mobile experience is already fast and stable
- You can’t reliably QA AMP changes (plugins, patchwork customizations)
Retiring AMP should be done carefully—redirect strategy, internal linking updates, sitemap updates, and validation. This is where controlled execution matters more than “SEO knowledge.”
Option C: Rebuild the experience (modern performance without AMP)
If you originally adopted AMP for speed, your real requirement isn’t AMP—it’s fast, reliable mobile pages. Modern approaches include:
- Optimizing your existing CMS templates
- Reducing JS payload and third-party script bloat
- Better image formats and lazy loading
- CDN and caching improvements
The key is to choose an approach your organization can maintain. “Fast once” is not a strategy; fast continuously is.
Technical checklist: what to verify in the next 30 days
Below is a practical checklist aimed at SMEs and lean teams. You don’t need to do all of it in a day. You do need to turn it into a tracked project with owners and a rollback plan.
1) Inventory: do you still have indexed AMP URLs?
- Identify AMP URL patterns (often
/amp/or?amp). - Check whether AMP pages are still appearing as landing pages from Google Search in your analytics.
- Confirm whether AMP URLs are listed in sitemaps or generated dynamically.
If you’re unsure where to start, a monitoring-first approach is safer than guessing. AYSA’s Monitoring is designed for exactly this kind of “what is Google actually indexing and sending traffic to?” reality.
2) Validate canonical relationships and indexation intent
- Canonical pages should correctly reference AMP alternates (if you keep AMP).
- AMP pages should declare the correct canonical.
- Decide explicitly: do you want AMP indexed, or do you want canonicals to win?
3) Check structured data parity
If your canonical page includes structured data for products, articles, FAQs, or local business entities, confirm your AMP templates don’t lag behind.
Parity matters because rich-result eligibility depends on what Google can parse from the page it evaluates. If AMP is the URL Google chooses to show users, parity is not optional.
4) Confirm conversion actions exist and work on AMP
- Forms submit successfully
- Click-to-call buttons work
- Booking widgets render properly
- Add-to-cart/checkout pathways (for ecommerce) function end-to-end
5) Audit consent + tags on AMP templates
- Confirm analytics tags fire consistently (pageview + key events)
- Confirm your consent logic behaves as intended on AMP
- Ensure marketing pixels aren’t silently broken (or silently over-firing)
6) Performance and stability check
- Test real-device performance on representative pages
- Validate caching headers and CDN behavior
- Watch for template bloat: extra fonts, extra scripts, heavy media
7) Decide whether signed exchanges and cache-specific configurations are still relevant
Per the SEJ report, Google removed references to signed exchanges and the cache viewer path from AMP documentation. If you maintained complex configuration primarily to influence how URLs displayed in Google’s viewer, reassess whether it’s still needed.
Practical guidance: reduce complexity when it no longer produces measurable outcomes. Fewer moving parts means fewer outages.
Concrete SME scenario: a local clinic and an appointment funnel
Let’s make this real with a scenario I’ve seen versions of many times.
Business: a multi-location dental clinic group running WordPress. Their agency enabled an AMP plugin years ago to “help mobile speed.” They rank well for informational pages like “tooth pain when biting” and “wisdom tooth recovery,” and those pages feed appointments.
Reality:
- The AMP pages are indexed and receive a portion of organic visits.
- The AMP template is missing key conversion elements (location selector, insurance messaging, appointment CTA).
- Analytics events for phone calls are inconsistent on AMP.
What changes with direct-to-domain routing:
- The clinic now gets traffic landing directly on their AMP URL—meaning their server, their scripts, and their conversion elements determine success.
- Any consent or script issues now show up as “our site is broken,” not “Google viewer weirdness.”
- Attribution becomes easier to interpret, because sessions originate at the clinic’s domain instead of a platform-hosted experience.
Decision framework:
- If the clinic can quickly bring AMP templates to parity (same CTAs, same trust elements, consistent tracking), keeping AMP may be fine.
- If parity is expensive and the canonical pages are already fast, retiring AMP and consolidating everything to canonicals may produce higher bookings and lower maintenance cost.
Where execution matters: a clinic can’t afford an SEO experiment that breaks appointment forms for two weeks. This is exactly the class of change that should be staged, monitored, approved, and then deployed with rollback.
Agency ops: what to change in SOPs and reporting
If you’re an agency or an in-house team managing multiple sites, treat this as an SOP update—not a one-off task.
1) Add “AMP landing page routing” to audits
Every technical audit should now include:
- Are AMP URLs still indexed?
- Are AMP URLs still receiving organic traffic?
- Do AMP URLs convert and track properly?
2) Update QA to include AMP parity (or AMP retirement plan)
When a client has AMP enabled, your QA checklist should explicitly include AMP templates—not just the canonical templates.
3) Report in business terms: revenue, leads, and operational cost
Most clients don’t care about “AMP viewer” semantics. They care about:
- Is mobile organic traffic converting?
- Are calls/forms/transactions tracked accurately?
- Are we paying extra dev/maintenance cost for something that doesn’t move the needle?
4) Expect questions from clients—and prepare a simple explanation
The simplest client explanation is: Google now sends users directly to your AMP page on your website instead of a Google-served version. Rankings aren’t the point. Reliability and measurement are.
Where AYSA fits: monitoring + approved execution (not more dashboards)
Google updates are constant. Most businesses don’t lose because they didn’t read the update. They lose because they:
- Don’t notice the change until revenue drops
- Don’t have a clean way to implement template-level fixes safely
- Get stuck between “marketing knows what to do” and “engineering can’t prioritize it”
AYSA is built for that gap: it monitors, prepares, asks for approval, and then executes accepted changes—so you don’t end up with strategy trapped in documents.
Monitoring that catches the real-world symptoms
If direct-to-domain AMP traffic exposes a problem, you’ll usually see symptoms first:
- Changes in landing page mix (AMP URLs rising or falling)
- Conversion rate shifts on mobile organic sessions
- Indexation anomalies (duplicates, unexpected URLs)
That’s why we start with Monitoring, not guesswork.
Execution that respects risk (approved changes)
Template and routing changes are high-risk: canonicals, redirects, internal links, and scripts affect thousands of pages at once. AYSA’s model is “prepare → approve → execute,” so businesses keep control without slowing down.
How to use AYSA for this specific change
- Use AI SEO tools to identify which URL variants are ranking and being used as landing pages.
- Use AI search visibility thinking to ensure your “best” version of the page is the one people land on (fast, converting, trustworthy).
- Turn findings into an execution plan and deploy changes with approval gates.
If you want more practical implementation notes, we publish ongoing playbooks on the AYSA blog, and you can align the scope to your team size using pricing options that fit SMEs through agencies.
What to do next (action list)
Here’s the straightforward plan I’d run over the next 2–4 weeks.
Week 1: Confirm reality
- Identify whether you have AMP URLs in production (patterns like
/amp/or?amp). - Check whether AMP URLs are receiving organic landing traffic.
- Pick 10 high-traffic pages and test them on mobile: load time, CTAs, forms, tracking.
Week 2: Decide your direction
- If AMP is converting and maintainable: keep, but fix parity gaps.
- If AMP is non-converting or costly: plan a retirement and consolidation to canonical pages.
- Document the intended landing page behavior (what URL should users see?).
Weeks 3–4: Implement with guardrails
- Stage changes, QA, then deploy.
- Monitor landing pages, conversion rate, and indexation for regressions.
- Create a lightweight SOP so you don’t repeat the same fire drill next quarter.
If you want a system to operationalize this instead of running it as a one-time project, start with Monitoring and then move into prepared changes via AYSA’s approved execution workflow.
Sources and further reading
- Search Engine Journal: Google Ends Cache-Served AMP Pages In Search (reporting on the July 2026 change)
- Search Engine Journal: Latest News (ongoing context on Google updates)
- Search Engine Journal: SEO coverage (broader background)
Note: The SEJ report references updates to Google’s AMP documentation (changelog and removed mentions). This editorial does not quote or reproduce Google’s documentation directly because it wasn’t provided in the supplied research context. If you manage a large AMP footprint, it’s worth having your team review the current official AMP docs and change logs directly.
Continue the AI search topic inside AYSA.
Use these pages to connect the article with AI SEO tools, AI visibility monitoring, AI Overviews and approved website execution.
Turn this topic into a website action plan.
Use these AYSA hubs to move from reading to technical fixes, AI visibility monitoring, research, glossary context and approval-first SEO execution.
