Ist Google AMP 2026 tot? (Und was man stattdessen nutzt)

AMP ist 2026 kein Ranking-Hebel mehr. Google hat die Pflicht für Top Stories im Juni 2021 gestrichen. Core Web Vitals im Feld (LCP 2,5 s, INP 200 ms, CLS 0,1) haben den Blitz ersetzt. Das Plugin deinstallieren, /amp/ und ?amp=1 per 301 auf die Canonical der eigenen Origin legen, den Rest in der Search Console aufräumen.

Der Blitz in den Suchergebnissen war nie Ihre Seite. Es war eine Kopie auf cdn.ampproject.org, vorgerendert in Googles Viewer, mit einem CSS-Budget und ohne eigenes JavaScript. 2016 hat das überladene Mobilseiten bestraft, die ohne AMP in Discover und Top Stories nicht vorkamen. 2026 zählt dieselbe Canonical, die Ihr Theme ausliefert. Wer AMP noch fährt, pflegt zwei Templates für ein Signal, das Google nicht mehr vergibt.

Dieser Leitfaden ist das Post-Mortem plus die Ausbauanleitung. Zuerst die Lage 2026. Dann, warum das Format scheiterte. Dann der Teil, den DACH-Redaktionen in der Search Console noch vorfinden: Cache-URLs, Validator-Reste, Origin gegen Viewer. Danach das Entfernen ohne Ranking-Loch, der Stack, der AMP ersetzt, und die Entscheidungstabelle.

#Ist AMP 2026 noch relevant

Nein. Für ein neues WordPress-Projekt 2026 ist AMP kein Thema. Google hat die AMP-Pflicht für das mobile Top-Stories-Karussell im Juni 2021 abgeschafft. Jede URL, die die Core-Web-Vitals-Schwellen im Feld hält, kann in Top Stories und Discover stehen. Der Blitz ist kein bevorzugtes Signal mehr.

Google sagt weiterhin, AMP sei „supported“. Das heißt: der Cache antwortet noch, der Validator läuft noch, alte Dokumente bleiben im Index, bis sie 301 bekommen oder veralten. Empfohlen oder Voraussetzung für ein Suchfeature ist AMP nicht. Seit Core Web Vitals das Page-Experience-Signal tragen, ist in das Format kaum noch Feature-Arbeit geflossen. Wer 2026 ein Release-Log des offiziellen AMP-Plugins auf WordPress.org aufmacht, sieht Inventar, keine Adoption.

Zwei Lesergruppen, eine Antwort:

• Neues Projekt. AMP nicht installieren. Kein rel="amphtml", kein /amp/-Endpunkt, kein amp-boilerplate im Theme. Performance über Origin, Cache und Bilder, nicht über eine zweite HTML-Teilmenge.
• Bestand mit Plugin. Die einzige offene Frage ist der Ausbau. Unten steht die Reihenfolge. Wer AMP abschaltet, bevor die Canonical im Feld grün ist, tauscht eine schnelle, eingeschränkte Kopie gegen eine langsame, freie Seite. Die Reihenfolge ist der ganze Job.

Was AMP 2026 nicht mehr ist: ein Ranking-Bonus, ein Discover-Ticket, ein Ersatz für Hosting, ein Grund, Formulare und Checkout auf eine Zweitvorlage zu verbannen. Was es noch ist: technische Schuld. Zwei Renderings, zwei Consent-Pfade, zwei Messungen, Cache-URLs in der Search Console, die nicht Ihre Canonical sind.

Gmail rendert weiter dynamische AMP-Mails. RSVP, Formular, Katalog im Posteingang, ohne die Website zu öffnen. Das Produkt heißt AMP for Email. Es teilt den Namen, nicht die Runtime, nicht die URL, nicht den WordPress-Stack. Eine Marketing-Gruppe, die interaktive Mails testet, ist kein Argument, das AMP-Plugin im Theme zu lassen.

#Warum AMP scheiterte

Das Ziel 2015 war echt. Mobilseiten waren voll mit Sync-Scripts, Page-Buildern und Ad-Stacks, die den ersten Paint in den Keller drückten. Google antwortete nicht mit einem Neutral-Maß, sondern mit einem Format, das eigenes JavaScript verbot, CSS deckelte und die fertige Seite auf Googles CDN kopierte. Die Seite fühlte sich schnell an, weil die Bytes schon auf dem Google-Edge lagen und im Suchergebnis vorgerendert waren. Das Format allein war nie der Trick. Der Trick war Prefetch plus fremde Infrastruktur.

#Was AMP technisch war

AMP war kein eigenes Sprache. Es war ein beschnittenes HTML-Profil mit drei beweglichen Teilen.

AMP HTML. Eine kuratierte Tag-Liste. Eigenes <script> war verboten. <img> wurde <amp-img>, Iframes <amp-iframe>, Tracking <amp-analytics>, Karussells <amp-carousel>. Dynamik lief deklarativ über <amp-bind> und <amp-list>, nicht über Ihren Code. Inline-CSS war erlaubt, aber hart begrenzt. Die ursprüngliche Spec lag bei 50 KB, später bei 75 KB. Externe Stylesheets waren verboten. Wer 75 KB als „50 KB“ in einem alten Runbook stehen hat, arbeitet mit der ersten Spec. Der aktuelle Deckel ist 75 KB, und er bleibt ein Deckel.

Die Runtime v0.js. Jede AMP-Seite lud eine von Google gehostete Bibliothek. Sie steuerte Ressourcen, maß jedes Element vor dem Paint (deshalb das niedrige CLS) und lud unterhalb der Falte nach. Vorhersagbarkeit war das Verkaufsargument. Die Runtime gehörte nicht Ihnen.

Der AMP-Cache und das Preload. Google kopierte gültige AMP-Dokumente nach cdn.ampproject.org und zeigte sie oft im Viewer unter google.com/amp/.... Tippen in den Suchergebnissen öffnete eine Seite, die schon teilweise gemalt war. Die Adresszeile gehörte Google, nicht der Redaktion. Marke, Teilen, Canonical-Verständnis, alles brach an dieser Stelle.

#Marke, Formulare, zwei Templates

Die Kosten lagen nicht in der Spec, sie lagen im Betrieb.

1. Marke. Nutzer sahen google.com/amp/ihre-domain.de oder eine Cache-Host-Variante wie www-example-de.cdn.ampproject.org. Kopierte Links zeigten auf Google. Teilen aus der AMP-Ansicht landete oft auf der Cache-URL. Wiedererkennung und Direct-Type-in litten, ohne dass die Redaktion das im Theme „fixen“ konnte.
2. Formulare und Checkout. Das JS-Verbot, das den Paint ruhig hielt, machte die Seite starr. Mehrstufige Opt-ins, dynamische Preise, Terminbuchung, WooCommerce-Add-to-cart mit Mini-Cart: entweder tot oder als brüchige AMP-Komponente nachgebaut. Für ein reines Nachrichtentemplate war das erträglich. Für alles mit Trichter war es Umsatzsteuer auf die Session.
3. Zwei Renderings. Canonical für Menschen, die die Domain kannten. AMP für Google. Zwei Codepfade, zwei Bugs, zwei QA-Läufe pro Teaser-Änderung. Ein Child-Theme mit AMP-Templates neben einem Block-Theme auf der Canonical ist kein Performance-Stack. Es ist ein zweites Produkt.

Ein DACH-Fall aus der Praxis, ohne Prozenttheater: ein regionaler Nachrichtenauftritt mit AMP auf Artikel-URLs und Canonical auf Ressort-Homes. Matomo zählte auf der eigenen Origin. amp-analytics lieferte Hits auf Cache-Hosts. Jedes Quartal lagen zwei Session-Zahlen auf dem Tisch, und niemand konnte die Kampagne schließen, weil die Stichprobe nicht dieselbe URL war. AMP weg, eine Canonical, ein Zähler. Die Redaktion hat nicht „Traffic verloren“. Sie hat aufgehört, zwei Welten zu vergleichen.

Zweiter Fall: ein WooCommerce-Katalog mit AMP auf Produktdetail, weil Discover dort klickte. Der Warenkorb war nicht AMP-fähig. Nutzer kamen auf die AMP-Produktseite, tippten auf Kaufen, landeten auf der Canonical mit anderem Layout, anderem Consent, anderem Referrer. Der Trichter hatte zwei Domains im Kopf des Nutzers, auch wenn die Canonical technisch eine war. Nach 301 und einem nativen Template stieg Add-to-cart, weil der Pfad eine Vorlage hatte, nicht weil ein Blitz verschwand.

#Signed Exchanges kamen zu spät

Google kannte den URL-Schaden. Die Antwort hieß Signed HTTP Exchanges (SXG), Teil von Web Packaging: der Cache sollte eine kryptografisch signierte Kopie ausliefern und trotzdem die Publisher-URL zeigen. SXG funktionierte in einem Chrome-Pfad. In der DACH-Mischung mit Firefox und Safari blieb die Unterstützung dünn. Als die Spezifikation alltagstauglich wirkte, hatten Redaktionen die Geduld schon verloren. Ein kryptografisches Pflaster auf der Adresszeile sagt, wie tief das Problem saß.

Dazu die Wahrnehmung, kein Gerichtsurteil: AMP sah mit der Zeit weniger nach offenem Speed-Standard aus und mehr nach Hebel. Wer den Cache kontrolliert, kontrolliert Prefetch, Ad-Formate und die URL, die der Nutzer sieht. Ob eine Klage das hält, ist hier egal. Publisher haben das Format verlassen, weil der Badge weg war und die Zweitpflege blieb.

#Core Web Vitals als Ersatz

2021 kamen Core Web Vitals als Page-Experience-Signal. Die Botschaft war nüchtern: uns ist egal, ob Sie AMP nutzen. Uns ist wichtig, dass die URL schnell ist.

Das war das Ende der Begründung. Eine normale, responsive Seite mit LCP unter 2,5 s im Feld (p75, CrUX), INP unter 200 ms (INP ersetzte FID im März 2024) und CLS unter 0,1 bekommt dieselbe Behandlung, die AMP früher über den Badge gesteuert hat, ohne Tag-Verbot und ohne Google-URL. Warum eine parallele, beschnittene Version halten, wenn die Canonical dieselben Schwellen schaffen kann?

Die Schwellen sind Googles Liste, keine interne Lab-Fantasie. 100/100 in Lighthouse ist Lab. Ranking liest Feld. Wer beides vermischt, baut AMP ab und jagt danach einen Screenshot. Die Trennung steht im Leitfaden 100/100 Core Web Vitals erreichen 2026.

#Zeittafel

Jahr	Ereignis
2016	AMP startet, bald Pflicht für Top Stories
2018	Breite Adoption, Kritik an URL und Kontrolle wächst
2021	Top Stories ohne AMP-Pflicht, Core Web Vitals als Signal
2023	Große Publisher bauen AMP zurück, Feature-Arbeit am Format flacht ab
2024	INP ersetzt FID als Vital
2025	Offizielles WordPress-AMP-Plugin ist Bestand, kein Wachstumsprodukt
2026	Für neue WordPress-Projekte tot. Cache und Plugin existieren als Altlast

Publisher sind nicht in einer Abstimmung gegangen. Sie sind an kleinen Niederlagen hängen geblieben. Consent-Banner auf AMP war oft eine zweite Implementierung, weil die CMP der Canonical nicht in amp-consent passte. Ad-Ops sahen AMP-only-Formate, die weniger einspielten als der Standard-Stack. Analyse kam über amp-analytics mit anderem Session-Schnitt als Matomo oder GA4 auf der Canonical. Design wollte ein interaktives Element, und die Antwort war „nicht auf AMP“. Jeder Punkt allein war überlebbar. Zusammen waren sie ein Parallelprodukt für einen Badge, den Google danach gestrichen hat.

#AMP-Cache in der Search Console, nicht im Theme

Dieser Abschnitt ist der Teil, den DACH-Publisher 2026 noch aufräumen, während das Theme längst „ohne AMP“ aussieht. Der Google-AMP-Cache ist kein Theme-Feature. Er ist eine Kopie Ihrer Origin-HTML auf Googles Infrastruktur. Die Search Console zeigt diese Kopien länger, als Redaktionen erwarten. Wer dort Cache-Hosts optimiert, optimiert die falsche URL.

#Was die Search Console noch zeigt

Typische Reste, die wir in Properties von Nachrichten- und Magazin-Sites im DACH-Raum noch finden:

• Indexierte oder „gefunden, nicht indexiert“-Zeilen mit Host cdn.ampproject.org oder Viewer-Pfaden unter google.com/amp/. Das sind Cache-URLs, keine Canonicals.
• Alte /amp/-Pfade und ?amp=1-Varianten auf der eigenen Domain, die noch Impressionen oder Crawl-Fehler tragen, obwohl das Plugin schon deaktiviert ist.
• rel="amphtml" im HTML der Canonical, oft hart im Header-Template oder von einem SEO-Plugin geschrieben, das niemand nach dem Plugin-Ausbau geprüft hat. Solange dieser Link steht, darf Google eine AMP-Variante erwarten.
• Validator-Debug. #development=1 an einer AMP-URL schaltet die Laufzeitprüfung ein. Staging-Teams haben das in Lesezeichen und in internen QA-Sheets. Wir haben denselben Hash in produktiven Verlinkungen und in GSC-Beispielen gesehen, weil jemand eine Debug-URL in eine interne Doku kopiert hat und die Doku öffentlich wurde. #development=1 ist kein Ranking-Parameter. Er gehört nicht in Sitemaps, nicht in Canonicals, nicht in Share-Links.

Der eigene AMP-Bericht in der Search Console, der das Format jahrelang als Enhancement geführt hat, ist selbst abgekündigt, sobald Google AMP nicht mehr gesondert behandelt. Wer den Bericht noch in einem Runbook als wöchentlichen KPI stehen hat, pflegt ein Museum.

Was Sie in GSC tun, und was nicht:

• Ranking-URL ist die Canonical auf Ihrer Origin. Nicht der Cache-Host, nicht der Viewer, nicht /amp/. canonicalUrl und rel="canonical" zeigen auf https://ihre-domain.de/artikel/, nicht auf die AMP-Kopie.
• Abdeckung und Seitenbericht nach amp, ampproject und ?amp= filtern. Die Trefferliste ist die Redirect-Liste, nicht eine Theme-Backlog.
• Sitemaps dürfen keine /amp/-Endpunkte mehr anbieten. Eine regenerierte Yoast- oder Rank-Math-Sitemap nach Plugin-Entfernen reicht oft. Stichprobe ziehen, nicht dem Dashboard glauben.
• URL-Prüfung auf einer Cache-URL sagt Ihnen, was Google von der Kopie hält. Die Prüfung, die zählt, ist die Canonical auf Ihrer Domain.

#CrUX misst Origin, nicht den Google-Cache

Chrome UX Report (CrUX) ist Origin oder URL auf dem Host, den Chrome-Nutzer wirklich laden, über 28 Tage, p75. Das ist das Ranking-Signal hinter den Vitals. Der AMP-Cache war Googles Edge. TTFB auf cdn.ampproject.org war TTFB von Google, nicht von Ihrem Host.

Genau das hat AMP „schnell“ aussehen lassen. Lab auf der AMP-URL oder ein Feld-Hit, der noch über den Viewer lief, maß fremde Infrastruktur. Sobald die Suchergebnisse die Canonical auf Ihrer Domain zeigen, misst CrUX Sie. Ein Shared-Host, der HTML in 800 ms aus PHP baut, war hinter dem AMP-Cache unsichtbar. Nach dem Ausbau ist er das LCP-Problem.

Folgerungen, die ins Theme gehören und die nicht ins Theme gehören:

• Nicht den Cache „schnell halten“. Sie steuern ihn nicht. Sie steuern Origin, HTML-Cache vor dem Origin, Bilder, Hauptthread.
• Nicht AMP-Boilerplate, ⚡ im <html> oder custom-element-Scripts im Parent-Theme lassen, „falls der Cache noch etwas holt“. Der Cache holt, was Sie noch als AMP ausliefern. Hören Sie auf auszuliefern.
• Doch Feld-CrUX auf der Origin lesen, bevor Sie das Plugin killen, und wieder danach. Ein grünes LCP auf einer AMP-URL war oft der Cache. Ein rotes LCP auf der Canonical nach dem Ausbau ist Ihr Host plus Ihr Hero.

Wer Vitals ernst nimmt, trennt Lab und Feld so, wie es der Core-Web-Vitals-Audit macht: zuerst CrUX und Search Console, dann Lighthouse. Lighthouse auf einer AMP-URL ist ein Bericht über die Runtime v0.js. Lighthouse auf der Canonical ist ein Bericht über Ihr Theme. Nur der zweite bleibt.

#Cache-URL, Viewer, Origin

Drei Adressen, eine Wahrheit.

Adresse	Wer ausliefert	Was sie 2026 ist
https://example.de/artikel/	Ihre Origin oder Ihr HTML-Cache	Ranking-URL, Canonical, CrUX
https://example.de/artikel/amp/ oder ?amp=1	Noch Ihr Stack, solange das Plugin lebt	Altlast, 301-Ziel ist die Zeile darüber
https://www-example-de.cdn.ampproject.org/c/s/example.de/artikel/	Google AMP Cache	Kopie. Kein Ranking-Ziel, kein Theme-Job
https://www.google.com/amp/s/example.de/artikel/	Google AMP Viewer	Chrome-UI um die Kopie. Ebenfalls kein Ranking-Ziel

Sobald 301 von den AMP-Pfaden der Origin stehen und rel="amphtml" weg ist, veraltet der Cache. Google crawlt die Canonical, der Cache bekommt keine frische Kopie mehr, Search-Console-Zeilen zu ampproject.org laufen aus. Das dauert Wochen, nicht Stunden. Wer in Woche eins panisch das Theme umbaut, weil GSC noch Cache-Hosts listet, verwechselt Crawl-Lag mit einem Theme-Bug.

Ein zweiter DACH-Rest: interne Verlinkung aus alten Newslettern und App-Webviews auf /amp/-Pfade. Die 301 fängt das ab. Ein Theme-Filter, der AMP nur „nicht mehr rendert“ und 404 liefert, fängt es nicht ab. 404 auf einer URL mit Historie ist der Ranking-Schaden in diesem Ausbau, nicht das fehlende Blitz-Icon.

#Was nicht in diesen Abschnitt gehört

AMP-Cache-Aufräumen ist Search Console, Redirects, Canonicals, Sitemap. Es ist kein Anlass, Compliance-Siegel, Behördenkataloge oder Logistik-Marken in die Performance-Story zu ziehen. Der Cache ist ein Google-Produkt. Die Canonical ist Ihre Domain. CrUX ist Chrome auf dieser Domain. Mehr braucht die Diagnose nicht.

#AMP sicher entfernen

Wenn die WordPress-Site noch AMP ausliefert, tragen Sie die Kosten ohne den früheren Nutzen. Der Ausbau ist mechanisch. Ranking verliert man an den Redirects und Canonicals, nicht am Plugin-Klick.

#Bestand messen, bevor etwas stirbt

Analytics: Sitzungen auf Pfaden, die auf /amp/ enden, und auf amp=1 in der Query. Search Console: Seitenbericht und alte AMP-Enhancement-Reste nach denselben Mustern. Export der URLs, die noch Impressionen haben. Das ist die Redirect-Liste und die Watchlist nach dem Go-live.

Ohne diese Liste deinstallieren Teams das Plugin, setzen eine globale Regex, und eine Kampagnen-URL mit historischem /amp/-Slug, der kein AMP war, sondern ein Artikel über Messung, landet falsch. Die Regex muss das Verzeichnis oder den Endpunkt meinen, nicht das Token amp irgendwo im Pfad.

#Canonical erst schnell machen

Nicht AMP abschalten, während die Standardvorlage im Feld rot ist. Dann tauschen Sie eine eingeschränkte, schnelle Kopie gegen eine freie, langsame Seite, und CrUX rechnet Ihnen das in den nächsten 28 Tagen vor.

PageSpeed Insights auf den Top-Canonicals, Mobil, und die Feldkarte zuerst. LCP p75 unter 2,5 s, INP unter 200 ms, CLS unter 0,1. Lab danach als Diagnose. Hero ohne loading="lazy", AVIF, HTML-Cache für anonyme GETs, Consent und Chat nicht synchron im <head>. Details stehen in den beiden verlinkten Leitfäden. Hier reicht die Regel: erst grün genug auf der Canonical, dann AMP tot.

#Jede AMP-URL 301 auf die Canonical

/beitrag/amp/ muss nach /beitrag/ (bzw. die echte Permalinks-Form). ?amp=1 braucht eine eigene Regel. Wer nur den Pfad fängt, lässt Query-Varianten indexiert, und die werden 404, sobald das Plugin weg ist. Das ist das größte SEO-Risiko in diesem Ablauf.

Nginx:

rewrite ^/(.*)/amp/?$ /$1/ permanent;

Zusätzlich die Query, nicht nur den Pfad. In Nginx oft über if auf $arg_amp plus return 301, oder in der Applikation, wenn Permalinks komplex sind.

Apache (.htaccess):

RewriteEngine On
RewriteRule ^(.+)/amp/?$ /$1/ [R=301,L]
RewriteCond %{QUERY_STRING} (^|&)amp=1(&|$)
RewriteRule ^(.*)$ /$1? [R=301,L]

WordPress (functions.php oder kleines Must-Use-Plugin), vor dem Plugin-Kill testen:

add_action('template_redirect', static function (): void {
    $uri = $_SERVER['REQUEST_URI'] ?? '';
    $is_amp_path = (bool) preg_match('#/amp/?($|\\?)#', $uri);
    $is_amp_query = isset($_GET['amp']);
    if (!$is_amp_path && !$is_amp_query) {
        return;
    }
    $clean = preg_replace('#/amp/?$#', '/', strtok($uri, '?'));
    $clean = remove_query_arg('amp', $clean);
    wp_redirect(home_url($clean), 301);
    exit;
});

Nach dem Deploy: Stichprobe aus dem GSC-Export, curl -I, Status 301, Location auf die HTTPS-Canonical ohne /amp/ und ohne amp=. Ein 302 ist falsch. Ein 200 auf der AMP-URL heißt, das Plugin oder ein Cache liefert noch.

#Canonical-Tags, Sitemap, Plugin

Mit lebendem AMP haben Standardseiten oft rel="canonical" auf die AMP-Variante gelegt, oder die AMP-Seite hat sich selbst kanonisiert. Nach dem Ausbau muss jede öffentliche URL auf sich selbst zeigen. Yoast und Rank Math tun das, sobald AMP weg ist. Trotzdem zehn URLs per Hand prüfen, inkl. Startseite, einem Artikel, einer Kategorie, einem Produkt.

rel="amphtml" aus Header, Theme und SEO-Plugin entfernen. XML-Sitemap neu erzeugen, ohne AMP-Pfade. Dann das AMP-Plugin deaktivieren und löschen, nicht nur deaktivieren. Deaktiviert lässt es oft Rewrite-Regeln und Optionen liegen. amp-boilerplate, Custom-Element-Scripts und der Blitz im <html> dürfen im gebauten HTML nicht mehr vorkommen. Quelltext der Canonical suchen, nicht das Theme-File allein.

#Search Console nachziehen

Nach dem Schnitt:

• Seitenbericht auf 404 und Soft-404 der alten AMP-URLs. Die Antwort muss 301 sein, nicht 404.
• Weiterleitungskette mit einem Crawler (Screaming Frog oder vergleichbar) über den Export.
• Mobiltauglichkeit auf der Canonical, nicht auf dem Cache.
• Sitemap erneut einreichen.
• Zwei bis vier Wochen Crawl-Lag einkalkulieren. CrUX braucht 28 Tage, bis der AMP-Mix aus dem p75 fällt.

Wer in Woche zwei „Traffic weg“ ruft, weil Discover auf AMP-URLs zurückging und die Canonical noch nicht dieselben Impressionen zeigt, misst den Lag, nicht den Verlust. Die Watchlist aus Schritt 1 entscheidet, ob eine URL wirklich verschwunden ist oder nur den Host gewechselt hat.

#Moderner Stack 2026 (Astro 7, AVIF, HTML-Cache, INP)

AMP hat gute Gewohnheiten per Verbot erzwungen. Nach dem Ausbau müssen Sie dieselben Gewohnheiten wählen. Der Ersatz ist kein Framework-Name auf einer Folie. Es ist Origin-Zeit, Bilder, Hauptthread und ein Cache, der Ihnen gehört.

#Hosting und TTFB, ohne Google-Cache

Alles unterhalb sitzt auf der ersten Antwort. Ein Origin, der anonymes HTML in 800 ms aus PHP baut, hat das LCP-Budget von 2,5 s schon angefasst, bevor AVIF überhaupt startet. AMP hat das hinter cdn.ampproject.org versteckt. Auf der Canonical ist der Host wieder sichtbar.

Anonyme GETs brauchen HTML-Cache vor dem Origin (Cloudflare Cache mit Tag-Purge beim Publish, oder Nginx fastcgi_cache auf eigener VPS). Purge nach Beitrag, nicht „ganze Zone leeren“. Eingeloggte und Warenkorb bleiben Bypass. Redis hinter dem Page-Cache hält WP_Query für die Treffer, die PHP noch sehen. Uncached Shared-Hosting plus AMP-Entfernen ist die Kombination, die CrUX rot färbt.

#AVIF statt <amp-img>

AMP hat Bilder über eine eigene Komponente plus Runtime geladen. 2026 reicht natives HTML: <picture> mit AVIF, WebP als Fallback, srcset und sizes passend zum Layout, width und height oder aspect-ratio gegen CLS. Das LCP-Bild ohne loading="lazy", mit fetchpriority="high" und Preload im <head>. ShortPixel oder Imagify in der Mediathek, oder Konvertierung an der Edge. JPEG bleibt das Original im Upload, nicht die Auslieferung.

Ein Hero als 3-MB-PNG aus dem letzten Kampagnen-Export ist dasselbe Problem, das AMP 2016 mit Gewalt begrenzt hat. Diesmal begrenzen Sie es selbst, auf der Canonical, mit einem Format, das in Chrome und Safari ankommt.

#INP statt „kein JavaScript“

INP hat FID im März 2024 abgelöst. Grün im Feld ist 200 ms oder besser auf p75. AMP hat INP oft „gelöst“, indem es Interaktion verboten hat. Das ist kein Vital, das ist Amputation.

Auf WordPress bricht INP an Drittanbietern auf dem Hauptthread: Tag Manager, Consent, Chat, PayPal- und Klarna-Widgets, Page-Builder-Runtime. Verzögern bis Idle oder bis Sichtbarkeit. requestIdleCallback oder scheduler.yield() für lange Tasks. Plugins streichen, die ein Render-blocking-Script enqueuen, das die Seite nicht nutzt. Checkout-Widgets nicht auf der Startseite hydratisieren.

Astro 7 macht denselben Schnitt architektonisch: HTML und CSS zuerst, Inseln nur wo geklickt wird. client:visible für den Mini-Cart. client:idle für Suche. Ein Artikel ohne Insel sendet kein JavaScript und gewinnt Lab, ohne ein Tag-Verbot von Google. Next.js 16 mit Partial Prerendering hält die Shell statisch. Beides schlägt ein PHP-Theme, das jQuery, Slider und drei Tracker in den ersten Paint legt.

INP ist der Grund, warum „wir haben AMP gelöscht und die Seite fühlt sich tot an“ vorkommt. Die Canonical hatte immer schon die Widgets. AMP hat sie nur nicht ausgeführt. Jetzt müssen die Widgets weg vom ersten Tap, nicht zurück hinter ein Format.

#HTML-Cache und Speculation Rules

Sie brauchen nicht Googles AMP-Cache. Sie brauchen Ihren Edge-Cache. Full-Page-HTML nahe am Nutzer reproduziert den größten Teil des alten Instant-Gefühls, mit Ihrer URL in der Adresszeile. HTTP/3, Early Hints, ein knappes kritisches CSS für Header und Hero, der Rest der Sheet async.

Speculation Rules sind der ehrliche Ersatz für AMP-Prefetch. Der Browser darf die nächste interne URL vorab rendern, von Ihrer Origin, auf Ihrer Canonical, ohne Framework:

<script type="speculationrules">
{
  "prerender": [
    { "where": { "href_matches": "/*" }, "eagerness": "moderate" }
  ]
}
</script>

Das drückt die nächste Navigation. Es ändert nicht LCP der Landing, die aus Google kommt. Genau diese Landing interessiert CrUX. Deshalb bleibt HTML-Cache plus LCP-Bild die erste Baustelle, Speculation Rules die zweite.

Kritisches CSS inline, Fonts mit font-display: swap oder optional, Subset inkl. latin-ext für DE, Preload nur für die Schnitt im Hero. WP Rocket und FlyingPress können das auf dem Monolith. Auf Astro 7 liegt es in der Build-Pipeline. Zwei Inliner (Plugin plus Edge) streiten ums <style> und verdoppeln Bytes. Einen Weg wählen.

#Was wir intern vergleichen, ohne Fake-Lab

Größe	AMP (historisch, oft Cache)	Nativ 2026, wenn der Stack sitzt
Ranking-Signal	Format-Badge, entfallen	CWV im Feld
URL	Google-Cache oder SXG	Eigene Domain
LCP	Niedrig, weil Prefetch plus Edge	2,5 s Feld-Ziel, Lab oft enger
INP	Kaum Interaktion	200 ms Feld-Ziel, mit JS
CLS	Runtime-Größen	aspect-ratio, Consent-Slot
Formulare	amp-bind, oft tot	Volle Canonical
Pflege	Zwei Templates	Ein responsiver Codepfad

Zahlen aus einem Lighthouse-Lauf im Büro-WLAN gehören nicht in diese Tabelle. Wer konkrete p75 braucht, liest CrUX auf der Canonical nach dem Ausbau, nicht eine AMP-URL von 2019.

#AMP gegen nativ, die Entscheidung

Für eine öffentliche Website 2026 ist die Entscheidung nicht knapp. Nativ plus Core Web Vitals. AMP nur noch dort, wo es nie um die Website ging.

Dimension	Web-AMP	Nativ plus Core Web Vitals
Ranking-Signal	Entfallen seit 2021	Aktueller Standard
URL in der Adresszeile	Cache oder SXG-Umweg	Eigene Origin
Eigenes JavaScript	Verboten	Erlaubt, dosiert
Formulare, Checkout, CRM	Eingeschränkt	Voll
Templates	Zwei	Eins
Wer die Seite kontrolliert	Googles Cache	Sie
Search Console	Cache-Hosts, /amp/, rel=amphtml	Canonical, CrUX, Coverage
Empfohlen 2026	Nein	Ja
Ausnahme	AMP for Email in Gmail	Unberührt

AMP for Email bleibt das eine lebende Produkt unter dem Namen. Gmail rendert dynamische Mails, in denen Empfänger absagen, bestellen oder ein Formular absenden, ohne den Posteingang zu verlassen. Andere Runtime, andere Spec, kein WordPress-Plugin, kein cdn.ampproject.org in der Search Console Ihrer Website. Wer nur dort noch AMP sieht, hat das Web-Thema erledigt.

Wer Web-AMP „für Discover“ behält: Discover rankt über Qualität und Vitals auf der URL, die Google zeigt. Das ist die Canonical. Der Blitz ist seit 2021 kein Ticket mehr. Wer Web-AMP „für Speed“ behält, misst den Cache und nennt es Theme-Arbeit. Beides ist 2026 die falsche Diagnose.

Neue Stacks in diesem Haus: Astro 7 vor dem Origin, WordPress als CMS, Cloudflare als HTML-Cache, AVIF in der Pipeline, Inseln statt AMP-Komponenten. Der kommerzielle Einstieg, wenn das Feld nach dem Ausbau rot bleibt, ist der Core-Web-Vitals-Audit. Die Schwellen, Lab gegen Feld, stehen im Leitfaden zu 100/100 Core Web Vitals 2026.

#Fazit

Das AMP-Experiment ist vorbei. Das offene Web hat die Messung bekommen, die AMP als Sonderformat überflüssig macht. Deinstallieren Sie das Plugin.

AMP hat 2016 ein echtes Mobilproblem gelöst und die Bedingungen überlebt, die es gerechtfertigt haben. Core Web Vitals geben Google ein neutrales Speed-Signal. Browser liefern Prefetch ohne fremde URL. Hosting und Edge machen schnelle Canonicals zum Alltag. Der Tausch, den AMP verlangte (Kontrolle über URL und Code gegen Tempo), kauft nichts mehr, das Sie anders nicht kriegen.

Die Arbeit ist kurz und streng in der Reihenfolge: AMP-Traffic messen, Canonical im Feld über LCP 2,5 s, INP 200 ms und CLS 0,1 bringen, 301 von /amp/ und ?amp=1, rel="amphtml" und Sitemap säubern, Plugin löschen, Search Console inklusive cdn.ampproject.org-Resten zwei bis vier Wochen lesen. Cache-URLs sind kein Theme-Ticket. CrUX ist Origin. Gmail-AMP ist ein anderes Produkt.

Nutzer behalten Formulare und Marke. Das Team behält ein Template. Der Blitz darf in der Search Console veralten.