Wie moderne Websites gebaut und ausgeliefert werden — und was Maschinen davon sehen

• HTML

  Beschreibt Inhalt und Struktur.

  Überschriften, Absätze, Links, Bilder, Formulare. Der HTML-Standard beschreibt, wie ein Dokument beim Verarbeiten in einen Baum aus Knoten überführt wird — diesen Baum sieht ein Browser, und auf ihn greift alles zu, was danach kommt.

• CSS

  Bestimmt Darstellung und Layout.

  CSS entscheidet, wie Inhalte angeordnet, sichtbar und bedienbar erscheinen. Es ersetzt keine inhaltliche Struktur: Was optisch wie eine Überschrift aussieht, ist deshalb noch keine.

• JavaScript

  Fügt Verhalten hinzu und kann den Dokumentbaum verändern.

  Daten nachladen, Elemente einblenden, Eingaben prüfen — normal für eine interaktive Website. Kritisch wird die Abhängigkeit erst, wenn geschäftlich wichtige Informationen oder Wege ausschließlich auf diesem Weg entstehen und der jeweilige Empfänger ihn nicht ausführt.

• TypeScript

  Ist ein Entwicklungswerkzeug, kein Auslieferungsmerkmal.

  Die offizielle TypeScript-Dokumentation beschreibt TypeScript als JavaScript mit einer Syntax für Typen und hält fest, dass TypeScript-Code zu JavaScript wird, das überall läuft, wo JavaScript läuft. Im Browser kommt also JavaScript an. „Wir setzen TypeScript ein“ sagt deshalb etwas über die Arbeitsweise im Projekt und nichts darüber, was eine Adresse ausliefert.

Tabelle seitlich verschiebbar

Werkzeug	Was es ist	Welche Auslieferungswege die eigene Dokumentation nennt
React	Bibliothek für Oberflächen aus Komponenten	Beschreibt unter anderem das Anhängen an bereits serverseitig erzeugtes HTML sowie Server Components als eigenes Ausführungsmodell.
Next.js	Framework auf React-Basis	Trennt im App Router Server- und Client-Komponenten. Nach eigener Beschreibung werden Client-Komponenten zusammen mit den Serverdaten zu HTML vorgerendert; beim ersten Aufruf zeigt dieses HTML die Seite zunächst ohne Interaktivität.
Vue / Nuxt	Komponentenansatz und Framework darüber	Nuxt beschreibt clientseitiges Rendering, universelles Rendering mit vollständig erzeugtem HTML und hybrides Rendering mit unterschiedlichen Regeln je Route.
Svelte / SvelteKit	Komponentenansatz und Framework darüber	SvelteKit dokumentiert die Optionen für Vorab-Erzeugung, Server-Rendering und Client-Rendering je Route. Ist das Server-Rendering abgeschaltet, wird laut Dokumentation eine leere Hülle ausgeliefert.
Angular	umfangreiches Anwendungs-Framework	Dokumentiert Server-Rendering je Anfrage, Vorab-Erzeugung zur Bauzeit und clientseitiges Rendering als drei wählbare Modi der Server-Routenkonfiguration.
Astro	inhaltsorientiertes Framework	Erzeugt Komponenten nach eigener Beschreibung standardmäßig zu HTML und CSS und entfernt clientseitiges JavaScript automatisch; Interaktivität wird je Komponente ausdrücklich angefordert.
WordPress / PHP	Redaktionssystem mit serverseitigem Stack	Beschreibt Templates als Bausteine der Dokumentstruktur; deren Auszeichnung wird ausgewertet, und WordPress gibt das entstehende HTML an den Browser aus. Themes, Erweiterungen und Kopflos-Setups verschieben das Bild erheblich.

• Vorab erzeugt

  Die Seite existiert schon, bevor jemand sie abruft.

  Zentrale Inhalte liegen beim Abruf bereits als HTML vor. JavaScript kann danach Bedienung ergänzen, muss den Inhalt aber nicht erst herstellen. Angular nennt diesen Weg Vorab-Erzeugung zur Bauzeit, SvelteKit führt ihn als Routenoption.

• Auf dem Server erzeugt

  Die Seite entsteht beim Abruf — auf dem Server.

  Auch hier kann bereits ein inhaltlich sinnvolles Dokument beim Empfänger ankommen. Nuxt beschreibt für dieses Modell eine vollständig erzeugte HTML-Seite. Dynamisch erzeugt heißt also nicht automatisch clientabhängig.

• Im Browser erzeugt

  Der erste Abruf liefert eine Hülle, der Inhalt folgt.

  Nuxt beschreibt für dieses Modell, dass die Elemente erst entstehen, nachdem der Browser den JavaScript-Code geladen und ausgewertet hat; SvelteKit spricht bei abgeschaltetem Server-Rendering von einer leeren Hülle. Für Anwendungen kann das richtig sein — für genau diese Inhalte entsteht aber eine zusätzliche Abhängigkeit vom Clientpfad.

• Gemischt

  Verschiedene Teile derselben Website nehmen verschiedene Wege.

  Der realistische Normalfall. Nuxt beschreibt hybrides Rendering ausdrücklich als eigene Regeln je Route; Angular fasst Server-, Vorab- und Client-Erzeugung unter einem gemeinsamen Begriff. Eine Leistungsseite kann ihren Text direkt liefern, während Terminplaner, Filter oder Konfigurator erst im Browser interaktiv werden.

Die React-Dokumentation beschreibt Hydration als das Anhängen an bereits vorhandenes HTML, das zuvor in einer Serverumgebung erzeugt wurde; React übernimmt danach die Verwaltung dieses Bereichs. Die Next.js-Dokumentation formuliert denselben Vorgang aus der anderen Richtung: Hydration ist der Prozess, mit dem React Ereignisbehandlungen an das Dokument hängt, um das statische HTML interaktiv zu machen. Nuxt beschreibt für sein universelles Rendering denselben Schritt und nennt als Ergebnis dynamische Oberflächen und Seitenübergänge.

Für die Praxis heißt das: Das Dokument kann bereits sichtbar und lesbar sein, bevor irgendetwas interaktiv ist. Was danach passiert, ist eine Ergänzung, keine Erzeugung.

Nach Googles eigener Darstellung durchläuft eine Seite mit JavaScript drei Phasen: Abruf, Rendern und Indexierung. Seiten mit dem Statuscode HTTP 200 stellt Google für das Rendern in eine Warteschlange, sofern keine Robots-Angabe die Indexierung untersagt. Dort kann eine Seite nach derselben Quelle einige Sekunden stehen, es kann aber auch länger dauern; erst wenn die Ressourcen es zulassen, rendert ein Chromium ohne Oberfläche die Seite und führt das JavaScript aus. Das gerenderte HTML nutzt Google anschließend ebenfalls für die Indexierung.

Im selben Dokument steht der Satz, auf den es hier ankommt: Server-seitiges oder vorab erzeugtes Rendering sei weiterhin eine gute Idee, weil es die Website für Nutzer und Crawler schneller mache — und weil nicht alle Bots JavaScript ausführen können. Das ist eine Aussage über die Bandbreite der Empfänger, nicht über Rangfolgen.

OpenAI führt in der eigenen Übersicht mehrere getrennte Zugriffe auf: einen für das Erscheinen in den Suchergebnissen von ChatGPT, einen für das Training generativer Modelle, einen für die Prüfung eingereichter Anzeigenseiten und einen für nutzerausgelöste Abrufe. Zum letzten hält dieselbe Seite ausdrücklich fest, dass er nicht dem automatischen Durchsuchen des Netzes dient und dass die Regeln der robots.txt für solche vom Nutzer angestoßenen Vorgänge möglicherweise nicht gelten. Damit ist die Vorstellung einer einzigen „KI-Sicht“ auf eine Website bereits widerlegt.

Nicht widerlegt und nicht belegt ist die Gegenrichtung. Eine vollständige Rendering-Spezifikation je Abrufweg steht in diesen Dokumenten nicht. Deshalb schreibt Pixelkiez nicht „KI-Crawler führen kein JavaScript aus“ — dieser Satz behauptet über alle Anbieter und alle Zugriffe hinweg etwas, das keine der hier genannten Quellen sagt. Umgekehrt gilt genauso: Dass ein Inhalt nach der JavaScript-Ausführung im Dokumentbaum steht, belegt nicht, dass ein bestimmtes System ihn dort auch vorfindet.

Was bleibt, ist ein Vorgehen statt einer Behauptung:

• 01

  Anbieter und Zugriff benennen.

  Nicht „die KI“, sondern der konkrete Zugriff mit seiner Kennung. Erst damit lässt sich überhaupt eine Dokumentation aufschlagen.

• 02

  Aktuelle Dokumentation und eigene Regeln prüfen.

  Was der Anbieter heute beschreibt, und was robots.txt sowie vorgeschaltete Schutzsysteme auf der eigenen Seite tatsächlich zulassen.

• 03

  Den tatsächlichen Abruf beobachten.

  Im Serverprotokoll oder mit einem wiederholbaren Test. Eine Beobachtung ist an ihr Datum gebunden — sie ersetzt keine Zusage und wird durch keine ersetzt.

Manche Automationswege arbeiten über die Semantik der Oberfläche. Playwright dokumentiert, dass sich Elemente über Rolle, Beschriftung und zugänglichen Namen ansprechen lassen, und beschreibt eigene Prüfungen, ob ein Element sichtbar, stabil, aktiv und für Ereignisse erreichbar ist. Die Grundlage dafür — Rollen, Zustände und zugängliche Namen — ist bei der W3C-Arbeitsgruppe für Barrierefreiheit beschrieben und war nie für Agenten gedacht, sondern für assistive Technik.

Andere Wege sehen die Seite so, wie ein Mensch sie sieht: Anbieter dokumentieren Systeme, die über Bildschirmfotos, Maus und Tastatur arbeiten. Für eine Website heißt das, dass semantische Links, echte Schaltflächen, beschriftete Formularfelder, stabile Bedienung und ein eindeutig lesbarer Erfolgs- oder Fehlerzustand eine robuste Grundlage sind — eine Grundlage, keine Garantie. Barrierefreiheit unterstützt bestimmte Automationswege; sie ist nicht dasselbe wie Agentenkompatibilität.

Was daraus für die Reifestufen einer Website folgt, steht ausführlich im Beitrag Agent-Readiness: Kann eine KI Ihre Website benutzen? — hier geht es nur um den Zusammenhang zur Auslieferung: Was erst nach erfolgreicher Client-Ausführung existiert, existiert für einen Agenten erst danach.

Der Frameworkname unterscheidet die beiden nicht. Geprüft werden muss die konkrete Route und ihr tatsächliches Verhalten.

Dabei hilft eine Genauigkeit, die oft untergeht: Die Angabe use client ist nicht gleichbedeutend mit „es gibt kein initiales HTML“. Die Next.js-Dokumentation beschreibt sie als Grenze zwischen Server- und Clientteil des Projekts und hält fest, dass Client-Komponenten zusammen mit den Serverdaten zu HTML vorgerendert werden; beim ersten Aufruf zeigt dieses HTML die Seite unmittelbar, zunächst ohne Interaktivität. Für Navigationen innerhalb der laufenden Anwendung beschreibt dieselbe Quelle es anders: Dort werden Client-Komponenten vollständig im Browser erzeugt, ohne servergeneriertes HTML.

1. Stehen Name, Leistung, Standort und die zentralen Aussagen im Dokument, das der direkte Abruf zurückgibt?
2. Sind interne Verweise und Kontaktwege echte Links — oder Flächen, die erst ein Skript bedienbar macht?
3. Ist im Projekt bekannt und dokumentiert, welche Inhalte erst durch JavaScript entstehen?
4. Bleibt die Seite verständlich, wenn ein Teil davon nicht lädt?
5. Sind Bedienelemente semantisch ausgezeichnet und beschriftet, statt nur optisch als Schaltfläche gestaltet?
6. Lässt sich nach einer wichtigen Handlung ein eindeutiger Erfolg oder Fehler lesen?
7. Ist die tatsächliche Auslieferung geprüft — oder aus dem Frameworknamen abgeleitet?

Google Search Central

Google beschreibt die drei Phasen Abruf, Rendern und Indexierung, die Warteschlange vor dem Rendern und weist darauf hin, dass nicht alle Bots JavaScript ausführen können.

Understand the JavaScript SEO basics Abgerufen am 4. September 2026

React

Die React-Dokumentation erklärt Hydration als das Anhängen von React an bereits serverseitig erzeugtes HTML und beschreibt, wie React anschließend die Verwaltung dieses Bereichs übernimmt.

React — hydrateRoot Abgerufen am 4. September 2026

Next.js

Next.js dokumentiert die Trennung von Server- und Client-Komponenten, das Vorrendern zu HTML, die zunächst nicht interaktive erste Ansicht und die abweichende Behandlung späterer Navigationen.

Next.js — Server and Client Components Dokumentstand 25. August 2026, abgerufen am 4. September 2026

Nuxt

Nuxt dokumentiert clientseitiges Rendering, universelles Rendering mit vollständig erzeugtem HTML und hybrides Rendering mit unterschiedlichen Regeln je Route.

Nuxt — Rendering Modes Abgerufen am 4. September 2026

SvelteKit

SvelteKit dokumentiert Routenoptionen für Vorab-Erzeugung, Server- und Client-Rendering sowie die leere Hülle bei abgeschaltetem Server-Rendering.

SvelteKit — Page options Abgerufen am 4. September 2026

Angular

Angular beschreibt Server-Rendering, Vorab-Erzeugung und clientseitiges Rendering als drei wählbare Modi.

Angular — Server-side and hybrid rendering Abgerufen am 4. September 2026

Astro

Astro beschreibt, dass Komponenten standardmäßig zu HTML und CSS erzeugt werden, clientseitiges JavaScript dabei entfernt wird und Interaktivität gezielt je Komponente angefordert werden kann.

Astro — Islands architecture Abgerufen am 4. September 2026

TypeScript

Die TypeScript-Projektseite beschreibt TypeScript als JavaScript mit einer Syntax für Typen und erklärt, dass TypeScript-Code zu JavaScript wird, das überall läuft, wo JavaScript läuft.

TypeScript — offizielle Projektseite Abgerufen am 4. September 2026

WordPress

Die WordPress-Dokumentation beschreibt Templates als Teil der Dokumentstruktur und erklärt, wie aus ihrer Auszeichnung HTML entsteht, das an den Browser ausgeliefert wird.

WordPress — Templates Abgerufen am 4. September 2026

OpenAI

OpenAI unterscheidet mehrere Zugriffe mit unterschiedlichen Zwecken und weist darauf hin, dass die Regeln der robots.txt für nutzerausgelöste Vorgänge möglicherweise nicht gelten.

Overview of OpenAI Crawlers Abgerufen am 4. September 2026

Playwright

Playwright dokumentiert das Ansprechen von Elementen über Rolle, Beschriftung und zugänglichen Namen sowie die Prüfungen, die vor einer Handlung stattfinden.

Playwright — Locators Abgerufen am 4. September 2026

W3C — Web Accessibility Initiative

Die W3C-Dokumentation definiert Rollen, Zustände und zugängliche Namen als Semantik für assistive Technik.

Accessible Names and Descriptions Abgerufen am 4. September 2026

Stand dieses Beitrags: 4. September 2026. Framework-Dokumentationen ändern sich mit ihren Versionen, Anbieterangaben zu Abrufwegen können sich ohne Ankündigung ändern. Wo dieser Beitrag ein Verhalten beschreibt, beschreibt er das dokumentierte Verhalten zu diesem Datum.