Mobile-SEO: 3 + 1 Mobile-Konfigurationen

Jan Hauf
Jan Hauf

Jan Hauf ist SEO-Analyst bei Performics und seit fünf Jahren im SEO aktiv. Bei Performics arbeitet er an nationalen sowie internationalen Kundenprojekten.

Mehr von diesem AutorArtikel als PDF laden
Maren Strauß
Maren Strauß

Maren Strauß ist Online-Redakteurin bei der Berliner Online-Marketing-Agentur Performics. Nach ihrem Studium absolvierte ein Traineeship in einer Online-Redaktion. Seit 2015 schreibt sie Ratgeber, Blogartikel und Produkttexte für Performics. Einer ihrer Schwerpunkte sind Ratgeber zu den Themen Finanzen und Versicherungen.

Mehr von diesem AutorArtikel als PDF laden

Google hat mit dem Mobile-First-Index auf die wachsende Bedeutung des Smartphones reagiert. Für Website-Betreiber bedeutet es, dass sie Mobile-SEO nicht außer Acht lassen dürfen. Der erste und wichtigste Schritt dabei: eine mobile Website. Dafür stehen drei Konfigurationen (oder besser vier) zur Verfügung. Jede davon kann zum Erfolg führen. Das bedeutet allerdings nicht, dass die verschiedenen Mobile-Konfigurationen für alle Szenarien gleichermaßen gut geeignet sind.

Nach welchem Gerät greifen Sie, wenn Sie etwas im Internet suchen möchten? Nutzen Sie dafür den Computer oder gehören Sie zu der wachsenden Mehrheit, die dafür das Smartphone verwendet? Schon 2015 hat Google gemeldet, dass Nutzer in mehr als zehn Ländern häufiger auf dem Mobiltelefon als auf dem Desktop-Computer via Google Suchanfragen stellten. Im World Wide Web wird außerdem mittlerweile mehr Traffic an Smartphones als an Desktop-Geräten generiert.

Die Bedeutung des Smartphones belegen auch Zahlen zum Nutzerverhalten. Der Bundesverband Digitale Wirtschaft (BVDW) hat in einer Studie für 2017 ermittelt, dass die Befragten ihr Smartphone unter der Woche 152 Minuten am Tag benutzt haben, am Wochenende sogar 202 Minuten am Tag. Das sind über 2,5 bzw. über 3 Stunden!

Google erkennt die Zeichen der Zeit

Diese Entwicklung ist Google natürlich nicht verborgen geblieben. Der Suchmaschinengigant hat sich deshalb zu einem bedeutenden Schritt entschieden: die Einführung des Mobile-First-Indexes. Im Webmaster-Blog hat Google den Schritt im November 2016 erstmals angekündigt und begründet.

Aufs Wesentliche heruntergebrochen geht es dabei um die Priorisierung der Mobile-Variante einer Website gegenüber der Desktop-Variante bei der Ermittlung des Suchrankings. Vor dem Hintergrund, dass die Mehrheit der Suchanfragen von Smartphones gestellt wird, ist der Schritt nur folgerichtig. Zieht der Crawler allein die Desktop-Variante heran, besteht eine hohe Wahrscheinlichkeit, dass ein Smartphone-Nutzer nicht die Suchergebnisse vorfindet, die seinen Erwartungen entsprechen. Die mobile Website kann nur eine abgespeckte Variante der Desktop-Seite sein, eine erheblich eingeschränkte Usability bieten oder gar nicht auf kleinere Displays abgestimmt sein – nicht unbedingt das, was der Nutzer gesucht hat. Ein auf Desktop-Seiten beschränkter Googlebot würde all das nicht erfassen.

Google konnte also gar nicht anders, als die mobile Seitenvariante bei der Indexierung einzubeziehen. Die große Unsicherheit war, wie dieser Schritt aussehen und was er für die Praxis bedeuten würde. Wesentliche Fragen waren: Wann würde Google den Mobile-First-Index ausrollen? Würde es zwei separate Indizes für Desktop und Mobile geben? Was bedeutet Mobile First für SEO? Wie müssen Seitenbetreiber bei der Seitenkonfiguration, der Content-Gestaltung und UX auf das Mobile-First-Paradigma reagieren?

Und was ändert sich nun wirklich unter Mobile First?

Mittlerweile sind die größten Unklarheiten beseitigt. Es wird keinen separaten Index geben, die mobile Seite wird aber vom Googlebot im Mobile-First-Index hauptsächlich herangezogen. Google geht davon aus, dass es Jahre dauern wird, bis der Index tatsächlich flächendeckend mobile-first ist. Eine solche Umstellung braucht Zeit. Nach Google-Angaben werden aktuell nur Seiten auf das Mobile-First-Indexing umgestellt, die darauf vorbereitet sind.

In der Search Console erfolgt eine Benachrichtigung, wenn die Umstellung vollzogen wurde. Über die URL-Prüfen-Funktion in der Search Console lässt sich auch nachvollziehen, welcher Googlebot eine spezifische URL gecrawlt hat.

Aus SEO-Sicht gilt auch unter den neuen Voraussetzungen das, was schon vorher galt: Der Content muss für Suchanfragen relevant, die Seite technisch sauber umgesetzt und für den Googlebot crawlbar sein. In der Feinabstimmung wirft der neue Index dagegen durchaus noch Fragen auf. So prallen stärker noch als früher unterschiedliche Meinungen bei der Frage nach dem Umfang des Contents aufeinander. Traditionell ist man aus SEO-Sicht darum bemüht, umfassenden Text-Content mit einem definierten Keyword-Set anzubieten. Wegen des beschränkten Platzes auf dem Smartphone pochen UX-Designer dagegen mehr auf kurze, prägnante Inhalte. Ein Kompromiss können hier ausklappbare Elemente bzw. „Akkordeons“ sein.

Von solchen Feinheiten abgesehen ist aber klar, dass Seitenbetreiber ihre Inhalte auch für Smartphones und Tablets gut aufbereiten müssen. Wer das nicht tut, nimmt geradezu in Kauf, dass Nutzerzufriedenheit und Besucherzahlen darunter leiden. Das gilt im Übrigen auch für den Erfolg von Online-Shops. Denn Mobile ist auch im E-Commerce längst zu einem wesentlichen Faktor geworden. Wer hier nicht reagiert, läuft über kurz oder lang Gefahr, erhebliche Umsätze zu verlieren.

Wer vor der Entscheidung steht, eine Mobile-Seite aufzusetzen, hat im Wesentlichen drei Möglichkeiten. Man spricht in diesem Zusammenhang auch von drei Konfigurationen. Sauber aufbereitet funktionieren alle drei für den Nutzer und für Google. Für Seitenbetreiber haben die drei Varianten jedoch Vor- und Nachteile, die man kennen sollte.

1. Unterschiedliche URLs

Bei der Konfiguration mit unterschiedlichen URLs existiert meist eine Standardversion für Desktop-Nutzer und eine Mobile-Version auf einer Subdomain (www.m.beispielseite.de). Diese haben jeweils einen eigenen HTML-Code. Gibt ein Nutzer www.beispiel.de im Browser seines Smartphones ein, wird er automatisch auf die Subdomain m.beispiel.de weitergeleitet.

Mehrere URLs bedeuten einen höheren Aufwand bei der Seitenpflege, da Inhalte meist separat gepflegt werden. In der Vergangenheit hat das häufig dazu geführt, dass die Desktop-Seite bevorzugt wurde – schließlich war sie die Grundlage für die Indexierung. Die m.-Seite wurde hingegen stiefmütterlich behandelt. Die Gestaltung war auf dieser einfacher, oft gab es nicht so viel Content oder es fehlten sogar ganze URLs auf der m.-Seite – entweder mit der guten Absicht, den Nutzer auf dem kleinen Bildschirm nicht zu überfordern, oder weil man ihr nicht genug Aufmerksamkeit schenkte.

Das kann Seitenbetreibern mittlerweile gefährlich werden. Zieht Google vorrangig eine möglicherweise schlecht gepflegte Subdomain zur Bewertung heran, kann das bei der Mobile- und der Desktop-Variante zu schlechterer Sichtbarkeit führen – auch wenn die Desktop-Seite hochwertigen Content bietet. Content bedeutet in diesem Fall Texte, Bilder und Videos.

Wenn Seitenbetreiber die Konfiguration mit mehreren URLs technisch sauber umsetzen, müssen sie keine Nachteile befürchten. Zur sauberen Umsetzung gehört auch, dass die beiden Seiten im Quelltext richtig miteinander verknüpft sind. So versteht Google die Struktur der Seiten besser.

Die mobile Seite sollte ein Canonical-Attribut enthalten und auf die Desktop-URL verweisen, zum Beispiel <link rel="canonical" href="http://www.beispiel.de">. Im Gegenzug sollte im Quelltext der Desktop-Seite hinterlegt sein, dass es eine weitere, gleichartige Seite gibt. Dafür ist folgendes Attribut vorgesehen: rel="alternate" zusammen mit der Mobile-URL, also zum Beispiel <link rel="alternate" media="only screen and (max-width: 800px)" href="http://m.beispiel.de">. Alternativ kann die Auszeichnung auch in der Sitemap erfolgen.

2. Dynamische Bereitstellung

Bei der dynamischen Bereitstellung gibt es für die mobile und die Desktop-Variante einer Website die gleiche URL, aber verschiedene HTML-Codes für die einzelnen Geräte. So wird sichergestellt, dass die Seite auf jedem Gerät ansprechend dargestellt wird. Wenn der Browser eines Geräts die Seite abrufen will, teilt er dem Server via User-Agent mit, um welchen Browser (und damit, um welchen Gerätetyp) es sich handelt. Anschließend wird der für das Gerät passende HTML- und CSS-Code ausgespielt.

Mit einem Vary-HTTP-Header erkennt der Googlebot, dass sich die Website je nach Browser und Gerät unterscheidet. Er kann so die richtige Variante crawlen. Technisch ist diese Variante aufwendig. Sie müssen diverse HTML- und CSS-Codes zur Verfügung stellen und diese regelmäßig aktualisieren, da neue Geräte und User-Agents dazukommen. Zudem werden die User-Agents nicht immer richtig erkannt – ein Smartphone-Nutzer bekommt dann möglicherweise eine Variante der Seite angezeigt, die auf seinem Gerät nicht ordentlich dargestellt wird.

3. Responsive Design

Die Responsive-Konfiguration umgeht die Probleme der beiden anderen Konfigurationen. Sie lässt sich einfach umsetzen und verwalten. Es gibt lediglich eine URL und einen HTML-Code, der für alle Geräte gilt. Die Darstellung der Seite ändert sich je nach Bildschirmgröße, nicht nach Gerät. Dafür wird im Header der Seite ein entsprechendes Meta-Tag hinterlegt.

Die Darstellung für unterschiedliche Bildschirmbreiten lässt sich zusätzlich im CSS-Code mit Media-Queries anpassen. Durch das simple Set-up ist der Pflegeaufwand für die Seite gering. Content muss nur einmal hochgeladen werden und der HMTL-Code bleibt ebenfalls gleich. Auch aus technischer Sicht sprechen gute Gründe für die Responsive-Lösung.

  • Sie ermöglicht ein einfacheres Indexierungsmanagement, da es nicht zur Verwässerung zwischen Mobile und Desktop kommt.
  • Es findet keine serverseitige Weiterleitung statt, was schnellere Ladezeiten im Vergleich zur dynamischen Bereitstellung ermöglicht.
  • Das vom Googlebot zugewiesene Crawling-Budget wird bei der Responsive-Lösung geschont.

Auch Google selbst spricht für die Responsive-Variante eine klare Empfehlung aus und begründet das sowohl mit User-Freundlichkeit als auch mit technischen Argumenten.

Außer Konkurrenz: AMPs

Neben den drei vorgestellten Konfigurationen gibt es eine weitere Möglichkeit, um Inhalte auf dem Smartphone zu präsentieren: Accelerated Mobile Pages (AMP). Diese stellen eine Ergänzung zur bestehenden Mobile-Website dar. Ihr Hauptmerkmal sind extrem kurze Ladezeiten. Diese werden möglich durch ein schlankes Design, asynchrones JavaScript und optimierte Bilder. Zudem speichert Google die Seiten in einem speziellen AMP-Cache zwischen und spielt sie über ein Content Delivery Network (CDN) aus.

AMPs werden in den Suchergebnissen auf dem Smartphone ausgespielt. Sie erkennen sie an dem Blitzsymbol. Zudem werden sie in einem eigenen News-Karussell über den Suchergebnissen gezeigt, wenn sich dies anbietet. AMP ist deshalb besonders für die Online-Auftritte von Zeitungen und Magazinen oder News-Plattformen relevant. Für viele andere Websitebetreiber sind AMPs wegen der eingeschränkten Funktionen dagegen weniger sinnvoll.

Wie bei der m.-Seite sollten AMPs sauber mit der Desktop-Seite verknüpft werden. Die AMP-Variante der Seite verweist via Canonical auf die mobile Nicht-AMP-Seite. Wenn es keine mobile Version gibt, verweist die AMP-Seite auf sich selbst. Die Nicht-AMP-Seite verweist mit "amphtml" auf die AMP-Seite.

Fazit

Google lässt Ihnen bei der Konfiguration freie Hand. Für das Ranking spielt es zunächst keine Rolle, ob Sie separate URLs oder Responsive-Design verwenden. Solange Sie die Konfiguration benutzer- und suchmaschinenfreundlich umsetzen, sollten keine Probleme entstehen. Behalten Sie bei Ihrer Entscheidung aber auch den technischen und redaktionellen Aufwand im Auge. Dieser ist beim Responsive-Design am geringsten, da Sie Content nur auf einer Seite hochladen müssen und nur einen HTML-Code haben.

Um sicherzustellen, dass der Googlebot die mobile Website korrekt crawlen kann, bietet Google ein Tool für einen Mobile-Friendly-Check an (https://search.google.com/test/mobile-friendly). Das Tool kann beispielsweise Hinweise geben, wenn der Googlebot beim Crawlen von Elementen wie CSS, JavaScript-Dateien oder Bildern von der robots.txt blockiert wird.