Google hat bei AMP eine Änderung vorgenommen, die auf den ersten Blick technisch klingt, in der Praxis aber ziemlich viel über den Zustand von AMP im Jahr 2026 erzählt. Wenn du AMP-Seiten betreibst oder in den vergangenen Jahren noch irgendwo AMP-Templates, AMP-Caches oder Signed Exchanges in deinem Setup mitschleppst, betrifft dich das durchaus. Die Kurzfassung: Nutzerinnen und Nutzer, die über die Google-Suche auf eine AMP-Seite klicken, werden künftig direkt auf die vom Publisher gehostete AMP-Seite geschickt. Nicht mehr auf eine im AMP-Viewer angezeigte, gecachte Version.
Das ist eine kleine Änderung mit einem langen Schatten. Denn AMP war einmal ein sehr großes Thema. Schnelligkeit, mobile Nutzererfahrung, Top Stories, technische Vorgaben, eigene Templates, Validierung, Caching, Canonicals, Analytics-Sonderwege – wer in SEO oder Publishing gearbeitet hat, erinnert sich vermutlich noch gut daran. Manchmal sogar zu gut. Aus meiner Erfahrung war AMP nie nur eine Technologiefrage. Es war immer auch eine Frage von Kontrolle: Wer liefert die Seite aus? Wer sieht welche URL? Wer misst was? Und wie viel Aufwand ist ein Publisher bereit zu akzeptieren, nur um in bestimmten Suchflächen besser oder überhaupt konkurrenzfähig sichtbar zu sein?
Jetzt wird ein Stück dieser alten AMP-Architektur zurückgebaut. Google betont dabei, dass AMP-Inhalte weiterhin wie andere Webseiten behandelt werden. Es soll keine Änderung beim Ranking geben, weder in der Google-Suche noch in Google Discover. Das ist wichtig, weil bei solchen technischen Anpassungen sofort die naheliegende Frage kommt: „Verliere ich dadurch Sichtbarkeit?“ Nach dem aktuellen Stand lautet die Antwort: nein, zumindest nicht wegen dieser Änderung an sich.
Trotzdem solltest du das Thema nicht einfach wegwischen. Gerade wenn du noch AMP einsetzt, lohnt sich ein prüfender Blick. Denn wenn Google Nutzer direkt zu deiner AMP-Host-Seite schickt, verschieben sich ein paar operative Dinge. Nicht dramatisch, aber spürbar. Und, na ja, bei alten AMP-Setups steckt der Teufel leider oft genau in diesen unscheinbaren Details.
Was sich bei AMP-Aufrufen aus der Google-Suche konkret ändert
Bisher war es bei AMP häufig so, dass Nutzer aus der Suche nicht unmittelbar auf deiner eigenen AMP-URL landeten, sondern auf einer von Google zwischengespeicherten Version, die innerhalb eines AMP-Viewers dargestellt wurde. Technisch betrachtet hatte das Vorteile: schnelle Auslieferung, standardisierte Darstellung, ein stark kontrollierter Abrufpfad. Für Publisher bedeutete es aber auch: ein zusätzlicher Layer zwischen Suchergebnis und eigener Website.
Mit der neuen Änderung fällt dieser Zwischenschritt weg. Google verbindet den Suchenden direkt mit der AMP-Seite auf dem Host des Publishers. Wenn du also eine AMP-Version deiner Seite unter deiner eigenen Domain betreibst, soll der Klick aus der Suche künftig genau dorthin führen. Nicht zu einer Cache-Variante, nicht in eine Google-gerahmte AMP-Ansicht, sondern auf deine eigene AMP-Seite.
Das klingt fast banal. Ist es aber nicht ganz. Lange Zeit war der AMP Cache ein zentraler Bestandteil des AMP-Erlebnisses in Google. Viele technische Empfehlungen, Dokumentationen und Implementierungen drehten sich darum, dass Inhalte korrekt gecacht, validiert und schnell ausgeliefert werden konnten. Jetzt heißt es sinngemäß: Du musst den AMP Cache nicht mehr aktualisieren und Signed Exchanges nicht mehr konfigurieren, nur um diesen Suchfluss sauber zu bedienen.
Für manche Publisher ist das eine Erleichterung. Für andere ist es eher ein Schulterzucken, weil sie AMP schon vor Jahren entfernt haben. Und für eine dritte Gruppe – meist größere oder ältere Publishing-Systeme – kann es ein Anlass sein, lange nicht mehr angerührte AMP-Konfigurationen endlich aufzuräumen.
Die offizielle Begründung ist pragmatisch: Die Änderung soll Wartungsaufwand reduzieren. Das passt ins Bild. AMP ist heute nicht mehr der strategische Hebel, der es vor einigen Jahren einmal war. Viele Websites haben sich davon verabschiedet, seit Page Experience, Core Web Vitals und bessere mobile Frameworks einen Teil der ursprünglichen AMP-Versprechen auch ohne AMP erreichbar gemacht haben.
Und doch: Wenn du noch AMP im Einsatz hast, solltest du nicht davon ausgehen, dass alles automatisch perfekt läuft. Direkt auf Publisher-gehostete AMP-Seiten zu schicken bedeutet nämlich auch, dass deine eigene Infrastruktur sauber funktionieren muss. Ladezeiten, Weiterleitungen, AMP-Validität, Tracking, Consent-Mechanismen, Canonicals und Serverantworten liegen wieder stärker bei dir. Eigentlich lagen sie das immer, aber jetzt wirkt sich ein Fehler weniger hinter einem Google-Zwischensystem versteckt aus.
Der AMP Viewer verliert an Bedeutung
Der frühere AMP Viewer war für viele Nutzer kaum sichtbar, aber für Publisher durchaus relevant. Er erzeugte eine Art kontrollierte Zwischenansicht, in der AMP-Seiten sehr schnell geladen wurden. Kritiker haben über Jahre bemängelt, dass dadurch die eigentliche Publisher-URL weniger präsent war und dass das Web ein Stück weit in Googles Infrastruktur hineingezogen wurde.
Mit dem neuen Verhalten wird diese Distanz kleiner. Der Nutzer kommt direkter zu dir. Das ist aus Web-Perspektive durchaus gesund. Ein Klick auf ein Suchergebnis sollte im Idealfall zu der Website führen, von der der Inhalt stammt. Nicht zu einer Ersatzansicht, nicht zu einer gecachten Zwischenstation, sondern zum Original unter Kontrolle des Betreibers.
Ich würde das nicht überromantisieren. Google bleibt natürlich weiterhin der Gatekeeper des Such-Traffics. Aber in diesem konkreten Punkt ist die Bewegung klar: weniger Cache-Abhängigkeit, weniger AMP-Sonderlogik, mehr Standard-Web.
Was Google zur Indexierung und Darstellung von AMP sagt
Parallel zur technischen Änderung wurde auch die Dokumentation rund um AMP angepasst. Besonders auffällig ist die Klarstellung, dass Google AMP-Seiten grundsätzlich wie andere Webseiten indexiert. Entscheidend ist nicht die Technologie an sich, sondern ob die Seite den allgemeinen Anforderungen entspricht, die auch für andere Webinhalte gelten.
Das ist ein wichtiger Satz, gerade weil AMP früher in vielen Köpfen fast wie ein eigener SEO-Modus behandelt wurde. Nach dem Motto: Wenn es AMP ist, gelten Sonderregeln. Ganz so einfach war es nie, aber in der Praxis fühlte es sich oft so an. Heute ist die Botschaft nüchterner: AMP ist eine technische Variante einer Webseite. Sie kann in der Suche erscheinen, sie kann Rich Results erhalten, sie kann in bestimmten Formaten wie Web Stories auftauchen. Aber sie wird nicht allein deshalb bevorzugt, weil sie AMP ist.
Google stellt außerdem klar, dass AMP-Seiten als Rich Results erscheinen können, genauso wie andere Seiten im Web. Wenn du willst, dass Google deine Inhalte besser versteht, kannst du strukturierte Daten einsetzen. Das ist keine Garantie für eine erweiterte Darstellung, aber es hilft Google, den Inhalt und die Entitäten auf der Seite einzuordnen. Das Prinzip kennst du vermutlich: Strukturierte Daten sind eine Einladung, kein Anspruchsschein.
Auch Web Stories bleiben im AMP-Kontext relevant. AMP-Seiten können weiterhin als Web Stories erscheinen, wenn die technischen Voraussetzungen erfüllt sind. Für klassische Publisher ist das vielleicht weniger zentral als früher, aber für visuelle, mobile Erzählformate spielt es weiterhin eine Rolle.
Eine kleine, aber nicht unwichtige Aussage steckt in der Formulierung, dass für alle Seiten derselbe Standard gilt, unabhängig von der Technologie, mit der sie gebaut wurden. Das ist im Grunde die Linie, die Google seit einiger Zeit immer stärker fährt: Nicht das Framework rankt, sondern das Ergebnis. Eine gute Seite kann mit AMP gebaut sein, mit Next.js, mit WordPress, mit statischem HTML oder mit einem ziemlich altmodischen CMS, wenn sie schnell, zugänglich, crawlbar und hilfreich ist. Umgekehrt rettet dich kein modernes Setup, wenn die Seite inhaltlich dünn, technisch kaputt oder für Nutzer mühsam ist.
Ranking bleibt laut Google unverändert
Der wahrscheinlich wichtigste Punkt für dich als SEO, Entwickler oder Publisher ist: Google sagt, dass diese Änderung keinen Einfluss darauf hat, wie AMP-Seiten ranken oder in Google Search und Discover ausgeliefert werden. Das heißt, es geht hier nicht um eine algorithmische Neubewertung von AMP. Es geht um den Weg, den ein Nutzer nach dem Klick nimmt.
Trotzdem würde ich solche Aussagen immer mit einem kleinen Praxisvorbehalt lesen. Nicht, weil ich unterstelle, dass die Aussage falsch ist. Sondern weil Ranking und Nutzerführung in echten Setups oft indirekt zusammenhängen. Wenn deine eigene AMP-Seite langsamer lädt als die gecachte Version, wenn Redirects haken, wenn Consent-Banner blockieren, wenn Analytics-Skripte anders feuern oder wenn bestimmte Ressourcen nicht sauber ausgeliefert werden, dann kann die Nutzererfahrung sehr wohl leiden. Und schlechte Nutzererfahrung ist selten gut, auch wenn der unmittelbare Rankingmechanismus unverändert bleibt.
Es ist also keine Ranking-Änderung im engeren Sinn. Aber es ist ein guter Anlass, die tatsächliche Auslieferung deiner AMP-Seiten zu testen. Nicht nur im Browser am Desktop, sondern auf echten mobilen Geräten, in der Google-App, in Chrome, vielleicht auch mit verschiedenen Netzbedingungen. Ich habe schon oft erlebt, dass ein Setup in einem Tool wunderbar aussieht und auf einem echten Smartphone dann irgendein unscheinbarer Redirect, ein Consent-Layer oder ein JavaScript-Fehler alles ausbremst.
Warum diese Änderung jetzt kommt
Man kann diese AMP-Anpassung nicht sinnvoll betrachten, ohne den größeren Kontext zu sehen. AMP war einmal Googles große Antwort auf langsame mobile Webseiten. Damals war das mobile Web vielerorts wirklich zäh. Überladene Seiten, riesige Bilder, blockierende Skripte, Pop-ups, Tracking-Kaskaden. AMP bot ein strenges Regelwerk, das viele dieser Probleme technisch einschränkte. Wer AMP korrekt implementierte, bekam schnelle Seiten – manchmal auch deshalb, weil AMP viele schlechte Gewohnheiten schlicht nicht erlaubte.
Aber die Weblandschaft hat sich verändert. Performance ist stärker in den Mainstream gerückt. Core Web Vitals haben das Thema messbarer gemacht. Moderne Frameworks und Hosting-Stacks sind besser geworden. Bildoptimierung, Caching, Edge Delivery und serverseitiges Rendering sind heute viel verbreiteter als damals. Gleichzeitig haben viele Publisher gemerkt, dass AMP zusätzlichen Aufwand verursacht: eigene Templates, doppelte QA, eigene Tracking-Logik, Validierungsprobleme, manchmal Unterschiede zwischen Canonical- und AMP-Version.
Viele Websites haben AMP deshalb entfernt. Nicht alle, aber viele. Besonders dort, wo AMP keinen klaren Sichtbarkeitsvorteil mehr brachte, wurde die Rechnung einfach: Warum zwei Varianten pflegen, wenn eine schnelle, saubere responsive Seite reicht?
Vor diesem Hintergrund wirkt die neue Änderung fast wie ein spätes Aufräumen. Google reduziert Sonderlogik für eine Technologie, die nicht mehr denselben Stellenwert hat wie früher. AMP verschwindet dadurch nicht. Aber es wird stärker wie eine normale Webtechnologie behandelt, nicht wie ein Sonderzugang zur mobilen Suche.
Ich finde das ehrlich gesagt konsequent. Vielleicht ein bisschen spät, aber konsequent. Das Web ist gesünder, wenn Publisher ihre Inhalte direkt hosten, Nutzer klare URLs sehen und technische Sonderwege nicht unnötig lange weiterleben. Natürlich war AMP nicht nur schlecht. Gerade in den Anfangsjahren hat es viele Seitenbetreiber gezwungen, sich endlich mit mobiler Geschwindigkeit auseinanderzusetzen. Aber AMP war eben auch ein recht enges Korsett.
Weniger Cache, weniger Signed Exchanges, weniger Sonderpflege
Ein konkreter praktischer Punkt ist der Wegfall bestimmter Pflegeanforderungen. Google weist darauf hin, dass Publisher den AMP Cache nicht mehr aktualisieren und Signed Exchanges nicht mehr konfigurieren müssen, um den neuen Suchpfad zu bedienen.
Signed Exchanges waren ohnehin ein Thema, das viele kleinere Publisher nie wirklich sauber angefasst haben. In der Theorie konnten sie helfen, Inhalte über Drittinfrastruktur auszuliefern und trotzdem die Publisher-URL im Browser sichtbarer zu machen. In der Praxis war das Setup nicht trivial. Zertifikate, Serverkonfiguration, Kompatibilität, Monitoring – das ist nichts, was man mal eben nebenbei macht, wenn das Redaktionsteam eigentlich neue Inhalte veröffentlichen will.
Wenn dieser Teil nun weniger wichtig wird, ist das für viele Teams eine Entlastung. Es nimmt Komplexität aus dem System. Und Komplexität ist in SEO- und Publishing-Setups eines der unterschätzten Risiken. Nicht jede Komplexität ist schlecht, aber jede zusätzliche Schicht kann brechen. Und sie bricht meistens freitagnachmittags oder kurz vor einem großen News-Peak. So fühlt es sich zumindest an.
Was du jetzt prüfen solltest, wenn du noch AMP nutzt
Wenn du AMP bereits entfernt hast, musst du vermutlich nicht viel tun. Dann ist diese Änderung eher eine Bestätigung dessen, was viele schon länger vermutet haben: AMP wird weiter in Richtung Normalisierung geschoben. Wenn du aber noch AMP-Seiten auslieferst, würde ich mir ein paar Dinge sehr genau anschauen.
Zuerst solltest du testen, welche URL nach einem Klick aus der Suche tatsächlich geladen wird. Dabei geht es nicht nur um die URL im Browser, sondern auch um den gesamten Pfad: Suchergebnis, Klick, Weiterleitung, finale Seite, Ladezeit, Darstellung. Besonders spannend ist der Unterschied zwischen Chrome und der Google-App. Es gab bereits einzelne Beobachtungen, dass eine AMP-URL in Chrome funktionierte, in der Google-App aber Probleme machte. Das kann ein Einzelfall sein, klar. Trotzdem würde ich genau solche Konstellationen testen, bevor du dich entspannt zurücklehnst.
Dann solltest du deine AMP-Seiten validieren. Nicht aus Prinzip, sondern weil direkte Auslieferung bedeutet, dass Fehler stärker sichtbar werden. Prüfe, ob deine AMP-Versionen noch gültig sind, ob Canonicals korrekt gesetzt sind und ob die Verbindung zwischen Canonical- und AMP-Seite sauber funktioniert. Alte AMP-Templates sind manchmal wie ein Kellerraum, den niemand mehr betreten will: Man weiß, da steht noch Zeug, aber man hofft, dass es schon nicht schimmelt. Leider schimmelt Technik durchaus.
Auch Analytics verdient Aufmerksamkeit. Wenn früher bestimmte Aufrufe über Cache- oder Viewer-Kontexte kamen und nun direkter auf deiner eigenen AMP-URL landen, können sich Messdaten verändern. Das heißt nicht automatisch, dass dein Traffic steigt oder fällt. Aber die Zuordnung, Referrer-Informationen, Session-Logik oder Consent-Auswirkungen können anders aussehen. Wenn du Traffic-Trends beobachtest, solltest du diesen technischen Wechsel als möglichen Faktor im Hinterkopf behalten.
Ein weiterer Punkt: Ladegeschwindigkeit. AMP-Seiten wurden oft unter der Annahme betrieben, dass der Cache einen Teil der Performance-Arbeit übernimmt. Wenn nun die Publisher-gehostete Variante stärker im Vordergrund steht, muss deine Infrastruktur liefern. CDNs, Bildgrößen, Serverantwortzeiten, Cache Header, Third-Party-Skripte – all das ist plötzlich wieder weniger abstrakt. Am Ende zählt die echte Nutzererfahrung.
AMP nicht reflexartig löschen, aber ehrlich bewerten
Ich würde niemandem empfehlen, AMP allein wegen dieser Änderung über Nacht zu entfernen. Das wäre zu grob. Es gibt immer noch Setups, bei denen AMP funktioniert, stabil ist und keinen übermäßigen Aufwand verursacht. Wenn deine AMP-Seiten schnell sind, valide laufen, gute Messdaten liefern und redaktionell sauber integriert sind, kannst du sie weiter betreiben.
Aber du solltest ehrlich prüfen, ob AMP dir heute noch genug bringt. Nicht nostalgisch, nicht aus Gewohnheit, sondern nüchtern. Gibt es messbaren Mehrwert? Gibt es Suchflächen, in denen AMP für dich weiterhin wichtig ist? Ist die Pflege überschaubar? Oder hältst du nur ein altes System am Leben, weil niemand die Migration anfassen möchte?
Gerade bei größeren Websites ist „wird schon noch gebraucht“ ein gefährlicher Satz. Er sorgt dafür, dass technische Altlasten jahrelang bestehen bleiben. Und irgendwann versteht niemand mehr, warum ein bestimmtes Template existiert, warum ein Tracking-Parameter anders heißt oder warum eine Weiterleitung exakt so gebaut wurde. AMP kann in solchen Fällen ein klassisches Altlastenthema sein.
Was die Änderung über die Zukunft von AMP verrät
Die spannendere Frage ist nicht, was sich technisch ändert. Die spannendere Frage lautet: Was sagt diese Änderung über AMP insgesamt aus?
Für mich zeigt sie, dass AMP weiter an Sonderstatus verliert. Nicht mit einem lauten Knall, sondern leise, dokumentarisch, durch kleine Änderungen an Auslieferung und Hilfetexten. AMP bleibt möglich, aber es wird weniger besonders. Es wird stärker eingebettet in die normale Logik des Webs: Google indexiert Seiten, bewertet sie nach allgemeinen Standards, kann Rich Results anzeigen, nutzt strukturierte Daten, und der Klick führt möglichst direkt zur Website.
Das ist eigentlich die Richtung, die viele SEOs und Publisher seit Jahren wollten. Weniger Spezialbehandlung, mehr klare Verantwortlichkeiten. Wenn deine Seite gut ist, soll sie funktionieren. Wenn sie schlecht ist, hilft dir auch ein AMP-Label nicht weiter. Das klingt brutal simpel, ist aber ein gesunder Gedanke.
Man darf trotzdem nicht vergessen, warum AMP überhaupt entstanden ist. Das mobile Web war an vielen Stellen kaputt langsam. Viele Publisher hatten ihre Seiten mit Werbung, Tracking und Skripten so stark überladen, dass Nutzer darunter litten. AMP war auch eine Reaktion auf diese Realität. In gewisser Weise hat die Branche AMP mitverursacht. Das wird in Rückblicken manchmal ausgeblendet.
Heute sollten wir aus AMP weniger die Frage mitnehmen, ob man ein bestimmtes Framework nutzen muss. Die bessere Frage ist: Lieferst du deine Inhalte schnell, stabil und nutzerfreundlich aus? Wenn ja, bist du auf dem richtigen Weg. Wenn nein, hilft dir keine technische Abkürzung dauerhaft.
Mein praktisches Fazit für dich
Wenn du AMP noch nutzt, teste jetzt deine echten Suchpfade. Nicht nur theoretisch. Klicke aus der mobilen Suche. Prüfe Chrome und die Google-App. Schau dir die Netzwerkanfragen an, wenn du kannst. Kontrolliere, ob deine AMP-Seiten valide sind und ob deine Messung noch plausibel aussieht. Besonders bei Publishern mit hohem mobilen Traffic kann eine kleine Auslieferungsänderung in den Reports erst einmal für Stirnrunzeln sorgen.
Wenn du AMP nicht mehr nutzt, ist diese Änderung vor allem ein weiteres Signal: Die Branche bewegt sich weg von AMP als Pflichtgefühl. Eine schnelle, saubere, responsive Website ist heute der nachhaltigere Kern. Nicht aufregend, ich weiß. Aber in vielen Projekten ist genau das die Wahrheit.
Und falls du gerade überlegst, ob du AMP neu einführen solltest: Ich wäre vorsichtig. Es kann spezielle Anwendungsfälle geben, aber für die meisten modernen Websites würde ich erst alle Energie in Performance, saubere Informationsarchitektur, strukturierte Daten, gute Inhalte und stabile technische Grundlagen stecken. AMP ist kein magischer SEO-Hebel mehr. Eigentlich war es das nie in der einfachen Form, in der es oft verkauft wurde.
Die wichtigste Aussage bleibt: Google schickt Nutzer aus der Suche nun direkt auf Publisher-gehostete AMP-Seiten statt auf gecachte AMP-Viewer-Versionen. Das Ranking soll dadurch unverändert bleiben. Der Wartungsaufwand für AMP-Publisher soll sinken. Und AMP wird damit noch ein Stück stärker zu dem, was es heute faktisch ist: eine optionale Webtechnologie, nicht mehr der zentrale mobile Sonderweg von früher.
Für dich heißt das: weniger Panik, aber auch nicht ignorieren. Ein kurzer technischer Check reicht bei kleinen Setups vielleicht aus. Bei großen Publishing-Systemen würde ich daraus eher einen kleinen Audit machen. Denn wenn alte AMP-Implementierungen irgendwo knirschen, ist jetzt ein ziemlich guter Moment, das zu merken – bevor Nutzer es merken.
