# Was ein System tatsächlich abrufen und verstehen kann

Eine im Browser sichtbare Seite ist nicht automatisch für jeden Client gleich zugänglich. Prüfe Status, Header, Weiterleitungen, ursprüngliches HTML und gerenderte Ansicht an der öffentlichen URL.

## Die kurze Antwort

Prüfe die öffentliche URL als vollständige Anfrage-Antwort-Kette. Dokumentiere Statuscodes, Weiterleitungen, Header, Inhaltstyp und den Inhalt des ursprünglichen HTML. Vergleiche ihn erst danach mit der gerenderten Ansicht. Eine Sitemap hilft bei der Entdeckung, repariert aber weder Zugriff noch Auslieferung und garantiert keine Indexierung.

Öffne eine veröffentlichte Seite nicht zuerst als Leser, sondern betrachte sie wie ein unbekannter technischer Client.

Dieser Client kennt deine Navigation nicht, akzeptiert möglicherweise keine Cookies, besitzt keine Sitzung und führt JavaScript nicht zwingend aus. Er sendet eine Anfrage an eine URL und bewertet die erhaltene Antwort. Was intern im CMS gespeichert ist, zählt nur, wenn es tatsächlich ausgeliefert wird.

## Die Anfrage-Antwort-Kette beobachten

HTTP ist das grundlegende Anfrage-Antwort-Protokoll des Webs. Zwischen Client und CMS können Domainauflösung, Content Delivery Network, Schutzsystem, Reverse Proxy und Anwendung liegen. Jede Station kann Statuscodes, Weiterleitungen, Caching oder Zugriffsregeln beeinflussen. Gemessen wird deshalb an der öffentlichen URL.

| Status | Grundbedeutung | Prüffrage |
|---|---|---|
| `2xx` | Anfrage verarbeitet | Wurde der erwartete Inhalt geliefert? |
| `3xx` | Weiterleitung | Wohin führt sie, und ist sie dauerhaft? |
| `4xx` | Ressource nicht verfügbar | Ist die URL falsch, entfernt oder geschützt? |
| `5xx` | Serverfehler | Ist die Störung vorübergehend oder anhaltend? |

`200 OK` bedeutet nicht automatisch, dass die richtige Seite geliefert wurde. Auch eine leere Seite, Login-Maske oder Fehlermeldung kann fälschlich mit `200` antworten.

## Jeder Weiterleitung folgen

Prüfe nicht nur das Endziel, sondern die gesamte Kette:

```text
angeforderte URL
  -> 301
neue URL
  -> 200
HTML-Inhalt
```

Das Ziel muss sachlich passen, ohne Schleife oder unnötige Zwischenstation erreichbar sein und mit Canonical sowie internen Links übereinstimmen. `301` und `308` kennzeichnen eine dauerhafte Verschiebung; `302`, `303` und `307` verschiedene vorübergehende Situationen.

## Header und Inhaltstyp lesen

Wichtige Antwort-Header sind `Content-Type`, `Location`, `X-Robots-Tag`, ein möglicher `Link`-Header mit `rel="canonical"` sowie Caching-Angaben wie `ETag` oder `Last-Modified`.

Eine HTML-Seite sollte als HTML ausgeliefert werden. PDF-Dateien und andere Ressourcen können keine HTML-Meta-Tags enthalten; ein `noindex` muss dort bei Bedarf über `X-Robots-Tag` übertragen werden.

## Ursprüngliches HTML und Rendering trennen

**HTML-first** bedeutet, dass Hauptinhalt, Überschriften, Seitentitel, zentrale Metadaten, kanonische URL, Indexierungsregeln und interne Links schon in der HTTP-Antwort vorhanden sind.

JavaScript darf Interaktionen ergänzen. Die Kernaussage sollte aber nicht unnötig davon abhängen, dass ein Client Skripte und weitere Datenquellen erreicht.

| Ansicht | Beobachtung |
|---|---|
| Ursprüngliche HTTP-Antwort | Was steht im empfangenen HTML? |
| Gerenderte Ansicht | Was erscheint nach JavaScript im Document Object Model? |

Google kann JavaScript rendern. Andere Crawler verarbeiten es anders oder gar nicht.

## Die Sitemap als Entdeckungssignal einordnen

Eine XML-Sitemap hilft bei der Entdeckung wichtiger URLs. Sie hebt keine `robots.txt`-Sperre auf, überschreibt kein `noindex`, repariert keine Fehlerantwort und ersetzt keine internen Links. Führe bevorzugt kanonische, erfolgreiche und für die Suche vorgesehene URLs auf.

**Plattformstand vom 17. August 2026:** Auch ein `200` garantiert keine Indexierung. Dauerhafte Weiterleitungen gelten bei Google als starkes Signal für das Ziel. Google kann JavaScript rendern, weist aber weiterhin auf serverseitig ausgeliefertes oder vorgerendertes HTML hin. Sitemaps sind Hinweise, keine Zusagen.

## Dein nächster Arbeitsschritt

Führe für eine kanonische URL ein Auslieferungsprotokoll: Prüfzeitpunkt und Umgebung, angeforderte und endgültige URL, Status- und Weiterleitungskette, Content-Type, X-Robots-Tag, Canonical, Caching-Angaben, Kernaussage und Links im ursprünglichen HTML, Unterschiede nach dem Rendering, Sitemap-Eintrag, eingehender interner Link, offene Abweichungen und verantwortliche Person.

## Quellen und Vertiefung

- [RFC 9110](https://www.rfc-editor.org/rfc/rfc9110) — IETF: Semantik von HTTP-Anfragen, Antworten und Statuscodes.
- [Quelle bei Google](https://developers.google.com/crawling/docs/troubleshooting/http-status-codes) — Google Crawling Infrastructure: Verarbeitung von Statuscodes.
- [Quelle bei Google](https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics) — Google Search Central: Crawling, Rendering und HTML-Auslieferung.
- [Quelle bei Google](https://developers.google.com/search/docs/crawling-indexing/sitemaps/overview) — Google Search Central: Sitemaps als Hinweis zur Entdeckung.

## Hinweis

Die Plattformangaben geben den dokumentierten Stand vom 17. August 2026 wieder. Sie können sich ändern; Indexierung, Ranking oder Nennung werden nicht garantiert.