Im Laufe der Jahre haben sich das Internet und die Funktionalität rund um das tägliche Leben so weiter entwickelt, dass die User in den meisten Fällen mit den Smartphones im Internet surfen. Somit ist es unabdingbar eine Website zu haben, die nicht nur schnell lädt, nein diese muss auch auf die mobilen Endgeräte abgestimmt sein. Google hat hierfür im Jahre 2015 „Mobile Friendly“ ins Leben gerufen gehabt. Ihr lest hier richtig, „gehabt“. Es wurde mächtig an der Werbetrommel gerührt und die Webseitenbetreiber in Aufruhr gebracht, dass die eigenen Webseiten auch ja „Mobile Friendly“ sein müssen. Dies Google hat dafür sogar eigene Tools auf den Markt gebracht, um die Funktionalität der eigenen Seite zu testen, wie z.B.: https://search.google.com/test/mobile-friendly.

Durch die fortwährende Einführung und Umstellung der Webseiten auf den Mobile-First-Index, der die mobile Seite zur Bewertung und Einstufung in den SERPs heranzieht, ist es unabdingbar, die eigene Seite für mobile Endgeräte optimiert zu haben. Nach und nach hat sich Google von dem Label „Mobile Friendly“ wieder verabschiedet, da bisher 85% der Webseiten mobil perfekt aufrufbar sind. Dem Label „Mobile Friendly“ steht nun das Responsive Webdesign (RWD) entgegen, dass nun jedem geläufig ist. Wer seine jetzt jetzt noch nicht für mobile Endgeräte aufgesetzt hat, wird es auch nicht mehr machen, davon ist auszugehen.

Der Umschwung zum responsive Webdesign (RWD)

Nachdem „Mobile Friedly“ ausgestorben war, auch weil sich die Webseitenbetreiber nun dazu bekannt haben, erstellen diese nun Webseiten im Responsive Webdesign. Diese dienen dazu, dass der User mittels Smartphone, oder Tablet eine Webseite angezeigt bekommt, die genau auf das verwendete Gerät ausgelegt ist. So sind alle Elemente so aufeinander abgestimmt, dass sich alles auf ein und derselben URL befindet und nicht wie in den Anfängen eine eigene mobile Version in den Index gejagt wurde und so duplicate Content verursachte. Die Darstellung der Website stellt sich nun mittels Abfrage der Bildschirmgröße und den dann im Cascading-Style-Sheet (CSS) eingetragenen Werten so zusammen, dass sich ein stimmiges Bild ergibt. Der User bekommt alle Daten so aufbereitet, dass er sozusagen ein barrierefreies  Nutzererlebnis hat. Alle Buttons, oder Icons sowie die Schrift sind genau auf das Device abgestimmt und verdrängen so immer mehr die Nutzung eines Desktop-PCs. Durch RWD ist die Nutzung der mobilen Endgeräte im Jahr 2018 höher, als die Nutzung von Desktop-Geräten. Auch wenn die Zugriffe dank RWD zunehmen, so werden doch bestimmte Conversions nur über Desktop-Geräte erzielt. Ein Beispiel ist hier z.B. die Kontoeröffnung bei einer Bank. Die Informationen über verschiedene Kontotypen wird noch über das mobile Endgerät erfolgen, aber der Abschuss wird NOCH in den meisten Fällen mit dem Desktop-PC durchgeführt, da hier die Hemmschwelle noch zu groß ist, wobei sich die Zahl auch langsam aber sicher nach oben entwickelt.

AMP – Was steckt dahinter?

Gerade in der jüngeren Zeit ist AMP schon geläufig. die Abkürzung steht für Accelerated Mobile Pages. Wenn es ins Deutsche übersetzt werden soll, dann wird hier von beschleunigten Mobilseiten gesprochen. AMP ist dafür da, dem Nutzer schnellstmöglich Informationen zu liefern, insbesondere dann, wenn sich der Suchende in einem Gebiet befindet, mit einer sehr niedrigen Bandbreite. Hier wird auch von sog. AMP-Dokumenten gesprochen. AMP wurde zunächst nur für den News-Bereich entwickelt, um so immer schnell neue Nachrichten an jeden darbringen zu können. Der Aufbau eines AMP-Dokuments ist sehr schlank gehalten, damit auch die schnellen Ladezeiten gewährleistet werden können. Die AMP-Seite muss der gängigen AMP-HTML-Spezifikation entsprechen. Bei der Entwicklung von AMP-Seiten muss ein Entwickler einige Einschränkungen im HTML hinnehmen, wie z.B.:

• Gängige HTML Elemente sind nicht zugelassen und müssen durch entsprechende AMP-Anweisungen ersetzt werden.
• Eigens entwickelte JavaScript-Schnipsel sind ausgeschlossen. Es gibt nur bestimmte eigene AMP-Skripte, die verwendet werden dürfen.
• Das CSS wird direkt in den <HEAD>-Bereich implementiert, da keine externe Datei verendet werden darf.
• Es dürfen keinerlei Inline-Styles verwendet werden.
• Es dürfen nur Werbebanner verwendet werden, die für AMP freigegeben wurden.
• Die Webseiten liegen auf Google-Servern und werden von dort an die Nutzer verteilt.

Inhalte, die durch AMP beeinflusst werden, sind innerhalb der SERPs entsprechend gekennzeichnet. Die Entwickler haben sich hier für einen Blitz (⚡) entschieden. Goggle hält es hier ganz streng, was die Umsetzung der AMP-Programmierung angeht. Sollte auch nur ein kleiner Teil nicht den Vergaben entsprechen, werden diese von der Indexierung ausgenommen, oder im Nachgang deindexiert. In der „alten“ Google Search Console gibt es die Möglichkeit, sich den Indexierungsstatus der AMP-Seiten anzuschauen. dies ist zu finden unter: Darstellung in der Suche à Accelerated Mobile Pages

Auch in den neuen Berichten der Google Search-Console gibt es die Möglichkeit, sich den Indexierungsstatus anzusehen. Dort ist der Bericht über AMP folgendermaßen auffindbar: Verbesserungen –> AMP

Unterstützte und verbotene Anweisungen bei AMP

Es gibt eine Vielzahl an AMP Spezifikationen, die bei der Erstellung der Seite beachtet werden müssen. So gibt es drei Arten von Tags, nicht unterstützte, eingeschränkte und AMP-Tags. Die Nachfolgende Tabelle zeigt auf, wie sich das verhält.

 

Nicht unterstützte Tags	Eingeschränkte Tags	Ersetzte Tags
base	script (Ist nur erlaubt, um AMP Komponenten zu laden oder der Auszeichnung von strukturierten Daten à type=“application/ld+json“)	img ⇒ amp-img
frame	style (Ein weiters Style Tag mit dem Attribut amp-custom ist im Head gedultet)	video ⇒ amp-video
frameset	link (rel-Attribute, die auf microformats.org registriert sind, durfen verwendet werden. Des Weiteren gibt es Ausnahmen, um benutzerdefinierte Fonts einzubinden)	audio ⇒ amp-audio
object	meta (http-equiv-Attribut darf nicht verwendet werden)	iframe ⇒ amp-iframe
param	svg
applet	a (Der Wert des href Attributs darf nicht mit javascript: beginnen)
embed
form (Zukünftiger Support wurde bereits angekündigt)
input Elemente, textarea, select, option etc. (Davon ausgenommen ist das <button>-Tag)

 

Was passiert mit der Conversion bei AMP-Seiten?

Keine Angst, AMP-Seiten dienen dazu, dass der erste Kontakt schneller von statten geht, gerade in Gebieten mit schlechter Internetverbindung ist es von großer Bedeutung, wenn die Inhalte schnell angezeigt werden. Durch die AMP-Seite wird dies auf alle Fälle gewährleistet. Der eigentliche Abschluss, sei es PDF-Download, oder der Kauf eines Produktes wird immer auf der eigentlichen Kundenseite stattfinden.

Fazit

Mobile Friendly ist tot, es lebe responsive Webdesign. Ganz klar, wer heute seine Webprojekte nicht für mobile Endgeräte optimiert hat, der sollte seine komplette Struktur überdenken. Wichtige Punkte sind, gerade durch Mobile First, eine responsive Seite zu haben. Des Weiteren ist eine geringe Ladezeit von Vorteil. Wer AMP nutzen möchte kann dies gerne machen. Es ist kein Zwang. Sollte die eigene Seite schon so geringe Ladezeiten haben, z.B. unter drei Sekunden, dann kann getrost auf AMP verzichtet werden, auch in Gebieten mit schlechter Internetbandbreite.