Mobile-First-Indexierung: Parität ist alles
Mobile-First-Indexierung bedeutet einen Satz mit großer Tragweite: Google bewertet und indexiert die mobile Version deiner Seite. Nicht die Desktop-Version mit einem Mobil-Bonus, sondern die Mobilversion als maßgebliche Quelle. Seit 2024 gilt das für praktisch alle Websites. Dieser Leitfaden zeigt, warum daraus ein einziges zentrales Prinzip folgt: Parität.
1. Was Mobile-First wirklich heißt
Der Name führt in die Irre. „Mobile-First" ist keine Bevorzugung mobiler Seiten im Ranking und kein separates Ranking-Signal. Es beschreibt schlicht, welche Fassung Googlebot abruft, rendert und in den Index legt: die, die ein Smartphone-Nutzer sieht.
Die Konsequenz ist unbequem: Alles, was nur in der Desktop-Fassung existiert – Text, Links, Bilder, strukturierte Daten – ist für Google praktisch nicht vorhanden. Deine Mobilversion ist deine Website, so weit es die Suche betrifft.
Kernprinzip: Nicht „responsive Gestaltung", sondern Content-Parität. Die Mobilversion muss denselben Inhalt, dieselben Links und dieselben Metadaten enthalten wie die Desktop-Version. Alles, was mobil fehlt, fehlt im Index.
2. Warum responsives Design das Problem meist löst
Es gibt drei technische Umsetzungen für mobile Seiten. Sie unterscheiden sich stark im Risiko:
| Umsetzung | Prinzip | Paritätsrisiko |
|---|---|---|
| Responsive Design | Ein HTML, per CSS an die Breite angepasst | Gering – empfohlen von Google |
| Dynamische Auslieferung | Gleiche URL, je nach Gerät anderes HTML | Hoch – zwei Fassungen driften auseinander |
| Separate m.-URL | Eigene mobile Domain/Subdomain | Sehr hoch – veraltet, meiden |
Responsives Design löst das Paritätsproblem an der Wurzel, weil Inhalt und Markup identisch sind – nur die Darstellung ändert sich. Getrennte HTML-Fassungen oder m.-Domains sind die Hauptquelle für die Fehler im nächsten Abschnitt und sollten migriert werden.
3. Die typischen Paritätslücken
Wo Mobile-First Rankings kostet, liegt es fast immer an einer dieser Lücken:
| Lücke | Was passiert | Folge |
|---|---|---|
| Gekürzter Text | Mobil wird Inhalt „aus Platzgründen" weggelassen | Der fehlende Text wird nicht indexiert |
| Eingeklappter Inhalt | Text in Akkordeons und Tabs | Wird indexiert – aber nur, wenn er im DOM liegt |
| Fehlende interne Links | Mobiles Menü zeigt weniger Verweise | Verlorene interne Verlinkung |
| Weniger Bilder | Mobil ausgeblendete oder ungeladene Bilder | Kein Bild-SEO für diese Bilder |
| Fehlende strukturierte Daten | JSON-LD nur in der Desktop-Fassung | Keine Rich-Result-Berechtigung |
| Abweichende Metadaten | Anderer Title/Description mobil | Google nutzt die mobile Variante |
Ein häufiges Missverständnis betrifft eingeklappten Inhalt: Text in Akkordeons, Tabs oder „Mehr anzeigen"-Bereichen wird voll gewertet, solange er im gerenderten DOM vorhanden ist – nur eben visuell verborgen. Wird der Text dagegen erst per Klick nachgeladen und liegt vorher nicht im DOM, sieht Googlebot ihn nicht, denn der Bot klickt nicht.
4. Der Zusammenhang mit Rendering
Mobile-First und Rendering greifen ineinander. Googlebot ruft die Seite mit einem mobilen User-Agent ab und rendert sie mit einem mobilen Viewport. Zwei Dinge müssen deshalb zusammenkommen:
- Der Inhalt muss im gerenderten DOM stehen – nicht nur nach einer Nutzerinteraktion erscheinen.
- Die für die Mobilansicht nötigen Ressourcen (CSS, JavaScript) dürfen nicht per robots.txt blockiert sein, sonst rendert Google die Seite falsch.
Gerade bei clientseitig gerenderten Seiten ist das kritisch: Wenn die mobile Variante Inhalte später oder gar nicht lädt, fehlt genau dieser Inhalt im Index.
5. Technische Mindestanforderungen
- Viewport-Meta-Tag.
<meta name="viewport" content="width=device-width, initial-scale=1">ist die Grundlage jeder mobilen Darstellung. - Lesbare Schriftgrößen und Tap-Ziele. Kein Zoom nötig, Buttons nicht zu dicht – Teil der Nutzererfahrung, die in die Core Web Vitals einfließt.
- Kein horizontales Scrollen. Inhalt passt in die Viewport-Breite.
- Gleiche hreflang- und Canonical-Angaben in beiden Ansichten – bei responsivem Design automatisch gegeben.
6. Parität prüfen
Der verlässlichste Test vergleicht, was der mobile Googlebot sieht, mit dem, was Desktop-Nutzer sehen:
- URL-Prüfung in der Search Console: zeigt das gerenderte HTML und einen Screenshot so, wie Google die Seite mobil abruft. Der Abgleich mit der Desktop-Ansicht deckt fehlende Inhalte auf.
- Gerendertes DOM statt Quelltext prüfen: Entscheidend ist, was nach dem Rendern im DOM steht, nicht der ursprüngliche Quelltext.
- Mobile Ansicht mit gedrosseltem Netz testen: deckt Inhalte auf, die zu spät oder gar nicht laden.
Profi-Tipp: Öffne die Seite in einem schmalen Browserfenster und lass Rank-O-Saur Überschriften, Links, Bilder und strukturierte Daten auslesen. Vergleiche die Zahlen mit der breiten Ansicht: Verschwinden mobil Links, Bilder oder JSON-LD, hast du eine Paritätslücke gefunden, bevor sie Rankings kostet.
7. Häufige Fehler
- Text nur mobil kürzen. Der weggelassene Inhalt wird nicht indexiert.
- Reduziertes Mobilmenü. Weniger interne Links bedeuten schwächere interne Verlinkung.
- Strukturierte Daten nur auf Desktop. Kostet die Rich-Result-Berechtigung.
- Bilder mobil ausblenden statt anpassen. Ausgeblendete Bilder liefern kein Bild-SEO.
- Rendering-Ressourcen per robots.txt blockieren. Google rendert die Mobilseite dann unvollständig.
- Abweichende Metadaten je Gerät. Google nutzt die mobile Fassung – auch wenn die Desktop-Version besser war.
8. Checkliste
- Mobilversion enthält denselben Haupttext wie die Desktop-Version.
- Alle internen Links auch mobil vorhanden.
- Strukturierte Daten in beiden Ansichten identisch.
- Title und Meta Description mobil gleich.
- Wichtige Bilder mobil geladen, nicht nur ausgeblendet.
- Eingeklappter Inhalt liegt im gerenderten DOM, nicht per Klick nachgeladen.
- Viewport-Meta-Tag gesetzt, kein horizontales Scrollen.
- CSS/JS für das Rendern nicht per robots.txt blockiert.
- URL-Prüfung zeigt vollständigen Inhalt in der mobilen Renderansicht.
9. Häufig gestellte Fragen
Ist Mobile-First-Indexierung ein Rankingfaktor?
Nein, es ist kein Ranking-Signal, sondern beschreibt, welche Version Google indexiert – die mobile. Ranking-relevant wird es indirekt: Fehlt in der Mobilversion Inhalt, kann Google ihn nicht bewerten, und die Seite rankt schlechter, als die Desktop-Fassung es zuließe.
Wird in Akkordeons versteckter Text abgewertet?
Nein. Inhalt in Tabs oder Akkordeons wird voll gewertet, solange er im gerenderten DOM liegt und nur visuell eingeklappt ist. Problematisch ist nur Inhalt, der erst per Klick nachgeladen wird und vorher nicht im DOM steht – den sieht Googlebot nicht.
Brauche ich eine separate mobile Website?
Nein, im Gegenteil. Responsives Design mit einer einzigen URL und identischem HTML ist Googles Empfehlung und vermeidet Paritätsprobleme. Separate m.-URLs gelten als veraltet und sind die häufigste Ursache für fehlende Inhalte im Index.
Muss der Inhalt auf Mobil und Desktop wirklich identisch sein?
Der indexrelevante Inhalt ja: Haupttext, interne Links, strukturierte Daten und Metadaten sollten übereinstimmen. Die Darstellung darf sich unterscheiden – ein anderes Layout oder eine andere Navigation ist unkritisch, solange derselbe Inhalt im DOM vorhanden ist.
Wie prüfe ich, was Google auf dem Handy sieht?
Nutze die URL-Prüfung in der Search Console: Sie zeigt das gerenderte HTML und einen Screenshot aus Sicht des mobilen Googlebot. Vergleiche diesen Stand mit der Desktop-Ansicht, um fehlende Inhalte, Links oder strukturierte Daten aufzudecken.
Was passiert mit Desktop-Nutzern unter Mobile-First?
Für sie ändert sich nichts – sie sehen weiterhin die Desktop-Ansicht. Mobile-First betrifft nur, welche Fassung Google für Indexierung und Bewertung heranzieht, nicht, welche Version welchem Nutzer ausgeliefert wird.
Weiterlesen
