„Wir werden bei Google nicht gefunden“ ist einer der häufigsten Sätze in Gesprächen über die eigene Website — und einer der ungenauesten. Dahinter stecken zwei grundverschiedene Zustände. Entweder kennt die Suchmaschine die Seite überhaupt nicht: Dann hilft kein besserer Text und keine schönere Überschrift, weil niemand sie zu sehen bekommt. Oder sie kennt die Seite, zeigt sie aber weit hinten: Dann ist jeder technische Handgriff wirkungslos, weil technisch alles in Ordnung ist. Wer diese beiden Fälle vermischt, verliert Wochen mit Maßnahmen, die am Problem vorbeigehen. Dieser Beitrag stellt deshalb keine Sammlung von Tipps vor, sondern eine feste Prüfreihenfolge: erst die Frage nach dem Index, dann die sechs technischen Blockaden in fester Abfolge, danach die inhaltliche Seite. Jeder Schritt hat einen Test, der in wenigen Minuten ein eindeutiges Ergebnis liefert.
Zwei Probleme, die getrennt gehören
Der Satz „wir werden nicht gefunden“ beschreibt ein Gefühl, keinen Befund. Für die Fehlersuche braucht es zwei klar getrennte Begriffe. Indexierung heißt: Eine Suchmaschine hat die Seite abgerufen, verstanden und in ihren Datenbestand aufgenommen. Platzierung heißt: Unter allen aufgenommenen Seiten steht diese eine an einer bestimmten Stelle, wenn jemand einen Begriff eingibt. Das sind zwei Ebenen mit völlig unterschiedlichen Ursachen und Lösungen. Eine Seite, die nicht im Index steht, hat ein technisches oder ein Entdeckungsproblem. Eine Seite, die im Index steht und trotzdem keinen Besuch bekommt, hat ein inhaltliches Problem oder schlicht starke Konkurrenz.
Die Größenordnung hilft bei der Einordnung. In einer Auswertung von rund 14 Milliarden Seiten aus dem eigenen Datenbestand kam Ahrefs zu dem Ergebnis, dass 96,55 Prozent (Ahrefs) aller untersuchten Seiten keinen einzigen Besuch aus der Google-Suche erhalten; weitere 1,94 Prozent (Ahrefs) bekommen zwischen einem und zehn Besuchen im Monat. Diese Zahlen sind kein Beleg dafür, dass Suchmaschinen nicht funktionieren. Sie zeigen, dass „vorhanden, aber ohne Suchbesuch“ der statistische Normalfall im Web ist — und dass die Frage „warum stehen wir nicht vorn“ selten mit einem einzelnen Defekt zu beantworten ist.
Google sichert nicht zu, dass Ihre Seite gecrawlt, indexiert oder ausgeliefert wird, selbst wenn sie die Grundlagen der Google Suche erfüllt.
Diese Formulierung steht bewusst am Anfang, weil sie die Erwartung sortiert. Es gibt keinen Anspruch auf Aufnahme in den Index und keinen Anspruch auf eine bestimmte Position. Was es gibt, ist eine überschaubare Liste von Gründen, aus denen eine Seite mit hoher Wahrscheinlichkeit nicht aufgenommen wird — und genau diese Liste lässt sich abarbeiten. Die folgende Tabelle ordnet die häufigsten Beobachtungen aus der Praxis der jeweils passenden Ebene zu.
| Beobachtung | Wahrscheinliche Ebene | Erster Test |
|---|---|---|
| Die Seite erscheint auch bei der Suche nach ihrem exakten Titel nicht | Indexierung | URL-Prüfung in der Search Console |
| Nur die Startseite erscheint, sämtliche Unterseiten fehlen | Indexierung einzelner Seiten | Bericht zur Indexierung von Seiten öffnen |
| Die Seite erscheint beim Firmennamen, aber bei keinem Bedarfsbegriff | Platzierung | Gibt es zum Begriff überhaupt eine eigene Seite? |
| Es gibt viele Impressionen, aber kaum Klicks | Darstellung im Ergebnis | Titel und erste Zeile des Ergebnisses prüfen |
| Von der ganzen Domain erscheint nichts, sie ist wenige Wochen alt | Entdeckung | Sitemap eingereicht, Verweise vorhanden? |
Worum es hier bewusst nicht geht
Der erste Test: steht die Seite überhaupt im Index?
Bevor irgendetwas geändert wird, braucht es eine Antwort auf genau eine Frage: Kennt die Suchmaschine diese Adresse? Der schnellste Behelf ist der Suchoperator site:, eingegeben als site:beispiel.de oder für einen Bereich als site:beispiel.de/leistungen/. Erscheint dort nichts, ist das ein Hinweis — aber kein Beweis, und die angezeigte Trefferzahl schon gar nicht.
Die Liste der zurückgegebenen Adressen ist nicht in jedem Fall vollständig. Bei größeren Websites sollte man nicht erwarten, alle eigenen Adressen in den Ergebnissen zu sehen.
Belastbar wird die Antwort erst mit der URL-Prüfung in der Search Console. Sie beantwortet für eine einzelne Adresse vier Fragen auf einmal: ob die Seite im Index ist, ob das Crawling erlaubt ist, ob die Indexierung erlaubt ist und welche Adresse Google als kanonische Fassung ausgewählt hat. Dabei werden zwei Werte nebeneinander ausgewiesen — die vom Betreiber angegebene und die von Google ausgewählte kanonische Adresse (Google Search Console Hilfe). Weichen beide voneinander ab, ist die Ursache meistens schon gefunden.
Eine Stolperfalle im Prüfwerkzeug
- Suchen Sie den exakten Seitentitel in Anführungszeichen. Erscheint die Seite, ist sie im Index und das Problem liegt bei der Platzierung.
- Prüfen Sie
site:ihre-domain.deund notieren Sie, welche Seitentypen auftauchen und welche fehlen — Startseite, Leistungsseiten, Ratgeberbeiträge. - Öffnen Sie die URL-Prüfung für eine fehlende Adresse und lesen Sie die vier Zeilen: Indexstatus, Crawling zulässig, Indexierung zulässig, ausgewählte kanonische Adresse.
- Öffnen Sie den Bericht zur Indexierung von Seiten und sortieren Sie die Gründe nach Anzahl. Der häufigste Grund ist der erste Arbeitsauftrag.
Der Bericht zur Indexierung von Seiten ist dabei das wichtigste Werkzeug des ganzen Beitrags, weil er die Ursache benennt statt nur den Zustand. Er unterscheidet unter anderem zwischen „Durch robots.txt blockiert“, „Durch ‚noindex‘-Tag ausgeschlossen“, „Seite mit Weiterleitung“, „Alternative Seite mit kanonischem Tag“, „Duplikat ohne vom Nutzer ausgewähltes Canonical“, „Gecrawlt – zurzeit nicht indexiert“ und „Gefunden – zurzeit nicht indexiert“ (Google Search Console Hilfe). Jeder dieser Gründe hat eine andere Lösung, und genau in dieser Reihenfolge arbeitet die folgende Prüfliste sie ab.
Prüfschritt 1: blockiert die robots.txt?
Die robots.txt liegt im Wurzelverzeichnis einer Domain und regelt, welche Bereiche abgerufen werden dürfen. Sie gilt pro Host, Protokoll und Port: Die Datei unter https://www.beispiel.de/robots.txt gilt nicht für https://beispiel.de/ (Google Search Central, robots.txt-Spezifikation). Genau das ist eine der stillen Fehlerquellen, weil in der Praxis oft nur eine der beiden Varianten geprüft wird. In der Auswertung des HTTP Archive liefern 83,9 Prozent (HTTP Archive Web Almanac) der mobil erfassten Websites eine robots.txt mit Statuscode 200 aus, 14,1 Prozent (HTTP Archive Web Almanac) antworten mit 404 — was unkritisch ist, denn eine fehlende Datei behandelt Google wie eine Datei ohne Einschränkungen.
# So sieht eine unauffällige robots.txt aus
User-agent: *
Allow: /
Sitemap: https://www.beispiel.de/sitemap.xml
# Diese zwei Zeilen sperren die komplette Website.
# Sie stammen meist aus der Entwicklungsphase und
# wurden beim Umschalten auf die Livefassung vergessen:
#
# User-agent: *
# Disallow: /Die technischen Grenzwerte sind schnell erzählt und in der Praxis selten das Problem: Google liest höchstens 500 Kibibyte (Google Search Central, robots.txt-Spezifikation) einer robots.txt, speichert sie bis zu 24 Stunden (Google Search Central, robots.txt-Spezifikation) zwischen und folgt bei Weiterleitungen mindestens fünf (Google Search Central, robots.txt-Spezifikation) Sprüngen, bevor die Datei wie nicht vorhanden behandelt wird. Nur 0,06 Prozent (HTTP Archive Web Almanac) der erfassten Dateien überschreiten die Leselänge, 97,82 Prozent (HTTP Archive Web Almanac) bleiben unter 100 Kilobyte. Relevanter ist das Verhalten bei Serverfehlern: Antwortet die robots.txt mit einem 5xx-Status, pausiert Google das Crawling zunächst für 12 Stunden (Google Search Central, robots.txt-Spezifikation) und greift danach bis zu 30 Tage (Google Search Central, robots.txt-Spezifikation) auf die zuletzt gespeicherte Fassung zurück.
Eine Sperre ist kein Ausschluss aus dem Index
- Ein
Disallow: /aus der Bauphase, das beim Livegang stehen blieb — der klassische Totalausfall. - Eine robots.txt, die nur unter der www-Variante existiert, während die Nicht-www-Variante einen Serverfehler liefert.
- Gesperrte Verzeichnisse für Skripte, Schriften oder Bilder, die zum Darstellen der Seite gebraucht werden.
- Eine fehlende oder falsche
Sitemap:-Zeile, die auf einen anderen Host oder auf eine nicht mehr vorhandene Datei zeigt. - Regeln, die für ein Testsystem gedacht waren und beim Kopieren auf die Livedomain mitgewandert sind.
Prüfschritt 2: steht ein noindex im Quelltext?
Der zweite Prüfschritt kostet dreißig Sekunden: Quelltext der Seite öffnen und nach dem Wort „noindex“ suchen. Die Anweisung kann als Meta-Element im Kopfbereich stehen oder als HTTP-Antwortkopfzeile ausgeliefert werden — beides hat dieselbe Wirkung (Google Search Central, Dokumentation zur Indexierung). Verbreitet ist sie durchaus: 46,2 Prozent (HTTP Archive Web Almanac) der mobil erfassten Seiten enthalten überhaupt ein robots-Meta-Element, 3,9 Prozent (HTTP Archive Web Almanac) davon eine noindex-Anweisung. Bei Danke-Seiten, internen Suchergebnissen oder Testfassungen ist das Absicht. Auf einer Leistungsseite ist es ein Defekt.
<!-- Variante 1: im Kopfbereich der Seite -->
<head>
<meta name="robots" content="noindex, nofollow">
</head>
<!-- Variante 2: als Antwortkopfzeile des Servers -->
X-Robots-Tag: noindex
<!-- Gewünscht auf einer Seite, die gefunden werden soll: -->
<meta name="robots" content="index, follow">
<link rel="canonical" href="https://www.beispiel.de/leistungen/dachsanierung/">Der Doppelfehler, der sich selbst versteckt
Eine zweite Ursache ist schwerer zu sehen, weil sie im Quelltext unauffällig wirkt: ein beschädigter Kopfbereich. 10,9 Prozent (HTTP Archive Web Almanac) der mobil erfassten Seiten enthalten Elemente, die den head-Bereich vorzeitig beenden, 22 Prozent (HTTP Archive Web Almanac) platzieren dort sogar ein Bild. Alles, was hinter der Bruchstelle steht — robots-Meta, Canonical, Sprachangaben —, rutscht damit in den Textkörper und wird als Anweisung nicht mehr berücksichtigt. Bereits die Hinweise von web.dev zu Metadaten machen deutlich, dass solche Angaben in den Kopfbereich gehören und dass Suchmaschinen sie als Bitte behandeln, der sie folgen sollen (web.dev). Der passende Test ist die Live-Prüfung in der Search Console: Sie zeigt den gerenderten Quelltext so, wie Google ihn sieht, nicht so, wie er im Editor aussieht.
Und schließlich braucht jede Änderung an dieser Stelle Zeit. Eine entfernte noindex-Anweisung wirkt erst, wenn die Seite erneut abgerufen wurde; erscheint sie weiterhin in den Ergebnissen, wurde sie seit der Änderung vermutlich noch nicht neu gecrawlt, und je nach Bedeutung der Seite kann das Monate dauern (Google Search Central, Dokumentation zur Indexierung). Über die URL-Prüfung lässt sich eine erneute Indexierung anfordern — mit einem Tageslimit und ohne Zusicherung, dass die Seite anschließend aufgenommen wird (Google Search Console Hilfe).
Prüfschritt 3: wohin zeigt das Canonical?
Ein Canonical benennt die maßgebliche Adresse für einen Inhalt, der unter mehreren Adressen erreichbar ist. 65 Prozent (HTTP Archive Web Almanac) der mobil erfassten Seiten setzen ein solches Element, in der Desktop-Erfassung sind es 69 Prozent (HTTP Archive Web Almanac). Der Fehler entsteht selten dadurch, dass es fehlt — sondern dadurch, dass es auf die falsche Adresse zeigt. Besonders tückisch ist der Fall, in dem eine Vorlage oder ein Testsystem kopiert wurde und das Canonical weiterhin auf die Adresse des Musters verweist: Die eigene Seite erklärt der Suchmaschine damit selbst, sie sei nur die Kopie einer fremden Seite.
Eine Angabe zur bevorzugten kanonischen Adresse ist ein Hinweis, keine Regel.
Das ist in beide Richtungen wichtig. Ein falsches Canonical kann eine Seite aus den Ergebnissen drängen, ein richtiges Canonical setzt eine Wunschadresse aber nicht durch. Google zieht mehrere Signale heran: ob die Seite über HTTP oder HTTPS ausgeliefert wird, vorhandene Weiterleitungen, das Vorkommen der Adresse in der Sitemap und die rel-canonical-Angabe (Google Search Central, Dokumentation zur Kanonisierung). Widersprechen sich diese Signale, entscheidet die Suchmaschine — und der Bericht zur Indexierung von Seiten meldet das als „Duplikat, Google hat eine andere Seite als kanonisch bestimmt als der Nutzer“ (Google Search Console Hilfe).
| Das Canonical zeigt auf ... | Was daraus folgt | Korrektur |
|---|---|---|
| die Adresse der Seite selbst | der erwartete Normalfall | keine |
| die Startseite, und zwar auf jeder Unterseite | sämtliche Unterseiten gelten als Dubletten der Startseite | je Seite die eigene Adresse eintragen |
| eine fremde Domain aus Vorlage oder Testsystem | die eigene Seite wird als Kopie eines fremden Originals behandelt | auf die eigene Domain umstellen und erneut prüfen lassen |
| die http- oder die Nicht-www-Variante | die Signale verteilen sich auf zwei Adressen derselben Seite | eine Variante festlegen und die übrigen dauerhaft weiterleiten |
| eine Seite, die selbst ein noindex trägt | die Anweisung überträgt sich sinngemäß auf die ganze Gruppe | Ziel prüfen oder das Canonical entfernen |
Zwei Feinheiten kommen hinzu. Erstens kann ein Canonical parallel im HTML und in der HTTP-Antwortkopfzeile gesetzt sein: 1 Prozent (HTTP Archive Web Almanac) der Seiten nutzen die Kopfzeile, und bei 0,8 Prozent (HTTP Archive Web Almanac) widersprechen sich beide Angaben. Zweitens verändert sich das Canonical bei 2,1 Prozent (HTTP Archive Web Almanac) der mobil erfassten Seiten während des Renderns, weil ein Skript es nachträglich überschreibt. Beides sieht im Editor unauffällig aus und fällt erst in der Live-Prüfung auf. Wer regelmäßig eine kleine Kontrollrunde dreht, findet solche Abweichungen früh; wie eine solche Routine aussehen kann, beschreibt der Beitrag zur regelmäßigen Pflege einer Website.
Prüfschritt 4: Sitemap, Statuscodes und Soft-404
Die Sitemap ist eine Liste der Adressen, die eine Website für auffindenswert hält. Sie ersetzt keine interne Verlinkung, beschleunigt aber die Entdeckung — vor allem bei neuen oder tief liegenden Seiten. Die Vorgaben sind eindeutig: höchstens 50.000 Adressen (Google Search Central) und 50 Megabyte (Google Search Central) unkomprimiert je Datei, UTF-8-kodiert, mit vollständigen absoluten Adressen. Größere Bestände werden auf mehrere Dateien plus eine Indexdatei aufgeteilt. Und auch hier gilt die Einordnung von Google selbst: Das Einreichen einer Sitemap ist ein Hinweis, kein Auftrag (Google Search Central).
Drei Fehler treten dabei besonders häufig auf. Die Sitemap ist unter der angegebenen Adresse nicht erreichbar, weil sie nach einem Systemwechsel an einer anderen Stelle liegt. Sie enthält Adressen der falschen Hostvariante, also etwa Nicht-www-Adressen, während die Website unter www ausgeliefert wird. Oder sie listet Seiten auf, die ein noindex tragen oder auf eine andere Adresse weiterleiten — dann widersprechen sich die Signale, und die Sitemap verliert an Aussagekraft.
200 für gültige Seiten
Der Erfolgsstatus. Google reicht den Inhalt an die weitere Verarbeitung weiter — was für sich genommen noch keine Aufnahme in den Index bedeutet (Google Search Central).
301 für Umzüge
Der dauerhafte Umzug ist laut Google ein starkes Signal dafür, dass das Ziel verarbeitet werden soll; ein 302 wirkt nur als schwaches Signal (Google Search Central).
404 und 410 für Entferntes
Adressen mit 4xx-Status werden nicht indexiert, bereits aufgenommene Adressen werden aus dem Index entfernt (Google Search Central).
Soft-404 vermeiden
Eine Fehlermeldung, die mit Status 200 ausgeliefert wird, gilt als Soft-404 — die Seite sagt „nicht gefunden“, der Server sagt „alles in Ordnung“ (Google Search Console Hilfe).
Der Soft-404 ist der Fall, den kleine Betriebe am seltensten auf dem Schirm haben, weil er im Browser unsichtbar bleibt. Ein typisches Muster: Eine gelöschte Seite leitet auf die Startseite weiter, oder ein System liefert für unbekannte Adressen eine hübsche Fehlerseite mit Status 200 aus. Die Suchmaschine bekommt damit für jede beliebige Falschschreibung eine scheinbar gültige Seite geliefert. Ebenfalls relevant für die Fehlersuche: Serverfehler mit 5xx sowie der Status 429 führen dazu, dass Google das Crawling vorübergehend verlangsamt (Google Search Central) — ein Server mit sporadischen Aussetzern wird so zum Sichtbarkeitsproblem, ohne dass an der Website selbst etwas falsch wäre.
Prüfschritt 5: www und Nicht-www, http und https
Jede Website ist im Grundzustand unter vier Adressen erreichbar: mit und ohne www, jeweils über http und https. Google nennt Protokollvarianten ausdrücklich als eine der Ursachen doppelter Inhalte (Google Search Central, Dokumentation zur Kanonisierung). Antworten mehrere dieser Varianten mit Status 200, existiert dieselbe Website mehrfach — die Signale verteilen sich, und welche Fassung in den Ergebnissen erscheint, entscheidet die Suchmaschine. Das saubere Ziel ist einfach zu beschreiben: Eine Variante liefert 200, die drei anderen leiten dauerhaft auf sie.
Aufgerufene Adresse erwartete Antwort
---------------------------------------------------------------------
http://beispiel.de/ 301 -> https://www.beispiel.de/
http://www.beispiel.de/ 301 -> https://www.beispiel.de/
https://beispiel.de/ 301 -> https://www.beispiel.de/
https://www.beispiel.de/ 200
https://www.beispiel.de/leistungen/ 200
https://www.beispiel.de/gibt-es-nicht 404 (nicht 200 mit Fehlertext)Zwei Muster fallen bei dieser Prüfung regelmäßig auf. Das erste ist die Sammelweiterleitung: https://beispiel.de/leistungen/ landet nicht auf https://www.beispiel.de/leistungen/, sondern auf der Startseite. Die einzelne Seite existiert damit für die Suchmaschine an ihrer Adresse nicht mehr. Das zweite ist die Kette: http ohne www leitet auf http mit www, das leitet auf https mit www. Das funktioniert, kostet aber bei jedem Abruf zusätzliche Sprünge; eine direkte Weiterleitung auf die Zieladresse ist sauberer. Wo Domain, DNS und Server zusammenspielen, hilft der Beitrag über Domain und geschäftliche E-Mail bei der Einordnung.
- Legen Sie eine Variante als Zieladresse fest — die Entscheidung zwischen www und Nicht-www ist inhaltlich unerheblich, sie muss nur einheitlich sein.
- Prüfen Sie, ob interne Verweise die Zielvariante nutzen und nicht die weitergeleitete Fassung.
- Stellen Sie die Sitemap auf die Zielvariante um, sonst widersprechen sich Sitemap und Weiterleitung.
- Legen Sie in der Search Console eine Property für die gesamte Domain an, damit alle Varianten gemeinsam ausgewertet werden.
- Kontrollieren Sie, ob das Canonical der einzelnen Seiten dieselbe Variante nennt wie die Weiterleitung.
Prüfschritt 6: ist die Domain schlicht noch jung?
Wenn die fünf technischen Schritte ohne Befund bleiben und die Domain erst wenige Wochen alt ist, ist die wahrscheinlichste Antwort unbequem: Es ist noch zu früh. Google beschreibt drei Wege, auf denen Seiten gefunden werden — aus früheren Abrufen bekannte Adressen, Verweise von bereits bekannten Seiten und eingereichte Sitemaps (Google Search Central, Dokumentation zur Funktionsweise der Google Suche). Eine brandneue Domain ohne einen einzigen eingehenden Verweis erfüllt keine dieser drei Bedingungen von allein.
Für die Erwartung an die Dauer gibt es eine belastbare Formulierung aus der Search Console Hilfe: Die Indexierung dauert in der Regel etwa einen Tag, in manchen Fällen aber deutlich länger, und eine eingereichte Anfrage bedeutet keine Zusage, dass die Seite anschließend im Index erscheint (Google Search Console Hilfe). Für die Anzahl solcher Anfragen gilt zudem ein Tageslimit. Wer nach 48 Stunden das dritte Werkzeug installiert, arbeitet gegen einen Vorgang, der Zeit braucht.
Vier Wochen Geduld statt vier neuer Werkzeuge
Im Index und trotzdem unsichtbar: die inhaltliche Seite
Ab hier ändert sich die Art der Frage. Wenn die Seite im Index steht, ist Technik nicht mehr die Ursache, und jede weitere Stunde in Statuscodes ist verlorene Zeit. Jetzt geht es darum, ob es zum gesuchten Begriff überhaupt eine passende Seite gibt, wonach tatsächlich gesucht wird und wer an dieser Stelle bereits steht. Die eingangs genannten 96,55 Prozent (Ahrefs) ohne Suchbesuch entstehen ganz überwiegend hier — nicht durch Defekte, sondern durch fehlende Passung.
Gibt es eine passende Seite?
Wer für „Dachrinne reinigen“ gefunden werden möchte, braucht eine Seite, die genau diese Leistung behandelt. Eine Startseite, die alle Leistungen in einem Absatz aufzählt, beantwortet keine einzelne Anfrage vollständig.
Firmenname oder Bedarf?
Die Suche nach dem eigenen Firmennamen ist ein Test der Indexierung, kein Test der Sichtbarkeit. Neue Kundschaft kennt den Namen nicht und sucht nach dem Anliegen, nach dem Ort oder nach dem Preis.
Wer steht dort tatsächlich?
Bei allgemeinen Begriffen ohne Ortsbezug stehen häufig Portale und Verzeichnisse vorn. Dagegen anzuschreiben ist aufwendig; der erreichbare Platz liegt meist in konkreteren Begriffen mit Orts- oder Leistungsbezug.
Der Firmenname-Test lohnt sich, weil er beide Ebenen in einem einzigen Schritt trennt. Erscheint die Website bei der Suche nach dem eigenen Namen, ist sie im Index — dann ist die technische Prüfliste abgeschlossen. Erscheint sie danach bei keinem einzigen Bedarfsbegriff, fehlt die Verbindung zwischen der Sprache der Kundschaft und den vorhandenen Seiten. Wie sich diese Sprache ohne zusätzliche Werkzeuge erheben lässt, beschreibt der Beitrag über die Suchbegriffe der eigenen Kundschaft im Detail.
| Was eingegeben wird | Was die suchende Person erwartet | Welche Seite dafür passt |
|---|---|---|
| der Firmenname | Adresse, Öffnungszeiten, Telefonnummer | Startseite und Unternehmensprofil |
| Leistung plus Ort | einen erreichbaren Anbieter in der Nähe | eine Leistungsseite, die den Ort im Text nennt |
| „was kostet ...“ | einen Preisrahmen und Beispiele | eine Seite mit Preisrahmen oder ein Ratgeberabschnitt |
| die Leistung ohne Ortsbezug | Überblick, Auswahl, Vergleich | meist Portale und Verzeichnisse, selten ein einzelner Betrieb |
| eine konkrete Frage | eine direkte Antwort in wenigen Sätzen | ein Ratgeberabschnitt mit der Frage als Überschrift |
Eine dritte Ursache auf dieser Ebene benennt die Search Console direkt: „Gecrawlt – zurzeit nicht indexiert“ bedeutet, dass die Seite abgerufen, aber nicht aufgenommen wurde und dies später geschehen kann oder auch nicht (Google Search Console Hilfe). Das ist kein technischer Defekt, sondern ein inhaltliches Signal — typischerweise bei sehr kurzen Seiten, bei mehreren fast gleichen Ortsseiten oder bei Texten, die den Zweck der Seite nicht erkennen lassen. Der wirksame Hebel ist an dieser Stelle die Verständlichkeit; welche Formulierungen dabei helfen, zeigt der Beitrag über Website-Texte, die gelesen werden.
Und ein realistischer Blick auf den Wettbewerb gehört dazu. Wer in einem Landkreis mit vier vergleichbaren Betrieben arbeitet, kann bei ortsbezogenen Begriffen realistisch vorn stehen. Wer gegen bundesweite Portale um einen allgemeinen Begriff antritt, braucht dafür einen langen Atem und Inhalte, die es dort nicht gibt. Diese Einordnung ist keine Kapitulation, sondern die Grundlage der Prioritäten: erst die erreichbaren Begriffe belegen, dann die schwierigen angehen. Welche Seiten dafür zuerst entstehen sollten, ordnet der Beitrag über den notwendigen Seitenbestand nach Reihenfolge.
Die Prüfreihenfolge als Checkliste
Die folgende Liste ist die Kurzfassung des ganzen Beitrags und in dieser Reihenfolge abzuarbeiten. Jeder offene Punkt ist eine konkrete Aufgabe. Was weiter unten steht, lohnt sich erst, wenn alles darüber erledigt ist.
- Der exakte Seitentitel wurde in Anführungszeichen gesucht — erscheint die Seite, liegt kein Indexierungsproblem vor.
- Die URL-Prüfung wurde für mindestens eine fehlende Adresse geöffnet und die vier Zeilen wurden gelesen.
- Der Bericht zur Indexierung von Seiten wurde nach Gründen sortiert, der häufigste Grund ist notiert.
- Die robots.txt wurde unter beiden Hostvarianten aufgerufen und enthält kein
Disallow: /. - Der Quelltext der betroffenen Seite enthält kein noindex, weder als Meta-Element noch als Antwortkopfzeile.
- Der Kopfbereich der Seite ist unbeschädigt — Canonical und robots-Angabe stehen vor dem ersten Inhaltselement.
- Das Canonical zeigt auf die Seite selbst und nennt dieselbe Hostvariante wie die Weiterleitungen.
- Die Sitemap ist unter der angegebenen Adresse erreichbar, listet die Zielvariante und keine weitergeleiteten Adressen.
- Von den vier Adressvarianten liefert genau eine den Status 200, die anderen drei leiten dauerhaft dorthin.
- Eine nicht vorhandene Adresse liefert 404 und keine Fehlerseite mit Status 200.
- Bei einer Domain unter vier Wochen wurde die Sitemap eingereicht und mindestens ein Verweis auf die Domain geschaffen.
- Zu jedem wichtigen Bedarfsbegriff existiert eine eigene Seite, die genau diesen Begriff behandelt.
Was eine Auslieferung ab Werk abnimmt
Auffällig an dieser Liste ist, wie wenig davon eine Frage von Fachwissen ist. Die sechs technischen Prüfschritte beschreiben Zustände, die entweder von Anfang an richtig eingestellt sind oder bei jeder Änderung neu verrutschen können. In selbst gepflegten Systemen entstehen die Fehler typischerweise dort, wo mehrere Bausteine zusammenwirken: Ein Zusatzmodul setzt das Canonical, ein zweites schreibt die robots.txt, die Weiterleitungen liegen in der Serverkonfiguration, die Sitemap erzeugt ein dritter Baustein. Jede dieser Stellen kann einzeln ausfallen, ohne dass im Browser etwas auffällt.
Statische Auslieferung mit klaren Statuscodes
Jede Seite wird als fertige Datei ausgeliefert. Vorhandene Adressen antworten mit 200, entfernte mit 404, umgezogene mit einer dauerhaften Weiterleitung — ohne Zusatzmodul, das diese Logik nachbilden muss.
Sitemap und robots.txt aus dem Bestand
Beide Dateien entstehen beim Veröffentlichen aus den tatsächlich vorhandenen Seiten. Sie können nicht auf eine alte Struktur zeigen, weil sie keine getrennt gepflegte Liste sind.
Eine Adressvariante, ein Canonical
Die Zielvariante ist festgelegt, die übrigen leiten dorthin, und jede Seite trägt ihre eigene Adresse als Canonical — auch in übersetzten Fassungen mit den passenden Sprachangaben.
Der praktische Unterschied zeigt sich nicht am Tag der Veröffentlichung, sondern beim zwanzigsten Änderungswunsch: Wenn eine Seite umbenannt, eine Leistung ergänzt oder eine Ortsseite entfernt wird, bleiben Sitemap, Canonicals und Statuscodes ohne zusätzlichen Handgriff stimmig. Was dabei zum Umfang gehört, listet die Übersicht der Funktionen auf; wie der Weg vom Briefing zur veröffentlichten Website aussieht, beschreibt die Seite So funktioniert XICflow. Fertige Ergebnisse lassen sich in den Beispielseiten ansehen, die Kosten stehen in der Preisübersicht.
Wer gerade zwischen einem selbst gepflegten System und einer betreuten Auslieferung abwägt, findet die Unterschiede in genau diesen Punkten — Statuscodes, Sitemap, robots.txt, Canonicals, Weiterleitungen — in der Gegenüberstellung der Ansätze. Hakt die Prüfliste aus diesem Beitrag an einer Stelle, die sich nicht zuordnen lässt, ist ein kurzes Gespräch über den konkreten Fall meist schneller als eine weitere Nacht im Quelltext.
Die Kurzfassung
Quellen und Studien