|

Findet Google deine wichtigen Seiten? Indexierung selbst prüfen

Patrick Stolp
Patrick Stolp2. September 2026

Zuletzt aktualisiert:

Hinweis: Mit der Google Search Console lässt sich prüfen, ob Google eine wichtige Seite kennt und weshalb sie fehlt. Nach welchen Kriterien Seiten in den Index aufgenommen oder daraus entfernt werden, veröffentlicht Google allerdings nicht.

Wenn eine Seite bei Google nicht erscheint, liegt das an der Technik? Diese Vermutung höre ich in Erstgesprächen fast immer zuerst, und sie trifft seltener zu, als die meisten denken. Google kennt nämlich zwei Arten von fehlenden Seiten. Bei der ersten kann die Suchmaschine eine Seite nicht erfassen, weil sie ausgesperrt ist oder der Server falsch antwortet. Bei der zweiten kann Google die Seite problemlos abrufen, nimmt sie aber nicht in den Index auf, weil sie aus Googles Sicht nichts liefert, was nicht schon anderswo steht.

Im Ergebnis sehen beide Fälle gleich aus, denn die Seite fehlt. Ursache, Zuständigkeit und Reihenfolge der Prüfung unterscheiden sich allerdings erheblich. Im Bericht „Seitenindexierung“ lassen sich beide Fälle auseinanderhalten. Dadurch wird auch klar, ob du einen Entwickler brauchst, ob die Inhalte geprüft werden müssen oder ob Google lediglich unwichtige Adressen aussortiert hat.

Wie häufig technische Ursachen bei kleinen Unternehmenswebsites vorkommen, habe ich an 91 Lübecker Betrieben geprüft. ChatGPT oder Gemini hatten deren Websites zwischen Juli und September 2026 in meinen Branchen-Radar-Messungen als Quelle verlinkt. Bei jeder zweiten erreichbaren Website fand sich mindestens ein technisches Problem, das Google die Erfassung erschwert. Die dramatischen Fehler, vor denen viele Ratgeber warnen, gehörten allerdings nicht dazu.

Am Anfang steht immer das sichtbare Symptom: Fehlen wichtige Seiten, erscheint fast nur die Startseite oder sind die Rankings nach einem Relaunch eingebrochen? Die Spalte „Meist“ ordnet diese Beobachtungen anhand meiner Erfahrung ein. Sie ist keine allgemeingültige Regel, gibt der anschließenden Prüfung aber eine sinnvolle Richtung.

BeobachtungPrüfung in der Search ConsoleMeistWer behebt
Wichtige Seiten werden nicht als indexiert gemeldetBericht „Seitenindexierung“, Grund der betroffenen URLs lesenBlockade oder Auswahldu selbst, bei Auswahl eine SEO-Analyse
Google zeigt fast nur die StartseiteBericht „Leistung“ nach Seiten filtern, Leistungsseiten mit dem URL-Prüftool testeninterne Verlinkung, noindex oder Auswahldu selbst, danach SEO-Analyse
Nach einem Relaunch sind Rankings verschwundenGründe „Nicht gefunden (404)“ und „Weiterleitungsfehler“, alte Adressen mit dem URL-Prüftool testenFehlerEntwickler
Viele ähnliche Adressen behandeln denselben InhaltGrund „Duplikat, vom Nutzer nicht als kanonisch festgelegt“, von Google gewählte kanonische URL prüfenAuswahl mit technischer UrsacheEntwickler und SEO-Analyse

Crawlen, indexieren und ranken sind drei getrennte Schritte

Bevor eine Seite in den Suchergebnissen erscheinen kann, muss Google sie zunächst finden und abrufen. Dieser Schritt nennt sich Crawling (Seitendurchsuchung). Anschließend wird die Seite verarbeitet. Google führt JavaScript aus, liest den Text sowie die Links und Canonical-Angaben und entscheidet, ob und unter welcher Adresse die Seite in den Index kommt. Erst danach kann sie für einzelne Suchanfragen ausgewählt werden. Eine gecrawlte Seite ist daher noch nicht automatisch indexiert. Und eine indexierte Seite muss für deine Suchanfragen keineswegs sichtbar sein.

Google erhebt dabei gar nicht den Anspruch, alles aufzunehmen. In der Hilfe zum Bericht „Seitenindexierung“ steht dazu ein Satz, den ich jedem Website-Betreiber vorlesen würde:

„Don’t expect every URL on your site to be indexed. Some URLs might be duplicates or might not contain meaningful information. Just be sure that the key pages on your site are indexed.“

Google Search Console-Hilfe, Bericht „Seitenindexierung“

Im Jahr 2026 hat Google diese Haltung noch einmal verschärft. Bei der Veranstaltung Search Central Live in Toronto erklärte Danny Sullivan am 21. April 2026 laut der Mitschrift von Jean-Christophe Chouinard, KI habe die Hürde für das Erstellen von Inhalten gesenkt. Google habe deshalb die Hürde für die Aufnahme in den Index angehoben. Konkrete Kriterien nannte Sullivan nicht. In den Search-Console-Berichten meiner Kunden ist diese strengere Auswahl allerdings seit einiger Zeit zu erkennen.

Gegen die Vorstellung eines einfachen Ja oder Nein spricht auch die 2024 bekannt gewordene interne Google-Dokumentation (der Content-Warehouse-Leak). Darin steht ein Attribut namens scaledSelectionTierRank. Außerdem werden Indexstufen mit den Bezeichnungen Base, Zeppelins und Landfills genannt. Shaun Anderson leitet daraus in seinem Buch „Technical SEO 2025“ einen gestuften Index ab, in dem Seiten je nach Stufe unterschiedliche Chancen erhalten. Kriterien oder Schwellenwerte enthält die Dokumentation hingegen nicht. Im Kartellverfahren gegen Google hielt das US-Justizministerium dazu fest, die Dokumente „don’t go into specifics of the curves and thresholds“. Ob eine Seite indexiert ist, lässt sich also als Zustand ablesen. Wie Google ihren Platz innerhalb des Index bewertet, bleibt von außen unbekannt.

Jede zweite Unternehmenswebsite hat ein technisches Problem bei der Indexierung

Wie häufig technische Ursachen bei kleinen Websites tatsächlich vorkommen, wollte ich nicht schätzen. Für die Messung habe ich deshalb 91 Websites Lübecker Betriebe aus 20 Branchen geprüft, vom Zahnarzt über den Dachdecker bis zur Fahrschule. ChatGPT oder Gemini hatten alle 91 als Quelle verlinkt, als ich die Systeme in meinen monatlichen Branchen-Radar-Messungen nach Empfehlungen fragte. Diese Websites spielen in der KI-Suche also bereits eine Rolle. Gerade deswegen hatte ich mit weniger Problemen gerechnet.

Ein Skript hat je Website vier Adressvarianten (mit und ohne www, http und https), die robots.txt, die XML-Sitemap, die Startseite, bis zu 40 von der Startseite verlinkte Seiten und bis zu 20 Sitemap-Adressen abgerufen. Insgesamt waren das 1.417 verlinkte Seiten und 976 Sitemap-Adressen. Gespeichert wurden ausschließlich Statuscodes und technische Merkmale, keine Inhalte und keine Rankings. Firmennamen nenne ich nicht, weil es um Muster geht und nicht um einzelne Betriebe.

MerkmalWebsites
Website antwortet auf allen vier Adressvarianten mit 401, 403 oder 4044 von 91
Startseite unter mehreren Host-Varianten erreichbar, ohne Weiterleitung auf eine Hauptadresse20 von 87 (23 Prozent)
davon ohne Canonical auf der Startseite12
Keine XML-Sitemap unter den üblichen Adressen16 von 87 (18 Prozent)
Sitemap nennt überwiegend veraltete oder fehlerhafte Adressen4 von 87
Von der Startseite verlinkte Inhaltsseiten mit noindex (Leistungen, Team, Kontakt, Aktuelles)10 von 87 (11 Prozent)
Startseite verlinkt auf Adressen, die erst weiterleiten17 von 87 (20 Prozent)
Startseite verlinkt auf Seiten mit 404 oder 5035 von 87
Nicht existierende Adresse endet mit Status 200 (Soft-404-Verdacht)6 von 87 (7 Prozent)
robots.txt sperrt die gesamte Website0 von 87
Startseite mit noindex0 von 87
Mindestens eines dieser Probleme45 von 87 (52 Prozent)
Zwei oder mehr dieser Probleme21 von 87 (24 Prozent)

Die komplette Sperre per robots.txt und eine Startseite mit noindex fanden sich kein einziges Mal. Genau diese beiden Fehler gelten in Ratgebern oft als typische Ursache fehlender Indexierung. In der Stichprobe lagen die Probleme dagegen in den Überbleibseln früherer Einrichtungen: erreichbare Startseiten mit und ohne www, fehlende Sitemaps, noindex-Angaben auf Leistungsseiten, die vermutlich aus einer Baukasten-Einstellung stammen, und interne Links auf veraltete Adressen. Ein einzelnes derartiges Problem macht noch keine Website unsichtbar. Google muss dadurch jedoch Entscheidungen treffen, die der Betreiber besser eindeutig vorgibt.

Auf allen Adressvarianten antworteten vier Websites nur noch mit einem Fehlercode. Für Google und Besucher waren sie damit nicht mehr erreichbar, während die KI-Systeme sie weiterhin als Quelle für Empfehlungen angaben. Zwischen einer Änderung an der Website und ihrer Wirkung in einer KI-Antwort kann demnach eine erhebliche Verzögerung liegen. Bei der Messung von KI-Sichtbarkeit ist dieser zeitliche Abstand zu berücksichtigen.

Den Bericht „Seitenindexierung“ in drei Gruppen lesen

Unter „Indexierung“ und „Seiten“ listet die Search Console alle Adressen, die Google von deiner Website kennt. Dabei wird zwischen indexierten und nicht indexierten Seiten unterschieden. Für jede nicht indexierte Adresse nennt Google einen Grund, sortiert diese Gründe allerdings nicht nach ihrer Ursache. Ich ordne sie deshalb den drei Gruppen Blockade, Fehler und Auswahl zu. Aus dieser Einteilung ergibt sich unmittelbar, wer das Problem sinnvoll prüfen kann.

GruppeGründe im BerichtWas dahintersteckt
BlockadeDurch robots.txt-Datei blockiert; durch noindex-Tag ausgeschlossen; wegen Zugriffsverbot (403) oder nicht autorisierter Anforderung (401) blockiertDu oder dein System haben Google ausgesperrt, meist unabsichtlich. Das behebst du selbst oder mit deinem Webdienstleister in Minuten.
FehlerServerfehler (5xx); Nicht gefunden (404); Weiterleitungsfehler; Soft 404Der Server antwortet falsch oder die Adresse existiert nicht mehr. Ein Thema für den Entwickler.
AuswahlGecrawlt, zurzeit nicht indexiert; Gefunden, zurzeit nicht indexiert; Duplikat, vom Nutzer nicht als kanonisch festgelegt; Alternative Seite mit richtigem kanonischen Tag; Seite mit WeiterleitungGoogle konnte die Seite erfassen und hat sich entschieden. Die Ursache liegt in Duplikaten, im Inhalt oder in der Bedeutung der Seite innerhalb deiner Website.

In den Berichten meiner Kunden steht „Gecrawlt, zurzeit nicht indexiert“ fast immer an erster Stelle. Danach folgen meist „Seite mit Weiterleitung“ und „Nicht gefunden (404)“. Weiterleitungen und 404-Adressen sind häufig Altlasten früherer Umbauten und für sich genommen harmlos, sofern die Weiterleitungsziele indexiert sind und keine wichtigen Seiten fehlen. Bei den gecrawlten, aber nicht indexierten Seiten muss dagegen geklärt werden, ob die Website ein technisches oder ein inhaltliches Problem hat.

So gehst du vor:

  1. Öffne in der Search Console den Bericht „Seitenindexierung“ und notiere, wie viele Seiten indexiert und wie viele nicht indexiert sind. Die zweite Zahl ist bei fast jeder Website höher, und das ist normal.
  2. Ordne jeden genannten Grund einer der drei Gruppen zu. Blockade und Fehler sind Technik, Auswahl ist es nicht.
  3. Klicke jeden Grund an und prüfe die betroffenen Adressen. Zähle nur die Seiten, die für dein Geschäft wichtig sind: Startseite, Leistungsseiten, Standortseiten, Kontakt. Eine nicht indexierte Tag-Seite oder ein alter Bildanhang ist kein Problem.
  4. Gib jede wichtige, nicht indexierte Adresse in das URL-Prüftool ein. Es zeigt dir, ob Google die Seite crawlen und indexieren darf, wann sie zuletzt gecrawlt wurde und welche Adresse Google als kanonisch gewählt hat. Weicht die von Google gewählte kanonische URL von deiner ab, hast du ein Duplikat-Problem gefunden.
  5. Verwende den Live-Test nur, um Blockaden und Fehler auszuschließen. Er prüft laut Google weder Duplikate noch die Qualität der Seite. Ein bestandener Live-Test bedeutet deshalb nicht, dass die Seite indexiert wird.

Verlasse dich bei dieser Prüfung nicht auf die Suche nach „site:deine-domain.de“ bei Google. Sie ist unvollständig und nennt keinen Grund, falls eine Adresse fehlt. Auch die Schaltfläche „Indexierung beantragen“ repariert keine Seite. Laut der Google-Hilfe zum URL-Prüftool garantiert eine solche Anfrage keine Aufnahme in den Index; zusätzlich gilt je Property ein Tageskontingent. Wenn du dieselbe abgelehnte Seite jeden Tag neu einreichst, bleibt die Ursache unverändert.

„Gecrawlt, zurzeit nicht indexiert“ ist meist eine Entscheidung, kein Fehler

„Gecrawlt, zurzeit nicht indexiert“ ist in meiner Arbeit der häufigste und zugleich der am häufigsten missverstandene Grund. Google hat die Seite abgerufen und konnte sie lesen, nahm sie aber trotzdem nicht in den Index auf. Viele Ratgeber empfehlen daraufhin eine lange Reihe technischer Prüfungen, von der Ladezeit bis zur internen Verlinkung. Diese Prüfreihenfolge setzt voraus, dass ein technischer Fehler vorliegen müsse. Genau diese Voraussetzung stimmt häufig nicht.

In Toronto ordnete Danny Sullivan diesen Status laut der Mitschrift als selten technisch und meist als Qualitätssignal ein. Auch John Mueller und Martin Splitt erklärten im Podcast „Search Off the Record“ vom 16. Juli 2026, dass Googles Systeme bei ernsten Zweifeln an der Qualität einer Website deutlich weniger Seiten crawlen und indexieren: „we’ll probably crawl a lot less, we’ll index a lot less“. Als Beispiel nannte Mueller Websites, die überwiegend aus KI-generiertem Text bestehen und Besuchern nichts Eigenes bieten. Ausdrücklich ergänzte er, dass deswegen nicht jeder KI-Text schlecht sei. Dokumentiert wurde das Gespräch von Barry Schwartz bei Search Engine Roundtable.

Im Juni 2026 berichteten zahlreiche Betreiber von Seiten, die nach Jahren im Index plötzlich unter genau diesem Grund verschwanden. Google sah laut Search Engine Journal keine ungewöhnliche Entwicklung in den Daten. Eine einmal indexierte Seite kann demnach später wieder abgelehnt werden. Ebenso kann Google eine zunächst abgelehnte Seite nach einer erneuten Bewertung aufnehmen. Auf diese Veränderlichkeit verweist bereits das Wort „zurzeit“ im Namen des Grundes.

Für die Praxis folgt daraus eine feste Reihenfolge. Zuerst prüfe ich, ob dieselben Inhalte unter einer anderen Adresse indexiert sind oder Google eine andere kanonische URL gewählt hat. Ist ein Duplikat ausgeschlossen, liegt sehr wahrscheinlich keine technische Ursache vor. Dann vergleiche ich die Seite mit den Kriterien für hilfreiche Inhalte aus Googles eigener Dokumentation und prüfe, ob sie die Aufgabe erfüllt, die Suchende an dieser Stelle haben. Am Beispiel Autokredit lässt sich gut erkennen, weshalb selbst ein fachlich guter Text scheitern kann, wenn Seitentyp und Suchintention nicht zusammenpassen. Während dieser Prüfung reiche ich die Seite weder täglich neu ein, noch setze ich vorschnell ein noindex oder ändere ihre Adresse. Derartige Maßnahmen verwischen die Daten, die für die Diagnose gebraucht werden.

Nur die Startseite rankt

Viele kleine Websites erscheinen bei Google fast ausschließlich mit ihrer Startseite, meist für den eigenen Firmennamen. Leistungsseiten fehlen entweder im Index oder erhalten keine Impressionen. Zuerst ist deshalb zu prüfen, wie Google diese Seiten findet, ob sie indexiert werden dürfen und ob mehrere Seiten nahezu denselben Inhalt anbieten.

Auf eine verwaiste Seite verlinkt keine andere Seite derselben Website. Google findet sie höchstens über die Sitemap und misst ihr kaum Bedeutung zu. Noch häufiger begegnen mir Leistungsseiten, die nur aus einem Aufklappmenü erreichbar sind, dessen Einträge im HTML gar keine Links darstellen. Daneben kann ein noindex gesetzt sein, ohne dass sich der Betreiber daran erinnert. In meiner Stichprobe hatten Inhaltsseiten wie „Behandlung“, „Über uns“ oder „Aktionen“ bei 10 von 87 Websites ein noindex. In mehreren Fällen stammte es offenbar aus einer Vorlage des Baukastens. Schließlich kann Googles Canonical-Wahl die Leistungsseiten ausschließen. Unterscheiden sich mehrere Seiten nur in wenigen Sätzen, wählt Google unter Umständen eine davon oder sogar die Startseite als kanonische Adresse aus und lässt die übrigen weg.

In der Search Console filterst du unter „Leistung“ nach Seiten und vergleichst die Impressionen je Adresse. Anschließend gibst du jede Leistungsseite ohne Impressionen in das URL-Prüftool ein. Steht dort „indexiert“ und entspricht die von Google gewählte kanonische URL der geprüften Seite, ist die Ursache nicht technisch. In diesem Fall muss die Seite eine Suchanfrage jenseits deines Firmennamens beantworten. Ob Google und Leser ihre Aufgabe erkennen, hängt unter anderem von Title, Überschriften und internen Links ab.

Nach dem Relaunch sind Rankings verschwunden

Ein Relaunch ist der häufigste Anlass für einen echten Fehler der Gruppe zwei. Google beschreibt in seiner Anleitung für Website-Umzüge mit URL-Änderungen das Vorgehen eindeutig: Jede alte Adresse erhält eine serverseitige permanente Weiterleitung auf ihre neue Entsprechung, die Weiterleitungen bleiben „generally at least 1 year“ bestehen, und selbst dann sind vorübergehende Schwankungen zu erwarten. Für mittelgroße Websites nennt Google „a few weeks or more“, bis die neuen Adressen die alten in den Ergebnissen ersetzen.

Was passiert, wenn dieser Schritt fehlt, zeigt ein Fall aus meiner Arbeit. Ein großer B2B-Maschinenhersteller wollte mit dem Relaunch die Zahl seiner Seiten reduzieren. Dafür wurden zahlreiche Sprachverzeichnisse entfernt, ohne die alten Adressen weiterzuleiten. Die Search Console zeigt das Ergebnis über zwölf Monate: Ab Mitte März 2026 fielen Klicks und Impressionen innerhalb weniger Tage auf einen Bruchteil des vorherigen Niveaus und blieben bis Ende August dort.

Die entfernten Seiten hatten Rankings, Verlinkungen und eine Historie. Ohne Weiterleitung ist all das für Google beendet, und die neuen Seiten beginnen bei null. Die geleakte Dokumentation kennt dafür sogar ein eigenes Attribut, eine Historie je Dokument (documentHistory), getrennt vom Alter der Domain (hostAge). Wie Google beides verwendet, ist nicht offengelegt. Es passt allerdings zu dem, was ich in Relaunch-Projekten regelmäßig beobachte: Eine neue Adresse beginnt ohne Vergangenheit, auch auf einer alten Domain. Deshalb ändere ich URLs nur, wenn es einen sachlichen Grund gibt, und leite in jedem anderen Fall weiter.

Prüfen kannst du einen Relaunch auch ohne Entwicklerkenntnisse. Rufe zwanzig alte Adressen auf, die du aus einem Export der Search Console vor dem Umzug oder aus der alten Sitemap kennst. Jede davon muss ohne Umweg auf die passende neue Seite führen, nicht auf die Startseite und nicht auf eine Fehlerseite. Im Bericht „Seitenindexierung“ darf die Zahl der Adressen mit „Nicht gefunden (404)“ nach dem Umzug nicht sprunghaft steigen. Und für die alten Adressen sollte das URL-Prüftool „Seite mit Weiterleitung“ melden. Weicht eine dieser Prüfungen ab, gibst du die Liste der betroffenen Adressen an den Entwickler weiter.

Viele ähnliche Adressen behandeln denselben Inhalt

Duplikate entstehen auf kleinen Websites selten durch kopierte Texte. Sie entstehen durch Adressen. Dieselbe Startseite ist mit und ohne www erreichbar, mit http und https, mit und ohne Schrägstrich am Ende, dazu kommen Druckversionen, Parameter aus Newslettern und in WordPress die automatisch erzeugten Tag- und Kategorieseiten. In meiner Stichprobe lieferten 20 von 87 Websites ihre Startseite unter mehreren Host-Varianten aus, ohne auf eine Hauptadresse weiterzuleiten. Bei zwölf davon fehlte zusätzlich das Canonical, also der Hinweis, welche Adresse gelten soll.

Google löst solche Fälle selbst, indem es eine Adresse als kanonisch auswählt und die übrigen als Duplikate führt. Diese Wahl kann von deiner abweichen. Google nennt in seiner Anleitung zur Fehlerbehebung bei der Kanonisierung als Gründe die Qualität des Inhalts oder technische Signale und weist darauf hin, dass Seiten nach einer Korrektur bis zu zwei Wochen im Duplikat-Cluster bleiben können. Solange sich Canonical, Weiterleitung und interne Links widersprechen, entscheidet Google jedes Mal neu.

Wie teuer ein solcher Widerspruch werden kann, zeigt der zweite Fall aus meiner Arbeit, ein regionaler Finanzdienstleister. Das Canonical der Seiten verwies auf die eine Host-Variante, die Weiterleitung führte auf die andere, und die Property in der Search Console deckte nur eine der beiden Varianten ab. Anfang Februar 2026 fiel die Kurve in dieser Property auf null.

Ohne Zugang zur vollständigen Ansicht ließ sich nicht abschließend klären, ob die Sichtbarkeit tatsächlich verloren ging oder nur in einer nicht eingerichteten Property landete. Für die zweite Erklärung spricht deutlich mehr. Dem Unternehmen fehlten trotzdem über Monate verwertbare Daten. Eine fehlerhafte Einrichtung kann folglich ein Indexierungsproblem verdecken und zugleich falsche Zahlen liefern, auf deren Grundlage anschließend falsche Entscheidungen getroffen werden.

Die Abhilfe ist immer dieselbe: eine Adresse pro Inhalt. Alle Varianten leiten per 301 auf diese Adresse weiter, jede Seite hat ein Canonical auf sich selbst, und die internen Links zeigen direkt auf das Ziel. Hilfsseiten wie Tag-Archive oder Druckversionen erhalten ein noindex. Was du dabei nicht tun solltest: Seiten per robots.txt sperren, die aus dem Index verschwinden sollen. Google erklärt in seiner Einführung zur robots.txt, dass die Datei kein Mittel ist, um Seiten aus der Suche fernzuhalten, denn eine gesperrte Seite kann Google nicht abrufen und sieht folglich auch das noindex nicht.

Sitemap und robots.txt sind Hilfsmittel, keine Schalter

Um die Sitemap ranken sich zwei Missverständnisse. Ohne Sitemap werde angeblich nichts indexiert, während Google mit einer Sitemap alle eingereichten Adressen aufnehmen müsse. Tatsächlich ist die Sitemap eine Vorschlagsliste, die Google beim Finden von Seiten hilft, vor allem bei großen, neuen oder schlecht verlinkten Websites. Eine fehlende Sitemap verhindert die Indexierung daher nicht. Ebenso wenig garantiert eine vorhandene Sitemap, dass Google jede genannte Adresse in den Index aufnimmt.

Ein Beispiel von meiner eigenen Website: Meine Seite zu SEO in Schleswig-Holstein fehlte nach der Veröffentlichung am 1. September 2026 zunächst in der Sitemap, weil ein Zwischenspeicher des SEO-Plugins die Datei nicht neu erzeugt hatte. Google fand die Seite trotzdem über die internen Links, indexierte sie und zeigte sie am Tag darauf in den Top 10 für ihre Suchanfrage. Den Sitemap-Eintrag habe ich anschließend nachgezogen, weil er Google spätere Änderungen schneller erkennen lässt. Für die Aufnahme selbst spielte er keine Rolle.

Ähnliches gilt für das Crawl-Budget, das in vielen Ratgebern als Erklärung für fehlende Indexierung dient. Google richtet seine Anleitung zum Crawl-Budget ausdrücklich an Websites mit über einer Million Seiten oder über zehntausend täglich wechselnden Seiten und schreibt dazu: „If your site doesn’t have a large number of pages that change rapidly, or if your pages seem to be crawled the same day that they are published, you don’t need to read this guide.“ Die Websites in meiner Stichprobe hatten im Median 19 Adressen in ihrer Sitemap. Bei dieser Größenordnung ruft Google jede Seite ohnehin ab, sodass das Crawl-Budget als Erklärung für fehlende Indexierung ausfällt.

Die robots.txt schließlich steuert nur, was Google abrufen darf, nicht, was im Index landet. Für eine kleine Unternehmenswebsite genügt in der Regel eine Datei, die nichts Wichtiges sperrt und die Adresse der Sitemap nennt. In meiner Stichprobe fehlte die Datei bei 9 von 87 Websites ganz, und 3 Websites sperrten Verzeichnisse mit CSS- oder JavaScript-Dateien. Letzteres kann dazu führen, dass Google die Seite nicht so sieht wie ein Besucher, weil Layout und Skripte für den Crawler nicht geladen werden.

Wer behebt was: du selbst, ein Entwickler oder eine SEO-Analyse

Bei einer Blockade kannst du die Ursache häufig selbst beheben. Ein noindex lässt sich in den Seiteneinstellungen des CMS entfernen, eine Sitemap in der Search Console einreichen und eine falsche robots.txt vom Webdienstleister korrigieren. Ebenso wichtig ist die Einrichtung der Search Console selbst. Eine Domain-Property umfasst alle Host-Varianten und Protokolle, während eine URL-Präfix-Property lediglich eine Variante abdeckt. Im zweiten Praxisfall hätte eine Domain-Property die entstandene Datenlücke verhindert.

Serverfehler, Weiterleitungsketten und widersprüchliche Host-Varianten gehören dagegen zum Entwickler. Das gilt auch für Seiten, deren Inhalt erst durch JavaScript entsteht und von Google nicht zuverlässig verarbeitet wird. In diesen Fällen brauchst du jemanden, der den Server und das CMS versteht. Diese Person setzt zudem die Weiterleitungstabelle eines Relaunchs um und prüft anschließend, ob jede alte Adresse ihr richtiges Ziel erreicht.

Bei der Auswahlgruppe wird eine SEO-Analyse benötigt. Dann geht es um Duplikate, die Zuständigkeit einzelner Seiten, den passenden Seitentyp, die Suchintention und die Bedeutung einer Seite innerhalb der gesamten Website. Für Unternehmen in Schleswig-Holstein beginnt meine SEO-Diagnose vor der Anbietersuche deshalb mit der technischen Prüfung der Indexierung. Erst danach werden die Inhalte und die externen Quellen geprüft, anhand derer Google und KI-Systeme ein Unternehmen fachlich einordnen können.

Sieben Kontrollen für deine Indexierung

  1. Sind die zehn wichtigsten Seiten deiner Website im Bericht „Seitenindexierung“ als indexiert aufgeführt?
  2. Hast du jeden Grund für nicht indexierte Seiten einer der drei Gruppen Blockade, Fehler oder Auswahl zugeordnet?
  3. Führen http, https, www und ohne www auf eine einzige Startseite, und hat diese ein Canonical auf sich selbst?
  4. Steht auf keiner Leistungs-, Team- oder Kontaktseite ein noindex?
  5. Verlinkt die Startseite auf aktuelle Adressen, ohne Weiterleitung und ohne Fehlerseite?
  6. Ist die Sitemap vorhanden, aktuell und in der Search Console eingereicht?
  7. Deckt deine Search-Console-Property als Domain-Property alle Varianten ab, und liegt für einen Relaunch eine Liste alter Adressen mit ihren Weiterleitungszielen vor?

Die Prüfung der Indexierung steht bei mir am Anfang jeder Analyse. Meldet der Bericht eine Blockade oder einen Fehler, ist die Ursache technisch und oftmals schnell behoben. Unter den Auswahlgründen werden dagegen Seiten gesammelt, die Google bereits abrufen konnte. Dort müssen die Inhalte und die fachlichen Signale außerhalb deiner Website geprüft werden, anhand derer Google und KI-Systeme dein Unternehmen einem Thema zuordnen. Erst diese Unterscheidung zeigt, welche Arbeit als Nächstes sinnvoll ist.

Über diesen Artikel

Die inhaltliche Verantwortung für jeden Artikel auf diesem Blog liegt bei mir, Patrick Stolp. Thema, These, Recherche und fachliche Prüfung sind meine Arbeit – hier wird nichts veröffentlicht, das ich nicht selbst konzipiert, geschrieben und als korrekt verifiziert habe. Generative KI (Claude von Anthropic) kommt punktuell als Werkzeug zum Einsatz – etwa für Formulierungsentwürfe oder das Gegenlesen technischer Erklärungen. Kein KI-Output landet ungeprüft oder unverändert auf dieser Seite. Beitragsbilder werden mit Google Nano Banana 2 erstellt.

Ähnliche Beiträge