On this page · 16 sections
- What changed on 1 July 2026
- What did not change
- Why 2027 is the decision year
- Keep, redirect or retire: the decision table
- Option 1: keep AMP, but run it as your own page
- Option 2: redirect AMP to the canonical page (the standard exit)
- Option 3: retire AMP through the CMS
- Canonical handling: the pairs Google expects
- Analytics after the switch
- Core Web Vitals: the gate before you redirect
- Top Stories, Discover and Web Stories without AMP
- Worked example: retiring paired AMP on a news site
- India and EU notes
- 2027 implementation checklist
- How eCorpIT can help
- References
Summary. On 1 July 2026 Google Search stopped sending users through its AMP viewer and AMP Cache and began taking them directly to the publisher's own AMP pages. Publishers no longer have to update the cache or set up signed exchanges, and AMP pages keep ranking as any other page does. Top Stories eligibility did not change: the AMP requirement ended with the page experience rollout in June 2021. What changed is who carries the load. Your server and CDN now deliver every AMP visit from Search, judged against the same Core Web Vitals targets as any page: Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint of 200 milliseconds or less and Cumulative Layout Shift of 0.1 or less, at the 75th percentile. The AMP framework still ships (latest stable release 26 August 2026), so nothing forces you off it. Our verdict for 2027: if you run paired AMP and non-AMP templates, retire AMP once the canonical template passes Core Web Vitals, using Google's documented route of removing rel=amphtml and redirecting each AMP URL to its canonical page. Keep AMP only where it is your canonical format or powers Web Stories.
About this article. This is for publishers, SEO leads and web engineers who still run AMP. On 1 November 2026 we checked it against Google's changelog and documentation, web.dev, amp.dev and the AMP GitHub repository, using press reports only where Google published nothing itself. Google can change Search behaviour without notice, so re-check before you migrate. The worked example uses assumed figures, the consent note is not legal advice, and no vendor paid for inclusion. Researched with AI assistance and reviewed by our editorial team.
What changed on 1 July 2026
Google's Search Central changelog says it took outdated references to the viewer, the AMP Cache and signed exchange out of its AMP documentation, because Search now sends users straight to the publisher's AMP host pages. A Google spokesperson told Search Engine Roundtable the change would cut maintenance for publishers, and the publication reported no effect on how AMP pages rank or are served in Search and Discover.
The table draws on the changelog, Google's 2020 note on cache-optimised AMP links, Search Engine Journal on the old viewer and Google's AMP guidelines.
| Item | Before 1 July 2026 | From 1 July 2026 |
|---|---|---|
| Where a Search click lands | Google's AMP viewer, showing a cached copy | Your own AMP URL on your host |
| AMP Cache updates | Publishers updated the cache when content changed | Not needed for Google Search |
| Signed exchanges | Configured so the browser could show your URL | Not needed for Google Search |
| Ranking | Same standards as other pages | Unchanged |
| URL in the browser | A Google URL in the viewer, or yours with signed exchanges | Your AMP URL, as on any web page |
| Who serves the bytes | Google's cache | Your origin and CDN |
Two consequences follow. First, searchers now see the AMP URL in the browser, so Google says amp.example.com/giraffes or example.com/amp/giraffes is fine, while an unrelated domain confuses people. Second, first-visit speed depends on your infrastructure. The changelog does not say whether Search still preloads AMP pages, and the AMP Project links safe pre-rendering to cache delivery, so plan as though your server's response time decides the first paint.
Google has not said the AMP Cache itself is switched off, and the AMP Project still lists Google and Bing as cache providers, with the linking platform choosing which to use.
Glenn Gabe posted on 2 July, via Search Engine Roundtable, that one AMP URL failed from the Google app while working in Chrome, and that it might be an anomaly. If you still serve AMP, test the click path from the Google app as well as mobile browsers.
What did not change
- Ranking. Google indexes AMP as it does other pages and applies the same standard whatever technology built the page.
- Validity rules. An AMP page must still follow the AMP HTML specification, be valid under the AMP Test and, where possible, offer the same content and actions as its canonical page.
- Canonical pairing. Google still requires an AMP page to link to a canonical page, which can be a non-AMP page or the AMP page itself.
- Structured data parity. Use the same markup on the AMP and canonical versions.
Why 2027 is the decision year
Many publishers carry AMP for one historical reason. Google began surfacing AMP pages in mobile results in February 2016, and, as Search Engine Land recorded, only AMP pages could then appear in mobile Top Stories, apart from a 2020 exception for some local COVID-19 coverage. It reported non-AMP listings in the carousel on 22 June 2021, after Google said in May 2020 that the carousel would open to any page.
The cache was AMP's other selling point: Google's infrastructure made even a slow origin look fast. Since July 2026 that advantage is gone for Search traffic. A site with paired templates still pays for two front ends, two sets of validation errors, two analytics configurations and two places for ads and consent to break, while Google's AMP page names no ranking benefit. That is the cost case for retiring AMP.
The risk case is a regression. If your canonical template is slower or less stable than your AMP template, a careless redirect can cost engagement and, because Google's ranking systems use Core Web Vitals, possibly some rankings. The decision turns on one measurement: does the canonical version of each template pass Core Web Vitals on mobile today?
Nothing forces a rushed move. The latest stable AMP release is 2608201643000 of 26 August 2026, commits reached the main branch as late as 19 October 2026, and the OpenJS Foundation lists AMP among its at-large projects.
Keep, redirect or retire: the decision table
| Your setup | Pick this | Why |
|---|---|---|
| Paired AMP and non-AMP; canonical passes Core Web Vitals at p75 | Redirect AMP to canonical | One template, no ranking benefit lost |
| Paired; canonical fails Core Web Vitals | Keep AMP for now and fix canonical first | Avoids a mobile speed regression |
| Canonical AMP (AMP is your only version) | Keep, or plan a full rebuild | No duplicate to remove; a rebuild is a site migration |
| Large Web Stories programme | Keep the AMP library for Stories | Web Stories must be valid AMP |
| CMS plugin generates AMP you never customised | Disable in the CMS and verify redirects | Lowest effort, but check the redirect target |
| AMP pages draw traffic from non-Google platforms | Keep until you measure that traffic | Google's change covers Google Search only |
Canonical passes means the non-AMP version of the template meets all three thresholds at the 75th percentile on mobile in field data, not in one lab run. If you rebuild a canonical AMP site, plan it with our replatforming guide.
Option 1: keep AMP, but run it as your own page
Treat it like any other template you host:
- Check hosting and caching. AMP visits from Search now hit your origin or CDN. Confirm cache headers, CDN coverage and Time to First Byte for AMP URLs.
- Validate monthly. Watch the AMP status report in Search Console and fix template-wide errors first. It shows a sample, capped at 1,000 URLs per issue, so keep your own inventory. Its help page still covers signed exchange issues; for Google Search, go by the changelog.
- Keep parity. Same main content, structured data, paywall and consent behaviour as the canonical page. If you adopt Google's UK page-level AI Overviews control, apply the same setting to the AMP variant.
- Keep sensible URLs. For paired pages Google recommends
https://www.example.com/myarticle/amporhttps://www.example.com/myarticle.amp.html.
- Retire cache plumbing. AMP Cache update requests and signed exchange certificates are no longer needed for Google Search. Before removing them, check whether any other platform you depend on still uses them.
Option 2: redirect AMP to the canonical page (the standard exit)
Google documents the procedure for paired setups:
- Remove the
rel=amphtmllink from each canonical non-AMP page.
- Configure the server to return
301 Moved Permanentlyor302 Foundfor the removed AMP URL.
- Point that redirect at the canonical non-AMP page.
- To remove the AMP page from other platforms too, Google describes returning
404, and suggests a301to the canonical page if you want to keep permalinks working.
Two warnings. Do not remove AMP by emptying the file: Google treats an empty document with no markup as invalid and keeps serving the oldest valid version it has. And prefer a permanent redirect. Google's removal guide accepts either, but its redirects guide explains that the indexing pipeline takes a 301 or 308 as a signal that the target should be canonical, and does not take a 302 that way.
Google's general site-move guidance adds two habits worth copying: avoid redirect chains, and keep redirects as long as possible, generally at least a year.
A minimal NGINX rule for the common /amp/ suffix pattern, using the return directive:
# Redirect /article-slug/amp/ (with or without trailing slash) to /article-slug/
location ~ ^/(?<slug>.+)/amp/?$ {
return 301 https://www.example.com/$slug/$is_args$args;
}
The Apache equivalent with mod_rewrite, which copies the query string to the target by default:
# .htaccess in the document root
RewriteEngine on
RewriteRule ^(.+)/amp/?$ /$1/ [R=301,L]
Change the pattern if your AMP URLs use a prefix or .amp.html. Test AMP URLs from every template type before shipping site-wide, and make sure each returns a single hop to the right canonical URL.
Option 3: retire AMP through the CMS
Google notes that disabling AMP in the CMS removes all AMP pages. On a CMS-hosted domain the CMS can redirect users to the canonical page afterwards, and Google says to contact the provider if it does not. Do not assume it does. After you switch the plugin off, request a sample of old AMP URLs and confirm each returns a 301 to the matching article, not a 404 or a redirect to the home page.
Canonical handling: the pairs Google expects
The AMP specification and Google's validation guide set out the link pairs, and the last column applies Google's removal steps. The last two rows are our advice.
| Element | Paired setup (keeping AMP) | After retirement |
|---|---|---|
| Canonical non-AMP page | rel=amphtml pointing to the AMP URL, plus self-referencing rel=canonical | Remove rel=amphtml; keep self-referencing canonical |
| AMP page | rel=canonical pointing to the non-AMP URL | URL returns 301 to the canonical page |
| Canonical AMP page | Self-referencing rel=canonical | Unchanged unless you rebuild |
| XML sitemaps | Canonical URLs | Canonical URLs only |
| Internal links, newsletters, apps | Point to canonical | Replace any hard-coded AMP links |
A redirect without removing rel=amphtml leaves the canonical page advertising an AMP alternate that now redirects back to it. Remove the tag in the same release as the redirect.
Analytics after the switch
- Sessions now start on your domain. A Search click opens your AMP URL directly rather than a Google-hosted copy, so we expect cookies and referrers to behave more like those on your other pages, though we found no Google guidance on this. The referrer mix and new-versus-returning split may shift around 1 July 2026. Mark the date in your reports before anyone reads it as a traffic change.
- Check what your AMP analytics sends. Google's Enhance AMP page still links its analytics advice to a URL that now lands on a notice that Universal Analytics ended on 1 July 2024. If your template followed that older guidance, confirm it reports to a current GA4 property. Google's tag setup guide says Tag Manager for AMP does not support Google Analytics, so you must add the AMP snippet by hand. The amp-analytics vendor list has separate
gtagand Tag Manager entries, so check which one your template uses.
- Watch pageview totals during migration. Pageviews should move to canonical URLs as redirects go live. Compare total article pageviews for a fortnight before and after each section. A sudden drop can mean the canonical template's analytics tag fires late or not at all.
Core Web Vitals: the gate before you redirect
The thresholds come from web.dev. The last column is our reading of AMP's design rules.
| Metric | Good threshold (p75) | AMP habit worth copying to canonical templates |
|---|---|---|
| Largest Contentful Paint | 2.5 seconds or less | Light pages and few render-blocking resources |
| Interaction to Next Paint | 200 milliseconds or less | Tight limits on custom JavaScript |
| Cumulative Layout Shift | 0.1 or less | Explicit dimensions for images, embeds and ad slots |
A page passes when it meets all three at the 75th percentile, segmented across mobile and desktop. INP replaced First Input Delay as a Core Web Vital on 12 March 2024. Google says its ranking systems use Core Web Vitals, and warns that good scores do not guarantee top positions.
Pull field data for the canonical version of your article template from Search Console's Core Web Vitals report or your own real-user monitoring. If it passes on mobile, the redirect should not cost users speed. If it fails, fix it first. AMP does not allow author-written JavaScript beyond its components and requires external resources to state their size in the HTML. Those habits help INP and CLS on any template, so carry them across before the switch.
Top Stories, Discover and Web Stories without AMP
Top Stories eligibility has not depended on AMP since 2021. Google said in April 2021 that any page meeting Google News policies could appear in the carousel, whatever its Core Web Vitals score or page experience status, having said in 2020 that page experience would become one ranking factor among many there. Google marks both posts as possibly outdated, but the July 2026 entry brings back no AMP advantage. Discover has no AMP condition: content is eligible if it is indexed and meets Discover's policies, with no special tags required.
For news publishers the practical levers are the same as for any page: policy compliance, including the clear dates and bylines Google News asks for, accurate structured data, and fast, stable templates.
Web Stories are the exception. They must be valid AMP and can appear as a result in Search and as a card in Discover, where Google says they are most likely to appear in the United States, India and Brazil. If Stories matter to your audience, retire paired article AMP and keep the AMP library for Stories alone.
Worked example: retiring paired AMP on a news site
All figures below are illustrative assumptions for planning, not measured results.
An Indian news site publishes 60,000 articles with paired templates. AMP URLs take 55% of its Google mobile clicks, about 1,00,000 clicks a month.
- Ongoing AMP cost. Engineers spend about 24 hours a month on AMP fixes, validation errors and ad or consent parity. At an assumed ₹2,500 an hour, that is 24 × ₹2,500 = ₹60,000 a month, or ₹7,20,000 a year.
- One-off retirement cost. Canonical template hardening for Core Web Vitals (60 hours), redirect rules and testing (30 hours), analytics checks (15 hours) and monitoring (15 hours) total 120 hours, or 120 × ₹2,500 = ₹3,00,000.
- Payback. ₹3,00,000 ÷ ₹60,000 = 5 months.
- Risk sizing. If a botched rollout lost 10% of the 1,00,000 AMP clicks for one month, that is 10,000 clicks. At an assumed ₹0.40 of ad revenue per click, the cost is ₹4,000. That is small next to the saving, but the loss compounds if it persists unnoticed.
So stage the rollout: redirect one section, compare four weeks of clicks against the prior period and an untouched section, then continue. The untouched section also stops you misreading a Google core update that lands mid-rollout. Run the same arithmetic with your own numbers, and raise the 60 hours if your canonical template fails Core Web Vitals by a wide margin.
India and EU notes
- India. For Search traffic on slower networks, Google's cache no longer does the delivery work; your origin and CDN do. Test canonical templates on mid-range Android phones with 4G throttling, not only on office Wi-Fi, before redirecting.
- Consent in the EU and India. If AMP pages use
amp-consent, which can block other AMP components based on the user's choice, the canonical template must enforce the same choices before analytics or ad tags fire. Treat consent parity as a launch blocker. For India, see our DPDP guide to GA4 and ad pixels.
2027 implementation checklist
- Inventory AMP URLs by template, separate paired from canonical AMP pages, and export 90 days of AMP clicks as a baseline.
- Pull mobile field data for each canonical template; fix any that fail LCP, INP or CLS at p75.
- Confirm AMP analytics reports to a current GA4 property, and mark 1 July 2026 in reports.
- Remove
rel=amphtmland ship 301 redirects one section at a time.
- Update internal links, sitemaps and hard-coded AMP links in newsletters and apps.
- Keep the AMP library only for Web Stories or canonical AMP pages.
- Watch indexed AMP pages trend down in the AMP status report while clicks hold steady for four weeks per section.
- Remove AMP Cache update jobs and signed exchange configuration once nothing else relies on them.
How eCorpIT can help
eCorpIT is a Gurugram-based technology organisation, founded in 2021, assessed at CMMI Level 5 and MSME certified, with senior-led engineering teams working across AWS, Microsoft and Google platforms. Our SEO and engineering teams run AMP exits as small, measured migrations, from Core Web Vitals template audits and redirect maps to GA4 checks and section-by-section rollouts. Talk to us at /contact-us/.
Last updated: 1 November 2026.