Zuerst genau beschreiben, was fehlt.

„Wir werden nicht gefunden“ ist als Beobachtung verständlich, aber noch kein prüfbarer Auftrag. Benötigt werden eine konkrete Ziel-URL, eine konkrete Suchfrage, der Zeitpunkt und die Art des Problems: Fehlt schon die Suche nach dem eindeutigen Namen, ist eine neue Unterseite noch nicht aufgenommen oder ist eine zuvor sichtbare Leistung eingebrochen?

Eine Beobachtung auf dem eigenen Gerät bleibt eine Momentaufnahme. Hilfreicher ist ein Protokoll aus Zielseite, erwartetem Inhalt, tatsächlichem Status und jüngsten Änderungen. Erst damit lässt sich die passende Prüfebene auswählen.

Crawling: Kann ein System die URL erreichen?

Die erste Ebene betrifft den Abruf. Liefert die URL einen erfolgreichen Status? Gibt es crawlbare interne Links? Erlauben robots-Regeln den gewünschten Bot? Sind für das Verständnis notwendige Ressourcen erreichbar? Eine Sitemap kann bei der Entdeckung helfen, ersetzt aber keinen funktionierenden Seitenweg.

robots.txt ist dabei weder Zugriffsschutz noch verlässliches Mittel, um eine URL aus Suchergebnissen zu halten. Eine gesperrte Adresse kann über externe Verweise bekannt werden, obwohl ihr Inhalt nicht abgerufen wird.

Rendering: Ist der Hauptinhalt tatsächlich vorhanden?

Nach dem Abruf muss aus HTML, CSS, JavaScript und Medien eine interpretierbare Seite entstehen. Bei clientseitigen Anwendungen können fehlgeschlagene Skripte, blockierte Ressourcen oder verspätete Daten dazu führen, dass die sichtbare und maschinenlesbare Fassung auseinanderfallen.

Robust ist eine progressive Basis: zentrale Antwort, Überschriften, Links und Metadaten stehen im ausgelieferten HTML. JavaScript verbessert Suche oder Interaktion, ohne den Inhalt erst freizuschalten.

Indexierung: Soll und kann diese Fassung aufgenommen werden?

Eine gerenderte Seite kann trotzdem von der Indexierung ausgeschlossen sein, etwa durch noindex. Sie kann als Duplikat einer anderen kanonischen URL eingeordnet werden oder wegen fehlender Eigenständigkeit nicht als relevante Suchseite dienen.

Canonical, interne Links und Sitemap sollten dieselbe bevorzugte URL nennen. Trotzdem bleiben Crawling, Indexierung und spätere Ausspielung Entscheidungen des Suchsystems; technische Korrektheit ist keine Aufnahmegarantie.

Die Diagnose in der richtigen Reihenfolge.

1. Abruf: URL, Statuscode, robots-Regeln und interne Links prüfen. 2. Darstellung: ausgeliefertes und gerendertes HTML vergleichen. 3. Signale: noindex, Canonical und Sitemap abgleichen. 4. Suchsystem: verfügbare Inspektions- und Indexierungsdaten einordnen.

Erst danach wird der Inhalt bewertet: beantwortet die Seite eine eigenständige Frage, ist sie intern sinnvoll eingebunden und entspricht das Markup den sichtbaren Aussagen?

Was ein einzelner Test nicht beweist.

Ein erfolgreicher HTTP-Abruf beweist kein korrektes Rendering. Eine gerenderte Vorschau beweist keine Indexierung. Eine indexierte URL beweist keine Sichtbarkeit für eine konkrete Anfrage.

Der Abschluss einer Diagnose benennt deshalb Stufe, Befund, Beleg, empfohlene Änderung und verbleibende Unsicherheit. So wird aus einer Fehlermeldung eine überprüfbare Entscheidung.

Arbeitsmittel

Diagnosematrix

BeobachtungWahrscheinliche StufeNächster Check
URL liefert Fehler oder leitet unerwartet umBetrieb oder CrawlingStatus, Zielhost, Weiterleitungsziel und interne Links
Inhalt ist nur nach Anmeldung sichtbarZugriffsschutzZweck und geprüfte Umgebung klären; Schutz nicht pauschal entfernen
HTML enthält die zentrale Antwort nicht zuverlässigRenderingAusgeliefertes HTML, No-JS, Ressourcen und Browserkonsole
Freigegebene Seite enthält noindexIndexierungUrsprung, betroffene Vorlagen und tatsächlichen Freigabeumfang prüfen
Andere kanonische URL wird gewähltIndexierungInhalt, Canonical, interne Links und Sitemap gemeinsam prüfen
Seite ist indexiert, passt aber nicht zur SuchaufgabeRelevanzSuchfragen, Leistungsversprechen und Informationslücken vergleichen
Viele Seiten verlieren gleichzeitigÜbergreifender AnlassVeröffentlichungsprotokoll, Technik, Zeitraum und Nachfrage vergleichen