Mobile SEO richtig umsetzen
Mobile Inhalte vollständig indexierbar, schnell und auf allen Viewports zuverlässig nutzbar machen
Mobile Inhalte vollständig indexierbar, schnell und auf allen Viewports zuverlässig nutzbar machen
Mobile SEO bedeutet nicht, eine verkleinerte Desktop-Seite bereitzustellen. Entscheidend ist, dass Suchmaschinen und Nutzer auf kleinen Bildschirmen denselben wesentlichen Inhalt, dieselben Funktionen und eindeutige technische Signale erhalten. Layout, Navigation und Medien dürfen sich an den verfügbaren Platz anpassen; die inhaltliche Aussage und Indexierbarkeit dürfen dabei nicht verloren gehen.
Google verwendet die mobile Fassung einer Seite, die mit Googlebot Smartphone abgerufen wird, für Indexierung und Ranking. Es gibt dabei keinen getrennten „Mobile Index“. Mobile-First Indexing beschreibt, welche Fassung Google als Grundlage verarbeitet, nicht einen automatischen Rankingbonus für responsive Websites. Seit Juli 2024 crawlt Google Websites für die Websuche grundsätzlich mit dem Smartphone-Crawler; Inhalte, die auf Mobilgeräten überhaupt nicht erreichbar sind, können dadurch nicht indexiert werden.
Eine technisch saubere mobile Seite verbindet deshalb vier Ebenen: erreichbares HTML, vollständige Inhalte und Metadaten, ein flexibles Layout sowie eine unter realen Bedingungen gute Nutzung. Erst die gemeinsame Prüfung dieser Ebenen verhindert, dass eine Seite im Desktop-Browser überzeugt, für den maßgeblichen mobilen Crawl aber unvollständig bleibt.
Google unterstützt drei technische Konfigurationen. Responsive Webdesign ist meist die wartungsärmste Lösung, weil dieselbe URL und dasselbe HTML für alle Geräte gelten und CSS nur die Darstellung verändert. Die Alternative ist nicht automatisch falsch, verlangt aber zusätzliche Signale und deutlich mehr Tests.
| Konfiguration | Technik | Wichtigste SEO-Prüfung |
|---|---|---|
| Responsive Design | Gleiche URL und grundsätzlich gleiches HTML, Anpassung über CSS | Inhalte dürfen an Breakpoints nicht ausgeblendet oder unbedienbar werden |
| Dynamic Serving | Gleiche URL, aber anderes HTML je User-Agent | Vary: User-Agent, Cache-Verhalten und Inhaltsparität kontrollieren |
| Separate mobile URLs | Beispielsweise Desktop-URL und m.example.de | Korrespondierende Seiten, Canonical/Alternate-Signale und gerätesichere Redirects |
Bei Dynamic Serving muss der Server mobile und Desktop-Anfragen zuverlässig erkennen. Der Antwortheader Vary: User-Agent informiert Caches darüber, dass die Darstellung vom User-Agent abhängt. Fehlt er, kann ein CDN die falsche Variante speichern und an Nutzer oder Crawler ausliefern. User-Agent-Erkennung ist außerdem wartungsintensiv, weil Gerätekennungen nicht dauerhaft stabil sind.
Separate mobile URLs benötigen für jede Desktop-Seite eine fachlich entsprechende mobile Seite. Die Desktop-Fassung verweist per rel="alternate" auf die mobile URL, die mobile Fassung per rel="canonical" auf das Desktop-Pendant. Weiterleitungen dürfen weder alle Mobilnutzer auf eine allgemeine Startseite schicken noch Desktop-Crawler blockieren. Bei einem neuen Projekt ist eine gemeinsame responsive URL-Struktur daher meist robuster.
Der Viewport-Hinweis sorgt dafür, dass ein Browser die Seite an der Gerätebreite rendert. Ohne ihn kann ein Mobilbrowser eine breite Desktop-Fläche simulieren und anschließend verkleinern. Eine solide Basis besteht aus dem Viewport-Meta-Tag, flexiblen Medien und Layouts, deren Elemente innerhalb des verfügbaren Platzes umbrechen.
<meta name="viewport" content="width=device-width, initial-scale=1">
img, video {
max-width: 100%;
height: auto;
}
.content {
width: min(100% - 2rem, 72rem);
margin-inline: auto;
}Feste Breiten bei Tabellen, Formularen, eingebetteten Karten, Videos oder Codebeispielen sind typische Ursachen für horizontales Scrollen. Ein umschließender Container darf bei fachlich notwendigen breiten Inhalten gezielt horizontal scrollen; die ganze Seite sollte es nicht. Breakpoints werden dort gesetzt, wo Inhalt und Bedienung sie benötigen, nicht nach einzelnen Gerätemodellen.
Die mobile Navigation muss vollständig per Touch und Tastatur bedienbar sein. Schaltflächen brauchen eine erkennbare Beschriftung und genügend Zielgröße beziehungsweise Abstand. Zoom sollte nicht durch user-scalable=no oder ein zu enges maximum-scale verhindert werden. Diese Punkte sind nicht nur Komfortdetails: Unlesbare Texte, überlappende Controls und unerreichbare Formulare verhindern reale Nutzung und Conversions.
Mobile und Desktop müssen nicht pixelgleich aussehen. Der primäre Text, sinnvolle Überschriften, Produktinformationen, interne Links und wesentliche Funktionen sollten jedoch inhaltlich gleichwertig sein. Inhalte dürfen auf Mobilgeräten in Akkordeons oder Tabs angeordnet werden. Sie dürfen nur nicht erst nach einer Nutzeraktion aus einer Quelle geladen werden, die Google beim Rendern nicht sieht.
noindex oder nofollow, wenn die Desktop-Fassung indexierbar sein soll.Auch Navigation und interne Verlinkung gehören zur Parität. Wird die Desktop-Hauptnavigation auf Mobilgeräten durch ein Menü ersetzt, müssen wichtige Kategorien weiterhin über echte <a href>-Links erreichbar sein. Hinweise zur Freigabe von CSS, JavaScript und Bildressourcen erläutert die Anleitung zur robots.txt für Suchmaschinen.
Ein responsive Layout löst keine Rendering-Probleme. Wenn der Hauptinhalt erst nach API-Aufrufen erscheint, müssen Smartphone-Crawler alle benötigten Skripte und Endpunkte erreichen können. Cookie-Dialoge, App-Installationsbanner oder Interstitials dürfen den Inhalt nicht dauerhaft verdecken. Lazy Loading muss an Scrollposition oder Viewport-Beobachtung anknüpfen und darf primäre Inhalte nicht erst nach Klick, Wischen oder Texteingabe laden.
Responsive Bilder reduzieren unnötige Datenübertragung, wenn srcset und sizes die tatsächlich benötigte Darstellungsbreite beschreiben. Für das wichtigste Bild im sichtbaren Bereich ist spätes Lazy Loading meist kontraproduktiv. Breiten- und Höhenangaben oder ein passendes Seitenverhältnis reservieren Platz und verhindern Layoutverschiebungen.
<img
src="produkt-800.webp"
srcset="produkt-480.webp 480w,
produkt-800.webp 800w,
produkt-1280.webp 1280w"
sizes="(max-width: 48rem) 100vw, 50vw"
width="800" height="600"
alt="Schwarzer Wanderschuh mit Profilsohle">Bei clientseitig erzeugten Seiten werden Smartphone- und Desktop-Ausgabe getrennt geprüft. Das gilt besonders für Menüs, Filter, Pagination und modale Inhalte. Der Beitrag JavaScript SEO und Rendering beschreibt die Unterschiede zwischen CSR, SSR und statischer Ausgabe ausführlich.
Mobile Geräte haben häufig weniger Rechenleistung und instabilere Verbindungen als Desktop-Systeme. Deshalb werden Performance-Probleme bei umfangreichem JavaScript, großen Bildern, Webfonts und Drittanbieter-Skripten mobil oft zuerst sichtbar. Ein schneller Labortest auf einem leistungsfähigen Rechner ersetzt keine Felddaten aus realen Besuchen.
Die Core Web Vitals messen Ladeerlebnis, Reaktionsfähigkeit und visuelle Stabilität. Als „gut“ gelten nach der aktuellen Google-Dokumentation LCP bis 2,5 Sekunden, INP bis 200 Millisekunden und CLS bis 0,1, jeweils am 75. Perzentil. Diese Schwellen gelten für Mobil und Desktop, die Daten werden aber getrennt ausgewertet. Für die Diagnose werden Felddaten aus PageSpeed Insights beziehungsweise Search Console mit Labormessungen und technischen Profilen verbunden.
Priorisiert werden die Ursachen, die viele wichtige Seitentypen betreffen: langsame Serverantworten, blockierendes CSS, zu spät entdeckte LCP-Ressourcen, lange JavaScript-Aufgaben, unreservierte Medienflächen und schwere Drittanbieter. Eine pauschale Punktzahl ist weniger hilfreich als die Frage, welches Element oder welche Interaktion eine konkrete Metrik verschlechtert.
Ein Audit beginnt nicht mit einem Screenshot, sondern mit dem Vergleich technischer Antworten. Status, Canonical, Robots-Angaben, Title, Überschriften, strukturierte Daten, interne Links und Hauptinhalt werden mit Smartphone- und Desktop-User-Agent abgerufen. Unterschiede müssen beabsichtigt und fachlich begründet sein.
# Smartphone-Antwort abrufen
curl -sS -D mobile-headers.txt -o mobile.html \
-A "Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 Chrome/131 Mobile Safari/537.36" \
https://www.example.de/kategorie/
# Desktop-Antwort zum Vergleich
curl -sS -D desktop-headers.txt -o desktop.html \
-A "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 Chrome/131 Safari/537.36" \
https://www.example.de/kategorie/Die URL-Prüfung in der Google Search Console zeigt unter anderem den beim letzten Crawl verwendeten Crawler und unterstützt den Live-Test einer einzelnen URL. Für Muster und Seitentypen bleiben ein eigener Crawl, Logdaten und echte Geräte unverzichtbar.