Mobile-First Indexing

Konsequenzen für die Praxis

• Content-Parität — Mobile und Desktop müssen dieselben Inhalte zeigen, dieselben H1/H2/Texte, dieselben Bilder mit ALT-Tags, dieselben strukturierten Daten.
• Lazy Loading mit Care — Lazy-Loaded-Content muss für den Googlebot Smartphone laden können (Intersection Observer, kein User-Interaktion-Trigger).
• Bilder vollständig — keine reduzierte Mobile-Galerie, sondern responsive Bildhandhabung.
• Strukturierte Daten identisch — Schema.org-Markup auf Mobile und Desktop gleich.
• Mobile Page Speed — Core Web Vitals werden vom Mobile-Profil gemessen. Mobile ist meist langsamer — also: priorisiert optimieren.

Klassische Mobile-First-Fehler

• Reduzierter Mobile-Content — Tabs, Akkordeons mit „Mehr lesen", ausgeblendete Sektionen, die Desktop zeigt, Mobile nicht.
• Andere Bilder/Videos — kleinere Auswahl auf Mobile.
• Footer-Links und Sitelinks fehlen auf Mobile (gibt es immer noch).
• Mobile-spezifische 404s bei AMP-Pages, die auf Desktop nicht existieren.
• Aggressive Mobile-Interstitials — Cookie- und Newsletter-Pop-ups, die den ganzen Bildschirm einnehmen. Direktes Negativ-Signal.
• Schwer-Klick-Buttons — kleinere als 48×48 px Touch-Ziele werden in Page Experience abgewertet.

Mobile-First in der Search Console

In der GSC unter „Einstellungen" lässt sich der aktive Crawler einsehen — bei den meisten Sites steht „Smartphone" als primär. Die URL-Inspektion zeigt unter „Live testen" den gerenderten Mobile-View, inklusive Konsole-Fehlern und tatsächlich geladenen Inhalten. Diskrepanzen zwischen Live-Test (was Google sieht) und visueller Mobile-Site (was der Nutzer sieht) sind die wichtigste Diagnose-Quelle für Mobile-First-Probleme.