Bei den Accelerated Mobile Pages, oder kurz: AMP, handelt es sich um eine Initiative, die das Ziel hat Webseiten schneller laden zu lassen. Hierzu wird die Gestaltungsfreiheit der Webseite zwar stark eingeschränkt, führt jedoch dazu, dass keine aufgeblähten und langsamen Webseiten zustande kommen. Doch was genau ist AMP?
- Wichtiger Hinweis zu AMP
- Was sind Accelerated Mobile Pages?
- Warum gibt es die Accelerated Mobile Pages überhaupt?
- Wie schwierig war es, auf Accelerated Mobile Pages umzustellen?
- Technische Voraussetzungen von Accelerated Mobile Pages
- Wie verlinkt man Accelerated Mobile Pages?
- Canonical-Setup selbst prüfen
- Strategische Überlegungen vor der Umstellung auf Accelerated Mobile Pages
- Welche Vorteile brachten Accelerated Mobile Pages?
- Welche Nachteile hatten Accelerated Mobile Pages?
- Wie sah es mit Online-Werbung auf Accelerated Mobile Pages aus?
- Fazit zu AMP
Wichtiger Hinweis zu AMP
Das AMP-Framework hat in der modernen Webentwicklung in den letzten Jahren stark an Bedeutung verloren. Gemäß den aktuellen Richtlinien von Google werden AMP-Seiten in den Suchergebnissen exakt wie herkömmliche HTML-Seiten behandelt. Google hat zudem den AMP Viewer und den Google AMP Cache für Suchergebnisse eingestellt. Nutzer werden beim Klick nun direkt auf die Domain des Website-Betreibers geleitet. Wer heute eine neue Website aufbaut, sollte auf natives, responsives Design und die Optimierung der Core Web Vitals (wie LCP und INP) setzen, anstatt ein separates AMP-System zu pflegen.
Was sind Accelerated Mobile Pages?
Das Projekt Accelerated Mobile Pages (wörtlich: beschleunigte Mobilseiten) ist ein Open-Source-Projekt, das 2015 von Google angekündigt und 2016 zur Verfügung gestellt wurde. AMP ist eine Reaktion auf die zunehmende Nutzung von mobilen Endgeräten und den daraus resultierenden neuen Anforderungen an Websites.
Mit AMP entstanden HTML-Seiten, die deutlich schneller als „normale“ Webseiten auf mobilen Endgeräten laden. Um das zu erreichen, sind bei AMP nur eine begrenzte Zahl von HTML- und CSS-Elementen verfügbar. In der Anfangszeit stand ausschließlich eine JavaScript-Library zur Verfügung, die nicht angepasst werden konnte. Mittlerweile dürfen externe JavaScript-Dateien asynchron über die „amp-script„-Komponente eingebunden werden.
Die technischen Anforderungen von AMP priorisieren die Ladegeschwindigkeit, um dem Besucher eine gute (schnelle) Nutzererfahrung zu bieten. Dabei sollen die Inhalte weiterhin individuell gestaltbar sein.
AMP-Seiten luden ursprünglich vor allem deswegen so schnell, weil Google die entsprechenden Webseiten auf eigenen Servern speicherte, also einen eigenen Cache der Daten vorhielt, der dann von Google selbst ausgeliefert wurde.
Damit umging Google die Gefahr, dass langsame Server einer Seite das schnelle Ausspielen der Seite verhinderten.
Vor diesem Hintergrund wies Google AMP-Seiten in den Suchergebnissen lange gesondert aus und betrieb ein eigenes News-Karussell für Accelerated-Mobile-Page-Beiträge. Seit 2021 ist AMP jedoch keine Voraussetzung mehr für die Aufnahme in die Top Stories, das AMP-Blitz-Symbol in den Suchergebnissen wurde ebenfalls entfernt. Wie oben beschrieben liefert Google AMP-Seiten seit Juli 2026 zudem nicht mehr aus dem eigenen Cache aus.
Warum gibt es die Accelerated Mobile Pages überhaupt?
Es lässt sich nicht abstreiten, dass AMP in direkter Konkurrenz zu Facebooks „Instant Articles“ stand. Und auch Google merkte, dass immer mehr Nutzer die Google-Suche von mobilen Endgeräten aus nutzten. Da es zu Googles wichtigsten Aufgaben gehört, Nutzern die bestmöglichen Ergebnisse in jeder Hinsicht zu liefern, war eine schnelle Ladezeit ein kritischer Faktor. Diese war insbesondere im Mobilnetz häufig ein Schwachpunkt vieler Seiten.
So sahen die Antworten auf die Frage „Was stört dich am meisten beim Browsen auf mobilen Endgeräten?“ wie folgt aus:
Wie schwierig war es, auf Accelerated Mobile Pages umzustellen?
Die Umstellung auf AMP war nicht „mal eben gemacht“. Wir liefern dir Antworten auf häufig aufgetretene Fragen.
Technische Voraussetzungen von Accelerated Mobile Pages
In gewisser Hinsicht machte es AMP einem einfach. Durch die Restriktionen bei JavaScript und CSS wurden die Möglichkeiten zwar eingeschränkt, ließen jedoch weiterhin viel Spielraum für die Umsetzung der eigenen Corporate Identity und forderten Webmaster, schnelle Seiten zu gestalten und umzusetzen.
Konnte mein aktuelles Content-Management-System mit Accelerated Mobile Pages umgehen?
Content-Management-Systeme boten eigene oder externe AMP-Plug-ins an, die bei der Auslieferung entsprechender Seiten halfen. Hier lohnte es sich zu prüfen, wie groß der Anpassungsbedarf für die eigene Seite war, um die notwendigen Entwicklerressourcen einzuplanen.
Hatte man genügend Entwicklungsressourcen, um zwei unterschiedliche Code-Stände zu unterhalten?
Accelerated Mobile Pages nutzten angepasstes HTML. Es gab dabei durchaus Methoden, regulären HTML-Quellcode in AMP-HTML umzuwandeln, zumindest solange das eigene Design nicht zu stark auf JavaScript setzte. Denn in diesem Fall konnte es passieren, dass ein angepasstes Template für die gewünschte AMP-Seite notwendig wurde. Dieses musste dann natürlich mit allen weiteren Ressourcen aktuell gehalten werden.
Wie verlinkt man Accelerated Mobile Pages?
AMP-Artikel haben eigene URLs. Die Zusammengehörigkeit von Artikeln, die sowohl auf einer HTML-Seite als auch in AMP verfügbar sind, muss Google kenntlich gemacht werden.
Das geschieht, ähnlich wie auch bei mobilen Seiten, dadurch, dass auf der AMP-Seite ein Canonical, <link rel="canonical" href="/article.html">, auf die HTML-Seite gesetzt wird. Auf der HTML-Seite selbst soll die AMP-Version per <link rel="amphtml" href="/article.amp.html"> eingebunden werden.
Quelle: https://amp.dev/static/img/docs/tutorials/tut-convert-html-link-between.png
Dabei war es sehr wichtig, dass die Bidirektionalität der Verlinkung (HTML sollte immer auf AMP und AMP immer auf HTML zeigen) immer gegeben war. Sonst konnte es passieren, dass man Google verwirrte und es zu Problemen kam.
Canonical-Setup selbst prüfen
Ob die Canonical-Verknüpfung zwischen HTML- und AMP-Version (oder allgemein zwischen doppelten Seiten-Varianten) korrekt gesetzt ist, kannst du mit dem Onpage-Crawl in den Onpage-Projekten von SISTRIX prüfen. Der Crawl erkennt unter anderem Duplicate Content und fehlende oder falsche Canonical-Tags, bevor sie zu Indexierungsproblemen führen. Teste SISTRIX 14 Tage kostenlos und überprüfe deine Website nach Duplicate Content und der richtigen Canonical-Setzung.
Strategische Überlegungen vor der Umstellung auf Accelerated Mobile Pages
Auf der strategischen Seite gab es einige wichtige Überlegungen, die helfen konnten, eine Entscheidung in Sachen AMP zu treffen:
War man in einer Branche tätig, in der AMP zum Einsatz kam?
Accelerated Mobile Pages kamen vor allem bei Newsseiten zum Einsatz. Eine weitere Branche, auf die das Format AMP abzielte, war E-Commerce. Es konnte also durchaus lohnenswert sein zu bedenken, in wie weit Google sich zur Nutzung von AMP in der eigenen Nische geäußert hatte oder äußern würde.
Im besten Fall hatte man die notwendigen Infrastruktur- und Prozessanpassungen rechtzeitig fertig, um einen Wettbewerbsvorteil zu erhaschen, sobald Google AMP für die eigene Branche pushte. Im schlimmsten Fall hatte man viel Geld und Zeit in etwas investiert, das für den eigenen Bereich keine Vorteile brachte, falls Google sich entschied, dass AMP für diesen Sektor nicht die beste Wahl für die Nutzer war.
Wollte man die eigene Infrastruktur auf etwas umstellen, bei dem nicht klar war, dass es auch in zwei Jahren noch existieren würde?
AMP gab es seit Oktober 2015 und im Newsbereich hatte sich der Standard zeitweise etabliert. Google versuchte die Verbreitung mit seiner Marktmacht voranzutreiben. Wie sich inzwischen zeigt, hat sich AMP als eigener Standard für andere Bereiche als News jedoch nicht durchgesetzt, und auch die Sonderrolle im Newsbereich ist mit den Änderungen von 2021 und 2026 weitgehend entfallen.
Wie bekam man die Besucher von dem Accelerated Mobile Page Artikel auf die eigene Seite?
Nutzer, die in den Google-Suchergebnissen auf ein AMP-Ergebnis klickten, kamen früher auf die von Google auf Google-Servern gespeicherte Version der Webseite. Das Tracking dieser Nutzer als Leser war möglich, jedoch aufwendig.
Wer die Leser zudem aus Googles Cache auf die eigene Webseite ziehen wollte, musste es schaffen, Besucher für einen weiteren Artikel zu interessieren und entsprechend ansprechende Links, Buttons oder sonstige Interaktionsmöglichkeiten zu bieten.
Welche Vorteile brachten Accelerated Mobile Pages?
Accelerated Mobile Pages brachten Vorteile für Besucher und Seitenbetreiber gleichermaßen.
Für die Besucher konnte sich ein merklicher Geschwindigkeitsanstieg bei der Ladezeit der Seite einstellen, besonders wenn sie in einem 3G- oder 2G-Netz unterwegs waren. Damit wurde natürlich die Nutzerzufriedenheit der eigenen Seite gesteigert. Zudem lud Google den direkt sichtbaren Teil der Artikel aus dem Accelerated-Mobile-Page-Karussell schon vor, bevor ein Nutzer überhaupt auf ein AMP-Ergebnis klickte (Prerendering), was zu einer noch schnelleren Ladezeit beitrug. Dieser Mechanismus ist mit der Einstellung des AMP-Viewers im Juli 2026 entfallen.
Als Webseitenbetreiber übergab man durch die Speicherung der Seite im Google-Cache den Ressourcenaufwand für eine schnelle Ausspielung der Seite an Google. Es war davon auszugehen, dass Googles Server stark genug waren, um selbst großen Besucherströmen standzuhalten. Somit fielen bei der Auslieferung dieser Seiten keine Traffickosten für die eigene Seite an.
Die Einschränkung der Gestaltungsmöglichkeiten des HTML-Quelltextes sowie der CSS- und JavaScript-Möglichkeiten konnte zu einer Fokussierung auf die „echten“ Bedürfnisse der Besucher führen, da der Aufbau der Seite mit einem Minimum an Werkzeugen erledigt werden musste.
Die AMP-Dokumente im Google-Cache wurden im Sinne der Ladezeit weiter optimiert, so wurden zum Beispiel große Bilder verkleinert. Ein weiterer Vorteil: Ein AMP-Karussell in den Suchergebnissen wurde häufig oberhalb des ersten organischen Ergebnisses angezeigt, was zu mehr Besuchern führte.
Welche Nachteile hatten Accelerated Mobile Pages?
Die URL stammte nicht von der eigenen Domain
Dadurch, dass Google die AMP-Seiten aus dem eigenen Cache auslieferte, war der Nutzer nicht wirklich auf der Seite, sondern immer noch bei Google. Im Browser ließ sich die Google-URL einsehen, auf Smartphones war dies jedoch nicht so tragisch, da Google die Quell-Seite des Artikels oben auf dem Accelerated-Mobile-Page-Ergebnis anzeigte. Seit der Einstellung von AMP-Cache und AMP-Viewer im Juli 2026 landen Nutzer beim Klick direkt auf der eigenen Domain, dieser Nachteil besteht also nicht mehr.
Vor diesem Hintergrund war es wichtig, die Analytics-Anbindung zu prüfen, damit die Nutzer korrekt der eigenen Domain zugeordnet werden konnten. Gleiches galt für die Werbeanzeigen und -einnahmen.
Damit Links auf entsprechende Artikel nicht auf Googles Cache-URL des Artikels zeigten, setzte Google automatisch einen Canonical-Tag auf der AMP-Seite, der auf das korrekte Dokument der Domain zeigte.
Auf Googles Entwicklerkonferenz I/O 2018 wurden zudem „Signed HTTP Exchanges“ angekündigt. Mit dieser technischen Lösung sollte es möglich werden, die eigene URL auch auf den von Google gecachten AMP-Seiten anzuzeigen. Mit der Einstellung von AMP-Cache und AMP-Viewer im Juli 2026 hat Google auch die Erwähnungen von Signed Exchanges aus der eigenen AMP-Dokumentation entfernt, das Thema hat sich damit erübrigt.
Andere Accelerated-Mobile-Page-Artikel waren nur einen Swipe entfernt
Eine zentrale Eigenschaft bei Google war es, dass man AMP-Artikel per Swipe (nach links oder rechts ziehen des Bildschirms) wechseln konnte. Daraus folgte, dass Nutzer mit einem „Wisch“ auf dem Artikel eines anderen Anbieters landen konnten. Da diese Funktion Teil des inzwischen eingestellten AMP-Viewers war, existiert sie heute nicht mehr.
Google ging hier der Reihenfolge nach, die auch im AMP-Karussell angezeigt wurde. Dieses Feature bedeutete, dass möglicherweise ein Beitrag der direkten Konkurrenz zum gleichen Thema mit einer einfachen Handbewegung erreichbar war. Es lohnte sich also durchaus, sich tiefgründige Gedanken dazu zu machen, wie man Besucher von einer Accelerated Mobile Page auf die eigene Domain bekommen konnte.
Wie sah es mit Online-Werbung auf Accelerated Mobile Pages aus?
AMP bot trotz aller Beschränkungen die Möglichkeit, Werbung auszuspielen. Die Werbeblöcke mussten entsprechend ausgezeichnet werden, was zusätzlichen Entwicklungsaufwand mit sich zog.
AMP-Seiten luden Werbung erst vollständig, wenn die Inhalte der Seite fertig geladen waren und genutzt werden konnten.
Eine weitere Möglichkeit fand sich durch AMP for Ads (A4A), bei dem Erkenntnisse aus der Entwicklung von Accelerated Mobile Pages auf das Ausliefern von Ads angewandt wurden. Hierbei war es natürlich notwendig, sich beim jeweiligen Ad-Netzwerk zu erkundigen, ob und in wie weit dieses Format angeboten wurde.
Für weiterführende Informationen schau dir bitte https://amphtml.wordpress.com/2016/07/19/but-what-about-the-ads/ näher an.
Fazit zu AMP
Mit den Accelerated Mobile Pages hatte Google ein Konstrukt geschaffen, um mit Facebooks Instant Articles zu konkurrieren, gleichzeitig war es auch durchaus verständlich, dass Google seinen Nutzern die schnellstmöglichen Ergebnisse anbieten wollte.
Google hatte ein großes Interesse daran, dass ausgespielte Webseiten in den Suchergebnissen schnell laden. Langsame Seiten führten zu Unzufriedenheit und Absprüngen bei Nutzern, was möglicherweise auf die Qualität der Suchmaschine selbst projiziert wurde. Im langsameren mobilen Netz kam diesem Faktor daher eine besondere Bedeutung zu.
Wie sich inzwischen zeigt, hat sich AMP nicht als dauerhafter neuer Standard durchgesetzt. Google hat seine Sonderbehandlung für AMP-Seiten Schritt für Schritt zurückgefahren, von der Streichung als Top-Stories-Voraussetzung 2021 bis zur vollständigen Einstellung von AMP-Cache und AMP-Viewer im Juli 2026. Wer heute an schnellen mobilen Seiten arbeitet, sollte den Fokus auf natives, responsives Design und die Optimierung der Core Web Vitals legen, statt ein separates AMP-System aufzubauen oder zu pflegen.
SISTRIX kostenlos testen
- Kostenloser Testaccount für 14 Tage
- Unverbindlich, keine Kündigung notwendig
- Persönliches Onboarding durch Experten
