AMP and SEO in 2026, what Google own documentation says about how AMP pages are judged and where the format still earns its keep

AMP pages get no ranking preference. Google own Search Central documentation, read on 22 October 2026, states it directly: 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 the page. So the reason to build AMP in 2026 is never ranking. It is speed on a weak connection, and for publishers it is the Web Stories format. If your site is already fast on a mid range phone, AMP is a maintenance cost with nothing on the other side of it.

Harvested against the India geo target on its own on 22 October 2026, seo amp draws 90 searches a month in India, and against the United Kingdom target on its own on the same day it draws 30 a month in the United Kingdom. Two countries, two readings, not added together.

What Google actually says, quoted

The sentence that settles the ranking question is worth quoting rather than summarising: "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 the page."

On appearance, the documentation says AMP pages can appear in Google Search as a rich result, just like other pages on the web, and that structured data helps Google understand the page. It also notes that adding structured data does not mean a page will appear as a rich result. Both statements are about pages generally, not about AMP specifically, which is the point.

The guidelines that still apply if you build AMP

Google lists requirements specific to AMP on Search, and these are the ones with practical consequences.

• The page must follow the AMP HTML specification and must be valid. An invalid AMP page is not a slightly worse AMP page. It stops being treated as one.
• Users must be able to experience the same content and complete the same actions on the AMP page as on the corresponding canonical page, where possible. A stripped AMP version missing the enquiry form fails this.
• The AMP URL scheme should make sense to the user. Google gives the example that a canonical page at a site slash giraffes should have its AMP at a subdomain or a path on the same site rather than on an unrelated domain, because the AMP URL is visible to the user in the browser.
• Structured data policies apply to AMP pages the same way they apply elsewhere.

The maintenance cost, stated plainly

Running AMP means running a second version of every page. That means a second template, a second place for an analytics change to be made, a second thing that breaks when the design changes, and a validity requirement that will fail silently the first time somebody embeds a widget that AMP does not permit. For a large publisher with a dedicated platform team this is routine. For a business site maintained by one person it is the kind of cost that goes unnoticed until the AMP version has been wrong for three months.

Where the format still earns its keep

• Web Stories. Google documentation names AMP pages as able to appear as Web Stories, and the Story format has its own placement surfaces. If you want to publish Stories, you are building AMP whether or not you think of it that way.
• Genuinely weak connections. For an audience on slow mobile data, a strict format that forbids blocking scripts produces a page that loads when the normal one does not. This is the honest case for AMP and it is a real one in several markets.
• Email. A separate specification, unrelated to Search, and worth knowing exists so you do not conflate the two when somebody says their platform supports AMP.

What to do instead, if the goal was speed

The goal most people actually have when they ask about AMP is a fast page, and that goal has a direct route now. Measure the three loading and stability metrics on your own templates, fix the worst one, and repeat. The three Core Web Vitals metrics, their thresholds and the fix for each failure gives the thresholds to work against, and the work transfers to every page on the site rather than to a parallel copy of it.

If instead you came here because somebody told you AMP was a technical requirement, it belongs in the wider ordering of technical work rather than at the top of it. The technical SEO checklist in the order that matters puts crawlability, indexation and templates ahead of any format decision, and that order is the right one.

How to decide, in four questions

1. Do you publish Web Stories or want to. If yes, build AMP for those and nothing else.
2. Is a meaningful share of your audience on slow mobile data. Check your own analytics by connection type and device rather than assuming.
3. Can your team keep a second template valid. If the honest answer is one person with other jobs, the answer is no.
4. Is your normal page already fast on a mid range phone. If it is, there is nothing left for AMP to give you.

If you already have AMP and want to remove it

Google documents a removal path, and the sequence that avoids losing anything is to make the canonical page carry everything the AMP version had first, then remove the AMP markup reference from the canonical page, then let the AMP URLs redirect to their canonical equivalents. Keep the redirects permanently, because old AMP URLs are linked from other people pages and from social shares you cannot edit.

Questions about AMP and search

Does AMP still help with Top Stories

Google current documentation frames AMP as indexed and judged like any other page, and the same standard applies to all pages regardless of the technology used to build them. Build the fast, valid, news worthy page and the format is not the deciding factor.

Will removing AMP cost me traffic

The traffic follows the canonical page if the canonical page carries the same content and the AMP URLs redirect to it. The work is in making sure the canonical version is genuinely as complete and as fast, which is the work AMP was standing in for.

Is an AMP page a duplicate of my normal page

Handled correctly it is a paired version, with the AMP page pointing at the canonical and the canonical declaring the AMP. Handled incorrectly it is two indexable copies of one page, which is the most common AMP implementation error.

Can an AMP page include my forms and tracking

Within the specification constraints, and this is where most implementations diverge from the canonical page. Google guideline is that users should be able to complete the same actions, so if a form cannot be made to work, that is an argument against having the AMP version rather than against the form.

Does AMP affect how an AI assistant reads my page

What matters there is whether the content is in the HTML the crawler receives, which is a property of your canonical page rather than of the format. A page whose body arrives in the first response is readable; one that assembles itself in the browser is not, whatever the technology.

The reader who never loads either version

Every argument above is about how fast a page renders for somebody who clicked a link. A growing share of the same questions get answered inside an assistant, where nothing renders at all: the answer is assembled from pages the assistant read and presented as a paragraph naming a company or two. Load time is irrelevant to that path and whether your body text is present in the served HTML is everything. At AI Knows Us we measure what the five assistants name and which pages they read to decide, dated each time, which is a different reading from any speed score and increasingly the one that moves revenue.