Eine erreichbare URL ist nur ein Teil der technischen SEO-Prüfung. Eine Preisseite oder Produktseite kann HTTP 200 liefern und indexierbar sein, während ein Crawler die für wichtige Inhalte benötigten Daten nicht abrufen kann. Im normalen Browser fällt dieses Problem möglicherweise nicht auf.
Der folgende Fall beschreibt eine am 12. September 2026 beobachtete Korrektur bei Sitelemetry. Belegt ist, dass ein Google-Livetest anschließend die Preiskarten darstellen konnte. Eine tatsächliche Aufnahme in den Index oder Verbesserungen bei Rankings, Besuchen oder Verkäufen sind damit nicht nachgewiesen.
Umfang dieser Prüfung
Was messbar ist
- Antworten und Indexierungshinweise der exakten öffentlichen URL sowie passende robots.txt-Regeln.
- Öffentliche Ressourcen, die für wesentliche Seiteninhalte benötigt werden.
- Vorher-nachher-Nachweise aus dem Google-Livetest und die getrennte Dokumentation weiterer Schritte.
Was sie nicht belegt
- Ein statischer Abruf ersetzt nicht Googles Rendering und Indexierungssysteme.
- Ein erfolgreicher Livetest garantiert weder Indexierung noch einen Termin dafür.
- Keine belegte Aussage über Ranking-, Traffic- oder Umsatzsteigerungen aus dieser Änderung.
Die manuellen Schritte können unabhängig von einem Abonnement durchgeführt werden. Sitelemetry bietet SEO-Prüfungen in kostenpflichtigen Tarifen; für die URL-Prüfung in der Search Console ist geeigneter Property-Zugriff erforderlich.
Der konkrete Fall der Preisseite
Bei Sitelemetry lieferte /pricing HTTP 200 und konnte grundsätzlich indexiert werden. Im Google-Livetest fehlte jedoch der Preiskatalog. Die Seite benötigte die öffentliche Ressource /api/plans, deren Abruf durch die allgemeine Regel Disallow: /api/ verhindert wurde. Der funktionierende Aufruf der HTML-Seite reichte deshalb nicht aus, um den vollständigen Inhalt darzustellen.
Am 12. September 2026 wurde die eng begrenzte Ausnahme Allow: /api/plans$ ergänzt. Ein anschließender Google-Livetest zeigte die Preiskarten und bewertete die Seite als indexierbar; danach wurde eine Indexierung beantragt. Das ist ein Nachweis der Rendering-Korrektur. Es belegt weder bereits erfolgte Indexierung noch zusätzliche Suchbesuche. Private Kontoressourcen waren nicht Gegenstand der Freigabe.
Drei unterschiedliche Fragen getrennt beantworten
Kann der Crawler die URL abrufen? Kann er die benötigten Ressourcen laden und den wichtigen Inhalt darstellen? Entscheidet die Suchmaschine anschließend, die Seite zu indexieren? Diese Fragen gehören zusammen, haben aber unterschiedliche Antworten und Nachweise.
Google erläutert die Grenzen von robots.txt: Eine Crawling-Sperre ist kein verlässlicher Weg, eine bekannte URL aus Suchergebnissen zu entfernen. Für noindex muss der Crawler die Anweisung lesen können; eine gleichzeitige Sperre kann das verhindern. Beachten Sie die Dokumentation zur Blockierung der Indexierung. Vertrauliche Daten benötigen unabhängig davon echte Zugriffskontrollen. Weder robots.txt noch noindex schützt Informationen vor unbefugtem Zugriff.
Die Seite samt Abhängigkeiten prüfen
- Prüfen Sie die exakte URL mit Weiterleitungen, Antwortstatus, Inhaltstyp sowie Indexierungshinweisen in HTML und HTTP-Headern.
- Lesen Sie robots.txt der richtigen Herkunft und die Regeln für den betreffenden Crawler. Ein allgemeines
Allow: /beantwortet nicht jede speziellere Pfadregel. - Vergleichen Sie anfängliches HTML mit dem normalen Browser. Ermitteln Sie JavaScript, Stylesheets und öffentliche Daten, die für entscheidende Inhalte benötigt werden.
- Untersuchen Sie im Google-Livetest gerendertes HTML, Bildschirmdarstellung und fehlgeschlagene Ressourcen. Prüfen Sie den tatsächlichen Inhalt statt nur den grünen Gesamtstatus.
Eine statische Prüfung ist kein Google-Renderer. Die Google-Grundlagen zu JavaScript-SEO beschreiben die Verarbeitungsschritte. Fehlt ein Nachweis, halten Sie ihn als offene Prüfung fest.
Die kleinste passende Änderung vornehmen
Bestätigen Sie zunächst, dass die Ressource öffentlich sein soll und für den Seiteninhalt benötigt wird. Im beschriebenen Fall handelte es sich um den öffentlichen Tarifkatalog, nicht um Kundendaten. Der relevante Ausschnitt sah so aus:
User-agent: *
Disallow: /api/
Allow: /api/plans$Dies ist nur ein Regelausschnitt, keine vollständige robots.txt zum unveränderten Übernehmen. Google verwendet die spezifischste passende Regel; das Zeichen $ kennzeichnet das Ende der URL. Abfragevarianten oder untergeordnete Pfade sind dadurch nicht automatisch abgedeckt. Prüfen Sie das mit der offiziellen Regelspezifikation. Öffnen Sie nicht pauschal sämtliche API-Pfade. Je nach Aufbau kann es sinnvoller sein, wesentliche Inhalte bereits im HTML bereitzustellen. Authentifizierung und Berechtigungen bleiben erforderlich.
Mit Google erneut prüfen und Ergebnisse präzise benennen
Prüfen Sie zunächst, ob robots.txt abrufbar ist und die konkrete Ressource die erwarteten öffentlichen Daten liefert. Wiederholen Sie anschließend den Livetest und kontrollieren Sie, ob echte Preiskarten erscheinen, nicht nur ein Platzhalter oder eine Ladeanzeige. Dokumentieren Sie Testzeitpunkt, sichtbaren Inhalt und verbleibende Ressourcenfehler.
Danach kann eine Indexierung beantragt werden, sofern das zum Zustand der Seite passt. Halten Sie den Indexierungsstatus trotzdem getrennt vom Livetest fest. Erfolgreicher Abruf und korrektes Rendering bedeuten nicht, dass die URL bereits indexiert ist. Wiederholte Anträge liefern keine Termin- oder Rankinggarantie. Die belastbare Aussage in diesem Fall lautet: Der Livetest konnte den zuvor fehlenden Katalog darstellen.
Den nächsten Schritt nach Wirkung priorisieren
Priorisieren Sie Seiten, auf denen fehlender Inhalt eine wichtige Entscheidung verhindert, etwa Tarifvergleich oder Produktverständnis. Eine kaputte Preisdarstellung verdient Aufmerksamkeit, ohne dass dafür große Suchvolumina behauptet werden müssen. Prüfen Sie verwandte Vorlagen auf dieselbe Abhängigkeit, statt wahllos neue Freigaben hinzuzufügen.
Sorgen Sie außerdem für erreichbare interne Links und eine passende Sitemap. Laut Google-Sitemap-Dokumentation hilft eine Sitemap beim Entdecken von URLs, garantiert aber weder Crawling noch Indexierung. Halten Sie deshalb Sitemap-Aufnahme, HTTP-Antwort, Rendering und Indexierungsnachweis getrennt fest. Keiner dieser einzelnen Schritte garantiert Impressionen, Klicks oder Käufe. So bleibt der Bericht nachvollziehbar und die nächste Maßnahme konkret.
| Beobachtung | Priorität im Kontext | Zu bestätigender Nachweis | Nächster Schritt |
|---|---|---|---|
| Wichtige Preisinhalte fehlen im Rendering | Hoch auf der betroffenen Entscheidungsseite | Live-Inhalt und blockierte öffentliche Abhängigkeit | Begründete enge Korrektur vornehmen und erneut testen |
| Ein privater API-Pfad ist gesperrt | Nicht grundsätzlich ein SEO-Defekt | Bedarf des öffentlichen Inhalts an dieser Ressource klären | Zugriffskontrollen erhalten; private Daten nicht öffnen |
| HTTP 200 ohne Indexierungsnachweis | Getrennt zu untersuchender Zustand | Gerenderter Inhalt und tatsächlicher Indexierungsstatus | Indexierung separat prüfen; keinen angenommenen Gewinn melden |
Häufige Fragen
Bedeutet HTTP 200, dass Google den vollständigen Inhalt sieht?
Nein. Die HTML-Seite kann erreichbar sein, während Skripte, Stylesheets oder öffentliche Daten blockiert sind. Prüfen Sie gerenderten Inhalt und Ressourcen zusätzlich.
Sollten alle API-Pfade für Crawler freigegeben werden?
Nein. Prüfen Sie gezielt die benötigte öffentliche Ressource und erlauben Sie nur den passenden Umfang. Private Daten benötigen weiterhin wirksame Zugriffskontrollen.
Hat die Sitelemetry-Änderung bereits mehr Suchtraffic gebracht?
Das ist durch diesen Fall nicht belegt. Dokumentiert sind die korrigierte Darstellung im Google-Livetest und ein anschließender Indexierungsantrag, keine Ranking- oder Traffic-Steigerung.
Quellen und weiterführende Links
- Google: Einführung in robots.txtdevelopers.google.com
- Google: Spezifikation der robots.txt-Regelndevelopers.google.com
- Google: Grundlagen von JavaScript-SEOdevelopers.google.com
- Google: Indexierung mit noindex verhinderndevelopers.google.com
- Google: Überblick über Sitemapsdevelopers.google.com
Vom Sitelemetry-Team mit dem Prüfumfang des Produkts und verlinkten Primärquellen abgeglichen. Beispiele dienen der Veranschaulichung, sofern kein beobachteter Fall ausdrücklich genannt wird.
