Warum dich viele „Nicht indexiert“-URLs in der Search Console nicht erschrecken sollten
Wenn du in der Google Search Console (GSC) unter „Indexierung > Seiten“ schaust, siehst du nicht „deine besten Seiten“, sondern alle URLs, die Google für deine Property kennt – inklusive Varianten, Duplikaten, Weiterleitungen und entfernten URLs. Google schreibt selbst sehr klar: Die meisten Websites haben mindestens einige nicht indexierte Seiten – entscheidend ist, dass alle wichtigen Seiten indexiert sind. Gleichzeitig gilt: Doppelte URLs sollten nicht indexiert werden.
Genau deshalb ist „nicht indexiert“ in vielen Fällen kein Fehler, sondern ein Hinweis, dass Google bereits eine kanonische (repräsentative) Version gefunden hat. Google formuliert das als Zielbild: Von jeder wichtigen Seite soll jeweils die kanonische Version indexiert sein; doppelte oder alternative Seiten sollten nicht indexiert sein.
Warum 100 % Indexierung weder möglich noch sinnvoll ist
Google sagt es im Seitenindexierungsbericht ausdrücklich: „100-prozentige Abdeckung“ solltest du nicht erwarten – indexiert werden sollen die kanonischen Seiten, nicht jede erreichbare URL-Variante.
Das ist nicht nur eine „Google-Laune“, sondern technisch logisch: Eine kanonische URL ist per Definition die URL, die Google als repräsentativste für einen Inhalt auswählt, wenn es mehrere sehr ähnliche oder doppelte Seiten gibt. Und Google ergänzt: Wenn Seiten sich nur durch Sortierung oder Filterung unterscheiden (z. B. Preis/Farbe), kann Google sie gruppieren und indexiert jeweils nur die kanonische URL dieser Duplikat-Gruppe.
„100 % indexiert“ wäre also oft gleichbedeutend mit: Du hast Google (und dir selbst) sehr viele Varianten in den Index gedrückt, die denselben Kerninhalt zeigen. Das führt selten zu mehr Sichtbarkeit – eher zu mehr Komplexität: Google muss mehr konsolidieren, und du bekommst unübersichtlichere Reports (und häufigere „Warum nicht indexiert“-Meldungen). Google beschreibt im Kontext Crawling sogar grundsätzlich: Das Web ist so groß, dass Google nicht jede verfügbare URL ermitteln und indexieren kann; nach dem Crawling wird jede Seite außerdem erst evaluiert und konsolidiert, bevor entschieden wird, ob sie in den Index passt.
Wichtig für die Einordnung von „schädlich“: Duplicate Content ist laut Google nicht automatisch „eine Strafe“, aber er erzeugt operative Probleme (Konsolidierung, Priorisierung). In einem Google-Help-Thread wird es sehr direkt formuliert: Wenn zwei Seiten substantiell überlappen/duplizieren, ist die Erwartung, dass beide indexiert und in Suchergebnissen ausgeliefert werden, oft unrealistisch – stattdessen sollst du mit Canonical-Signalen arbeiten.
Welche WordPress- und WooCommerce-Seiten oft bewusst nicht in den Index gehören
Bei WordPress- und WooCommerce-Websites entsteht „Index-Ballast“ weniger durch „zu wenig SEO“, sondern durch automatisch generierte Seitentypen und URL-Varianten, die für Suchende kaum Mehrwert liefern.
Typische Kandidaten, die häufig nicht indexiert sein sollten (oder nur dann, wenn du sie wirklich editorial pflegst):
Tag-Seiten und manche Archive:
Tag-Archive sind oft „Listen ohne eigenen Inhalt“. Genau diese Art von „nahezu identischen“ Seiten (Listen, die nur anders gefiltert/sortiert sind) nennt Google als klassisches Kanonikalitäts-/Duplikat-Szenario.
Ein wichtiger Zusatz: Kategorie-Seiten können sehr wohl indexwürdig sein – wenn sie eine klare thematische Klammer, stabile interne Verlinkung und eigenständigen Content (Introtext, FAQ, curated Produkte/Beiträge) bieten. Bei reinen Tag-Listen ist das seltener der Fall.
Interne Suchergebnisse:
WordPress selbst behandelt Suchergebnis-Seiten standardmäßig als „nicht indexwürdig“: Es gibt eine Core-Funktion, die bei einer Suche noindex in den Robots-Meta-Tag setzt („Adds noindex … if a search is being performed“).
Das passt zur Praxis: Suchergebnisse sind häufig dünn, variabel und können unendlich viele Parameterkombinationen erzeugen.
Shop-Utility-Seiten im WooCommerce-Kontext:
Warenkorb („Cart“), Checkout und „Mein Konto“ sind für Nutzer essenziell, aber als Suchergebnis meist sinnlos (oder sogar problematisch). WooCommerce beschreibt Cart/Checkout als zentralen Teil des Kaufprozesses – also als Transaktionsstrecke, nicht als Content-Landingpage.
Aus SEO-Sicht ist die häufige Konsequenz: Diese URLs sollten typischerweise nicht indexiert werden (z. B. via noindex), damit Google sich auf Produkt-, Kategorie- und Ratgeberseiten konzentriert. Wie du das technisch sauber steuerst, erklärst du am besten mit Googles offiziellem „noindex“-Mechanismus.
Filter- und Sortiervarianten (Facetten):
Genau hier entstehen in Shops schnell tausende „neue“ URLs, obwohl der Kerninhalt identisch bleibt. Google nennt diese Muster (Parameter für Filter/Sortierung) explizit als häufigen Grund für sehr viele nicht indexierte Seiten – und sagt sinngemäß: Oft ist es die bessere Lösung, diese Seiten nicht zu indexieren, wenn sie denselben Inhalt nur anders sortiert/erreichbar machen.
Die häufigsten Gründe „Warum Seiten nicht indexiert werden“ und was du daraus ableiten kannst
Im Report siehst du Begründungen, die von „alles okay“ bis „hier ist ein echtes Problem“ reichen. Die folgenden sieben Ursachen sind in WordPress/WooCommerce besonders häufig:
Weiter mit Weiterleitung (in der GSC-Doku: „Seite mit Weiterleitung“):
Das ist eine nicht-kanonische URL, die auf eine andere Seite weiterleitet und deshalb selbst nicht indexiert wird. Ob die Ziel-URL indexiert wird, hängt von Googles Bewertung ab.
WordPress-spezifisch: WordPress nutzt eine Canonical-Redirect-Logik, um Nutzer (und Crawler) auf die „richtige“ URL-Form zu schieben; redirect_canonical() versucht dabei, die korrekte Ziel-URL zu finden.
Was du daraus ableitest: Häufig ist das kein Fehler, sondern Hygiene. Wichtig ist, dass interne Links, Sitemap-Einträge und Canonical-Signale auf die finale Ziel-URL zeigen. Für Redirect-Strategien sind serverseitige Weiterleitungen am zuverlässigsten.
Durch noindex ausgeschlossen:
Hier blockiert eine noindex-Anweisung die Indexierung. Die GSC empfiehlt sogar explizit, im Quelltext oder in Response-Headern nach „noindex“ zu suchen und per Live-Test zu prüfen, ob es noch vorhanden ist.
WordPress-spezifisch: Wenn die Website in WordPress „nicht öffentlich“ gesetzt ist, wird (Core-seitig) noindex ausgegeben; das passiert über wp_robots_noindex().
WooCommerce-spezifisch: Permalink-Konflikte entstehen z. B., wenn Produktbase und Kategoriebase identisch konfiguriert werden; WooCommerce warnt, dass Bases eindeutig sein müssen, sonst gibt es Konflikte.
Was du daraus ableitest: noindex ist häufig absichtlich (z. B. interne Suche, Utility-Seiten) – oder ein klassischer Launch-Fehler („Development Mode“ vergessen). Google beschreibt, wie noindex umgesetzt wird (Meta-Tag oder X-Robots-Tag Header).
Gefunden – zurzeit nicht indexiert:
Google hat die URL gefunden, aber noch nicht gecrawlt. Wenn diese Begründung angezeigt wird, hat Google normalerweise versucht zu crawlen, aber das hätte die Website überlastet; deshalb wird das Crawling neu geplant (und das letzte Crawling-Datum bleibt leer).
WordPress / WooCommerce-Muster: Das passiert häufig, wenn sehr viele URLs durch Tags, Filter, Sortierung oder Parameter entstehen. Für große oder sehr dynamische Websites ist das sogar ein expliziter Anwendungsfall der Crawl-Budget-Guides.
Was du daraus ableitest: Meist ist das kein „einzelner Bug“, sondern ein Signal für zu viel URL-Inventar. Reduziere Varianten, konsolidiere Duplikate, halte Sitemaps sauber und sorge für klare interne Verlinkung auf die gewünschten kanonischen Seiten.
Gecrawlt – zurzeit nicht indexiert
Google hat die Seite gecrawlt, aber nicht indexiert. Sie könnte später indexiert werden; du musst die URL nicht erneut einreichen.
WordPress/WooCommerce-Muster: Sehr häufig bei „thin“ Archives (Tag-Seiten ohne Intro), Paginierung, Filterkombis oder Produktseiten, die nahezu identisch sind (Varianten, Boilerplate-Texte). In solchen Fällen greift oft Kanonisierung/Konsolidierung.
Was du daraus ableitest: Prüfe im URL-Prüftool die kanonische Auswahl und den gerenderten Inhalt. „Gecrawlt, nicht indexiert“ ist oft ein Signal: Google hat’s gesehen, findet es aber aktuell nicht index-würdig (z. B. zu ähnlich, zu wenig eigenständig).
Durch robots.txt blockiert
Die Seite wurde durch deine robots.txt blockiert. Google weist darauf hin, dass eine Seite trotzdem mit geringer Wahrscheinlichkeit indexiert werden kann, wenn Google ohne Laden der Seite genug Signale erhält. Und wenn du sicher verhindern willst, dass eine Seite indexiert wird, sollst du statt robots.txt noindex verwenden.
Gleichzeitig gilt (wichtige Differenzierung): robots.txt ist primär ein Werkzeug, um Crawler-Traffic zu steuern.
Was du daraus ableitest (praxisnah, ohne Dogma):
Wenn dein Ziel lautet „Diese URL soll nicht als Suchergebnis erscheinen“, ist noindex die sauberere Steuerung, weil Google die Seite dann crawlen und die Anweisung sicher sehen kann.
Wenn dein Ziel lautet „Google soll diese endlosen Facetten/Parameter gar nicht erst crawlen“ (v. a. bei sehr vielen URLs), kann robots.txt sinnvoll sein. Googles Crawl-Budget-Doku empfiehlt für bestimmte Arten unwichtiger Duplikat-URLs (z. B. unterschiedlich sortierte Versionen) sogar explizit robots.txt, um Crawling-Zeit nicht für noindex-Seiten zu verschwenden.
Alternative Seite mit richtigem kanonischen Tag
Das ist meistens ein gutes Zeichen: Die URL ist als Alternative gekennzeichnet (z. B. AMP/Mobile/Desktop-Konstellationen) und verweist korrekt auf die indexierte kanonische Seite; Google sagt: Du musst nichts weiter unternehmen.
WordPress-spezifisch: WordPress kann Canonicals ausgeben (rel_canonical() für Singular-Queries).
Was du daraus ableitest: Nicht „alles indexieren wollen“, sondern prüfen, ob die richtige URL kanonisch ist (im URL-Prüftool). Außerdem: intern konsequent auf die kanonische URL verlinken – das empfiehlt Google als Best Practice.
Nicht gefunden (404)
Google erhält beim Abruf einen 404. Laut GSC kann Google die URL über Links gefunden haben oder sie existierte früher; Googlebot versucht wahrscheinlich eine Zeit lang weiter. Außerdem: Es gibt keine Möglichkeit, Googlebot anzuweisen, eine URL „dauerhaft zu ignorieren“.
Google empfiehlt: Wenn Inhalte verschoben wurden, setze eine Weiterleitung; wenn Inhalte dauerhaft gelöscht wurden und keinen Ersatz haben, gib korrekt 404 oder 410 zurück (Google behandelt 410 derzeit wie 404) und halte deine Sitemap aktuell.
WordPress/WooCommerce-Muster: 404er entstehen häufig nach Permalink-Änderungen oder wenn Produkte/Beiträge gelöscht wurden. WordPress kann alte Slugs automatisch auflösen (wp_old_slug_redirect()), aber eben nur in bestimmten Fällen.
Ein Workflow, der in Kundenprojekten wirklich funktioniert
Wenn du als Website-Inhaber „zu viele nicht indexierte Seiten“ siehst, hilft ein reproduzierbares Vorgehen statt Aktionismus:
Nimm dir eine Beispiel-URL aus einem Status und prüfe sie im URL-Prüftool. Dort siehst du getrennt die indexierte Version und per Live-Test die aktuelle Version; außerdem die von Google gewählte kanonische URL.
Bewerte dann zuerst die Frage „Soll diese URL überhaupt indexiert sein?“ – Google selbst sagt: Du solltest nicht erwarten, dass jede URL indexiert ist, denn viele URLs sind Duplikate oder enthalten keine relevanten Informationen.
Und zuletzt der Realismus-Check: Selbst wenn eine URL „auf Google“ ist, heißt das nicht, dass sie garantiert in Suchergebnissen erscheint; das URL-Prüftool sagt ausdrücklich, die Eigenschaft „URL is on Google“ bedeutet „eligible“, aber nicht garantiert sichtbar.
Zusammenfassung
Die Search Console zeigt dir nicht „Fehler“, sondern in vielen Fällen „URL-Realität“. Google erwartet keine 100 % Indexierung und empfiehlt stattdessen: Indexiere die kanonischen, wichtigen Seiten – und lass Duplikate/Alternativen bewusst draußen.
Gerade bei WordPress und WooCommerce entstehen viele URLs, die nicht in den Index gehören (Tag-Archive ohne eigenen Inhalt, interne Suche, Filter-/Sortiervarianten, Cart/Checkout).
Die sieben häufigsten GSC-Gründe lassen sich sauber einordnen: Weiterleitungen und „Alternative Seite mit richtigem Canonical“ sind oft normal, „noindex“ und robots.txt sind Steuermechanismen, und 404 ist häufig Aufräumarbeit nach Änderungen.
Quellen & weiterführende Links:
Bericht zur Seitenindexierung – Search Console-Hilfe
https://support.google.com/webmasters/answer/7440203?hl=de
Kanonisch – Search Console-Hilfe
https://support.google.com/webmasters/answer/10347851?hl=de
Verwaltung des Crawling-Budgets | Google-Crawling-Infrastruktur | Crawling infrastructure | Google for Developers
https://developers.google.com/crawling/docs/crawl-budget?hl=de
Duplicate Content: Does it still get penalized? – Google Help
https://support.google.com/webmasters/thread/32179266/duplicate-content-does-it-still-get-penalized
wp_robots_noindex_search() – Function | Developer.WordPress.org
https://developer.wordpress.org/reference/functions/wp_robots_noindex_search/
Customizing the Cart and Checkout Pages – WooCommerce
https://woocommerce.com/document/woocommerce-store-editing/customizing-cart-and-checkout/
Aufnahme in den Google-Suchindex mit „noindex“ blockieren | Google …
https://developers.google.com/search/docs/crawling-indexing/block-indexing
redirect_canonical () – Function | Developer.WordPress.org
https://developer.wordpress.org/reference/functions/redirect_canonical/
Permalinks Documentation – WooCommerce
https://woocommerce.com/document/permalinks/
Weiterleitungen und die Google Suche | Google Search Central …
https://developers.google.com/search/docs/crawling-indexing/301-redirects
wp_robots_noindex () – Function | Developer.WordPress.org
https://developer.wordpress.org/reference/functions/wp_robots_noindex/
URL-Prüftool – Search Console-Hilfe – Google Help
https://support.google.com/webmasters/answer/9012289
Einführung und Leitfaden zu robots.txt-Dateien | Google Search Central …
https://developers.google.com/search/docs/crawling-indexing/robots/intro
rel_canonical () – Function | Developer.WordPress.org
https://developer.wordpress.org/reference/functions/rel_canonical/
Kanonische URL mit rel=“canonical“ und anderen Methoden angeben
https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls
404-Fehler (Seite nicht gefunden) – Search Console-Hilfe
https://support.google.com/webmasters/answer/2445990
wp_old_slug_redirect () – Function | Developer.WordPress.org
https://developer.wordpress.org/reference/functions/wp_old_slug_redirect/
URL Inspection tool – Search Console Help
https://support.google.com/webmasters/answer/9012289
