Wie eine Suchmaschine (und eine KI) Ihre Seite liest

Eine Suchmaschine und eine generative KI „betrachten" Ihre Seite nicht wie ein menschlicher Besucher. Sie rufen einen HTML-Stream ab, wandeln ihn (oder auch nicht) in eine Datenstruktur namens DOM um und extrahieren daraus reinen Text, den sie in Blöcke zerlegen, um ihn zu indexieren oder als Antwort zu verwenden. Dieses Verständnis des Ablaufs verändert ganz konkret, wie Sie Ihre Seiten schreiben und strukturieren sollten.

Der Weg vom rohen HTML zum Rendering

Besucht ein Crawler eine URL, erhält er zunächst eine HTTP-Antwort mit dem rohen HTML, das Ihr Server sendet, noch vor jeglicher JavaScript-Ausführung. Genau dieses ursprüngliche HTML analysieren die meisten Bots vorrangig, denn die vollständige Ausführung (das „Rendering") kostet Rechenzeit und Speicher – multipliziert mit Milliarden täglich gecrawlter Seiten.

Google kann JavaScript in einem zweiten Schritt rendern, über eine separate Warteschlange, die je nach aktueller Auslastung und der Ihrer Website zugewiesenen Priorität von wenigen Sekunden bis zu mehreren Tagen dauern kann. Mit anderen Worten: Es gibt eine mitunter erhebliche Verzögerung zwischen dem Moment, in dem Ihr rohes HTML gelesen wird, und dem Moment, in dem sein vollständiges Rendering (nach JavaScript-Ausführung) berücksichtigt wird. Crawler generativer KI (insbesondere ChatGPT, Claude, Perplexity) sind in diesem Punkt in der Regel eingeschränkter: Sie stützen sich beobachtbar stärker auf statisches HTML oder auf bereits von Drittsuchmaschinen indexierte Versionen als auf ein vollständiges, bei jedem Besuch systematisches JavaScript-Rendering.

Dieser Unterschied in der Verarbeitung erklärt, warum zwei Tools ein unterschiedliches Bild derselben Seite haben können: Das eine hat möglicherweise das vollständige Rendering abgewartet, das andere nicht.

Was ein Crawler sieht vs. was ein Browser sieht

Ein Browser führt CSS und JavaScript aus, lädt Schriftarten, wendet Animationen an und zeigt ein vollständiges visuelles Rendering, Pixel für Pixel. Ein Crawler „sieht" nichts Visuelles: Er verarbeitet eine Zeichenkette (das HTML) und, gegebenenfalls, eine daraus aufgebaute Baumstruktur.

Existiert ein Inhalt konkret nur visuell – eine Information, die ausschließlich in einem Bild ohne Alt-Text kodiert ist, ein durch eine CSS-Animation erzeugter Text, ein erst nach einem Nutzerklick eingefügter Inhalt, ein Tooltip, der nur beim Hover erscheint –, ist es wahrscheinlich, dass kein Bot ihn jemals als verwertbaren Text wahrnimmt. Nicht, weil er ihn absichtlich ignoriert: Er hat schlicht keine Möglichkeit, die menschliche Interaktion nachzubilden, die sein Erscheinen auslöst.

Das DOM und die Textextraktion

Das DOM (Document Object Model) ist die Baumdarstellung des HTML: Jedes Tag wird zu einem „Knoten" mit Eltern, Kindern und Attributen. Aus dieser Baumstruktur extrahieren Suchmaschinen und KI-Systeme den nutzbaren Text, wobei sie sich insbesondere stützen auf:

die Tag-Hierarchie (<header>, <nav>, <main>, <article>, <footer>), um Hauptinhalt von Randelementen zu unterscheiden;
Überschrifts-Tags (<h1> bis <h6>), um die logische Struktur des Inhalts zu erkennen;
die Reihenfolge des HTML im Dokument (nicht die durch CSS bestimmte visuelle Reihenfolge).

Ein oft übersehener Punkt: Nutzen Sie position: absolute oder flex-direction: row-reverse, um Blöcke visuell umzuordnen, bleibt die von der Maschine gelesene Reihenfolge die des Quellcodes, nicht die auf dem Bildschirm angezeigte. Ein Absatz, der im HTML zuletzt steht, aber per CSS visuell an den Seitenanfang verschoben wird, wird von den meisten Extraktionssystemen weiterhin als letzter Inhaltsblock behandelt – was die von einem automatisierten Leser wahrgenommene logische Struktur verfälschen kann.

JavaScript: die Falle des unsichtbaren Inhalts

Websites, die clientseitig mit JavaScript aufgebaut sind (manche React-, Vue- oder Angular-Anwendungen ohne serverseitiges Rendering), bergen ein reales Risiko: Erscheint der Textinhalt erst nach Ausführung des Skripts, und führt der besuchende Bot dieses nicht oder nur teilweise aus, fehlt dieser Inhalt schlicht in dem, was indexiert wird. Das Risiko ist besonders hoch bei verzögert geladenen Blöcken (aggressives Lazy Loading), bei Inhalten hinter einem standardmäßig geschlossenen Tab oder bei Daten, die über einen asynchronen API-Aufruf nach dem initialen Laden der Seite eingefügt werden.

Um dieses Risiko zu begrenzen, gibt es mehrere Ansätze:

<!-- Serverseitiges Rendering (SSR): Das initiale HTML enthält den Text bereits -->
<article>
  <h1>Überschrift, sofort im HTML-Quellcode sichtbar</h1>
  <p>Dieser Absatz ist vorhanden, noch bevor JS ausgeführt wird.</p>
</article>

SSR (serverseitiges Rendering), statisches Rendering (SSG) oder progressive Hydration stellen sicher, dass der wesentliche Text bereits in der ersten HTTP-Antwort vorhanden ist, ohne von der JavaScript-Ausführung durch den besuchenden Bot abzuhängen. Diese Ansätze sind keine bloßen technischen Optionen für Entwickler: Sie wirken sich direkt auf die Sichtbarkeit Ihres Inhalts für jedes automatisierte System aus, ob klassische Suchmaschine oder generative KI, die das Web durchsucht, um eine Antwort zu erstellen.

Was das konkret für Ihren Inhalt bedeutet

Drei direkte Konsequenzen für das Schreiben und die Integration Ihrer Seiten:

Wichtiger Textinhalt (Argumente, Antworten auf Fragen, Zahlen) muss im rohen HTML vorhanden sein, nicht nur nach einer Interaktion oder Animation.
Die Struktur des Quellcodes sollte die logische Lesereihenfolge widerspiegeln, unabhängig von der durch CSS bestimmten visuellen Formatierung.
Ein klares semantisches Markup hilft, den Hauptinhalt von Rauschen (Menüs, Werbung, sich wiederholende Footer) zu trennen – ein Punkt, der in der Lektion zu semantischem HTML5 vertieft wird.

Um konkret zu überprüfen, was ein Bot lesen kann, vergleichen Sie das von Ihrem Server zurückgegebene rohe HTML (Rechtsklick → „Seitenquelltext anzeigen", nicht der Inspector, der das DOM nach dem Rendering zeigt) mit dem, was auf dem Bildschirm angezeigt wird. Jede nennenswerte Abweichung – ein visuell vorhandener Textblock, der im Quellcode fehlt – ist ein Signal, das vorrangig behoben werden sollte.

Diese Frage nach dem technischen Weg des Inhalts führt direkt zu zwei Themen des nächsten Moduls: wie ein LLM Ihren Inhalt in Blöcke zerlegt, sobald der Text extrahiert ist, und wie Sie den Zugriff von Crawlern über die robots.txt-Datei steuern.