Die kurze Antwort
Die Mobile-First-Indexierung ist abgeschlossen. Seit Juli 2024 verwendet Google ausschließlich die mobile Version Ihrer Website für die Indexierung und das Ranking. Wenn Inhalte, strukturierte Daten oder interne Links auf dem Desktop, aber nicht auf dem Mobilgerät vorhanden sind, sieht Google sie nicht. Im Jahr 2026 hat dies drei neue Konsequenzen, mit denen sich die meisten Website-Betreiber noch nicht befasst haben: INP hat FID als Core Web Vital ersetzt, AI Overviews greifen auf mobil gerenderte Inhalte zu, und das März-2026-Core-Update hat das Ranking-Gewicht der mobilen Page Experience erhöht.
Nachfolgend finden Sie einen vollständigen Audit-Workflow – und eine Copy-Paste-Codex-Skill, die die meisten Prüfungen für Sie durchführt.
Was "nur mobil" im Jahr 2026 tatsächlich bedeutet
Google begann 2018 damit, Websites auf die Mobile-First-Indexierung umzustellen. Die Umstellung dauerte über sechs Jahre. Seit Juli 2024 hat jede Website, die noch desktop-exklusive Inhalte ohne mobiles Äquivalent hatte, diese Inhalte aus dem Google-Index verloren. Es gibt kein Opt-out und keinen Desktop-Fallback.
Doch damit endete die Geschichte nicht. Drei Entwicklungen in den Jahren 2025–2026 haben verändert, was "Mobile-First" von Ihrer Website verlangt:
Entwicklung 1: INP hat FID ersetzt – und die meisten mobilen Websites scheitern daran
Im März 2024 ersetzte Google den First Input Delay (FID) durch den Interaction to Next Paint (INP) als Core Web Vital. INP misst, wie schnell Ihre Seite auf Taps, Klicks und Tastendrücke während der gesamten Seiten-Session reagiert – nicht nur bei der ersten Interaktion.
Die harte Zahl: Rund 40 % der Websites, die FID bestanden haben, bestehen INP nicht. Auf Mobilgeräten erreichen nur etwa 65 % der Websites den "guten" Schwellenwert von 200 Millisekunden oder weniger. Das März-2026-Core-Update hat das Ranking-Gewicht der Core Web Vitals weiter erhöht. Websites, die bei mobilem INP durchfallen, verlieren jetzt Positionen an schnellere Wettbewerber.
Entwicklung 2: AI Overviews und KI-Crawler lesen Ihre mobilen Inhalte
Googles AI Overviews erscheinen Mitte 2026 in rund 47 % aller Suchanfragen. Wenn Googles KI-Systeme Antworten generieren, greifen sie auf dieselben mobil indexierten Inhalte zu, die auch die normale Suche verwendet. Auch Drittanbieter-KI-Crawler (GPTBot, ClaudeBot, PerplexityBot) greifen auf Ihre mobil gerenderten Seiten zu.
Wenn Ihrer mobilen Version strukturierte Daten, klare Überschriften oder wichtige Texte fehlen, können KI-Systeme Sie nicht zitieren – selbst wenn die Desktop-Version diese Inhalte enthält.
Entwicklung 3: Content-Paritätslücken haben jetzt messbare Ranking-Auswirkungen
Im Jahr 2026 zeigen Websites mit inkonsistenten mobilen und Desktop-Inhalten eine durchschnittlich 31,2 % geringere organische Suchpräsenz im Vergleich zu Websites mit vollständiger Content-Parität. Die häufigsten fehlenden Elemente auf Mobilgeräten: versteckte Tab-Inhalte, Sidebar-Links, strukturierte Daten (Markup), Bild-Alt-Texte und interne Navigationslinks.
Inhaltselement | % der Websites, bei denen es mobil fehlt |
|---|---|
Strukturierte Daten (JSON-LD) | 23 % |
Interne Links (Menüs, Breadcrumbs) | 18 % |
Bild-Alt-Texte | 27 % |
Vollständiger Text in Tabs/Akkordeons | 15 % |
Meta-Robots-Tags | 9 % |
So prüfen Sie, ob Ihre Website besteht (2-Minuten-Version)
Bevor Sie ein vollständiges Audit durchführen, prüfen Sie diese drei Signale. Jedes dauert weniger als eine Minute und zeigt Ihnen, ob Sie tiefer graben sollten.
Signal 1: Google Search Console – Indexierungsstatus
Öffnen Sie die Google Search Console → klicken Sie auf Einstellungen (Zahnrad-Symbol, unten links) → sehen Sie im Bereich "Info" nach. Wenn dort unter "Indexierungs-Crawler" "Googlebot-Smartphone" steht, läuft Ihre Website auf Mobile-First-Indexierung. Dies gilt im Jahr 2026 für praktisch jede Website – verifizieren Sie es aber trotzdem.
Prüfen Sie außerdem: URL-Prüftool → geben Sie eine wichtige Seite ein → klappen Sie "Crawl" aus → bestätigen Sie "Gecrawlt als: Googlebot-Smartphone". Sehen Sie sich den Screenshot an, den Google bereitstellt – das ist genau das, was Google sieht. Wenn wichtige Inhalte auf diesem Screenshot fehlen, fehlen sie auch im Index.
Signal 2: PageSpeed Insights mit echten mobilen Daten
Gehen Sie zu PageSpeed Insights, geben Sie Ihre URL ein und sehen Sie sich den Bereich "Entdecken Sie, was Ihre echten Nutzer erleben" an. Dies sind Chrome User Experience Report (CrUX)-Felddaten – dieselben Daten, die Google für das Ranking verwendet.
Wenn der mobile Bericht für INP (Interaction to Next Paint) Orange oder Rot anzeigt, haben Sie eine aktive Ranking-Belastung. Der Schwellenwert liegt bei unter 200 Millisekunden für Grün.
Signal 3: Chrome DevTools – mobiler Viewport-Schnellcheck
Öffnen Sie die Chrome DevTools (F12 oder Cmd+Option+I), klicken Sie auf das Gerätesymbol (Ctrl+Shift+M) und wählen Sie ein mobiles Geräte-Preset wie "Pixel 7". Laden Sie die Seite neu. Achten Sie auf:
- Text, der horizontales Scrollen erfordert
- Schaltflächen oder Links, die zu klein zum Antippen sind (unter 48×48 CSS-Pixel)
- Inhalte, die hinter "Weiterlesen"-Umschaltern versteckt sind und sich nicht im HTML-Quelltext befinden
- Pop-ups, die den Großteil des Bildschirms verdecken
Jedes dieser Probleme ist ein Mobile-First-Indexierungsproblem, wenn die dahinter liegenden Inhalte oder Links sich von dem unterscheiden, was Desktop-Nutzer sehen.
Das 30-minütige Mobile-First-Audit (mit Codex)
Der schnellste Weg, heute ein vollständiges Mobile-First-Audit durchzuführen, besteht darin, einem KI-Coding-Agenten – Claude Code oder Codex – eine strukturierte Aufgabe zu geben. Der Agent liest den Quelltext Ihrer Website, prüft die Regeln und erstellt eine priorisierte Behebungsliste.
Nachfolgend finden Sie eine vollständige Skill-Datei. Kopieren Sie sie in Ihr Projekt und bitten Sie dann Ihren Agenten, sie auszuführen.
Schritt 1: Skill-Datei erstellen
Erstellen Sie eine Datei unter .claude/skills/mobile-first-audit/SKILL.md (für Claude Code) oder .codex/skills/mobile-first-audit/SKILL.md (für Codex):
name: mobile-first-audit
description: Audit a URL or list of URLs for mobile-first indexing readiness. Checks content parity, Core Web Vitals, structured data, mobile UX, and AI crawler access.
# Mobile-First Indexing Audit
Run a structured mobile-first indexing audit on one or more URLs. The agent must report findings, not make edits, unless the user explicitly approves a fix plan.
## Input
The user provides one or more page URLs. If they provide a sitemap URL or a list of more than 5 URLs, sample 5 URLs that represent different page types (homepage, product page, article, category page, landing page).
## Audit Checklist
For each URL, check and report on all eleven items below. Mark each item as `PASS`, `WARN`, or `FAIL`. Include the evidence for every WARN and FAIL.
### 1. Viewport Meta Tag
Check that `<meta name="viewport" content="width=device-width, initial-scale=1">` is present in the HTML `<head>`. If missing or if it sets a fixed width or disables user-scaling without a valid accessibility reason, mark FAIL.
### 2. Content Parity (Text)
Fetch the page with a desktop user-agent and a mobile user-agent (Googlebot Smartphone). Compare the visible text content. If any text block over 50 words exists on desktop but not in the mobile HTML source, mark WARN. If important body text, headings, or product descriptions are missing, mark FAIL.
### 3. Structured Data Parity
Extract all JSON-LD blocks from both desktop and mobile fetches. If any schema type present on desktop is missing from mobile, mark FAIL. If schema content differs between versions, mark WARN.
### 4. Meta Tags Parity
Compare title, meta description, canonical, robots, and hreflang tags between desktop and mobile versions. Any difference is a WARN. A missing canonical or conflicting robots tag is FAIL.
### 5. Internal Links and Navigation
Count the number of internal `<a href>` links in the desktop and mobile HTML. If the mobile version has 20%+ fewer internal links, mark WARN. If breadcrumb links, category navigation, or footer links present on desktop are missing from mobile, mark FAIL.
### 6. Image Alt Text
Count images in the mobile HTML. Report the number and percentage missing alt attributes. If more than 10% of images lack alt text, mark WARN. If hero images or product images lack alt text, mark FAIL.
### 7. Core Web Vitals (Field Data)
Look up the URL's Chrome UX Report (CrUX) field data. If accessible via PageSpeed Insights API or a direct CrUX lookup, report LCP, INP, and CLS for mobile. Mark thresholds: LCP > 2.5s = WARN, > 4.0s = FAIL. INP > 200ms = WARN, > 500ms = FAIL. CLS > 0.1 = WARN, > 0.25 = FAIL.
If CrUX data is unavailable (insufficient traffic), note this and use lab data from Lighthouse as a fallback with the caveat that lab data is not used for ranking.
### 8. Tap Target Sizing
Inspect CSS for buttons, links, and interactive elements. Flag any element whose computed height or width is under 48 CSS pixels. Flag adjacent interactive elements with less than 8px spacing. Mark WARN for 1-3 violations, FAIL for 4+.
### 9. Font Sizing
Check that body text uses a computed font-size of at least 16px. Flag any text below 12px. Mark WARN if body text is 14-15px, FAIL if below 12px.
### 10. Interstitials and Pop-ups
Visually inspect the mobile viewport. If a pop-up, banner, or interstitial covers more than 30% of the initial viewport and is not legally required (cookie consent, age verification), mark WARN. If the pop-up prevents scrolling or reading content, mark FAIL.
### 11. AI Crawler Access
Check robots.txt for rules blocking GPTBot, ClaudeBot, PerplexityBot, Google-Extended, or OAI-SearchBot. If any AI crawler is blocked, note that as a deliberate choice. If AI crawlers are allowed but the page has no structured data, mark WARN (AI systems rely on structured data for citations).
## Output Format
Produce a Markdown report:
```markdown
# Mobile-First Audit Report
**Date:** YYYY-MM-DD
**URLs audited:** N
**Overall score:** X/11 PASS items per URL average
## Summary
| Check | URL 1 | URL 2 | URL 3 | URL 4 | URL 5 |
|-------|-------|-------|-------|-------|-------|
| 1. Viewport | PASS | PASS | ... | ... | ... |
| ... | ... | ... | ... | ... | ... |
## Detailed Findings
### URL 1: [url]
**FAIL items (must fix):**
- [Item name]: [evidence and fix instructions]
**WARN items (should fix):**
- [Item name]: [evidence and fix instructions]
**PASS items:** [list]
### Priority Fix Queue
1. [Highest priority fix] — affects indexing directly
2. [Next fix] — affects ranking
3. ...Rules
- Do not make any changes to the site without explicit user approval of a fix plan.
- If you cannot check an item because the page requires authentication, note it as "NOT CHECKED — authentication required."
- For CrUX data, use the official Chrome UX Report API or PageSpeed Insights API if available. If neither is accessible, use Lighthouse mobile audit as a fallback.
- Never fabricate metrics, scores, or check results. If data is unavailable, say so.
- Do not access or expose API keys, cookies, tokens, or credentials.
### Schritt 2: Audit ausführen
Bitten Sie Ihren Agenten: **"Run the mobile-first audit skill on [your URL]"** und fügen Sie die URL ein, die Sie prüfen möchten. Der Agent erstellt einen Bericht mit PASS/WARN/FAIL für jede der 11 Prüfungen sowie eine priorisierte Behebungsliste.
Wenn Sie mehrere Seiten auf einmal prüfen möchten, geben Sie eine Liste an: **"Run the mobile-first audit on these 5 URLs: [URL1, URL2, URL3, URL4, URL5]"**.
## Lösung 1: Content-Parität – was Sie zuerst prüfen sollten
Content-Parität ist die wirkungsvollste Lösung, da sie direkt bestimmt, was Google indexieren kann. Hier sind die häufigsten Probleme und wie Sie sie beheben.
### Versteckte Inhalte in Tabs und Akkordeons
Viele Websites komprimieren auf Mobilgeräten lange Inhalte in Tabs, Akkordeons oder "Weiterlesen"-Umschalter. Das ist in Ordnung, **solange der Inhalt im HTML-Quelltext vorhanden ist** – Google wertet aus UX-Gründen versteckte Inhalte nicht mehr ab. Wenn Ihre Tabs Inhalte jedoch per JavaScript nach einem Nutzer-Tap laden, löst Googlebot diesen Tap nicht aus. Der Inhalt ist unsichtbar.
**So prüfen Sie es:** Klicken Sie in den Chrome DevTools mit der rechten Maustaste auf versteckte Inhalte und wählen Sie "Untersuchen". Wenn Sie den Text im Elemente-Panel sehen, ist er im DOM und Google kann ihn sehen. Zeigt das Elemente-Panel einen leeren Container, bis Sie auf den Tab klicken, wird der Inhalt dynamisch geladen und Google verpasst ihn.
**So beheben Sie es:** Rendern Sie die versteckten Inhalte serverseitig in das HTML. Verwenden Sie CSS (`display: none` oder Sichtbarkeits-Umschalter) für das Ein-/Ausblend-Verhalten anstelle von JavaScript-Content-Injection.
### Fehlende strukturierte Daten auf Mobilgeräten
Strukturierte Daten (JSON-LD) müssen im mobilen HTML vorhanden sein. Dies wird leicht übersehen, wenn Ihr mobiles Theme oder Ihre AMP-Version eine andere Vorlage verwendet.
**So prüfen Sie es:** Öffnen Sie die mobile Seite, zeigen Sie den Quelltext an (`Cmd+Option+U`) und suchen Sie nach `application/ld+json`. Machen Sie dasselbe auf dem Desktop. Dieselben JSON-LD-Blöcke sollten in beiden Versionen erscheinen.
**So beheben Sie es:** Stellen Sie sicher, dass Ihre strukturierten Daten serverseitig gerendert und in derselben HTML-Antwort für Mobilgeräte und Desktop enthalten sind. Wenn Sie ein CMS verwenden, prüfen Sie, ob Ihr Schema-Plugin oder Theme Skripte nicht basierend auf Geräteerkennung bedingt lädt.
### Aus mobilen Menüs entfernte Navigationslinks
Mobile Menüs vereinfachen oder entfernen oft Links, die in der Desktop-Navigation vorhanden sind: Breadcrumbs, Kategorie-Links, Footer-Spalten, Sidebar-Links. Google verwendet interne Links, um die Seitenstruktur zu verstehen und PageRank zu verteilen. Links, die auf Mobilgeräten fehlen, fehlen auch in Googles Graphen.
**So prüfen Sie es:** Zählen Sie die `<a href>`-Tags im Desktop-Quelltext im Vergleich zum mobilen Quelltext. Ein responsives Design sollte ungefähr gleiche Anzahlen haben. Wenn die mobile Anzahl 30 %+ niedriger ist, untersuchen Sie, welche Links verschwunden sind.
**So beheben Sie es:** Fügen Sie fehlende Navigationslinks zum mobilen Menü, Hamburger-Menü oder Footer hinzu. Priorisieren Sie Links zu wichtigen Kategorieseiten, Schlüsselartikeln und übergeordneten Seiten.
## Lösung 2: INP – die mobile Geschwindigkeitsmetrik, die die meisten Websites ignorieren
Interaction to Next Paint (INP) misst, wie lange es dauert, bis die Seite visuell reagiert, nachdem ein Nutzer tippt, klickt oder eine Taste drückt. Der Schwellenwert liegt bei **200 Millisekunden oder weniger**.
Im Gegensatz zu FID, das nur die Eingabeverzögerung der ersten Interaktion maß, misst INP jede Interaktion und meldet die **schlechteste**. Dies macht es zu einem deutlich strengeren Test.
### Was die mobile INP verschlechtert
Die häufigsten Ursachen, in Reihenfolge:
1. **Schweres JavaScript, das im Hauptthread läuft.** Große Bundles, nicht optimierte React/Vue-Komponenten und Tracking-Skripte blockieren den Browser bei der Reaktion auf Taps.
2. **Click-Handler, die zu viel Arbeit vor der Aktualisierung der UI erledigen.** Wenn ein Tap einen API-Aufruf, State-Update und DOM-Änderung auslöst, bevor ein visuelles Feedback erscheint, leidet die INP.
3. **Drittanbieter-Tags.** Analyse-, Chat-Widgets, Werbenetzwerke und Personalisierungsskripte – besonders wenn mehrere Tags um den Hauptthread konkurrieren.
### So diagnostizieren Sie INP
1. Öffnen Sie [PageSpeed Insights](https://pagespeed.google.com/), geben Sie Ihre URL ein und scrollen Sie zu "Entdecken Sie, was Ihre echten Nutzer erleben". Der INP-Wert unter "Mobil" ist das, was Google verwendet.
2. Öffnen Sie in den Chrome DevTools das **Performance**-Panel, klicken Sie auf Aufnahme, interagieren Sie mit der Seite (tippen Sie auf Schaltflächen, öffnen Sie Menüs, geben Sie Text ein) und beenden Sie dann die Aufnahme. Achten Sie auf lange Tasks (rot markiert, 200 ms+). Dies sind Ihre INP-Probleme.
3. Sie können auch Ihren KI-Agenten fragen: **"Check the Core Web Vitals for [URL] and tell me specifically what is hurting INP on mobile. Give me the top 3 fixes in priority order."**
### So beheben Sie INP (Prioritätsreihenfolge)
```text
Priorität 1: Nicht kritische Drittanbieter-Skripte zurückstellen oder verzögern.
→ Laden Sie Chat-Widgets, Analyse- und Werbe-Tags, nachdem die Seite interaktiv ist.
→ Verwenden Sie <script defer> oder laden Sie sie 3–5 Sekunden nach dem Seitenaufruf.
Priorität 2: Lange JavaScript-Tasks aufteilen.
→ Code-Splitting nach Route. Komponenten unterhalb des Folds per Lazy Loading laden.
→ Schwere Berechnungen in requestIdleCallback() oder einen Web Worker auslagern.
Priorität 3: Click-Handler die UI sofort aktualisieren lassen.
→ Zeigen Sie einen Ladezustand, Spinner oder deaktivierten Button innerhalb der ersten 50 ms an.
→ Führen Sie die eigentliche Arbeit (API-Aufruf, State-Update) nach der visuellen Antwort aus.Lösung 3: KI-Crawler-Bereitschaft (die 2026-Ebene)
Die Mobile-First-Indexierung hat jetzt eine KI-Ebene. Wenn Googles AI Overviews oder Drittanbieter-KI-Systeme eine Frage beantworten, greifen sie auf dieselben mobil indexierten Inhalte zu. Wenn Ihren mobilen Seiten die Signale fehlen, nach denen KI-Systeme suchen, verlieren Sie Zitate.
Was KI-Systeme von Ihren mobilen Seiten benötigen
Signal | Warum es wichtig ist | Schnellcheck |
|---|---|---|
Strukturierte Daten (JSON-LD) | Hilft KI-Systemen, Entitäten, Produkte, Artikel, FAQs zu verstehen | Quelltext anzeigen → nach |
Klare Überschriften-Hierarchie | KI-Extraktoren nutzen H1–H4, um die Seitenstruktur zu analysieren | Scannen Sie Ihre Seite: Hat jeder Abschnitt eine beschreibende Überschrift? |
Kurze Antwortblöcke | AI Overviews bevorzugen 2–4 Sätze umfassende Antworten im oberen Bereich | Beantwortet Ihre Seite die Hauptfrage in den ersten 200 Wörtern? |
Robots.txt-Zugriff für KI-Crawler | Wenn blockiert, können KI-Systeme Ihre Inhalte nicht abrufen | Prüfen Sie robots.txt auf |
llms.txt-Datei | Hilft KI-Systemen, Ihre wichtigsten Inhalte effizient zu entdecken | Prüfen Sie |
Schneller KI-Bereitschafts-Prompt für Ihren Agenten
"Check [URL] for AI search readiness. Tell me: (1) is JSON-LD structured data present and valid? (2) is there a clear answer to the page's main question in the first 200 words? (3) are AI crawlers allowed in robots.txt? (4) does llms.txt exist at the root? Give me a PASS/FAIL for each and tell me what to fix first."
Vollständige Mobile-First-Audit-Prompts für Einsteiger
Hier ist eine Reihe von Prompts, die Sie direkt in Claude Code oder Codex kopieren können. Jeder Prompt erledigt eine spezifische Aufgabe – keine Konfiguration erforderlich, außer dass der Agent geöffnet und auf Ihr Projekt oder eine URL gerichtet ist.
Prompt 1: Einzelseiten-Mobile-Audit
Run a mobile-first indexing audit on [YOUR URL HERE].
Check these 8 things and report PASS or FAIL for each with the evidence:
1. Viewport meta tag is correct
2. All body text visible on desktop is also in the mobile HTML source
3. JSON-LD structured data is the same on desktop and mobile
4. Title tag, meta description, and canonical are identical across desktop and mobile
5. Internal link count is roughly equal (not 20%+ fewer on mobile)
6. Images have alt text
7. Mobile Core Web Vitals (LCP, INP, CLS) from CrUX field data if available
8. AI crawlers (GPTBot, ClaudeBot, PerplexityBot, Google-Extended) are not blocked in robots.txt
For each FAIL, give me the exact fix in one sentence.Prompt 2: Massen-Audit über verschiedene Seitentypen
I need to audit mobile-first readiness across different page types on my site. Here are 5 URLs, each representing a different template:
1. [HOMEPAGE URL]
2. [PRODUCT PAGE OR SERVICE PAGE URL]
3. [BLOG POST OR ARTICLE URL]
4. [CATEGORY OR COLLECTION PAGE URL]
5. [ABOUT OR CONTACT PAGE URL]
For each URL, check: viewport meta tag, content parity (text + structured data), meta tags consistency, internal links, image alt coverage, and mobile font/tap-target sizing.
Then produce a single table with all 5 URLs as columns and each check as a row. Color-code PASS green, WARN yellow, FAIL red (use emoji 🟢 🟡 🔴 if colors are not supported). Below the table, list the top 3 fixes across all pages in priority order.Prompt 3: Content-Paritäts-Tiefenanalyse
Fetch [URL] with both a desktop user-agent and the Googlebot Smartphone user-agent (Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/W.X.Y.Z Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)).
Compare the two versions and report any differences in:
- Visible text content (highlight blocks missing from mobile)
- Structured data (JSON-LD blocks)
- Meta tags (title, description, canonical, robots, hreflang)
- Internal link count and which sections lost links
- Image alt attributes
Do not make any edits. Just produce a diff report.Prompt 4: INP-Diagnose und Behebungsplan
Analyze [URL] for Interaction to Next Paint (INP) issues on mobile.
1. Check if CrUX field data is available and report the current mobile INP value.
2. If CrUX data is unavailable, run a Lighthouse mobile audit and report the Total Blocking Time (TBT) as a proxy indicator.
3. Identify the top 3 JavaScript tasks blocking the main thread during page load and after user interaction.
4. For each problem, give me: the specific file or script causing it, the impact on INP, and the one-line fix.
Format the output as a table: Problem | Source | Impact | Fix.Prompt 5: KI-Crawler + Strukturierte-Daten-Audit
Check [URL] for AI search and AI crawler readiness:
1. Crawl robots.txt at the domain root. List all rules that mention these user-agents: GPTBot, ClaudeBot, PerplexityBot, Google-Extended, OAI-SearchBot, Amazonbot, Bytespider. If any are blocked, flag it.
2. Extract all JSON-LD blocks from the page. Validate each against Schema.org types. Report which types are present and whether they are complete (all required properties filled).
3. Check if /llms.txt exists at the domain root. If it does, report its content summary. If it does not, note that as a missing AI discovery asset.
4. Check if the page has a clear, self-contained answer (2-4 sentences) to its main topic within the first 200 words of body text.
5. Score the page on AI readiness: 0-100. Deduct points for: missing structured data (-30), blocked AI crawlers (-20 per crawler), no llms.txt (-15), no clear answer block (-20), headings not descriptive (-15).FAQ
F: Kann ich weiterhin eine separate mobile Website (m.beispiel.de) verwenden? Technisch ja, aber Google empfiehlt responsives Design. Separate mobile URLs erhöhen die Komplexität: Sie müssen identische Inhalte, Canonical-Tags und Hreflang über zwei URL-Sets hinweg pflegen. Wenn etwas aus dem Takt gerät, indexiert Google die Version, die zuletzt gecrawlt wurde. Responsives Design eliminiert dieses Risiko vollständig.
F: Was ist, wenn meine Website nur für Desktop ist – überhaupt keine mobile Version? Wenn Googlebot-Smartphone nicht auf Ihre Inhalte zugreifen und sie rendern kann, werden diese Inhalte nicht indexiert. Punkt. Eine reine Desktop-Website ist im Jahr 2026 für Google praktisch unsichtbar. Wenn Sie sich in dieser Situation befinden, ist die Umstellung auf ein responsives Theme Ihre Aufgabe mit höchster Priorität.
F: Muss ich mich um Tablet-Größen kümmern? Googlebot crawlt als Smartphone, nicht als Tablet. Konzentrieren Sie sich auf den Smartphone-Viewport. Allerdings sind Tablet-Nutzer echte Nutzer – stellen Sie sicher, dass Ihr responsives Design bei mittleren Breiten (768–1024 px) nicht bricht.
F: Woher weiß ich, ob meine Website die Mobile-First-Umstellung bereits bestanden hat? Öffnen Sie die Google Search Console → Einstellungen → prüfen Sie den Bereich "Info" auf "Indexierungs-Crawler: Googlebot-Smartphone". Wenn das dort steht, sind Sie auf Mobile-First-Indexierung. Das sind inzwischen nahezu alle Websites.
F: Crawlt Google meine Website noch mit einem Desktop-User-Agent für irgendetwas? Ja. Google crawlt gelegentlich mit einem Desktop-User-Agent für bestimmte Prüfungen (Beziehungsverifikation, einige Neuverarbeitungen strukturierter Daten). Seien Sie nicht beunruhigt, wenn Sie Desktop-Googlebot in Ihren Logs sehen. Diese Besuche bedeuten nicht, dass Ihre Website auf Desktop-First-Indexierung läuft.
F: Wird die Behebung von Mobile-First-Problemen meine AI-Overview-Sichtbarkeit verbessern? Die Behebung von Mobile-First-Indexierungsproblemen verbessert die Grundlage. Wenn Ihre mobilen Inhalte, strukturierten Daten und die Seitengeschwindigkeit alle solide sind, sind Ihre Inhalte zitierfähig – aber Googles KI-Systeme wählen immer noch basierend auf Relevanz, Autorität und Antwortqualität aus, was sie zitieren. Die Behebung von Mobile-First-Problemen beseitigt einen Blocker; sie garantiert keine KI-Aufnahme.
Autor: Julian Mercer, 14 Jahre Technical-SEO-Praktiker bei Auspia. Julian schreibt über Crawlbarkeit, Rendering, Schema, Seitenarchitektur und die technischen Grundlagen, die Inhalte für Suchmaschinen und KI-Systeme auffindbar machen.
