ONMA Ratgeber

Webseite bei Suchmaschinen eintragen: Der technische Indexierungs-Workflow

Erfahren Sie, wie Sie Indexierbarkeit prüfen, Properties verifizieren, Sitemaps einreichen und Ablehnungsgründe in der Search Console beheben.

Nahaufnahme einer Laptop-Tastatur, darüber blau eingefärbter HTML-Quelltext

Wer eine neue oder relaunchte Webseite “bei Suchmaschinen eintragen” will, arbeitet in der Praxis nicht mit einem Eintragsformular, sondern mit einer kontrollierten Prozesskette: Indexierbarkeit prüfen, Property verifizieren, URLs diagnostizieren, Sitemap einreichen, Änderungen melden und den Indexierungsstatus laufend kontrollieren. Der klassische Eintrag als einmalige Aktion existiert so nicht mehr.

Google hat sein öffentliches Formular unter google.com/addurl bereits 2018 abgeschaltet. Seitdem läuft das Melden einzelner URLs über die URL-Prüfung der Search Console. Grundsätzlich findet Google die meisten neuen Seiten ohne jede manuelle Einreichung, sofern sie intern oder extern verlinkt sind. Ein eingereichtes Signal garantiert weder das Crawling noch die Aufnahme in den Index. Deshalb liegt der eigentliche Wert nicht im Einreichen, sondern in der anschließenden Diagnose: Wie erkenne ich, dass eine URL indexiert ist, und warum ist sie es nicht?

1. Indexierbarkeit prüfen, bevor irgendetwas eingereicht wird

Der häufigste Fehler besteht darin, URLs zu melden, die ein Crawler gar nicht aufnehmen darf. Prüfen Sie deshalb jede wichtige URL vorab:

  • Liefert die URL den HTTP-Status 200?
  • Ist sie ohne Login, Cookie-Pflicht oder IP-Beschränkung erreichbar?
  • Erlaubt die robots.txt das Crawling?
  • Fehlt eine noindex-Anweisung im HTML oder im HTTP-Header?
  • Verweist das Canonical-Tag auf die URL selbst oder zumindest auf das richtige Ziel?
  • Ist die Seite intern verlinkt und nicht nur über die Sitemap bekannt?
  • Lässt sich der zentrale Inhalt serverseitig oder per Rendering auslesen?
  • Leitet die URL nicht auf eine andere Adresse weiter?

Gerade nach einem Relaunch bleiben Sperren aus der Entwicklungsumgebung bestehen. Typische Relikt-Fälle sind ein seitenweites noindex aus dem Staging-System, eine blockierende robots.txt oder ein Passwortschutz, der nach dem Livegang nicht entfernt wurde.

Zwei Zusammenhänge werden oft übersehen. Erstens: Ein noindex verhindert die Aufnahme in den Index auch dann, wenn die URL ausdrücklich eingereicht wurde. Zweitens: Google muss die Seite crawlen können, um das noindex überhaupt zu sehen. Die Kombination aus robots.txt-Sperre und noindex ist deshalb doppelt problematisch: Der Crawler darf die Seite nicht laden, erkennt die dort hinterlegte Anweisung nicht und kann die URL vorübergehend sogar ohne Inhaltskenntnis listen.

Auch Canonicals entscheiden über das Ergebnis. Zeigt eine neue Unterseite per Canonical auf die Startseite, eine alte URL oder eine Staging-Domain, behandelt die Suchmaschine die eingereichte URL als Duplikat und schließt sie aus, unabhängig davon, wie oft sie gemeldet wird.

2. Die Search-Console-Property verifizieren

Ohne verifizierte Property in der Google Search Console fehlt jede Diagnosemöglichkeit. Für neue Projekte und Relaunches ist die Domain-Property die sinnvollste Variante. Sie wird über einen DNS-TXT-Eintrag verifiziert und deckt anschließend alle Protokolle und Subdomains gemeinsam ab, also etwa:

  • https://example.de
  • https://www.example.de
  • https://shop.example.de
  • verbliebene HTTP-Varianten

Das ist besonders beim Relaunch relevant, weil Indexierungsprobleme selten auf genau einer URL-Variante auftreten. Wer nur eine URL-Präfix-Property für www.example.de einrichtet, sieht nichts von URLs unter shop.example.de. Richten Sie die DNS-Verifizierung möglichst vor dem Livegang ein, damit Daten und Prüfwerkzeuge ab Veröffentlichung verfügbar sind.

3. Einzelne URLs mit der URL-Prüfung diagnostizieren

Die URL-Prüfung ist das zentrale Werkzeug für die Analyse einzelner Seiten. Beginnen Sie mit repräsentativen Adressen: eine Leistungsseite, eine Kategorieseite, ein zentraler Ratgeberartikel.

Das Ergebnis beantwortet die entscheidenden Fragen:

  • Befindet sich die URL im Index?
  • Darf Google sie crawlen?
  • Welches Canonical hat Google ausgewählt?
  • Wann wurde die Seite zuletzt gecrawlt?
  • Wurde sie über eine Sitemap entdeckt?
  • Gibt es Probleme mit strukturierten Daten oder der mobilen Darstellung?

Wichtig ist die Unterscheidung zwischen gespeichertem Indexstand und Live-Test. Der gespeicherte Stand zeigt den zuletzt bekannten Zustand, der Live-Test prüft, ob die URL aktuell abrufbar und indexierbar wäre. Direkt nach einem Relaunch können beide Angaben deutlich auseinanderliegen.

Ist der Live-Test erfolgreich, können Sie die Indexierung beantragen. Nutzen Sie diese Funktion gezielt für wichtige neue oder stark überarbeitete Seiten, nicht für den gesamten URL-Bestand. Und beachten Sie: Eine erfolgreiche Beantragung bedeutet nur, dass die URL in eine Warteschlange aufgenommen wurde. Sie ist keine Indexierungszusage.

4. Die XML-Sitemap bereitstellen und einreichen

Für größere Webseiten ist die XML-Sitemap das wichtigste Signal für den vollständigen URL-Bestand. Sie sollte ausschließlich kanonische, indexierbare URLs mit Status 200 enthalten. Nicht hinein gehören:

  • weiterleitende URLs
  • Fehlerseiten
  • per noindex ausgeschlossene Seiten
  • Parameter- und Filtervarianten ohne Indexierungsziel
  • Duplikate mit fremdem Canonical
  • Staging- oder Testadressen

Eine einzelne Sitemap darf laut Protokoll maximal 50.000 URLs und unkomprimiert 50 MB umfassen. Größere Bestände werden auf mehrere Dateien verteilt und über einen Sitemap-Index gebündelt.

Reichen Sie die Sitemap in der Search Console ein und kontrollieren Sie, ob sie erfolgreich abgerufen wurde. Die Zahl der erkannten URLs sollte dem erwarteten Bestand entsprechen. Große Abweichungen deuten auf Generierungsfehler, falsche Hostnamen oder eine veraltete Datei hin.

Ergänzend können Sie den Speicherort suchmaschinenübergreifend in der robots.txt bekanntgeben:

Sitemap: https://www.example.de/sitemap.xml

Diese Direktive ersetzt aber nicht die Kontrolle in den Webmaster-Oberflächen. Und auch hier gilt: Die Sitemap ist ein Hinweis, keine Garantie. Ob URLs aufgenommen werden, hängt von Indexierbarkeit, Canonicals, Inhaltssignalen und interner Verlinkung ab.

5. Änderungen über IndexNow melden

Für Microsoft Bing, Yandex und weitere unterstützende Suchmaschinen ergänzt IndexNow den klassischen Crawling-Prozess. Das offene Protokoll, dessen gemeinsame Unterstützung Bing und Yandex 2021 angekündigt haben, meldet neue, geänderte oder gelöschte URLs per API.

IndexNow lohnt sich besonders bei häufigen Änderungen, etwa bei:

  • Nachrichten und aktuellen Meldungen
  • Stellenangeboten
  • Produktbeständen
  • Angebotsseiten mit wechselnden Preisen

Die Integration erfolgt meist über das CMS, ein Plugin oder eine serverseitige Anbindung. Gemeldet werden sollten nur tatsächlich geänderte URLs. Das dauerhafte Übermitteln des kompletten Bestands erzeugt keinen Mehrwert.

In den Bing Webmaster Tools lassen sich zusätzlich Sitemaps einreichen und einzelne URLs über die URL-Übermittlung melden, jeweils mit tages- und monatsbezogenen Kontingenten pro Property. Auch diese Meldung ist ein Crawling-Signal, keine Indexierungszusage. Für DuckDuckGo ist kein eigener Prozess nötig: Die Suchmaschine bezieht Web-Ergebnisse unter anderem aus dem Bing-Index, sodass eine saubere Erfassung durch Bing über Bing hinauswirkt.

6. Den Indexierungsstatus im Seitenindexierungsbericht kontrollieren

Nach dem Einreichen beginnt die eigentliche Arbeit: die Kontrolle. Der Bericht zur Seitenindexierung der Search Console zeigt pro bekannter URL, ob sie indexiert ist, und nennt für ausgeschlossene URLs einen konkreten Grund.

Beurteilen Sie nicht nur die Gesamtzahl, sondern die wichtigen URL-Gruppen. Nach einem Relaunch sollten die neuen Ziel-URLs schrittweise im Index erscheinen, während weitergeleitete Alt-URLs abnehmen. Typische Ausschlussgründe sind:

  • Durch robots.txt blockiert
  • Durch noindex-Tag ausgeschlossen
  • Seite mit Weiterleitung
  • Alternative Seite mit richtigem kanonischen Tag
  • Duplikat, Google hat eine andere kanonische Seite bestimmt
  • Gefunden, zurzeit nicht indexiert
  • Gecrawlt, zurzeit nicht indexiert
  • Nicht gefunden (404)
  • Serverfehler (5xx)

Nicht jeder Ausschluss ist ein Fehler. Eine weitergeleitete Alt-URL, eine bewusst ausgeschlossene Filterseite oder ein korrekt erkanntes Duplikat darf ausgeschlossen sein. Kritisch wird es erst, wenn eine strategisch wichtige, eindeutig indexierbare Zielseite betroffen ist.

7. Ablehnungsgründe systematisch auflösen

Bearbeiten Sie Ausschlüsse nach Ursache, nicht pauschal. Bei Durch robots.txt blockiert prüfen Sie, welche Regel greift und ob sie beabsichtigt ist. Bei Durch noindex-Tag ausgeschlossen untersuchen Sie sowohl den HTML-Quelltext als auch X-Robots-Tag-Header, die etwa vom Server oder CDN gesetzt werden.

Bei Canonical-Problemen müssen interne Links, Sitemap-Einträge, Weiterleitungen und Canonical-Tags dasselbe Ziel stützen. Nennt die Sitemap URL A, das Canonical verweist aber auf URL B, entsteht ein widersprüchliches Signal, das Google zulasten Ihrer Wunsch-URL auflöst.

Gefunden, zurzeit nicht indexiert heißt meist: Google kennt die URL, hat sie aber noch nicht abgerufen. Prüfen Sie interne Verlinkung, Sitemap-Zugehörigkeit und Serverstabilität. Bei Gecrawlt, zurzeit nicht indexiert wurde die Seite bereits geladen, aber verworfen. Kontrollieren Sie dann Duplikate, sehr ähnliche Inhalte, dünne Seiten und die Einbindung in die Seitenstruktur.

Nach jeder Korrektur testen Sie eine betroffene URL erneut per URL-Prüfung. Liegt das Problem berichtsweit vor, lassen Sie die Fehlerbehebung anschließend in der Search Console validieren.

Woran Sie erkennen, dass die Indexierung geklappt hat

Technisch bestätigt ist die Aufnahme, wenn die URL-Prüfung meldet, dass sich die URL im Index befindet und Google das erwartete Canonical verwendet. Ergänzend sollte die URL im Seitenindexierungsbericht als indexiert erscheinen.

Eine site:-Abfrage liefert einen schnellen Hinweis, ist aber keine verlässliche Bestandskontrolle. Fehlende Treffer beweisen nicht, dass eine URL nicht indexiert ist. Für die Diagnose sind Search Console und Bing Webmaster Tools deutlich aussagekräftiger.

Kontrollieren Sie nach einem Relaunch fortlaufend:

  • Steigt die Zahl indexierter neuer URLs?
  • Werden alte URLs sauber weitergeleitet?
  • Wählt Google die neuen Adressen als Canonical?
  • Enthält die Sitemap ausschließlich aktuelle Ziel-URLs?
  • Gehen 404- und Serverfehler zurück?

So wird aus dem vermeintlichen Suchmaschineneintrag ein überprüfbarer Workflow: technische Freigabe, Verifizierung, URL-Diagnose, Sitemap-Übermittlung, optional IndexNow und eine dauerhafte Kontrolle der Indexierungsgründe.