Was ist Mobile-First-Indexierung?

Mobile-First-Indexierung legt fest, welche Version einer Seite Google beim Crawling, beim Speichern im Index und bei der Rankingberechnung als Hauptquelle nutzt: die, die ein Smartphone sieht, nicht die eines Desktop-Rechners. Das gilt unabhängig davon, von welchem Gerät aus jemand später sucht. Zeigen mobile und Desktop-Version unterschiedliche Inhalte, kennt und bewertet Google fast immer nur die mobile Fassung.

Die Umstellung kam nicht über Nacht. Google testete das Prinzip ab November 2016 und rollte es ab März 2018 schrittweise aus, zuerst bei Seiten, die bereits die empfohlenen Best Practices umsetzten. Am 1. Juli 2019 wurde Mobile-First-Indexierung zum Standard für jede neue Domain, die Google noch nicht kannte. Für den Rest des Webs zog sich die Migration deutlich länger hin als geplant: Google visierte zunächst September 2020 an, verschob das auf März 2021 und räumte im November desselben Jahres ein, kein festes Datum mehr zu nennen, weil einzelne Seiten unerwartete technische Probleme hatten.

Den offiziellen Abschluss verkündete Google am 31. Oktober 2023 im Blogbeitrag „Mobile-first indexing has landed". Seither wird, von wenigen Ausnahmen abgesehen, das gesamte Suchindex mit dem Googlebot Smartphone gecrawlt und bewertet. Jede Quelle, die Mobile First noch als „seit 2020 umgesetzt" beschreibt, meint eine Zwischenphase, nicht den Zeitpunkt, an dem Google die Migration für abgeschlossen erklärt hat.

Hier werden drei Begriffe vermischt, die unterschiedliche Probleme lösen. Der eine ist eine Indexierungsstrategie von Google. Der zweite eine Entwicklungstechnik. Der dritte eine Gruppe von Performance-Kennzahlen.

Eine responsive Website erleichtert Mobile First erheblich, weil beide Versionen dasselbe HTML nutzen und dabei kein Inhalt verloren geht. Identisch sind beide Konzepte trotzdem nicht: Eine Seite kann responsive sein und trotzdem an Mobile First scheitern, etwa wenn ein Textblock per CSS auf kleinen Bildschirmen ausgeblendet wird und dieser Block dadurch nie Teil dessen wird, was Google indexiert. Umgekehrt kann eine Seite mit getrennten URLs für Mobil und Desktop (das alte m.domain.de-Schema) Mobile First durchaus erfüllen, wenn die mobile Version alle relevanten Inhalte enthält, auch wenn Google heute responsives Design empfiehlt, weil es solche Paritätsfehler von vornherein vermeidet.

Die Core Web Vitals sind wieder etwas anderes: Sie messen, wie schnell und wie stabil eine Seite lädt, nicht welche Version Google indexiert. Eine Seite kann Mobile First problemlos erfüllen und trotzdem einen schlechten LCP auf Mobil haben, weil beides unabhängig voneinander bewertet wird.

Die meisten Mobile-First-Probleme entstehen nicht, weil eine Seite nicht für Mobil optimiert ist, sondern weil mobile und Desktop-Version nicht dasselbe sagen. Die häufigsten Fälle:

Gekürzter Text auf Mobil. Lange Absätze werden auf der mobilen Version oft gekürzt oder ganze Abschnitte weggelassen, um den Bildschirm nicht zu überladen. Google indexiert genau diese gekürzte Fassung. Jedes Keyword und jeder Fakt, der nur im gestrichenen Absatz stand, zählt dann nicht mehr fürs Ranking.

Elemente, die Google ebenfalls nicht sieht. Tabs, Akkordeons oder ausklappbare Menüs sind an sich kein Problem: Google liest Inhalt, der hinter einem Klick verborgen ist, wenn er im HTML steht. Kritisch wird es, wenn dieser Inhalt erst nach einer Nutzerinteraktion nachgeladen wird, etwa durch einen Scroll, einen Swipe oder einen Klick, der einen Server-Request auslöst, denn der Googlebot interagiert nicht wie ein Mensch mit der Seite.

Unvollständige strukturierte Daten. Häufig wird das schema.org-Markup nur im Desktop-Template gepflegt und im mobilen Template vergessen, vor allem wenn beide technisch getrennte Templates sind. Indexiert Google nur die mobile Version, verschwindet ein Rich Snippet, das von diesem Markup abhängt, selbst wenn die Desktop-Version fehlerfrei ist.

Abweichende Metadaten. Ein Title oder eine Meta Description, die sich zwischen den Versionen unterscheiden, oft weil sie für ein schmaleres mobiles Template zwangsweise gekürzt wurden, führen dazu, dass im Suchergebnis nicht das steht, was das Desktop-Team eigentlich freigegeben hat.

Reduzierte interne Verlinkung. Mobile Versionen vereinfachen Menüs und Footer oft, um Platz zu sparen. Fallen dabei interne Links weg, die es auf Desktop gibt, verlieren die verlinkten Zielseiten einen Teil des Signals aus der internen Verlinkung, ohne dass sich an deren eigenem Inhalt etwas geändert hätte.

Abweichende technische Sperren. Seltener, aber es kommt vor: robots.txt-Regeln oder noindex-Anweisungen, die nur für das mobile Template gelten und nicht für das Desktop-Template, oder umgekehrt, meist durch einen Konfigurationsfehler im CDN oder im Server, der die jeweilige Version ausliefert.

Der erste Anlaufpunkt bleibt die Search Console, mit einer wichtigen Einschränkung: Der eigenständige Bericht „Mobile Usability", den es seit 2016 gab, ist seit dem 1. Dezember 2023 nicht mehr verfügbar, zusammen mit dem Mobile-Friendly-Test-Tool und dessen API. Google begründete das damit, dass diese Einzelprüfung überflüssig wurde, sobald Mobile First für das gesamte Index galt, und dass es inzwischen umfassendere Werkzeuge für dieselbe Aufgabe gibt, allen voran Lighthouse.

Um zu prüfen, was Google von einer konkreten URL sieht, ist heute die URL-Prüfung in der Search Console das richtige Werkzeug: Sie zeigt das bereits gerenderte HTML, so wie es der Googlebot mit dem Smartphone-User-Agent verarbeitet hat. Dieses Ergebnis mit der Desktop-Ansicht derselben URL im Browser zu vergleichen, deckt zuverlässig auf, ob ein Textblock, ein strukturiertes Datum oder ein Link fehlt.

Ein zweiter, manuellerer, aber ebenso verlässlicher Check ist es, dieselbe URL im responsiven Modus der Browser-Entwicklertools zu öffnen und Abschnitt für Abschnitt mit der Desktop-Version zu vergleichen. Besondere Aufmerksamkeit verdient alles, was hinter einem Akkordeon oder Tab verborgen ist: Steht es im Quell-HTML, auch wenn es visuell ausgeblendet ist, gibt es kein Problem; wird es erst durch eine Interaktion erzeugt, schon.

Für strukturierte Daten validiert der Rich-Snippet-Test von Google das Markup so, wie es der mobile Crawler sieht, nicht der Desktop-Crawler. Es lohnt sich, ihn immer auf der echten URL laufen zu lassen und nicht nur auf einer Referenzvorlage.

• Setze auf responsives Design mit derselben URL und demselben HTML für beide Versionen: Google empfiehlt das seit 2018 genau deshalb, weil es das Risiko voneinander abweichender Inhalte von vornherein ausschließt.
• Pflege die vollständigen strukturierten Daten im mobilen Template, nicht nur im Desktop-Template, auch wenn beide technisch getrennt sind.
• Halte Title, Meta Description und hreflang-Angaben in beiden Versionen identisch, auch wenn auf dem Bildschirm weniger Platz zur Verfügung steht.
• Verstecke sekundären Inhalt auf Mobil mit Akkordeons oder Tabs, die im HTML erhalten bleiben, statt ihn aus dem Markup zu entfernen oder erst nach einer Nutzerinteraktion nachzuladen.
• Prüfe, ob die interne Verlinkung in Menü und Footer auf Mobil nicht so stark reduziert wird, dass Zielseiten verwaiste oder schwerer erreichbare Seiten werden.
• Kontrolliere über die URL-Prüfung in der Search Console, nicht nur über die Browseransicht, denn nur sie zeigt das exakte HTML, das der Googlebot Smartphone verarbeitet hat.

• Inhalt per CSS ausblenden (display: none oder ähnlich) in der Annahme, das betreffe nur die mobile Ansicht: Landet dieser Inhalt nie im HTML, das der Googlebot crawlt, zählt er auch für das Desktop-Ranking nicht mehr, weil Google beide Fälle nicht mehr getrennt behandelt.
• Davon ausgehen, dass responsives Design Mobile First automatisch erfüllt, ohne je zu prüfen, welche konkrete Version Google für die wichtigsten Seiten tatsächlich indexiert.
• Strukturierte Daten nur per JavaScript laden, das erst nach einer Nutzerinteraktion ausgeführt wird, statt sie im initialen HTML oder im DOM bereitzustellen, das Google rendert.
• Die mobile Usability weiterhin nach dem Stand von 2020 prüfen, ohne zu berücksichtigen, dass der eigenständige Search-Console-Bericht dafür nicht mehr existiert und Lighthouse oder die URL-Prüfung die aktuellen Werkzeuge sind.
• Per robots.txt Ressourcen wie CSS oder Bilder blockieren, die Google zum korrekten Rendern der mobilen Version braucht, wodurch die Seite schlechter optimiert wirkt, als sie tatsächlich ist.