noindex gehört zu den wichtigsten technischen Anweisungen einer Website an Suchmaschinen.
Die Bedeutung lässt sich zunächst erstaunlich einfach zusammenfassen:
Diese Seite soll nicht in den Suchergebnissen erscheinen.
Technisch kann die Anweisung beispielsweise so im HTML einer Seite stehen:
<meta name="robots" content="noindex">
Wenn Googlebot die Seite crawlen kann und diese Anweisung erkennt, soll die Ressource nicht in den Google-Suchergebnissen erscheinen beziehungsweise aus dem Index entfernt werden. Google unterstützt noindex sowohl über ein Robots-Meta-Tag bei HTML-Seiten als auch über den HTTP-Header X-Robots-Tag. (Google for Developers)
Damit unterscheidet sich noindex grundlegend von der im vorherigen Artikel behandelten robots.txt.
robots.txt entscheidet, ob ein Crawler eine URL abrufen darf.
noindex entscheidet, ob die abrufbare URL im Suchindex erscheinen soll.
Diese Trennung ist die Grundlage für fast alles, was danach kommt.
Eine Seite muss crawlbar sein, damit Google noindex sehen kann
Dieser Punkt klingt zunächst widersprüchlich.
Wenn ich eine Seite nicht bei Google haben möchte, warum sollte ich Google erlauben, sie aufzurufen?
Weil noindex selbst auf oder bei dieser Seite ausgeliefert wird.
Google muss die URL also abrufen, um die Anweisung überhaupt erkennen zu können. Wird dieselbe URL zusätzlich über robots.txt blockiert, kann Googlebot das noindex möglicherweise nicht sehen. Google warnt ausdrücklich vor dieser Kombination. (Google for Developers)
Vereinfacht:
URL
↓
Googlebot darf crawlen
↓
Seite antwortet
↓
Google sieht noindex
↓
URL soll nicht im Suchindex erscheinen
Dagegen:
URL
↓
robots.txt verbietet Crawling
↓
Google sieht Seiteninhalt nicht
↓
Google sieht auch noindex nicht
Genau deshalb ist Disallow nicht einfach eine stärkere Version von noindex.
Die beiden Regeln greifen auf verschiedenen Ebenen.
robots.txt und noindex lösen unterschiedliche Probleme
Angenommen, eine Website besitzt eine interne Suchseite:
/suche/?q=wordpress
Die Seite darf für Besucher funktionieren.
Suchmaschinen sollen sie aber nicht als eigenes Suchergebnis anbieten.
Dann lautet das Problem:
Indexierung unerwünscht.
Dafür ist noindex grundsätzlich passend.
Ein anderes Beispiel:
Eine sehr große Website besitzt Millionen technisch erzeugter Filter-URLs, die ein Crawler gar nicht erst ständig abrufen soll.
Hier lautet das Problem:
Crawling reduzieren.
Dann kann robots.txt in bestimmten Fällen ein geeignetes Werkzeug sein.
Die Auswahl beginnt also nicht mit:
Welchen SEO-Tag nehme ich?
Sondern mit:
Welches Problem möchte ich eigentlich lösen?
noindex ist kein Zugriffsschutz
Eine Seite mit:
<meta name="robots" content="noindex">
bleibt öffentlich erreichbar.
Jeder Mensch, der ihre Adresse kennt, kann sie weiterhin aufrufen.
Der Webserver liefert die Seite ganz normal aus.
noindex bittet unterstützende Suchmaschinen lediglich, sie nicht in den Suchergebnissen zu führen. Google beschreibt noindex ausdrücklich als Indexierungsregel und nicht als Zugriffsschutz. (Google for Developers)
Deshalb wäre noindex völlig ungeeignet für:
vertrauliche Kundendaten,
interne Dokumente,
private Staging-Systeme,
geschützte Downloads.
Solche Inhalte benötigen Authentifizierung oder einen anderen echten Zugangsschutz.
Eine versteckte URL ist nicht automatisch eine geschützte URL
Manchmal lautet die Strategie:
Die Seite wird nirgendwo verlinkt und bekommt noindex. Dann findet sie niemand.
Darauf sollte man sich nicht verlassen.
Eine URL kann:
weitergegeben,
in Logs sichtbar,
in Browserhistorien gespeichert,
über andere Systeme verlinkt
oder schlicht erraten
werden.
Wenn ein Inhalt wirklich nicht öffentlich sein darf, muss der Server entscheiden:
Dieser Besucher darf hinein.
Nicht eine Suchmaschine:
Diese Seite bitte nicht anzeigen.
Wie sieht ein noindex-Meta-Tag aus?
Die häufigste Variante für HTML-Seiten lautet:
<head>
<meta name="robots" content="noindex">
</head>
Google dokumentiert das Robots-Meta-Tag als seitenbezogene Möglichkeit, Indexierungs- und Darstellungsregeln an Suchmaschinen zu übermitteln. (Google for Developers)
robots bedeutet in diesem Fall, dass die Anweisung für Suchmaschinen-Crawler allgemein gedacht ist, sofern sie diese Direktive unterstützen.
Man kann Regeln auch gezielt für Google angeben.
Beispielsweise:
<meta name="googlebot" content="noindex">
Dann richtet sich die Anweisung speziell an Googlebot. Google unterstützt dafür aktuell unter anderem die Tokens googlebot und googlebot-news. (Google for Developers)
Für normale Websites ist eine allgemeine robots-Anweisung meist verständlicher.
Was passiert bei mehreren Robots-Meta-Tags?
Eine Seite kann theoretisch mehrere entsprechende Tags enthalten.
Beispielsweise:
<meta name="robots" content="nofollow">
<meta name="googlebot" content="noindex">
Für Googlebot werden die negativen Regeln zusammen berücksichtigt. Google beschreibt dieses Beispiel entsprechend als Kombination aus noindex und nofollow. Bei widersprüchlichen Robots-Regeln wendet Google grundsätzlich die restriktivere Regel an. (Google for Developers)
Das bedeutet auch:
Wenn ein SEO-Plugin index ausgeben möchte und ein anderes System gleichzeitig noindex, sollte man nicht darauf hoffen, dass die gewünschte positive Anweisung gewinnt.
Solche Konflikte gehören beseitigt.
index muss normalerweise nicht ausdrücklich angegeben werden
Wenn keine noindex-Anweisung vorhanden ist, darf eine Seite grundsätzlich indexiert werden, sofern keine anderen Hindernisse bestehen.
Google dokumentiert all als Standardzustand ohne Einschränkungen. (Google for Developers)
Deshalb ist:
<meta name="robots" content="index, follow">
für Google normalerweise nicht notwendig.
Das Fehlen von noindex bedeutet allerdings noch lange nicht:
Diese Seite wird garantiert indexiert.
Es bedeutet lediglich:
Von dieser Robots-Regel geht keine Indexierungssperre aus.
Google entscheidet weiterhin selbst, ob eine Seite tatsächlich in den Index aufgenommen wird.
indexierbar ist nicht dasselbe wie indexiert
Das ist dieselbe Unterscheidung, die uns bereits mehrfach begegnet ist.
Eine Seite kann technisch:
crawlbar,
ohne noindex,
mit korrektem Statuscode
und sauberem Canonical
sein.
Trotzdem kann Google entscheiden, sie nicht zu indexieren.
index beziehungsweise das Fehlen von noindex ist deshalb keine Anweisung:
Nimm diese Seite unbedingt auf.
noindex ist dagegen eine klare negative Regel:
Diese Ressource soll nicht als Suchergebnis erscheinen. (Google for Developers)
Was bedeutet nofollow?
nofollow kann ebenfalls als seitenweite Robots-Regel eingesetzt werden:
<meta name="robots" content="nofollow">
Google beschreibt nofollow in diesem Zusammenhang als Anweisung, die Links auf dieser Seite nicht zu verfolgen. Ohne diese Direktive kann Google Links auf der Seite zur Entdeckung weiterer URLs verwenden. (Google for Developers)
Das ist etwas anderes als:
<a href="..." rel="nofollow">
Bei letzterem wird ein einzelner Link entsprechend gekennzeichnet.
Beim Robots-Meta-Tag betrifft nofollow die Seite als Ganzes.
noindex bedeutet nicht automatisch nofollow
Eine Seite kann einfach enthalten:
<meta name="robots" content="noindex">
Dann wurde zunächst nur die Indexierung geregelt.
Die Links auf der Seite werden dadurch nicht automatisch mit einer nofollow-Anweisung versehen.
Google dokumentiert noindex und nofollow als getrennte Direktiven. (Google for Developers)
Wenn beide gewünscht wären, könnte man schreiben:
<meta name="robots" content="noindex, nofollow">
Die Frage ist allerdings, ob nofollow im konkreten Fall überhaupt sinnvoll ist.
Was bedeutet noindex, follow?
Eine häufige Konfiguration lautet:
<meta name="robots" content="noindex, follow">
Die Absicht dahinter:
Die Seite selbst soll nicht indexiert werden.
Die enthaltenen Links dürfen aber weiterhin verarbeitet werden.
Da follow ohnehin dem normalen Zustand entspricht, ist die ausdrückliche Angabe aus Googles Sicht nicht zwingend nötig. Entscheidend ist das noindex; ohne nofollow dürfen Links grundsätzlich genutzt werden. (Google for Developers)
Praktisch genügt deshalb oft:
<meta name="robots" content="noindex">
Was bedeutet none?
Ein besonders missverständlicher Wert lautet:
<meta name="robots" content="none">
none bedeutet bei Google nicht:
keine Einschränkungen.
Es entspricht:
noindex, nofollow
Google dokumentiert diese Gleichsetzung ausdrücklich. (Google for Developers)
Wer none intuitiv als „nichts Besonderes machen“ interpretiert, würde also genau das Gegenteil erreichen.
Deshalb würde ich in normalen Redaktions- und WordPress-Workflows lieber die konkreten Direktiven verwenden.
Sie sind sofort verständlich.
Was ist der X-Robots-Tag?
Nicht jede indexierbare Ressource ist eine HTML-Seite.
Eine PDF-Datei besitzt beispielsweise keinen HTML-<head>, in den man ein Meta-Tag schreiben könnte.
Dafür gibt es den HTTP-Header:
X-Robots-Tag: noindex
Google unterstützt den X-Robots-Tag als alternative Möglichkeit für dieselben Robots-Regeln. Er eignet sich besonders für Nicht-HTML-Inhalte wie PDFs, Bilder oder Videodateien. (Google for Developers)
Der Server liefert dann beispielsweise:
HTTP/1.1 200 OK
Content-Type: application/pdf
X-Robots-Tag: noindex
Der Browser kann die PDF weiterhin anzeigen.
Google erhält zusätzlich die Indexierungsanweisung.
X-Robots-Tag funktioniert auch bei HTML
Der HTTP-Header ist nicht ausschließlich PDFs vorbehalten.
Er kann grundsätzlich auch für HTML-Seiten verwendet werden.
Das normale Meta-Tag ist dort allerdings häufig leichter innerhalb des CMS zu verwalten.
Der Vorteil des HTTP-Headers liegt insbesondere darin, dass Regeln auf Serverebene gesetzt werden können.
Beispielsweise für:
alle PDFs in einem Verzeichnis,
bestimmte Dateiendungen,
automatisch erzeugte Downloads.
Google zeigt in seiner Dokumentation selbst Beispiele für serverseitige X-Robots-Tag-Regeln auf Apache und NGINX. (Google for Developers)
Ein PDF kann also aus Google ausgeschlossen werden
Angenommen, eine Website besitzt eine PDF-Version eines Artikels.
Die HTML-Seite soll indexiert werden.
Die PDF soll zwar für Leser herunterladbar bleiben, aber nicht als separates Google-Ergebnis auftauchen.
Dann kann die PDF beispielsweise mit:
X-Robots-Tag: noindex
ausgeliefert werden.
Damit lässt sich die Indexierungssteuerung auf Dateitypen anwenden, für die ein HTML-Meta-Tag ungeeignet wäre. (Google for Developers)
Das ist wesentlich sauberer als zu versuchen, PDF-Dateien über robots.txt zu verstecken.
Die PDF muss wiederum crawlbar bleiben
Auch beim X-Robots-Tag gilt dieselbe Logik.
Wenn die PDF per robots.txt vollständig blockiert wird, kann Google den HTTP-Header beim Abruf nicht sehen.
Google betont ausdrücklich, dass Robots-Meta- und HTTP-Header-Regeln nur ausgewertet werden können, wenn der Crawler die entsprechende Ressource abrufen darf. (Google for Developers)
Die Regel lautet daher immer wieder:
Für noindex muss Google die Ressource sehen dürfen.
Wann verschwindet eine bereits indexierte Seite?
Wenn eine Seite bereits in Google steht und heute noindex erhält, verschwindet sie nicht notwendigerweise in derselben Sekunde.
Google muss die URL erneut crawlen und die neue Anweisung erkennen.
Google weist darauf hin, dass eine erneute Prüfung abhängig von der Bedeutung und Crawl-Frequenz einer URL dauern kann. Für einzelne URLs kann über die URL-Prüfung in Search Console ein erneutes Crawling angefragt werden. (Google for Developers)
Vereinfacht:
Seite ist indexiert
↓
noindex wird gesetzt
↓
Google kennt noch alten Zustand
↓
Google crawlt erneut
↓
Google erkennt noindex
↓
Seite wird aus Suchergebnissen entfernt
Deshalb sollte man nach einer Änderung zunächst sicherstellen, dass Google die URL auch wirklich wieder crawlen kann.
noindex ist keine Sofort-Löschung
Wenn sensible Informationen versehentlich in Google aufgetaucht sind, kann es zu langsam sein, lediglich noindex zu setzen und auf den nächsten Crawl zu warten.
Google bietet für kurzfristige Ausblendungen das Removals-Werkzeug in Search Console an. Solche temporären Entfernungen ersetzen jedoch keine dauerhafte technische Lösung; Google beschreibt sie als zeitlich begrenzte Ausblendung, während für eine dauerhafte Entfernung die Ursache entsprechend geändert werden muss. (Google for Developers)
Die dauerhafte Maßnahme kann beispielsweise sein:
Inhalt entfernen,
Zugriff schützen,
noindex setzen,
je nach Situation einen passenden HTTP-Status liefern.
noindex und das Removals-Tool sind deshalb nicht dasselbe
Das Removals-Tool beantwortet eher:
Wie kann ich dieses Ergebnis schnell vorübergehend aus Google ausblenden?
noindex beantwortet:
Wie soll diese öffentlich erreichbare Ressource langfristig hinsichtlich Indexierung behandelt werden?
Wer nur das Removals-Tool verwendet und die eigentliche Seite unverändert indexierbar lässt, hat das zugrunde liegende Problem nicht gelöst. Google gibt an, dass temporäre Entfernungsanfragen ungefähr sechs Monate wirken. (Google for Developers)
Wann ist noindex die richtige Lösung?
noindex eignet sich besonders für Seiten, die technisch oder für Nutzer benötigt werden, aber keinen eigenständigen Platz in Suchmaschinen erhalten sollen.
Typische Beispiele können sein:
interne Suchergebnisse,
bestimmte funktionale Seiten,
bestimmte dünne Archive,
Test- oder Hilfsseiten, sofern sie überhaupt öffentlich sein sollen,
personalisierte öffentlich erreichbare Ansichten ohne Suchwert.
Die Entscheidung hängt immer von der Aufgabe der Seite ab.
Eine URL ist nicht deshalb ein noindex-Kandidat, weil sie wenig Traffic hat.
Wenig Traffic ist kein Grund für noindex
Ein Spezialartikel kann nur zehn Besucher im Monat haben und trotzdem exakt zehn Menschen hervorragend helfen.
Wenn die Seite:
einen klaren Suchzweck besitzt,
eigenständigen Inhalt bietet
und bewusst Teil der Website ist,
gibt es keinen Grund, sie nur wegen geringer Reichweite aus dem Index auszuschließen.
noindex ist kein Aufräumwerkzeug für alles, was ein SEO-Tool als „schwach“ bezeichnet.
Es ist eine bewusste Aussage:
Diese Seite soll kein Suchergebnis sein.
Interne Suchergebnisse sind ein klassisches Beispiel
WordPress selbst fügt für interne Suchergebnisse eine noindex-Direktive über seine Robots-Infrastruktur hinzu. Die Core-Funktion wp_robots_noindex_search() ist genau dafür vorgesehen. (WordPress Developer Resources)
Das ist konzeptionell sinnvoll.
Wenn jemand auf Casiopeya intern nach:
wordpress
sucht, entsteht möglicherweise eine Seite wie:
/?s=wordpress
Diese Seite dient der internen Navigation.
Sie muss nicht zwangsläufig selbst als Google-Suchergebnis konkurrieren.
Kategoriearchive sind dagegen nicht automatisch noindex
Eine gut gestaltete Kategorieseite kann eine eigenständige Aufgabe besitzen.
Unser Hub:
/wissen/web-wordpress/
ist ein gutes Beispiel.
Er verbindet einen Themenbereich, erklärt Zusammenhänge und führt gezielt zu Unterseiten.
Eine solche Seite könnte sehr wohl indexiert werden sollen.
Ein automatisches Tagarchiv mit einem einzigen Beitrag und praktisch keinem eigenen Nutzen kann anders bewertet werden.
Entscheidend ist deshalb nicht:
Kategorie oder nicht?
Sondern:
Besitzt diese Seite einen eigenständigen Zweck als Suchergebnis?
Tags sind ebenfalls eine Architekturentscheidung
Bei WordPress entstehen schnell Schlagwortarchive.
Angenommen, ein Blog besitzt:
/tag/wordpress/
/tag/cms/
/tag/webseiten/
und alle zeigen fast dieselben Beiträge.
Dann kann man überlegen, ob diese Archive überhaupt eigenständige Suchseiten sein sollen.
Eine mögliche Konsequenz kann noindex sein.
Die bessere Lösung kann aber auch lauten:
weniger Tags verwenden,
Archive zusammenlegen,
echte Hub-Seiten bauen.
noindex sollte nicht automatisch die Konsequenz einer ungeplanten Informationsarchitektur sein.
Autorenarchive hängen vom Projekt ab
Auf einem großen Magazin können Autorenseiten wertvoll sein.
Sie können enthalten:
Biografie,
Fachgebiete,
Artikelübersicht,
Kontaktinformationen.
Dann besitzen sie einen echten Zweck.
Auf einem Ein-Personen-Blog kann das Autorenarchiv möglicherweise fast exakt dieselben Beiträge wie die normale Blogübersicht zeigen.
Auch hier gibt es keine allgemeine Regel:
Autorenarchive = noindex
Die Entscheidung kommt aus dem konkreten Seitenmodell.
Datumsarchive sind häufig weniger wichtig
WordPress kann Archive nach:
Jahr,
Monat,
Tag
erzeugen.
Bei einem Nachrichtenprojekt kann das sinnvoll sein.
Bei einem Evergreen-Wissensportal interessiert den Besucher möglicherweise kaum, welche Artikel im April 2024 veröffentlicht wurden.
Solche Archive können je nach Website keinen eigenen Suchwert besitzen.
Aber wieder gilt:
Zuerst entscheiden, ob sie überhaupt Teil der gewünschten Informationsarchitektur sein sollen.
Danach Indexierungssteuerung wählen.
noindex ist nicht dasselbe wie Löschen
Angenommen, eine Seite wird nicht mehr benötigt.
Dann könnte man sie theoretisch weiterhin öffentlich ausliefern und noindex setzen.
Warum?
Wenn sie für Besucher keinen Zweck mehr erfüllt, ist möglicherweise eine andere Lösung sinnvoller.
Existiert ein direkter relevanter Ersatz?
Dann kann eine Weiterleitung passen.
Ist der Inhalt ersatzlos entfernt?
Dann kann ein korrekter 404- oder 410-Status sinnvoll sein.
Muss die Seite weiterhin für bestimmte Nutzer erreichbar bleiben?
Dann kann noindex passend sein.
Die Entscheidung beginnt wieder beim Zustand des Inhalts.
noindex oder 404?
Diese beiden Signale sagen völlig verschiedene Dinge.
noindex:
Diese Seite existiert weiterhin, soll aber nicht im Suchindex erscheinen.
404:
Unter dieser URL existiert die angeforderte Ressource nicht.
Wenn eine Seite tatsächlich dauerhaft entfernt wurde und keinen Ersatz besitzt, ist es meist sauberer, diesen Zustand auch auf Serverebene abzubilden.
Eine weiterhin funktionierende 200-Seite mit noindex wäre dann möglicherweise eine unnötige Scheinexistenz.
noindex oder Weiterleitung?
Angenommen, zwei ältere Artikel wurden zu einem neuen umfangreichen Ratgeber zusammengeführt.
Die alten URLs haben keinen eigenständigen Zweck mehr.
Dann könnte man sie:
mit noindex bestehen lassen
oder
auf den passenden neuen Artikel weiterleiten.
Wenn der alte Inhalt tatsächlich durch den neuen ersetzt wurde, ist die Weiterleitung häufig die logischere Aussage:
alter Inhalt
↓
dauerhaft ersetzt durch
↓
neuen Inhalt
Genau dafür behandeln wir anschließend 301-Weiterleitungen.
noindex oder Canonical?
Diese Frage ist besonders wichtig.
Angenommen, zwei URLs enthalten fast denselben Inhalt.
Man möchte lediglich sagen:
URL A ist meine bevorzugte Version.
Dann ist noindex nicht Googles empfohlene Methode zur Canonicalisierung innerhalb derselben Website. Google empfiehlt dafür rel="canonical" und rät davon ab, noindex als Mittel zu verwenden, um die Auswahl einer kanonischen Seite zu erzwingen. (Google for Developers)
Warum?
Weil beide Aussagen unterschiedlich sind.
Canonical:
Diese Inhalte gehören zusammen; diese URL ist die bevorzugte Version.
noindex:
Diese Seite soll überhaupt nicht in den Suchergebnissen erscheinen.
Das ist ein erheblicher Unterschied.
Canonical erhält den Zusammenhang zwischen Varianten
Nehmen wir zwei Varianten:
/produkt/
/produkt/?farbe=rot
Wenn beide im Wesentlichen denselben Inhalt darstellen, kann ein Canonical dazu beitragen, die bevorzugte URL zu kommunizieren.
noindex würde dagegen die betreffende Variante vollständig für Suchergebnisse ausschließen.
Google weist deshalb ausdrücklich darauf hin, noindex nicht zur Canonical-Auswahl innerhalb einer Site einzusetzen. (Google for Developers)
Den vollständigen Unterschied behandeln wir direkt im nächsten Artikel.
noindex und Canonical gleichzeitig können widersprüchlich werden
Technisch kann eine noindex-Seite zusätzlich einen Canonical-Verweis besitzen.
Aber man sollte sich fragen, was damit eigentlich kommuniziert werden soll.
noindex sagt:
Diese Seite nicht indexieren.
Canonical sagt:
Diese Seite gehört zu einer anderen kanonischen Variante.
Wenn das eigentliche Problem Duplikation ist, ist Canonical meist das passendere Werkzeug.
Wenn die Seite unabhängig davon grundsätzlich nicht als Suchergebnis existieren soll, ist noindex die klarere Aussage.
Technische SEO wird besser, wenn nicht jede Seite mit sämtlichen verfügbaren Signalen gleichzeitig versehen wird.
noindex-Seiten gehören normalerweise nicht in die XML-Sitemap
Eine Sitemap soll bevorzugte URLs aufführen, die man Suchmaschinen als relevanten indexierbaren Bestand mitteilt.
Eine noindex-Seite sagt dagegen:
Bitte nicht indexieren.
Beides gleichzeitig ist unnötig widersprüchlich.
Deshalb sollten bewusst dauerhaft auf noindex gesetzte Seiten normalerweise nicht als gewünschte Such-URLs in der XML-Sitemap stehen.
Die Sitemap ist zwar keine Indexierungsgarantie, aber die technische Kommunikation sollte möglichst konsistent sein.
Interne Links zu noindex-Seiten können trotzdem sinnvoll sein
Eine Seite kann für Suchmaschinen uninteressant, für Besucher aber wichtig sein.
Beispielsweise:
Login,
interne Suche,
bestimmte Funktionsseiten.
Natürlich dürfen Nutzer dorthin navigieren.
noindex bedeutet nicht:
Diese Seite darf innerhalb meiner Website nicht verlinkt werden.
Es bedeutet ausschließlich, dass sie nicht als eigenständiges Suchergebnis erscheinen soll.
Informationsarchitektur und Suchindex sind zwei verschiedene Ebenen.
Aber zentrale Wissensseiten sollten nicht versehentlich noindex sein
Wenn ein Artikel:
in der Hauptnavigation steckt,
in der Sitemap steht,
zahlreiche interne Links erhält
und ein zentraler Bestandteil eines Themenclusters ist,
gleichzeitig aber:
<meta name="robots" content="noindex">
enthält, besteht offensichtlich ein Konflikt.
Die Website sagt auf mehreren Ebenen:
Diese Seite ist wichtig.
und an einer entscheidenden Stelle:
Bitte nicht indexieren.
Solche Widersprüche sind typische Ursachen technischer SEO-Probleme.
noindex kann durch ein Plugin entstehen
Bei WordPress muss die Anweisung nicht manuell im Theme stehen.
SEO-Plugins können für einzelne Inhalte oder ganze Inhaltstypen Indexierungsregeln setzen.
Beispielsweise könnte ein Plugin festlegen:
Tags → noindex.
Autorenarchive → noindex.
Bestimmte Custom Post Types → noindex.
Das kann völlig beabsichtigt sein.
Bei einem Pluginwechsel sollte aber kontrolliert werden, welche Regeln die neue Konfiguration tatsächlich ausgibt.
WordPress besitzt selbst eine Robots-Meta-Infrastruktur
WordPress verwendet seit Version 5.7 den Filter wp_robots, um Robots-Direktiven zusammenzustellen. Die entsprechende Core-Schnittstelle kann unter anderem noindex hinzufügen. (WordPress Developer Resources)
Damit können:
WordPress Core,
Theme
und Plugins
auf einer standardisierten Ebene Robots-Regeln beeinflussen.
Für den Betreiber zählt am Ende aber weiterhin nur:
Was steht tatsächlich im ausgelieferten HTML beziehungsweise HTTP-Header?
Die WordPress-Sichtbarkeitseinstellung kann die ganze Website noindex setzen
Unter Einstellungen → Lesen besitzt WordPress die Option:
Suchmaschinen davon abhalten, diese Website zu indexieren.
Wenn eine WordPress-Website als nicht öffentlich markiert ist, fügt der Core entsprechende noindex-Robots-Direktiven hinzu. Die aktuelle Core-Funktion wp_robots_noindex() prüft dafür die Option blog_public. (WordPress Developer Resources)
Das ist bei Testinstallationen praktisch.
Bei einer produktiven Website kann eine vergessene Einstellung dagegen gravierende Folgen haben.
Staging → Produktion ist deshalb ein kritischer Moment
Ein häufiger Ablauf:
Staging-Website
↓
Suchmaschinen sollen sie nicht indexieren
↓
noindex aktiviert
↓
Website wird fertig
↓
auf Produktivdomain umgezogen
↓
noindex bleibt bestehen
Die Website funktioniert für Menschen perfekt.
Google erhält aber weiterhin:
Bitte nicht indexieren.
Google nennt vergessene noindex– oder robots.txt-Sperren ausdrücklich als typischen Fehler bei Website-Migrationen. (Google for Developers)
Eine Relaunch-Checkliste sollte diese Prüfung deshalb immer enthalten.
Staging sollte trotzdem besser geschützt werden
Eine unveröffentlichte Website ausschließlich per noindex vor Google zu verstecken, verhindert keine menschlichen Zugriffe.
Wenn Entwürfe, Kundendaten oder vertrauliche Inhalte vorhanden sind, sollte die Umgebung besser zusätzlich durch Authentifizierung geschützt werden.
noindex kann ergänzend verhindern, dass ein öffentlich zugängliches Testsystem regulär im Suchindex landet.
Es ersetzt keinen Zugangsschutz.
WordPress-Suchergebnisse werden automatisch noindex behandelt
WordPress Core besitzt die Funktion wp_robots_noindex_search(), die bei internen Suchergebnisseiten noindex zu den Robots-Direktiven hinzufügt. (WordPress Developer Resources)
Das ist für unser Verständnis sehr hilfreich.
WordPress unterscheidet selbst:
Eine Suchergebnisseite kann für Benutzer funktional wichtig sein.
Sie braucht aber nicht unbedingt als eigenständiges Ergebnis einer anderen Suchmaschine aufzutauchen.
Genau das ist ein typischer noindex-Anwendungsfall.
WordPress-Embeds besitzen ebenfalls eigene noindex-Logik
Im aktuellen WordPress-Core existiert auch wp_robots_noindex_embeds() für Embed-Seiten. (WordPress Developer Resources)
Das unterstreicht einen wichtigen Punkt:
Eine moderne CMS-Installation besitzt bereits verschiedene technische Seitentypen, die nicht alle wie normale Artikel behandelt werden.
Deshalb sollte man bei der Indexierungsanalyse nicht nur Beiträge und Seiten betrachten.
Man sollte verstehen, welche URL-Typen das CMS tatsächlich erzeugt.
Wie prüfe ich, ob eine Seite noindex ist?
Die einfachste Variante besteht darin, den HTML-Quelltext zu betrachten.
Suche nach:
robots
Ein entsprechender Eintrag könnte lauten:
<meta name="robots" content="noindex, follow">
oder:
<meta name="googlebot" content="noindex">
Bei einem X-Robots-Tag reicht die HTML-Ansicht dagegen nicht.
Dann muss der HTTP-Response-Header untersucht werden.
Browser-Entwicklerwerkzeuge oder Kommandozeilentools können dabei helfen.
Nur im sichtbaren HTML suchen reicht deshalb nicht immer
Eine PDF kann noindex besitzen.
Eine normale HTML-Seite könnte ihre Regel ebenfalls als HTTP-Header erhalten.
Dann siehst du im Quelltext möglicherweise überhaupt kein Robots-Meta-Tag.
Trotzdem liefert der Server:
X-Robots-Tag: noindex
Google unterstützt beide Verfahren. (Google for Developers)
Bei technischen SEO-Audits sollte deshalb im Zweifel sowohl das HTML als auch die tatsächliche HTTP-Antwort geprüft werden.
Search Console hilft bei der Kontrolle
Die URL-Prüfung in der Google Search Console kann zeigen, was Google über eine konkrete URL weiß und ob ein noindex-Signal erkannt wurde.
Google empfiehlt die URL-Prüfung ausdrücklich auch zur Diagnose von noindex-Problemen. Der Seitenindexierungsbericht kann außerdem URLs gruppieren, bei denen Google eine noindex-Regel festgestellt hat. (Google for Developers)
Damit lässt sich unterscheiden:
Was sehe ich heute live?
Was hat Google beim letzten Crawl gesehen?
Diese beiden Zustände müssen nicht identisch sein.
„Durch noindex ausgeschlossen“ ist nicht automatisch ein Fehler
Search Console kann melden, dass eine Seite wegen noindex nicht indexiert wurde.
Das ist nur dann ein Problem, wenn diese Seite indexiert werden sollte.
Bei:
internen Suchseiten,
bestimmten Funktionsseiten,
bewusst ausgeschlossenen Archiven
kann die Meldung exakt den gewünschten Zustand beschreiben.
Technische SEO besteht deshalb nicht darin, sämtliche Search-Console-Hinweise grün zu bekommen.
Sie besteht darin, zu prüfen:
Entspricht Googles Verhalten unserer Absicht?
Bei einem wichtigen Artikel ist dieselbe Meldung dagegen kritisch
Angenommen:
/wissen/caching/
steht auf noindex.
Dann sollten wir fragen:
Woher kommt die Direktive?
WordPress-Sichtbarkeit?
SEO-Plugin?
Template?
HTTP-Header?
Staging-Konfiguration?
Serverregel?
Danach wird genau diese Ursache behoben.
Nicht gleichzeitig die Sitemap, Überschrift, interne Verlinkung und Serverleistung ändern.
Ein technisches Signal nach dem anderen.
Nach dem Entfernen von noindex braucht Google einen neuen Crawl
Wenn eine wichtige Seite bisher:
<meta name="robots" content="noindex">
enthielt und dieser Tag entfernt wird, bedeutet das zunächst nur:
Die aktuelle Live-Seite ist wieder indexierbar.
Google kennt möglicherweise noch den alten Zustand.
Die Suchmaschine muss die Seite erneut abrufen und neu bewerten. Bei einzelnen Seiten kann dafür über Search Console eine erneute Indexierung angefragt werden. (Google for Developers)
Auch danach gibt es keine Garantie für eine Indexierung.
Das Hindernis noindex wurde lediglich beseitigt.
JavaScript und noindex brauchen besondere Vorsicht
Google kann Robots-Meta-Tags grundsätzlich auch im gerenderten Seitenzustand verarbeiten. Google warnt allerdings davor, eine Seite zunächst mit noindex auszuliefern und anschließend per JavaScript zu versuchen, diese Anweisung wieder zu entfernen: Sobald Google noindex sieht, kann es auf weiteres Rendering verzichten. (Google for Developers)
Deshalb sollte eine Seite, die indexiert werden soll, nicht nach dem Prinzip funktionieren:
HTML:
noindex
JavaScript später:
doch index
Die ursprüngliche Serverantwort sollte möglichst bereits die gewünschte Indexierungsstrategie widerspiegeln.
Dynamische noindex-Regeln sollten deshalb zuverlässig sein
Eine Anwendung könnte abhängig vom Seitenzustand entscheiden:
Produkt vorhanden → indexierbar.
Produkt fehlerhaft → noindex.
Das kann technisch sinnvoll sein.
Aber die Entscheidung sollte stabil und reproduzierbar sein.
Wenn Google beim ersten Crawl zufällig noindex erhält und ein normaler Nutzer eine Sekunde später eine indexierbare Version, entsteht unnötige Unsicherheit.
Indexierungsregeln sollten keine zufälligen Zustände sein.
noindex ist auch kein Qualitätsfilter für den ganzen Webauftritt
Manchmal wird empfohlen:
Setze alle schwachen Seiten auf noindex, dann wird der Rest stärker.
So pauschal sollte man Websitequalität nicht betrachten.
Wenn eine Seite schlecht ist, gibt es mehrere mögliche Reaktionen:
verbessern,
mit einer anderen Seite zusammenführen,
entfernen,
bewusst als funktionale noindex-Seite behalten.
Das Setzen von noindex verändert nicht automatisch die Qualität der übrigen Inhalte.
Die Entscheidung sollte auf der Aufgabe der Seite beruhen.
Thin Content bedeutet nicht automatisch noindex
Eine kurze Seite kann hervorragend sein.
Eine Definition von:
Was bedeutet TTL?
braucht vielleicht keine 4.000 Wörter.
Wenn sie die Frage präzise beantwortet, kann sie einen klaren Zweck erfüllen.
Eine lange Seite kann dagegen trotz 8.000 Wörtern wenig eigenständigen Nutzen besitzen.
Die richtige Indexierungsfrage lautet deshalb nicht:
Wie viele Wörter hat die Seite?
Sondern:
Ist diese Seite als eigenständiges Suchergebnis sinnvoll?
Filterseiten sind ein gutes Beispiel für differenzierte Entscheidungen
Ein Shop könnte besitzen:
/schuhe/
/schuhe/?farbe=rot
/schuhe/?farbe=blau
/schuhe/?groesse=42
/schuhe/?farbe=rot&groesse=42
Manche Kombinationen können echte Landingpages mit Nachfrage und eigenständigem Inhalt darstellen.
Andere erzeugen tausende kaum sinnvolle Varianten.
Nun können verschiedene Werkzeuge relevant werden:
Canonical,
noindex,
robots.txt,
technische Begrenzung der URL-Erzeugung.
Die richtige Lösung hängt von der Architektur ab.
noindex für alle Parameter ist ebenso wenig automatisch richtig wie alles indexieren.
Pagination sollte ebenfalls nicht pauschal noindex sein
Mehrseitige Listen können wichtige Inhalte enthalten.
Wenn Seite zwei eines Archivs weitere relevante Artikel verlinkt, ist sie Teil der Navigation.
Eine pauschale Regel:
Seite 2 bis 100 = noindex
sollte deshalb nicht ohne konkreten Grund verwendet werden.
Auch hier gilt:
Zuerst verstehen, welche Funktion die URL im System besitzt.
Dann entscheiden, welche Indexierungsstrategie dazu passt.
Druckversionen können Kandidaten für Konsolidierung sein
Manche Websites erzeugen zusätzlich:
/artikel/
/artikel/print/
mit fast identischem Inhalt.
Hier stellt sich weniger die Frage:
Wie bekomme ich die Druckversion irgendwie aus Google?
Sondern:
Brauche ich überhaupt zwei eigenständige URLs und wenn ja, wie kommuniziere ich ihre Beziehung?
Je nach technischer Umsetzung kann Canonicalisierung geeigneter sein als noindex.
Das ist genau der Übergang zum nächsten Artikel.
Danke-Seiten können sinnvoll noindex sein
Nach erfolgreichem Formularversand könnte beispielsweise:
/vielen-dank/
angezeigt werden.
Diese Seite kann technisch wichtig sein:
Bestätigung geben,
nächsten Schritt erklären,
Conversion messen.
Als allgemeines Google-Suchergebnis besitzt sie möglicherweise wenig Nutzen.
Dann kann noindex gut passen.
Wichtig ist nur, dass die Seite nicht als vermeintlicher Sicherheitsschutz behandelt wird.
Wer die URL kennt, kann sie weiterhin aufrufen.
Login- und Accountseiten sind ein Sonderfall
Ein Loginformular muss nicht zwangsläufig in Google erscheinen.
Wenn der Bereich wirklich persönlich oder vertraulich ist, sollte der eigentliche Inhalt ohnehin hinter Authentifizierung liegen.
noindex kann für öffentlich erreichbare Einstiegsseiten ergänzend sinnvoll sein.
Aber die Sicherheit kommt vom Login-System.
Nicht vom Robots-Meta-Tag.
Warenkorb und Checkout sind ebenfalls keine klassischen Suchergebnisse
Eine Shop-Kasse dient einem konkreten Prozess.
Sie besitzt normalerweise keinen eigenständigen Informationswert für jemanden, der bei Google nach einem Thema sucht.
Solche funktionalen URLs werden daher typischerweise anders behandelt als Produkt- oder Kategorieseiten.
Auch hier zeigt sich:
Indexierungsstrategie folgt dem Zweck der Seite.
noindex kann auch temporär sinnvoll sein
Eine öffentlich erreichbare Seite könnte vorübergehend nicht für Google vorgesehen sein.
Beispielsweise während einer bestimmten redaktionellen Phase.
Technisch lässt sich noindex später wieder entfernen.
Man sollte dabei aber berücksichtigen, dass Suchmaschinen Änderungen nicht sofort sehen und eine spätere Indexierung nicht garantiert oder augenblicklich erfolgt. (Google for Developers)
Für einen Artikel, der in drei Stunden ohnehin regulär veröffentlicht werden soll, wäre ein komplexer kurzfristiger Indexierungszyklus häufig unnötig.
Bei Relaunches kann temporäres noindex gefährlich werden
Google nennt ausdrücklich vergessene noindex-Regeln auf neuen Websites als typischen Fehler bei Migrationen. (Google for Developers)
Deshalb sollte ein Relaunch klare Zustände besitzen.
Vor Livegang:
Testsystem geschützt oder noindex.
Nach Livegang:
produktive URLs kontrolliert indexierbar.
Ein unklarer Zwischenzustand ist riskanter als eine einfache, dokumentierte Umschaltung.
Eine ganze Website lässt sich mit WordPress noindex setzen
WordPress kann auf Site-Ebene die Suchmaschinensichtbarkeit deaktivieren. Die Core-Funktion wp_robots_noindex() fügt dann noindex hinzu; wp_robots_no_robots() kombiniert dies je nach öffentlicher Site-Konfiguration zusätzlich mit follow beziehungsweise nofollow. (WordPress Developer Resources)
Das sollte man insbesondere dann kennen, wenn man:
Websites kopiert,
Staging-Systeme klont,
Domains umzieht
oder Templates für neue Projekte verwendet.
Eine kopierte Datenbank kann entsprechende Einstellungen mitnehmen.
noindex sollte nicht in robots.txt geschrieben werden
Der Begriff wird manchmal mit einer alten robots.txt-Zeile verwechselt:
Noindex: /ordner/
Google unterstützt noindex in robots.txt ausdrücklich nicht. (Google for Developers)
Für Google existieren dafür die beiden vorgesehenen Wege:
<meta name="robots" content="noindex">
oder:
X-Robots-Tag: noindex
Alles andere sollte nicht als zuverlässige Indexierungssteuerung behandelt werden.
Meta-Description und noindex haben nichts miteinander zu tun
Eine Seite kann eine perfekte:
<meta name="description">
besitzen und gleichzeitig:
<meta name="robots" content="noindex">
Dann soll sie nicht in den Suchergebnissen erscheinen.
Die Meta Description ist keine Indexierungsanweisung.
Umgekehrt benötigt eine indexierbare Seite keine besondere Robots-Zeile, nur weil eine Meta Description vorhanden ist.
Meta-Tags erfüllen unterschiedliche Aufgaben.
Der gemeinsame Speicherort im HTML-Head macht sie nicht funktional gleich.
noindex und SEO-Titel sind ebenfalls getrennt
Ein perfekt optimierter Title bringt wenig, wenn die Seite bewusst noindex besitzt.
Das klingt trivial.
In komplexen WordPress-Systemen kann genau das aber passieren.
Ein SEO-Plugin zeigt:
SEO-Score 95/100.
Keyword im Titel.
Meta Description perfekt.
Gleichzeitig ist für den Inhaltstyp:
Nicht indexieren
aktiviert.
Deshalb sollte technische Indexierbarkeit vor Detailoptimierung geprüft werden.
Die Reihenfolge der SEO-Diagnose ist entscheidend
Wenn eine Seite keinen Google-Traffic besitzt, sollte man zunächst fragen:
Ist URL erreichbar?
↓
darf Google sie crawlen?
↓
enthält sie noindex?
↓
welche Canonical-URL gilt?
↓
wurde sie indexiert?
↓
für welche Queries erscheint sie?
Erst danach lohnt sich die Frage:
Sollte der Title umformuliert werden?
Wer die Reihenfolge umdreht, optimiert möglicherweise eine Seite, die Google ausdrücklich nicht indexieren darf.
Ein noindex-Audit kann bei großen WordPress-Seiten sehr aufschlussreich sein
Bei einer großen Website würde ich alle URL-Typen systematisch betrachten.
Beispielsweise:
Beiträge.
Seiten.
Kategorien.
Tags.
Autorenarchive.
Suchergebnisse.
Custom Post Types.
Spezielle Pluginseiten.
Dann lässt sich für jeden Typ festlegen:
index
oder
noindex
und vor allem:
warum?
Das ist wesentlich besser, als jahrelang einzelne Checkboxen in verschiedenen Plugins wachsen zu lassen.
Indexierungsregeln sollten dokumentiert werden
Ein sinnvolles Architektur-Dokument könnte beispielsweise enthalten:
Wissensartikel
→ index
Hub-Seiten
→ index
Magazinartikel
→ index
interne Suche
→ noindex
Dankeseiten
→ noindex
Tagarchive
→ derzeit nicht genutzt / noindex
Staging
→ Zugangsschutz + noindex
Dann weiß auch nach einem Pluginwechsel noch jemand, welcher Zustand gewollt ist.
Die Software ist austauschbar.
Die Indexierungsstrategie sollte es nicht sein.
noindex-Seiten sollten bei einem SEO-Plugin-Wechsel kontrolliert werden
Ein Plugin speichert Indexierungseinstellungen möglicherweise in eigenen Feldern.
Ein anderes verwendet andere Standardwerte.
Nach einem Wechsel könnten daher:
vorher indexierte Archive plötzlich noindex
oder
vorher ausgeschlossene Bereiche plötzlich indexierbar
werden.
Das ist kein Grund, Pluginwechsel zu vermeiden.
Es ist ein Grund, die wichtigsten Seitentypen danach technisch zu kontrollieren.
Auch Themewechsel können theoretisch Robots-Ausgaben beeinflussen
WordPress-Robots-Direktiven werden normalerweise über Core und Plugins verwaltet.
Themes können jedoch ebenfalls Code im Head oder Filter hinzufügen.
Deshalb zählt am Ende niemals die Annahme:
Mein SEO-Plugin steht auf „Index“.
Sondern die tatsächliche Antwort der Website.
Ein Browser beziehungsweise Crawler erhält nur das ausgelieferte Ergebnis.
Serverregeln können selbst WordPress überstimmen
Wenn ein Webserver für sämtliche Antworten setzt:
X-Robots-Tag: noindex
kann WordPress im HTML noch so oft indexierbar wirken.
Google erhält trotzdem die restriktive HTTP-Regel.
Da Google bei widersprüchlichen Robots-Direktiven restriktivere Regeln berücksichtigt, kann ein solcher Header entscheidend sein. (Google for Developers)
Das ist besonders bei Staging-Systemen und Servermigrationen wichtig.
CDN und Reverse Proxy können ebenfalls Header verändern
Wenn vor dem Origin ein Proxy oder CDN sitzt, kann auch dort ein X-Robots-Tag hinzugefügt werden.
Dann sieht der Administrator im WordPress-HTML keinen Fehler.
Der öffentliche HTTP-Response enthält trotzdem noindex.
Das ist ein weiterer Grund für unsere wiederkehrende Regel:
Diagnostiziere die tatsächliche öffentliche Antwort – nicht nur die Einstellung in einem Backend.
Cache kann eine alte noindex-Version festhalten
Angenommen, eine Seite war gestern noindex.
Heute wird die Einstellung geändert.
Ein CDN oder Page Cache liefert aber weiterhin eine ältere HTML-Fassung mit:
<meta name="robots" content="noindex">
Dann sieht Googlebot weiterhin den alten Zustand.
Nach Indexierungsänderungen sollte deshalb geprüft werden, ob sämtliche relevanten Cache-Ebenen die aktuelle Version ausliefern.
Die technischen Grundlagen dazu findest du unter Caching einfach erklärt.
Dasselbe gilt in die andere Richtung
Eine Seite soll neu auf noindex gesetzt werden.
WordPress ist korrekt konfiguriert.
Das CDN liefert aber noch die alte indexierbare Fassung.
Googlebot kann dann weiterhin die vorherige Variante erhalten.
Indexierungssteuerung ist deshalb nicht nur eine SEO-Plugin-Frage.
Sie ist Teil der kompletten Webauslieferung.
noindex kann Suchtraffic vollständig beenden
Das klingt selbstverständlich, sollte aber bei redaktionellen Entscheidungen nicht vergessen werden.
Wenn eine Seite bewusst noindex erhält, soll sie nicht als Google-Suchergebnis erscheinen. Google sagt ausdrücklich, dass erkannte noindex-Ressourcen aus Google Search entfernt werden, unabhängig davon, ob andere Websites auf sie verlinken. (Google for Developers)
Eine bestehende Seite mit gutem Suchtraffic sollte daher niemals leichtfertig auf noindex gesetzt werden.
Vorher sollte klar sein:
Warum soll dieser Traffic künftig nicht mehr über diese URL stattfinden?
Interne Seitenkonsolidierung braucht deshalb einen Plan
Angenommen, zwei Artikel behandeln dasselbe Thema.
Artikel A bekommt 5.000 Besucher.
Artikel B bekommt 200.
Die Lösung lautet nicht automatisch:
B auf noindex.
Vielleicht sollten beide Inhalte zusammengeführt und B auf A weitergeleitet werden.
Vielleicht erfüllen sie doch unterschiedliche Suchintentionen.
Vielleicht sollte B verbessert werden.
noindex ist nur eine mögliche Option – häufig nicht die beste für eine tatsächlich überflüssige Seite.
noindex kann ein Symptom verdecken
Eine Website besitzt 50.000 schwache Tagseiten.
Nun setzt man alle auf noindex.
Das Indexproblem ist damit möglicherweise reduziert.
Aber die Website erzeugt weiterhin 50.000 unnötige URLs.
Crawler können sie weiterhin entdecken und abrufen, sofern nichts anderes geändert wurde.
Die technische Architektur bleibt komplex.
Manchmal ist deshalb die bessere Lösung:
unnötige URL-Erzeugung reduzieren.
Nicht nur ihre Indexierung abschalten.
Indexsteuerung und Crawlsteuerung müssen gemeinsam geplant werden
Bei großen Websites können beide Anliegen gleichzeitig relevant sein.
Eine URL soll:
nicht indexiert werden
und
langfristig möglichst wenig Crawlerressourcen verbrauchen.
Nun muss die Reihenfolge bedacht werden.
Wenn Google die noindex-Anweisung noch nicht kennt, sollte die URL zunächst crawlbar bleiben, damit das Signal verarbeitet werden kann. Eine sofortige robots.txt-Sperre kann genau das verhindern. (Google for Developers)
Solche Strategien sind für sehr große Websites interessant.
Für einen normalen Blog ist diese Komplexität meistens unnötig.
Kleine Websites brauchen selten komplizierte noindex-Regeln
Für ein überschaubares Wissensportal kann die Strategie erstaunlich einfach sein.
Indexierbar:
gute Artikel,
echte Hub-Seiten,
sinnvolle Magazinbeiträge.
Nicht indexierbar:
rein funktionale oder bewusst nicht als Suchergebnis gedachte Seiten.
Das reicht häufig.
Je klarer die Informationsarchitektur, desto weniger Indexierungs-Sonderregeln werden benötigt.
Gute Seitenstruktur reduziert den Bedarf an SEO-Schaltern
Wenn Casiopeya keine sinnlosen Tagarchive erzeugt, müssen wir sie später auch nicht mühsam auf noindex stellen.
Wenn jede wichtige Seite einen klaren Zweck besitzt, muss niemand hunderte „Thin Content“-URLs aussortieren.
Wenn Funktionen bewusst geplant werden, ist von Anfang an klar, welche Seiten Suchziele sind.
Die eleganteste technische SEO ist häufig diejenige, bei der nur wenige Ausnahmen geregelt werden müssen.
Was du dir über noindex merken solltest
noindex ist eine Anweisung an unterstützende Suchmaschinen, eine Seite oder Ressource nicht in ihren Suchergebnissen zu führen. Google unterstützt sie über ein Robots-Meta-Tag und über den HTTP-Header X-Robots-Tag. (Google for Developers)
Für HTML kann die Regel beispielsweise lauten:
<meta name="robots" content="noindex">
Für eine PDF beispielsweise:
X-Robots-Tag: noindex
Damit Google die Regel erkennen kann, muss die URL crawlbar sein. Eine gleichzeitige robots.txt-Sperre kann verhindern, dass Google das noindex sieht. (Google for Developers)
noindex bedeutet nicht:
privat,
passwortgeschützt,
gelöscht,
weitergeleitet
oder
kanonisiert.
Es bedeutet nur:
Diese Ressource soll nicht als Suchergebnis indexiert sein.
nofollow ist eine eigene Direktive.
none entspricht bei Google noindex, nofollow. (Google for Developers)
Google unterstützt noindex nicht als Regel innerhalb der robots.txt. (Google for Developers)
WordPress besitzt eine eigene Robots-Infrastruktur und verwendet noindex unter anderem für interne Suchergebnisse sowie für Websites, deren Suchmaschinensichtbarkeit deaktiviert wurde. (WordPress Developer Resources)
Vor allem aber sollte vor jeder noindex-Entscheidung eine Frage beantwortet werden:
Soll diese Seite grundsätzlich ein eigenständiges Suchergebnis sein?
Wenn die Antwort Nein lautet und die Seite für Besucher trotzdem weiterhin existieren soll, ist noindex häufig genau das richtige Werkzeug.
Wenn die Antwort dagegen lautet:
Eigentlich ist das nur eine zweite Version einer anderen Seite,
dann kommen wir zum nächsten Thema.