Was ist Indexierung?

Indexierung bezeichnet die Aufnahme einer Webseite in den Google-Index, die durchsuchbare Datenbank der Suchmaschine. Nur indexierte Seiten können in den Suchergebnissen ranken. Bevor eine Seite indexiert wird, durchläuft sie zwei Schritte: das Crawling (Google findet und lädt die Seite) und das Rendering (Google baut die Seite inklusive JavaScript zusammen). Erst danach entscheidet Google, ob die Seite in den Index aufgenommen wird.

Die Indexierung ist die Eintrittskarte in die Google-Suche. Eine Seite, die nicht im Index steht, existiert für Google praktisch nicht, egal wie gut ihr Inhalt ist. Deshalb ist die Kontrolle über den Indexierungsstatus eine der wichtigsten Aufgaben im technischen SEO.

Kurzprofil des Begriffs

Was bedeutet Indexierung bei Google?

Indexierung bedeutet, dass Google eine Seite analysiert, versteht und in seinen Index einsortiert. Der Google-Index ist eine riesige Datenbank, in der Google Milliarden von Webseiten samt ihren Inhalten, Schlüsselbegriffen und Metadaten speichert. Stellt ein Nutzer eine Suchanfrage, durchsucht Google nicht das Live-Web, sondern diesen vorbereiteten Index, das macht die Suche in Sekundenbruchteilen möglich.

Eine indexierte Seite ist also für ein Ranking überhaupt erst qualifiziert. Wichtig ist die Abgrenzung: Indexierung ist die Voraussetzung fürs Ranking, keine Garantie dafür. Google nimmt eine Seite in den Index auf und entscheidet danach über einen völlig separaten Bewertungsprozess, auf welcher Position sie zu welchem Suchbegriff erscheint. Viele indexierte Seiten ranken für kein einziges relevantes Keyword auf Seite 1.

Google indexiert längst nicht jede gefundene URL. Die Suchmaschine trifft eine Auswahl und ignoriert Seiten, die sie für minderwertig, doppelt oder irrelevant hält. In der Google Search Console tauchen solche URLs im Status „Gefunden – zurzeit nicht indexiert“ oder „Gecrawlt – zurzeit nicht indexiert“ auf.

Crawling, Rendering, Indexierung – was ist der Unterschied?

Crawling, Rendering und Indexierung sind drei aufeinanderfolgende Phasen, die eine Seite durchläuft, bevor sie in der Suche erscheint. Sie werden oft verwechselt, beschreiben aber klar getrennte Vorgänge.

1. Crawling: Der Crawler (Googlebot) besucht eine URL und lädt ihren Quelltext herunter. Voraussetzung: Die Seite darf nicht per robots.txt vom Crawling ausgeschlossen sein.
2. Rendering: Google baut die Seite so zusammen, wie ein Browser sie darstellt, inklusive nachgeladener Inhalte per JavaScript. Erst nach dem Rendering sieht Google den vollständigen Inhalt.
3. Indexierung: Google bewertet den gerenderten Inhalt und speichert die Seite im Index, sofern sie den Qualitätskriterien genügt und kein Signal die Aufnahme verbietet.

Die Reihenfolge ist entscheidend: Ohne Crawling kein Rendering, ohne Rendering keine vollständige Indexierung. Ein häufiges Missverständnis betrifft das Zusammenspiel von robots.txt und noindex. Eine per robots.txt blockierte Seite kann Google gar nicht crawlen und liest deshalb auch kein noindex im Quelltext, ein Widerspruch, der viele Indexierungsprobleme verursacht.

Warum wird meine Seite nicht indexiert?

Eine Seite wird nicht indexiert, wenn ein technisches Signal die Aufnahme verhindert oder Google den Inhalt für nicht wertvoll genug hält. Die häufigsten Ursachen lassen sich in zwei Gruppen teilen: technische Blockaden und Qualitätsentscheidungen.

Technische Blockaden sind meist gewollt oder ein Konfigurationsfehler:

• noindex-Signal: Ein noindex-Attribut im Meta-Tag oder ein X-Robots-Tag im HTTP-Header weist Google an, die Seite nicht in den Index aufzunehmen.
• Crawl-Sperre: Ein Eintrag in der robots.txt blockiert den Zugriff. Google kann die Seite dann nicht lesen und ein etwaiges index-Signal nie sehen.
• Canonical auf eine andere URL: Zeigt der Canonical-Tag auf eine andere Seite, wertet Google die aktuelle URL als Kopie und indexiert stattdessen das Original.
• Fehlende interne Verlinkung: Findet Google eine Seite über keinen internen Link und keine Sitemap, wird sie oft gar nicht erst gecrawlt.

Qualitätsentscheidungen trifft Google eigenständig. Dünner Inhalt, nahezu identische Duplikate oder Seiten ohne erkennbaren Mehrwert landen im Status „Gecrawlt – zurzeit nicht indexiert“. Hier hilft kein technischer Schalter, sondern nur besserer, eigenständiger Inhalt. In der Praxis ist genau diese Diagnose, technisches Problem oder Qualitätsproblem, ein Kernstück jedes SEO-Audits.

Wie prüft man den Indexierungsstatus?

Den Indexierungsstatus prüfst du am zuverlässigsten in der Google Search Console. Das kostenlose Tool zeigt für jede verifizierte Website exakt, welche Seiten im Index stehen und warum andere fehlen. Es gibt drei bewährte Wege:

1. URL-Prüfung in der Search Console: Einzelne URL eingeben, Google zeigt „URL ist auf Google“ oder den konkreten Ausschlussgrund. Der genaueste Weg für eine einzelne Seite.
2. Bericht „Seiten“: Zeigt alle indexierten und nicht indexierten URLs der gesamten Website, gruppiert nach Ursache. Ideal, um Muster zu erkennen.
3. site:-Abfrage bei Google: Die Suche nach site:deine-domain.de listet grob die indexierten Seiten. Das ist nur eine Stichprobe, keine exakte Zahl, aber ein schneller erster Blick ohne Login.

Für einzelne wichtige Seiten kannst du in der Search Console über „Indexierung beantragen“ das Crawling anstoßen. Google stellt die URL dann in die Warteschlange, eine Garantie oder feste Frist für die Aufnahme gibt es aber nicht.

Wie steuert man Indexierung (noindex, canonical, robots)?

Die Indexierung steuerst du über drei Instrumente, die an unterschiedlichen Stellen ansetzen. Jedes hat eine klar abgegrenzte Aufgabe, und ihre Verwechslung ist die häufigste Fehlerquelle im technischen SEO.

• robots.txt steuert das Crawling, nicht die Indexierung. Sie sagt Google, welche Bereiche es nicht besuchen soll. Eine per robots.txt gesperrte Seite kann trotzdem im Index landen, wenn andere Seiten auf sie verlinken, dann aber ohne Snippet.
• noindex steuert die Indexierung direkt. Das Signal als Meta-Tag oder X-Robots-Tag hält eine Seite zuverlässig aus dem Index. Wichtig: Die Seite muss crawlbar bleiben, sonst liest Google das noindex nie.
• Canonical steuert, welche von mehreren gleichen URLs indexiert wird. Der Canonical-Tag bündelt Duplikate auf eine bevorzugte Version und vermeidet so Duplicate Content.

Die Faustregel lautet: robots.txt regelt den Zugang, noindex regelt die Aufnahme, Canonical regelt die Auswahl unter Duplikaten. Wer eine Seite verlässlich aus dem Index halten will, setzt noindex und lässt die Seite crawlbar. Wer Crawl-Budget sparen will, nutzt die robots.txt, akzeptiert aber, dass ein noindex dort wirkungslos ist.

Häufige Fragen zur Indexierung

Wie lange dauert die Indexierung einer neuen Seite?
Von wenigen Stunden bis zu mehreren Wochen. Bei etablierten, häufig gecrawlten Websites geht es meist schnell, bei neuen Domains ohne Verlinkung kann es dauern. Eine feste Frist garantiert Google nicht.

Bedeutet indexiert, dass meine Seite auf Platz 1 steht?
Nein. Indexierung ist nur die Voraussetzung dafür, dass eine Seite überhaupt ranken kann. Auf welcher Position sie erscheint, entscheidet ein separater Bewertungsprozess anhand von Relevanz und Qualität.

Wie beantrage ich die Indexierung einer Seite?
Über die URL-Prüfung in der Google Search Console mit der Funktion „Indexierung beantragen“. Das stellt die URL in die Crawl-Warteschlange, erzwingt die Aufnahme aber nicht.

Warum verschwinden indexierte Seiten wieder aus dem Index?
Google entfernt Seiten, wenn sie dauerhaft einen Fehler liefern, ein noindex erhalten, per Canonical auf eine andere URL zeigen oder an Qualität und Relevanz verlieren. Ein regelmäßiger Blick in den Search-Console-Bericht „Seiten“ deckt solche Verluste auf.

Was ist Interaction to Next Paint (INP)?

Interaction to Next Paint (INP) ist eine Metrik der Core Web Vitals, die die Reaktionsfähigkeit einer Webseite misst. INP erfasst die Verzögerung zwischen einer Nutzerinteraktion – etwa einem Klick, Tippen oder einer Tastatureingabe – und der nächsten sichtbaren Reaktion auf dem Bildschirm, und zwar über die gesamte Dauer des Seitenbesuchs. Seit März 2024 ist INP ein stabiles Core Web Vital und ersetzt die frühere Metrik First Input Delay (FID). Als guter Wert gilt eine Verzögerung von maximal 200 Millisekunden am 75. Perzentil aller Seitenaufrufe.

INP beantwortet eine einfache Frage aus Nutzersicht: Wie schnell reagiert die Seite, wenn ich etwas anklicke oder eintippe? Eine Seite kann blitzschnell laden und trotzdem träge wirken, wenn jeder Klick eine spürbare Gedenksekunde braucht. Genau diese gefühlte Trägheit macht INP messbar – und damit zu einem festen Bestandteil jeder technischen Core Web Vitals-Optimierung.

Kurzprofil des Begriffs

Was ist INP genau?

INP misst die gesamte Latenz einer Interaktion – nicht nur den Moment, in dem der Browser die Eingabe entgegennimmt. Jede Interaktion durchläuft drei Phasen, und INP addiert sie zur vollständigen Verzögerung bis zum nächsten gerenderten Bild (dem „next paint“):

• Input Delay (Eingabeverzögerung): Die Zeit vom Klick bis zum Start der Verarbeitung. Ist der Haupt-Thread gerade mit einer langen Aufgabe blockiert, wartet die Eingabe.
• Processing Time (Verarbeitungszeit): Die Dauer, die der zugehörige Event-Handler im JavaScript braucht, um die Reaktion zu berechnen.
• Presentation Delay (Darstellungsverzögerung): Die Zeit, bis der Browser das Ergebnis tatsächlich auf den Bildschirm zeichnet.

Über den gesamten Seitenbesuch sammelt der Browser alle Interaktionen und meldet am Ende einen einzigen, repräsentativen Wert – bei den meisten Seiten die langsamste Interaktion. Klicks, Taps und Tastatureingaben zählen dazu; reines Scrollen und Hovern nicht, weil sie keine unmittelbare gerenderte Reaktion auslösen müssen.

Was ist ein guter INP-Wert?

Ein guter INP-Wert liegt bei maximal 200 Millisekunden. Google bewertet INP – wie alle Core Web Vitals – am 75. Perzentil: Mindestens 75 Prozent aller Seitenaufrufe müssen den Schwellenwert einhalten, damit die Seite als „gut“ gilt. Es gibt drei Bewertungsstufen:

• Gut: 200 ms oder schneller. Die Seite fühlt sich flüssig an, Interaktionen wirken unmittelbar.
• Verbesserungswürdig: zwischen 200 ms und 500 ms. Nutzer spüren eine leichte Verzögerung.
• Schlecht: über 500 ms. Die Seite reagiert spürbar träge, was Absprünge begünstigt.

Wichtig: Der 75.-Perzentil-Ansatz bedeutet, dass einzelne langsame Interaktionen die gesamte Bewertung kippen können. Es reicht nicht, dass die Seite „meistens“ schnell reagiert – auch die selteneren, schweren Interaktionen müssen im Rahmen bleiben. Wie schnell die Seite lädt, misst dagegen der Largest Contentful Paint (LCP); wie stabil das Layout bleibt, der Cumulative Layout Shift (CLS).

INP vs. FID: Was ist neu?

INP hat First Input Delay (FID) als Core Web Vital abgelöst, weil es die Reaktionsfähigkeit einer Seite deutlich vollständiger abbildet. Der Unterschied liegt in drei Punkten:

• Alle Interaktionen statt nur der ersten: FID maß ausschließlich die Verzögerung der ersten Interaktion auf einer Seite. INP berücksichtigt alle Interaktionen während des gesamten Besuchs.
• Volle Latenz statt nur Input Delay: FID erfasste nur die Eingabeverzögerung bis zum Start der Verarbeitung. INP misst die komplette Kette bis zum sichtbaren Ergebnis – inklusive Verarbeitung und Darstellung.
• Realistischeres Bild: Weil FID nur den ersten Klick und nur dessen Anfang maß, erzielten viele Seiten gute FID-Werte, obwohl sie sich im weiteren Verlauf träge anfühlten. INP deckt diese Lücke.

Am 12. März 2024 wurde INP offiziell zum stabilen Core Web Vital, FID wurde im September 2024 aus den Core Web Vitals entfernt. Für die Praxis heißt das: Wer seine Seite früher auf einen guten FID-Wert optimiert hat, sollte den INP separat prüfen – ein guter alter FID-Wert garantiert keinen guten INP.

Wie wird INP gemessen?

INP wird primär mit Felddaten echter Nutzer gemessen (Field Data), lässt sich aber auch im Labor annähern. Beide Perspektiven ergänzen sich:

• Felddaten (maßgeblich): Der Chrome User Experience Report (CrUX) sammelt anonymisierte INP-Werte echter Chrome-Nutzer. Diese Daten fließen in die Google Search Console und in PageSpeed Insights ein. Nur Felddaten zählen für die offizielle Core-Web-Vitals-Bewertung.
• Labordaten (zur Diagnose): Werkzeuge wie Lighthouse oder die Chrome DevTools simulieren Interaktionen, um konkrete Engpässe zu finden. Da im Labor keine echten Nutzer klicken, ist der Laborwert nur eine Annäherung.

Für eine belastbare Bewertung braucht es genügend echten Traffic, damit CrUX-Daten vorliegen. Fehlen sie, hilft nur die Labor-Diagnose – oder ein eigenes Real-User-Monitoring, das die INP-Werte der Besucher direkt im Browser erfasst.

Wie verbessert man INP?

INP verbessert man vor allem, indem man den Haupt-Thread des Browsers entlastet – denn die häufigste Ursache für schlechte Werte ist blockierendes JavaScript. Die wirksamsten Hebel:

1. Lange Aufgaben aufteilen: Zerlege umfangreiche JavaScript-Aufgaben in kleinere Häppchen und gib den Haupt-Thread zwischendurch frei (Yielding), damit anstehende Interaktionen nicht warten müssen.
2. Event-Handler verschlanken: Halte die Verarbeitung in Klick- und Eingabe-Handlern kurz. Aufwändige, nicht sofort sichtbare Arbeit lässt sich auf später verschieben.
3. Rendering-Arbeit reduzieren: Ein großer oder tief verschachtelter DOM verlängert die Darstellungsphase. Ein schlankes Markup verkürzt den Weg bis zum next paint.
4. Third-Party-Skripte prüfen: Tracking-, Chat- und Werbeskripte belegen den Haupt-Thread oft unbemerkt. Weniger oder verzögert geladene Fremdskripte entlasten die Interaktivität spürbar.

In der Praxis ist die INP-Optimierung eng mit dem Rest des Performance-Profils verzahnt. Ein strukturierter SEO-Audit deckt auf, welche Skripte und Vorlagen die Reaktionsfähigkeit ausbremsen – und in welcher Reihenfolge sich die Optimierung am meisten lohnt.

Häufige Fragen zu INP

Ist INP ein Rankingfaktor?
INP ist als Core Web Vital Teil des Page-Experience-Signals und damit ein Rankingfaktor – allerdings ein vergleichsweise schwacher. Relevanz und Inhaltsqualität wiegen deutlich schwerer. Ein guter INP schadet nie, ersetzt aber keine gute Seite.

Warum ist mein INP im Labor gut, im Feld aber schlecht?
Weil im Labor niemand wirklich klickt. Laborwerkzeuge simulieren nur einzelne Interaktionen, während echte Nutzer komplexe Formulare, Menüs und Filter bedienen. Für die Bewertung zählen ausschließlich die Felddaten aus CrUX.

Gilt INP auch für mobile Geräte?
Ja, und gerade dort ist er kritisch. Mobile Prozessoren sind schwächer, sodass blockierendes JavaScript stärker durchschlägt. Google bewertet Mobil- und Desktop-Werte getrennt.