Marketing-Glossar

Crawling & Indexierung – So findet Google deine Seiten

Zuletzt aktualisiert: 17.03.2026 · Redaktion Think11

Crawling und Indexierung bilden das Fundament, auf dem jede SEO-Strategie steht. Bevor deine Seite in den SERPs auftauchen kann, muss Google sie erst finden (Crawling) und dann in seinen Index aufnehmen (Indexierung). Klingt trivial, ist es aber nicht. Wir sehen bei unseren Kunden regelmäßig, dass technisch fehlerhafte Crawling-Steuerung dafür sorgt, dass hunderte relevante Seiten nie im Index landen — oder dass Google sein Crawl-Budget mit irrelevanten URLs verschwendet. Wer diesen Prozess nicht versteht und aktiv steuert, überlässt sein Ranking dem Zufall.

Was ist Crawling und wie funktioniert der Googlebot?

Crawling beschreibt den automatisierten Prozess, mit dem Suchmaschinen das Web durchsuchen. Google setzt dafür den Googlebot ein — ein Software-Programm, das systematisch URLs aufruft, den HTML-Quellcode herunterlädt und die gefundenen Links verfolgt, um weitere Seiten zu entdecken.

Der Googlebot arbeitet nicht wie ein Mensch, der eine Website von der Startseite aus durchklickt. Er verwaltet eine gigantische Liste bekannter URLs, die sogenannte Crawl Queue. Neue URLs gelangen über mehrere Wege in diese Warteschlange: durch Links auf bereits bekannten Seiten, durch XML-Sitemaps, durch direkte URL-Einreichung in der Google Search Console oder durch Verweise von externen Websites (Backlinks).

Für jede URL in der Queue entscheidet Google, ob und wann sie gecrawlt wird. Dabei spielen mehrere Faktoren eine Rolle: Wie häufig ändert sich der Inhalt? Wie wichtig ist die Seite (gemessen an internen und externen Links)? Wie schnell antwortet der Server? Der Googlebot existiert in verschiedenen Varianten — der primäre Crawler für die Websuche, ein Smartphone-Crawler für Mobile-First-Indexing, ein Crawler für Bilder, einer für Videos und spezialisierte Crawler für News und Discover.

Ein häufiges Missverständnis: Der Googlebot rendert nicht jede Seite sofort vollständig. Google nutzt ein zweistufiges System. Im ersten Durchgang wird der HTML-Code heruntergeladen und Links extrahiert. Das vollständige Rendering mit JavaScript-Ausführung erfolgt in einer separaten Phase, die Stunden oder Tage später stattfinden kann. Für Websites, die ihre Inhalte primär per JavaScript generieren, ist das ein kritischer Punkt.

Was ist Indexierung und wann nimmt Google eine Seite auf?

Indexierung ist der Schritt nach dem Crawling. Google analysiert den gecrawlten Inhalt, versteht seine Bedeutung und speichert ihn in einem strukturierten Index — einer riesigen Datenbank, die bei Suchanfragen durchsucht wird. Nur Seiten, die im Index sind, können in den Suchergebnissen erscheinen.

Der Indexierungsprozess umfasst mehrere Schritte: Google analysiert den Text, identifiziert Hauptthema und Nebentopics, extrahiert strukturierte Daten (Schema Markup), prüft Canonical Tags und bewertet die inhaltliche Qualität. Dabei erkennt Google auch Duplikate. Wenn mehrere Seiten nahezu identischen Inhalt haben, wird nur eine Version indexiert — die kanonische URL.

Nicht jede gecrawlte Seite wird indexiert. Google lehnt Seiten ab, die qualitativen Mindeststandards nicht genügen: Thin Content (zu wenig Substanz), Duplicate Content (bereits in anderer Form vorhanden), Spam-Signale oder explizite Noindex-Anweisungen. Laut internen Google-Studien sind weniger als die Hälfte aller gecrawlten URLs tatsächlich im Index. Die Search Console zeigt unter “Seiten” detailliert, welche URLs indexiert sind und warum andere ausgeschlossen wurden.

Wir sehen bei unseren Kunden immer wieder dasselbe Muster: Unternehmen erstellen Inhalte, aber prüfen nie, ob diese überhaupt indexiert werden. Ein Blog mit 200 Artikeln, von denen Google nur 80 in den Index aufnimmt, hat ein fundamentales Problem, das durch keine Keyword-Recherche und keine Content-Marketing-Strategie kompensiert werden kann.

Crawl-Budget: Warum nicht jede URL gecrawlt wird

Das Crawl-Budget ist die Anzahl an URLs, die Google innerhalb eines bestimmten Zeitraums auf deiner Website crawlen will und kann. Es setzt sich aus zwei Komponenten zusammen: dem Crawl-Rate-Limit (wie schnell darf der Googlebot crawlen, ohne den Server zu überlasten) und dem Crawl-Demand (wie sehr möchte Google die URLs crawlen).

Für kleine Websites mit unter 10.000 Seiten ist das Crawl-Budget selten ein Problem. Google crawlt regelmäßig alle Seiten, und die Indexierung funktioniert reibungslos. Kritisch wird es bei größeren Websites: Online-Shops mit hunderttausenden Produktseiten, Nachrichtenportale mit täglichen Publikationen, Plattformen mit nutzergenerierten Inhalten oder Websites mit dynamisch generierten URL-Parametern.

Stell dir vor, ein Online-Shop hat 50.000 Produktseiten, aber zusätzlich 200.000 URLs durch Filterseiten, Sortieroptionen und Paginierung. Google muss entscheiden, welche dieser 250.000 URLs es crawlt. Wenn der Bot die meiste Zeit mit Filterseiten verbringt, die kaum Suchrelevanz haben, werden neue Produkte erst Wochen später entdeckt und indexiert.

Crawl-Budget-Verschwendung hat reale Konsequenzen. Ein Kunde aus dem E-Commerce kam mit dem Problem zu uns, dass neue Produkte erst nach drei bis vier Wochen in den SERPs erschienen. Die Ursache: Über 300.000 facettierte Filter-URLs, die der Googlebot priorisierte, weil sie intern massiv verlinkt waren. Nach Bereinigung durch gezielte robots.txt-Regeln und Canonical-Tags sank die Indexierungszeit neuer Produkte auf unter fünf Tage.

robots.txt, Sitemaps und Meta Robots: Die Steuerungsinstrumente

Die Crawling- und Indexierungssteuerung basiert auf drei zentralen Instrumenten, die unterschiedliche Aufgaben erfüllen und präzise eingesetzt werden müssen.

robots.txt ist eine Textdatei im Root-Verzeichnis der Domain, die Suchmaschinen-Crawlern Anweisungen gibt, welche Verzeichnisse oder URLs nicht gecrawlt werden sollen. Sie steuert ausschließlich das Crawling, nicht die Indexierung. Eine per robots.txt blockierte URL kann theoretisch trotzdem im Index erscheinen, wenn andere Seiten auf sie verlinken — Google kennt dann die URL, hat aber den Inhalt nicht.

Typische Einsatzzwecke: interne Suchseiten blockieren, Admin-Bereiche ausschließen, Staging-Umgebungen abschirmen, facettierte Navigation einschränken. Fehler bei der robots.txt-Konfiguration gehören zu den destruktivsten SEO-Problemen. Ein einzelner falscher Disallow-Eintrag kann tausende Seiten aus dem Index entfernen. Wir haben einen Fall erlebt, bei dem ein Relaunch die robots.txt mit “Disallow: /” überschrieben hat — die gesamte Website war innerhalb von zwei Wochen aus dem Google-Index verschwunden.

XML-Sitemaps sind maschinenlesbare Dateien, die Google eine Liste aller relevanten URLs samt Metadaten (letzte Änderung, Änderungsfrequenz, Priorität) übermitteln. Sie sind besonders wertvoll für große Websites, neue Websites mit wenigen externen Links und Seiten, die durch die interne Linkstruktur schwer erreichbar sind. Die Sitemap ist kein Garant für Indexierung — sie ist eine Empfehlung an Google, diese URLs zu berücksichtigen.

Best Practices: Nur kanonische, indexierbare URLs aufnehmen. Keine URLs mit Noindex-Tag, keine per Canonical auf andere Seiten verweisenden URLs, keine 404-Seiten. Die lastmod-Angabe ehrlich pflegen — Google ignoriert Sitemaps, wenn das Datum bei jeder Aktualisierung pauschal auf “heute” gesetzt wird, ohne dass sich der Inhalt geändert hat. Sitemaps in der Google Search Console einreichen und den Indexierungsstatus regelmäßig prüfen.

Meta Robots Tags und X-Robots-Tag steuern die Indexierung auf Seitenebene. Mit “noindex” verhinderst du, dass eine Seite im Index erscheint. Mit “nofollow” sagst du Google, dass die Links auf dieser Seite nicht gewertet werden sollen. Das X-Robots-Tag funktioniert identisch, wird aber per HTTP-Header übermittelt und eignet sich damit auch für PDF-Dateien und andere Nicht-HTML-Ressourcen.

Entscheidend ist das Zusammenspiel: Du kannst eine Seite per Meta Robots auf “noindex” setzen, musst sie aber für das Crawling zugänglich lassen. Wenn du die URL gleichzeitig per robots.txt blockierst, sieht Google das Noindex-Tag nie — und könnte die Seite trotzdem indexieren, falls sie extern verlinkt wird.

Mobile-First Indexing: Googles Standard seit 2023

Seit dem vollständigen Rollout von Mobile-First Indexing im Oktober 2023 nutzt Google ausschließlich die mobile Version einer Website für Crawling und Indexierung. Die Desktop-Version wird nicht mehr als primäre Quelle herangezogen. Das hat direkte Konsequenzen für die Crawling- und Indexierungsstrategie.

Wenn die mobile Version einer Seite weniger Inhalte zeigt als die Desktop-Version — etwa durch ausgeblendete Textabschnitte, fehlende interne Links oder andere Navigationsstrukturen — dann existieren diese Inhalte für Google nicht. Wir haben bei mehreren Kunden erlebt, dass nach dem Wechsel zu einer Mobile-First-optimierten Seite Rankings eingebrochen sind, weil die mobile Version bestimmte Content-Blöcke per CSS ausgeblendet hat.

Prüfe folgende Punkte für eine Mobile-First-konforme Crawling-Struktur: Ist der gesamte Content der Desktop-Version auch mobil verfügbar? Sind alle internen Links auf der mobilen Version vorhanden? Sind die strukturierten Daten (Schema Markup) auf beiden Versionen identisch? Sind Meta Robots Tags auf Desktop und Mobil konsistent? Lädt die mobile Version schnell genug, um gute Core Web Vitals zu erzielen?

JavaScript-Rendering und Crawling: Die unterschätzte Hürde

JavaScript-basierte Websites stellen Google vor besondere Herausforderungen. Frameworks wie React, Angular und Vue.js generieren Inhalte erst clientseitig — der initiale HTML-Code enthält oft nur ein leeres Container-Element. Google muss die Seite vollständig rendern, um den tatsächlichen Inhalt zu sehen.

Google nutzt dafür den Web Rendering Service (WRS), der auf einer Chromium-Engine basiert. Das Problem: Das Rendering passiert asynchron zum Crawling. Google crawlt die URL, sieht zunächst nur den leeren HTML-Container und stellt die Seite in eine Rendering-Queue. Tage später wird sie gerendert, der Inhalt extrahiert und indexiert. In der Zwischenzeit kennt Google den eigentlichen Content nicht.

Für geschäftskritische Seiten ist das ein Risiko. Es gibt drei Lösungsansätze: Server-Side Rendering (SSR) liefert vollständiges HTML aus, das Google sofort lesen kann. Static Site Generation (SSG) erzeugt statische HTML-Dateien beim Build. Dynamic Rendering erkennt Crawler und liefert ihnen eine vorgerenderte Version. SSR und SSG sind die saubersten Lösungen, Dynamic Rendering ist ein Workaround für Legacy-Systeme.

Wir empfehlen grundsätzlich: Jede URL, die in den SERPs ranken soll, muss ihren wesentlichen Content im initialen HTML ausliefern — ohne JavaScript-Abhängigkeit. Das ist keine Frage der Bequemlichkeit, sondern der Indexierungssicherheit.

Typische Crawling- und Indexierungsprobleme diagnostizieren

Die Google Search Console ist das wichtigste Diagnosewerkzeug. Unter “Seiten” (früher “Abdeckung”) zeigt sie den Indexierungsstatus jeder URL mit detaillierten Gründen für Ausschlüsse. Die häufigsten Probleme, die wir bei Audits identifizieren:

“Gecrawlt — derzeit nicht indexiert”: Google hat die Seite besucht, aber entschieden, sie nicht in den Index aufzunehmen. Ursachen: Thin Content, Duplicate Content, zu geringe wahrgenommene Qualität. Das betrifft oft Kategorieseiten mit wenig eigenem Text oder Blog-Artikel, die ein Thema nur oberflächlich behandeln.

“Gefunden — derzeit nicht indexiert”: Google kennt die URL (etwa aus der Sitemap oder internen Links), hat sie aber noch nicht gecrawlt. Häufig bei großen Websites mit Crawl-Budget-Problemen. Die URL steht in der Warteschlange, wird aber nicht priorisiert.

“Durch robots.txt blockiert”: Die URL ist per robots.txt vom Crawling ausgeschlossen. Prüfe, ob das beabsichtigt ist. Fehlkonfigurationen blockieren regelmäßig wichtige Seiten.

“Duplikat — von Google gewählte kanonische URL weicht vom Nutzer ab”: Du hast eine kanonische URL definiert, Google hat sich anders entschieden. Das passiert, wenn Google der Meinung ist, eine andere Seite sei die bessere kanonische Variante — etwa weil sie mehr externe Links hat oder der Content identisch ist.

“Soft 404”: Google erkennt die Seite als funktionale 404-Seite, obwohl sie den HTTP-Statuscode 200 zurückgibt. Das passiert bei leeren Kategorieseiten, Produktseiten ohne Inhalt oder Suchseiten ohne Ergebnisse.

Für tiefergehende Analysen eignen sich Crawling-Tools wie Screaming Frog, Sitebulb oder Lumar. Sie simulieren den Googlebot und decken technische Probleme auf, bevor Google sie entdeckt: defekte Links, Redirect-Ketten, kanonische Inkonsistenzen, fehlende Hreflang-Tags und Performance-Engpässe.

Indexierungssteuerung für verschiedene Website-Typen

Die optimale Crawling- und Indexierungsstrategie hängt stark vom Website-Typ ab. Eine pauschale Lösung gibt es nicht.

E-Commerce-Websites haben die größten Herausforderungen: Tausende Produktseiten, facettierte Navigation, saisonale Sortimente, vergriffene Artikel. Die Strategie muss definieren, welche Filterseiten indexiert werden (nur die mit Suchvolumen), wie mit vergriffenen Produkten umgegangen wird (301-Redirect vs. Soft 404 vs. “nicht verfügbar”-Status) und wie die interne Linkstruktur das Crawl-Budget auf die wichtigsten Seiten lenkt. Parameter-Handling über Canonical Tags statt robots.txt ist hier oft der bessere Weg, weil Google den Canonical-Hinweis respektiert und trotzdem die Linkpower durchreicht.

Publisher und Nachrichtenseiten leben von schneller Indexierung. Neue Artikel müssen innerhalb von Minuten im Index sein. Hier helfen die Google Indexing API (für Job-Postings und Livestreams), WebSub/PubSubHubbub für Feeds, eine saubere XML-Sitemap mit korrekten lastmod-Werten und die Einreichung über die Search Console URL-Prüfung. Die Herausforderung: Alte Artikel nicht verwässern lassen. Ein Archiv mit 50.000 kaum besuchten Artikeln kann das Crawl-Budget belasten.

SaaS-Plattformen generieren oft dynamische URLs pro Nutzer oder Workspace. Login-geschützte Bereiche sollten konsequent per robots.txt und Noindex-Tag ausgeschlossen werden. Öffentliche Seiten — Preisseite, Feature-Übersicht, Blog, Integrations-Verzeichnis — bilden den SEO-relevanten Kern und brauchen eine saubere, flache Architektur mit kurzen Klickwegen.

Internationale Websites mit Hreflang-Implementierungen erfordern besondere Aufmerksamkeit. Jede Sprachversion muss crawlbar und indexierbar sein, die Hreflang-Annotations müssen bidirektional korrekt sein, und Canonical Tags dürfen nicht versehentlich alle Sprachversionen auf eine einzige kanonische URL zeigen. Fehlerhafte Hreflang-Setups gehören zu den komplexesten Crawling-Problemen, die wir in Audits finden.

Log-File-Analyse: Den Googlebot direkt beobachten

Die Log-File-Analyse ist das ehrlichste Instrument, um zu verstehen, wie Google deine Website tatsächlich crawlt. Während die Search Console aggregierte Berichte liefert, zeigen Server-Logs jeden einzelnen Request des Googlebots: welche URL, wann, mit welchem User-Agent, welchen Statuscode der Server zurückgegeben hat.

Daraus lassen sich Fragen beantworten, die kein anderes Tool beantwortet: Welche Seiten crawlt Google am häufigsten? Welche Verzeichnisse ignoriert er? Gibt es Seiten, die nie gecrawlt werden? Wie reagiert der Server auf den Googlebot — mit Timeouts, 5xx-Fehlern, langsamen Antwortzeiten? Stimmt das Crawling-Verhalten mit der Sitemap überein?

Wir setzen Log-File-Analysen bei jedem umfassenden SEO-Audit ein. Der Erkenntnisgewinn ist regelmäßig höher als erwartet. Ein Beispiel: Bei einem Kunden mit 80.000 indexierbaren Seiten zeigte die Log-Analyse, dass der Googlebot 60 % seines Crawl-Budgets für interne Suchseiten aufwendete, die per Noindex markiert, aber nicht per robots.txt blockiert waren. Google crawlte sie trotzdem, weil sie intern massiv verlinkt waren. Die Lösung: robots.txt-Block für /search/ plus Entfernung der internen Links zu Suchseiten. Das Crawling der eigentlichen Inhaltsseiten verdoppelte sich innerhalb eines Monats.

Tools für die Log-File-Analyse: Screaming Frog Log File Analyser, Lumar (ehemals Deepcrawl), On Crawl oder eigene Auswertungen mit ELK Stack oder BigQuery. Die Integration mit Google Analytics 4 oder dem Google Tag Manager liefert zusätzlichen Kontext, indem Crawling-Daten mit Nutzerverhalten verknüpft werden.

Think11-Praxis

Crawling und Indexierung sind kein Set-it-and-forget-it-Thema. Wir behandeln sie bei Think11 als laufenden Prozess, nicht als einmalige Konfiguration. In über 110 aktiven Kundenprojekten haben wir ein Muster erkannt: Die meisten SEO-Probleme, die uns als Ranking-Verluste gemeldet werden, haben ihre Wurzel in der technischen Crawling-Ebene.

Unser Vorgehen bei jedem neuen SEO-Mandat beginnt mit einem technischen Crawl-Audit. Wir kombinieren Screaming Frog, Search Console Daten und — wo verfügbar — Log-File-Analysen, um ein vollständiges Bild zu zeichnen. Die Ergebnisse priorisieren wir nach Business-Impact: Welche Seiten generieren Umsatz oder Leads? Sind diese sauber indexiert? Gibt es Crawling-Hindernisse, die verhindern, dass neue Inhalte gefunden werden?

Als Google Premium Partner (Top 3 %) haben wir direkten Zugang zu Google-Ansprechpartnern, die bei komplexen Indexierungsproblemen unterstützen. Das ist kein Marketing-Claim, sondern praktischer Vorteil: Wenn eine Website nach einem Relaunch plötzlich aus dem Index verschwindet, können wir schneller eskalieren als Agenturen ohne diesen Zugang. CEO Schahab Hosseiny hat diesen Prozess in zahlreichen Enterprise-Projekten etabliert, in denen Indexierungsfehler sechsstellige Umsatzeinbußen pro Woche verursacht haben.

Unsere Empfehlung: Prüfe monatlich den Indexierungsbericht in der Search Console. Richte Alerts ein, wenn die Anzahl indexierter Seiten signifikant sinkt. Und behandle deine robots.txt und Sitemap wie geschäftskritische Konfigurationsdateien — mit Versionierung, Review-Prozessen und Monitoring. Wir unterstützen dich dabei mit unserer SEO-Beratung und Web-Analytics-Expertise, die technische Daten in strategische Entscheidungen übersetzt.

Profilbild von Schahab Hosseiny
Think11 Team
Antwort in wenigen Sekunden