AMP-SEO

TL;DR — AMP (Accelerated Mobile Pages) ist ein Google-Framework aus dem Jahr 2015 zum Erstellen extrem schneller mobiler Seiten. AMP war nie ein Rankingfaktor, und seit Juni 2021 ist es nicht mehr nötig, um in Googles Top-Stories-Karussell zu erscheinen — diese Aufgabe haben die Core Web Vitals übernommen. Für eine neue Website lohnt sich AMP nicht. Wenn du es bereits einsetzt, entscheide, ob sich der Aufwand noch lohnt.

Was ist AMP?

AMP steht für Accelerated Mobile Pages. Google startete das Projekt 2015 (im Oktober erschien es in der Google-Suche) als Open-Source-Ansatz, mit dem mobile Seiten nahezu sofort laden.

AMP setzt deine Seite auf eine strenge Diät. AMP erlaubt nur einen begrenzten HTML-Umfang, dein eigenes JavaScript ist größtenteils verboten, CSS muss inline und klein sein, und du musst eine spezielle AMP-Bibliothek laden. Im Gegenzug kann Google eine Kopie deiner Seite in seinem extrem schnellen Netzwerk (dem Google AMP Cache) speichern und im Hintergrund laden, bevor jemand dein Ergebnis überhaupt antippt — dadurch wirkt es sofort.

Warum es eingesetzt wurde

Jahrelang war AMP praktisch der Eintrittspreis für das Top-Stories-Karussell — den Nachrichtenkasten oben in den mobilen Suchergebnissen. Wenn du eine Nachrichtenseite betrieben und in Top Stories erscheinen wolltest, brauchtest du AMP. Google zeigte neben AMP-Ergebnissen außerdem ein kleines Blitzsymbol (⚡), damit Nutzer wussten, dass die Seite schnell laden würde.

Was sich geändert hat

Im Juni 2021 stellte Google die Pflicht für AMP in Top Stories ein. Jetzt kann jede Seite dort erscheinen, solange sie Googles Nachrichtenkriterien erfüllt — für die Performance zählen Core Web Vitals, Googles Messwerte für Geschwindigkeit und Stabilität, nicht AMP. Google entfernte ungefähr zur selben Zeit auch das Blitzsymbol aus den Ergebnissen.

Der häufigste Denkfehler

AMP ist kein Ranking-Boost. Google hat immer gesagt, dass AMP selbst kein Rankingfaktor ist. Schnelle Seiten können natürlich besser ranken — aber AMP ist nur eine Möglichkeit, Geschwindigkeit zu erreichen, und nicht die einzige. Eine gut gebaute normale Seite kann ohne die Einschränkungen von AMP genauso schnell oder schneller sein.

Solltest du es heute einsetzen?

• Neue Website? Baue sie nicht auf AMP auf. Investiere den Aufwand stattdessen in die Core Web Vitals.
• AMP bereits vorhanden? Es funktioniert weiterhin und wird weiterhin indexiert. Viele Publisher haben es jedoch abgeschaltet, ohne viel Traffic zu verlieren — auch weil AMP die Analytics unübersichtlicher macht. Frage dich, ob es seinen Unterhalt noch rechtfertigt.

Du möchtest die vollständige Version — mit Canonical-Tags, dem Problem der URL-Umschreibung, Signed Exchange, Analytics-Fallen und einer echten Checkliste zum Entfernen? Wechsle zum Tab Fortgeschritten.

TL;DR — AMP ist Googles Open-Source-Framework von 2015 für nahezu sofort ladende mobile Seiten — mit eingeschränktem HTML/CSS/JS und Prerendering aus dem Google AMP Cache. AMP war nie ein Rankingfaktor (Google sagt das ausdrücklich), und seit dem Page-Experience-Update vom Juni 2021 ist es für Top Stories nicht mehr erforderlich — die Core Web Vitals haben AMP ersetzt und das AMP-Badge wurde entfernt. Gecachtes AMP wird weiterhin unter google.com/amp/s/… ausgeliefert; Signed Exchange (SXG) kann es unter deiner eigenen URL ausliefern, aber nur in Chrome. Die Canonical-Beziehung verbindet eine nicht-AMP-Seite mit Self-Canonical (und rel="amphtml") mit einer AMP-Seite, die per rel="canonical" auf sie zurückverweist. Heute ist AMP optional und rückläufig: Baue kein neues AMP und wäge die Betriebskosten (insbesondere bei Analytics) ab, bevor du es beibehältst.

Ein wenig Geschichte

Google startete AMP 2015 und machte es im Oktober 2015 in der Google-Suche verfügbar. Das Projekt wurde als Antwort des offenen Webs auf Facebook Instant Articles und Apple News positioniert — als Möglichkeit, Publisher-Seiten bei der mobilen Geschwindigkeit konkurrenzfähig zu halten. Zum Start wurde es von Partnern wie Twitter, LinkedIn, WordPress und Pinterest unterstützt. Später wechselte das Projekt unter die Governance der OpenJS Foundation, obwohl Google der wichtigste Beitragende geblieben ist.

Der Grund, warum die meisten Publisher AMP tatsächlich einführten, war keine Ideologie — es war das Top-Stories-Karussell. Von ungefähr 2016 bis 2021 war AMP für das Erscheinen dort praktisch erforderlich, und Google kennzeichnete AMP-Ergebnisse mit einem Blitzsymbol (⚡).

Wie AMP technisch funktioniert

AMP kauft Geschwindigkeit durch Einschränkungen:

• Eingeschränktes Markup. Eine AMP-Seite deklariert <html ⚡> (oder <html amp>), lädt die AMP-JS-Laufzeit (<script async src="https://cdn.ampproject.org/v0.js">) und enthält das AMP-Boilerplate sowie die erforderlichen charset- und Viewport-Meta-Tags.
• Kein JavaScript des Autors. Dein eigenes JS ist nur über die in einer Sandbox ausgeführte Komponente amp-script erlaubt; Drittanbieter-JS läuft ausschließlich in Iframes. Alles, was läuft, ist asynchron, sodass nichts das Rendern blockiert.
• CSS ist inline und auf 75 KB begrenzt. Keine externen Stylesheets.
• Ressourcenabmessungen werden statisch angegeben. Bilder und Embeds reservieren ihren Platz im Voraus, wodurch Layout Shifts verhindert werden.

Diese Regeln ermöglichen es Google, eine AMP-Seite sicher in einem versteckten Iframe vorab zu rendern, bevor der Nutzer tippt — daher kommt das Gefühl der sofortigen Ladezeit.

Der Google AMP Cache

Die Geschwindigkeit von AMP kommt nicht nur vom Framework — auch die Auslieferung zählt. Google speichert eine validierte und optimierte Kopie deiner AMP-Seite unter cdn.ampproject.org, liefert sie über HTTPS und moderne Protokolle aus und optimiert Bilder. Eine wichtige Konsequenz: Bei gecachtem AMP wird Googles Infrastruktur zum Host deiner Inhalte, nicht deine Server. Beachte außerdem, dass Desktop-AMP-Seiten nicht aus dem AMP Cache ausgeliefert werden — kanonisches AMP verhält sich dort wie ein normales Ergebnis. Der CDN-Beschleunigungsvorteil betrifft daher im Wesentlichen mobile Seiten.

Was tatsächlich in der Google-Suche geschah

Die entscheidende Zeitleiste:

• 2016–2021: AMP-Badge (⚡) in den Ergebnissen; AMP für Top Stories erforderlich.
• April 2021: Google kündigte für das Page-Experience-Update an: Für Top Stories sei “using the AMP format is no longer required” (Übersetzung) „die Verwendung des AMP-Formats nicht mehr erforderlich“.
• Juni 2021: Das Page-Experience-Update wurde ausgerollt. Core Web Vitals wurden zum Performance-Signal für die Top-Stories-Berechtigung, und Google entfernte das AMP-Badge aus den Ergebnissen.
• 2021 bis heute: AMP ist optional, bietet keinen Ranking-Boost, und CWV steuern tatsächlich die performancebezogenen Signale.

Die wichtigste Aussage: AMP selbst ist kein Rankingfaktor und längst nicht mehr dein Ticket für Top Stories.

Das Problem der URL-Umschreibung (und Signed Exchange)

Für einen einzelnen AMP-Artikel sind drei URLs relevant: die ursprüngliche Publisher-URL, die AMP-Cache-URL unter cdn.ampproject.org und die Google-AMP-Viewer-URL, die wie https://www.google.com/amp/s/[your-domain]/[path] aussieht. Da das Prerendering einen Same-Origin-Iframe benötigt, liefert der Viewer deine Inhalte unter einer google.com-URL aus — Nutzer sehen also Googles Domain, nicht deine. Das war eine echte Quelle für Markenverwirrung und Zuordnungsprobleme.

Signed Exchange (SXG) ist die Lösung. Dabei wird das AMP-Dokument in eine kryptografische Signatur eingebettet, die an deine URL gebunden ist. Wenn Chrome sie validiert, zeigt der Browser deine eigene Domain in der Adresszeile. Google priorisiert Signed Exchange gegenüber dem AMP Viewer, wenn es unterstützt wird. Die Einschränkungen: SXG funktioniert nur in Chrome, Signaturen gelten höchstens 7 Tage (der Packager muss also neu signieren), es ist auf Rich Results und einfache Ergebnisse beschränkt (keine Karussells), und du musst einen amppackager-Server oder einen Drittanbieter-SXG-Provider betreiben. Es ist die „richtige“ Auslieferungsmethode, aber mit erheblichem Betriebsaufwand verbunden.

AMP-Canonical-Tags

Hier gehen AMP-Implementierungen am häufigsten kaputt. Es gibt zwei Setups:

• Gekoppelt (am häufigsten): eine Nicht-AMP-Seite und eine separate AMP-Seite.
  • Die Nicht-AMP-Seite ist ihr eigener Canonical und ergänzt <link rel="amphtml" href="https://example.com/article/amp/">.
  • Die AMP-Seite ergänzt <link rel="canonical" href="https://example.com/article/">, das zurück auf die Nicht-AMP-Version zeigt.
• Nur AMP: Eine einzelne URL ist zugleich Canonical und AMP und verweist daher auf sich selbst.

Praktische Regeln: Google indexiert die Canonical-URL (AMP wird als Duplikat behandelt). Deshalb solltest du strukturierte Daten auf beiden Versionen einfügen, nur kanonische URLs in deiner Sitemap verwenden und die AMP-Entdeckung über rel="amphtml" steuern. Google dokumentiert genau diese Paarung von rel="amphtml" und rel="canonical" — siehe Über AMP: Inhalte auffindbar machen, wenn dein Setup keinem der beiden Fälle entspricht.

Analytics-Herausforderungen bei AMP

Die Tracking-Komplexität von AMP ist echte Betriebskosten, keine theoretische Sorge:

• Das Referral-Problem. Traffic von gecachten AMP-Seiten erschien historisch als Referral von cdn.ampproject.org statt als organische Suche — die Lösung ist ein Referral-Ausschluss für diese Domain.
• Sitzungsfragmentierung. Der Wechsel von einer gecachten AMP-Seite auf deine Nicht-AMP-Seite startete standardmäßig eine neue Sitzung. Der AMP Linker (der die Client-ID über den URL-Parameter amp_id= über die Grenze zwischen Cache und Website übergibt) fügt sie wieder zusammen.
• GTM für AMP verwendet die Komponente amp-analytics — ein komplexeres Setup als Standard-GTM mit weniger Funktionen.
• GA4 erhielt im Juni 2024 native AMP-Unterstützung; zuvor stützte sich die AMP-Messung auf Community-Implementierungen.

Als Search Engine Land AMP abschaltete, war “a clearer picture of their audience analytics” (Übersetzung) „ein klareres Bild der Analytics ihrer Zielgruppe“ einer der gemeldeten Vorteile — das ist also ein bekanntes Problem.

Andere AMP-Oberflächen (damit du sie nicht vermischst)

• Web Stories (2018 als AMP Stories gestartet und 2020 in Google Web Stories umbenannt) sind ein visuelles, antippbares Story-Format auf AMP-Basis. Sie erscheinen in Suche, Discover und Bilder. Sie unterscheiden sich von normalen AMP-Artikeln.
• AMP for Email bringt interaktive Inhalte (Formulare, Karussells und Echtzeitdaten) in Gmail und einige andere Clients. Das ist eine E-Mail-Funktion, keine Such-SEO-Funktion — es ist gut, ihre Existenz zu kennen, aber sie ist für Rankings nicht relevant.

Bing und AMP

Bing beteiligte sich im September 2016 an der AMP-Open-Source-Initiative und betrieb zeitweise einen eigenen AMP-Viewer und Cache mit eigenem Blitzsymbol. Laut Bing beeinflusste AMP die Ranking-Algorithmen in keiner Weise, und Bings AMP-Unterstützung ist heute größtenteils Geschichte — es gibt kein aktuelles Nachrichtenkarussell, das AMP voraussetzt, und keine prominente AMP-Berichterstattung in den Bing Webmaster Tools. In der Praxis entspricht Bings Haltung der von Google: optional, kein Ranking-Boost.

Solltest du AMP weiterhin einsetzen?

Fälle, in denen es sinnvoll sein kann, AMP beizubehalten:

• Ein Nachrichten- oder Medien-Publisher nutzt bereits AMP, hat wenige Search-Console-Fehler und hohe Wechselkosten.
• Eine Website mit einfachen Inhalten, bei der AMP zufällig der Weg des geringsten Widerstands zu guten Core Web Vitals ist.

Fälle, in denen du es entfernen solltest:

• Unternehmenswebsites mit Funktionen, die AMP nicht unterstützt — genau das war mein Argument bei SMX West: Für ein großes Unternehmen mit komplexer Struktur kann AMP zu schwierig zu implementieren sein und übermäßige Risiken mit sich bringen; außerdem gibt es echte geschäftliche Gründe, Website-Elemente beizubehalten, die AMP nicht zulässt.
• Websites, die AMP nur wegen eines Top-Stories-Badges betreiben, das nicht mehr existiert.
• Websites, bei denen klare Analytics wichtig sind — die AMP-Tracking-Komplexität verursacht reale Kosten.
• Websites, die bereits die Core Web Vitals erfüllen — AMP bringt keinen zusätzlichen Vorteil.
• Jede Website, bei der die AMP-URL-Umschreibung Marken- oder Zuordnungsprobleme verursacht.

Die ehrliche Antwort für 2026: AMP ist optional und rückläufig. Implementiere es für neue Projekte nicht. Bewerte bei bestehenden Projekten die Betriebskosten im Verhältnis zum verbleibenden Nutzen.

So entfernst du AMP (falls du dich dafür entscheidest)

1. Entferne das rel="amphtml"-Tag von deinen kanonischen (Nicht-AMP-)Seiten.
2. Leite die AMP-URLs per 301-Redirect auf ihre kanonischen Nicht-AMP-Entsprechungen weiter.
3. Beende die Überwachung des AMP-Statusberichts in der Search Console.
4. Prüfe in den folgenden Wochen, ob die AMP-Fehler aus der Search Console verschwinden.

Wenn du es korrekt machst, bleiben die kanonischen Seiten indexiert und ranken weiter. Große Publisher, darunter Search Engine Land, haben AMP mit minimalen Traffic-Einbußen entfernt.

Mythen, die man beenden sollte

• „AMP bringt einen Ranking-Boost.“ Nein. AMP ist kein Rankingfaktor; Geschwindigkeit ist es, und AMP ist nur eine Möglichkeit, Geschwindigkeit zu erreichen.
• „Für Top Stories brauchst du AMP.“ Seit Juni 2021 falsch.
• „AMP ist immer schneller als eine normale Seite.“ Nein — der Vorteil kommt vom Prerendering der Cache-Kopie durch Google. Eine schnelle Nicht-AMP-Seite kann eine langsame AMP-Seite übertreffen.
• „AMP-URLs sind deine URLs.“ Nur mit Signed Exchange (nur Chrome). Der Standard-Viewer zeigt google.com/amp/s/….
• „AMP zu entfernen wird den Traffic einbrechen lassen.“ Setze Canonical und Redirects korrekt, dann sind die Auswirkungen typischerweise gering.

Zu den Performance-Signalen, die jetzt tatsächlich zählen, siehe Core Web Vitals und den breiteren Cluster Web Performance.

KI-Zusammenfassung

Eine komprimierte Fassung der Advanced-Version:

• AMP = Accelerated Mobile Pages, Googles 2015 gestartetes Open-Source-Framework für nahezu sofort ladende mobile Seiten durch eingeschränktes HTML/CSS/JS und Prerendering aus dem Google AMP Cache.
• Nie ein Rankingfaktor — Google sagt das ausdrücklich. Geschwindigkeit zählt; AMP ist eine Möglichkeit, sie zu erreichen, nicht die einzige.
• Seit dem Page-Experience-Update vom Juni 2021 nicht mehr für Top Stories erforderlich — die Core Web Vitals haben AMP ersetzt und das AMP-Badge wurde entfernt.
• Auslieferung: Gecachtes AMP erscheint normalerweise unter google.com/amp/s/…; Signed Exchange (SXG) kann es unter deiner eigenen URL ausliefern, ist aber nur in Chrome möglich (maximal 7 Tage gültige Signatur, keine Karussells, Packager erforderlich).
• Canonical-Paarung: Die Nicht-AMP-Seite ist ihr eigener Canonical und trägt rel="amphtml"; die AMP-Seite verweist mit rel="canonical" zurück. Google indexiert den Canonical; füge strukturierte Daten auf beiden Versionen ein und führe in der Sitemap nur kanonische URLs.
• Analytics ist der eigentliche Kostenfaktor: Referral-Problem von cdn.ampproject.org, Sitzungsfragmentierung (behoben mit AMP Linker / amp_id=) und komplexes GTM für AMP. GA4 fügte im Juni 2024 native AMP-Unterstützung hinzu.
• Separate Oberflächen: Web Stories (AMP Stories, 2020 umbenannt) und AMP for Email — keine davon ist Artikel-AMP für die Suche.
• Bing: Beteiligte sich 2016 an AMP, aber AMP beeinflusste Bings Ranking nie; die Unterstützung ist heute größtenteils historisch.
• Entscheidung: optional und rückläufig. Baue kein neues AMP; entferne es (entferne rel="amphtml" und leite die AMP-URLs per 301 weiter), wenn die Betriebskosten den schrumpfenden Nutzen übersteigen.

Offizielle Dokumentation

Primärquellen-Dokumentation der Suchmaschinen und des AMP-Projekts.

Google

• Über AMP — wie Google AMP ausliefert (Viewer gegenüber Signed Exchange), die Aussage „kein Rankingfaktor“ und der Hinweis zum Desktop-Cache.
• AMP-Seiten validieren — AMP Test, Rich Results Test und AMP-Statusbericht in der Search Console.
• Weitere Details zum Page-Experience-Update (April 2021) — die Ankündigung, dass AMP für Top Stories nicht mehr erforderlich ist.
• Überblick über den Google-AMP-Cache und URL-Format des AMP-Cache — wie der Cache AMP speichert und adressiert.
• Was enthält eine AMP-URL? — warum die Viewer-URL für das Prerendering erforderlich ist.
• Signierte Exchanges (SXG) — AMP unter deiner eigenen URL ausliefern.
• AMP für E-Mail — der separate Anwendungsfall für E-Mail.
• GA4-Messung von AMP und Vereinheitlichung von AMP-Sitzungen — die Analytics-Details.

AMP-Projekt

• So funktioniert AMP — die eigene Erklärung des Frameworks zu Einschränkungen und Prerendering.
• AMP mit Signed Exchanges ausliefern — die Implementierungsanleitung.

Bing / Microsoft

• Bing-App beteiligt sich an der AMP-Open-Source-Initiative (Sept. 2016) — Bings Einstieg in AMP.

Zitate aus den Quellen

Nachprüfbare Aussagen von Google und Bing. Jeder Link führt, sofern unterstützt, über einen Deep Link direkt zur zitierten Passage auf der Quellseite.

Google — AMP ist kein Rankingfaktor

• “AMP itself isn’t a ranking factor.” (Übersetzung) „AMP selbst ist kein Rankingfaktor.“ — Google Search Central Docs. Zum Zitat

Google — AMP für Top Stories nicht mehr erforderlich

• “using the AMP format is no longer required” (Übersetzung) „Die Verwendung des AMP-Formats ist nicht mehr erforderlich“ für das Top-Stories-Karussell. Zum Zitat

Google — Signed Exchange wird dem Viewer vorgezogen

• Google “prioritizes signed exchange over AMP Viewer when supported.” (Übersetzung) „Google priorisiert Signed Exchange gegenüber dem AMP Viewer, wenn dies unterstützt wird.“ Zum Zitat

Google — Desktop-AMP wird nicht aus dem Cache ausgeliefert

• “Desktop AMP pages are not currently served from Google AMP Cache; canonical AMP pages behave as standard results.” (Übersetzung) „Desktop-AMP-Seiten werden derzeit nicht aus dem Google AMP Cache ausgeliefert; kanonisches AMP verhält sich wie ein normales Ergebnis.“ Zum Zitat

Bing — AMP ist kein Bing-Rankingfaktor

• “AMP does not impact our ranking algorithms in any way.” (Übersetzung) „AMP beeinflusst unsere Ranking-Algorithmen in keiner Weise.“ — Bings Group Engineering Manager zur Zeit des AMP-Starts. Berichterstattung lesen

AMP beibehalten, entfernen oder vermeiden?

Ziehst du AMP für ein neues Projekt in Betracht? Füge es nicht wegen SEO hinzu. AMP ist kein Rankingfaktor und für Top Stories nicht mehr erforderlich. Baue die kanonische Website direkt so, dass sie ihre Performance- und Veröffentlichungsanforderungen erfüllt.

Betreibst du bereits AMP-Seiten? Fahre nur fort, wenn die AMP-Version weiterhin einen gemessenen geschäftlichen oder auslieferungsbezogenen Vorteil bietet, der die Kosten einer zweiten Implementierung übersteigt.

• AMP ist stabil, günstig und materiell nützlich: Behalte es bei, prüfe aber Canonical-Paarung, Validierung, Analytics und Inhaltsgleichheit.
• AMP existiert nur wegen einer alten Top-Stories-Anforderung: Plane die Entfernung.
• AMP verursacht Analytics-, Funktions-, Marken- oder Wartungsprobleme: Entferne es mit URL-für-URL-Redirects auf die kanonischen Entsprechungen.
• Die kanonischen Seiten erfüllen deine Performance-Anforderungen noch nicht: Behebe das zuerst und migriere dann; entferne die funktionierende Version nicht ohne Ersatz.

AMP-Wartungs- und Entfernungscheckliste

Wenn AMP bleibt

• Jede kanonische Seite verweist mit rel="amphtml" auf ihr AMP-Gegenstück.
• Jede AMP-Seite verweist per Canonical zurück auf die entsprechende Nicht-AMP-URL.
• Inhalte und strukturierte Daten bleiben in beiden Versionen gleichwertig.
• AMP-Dokumente werden nach Änderungen an Templates, Komponenten und Werbung validiert.
• Analytics erhält Attribution und Sitzungen über die Navigation vom Cache zur Website hinweg.
• Nur kanonische URLs erscheinen in der XML-Sitemap.

Wenn AMP entfernt wird

• Bestätige, dass die kanonischen Seiten den vollständigen Inhalt enthalten und die Performance-Abnahmekriterien des Teams erfüllen.
• Entferne rel="amphtml" von den kanonischen Seiten.
• Ordne jede AMP-URL ihrem exakten kanonischen Gegenstück über einen permanenten Redirect zu.
• Teste Canonicals, strukturierte Daten, interne Links und Analytics am Ziel erneut.
• Überwache die Search Console, während AMP-Berichte verschwinden und kanonische URLs erneut gecrawlt werden.

AMP-Fehler, die du vermeiden solltest

AMP wegen eines nicht vorhandenen Ranking-Boosts beibehalten

AMP war nie ein Rankingfaktor und ist seit 2021 für Top Stories nicht mehr erforderlich. Behalte es nur wegen eines aktuellen, gemessenen betrieblichen Vorteils.

Zwei auseinanderlaufende Versionen veröffentlichen

Eine AMP-Seite mit dünnerem Text, fehlenden strukturierten Daten oder anderen Handlungsaufforderungen erzeugt Gleichheits- und Wartungsprobleme. Verwende eine gemeinsame Inhaltsquelle und validiere beide Ausgaben.

AMP ohne URL-spezifische Redirects entfernen

AMP-Endpunkte zu löschen oder alle auf eine Startseite zu schicken, zerstört die etablierte URL-Beziehung. Leite jede AMP-URL auf ihre passende kanonische Seite weiter.

Den Erfolg erklären, weil das Dokument validiert

Die Validierung beweist AMP-Konformität, nicht Analytics-Kontinuität, korrekte Canonicals, Inhaltsgleichheit oder gute Nutzerergebnisse. Teste den gesamten Auslieferungsweg.

AMP-Spickzettel

Die Fakten, die für die meisten Diskussionen entscheidend sind

Die Canonical-Paarung

Sitemaps / strukturierte Daten: Die Sitemap listet nur kanonische URLs; füge strukturierte Daten auf beiden Versionen ein.

Kurzfakten zu Auslieferung und Analytics

• Gecachtes AMP wird normalerweise unter cdn.ampproject.org / google.com/amp/s/… ausgeliefert.
• SXG = deine URL in der Adresszeile, nur Chrome, maximal 7 Tage gültige Signatur, keine Karussells.
• Schließe cdn.ampproject.org als Referral aus; verwende den AMP Linker (amp_id=), um Sitzungen zusammenzuführen.
• Native AMP-Unterstützung in GA4: Juni 2024.

AMP entfernen

1. rel="amphtml" von kanonischen Seiten entfernen → 2. AMP-URLs per 301 auf den Canonical weiterleiten →
2. AMP-Überwachung in GSC beenden → 4. prüfen, ob die Fehler verschwinden.

Validieren: AMP Test (search.google.com/test/amp), Rich Results Test, AMP-Statusbericht der GSC.

AMP-Audit-Befehle

AMP-Beziehungen in einem Crawl-Export finden

Verwende diesen regulären Ausdruck in einer benutzerdefinierten Extraktion eines Crawlers auf dem HTML-Quelltext:

<link\s+[^>]*rel=["'](?:amphtml|canonical)["'][^>]*href=["']([^"']+)["'][^>]*>

Erfassungsgruppe 1 gibt die verknüpfte AMP- oder Canonical-URL zurück. Prüfe die extrahierten Paare auf fehlende, domainübergreifende oder Viele-zu-eins-Zuordnungen.

Einen AMP-Redirect während der Entfernung prüfen

Führe dies in einem Terminal aus und ersetze die Beispiel-URL:

curl -sSIL https://example.com/article/amp/

Die erste Antwort sollte ein permanenter Redirect sein, und ihr endgültiges Ziel sollte der exakte kanonische Artikel ohne vermeidbare Weiterleitungskette sein.

AMP-Links im aktuellen Dokument inventarisieren

Führe dies in der Chrome-DevTools-Konsole auf einer kanonischen oder AMP-Seite aus:

[...document.querySelectorAll('link[rel="amphtml"], link[rel="canonical"]')].map(link => ({ rel: link.rel, href: link.href }))

Tools zur Wartung oder Entfernung von AMP

• AMP Validator: Prüfe, ob das veröffentlichte Dokument nach Änderungen an Templates und Komponenten den AMP-Markup-Regeln entspricht.
• Search-Console-URL-Inspection: Vergleiche den indexierten Canonical und die gerenderte Ausgabe repräsentativer Canonical- und AMP-URLs.
• AMP-Statusbericht der Search Console: Nutze ihn, solange AMP eingesetzt wird, um templateweite Validierungsfehler zu finden; nach einer geplanten Entfernung sollte das Inventar zurückgehen.
• PageSpeed Insights: Bestätige, dass der kanonische Ersatz das Performance-Ziel erfüllt, für das AMP eingesetzt wurde; teste die kanonische URL, nicht nur die gecachte AMP-Kopie.
• Crawler mit benutzerdefinierter Extraktion: Inventarisiere amphtml-/Canonical-Paare und prüfe, ob jede ausgemusterte AMP-URL auf ihr entsprechendes kanonisches Ziel weiterleitet.

Eine AMP-Änderung validieren

Canonical-Paarung nach einer AMP-Template-Veröffentlichung testen

Durchzuführender Test: Repräsentative Paare crawlen und amphtml- sowie Canonical-Links extrahieren. Erwartetes Ergebnis: Der Canonical verweist auf genau eine passende AMP-URL und die AMP-Seite zurück auf diesen Canonical. Fehlerinterpretation: Entdeckungs- oder Konsolidierungssignale sind beschädigt. Überwachungsfenster: Sofort. Rollback-Auslöser: Fehlende, gekreuzte oder Viele-zu-eins-Zuordnungen erscheinen.

Einen AMP-Entfernungs-Redirect testen

Durchzuführender Test: Fordere ein Beispiel aus jedem AMP-URL-Muster mit deaktivierter und anschließend aktivierter Redirect-Verfolgung an. Erwartetes Ergebnis: Ein permanenter Hop zum exakten kanonischen Gegenstück, der erfolgreich antwortet. Fehlerinterpretation: Die Migrationszuordnung ist unvollständig oder verkettet. Überwachungsfenster: Sofort nach dem Deploy und während des erneuten Crawls. Rollback-Auslöser: AMP-URL-Fehler, Schleifen oder ein generisches Ziel.

Das Erlebnis des kanonischen Ersatzes testen

Durchzuführender Test: Führe das kanonische Ziel durch PageSpeed Insights und die Analytics-QA. Erwartetes Ergebnis: Der Ersatz erfüllt die festgelegte mobile Performance-Basis und erhält die erwartete Messung. Fehlerinterpretation: AMP wurde entfernt, bevor seine Auslieferungs- oder Tracking-Rolle ersetzt war. Überwachungsfenster: Laborprüfungen sofort; Felddaten über das normale rollierende Fenster. Rollback-Auslöser: Systematische Performance-Verschlechterung oder Verlust erforderlicher Messungen nach der Migration.

Teste dich selbst: AMP-SEO

Fünf kurze Fragen dazu, was AMP ist, was es tut und welchen Stellenwert es heute hat. Wähle jeweils eine Antwort und prüfe anschließend.

Ressourcen, die sich lohnen

Meine Texte

• Der Einsteigerleitfaden für technische SEO — dort wird erklärt, wie mobile Performance und AMP in das größere Bild gehören.

Meine Vorträge

• AMP: Sein oder Nichtsein? — Rückblick auf die SMX-West-Session 2018 (Search Engine Land) — meine „wütender alter Mann“-Position dazu, dass AMP möglicherweise nicht für jedes Unternehmen die richtige Lösung ist, besonders nicht für große Unternehmen mit komplexen Strukturen und Funktionen, die AMP nicht unterstützen kann.

Offiziell

• Google — Über AMP und AMP-Seiten validieren.
• Google — Weitere Details zum Page-Experience-Update (April 2021) — AMP für Top Stories nicht mehr erforderlich.

Aus der Branche

• Warum dieser Verlag AMP-Seiten abschaltet — die Entscheidung eines großen Verlags, AMP abzuschalten.
• Was geschah, als wir AMP abschalteten (Branchenverlag) — die Nachbetrachtung: sehr wenig Traffic-Unterbrechung und klarere Zielgruppen-Analytics.
• Werden Verlage AMP aufgeben, wenn es für Top Stories nicht mehr erforderlich ist? (Branchenverlag).
• Google AMP ist tot! (Plausible Analytics) — die Einschätzung „AMP geht zurück“ plus der Kontext der kartellrechtlichen Prüfung hinter Googles Aufgabe der Anforderung.
• Google AMP und SEO: Alles, was Sie wissen müssen (Search Engine Journal) — eine technische Anleitung einschließlich Canonical-Handhabung.
• Gute Nachricht: Google verlangt von Publishern kein AMP mehr (Branchenmedium) — Berichterstattung über den Wechsel zu den Core Web Vitals.

Videos

• Google Search Central (YouTube) — die Reihe So funktioniert die Google-Suche sowie Martin Splitts Erklärungen zu Page Experience und Core Web Vitals; sie behandeln die Performance-Signale, welche AMP für Top Stories ersetzt haben. Kanal

Änderungsprotokoll