Mobile-First-Indexing

Mobile-First-Indexing bedeutet, dass Google für Crawling, Rendering und Bewertung einer Website primär die mobile Version heranzieht. Früher wurde in vielen Fällen die Desktop-Version als Hauptquelle betrachtet. Heute gilt das Gegenteil: Wenn Inhalte, interne Links, strukturierte Daten oder Meta-Informationen mobil fehlen, behandelt Google diese Lücken als reales Problem der Seite. Mobile-First-Indexing ist deshalb kein Designtrend, sondern ein technischer SEO-Standard mit direkter Wirkung auf Sichtbarkeit, Nutzererfahrung und Conversion-Pfade.

Was Google dabei konkret bewertet

Beim Mobile-First-Indexing geht es nicht nur darum, ob eine Seite “auf dem Handy irgendwie funktioniert”. Google schaut darauf, ob die mobile Version dieselben zentralen Signale transportiert wie die Desktop-Version:

• Hauptinhalte und relevante Textbloecke
• Titel, Meta Description und Headlines
• interne Verlinkung und Navigation
• strukturierte Daten
• Bilder, Alt-Texte und eingebettete Medien
• Ladezeit und wahrgenommene User Experience

Wenn mobil abgespeckte Templates wichtige Inhalte ausblenden, bricht oft nicht nur die UX ein. Es fehlen dann auch genau die Informationen, die Google für Ranking und thematische Einordnung braucht.

Responsive vs. Adaptive vs. Separate URLs: Die drei Ansätze im Vergleich

Responsive Design ist die gaengigste technische Umsetzung, aber nicht die einzige Option. Hier die drei Ansätze mit ihren SEO-Implikationen:

Die klare Empfehlung: Responsive Design mit sauber konfigurierten Breakpoints. Wer separate Mobile-URLs betreibt, muss rel="alternate" und rel="canonical" korrekt setzen — und das geht in der Praxis staendig schief. Wir sehen bei Audits mit Screaming Frog regelmäßig fehlende oder falsch gesetzte Alternate-Tags, die dazu führen, dass Google Desktop- und Mobile-Version nicht korrekt zuordnet.

AMP im Jahr 2026: Status und Einordnung

AMP (Accelerated Mobile Pages) war Googles Versuch, mobile Seiten schneller zu machen. Die Frage, die wir staendig hoeren: Braucht man AMP noch?

Kurze Antwort: Nein, für die meisten Websites nicht mehr.

Google hat AMP als Ranking-Signal und als Voraussetzung für das Top Stories Karussell abgeschafft. Seiten, die ohne AMP saubere Core Web Vitals liefern, haben keinen Nachteil. AMP kann sinnvoll sein für Publisher mit extremen Ladezeit-Anforderungen und begrenzten Entwicklerressourcen. Für alle anderen erzeugt AMP eher Komplexitaet: eingeschraenktes HTML, limitiertes JavaScript, doppelte Content-Pflege.

Wenn du aktuell AMP einsetzt, prüfe in der Google Search Console, ob deine Non-AMP-Seiten vergleichbare Core Web Vitals erreichen. Falls ja, kannst du AMP schrittweise auslaufen lassen.

Warum das Thema für SEO so wichtig ist

Google nutzt die mobile Sicht auf deine Seite als Arbeitsgrundlage. Das betrifft:

• thematische Relevanz und Vollständigkeit
• interne Linksignale
• Crawl-Pfade zu tieferen Seiten
• Wahrnehmung von Core Web Vitals und Page Speed

Wenn eine Desktop-Seite stark und vollständig ist, mobil aber ausgeduennt, hilft dir die Desktop-Qualität nur begrenzt weiter. Gerade auf B2B-Websites sehen wir oft dieselben Fehler: Tabellen werden abgeschnitten, Trust-Elemente verschwinden, FAQ-Bloecke werden für mobile Nutzer gar nicht erst geladen oder CTAs rutschen so weit nach unten, dass sie praktisch unsichtbar werden.

Mobile Core Web Vitals: Deep-Dive

Die Core Web Vitals sind mobil fast immer schlechter als auf Desktop. Hier die drei Metriken mit mobilspezifischen Optimierungsansätzen:

LCP (Largest Contentful Paint) — Ziel: unter 2,5 Sekunden

Auf mobilen Geraeten ist LCP typischerweise 40-60 % langsamer als auf Desktop. Hauptgründe:

• Langsamere Netzwerke: Selbst mit 4G liegt die effektive Bandbreite oft bei 5-15 Mbit/s, nicht bei den theoretischen 100 Mbit/s.
• Schwaehere Prozessoren: Ein Android-Mittelklassegeraet (ca. 70 % des Marktes) hat 3-5x weniger Rechenleistung als ein Desktop.
• Grosse Hero-Bilder: Das häufigste LCP-Problem. Ein unkomprimiertes Hero-Image mit 2 MB toetet den LCP auf Mobilgeraeten.

Lösung: Nutze fetchpriority="high" auf dem LCP-Element und liefere per srcset eine mobiloptimierte Bildgröße aus:

<img
  src="/hero-800.webp"
  srcset="/hero-400.webp 400w, /hero-800.webp 800w, /hero-1200.webp 1200w"
  sizes="(max-width: 768px) 100vw, 800px"
  fetchpriority="high"
  alt="Beschreibung des Hero-Bildes"
  width="800"
  height="450"
  decoding="async"
/>

INP (Interaction to Next Paint) — Ziel: unter 200ms

INP ersetzt FID seit Maerz 2024 und misst die tatsaechliche Reaktionsfähigkeit. Auf Mobilgeraeten scheitern die meisten Seiten an zu viel JavaScript:

• Third-Party-Scripts (Chat-Widgets, Analytics, Consent-Banner) blockieren den Main Thread
• Frameworks wie React oder Angular rendern auf schwachen Mobilgeraeten deutlich langsamer
• Event-Handler, die synchron schwere Berechnungen ausführen

Prüfe INP-Probleme mit Chrome DevTools im Performance-Tab. Achte auf “Long Tasks” (alles über 50ms). In Screaming Frog siehst du die CWV-Daten aggregiert für die gesamte Domain.

CLS (Cumulative Layout Shift) — Ziel: unter 0,1

CLS-Probleme sind mobil besonders sichtbar, weil der Viewport kleiner ist. Ein Element, das sich um 50px verschiebt, macht auf einem Desktop mit 1440px Breite kaum etwas aus. Auf einem 375px-Smartphone verschiebt sich gefuehlt alles.

Praxisbeispiel: Bei einem Audit einer TYPO3-Website eines Energieversorgers betrug der CLS im Lighthouse-Lab lediglich 0,029 — auf dem Papier ein exzellenter Wert. Die Felddaten echter Nutzer (CrUX) zeigten allerdings einen CLS von 0,2, also doppelt so hoch wie der Schwellenwert. Der Grund: Ein Chatbot-Iframe und der Consent-Banner verursachten auf mobilen Geraeten massive Layout-Verschiebungen, die im Lab-Test nicht simuliert wurden. Das ist ein typisches Mobile-First-Problem: Was im Labor gut aussieht, scheitert auf echten Geraeten an Third-Party-Elementen.

Häufigste Ursachen mobil:

• Bilder ohne width/height-Attribute
• Web Fonts ohne font-display: swap oder ohne Fallback-Dimensionen
• Dynamisch eingefuegte Banner (Cookie-Consent, Newsletter-Popups)
• Ads, die nach dem Laden ihren Platz reservieren

Häufige Fehler im Mobile-First-Setup

Versteckte Inhalte

Accordion- oder Tab-Inhalte sind nicht automatisch problematisch. Kritisch wird es, wenn Inhalte nur visuell versteckt, technisch aber gar nicht erst ausgeliefert werden. Dann fehlen Google relevante Informationen vollständig.

Schwache mobile Navigation

Wenn die mobile Navigation nur wenige Links enthält oder wichtige Bereiche tiefer versteckt als auf Desktop, schwachst du deine interne Verlinkung. Das wirkt sich auf Crawl-Tiefe, Priorisierung und Indexierbarkeit aus.

Mobile Templates ohne Proof und Conversion-Elemente

Viele Seiten reduzieren mobil ausgerechnet die Elemente, die Vertrauen schaffen: Referenzen, Zahlen, Bewertungen, Case Links oder klare Handlungsaufforderungen. Das verschlechtert sowohl die Wahrnehmung durch Nutzer als auch die wirtschaftliche Leistung der Seite.

Zu schwere mobile Assets

Mobile Nutzer leiden zuerst unter unoptimierten Bildern, schweren Skripten und spät ladenden Widgets. Eine schlechte mobile Performance verschlechtert die User Experience und kann die organische Leistung indirekt und direkt belasten.

Mobile UX Audit: Vollständige Checkliste

Bevor du ins Tool-Setup gehst, hier die systematische Prüfung der mobilen Nutzererfahrung:

Navigation und Erreichbarkeit:

• Hauptnavigation mobil: Sind alle wichtigen Seitenbereiche erreichbar?
• Hamburger-Menue: Maximal 2 Ebenen tief, keine verschachtelten Mega-Menus
• Breadcrumbs: Sichtbar und funktional auf mobilen Seiten?
• Footer-Navigation: Nicht abgeschnitten, Links funktionieren?
• Suche: Prominent und nutzbar auf kleinen Screens?

Content-Paritaet:

• Alle Textbloecke, die auf Desktop sichtbar sind, auch mobil vorhanden?
• Tabellen: Horizontal scrollbar oder responsive umgebaut?
• Formulare: Richtige Tastatur-Typen (tel, email, number)?
• Videos und Embeds: Responsive eingebettet, nicht abgeschnitten?
• Strukturierte Daten auf mobilen und Desktop-Seiten identisch?

Touch und Interaktion:

• Touch Targets: Mindestens 48x48px für alle interaktiven Elemente
• Abstand zwischen klickbaren Elementen: Mindestens 8px
• Kein Hover-abhängiger Content (Tooltips, Dropdown-Menus, die nur bei Hover öffnen)
• Formulare: Autofill funktioniert, Labels sind sichtbar, Fehlermeldungen klar

Performance:

• LCP unter 2,5s auf echtem Mobilgeraet
• INP unter 200ms
• CLS unter 0,1
• Gesamte Seitengröße unter 3 MB (inkl. aller Assets)

Testing-Tools im Vergleich

Praktischer Audit-Workflow mit konkreten Tools

Ein Mobile-First-Audit ist kein Hexenwerk, wenn du die richtigen Tools in der richtigen Reihenfolge einsetzt:

Schritt 1: Screaming Frog im Mobile-Modus crawlen

Screaming Frog bietet die Option, als Googlebot Mobile zu crawlen (Configuration > User-Agent > Googlebot Smartphone). Starte zwei Crawls: einen als Desktop-Googlebot, einen als Mobile-Googlebot. Exportiere beide und vergleiche:

• Unterschiede in der Seitenzahl (werden mobil weniger Seiten gefunden?)
• Unterschiede bei internen Links (verweist die mobile Navigation auf weniger Seiten?)
• Fehlende Meta-Titles oder Descriptions in der mobilen Version
• Unterschiede bei strukturierten Daten

Dieser Vergleich deckt in wenigen Minuten die größten Diskrepanzen auf.

Schritt 2: Google Search Console URL-Prüfung

Nutze die URL-Prüfung in der Google Search Console für deine fünf wichtigsten Seiten. Klicke auf “Getestete Seite anzeigen” und prüfe das gerenderte HTML. Siehst du dort alle Inhalte, die auf der Desktop-Version sichtbar sind? Wenn ganze Textbloecke, Tabellen oder FAQ-Bereiche fehlen, liegt ein Rendering-Problem vor.

Schritt 3: Core Web Vitals mobil prüfen

Öffne PageSpeed Insights und teste deine Seiten im Mobile-Modus. Achte besonders auf:

• LCP (Largest Contentful Paint): Soll unter 2,5 Sekunden liegen. Häufigster Blocker: unkomprimierte Hero-Bilder.
• INP (Interaction to Next Paint): Soll unter 200ms liegen. Häufigster Blocker: schwere JavaScript-Bundles.
• CLS (Cumulative Layout Shift): Soll unter 0,1 liegen. Häufigster Blocker: nachlaufende Werbebanner oder Schriften ohne font-display:swap.

Schritt 4: Reale Geraete testen

Chrome DevTools simulieren, aber sie ersetzen kein echtes Smartphone. Teste deine wichtigsten Seiten auf mindestens zwei realen Geraeten (ein aktuelles iPhone und ein Android-Mittelklassegeraet). Achte auf:

• Schriftgrößen und Lesbarkeit
• Touch-Target-Größen (Buttons und Links müssen mindestens 48x48px gross sein)
• Formular-Usability (öffnet sich die richtige Tastatur? Funktioniert Autofill?)
• Ladeverhalten bei realer Mobilfunkverbindung

Schritt 5: Sistrix Mobile-Sichtbarkeit prüfen

Sistrix zeigt dir den Sichtbarkeitsindex getrennt nach Desktop und Mobile. Vergleiche beide Kurven. Wenn die mobile Sichtbarkeit deutlich unter der Desktop-Sichtbarkeit liegt, hast du ein Mobile-First-Problem. Filtere nach Verzeichnissen, um zu identifizieren, welche Seitenbereiche betroffen sind.

CMS-spezifische Mobile-Probleme

WordPress

WordPress-Themes sind oft Desktop-first entwickelt. Typische Probleme:

• Page Builder (Elementor, Divi) generieren überdimensioniertes CSS und JS für Mobilgeraete
• Slider-Plugins laden Desktop-Bilder auch auf Mobilgeraeten
• WooCommerce-Produkttabellen brechen mobil um und werden unleserlich
• Contact Form 7 und andere Formular-Plugins haben keine mobil-optimierten Layouts

Lösung: Prüfe mit wp_is_mobile() und lade mobilspezifische Assets:

// functions.php - Mobile-spezifische Optimierungen
add_action('wp_enqueue_scripts', function() {
    if (wp_is_mobile()) {
        wp_dequeue_script('slider-plugin');
        wp_dequeue_style('desktop-animations');
        wp_enqueue_style('mobile-optimized', get_template_directory_uri() . '/mobile.css');
    }
});

Shopify

Shopify-Themes sind grundsaetzlich responsive, aber:

• Liquid-Templates laden häufig alle Sections, auch wenn sie mobil per CSS versteckt werden
• App-basierte Widgets (Reviews, Upsells) laden zusätzliches JS unabhängig vom Geraet
• Predictive Search kann auf schwachen Geraeten traege reagieren

Astro und statische Frameworks

Astro hat hier einen natürlichen Vorteil: kein Client-Side JavaScript per Default. Aber auch Astro-Sites können mobile Probleme haben:

• Island-Komponenten mit schwerem JS (React/Svelte) verschlechtern INP auf Mobilgeraeten
• Fehlende responsive Bilder, weil Astros Image-Komponente nicht immer korrekt konfiguriert ist
• Keine automatische Mobile-Navigation — muss bewusst gebaut werden

Mobile-First und interne Verlinkung: Der unterschaetzte Hebel

Ein Punkt, der bei Mobile-First-Audits fast immer untergeht: die interne Verlinkung. Auf Desktop-Seiten findet man oft Sidebar-Links, Footer-Navigationen mit 30+ Links und kontextuelle Verlinkungen in breiten Layouts. Mobil fallen viele dieser Links weg — entweder durch Responsive-Breakpoints, die Sidebars entfernen, oder durch vereinfachte mobile Navigationen.

Das Problem: Google nutzt die mobile Version für die Indexierung. Wenn mobil 40 Prozent weniger interne Links vorhanden sind, schwachst du deine gesamte interne Linkstruktur. Seiten, die auf Desktop gut erreichbar sind, werden mobil möglicherweise gar nicht gefunden.

Die Lösung ist nicht, mobil einfach alle Desktop-Links zu übernehmen. Stattdessen:

• Stelle sicher, dass die mobile Hauptnavigation alle zentralen Seitenbereiche abdeckt.
• Nutze kontextuelle Verlinkungen im Fliesstext — die funktionieren auf beiden Geraetetypen. Das betrifft auch die Onpage-Optimierung insgesamt.
• Prüfe Breadcrumbs: Sie sind ein einfaches, aber effektives Mittel, um interne Verlinkung geraeteuebergreifend stabil zu halten.
• Vermeide reine Desktop-Sidebar-Links für kritische SEO-Seiten. Wenn eine Seite nur über die Sidebar erreichbar ist, fehlt sie mobil komplett.

Mobile interne Links quantifizieren

Hier ein konkreter Workflow: Crawle deine Website in Screaming Frog einmal als Desktop-Googlebot und einmal als Mobile-Googlebot. Exportiere für beide Crawls die Spalte “Unique Inlinks”. Vergleiche die Werte pro URL. Seiten, die mobil signifikant weniger Inlinks haben, sind deine Problemkandidaten.

In Ahrefs kannst du das ergänzen: Prüfe unter Site Audit die interne Verlinkungsstruktur und filtere nach Seiten mit weniger als 3 internen Links. Diese Seiten sind für Google schwer erreichbar — mobil wie desktop.

Mobile-spezifische Structured Data

Ein oft übersehener Punkt: Strukturierte Daten müssen auf der mobilen Version identisch mit der Desktop-Version sein. Wenn du Schema Markup nur im Desktop-Template implementiert hast oder ein Plugin strukturierte Daten nur auf Desktop ausliefert, fehlen Google diese Signale komplett.

Prüfe das konkret: Rufe eine Seite in Chrome DevTools im Mobile-Modus auf, öffne den Seitenquelltext und suche nach application/ld+json. Vergleiche mit der Desktop-Version. Bei responsiven Sites ist das normalerweise kein Problem, aber bei adaptiven Designs oder separaten Mobile-URLs ist es eine häufige Fehlerquelle.

In Screaming Frog kannst du das automatisiert prüfen: Crawle als Mobile-Googlebot, extrahiere JSON-LD und vergleiche mit dem Desktop-Crawl. Diskrepanzen sind sofortige Handlungsfelder.

Mobile Crawl-Budget und Indexierung

Google vergibt Crawl-Budget basierend auf der mobilen Version. Wenn deine mobile Seite langsamer laedt als Desktop, crawlt Google weniger Seiten pro Tag. Das betrifft besonders grosse Sites mit tausenden Seiten — E-Commerce-SEO ist hier besonders anfällig.

Prüfe in der Google Search Console unter Einstellungen die Crawling-Statistiken. Wenn die durchschnittliche Antwortzeit mobil über 500ms liegt, optimiere Server-Antwortzeiten und reduziere die Seitengröße. Jede Millisekunde zählt, wenn Google 1.000+ Seiten pro Tag crawlen soll.

Mobile-First-Indexing und Conversion

Mobile-First-Indexing ist nicht nur ein SEO-Thema. Es trifft direkt auf die Conversion-Ebene. Wenn Nutzer mobil zuerst kommen, aber mobil das Vertrauen, die Klarheit oder die Geschwindigkeit fehlen, verlierst du Nachfrage vor dem ersten qualifizierten Kontakt.

Besonders bei komplexeren Leistungen müssen Mobilansichten nicht “kleiner”, sondern fokussierter werden: weniger Reibung, klare Struktur, schnelle Einordnung, sauberer CTA. Die Prinzipien der Conversion Rate Optimierung gelten mobil verstaerkt, weil der Bildschirmplatz begrenzt und die Aufmerksamkeitsspanne kuerzer ist.

Prüfe in GA4 die Conversion-Rate getrennt nach Device-Kategorie. Wenn Mobile deutlich unter Desktop liegt (was normal ist), quantifiziere den Gap. Ein typischer Wert: Mobile konvertiert 30-60 % schlechter als Desktop. Alles darueber hinaus deutet auf UX-Probleme hin, die du beheben kannst.

Mobile-First Monitoring: Laufende Überwachung

Mobile-First ist kein einmaliges Audit. Templates ändern sich, Plugins werden aktualisiert, neue Seitenbereiche kommen hinzu. Richte ein laufendes Monitoring ein:

Woechentlich:

• Sistrix Mobile-Sichtbarkeitsindex prüfen (Einbrueche deuten auf mobile Probleme hin)
• Google Search Console: Mobile Usability Report auf neue Fehler prüfen

Monatlich:

• Screaming Frog Crawl als Mobile-Googlebot, Vergleich mit vorherigem Monat
• PageSpeed Insights für Top-10-Seiten: Haben sich Core Web Vitals verschlechtert?
• GA4: Conversion-Rate Mobile vs. Desktop prüfen, Gap quantifizieren

Quartalsweise:

• Reale Geraete-Tests auf zwei Smartphones (aktuelles iPhone, Android-Mittelklasse)
• Mobile Content-Paritaets-Check: Neue Inhalte auf Desktop auch mobil vorhanden?
• Interne Verlinkung: Desktop/Mobile-Vergleich der Inlink-Zahlen in Screaming Frog

Dieses Monitoring verhindert, dass mobile Probleme unbemerkt die Sichtbarkeit erodieren. Gerade bei größeren Websites mit mehreren Redakteuren und regelmäßigen Änderungen ist das unverzichtbar.

Mobile-First-Indexing mit Think11

Think11 betrachtet Mobile-First-Indexing als Schnittstelle aus SEO, Content-Struktur, interner Verlinkung und technischer Umsetzung. Wir prüfen nicht nur, ob Seiten responsive wirken, sondern ob die mobile Version dieselben Ranking- und Conversion-Signale traegt wie Desktop. Genau dort entstehen oft die Hebel, die Rankings stabilisieren und mobile Anfragen planbarer machen.