Mobile SEO: was Google auf dem Smartphone anders bewertet

Mobile-First-Indexierung bedeutet, dass Google für die allermeisten Websites ausschließlich die Version crawlt und bewertet, die der Smartphone-Bot zu sehen bekommt – unabhängig davon, ob ein menschlicher Besucher gerade am Handy oder am Desktop sitzt. Das führt zu einem Problem, das auf den ersten Blick nicht sichtbar ist: Viele Websites liefern auf dem Smartphone tatsächlich weniger Inhalt aus als auf dem Desktop. Nicht aus Absicht, sondern weil das mobile Template Text in Akkordeons faltet, interne Links nur in der Desktop-Sidebar stehen, strukturierte Daten im mobilen Build fehlen oder Bilder gegen leichtere Varianten ohne Alt-Text getauscht werden.

Dieser Artikel ist kein Leitfaden zu responsivem Design und auch keiner zu Ladezeiten – Core Web Vitals wie der Largest Contentful Paint haben einen eigenen Leitfaden verdient und werden hier bewusst nicht behandelt. Es geht ausschließlich um Content-Parität: sicherstellen, dass das, was Google tatsächlich indexiert, deckungsgleich mit dem ist, was auf dem Desktop steht – und das mit echten Rendering-Daten aus der URL-Prüfung nachweisen, statt mit dem eigenen Handy durch die Seite zu scrollen und zu hoffen, dass es stimmt.

Warum Mobile-First-Indexierung Content-Paritätsprobleme überhaupt erst schafft

Seit der vollständigen Umstellung auf Mobile-First-Indexierung nutzt Google für praktisch jede Website ausschließlich den Smartphone-Crawler, um Inhalte zu erfassen und zu bewerten. Der Ablauf ist dabei simpel, aber die Konsequenz oft nicht: Der Bot ruft die Seite mit einem mobilen User-Agent auf, führt JavaScript aus, wartet auf das fertige Rendering und speichert genau das DOM, das dabei entsteht. Genau dieses DOM – nicht der Quellcode, den ein Entwickler im Editor sieht, und nicht das, was am Desktop-Bildschirm sichtbar ist – bildet die Grundlage für Ranking-Signale wie Textinhalt, interne Verlinkung und strukturierte Daten.

Das bedeutet konkret: Wenn ein Absatz, ein Link oder ein JSON-LD-Block nur in der Desktop-Version existiert, existiert er für Google schlicht nicht. Es spielt keine Rolle, wie sorgfältig er dort formuliert oder ausgezeichnet wurde. Die mobile Version ist keine abgespeckte Zusatzansicht mehr, sie ist die Hauptquelle. Jede Lücke zwischen den beiden Versionen ist deshalb kein kosmetisches Problem, sondern eine direkte Lücke in dem, was indexiert wird. Wichtig dabei: Meist steckt keine Absicht dahinter. Desktop- und mobiles Template entstehen oft zu unterschiedlichen Zeitpunkten, manchmal von unterschiedlichen Agenturen oder Teams, und werden danach getrennt weitergepflegt. Ein Absatz, der am Desktop nachträglich ergänzt wird, landet dann im mobilen Template nur, wenn jemand aktiv daran denkt, ihn dort ebenfalls einzupflegen – und genau das wird bei laufendem Tagesgeschäft leicht vergessen.

Wenn responsiv nicht vollständig bedeutet: Akkordeons, Tabs und bedingt geladener Inhalt

Ein responsives Theme skaliert Layout und Schriftgrößen zuverlässig – über den tatsächlichen Inhalt sagt das nichts aus. Text, der per CSS mit display:none versteckt und erst bei Klick auf ein Akkordeon oder einen Tab eingeblendet wird, aber von Anfang an im HTML steht, liest Google in aller Regel trotzdem, weil der Renderer das komplette DOM erfasst, unabhängig davon, ob ein Element gerade sichtbar ist. Das eigentliche Parity-Problem beginnt eine Stufe früher: bei Inhalt, der für mobile Viewports gar nicht erst ausgeliefert wird, sondern erst nachträglich per Klick oder AJAX-Aufruf nachgeladen werden müsste.

Typische Muster, die genau das auslösen:

• Separate mobile Templates, die eine gekürzte Produktbeschreibung rendern, während die vollständige Version nur im Desktop-Template steht
• Tab-Inhalte, die erst beim Klick per AJAX nachgeladen werden, statt beim ersten Seitenaufruf bereits im HTML zu stehen
• Weiterlesen-Buttons, die eine Interaktion voraussetzen, bevor der restliche Absatz überhaupt ins DOM eingefügt wird
• Serverseitige Geräteerkennung, die für schmale Viewports ganze Absätze oder Blöcke komplett aus der Antwort entfernt, statt sie nur optisch zu verbergen

Der Unterschied lässt sich schnell testen: Steht der komplette Text bereits beim ersten Laden im HTML und wird nur optisch gefaltet, ist ein Klick auf das Akkordeon nicht nötig, um ihn im gerenderten HTML wiederzufinden. Muss man dagegen selbst klicken, um den Text im DOM überhaupt entstehen zu sehen, sieht der Googlebot beim automatisierten Rendering ohne Interaktion denselben leeren Zustand wie jeder Besucher, der nicht klickt.

Interne Links, die es nur auf dem Desktop gibt

Sidebar-Widgets, Mega-Menüs und Footer-Linkcluster werden auf kleinen Bildschirmen aus Platzgründen oft radikal reduziert. Solange die Links dabei nur optisch verschwinden – etwa hinter einem Hamburger-Menü, das sie im HTML behält und nur per Klick einblendet –, ist das unproblematisch. Kritisch wird es, wenn das mobile Template diese Links beim Rendern komplett weglässt, statt sie nur zu verbergen: Dann taucht der href-Wert im gerenderten mobilen HTML gar nicht auf, und der Smartphone-Bot kann diesem Pfad nicht folgen. Ein typisches Beispiel ist ein Mega-Menü, das am Desktop pro Kategorie eine Liste mit fünf bis zehn Unterkategorien ausklappt, während die mobile Navigation aus Platzgründen nur die Hauptkategorien zeigt und die Unterkategorie-Links komplett aus dem mobilen Markup entfernt, statt sie in ein aufklappbares Untermenü zu verschieben. Die Unterkategorien selbst bleiben dabei über die eigentliche Kategorieseite weiterhin erreichbar – verloren geht nur der zusätzliche, oft themenrelevante Linkpfad aus dem Menü.

Das ist nicht dasselbe Problem wie eine verwaiste Seite ohne jede interne Verlinkung – hier existiert der Link ja, nur eben nicht in der Version, die der primäre Crawler sieht. Die praktische Prüfung: die Liste aller Link-Elemente aus dem gerenderten Desktop-HTML gegen die Liste aus dem gerenderten mobilen HTML abgleichen. Jeder Link, der nur auf einer Seite auftaucht, ist ein Kandidat, den man sich gezielt ansehen sollte – besonders wenn er zu einer Kategorie- oder Produktseite führt, die sonst kaum verlinkt ist.

Strukturierte Daten, die im mobilen Build fehlen

Ein häufiger, aber leicht zu übersehender Fehler: Das Desktop-Template bindet einen JSON-LD-Block über ein Include ein, das beim Bau des separaten mobilen Templates nie mit übernommen wurde – oft, weil beide Templates zu unterschiedlichen Zeitpunkten entstanden sind und seither getrennt gepflegt werden. Für die Frage, wie strukturierte Daten grundsätzlich funktionieren und was Google damit macht, lohnt sich ein Blick in die entsprechenden Leitfäden zu Schema Markup; an dieser Stelle geht es ausschließlich um die Parity-Frage.

Weil praktisch nur die mobile Version indexiert wird, entscheidet ausschließlich das mobile Rendering darüber, ob eine Seite für Rich Results in Frage kommt – ein makelloser JSON-LD-Block, der nur im Desktop-DOM steht, hat für die Eligibility schlicht keine Wirkung mehr. Die Prüfung ist mechanisch: Man sucht im gerenderten mobilen HTML nach dem exakten Skript-Block, den man erwartet, statt sich auf den Quellcode oder ein Test-Tool zu verlassen, das eventuell mit einem Desktop-User-Agent testet.

Bilder, Alt-Text und die leichtere Mobile-Variante

Um Ladezeit zu sparen, tauschen viele Themes Bilder auf kleinen Viewports gegen kleinere Dateien aus – über ein srcset innerhalb eines einzelnen Bild-Elements, oder über ein picture-Element mit mehreren Quellangaben. Beide Varianten sind unproblematisch, solange das Alt-Attribut am äußeren Element gepflegt bleibt, weil es für alle Quellen gilt. Löst sich der Bildtausch stattdessen dadurch, dass zwei separate Bild-Tags im HTML stehen und eines davon per CSS für den jeweiligen Breakpoint ausgeblendet wird, entsteht eine typische Kopierlücke: Das zuerst gebaute Desktop-Bild bekommt seinen Alt-Text, das mobile Pendant wird schnell ergänzt und dabei vergessen.

Ein zweiter, subtilerer Fall: Lazy-Loading-Skripte, die den Alt-Text erst per JavaScript aus einem Daten-Attribut ins finale Alt-Attribut schreiben, sobald das Bild in den Viewport scrollt. Führt Google diesen Schritt beim Rendering nicht rechtzeitig aus – etwa weil das Skript an ein Scroll-Ereignis gebunden ist, das der Renderer nie auslöst –, bleibt das Alt-Attribut im erfassten DOM leer, unabhängig davon, was im Quellcode als Platzhalter steht.

Content-Parität nachweisen: ein Praxisbeispiel und die URL-Prüfung statt das eigene Handy

Ein Online-Shop hat für eine bestimmte Kategorie ein eigenes mobiles Template gebaut, weil die Desktop-Version auf kleinen Bildschirmen zu überladen wirkte. Die Produktbeschreibung wurde dabei auf drei kurze Absätze gekürzt, während die Desktop-Version sechs Absätze mit technischen Details, Maßangaben und Pflegehinweisen zeigt. Ein Link zu einer verwandten Kategorie, der im Desktop nur in einer Sidebar-Box steht, taucht im mobilen Template gar nicht auf, weil die Sidebar dort komplett durch eine schmale Buy-Box ersetzt wurde. Und der Produkt-Schema-Block, ursprünglich für die Desktop-Version geschrieben, wurde beim Bau des mobilen Templates schlicht vergessen, weil dafür ein anderes Entwicklerteam zuständig war.

Für sich genommen wirkt jede dieser drei Lücken klein. In Summe bedeutet sie aber: Google indexiert eine Seite mit weniger als der Hälfte des ursprünglichen Fließtexts, ohne den internen Link, der Crawling-Signale in Richtung der verwandten Kategorie gelenkt hätte, und ohne die Chance auf ein Rich Result, das am Desktop technisch längst vorbereitet war. Keine dieser drei Lücken wäre am eigenen Handy aufgefallen, weil das mobile Template dort genauso aussieht wie beabsichtigt – kürzer, aufgeräumter, schneller. Sichtbar wird der Verlust erst im Abgleich mit dem, was am Desktop tatsächlich steht, und im gerenderten HTML aus der URL-Prüfung.

Das eigene Smartphone zu nehmen und die Seite durchzuscrollen, wirkt wie der naheliegendste Test – ist es aber nicht. Der eigene Browser trägt einen anderen User-Agent, führt Skripte in einer anderen Reihenfolge und mit anderem Timing aus, hat möglicherweise eigene Cookies gesetzt, die Consent-Banner oder A/B-Tests unterdrücken, und zeigt schlicht nicht das DOM, das der Googlebot erfasst hat. Auch der Geräte-Emulator in den Browser-Entwicklertools ändert nur die Viewportgröße, nicht den tatsächlichen Crawler.

Belastbar ist nur ein Blick in die Search Console. Die URL-Prüfung rendert die Seite mit dem Smartphone-Googlebot – also mit exakt dem Crawler, der für die Indexierung zuständig ist – und stellt anschließend das gerenderte HTML zur Verfügung: den DOM-Zustand nach vollständiger JavaScript-Ausführung, nicht den ursprünglichen Quellcode. Genau darin lässt sich mit einer einfachen Textsuche prüfen, ob ein bestimmter Absatz, ein bestimmter Link oder ein bestimmter strukturierter-Daten-Block tatsächlich vorhanden ist.

Der praktische Ablauf: URL in der URL-Prüfung testen, den Bereich mit der gerenderten Seite beziehungsweise dem gerenderten HTML öffnen, und dort gezielt nach den Textpassagen, Link-Zielen oder Schema-Feldern suchen, die auf dem Desktop unstrittig vorhanden sind. Fehlt etwas, ist die Lücke damit nicht vermutet, sondern belegt – mit den Daten, die Google tatsächlich verwendet, nicht mit einer Annahme über das eigene Rendering.

Das deutsche Sonderproblem: Consent-Banner, die das Sichtfeld fressen

Auf deutschen und generell europäischen Websites ist das Consent-Banner oft kein kleiner Hinweis am unteren Bildschirmrand, sondern eine Fläche, die auf dem schmalen Smartphone-Viewport einen erheblichen Teil des sichtbaren Bereichs einnimmt – mit ausführlichen Rechtstexten, granularen Umschaltern pro Anbieter und mehreren Buttons, die auf einem kleinen Bildschirm schlicht mehr Platz brauchen als auf dem Desktop. Das verschiebt sichtbaren Inhalt nach unten und kann, je nach Umsetzung, einen Layout-Sprung auslösen, sobald das Banner nach der Interaktion verschwindet.

Für die Frage nach aufdringlichen Interstitials gibt es dabei eine Ausnahme, die Google in den eigenen Richtlinien explizit macht: Gesetzlich vorgeschriebene Hinweise, zu denen Cookie-Consent zählt, fallen ausdrücklich nicht unter die Regeln gegen störende Zwischenseiten. Das Banner selbst ist also für sich genommen kein Ranking-Risiko in diesem Sinne.

Das eigentliche Content-Parity-Risiko liegt woanders: Manche Consent-Management-Plattformen blockieren nicht nur Tracking-Skripte bis zur Einwilligung, sondern auch das eigene Rendering-Skript der Website, wenn beide über denselben Skript-Blocker laufen. In der Praxis sieht das oft so aus: Das Tool lädt zunächst nur ein minimales Grundgerüst der Seite plus das Banner, und erst nach einem Klick auf Akzeptieren oder Ablehnen wird ein zweites Skript nachgeladen, das den eigentlichen Artikeltext, die Produktbilder und die interne Navigation ins DOM schreibt – aus Sicht des Entwicklerteams ein sauberer, datensparsamer Ablauf, aus Sicht eines Renderers, der niemals klickt, jedoch keine verzögerte Ladephase, sondern schlicht eine leere Seite. Das ist auf deutschen Websites deutlich häufiger als anderswo, weil die Anforderungen an granulare Einwilligung hier besonders strikt umgesetzt werden und entsprechend umfangreiche Consent-Layer zum Einsatz kommen. Ob genau das passiert, zeigt derselbe Blick ins gerenderte HTML aus der URL-Prüfung: Steht der eigentliche Seiteninhalt dort, oder nur das Gerüst des Consent-Banners?

Was hier bewusst fehlt: Ladezeit und Core Web Vitals

Ob eine Seite auf dem Smartphone schnell genug lädt, ist eine eigene, wichtige Frage – aber eine andere als die in diesem Artikel. Largest Contentful Paint, Layout-Verschiebungen und Interaktionsgeschwindigkeit messen, wie sich das Laden anfühlt, nicht, ob Inhalt, Links und strukturierte Daten überhaupt vorhanden sind. Eine Seite kann perfekte Ladezeiten haben und trotzdem die Hälfte ihres Inhalts nur am Desktop zeigen; sie kann auch inhaltlich vollständig sein und dabei langsam laden. Wer beide Baustellen angehen will, findet die Performance-Seite im eigenen Leitfaden zum Largest Contentful Paint – hier ging es ausschließlich darum, ob das, was Google sieht, mit dem übereinstimmt, was tatsächlich auf der Seite steht.