Eine Seite, die nicht im Index steht, rankt nicht schlecht — sie rankt gar nicht. Dieser Beitrag zeigt, warum Crawl-Budget, Discovery und Indexierung drei getrennte Stufen sind und wie der Indexing Hub im neuen Semalt Panel diesen blinden Fleck messbar macht.
Die meisten SEO-Projekte in Wien und Umgebung beginnen bei Inhalten, Keywords und Verlinkung. Das ist nachvollziehbar, denn dort passiert die sichtbare Arbeit. Übersehen wird dabei regelmäßig die Stufe davor: die Frage, ob eine Suchmaschine die betreffenden Seiten überhaupt kennt und aufgenommen hat. Solange diese Frage offen ist, sind alle weiteren Optimierungen Arbeit an einem Objekt, das für die Suche nicht existiert.
Das Problem betrifft nicht nur Großportale. Ein Onlineshop mit 8.000 Artikelseiten, ein Immobilienbüro mit tausenden Objektseiten, ein Fachverlag mit gewachsenem Archiv — überall entstehen Seitenmengen, die schneller wachsen, als sie freiwillig erfasst werden. Weil Indexierung im Alltag unsichtbar bleibt, fällt der Rückstand erst auf, wenn der organische Traffic seit Monaten stagniert, obwohl das Redaktionsteam fleißig produziert hat. Wer einen Gesamteindruck der Plattform sucht, findet ihn auf der Übersichtsseite für das neue Semalt Panel; hier geht es bewusst nur um das Indexierungskapitel.
Crawl-Budget, Discovery und Indexierung sind nicht dasselbe
Der häufigste Denkfehler in Indexierungsfragen ist die Annahme, es handle sich um einen einzigen Vorgang. Tatsächlich sind es drei aufeinanderfolgende Stufen mit jeweils eigener Logik. Ein Problem auf der ersten Stufe lässt sich nicht durch Maßnahmen auf der dritten reparieren — und umgekehrt genauso wenig.
Die Entdeckung einer Adresse, ihr tatsächlicher Abruf und die Entscheidung über die Aufnahme in den Suchindex sind organisatorisch getrennte Schritte. Wer diese Trennung im Kopf hat, stellt bei einem Sichtbarkeitsproblem sofort die richtige erste Frage: Auf welcher Stufe hakt es eigentlich?
| Stufe | Was dabei passiert | Typische Blockade | Richtige Gegenmaßnahme |
|---|---|---|---|
| Discovery | Die Suchmaschine erfährt, dass eine URL existiert — über interne Links, Sitemaps, externe Verweise oder eine aktive Meldung. | Verwaiste Seite, fehlender Sitemap-Eintrag, Klicktiefe jenseits von zehn Ebenen. | Interne Verlinkung, saubere Sitemap, aktive Übermittlung. |
| Crawling | Der Bot ruft die Adresse tatsächlich ab. Die Menge der Abrufe pro Zeitraum wird umgangssprachlich Crawl-Budget genannt. | Langsame Serverantwort, 5xx unter Last, Millionen wertloser Parametervarianten. | Infrastruktur, Statuscodes, Aufräumen von URL-Varianten. |
| Indexierung | Die abgerufene Seite wird bewertet und aufgenommen — oder eben nicht. Diese Entscheidung ist inhaltlich, nicht mechanisch. | Dünner Inhalt, Duplikat, fehlender eigenständiger Wert, widersprüchliche Kanonisierung. | Inhaltliche Substanz, klare Canonicals, konsistente Signale. |
Das Crawl-Budget ist dabei keine Zahl auf einer Rechnung, sondern das Ergebnis aus Serverleistung, bisheriger Antwortqualität und der Einschätzung, wie lohnend eine Domain ist. Ein Server, der bei Lastspitzen mit Fehlern antwortet oder drei Sekunden bis zum ersten Byte braucht, bekommt weniger Abrufe zugeteilt — die Suchmaschine drosselt sich selbst, um die Website nicht zu belasten.
Sechs Gründe, warum Seiten draußen bleiben
In Audits wiederholen sich die Ursachen bemerkenswert zuverlässig. Die folgenden sechs Muster decken den größten Teil dessen ab, was in der Praxis auffällt — sortiert nach der Stufe, auf der sie wirken.
Verwaiste Seiten
Eine URL existiert und ist aufrufbar, wird aber von keiner anderen Seite der eigenen Website verlinkt. Sie hat damit keinen Zugangsweg mehr.
- Entsteht bei Kategorieumbauten und entfernten Filtern
- Kampagnenseiten nach Aktionsende aus der Navigation genommen
- Bleibt online, verliert aber jede Auffindbarkeit
Schwache interne Verlinkung
Subtiler als die verwaiste Seite: formal verlinkt, praktisch unerreichbar. Klicktiefe wird als Relevanzsignal gelesen.
- Produkt hängt auf Seite 14 einer Paginierung
- Zwölf Klicks Abstand von der Startseite
- Für Nutzer wie für Bots faktisch unsichtbar
Duplicate Content
Shops erzeugen Dubletten fast automatisch. Die Suchmaschine wählt dann eine Variante aus — nicht unbedingt Ihre bevorzugte.
- Dasselbe Produkt in drei Kategoriepfaden
- Sortier-, Filter- und Sitzungsparameter
- Druckansichten, Varianten mit und ohne Schrägstrich
Fehlerhafte Canonicals
Das Canonical-Tag ist das richtige Instrument gegen Dubletten, wird aber häufig gegen sich selbst gerichtet.
- Alle Paginierungsseiten zeigen auf Seite 1
- Ziel leitet weiter, trägt noindex oder existiert nicht
- Ein Canonical ist ein Hinweis, keine Anweisung
robots.txt und noindex
Zwei Mechanismen, die ständig verwechselt werden — mit teuren Folgen beim Livegang.
- Gesperrte URLs werden nicht abgerufen, ihr noindex bleibt ungelesen
- Ausschluss aus dem Index verlangt Crawlbarkeit plus noindex
- Staging-noindex, das beim Relaunch stehen bleibt, kostet Wochen
Langsame Auslieferung
Antwortzeiten begrenzen unmittelbar die Zahl der Abrufe pro Zeiteinheit. Bei kleinen Websites folgenlos, bei großen entscheidend.
- 200 Millisekunden gegen 2 Sekunden ist ein Vielfaches an Durchsatz
- Bei 30.000 URLs entscheidet das über Tage oder Monate
- Serverfehler wirken auf die gesamte Domain zurück
Wer eine große Seitenmenge hat und die Serverantwort nicht im Griff, sollte dort ansetzen, bevor er über Einreichungswerkzeuge nachdenkt. In dieser Reihenfolge liegt der Unterschied zwischen einer wirksamen Maßnahme und einem verbrauchten Budget — die technischen Grundlagen stehen zu Recht am Anfang.
Der Indexing Hub und seine harten Grenzwerte
Der Indexing Hub ist der Bereich des Panels, in dem Einreichung, Sitemap-Verarbeitung und Beobachtung zusammenlaufen. Für die Planung entscheidend sind seine Grenzwerte, denn sie bestimmen, was in welchem Zeitraum realistisch ist. Diese Zahlen offen zu kennen, ist wertvoller als jedes Versprechen.
Die interessanteste Zahl ist die kleinste. Tausend URLs pro Tag klingen nach viel, solange man an eine Firmenwebsite mit sechzig Seiten denkt. Bei einem Katalog im fünfstelligen Bereich ist es ein Budget, das verplant werden muss wie ein Werbeetat. Genau darin liegt der eigentliche Nutzen: Die Grenze erzwingt eine Entscheidung darüber, welche Seiten wichtig sind — eine Entscheidung, die ohnehin fällig wäre und im Alltag gerne umgangen wird.
| Kennwert | Wert | Praktische Bedeutung |
|---|---|---|
| Tagesbudget URL-Tracker | 1.000 URLs pro Tag und Konto | Die eigentliche Durchsatzgrenze. Tausend sorgfältig gewählte URLs schlagen tausend zufällige. |
| Massen-Einreichung | bis 10.000 URLs je Stapel | Eine ganze Liste in einem Arbeitsschritt übergeben statt manuell stückeln. Die Abarbeitung folgt weiterhin dem Tagesbudget. |
| Sitemap-Quelle | Datei-Upload oder URL | Auch noch nicht öffentlich verlinkte Sitemaps lassen sich vor einem Relaunch prüfen. |
| Rekursives Parsen | bis zu 3 Ebenen tief | Index-Sitemaps, die auf weitere Index-Sitemaps verweisen, werden aufgelöst. Tiefere Verschachtelung muss flacher gebaut werden. |
| Sitemaps pro Job | bis zu 1.000 | Deckt große, nach Kategorien oder Sprachen segmentierte Sitemap-Sets in einem Durchgang ab. |
| Gleichzeitige Jobs | maximal 2 | Zwei Domains oder zwei Sitemap-Sets parallel, alles Weitere wartet. |
| Warteschlange | maximal 20 Jobs | Genügt für Agenturen mit mehreren Mandanten, ist aber kein unbegrenzter Stapelbetrieb. |
| Protokoll je URL | Zeitstempel, Status, Fehlerdetails | Macht nachvollziehbar, ob eine Adresse abgerufen wurde und mit welchem Ergebnis. |
Zwei Wege hinein: Stapel und Sitemap
Der Hub bietet zwei Einstiegspunkte, die sich in der Praxis ergänzen. Der eine geht von einer Liste konkreter Adressen aus, der andere von einer bestehenden Sitemap-Struktur. Beide münden in denselben Tracker und teilen sich dasselbe Tagesbudget.
Massen-Einreichung von URLs
Für Situationen, in denen kurzfristig sehr viele Adressen neu oder verändert sind.
- Ein Arbeitsschritt statt vieler. Die vollständige Liste wird einmal übergeben; das manuelle Aufteilen in Tagesportionen entfällt.
- Das Tagesbudget bleibt die Bremse. Ein Stapel von 10.000 Adressen wird nicht an einem Tag abgearbeitet, sondern über die Zeit hinweg im Rahmen der 1.000 pro Tag.
- Reihenfolge ist eine Entscheidung. Weil das Budget knapp ist, entscheidet die Sortierung der Liste über den geschäftlichen Ertrag der ersten Woche.
- Lohnend bei Ausnahmen, nicht im Dauerbetrieb. Relaunch mit neuer URL-Struktur, Domainmigration, saisonale Kategorien, ein neu aufgenommenes Sortiment oder eine nachträglich behobene Blockade.
Sitemap-Verarbeitung
Für gewachsene Bestände, die bereits in einer Index-Sitemap-Struktur organisiert sind.
- Upload oder URL. Die Datei kann hochgeladen oder als Adresse angegeben werden — praktisch, wenn eine neue Struktur vor dem Livegang geprüft werden soll.
- Rekursiv bis drei Ebenen. Eine Index-Sitemap, die auf weitere Index-Sitemaps zeigt, wird aufgelöst. Wer tiefer verschachtelt, baut die Struktur besser flacher.
- Bis 1.000 Sitemaps je Auftrag. Auch nach Sprachen, Standorten oder Inhaltstypen segmentierte Sets laufen in einem Durchgang durch.
- Zwei Jobs parallel, zwanzig warten. Für Mehrmandantenbetrieb ausreichend, aber die Reihenfolge sollte bewusst gesetzt werden: der Kunde mit dem Relaunch am Freitag gehört vor die Routinepflege.
Die Übermittlung selbst erfolgt in beiden Fällen über die IndexNow-Schnittstelle an GoogleBot und BingBot. Wer sich ansehen möchte, wie der Indexing Hub von Semalt das im Zusammenspiel mit den übrigen Modulen abbildet, findet die Beschreibung in der Plattformübersicht.
Push statt Warten — und was danach im Protokoll steht
IndexNow als aktive Meldung
Klassisch funktioniert Indexierung nach dem Pull-Prinzip: Die Suchmaschine entscheidet, wann sie vorbeischaut. Bei einer selten aktualisierten Domain kann das für tief liegende Seiten Wochen dauern. IndexNow dreht die Richtung um — die Website meldet aktiv, dass sich unter einer bestimmten Adresse etwas geändert hat.
Der Gewinn liegt vor allem im Zeitfaktor bei Änderungen. Eine korrigierte Produktbeschreibung, ein aktualisierter Preis, eine überarbeitete Ratgeberseite, eine frisch veröffentlichte Kategorie: Statt zu hoffen, dass der nächste turnusmäßige Besuch die Änderung mitnimmt, wird der Anlass gemeldet. Für saisonale Geschäfte ist das der Unterschied zwischen rechtzeitiger Sichtbarkeit und Sichtbarkeit nach der Saison.
Realistisch formuliert leistet der Push zweierlei. Er verkürzt die Zeit bis zur Entdeckung, und er ersetzt die unbeantwortbare Frage, ob die Suchmaschine von einer Seite überhaupt weiß, durch die beantwortbare Frage, warum sie sich gegen die Aufnahme entschieden hat. Das ist ein erheblicher Fortschritt, auch wenn er unspektakulär klingt.
Das Bot-Besuchsprotokoll als Diagnosewerkzeug
Der aus Diagnosesicht wertvollste Teil des Hubs ist nicht die Einreichung, sondern das Protokoll je URL. Für jede übermittelte Adresse wird festgehalten, wann ein Bot sie besucht hat, mit welchem Status das endete und welche Fehlerdetails dabei anfielen. Dazu kommen Live-Zähler für eingereichte, gefundene und fehlgeschlagene Adressen, sodass ein laufender Vorgang nicht blind beobachtet werden muss.
Der Nutzen entsteht durch die Kombination der drei Angaben. Der Zeitstempel beantwortet, ob überhaupt ein Abruf stattfand. Der Status trennt technische von inhaltlichen Fällen. Die Fehlerdetails liefern die Richtung für die Korrektur.
- Kein Besuch trotz Einreichung. Gemeldet, aber nicht abgerufen. Prüfen Sie robots.txt, Serverauslastung und ob die Domain generell gedrosselt wird.
- Besuch mit Serverfehler. Der Crawler war da und ist auf einen 5xx gestoßen. Ein Infrastrukturthema, das auf das gesamte Crawl-Verhalten zurückwirkt, nicht nur auf diese eine Seite.
- Besuch mit 404 oder 410. Meist eine veraltete Sitemap oder ein interner Link auf entfernte Inhalte. Aufräumen statt erneut einreichen.
- Besuch mit Weiterleitung. Eingereicht wurde eine Zwischenstufe. Übergeben Sie grundsätzlich das Weiterleitungsziel.
- Erfolgreicher Besuch, keine Aufnahme. Der technische Teil ist erledigt. Die Ursache liegt im Inhalt, in der Kanonisierung oder in fehlender interner Verlinkung.
40.000 URLs bei 1.000 pro Tag
Das folgende Szenario ist konstruiert, um die Größenordnung greifbar zu machen. Es ist eine Beispielrechnung, kein Erfahrungswert aus einem konkreten Projekt.
Ein Shop führt 40.000 Adressen in der Sitemap. Bei einem Tagesbudget von 1.000 ergibt das rechnerisch 40 Tage, sofern das Budget täglich vollständig genutzt wird und nichts nachgereicht werden muss. In der Praxis kommen Korrekturläufe dazu, sodass sechs bis acht Wochen realistischer sind. Der Stapel mit bis zu 10.000 Adressen verkürzt diesen Zeitraum nicht — er erspart nur das manuelle Stückeln.
Sechs Wochen sind für eine Saisonstrecke zu lang. Die Konsequenz ist nicht, das Werkzeug abzulehnen, sondern die Liste zu sortieren. Eine plausible Aufteilung derselben 40.000 Adressen sähe so aus:
- Rund 12.000 Varianten und Parameterseiten. Farb- und Größenkombinationen, Filter, Sortierungen. Sie gehören kanonisiert, nicht eingereicht. Budgetaufwand: null.
- Rund 6.000 dauerhaft nicht verfügbare Artikel. Sie brauchen eine Entscheidung über Weiterleitung oder Entfernung, keine Übermittlung.
- Rund 400 Kategorie- und Ratgeberseiten. Sie tragen den Löwenanteil des Umsatzes und kommen zuerst — weniger als ein halber Tag Budget.
- Rund 5.000 Artikelseiten mit Suchvolumen und Lagerbestand. Sie folgen in fünf Tagen und decken das laufende Geschäft ab.
- Rund 16.000 Seiten Long Tail. Läuft danach im Hintergrund weiter, ohne Terminbindung und ohne Erwartungsdruck.
Aus 40 Tagen Blindeinreichung werden so knapp sechs Tage für alles, was geschäftlich zählt. Der Unterschied liegt nicht in der Technik, sondern in der Reihenfolge. Wer die Sichtbarkeitsdaten aus der Search-Console-Auswertung danebenlegt, richtet die Priorisierung zusätzlich an tatsächlichen Impressionen aus; die entsprechenden Ansichten derselben Plattform liegen im gleichen Konto und müssen nicht separat exportiert werden.
Sitemap-Hygiene und ein praktikabler Ablauf
Eine Sitemap ist keine Inventarliste aller vorhandenen Adressen, sondern eine Empfehlung. Jeder Eintrag darin ist eine Aussage: Diese Seite ist indexierungswürdig. Besteht die Datei zu dreißig Prozent aus Weiterleitungen, Fehlerseiten und noindex-Adressen, sinkt das Vertrauen in die gesamte Datei — und damit ihr Nutzen für die Seiten, die zu Recht darin stehen.
Indexierbare Zielseiten
Ausschließlich kanonische Adressen mit Status 200 in der finalen Schreibweise, inklusive korrektem Protokoll und Host.
- Ehrliche lastmod-Angaben statt täglich neu gesetzter Daten
- Segmentierung nach Kategorien, Produkten, Redaktion, Standorten
- Index-Sitemap als Dach — passt zur rekursiven Verarbeitung
Alles Nicht-Indexierbare
Jede Adresse, die ohnehin abgelehnt wird, verwässert die Aussage der Datei und verbraucht Aufmerksamkeit.
- noindex-Seiten, per robots.txt gesperrte Adressen, Weiterleitungen
- Parameter- und Filtervarianten, interne Suchergebnisse
- Warenkorb, Kontobereich, Staging-Hosts, Fehlerseiten
Aus alldem ergibt sich eine Reihenfolge, die sich in den meisten Projekten bewährt und die bewusst mit Aufräumen beginnt, nicht mit Einreichen. Zuerst wird die Sitemap bereinigt. Anschließend wird sie verarbeitet — per Upload oder Adresse, je nachdem, ob die Datei schon öffentlich erreichbar ist. Aus dem Ergebnis entsteht ein erstes Lagebild: Wie viele Adressen wurden gefunden, wie viele sind gescheitert, wo häufen sich Statuscodes?
Diese Fehlerliste wird abgearbeitet, bevor Budget für Einreichungen ausgegeben wird. Erst danach beginnt die priorisierte Übergabe, geschäftskritische Seiten zuerst. Nach etwa einer Woche liefert das Protokoll genug Datenpunkte für die eigentliche Analyse: besucht und aufgenommen, besucht und verworfen, gar nicht erst abgerufen. Die dritte Gruppe verweist auf technische Ursachen, die zweite auf inhaltliche. Beide führen zu konkreten Aufgaben, und der Zyklus beginnt von vorn — nun mit besserer Datengrundlage.
Häufige Fragen
Wie schnell wird eine eingereichte URL indexiert?
Dafür gibt es keine zusagbare Frist, und jede Zahl, die Ihnen genannt wird, ist geraten. Die Übermittlung verkürzt in der Regel die Zeit bis zur Entdeckung und bis zum ersten Abruf. Ob und wann die Aufnahme in den Index folgt, entscheidet die Suchmaschine anhand des Inhalts. Das Protokoll zeigt Ihnen immerhin, ob der Abruf stattgefunden hat — das ist die Hälfte der Antwort.
Reichen 1.000 URLs pro Tag für einen mittelgroßen Shop?
Für den laufenden Betrieb fast immer. Neue Artikel und geänderte Seiten liegen selbst bei aktiven Shops meist deutlich unter dieser Marke. Eng wird es nur bei Erstaufnahmen großer Bestände, bei Relaunches und bei Migrationen. Genau dann lohnt sich die Vorabsortierung, weil sich der relevante Anteil eines Katalogs erfahrungsgemäß auf einen Bruchteil der Gesamtmenge reduzieren lässt.
Ersetzt der Indexing Hub die Google Search Console?
Nein, und er ist auch nicht so gedacht. Die Search Console bleibt die Instanz für die Sicht der Suchmaschine auf Ihre Domain. Der Hub ergänzt sie um den aktiven Teil: Übermittlung im Stapel, rekursive Sitemap-Verarbeitung und ein eigenes Protokoll über Bot-Besuche. Beide Perspektiven zusammen ergeben ein Bild, das keine der beiden allein liefert.
Was passiert, wenn ich dieselbe URL mehrfach einreiche?
Sie verbrauchen Tagesbudget, ohne etwas zu gewinnen. Wiederholtes Einreichen einer unveränderten Seite beschleunigt keine Entscheidung. Sinnvoll ist eine erneute Übergabe nur, wenn sich am Inhalt, an der Kanonisierung oder an einer technischen Blockade tatsächlich etwas geändert hat — beispielsweise nach dem Entfernen eines versehentlichen noindex.
Wie viele Sitemap-Jobs kann ich parallel laufen lassen?
Zwei gleichzeitig, weitere zwanzig können in der Warteschlange stehen. Für eine kleine Agentur mit mehreren Mandanten reicht das im Normalbetrieb aus, verlangt aber eine bewusste Reihenfolge. Planen Sie zeitkritische Fälle wie einen Relaunch vor die Routinepflege, sonst blockiert ein großer Durchlauf den dringenden.
Fazit: Sichtbarkeit beginnt bei der Auffindbarkeit
Indexierung ist deshalb der unterschätzte Engpass, weil sie im Erfolgsfall unsichtbar bleibt und im Fehlerfall nicht nach einem Fehler aussieht. Es gibt keine Warnmeldung und keinen roten Balken, nur Seiten ohne Impressionen. Wer diesen Bereich nicht aktiv misst, arbeitet an Texten und Verlinkung, während die Ursache eine Stufe früher liegt.
Der Indexing Hub ändert daran nichts durch Magie. Er ändert etwas, indem er drei Dinge zusammenbringt: eine klare Durchsatzgrenze, die zur Priorisierung zwingt; ein aktives Meldeverfahren, das die Entdeckungszeit verkürzt; und ein Protokoll, das Vermutungen durch Zeitstempel und Statuscodes ersetzt. Die Grenzen gehören ausdrücklich zum Bild — tausend Adressen pro Tag sind endlich, zwei parallele Jobs sind endlich, und eine Einreichung bleibt eine Einreichung.
Genau diese Nüchternheit macht den Bereich planbar. Wer weiß, dass 40.000 Adressen bei vollem Budget rund 40 Tage brauchen, plant anders als jemand, der auf einen Knopf drückt und hofft. Wenn Sie prüfen möchten, wie viele Ihrer Seiten tatsächlich erfasst sind, können Sie das Semalt-Dashboard öffnen und mit einem Sitemap-Durchlauf beginnen; das erste Lagebild ist meist aufschlussreicher als erwartet.