Ist WordPress oder ein modernes Framework besser für Google und KI?

Am Werkzeug lässt sich das nicht ablesen. Fast alle Frameworks bieten mehrere Auslieferungswege, und mit demselben Framework kann eine Seite vollständig oder als fast leerer Rahmen ankommen. Aussagen wie „Astro rankt besser“ finden in den verwendeten Quellen keine Stütze; entscheidend ist, was eine bestimmte Adresse tatsächlich ausliefert.

Kann Google Inhalte lesen, die erst durch JavaScript entstehen?

Ja, Google führt JavaScript nach eigenen Angaben mit Chromium aus, empfiehlt aber trotzdem Server-Rendering oder Vorab-Erzeugung, weil die Seite schneller wird und nicht jeder Bot JavaScript ausführt. Bessere Platzierungen folgen daraus nicht. Belastbar ist nur, dass Inhalte im ersten Dokument auch Systemen offenstehen, die den Browserschritt auslassen.

Wie finde ich heraus, was meine Seite beim ersten Abruf ausliefert?

Betrachten Sie das Dokument, das beim direkten Abruf einer Adresse zurückkommt, statt sich durch die Seite zu klicken. Stehen Unternehmensname, Leistung, Ort und Kontaktweg schon darin, und sind Verweise echte Links? Aus dem Namen des Frameworks lässt sich das nicht schließen.

Website-Auslieferung: Was beim ersten Abruf ankommt

Q: Was bedeutet Hydration, und schadet sie meiner Auffindbarkeit?

Hydration verbindet bereits vorhandenes HTML nachträglich mit JavaScript, damit etwa Filter oder Terminauswahl bedienbar werden. Eine Seite kann also lesbar sein, bevor sie auf Klicks reagiert. Ein Vor- oder Nachteil für die Auffindbarkeit ist das nicht; entscheidend ist, was vor diesem Schritt schon im Dokument steht.

Vier Begriffe, vier Aufgaben

In Projektbeschreibungen tauchen fast immer dieselben Schlagworte auf, die aber Unterschiedliches bezeichnen.

HTML trägt Inhalt und Gliederung: Überschriften, Absätze, Links, Bilder, Eingabefelder. Der Browser macht daraus einen Baum aus Knoten, auf dem alles Weitere aufsetzt.
CSS regelt Anordnung und Aussehen, schafft aber keine Struktur: Groß gesetzter Text wird dadurch nicht zur Überschrift.
JavaScript ergänzt Verhalten und kann das Dokument nachträglich verändern. Heikel wird das erst, wenn geschäftlich wichtige Angaben nur so zustande kommen und ein Empfänger das Skript nicht ausführt.
TypeScript dient der Entwicklung und wird laut offizieller Projektseite zu JavaScript übersetzt. Im Browser landet also JavaScript; TypeScript beschreibt die Arbeitsweise des Teams, nicht die ausgelieferte Seite.

Was ein Frameworkname offenlässt

React, Vue und Svelte sind Komponentenansätze, auf denen Next.js, Nuxt und SvelteKit aufbauen; daneben stehen Angular, Astro und WordPress. Fast alle dokumentieren mehrere Auslieferungswege: Next.js trennt Server- und Client-Komponenten, Nuxt kennt Rendering im Browser sowie universelles und hybrides Rendering, SvelteKit und Angular lassen den Weg je Route festlegen. Astro erzeugt nach eigener Darstellung standardmäßig HTML und CSS ohne clientseitiges JavaScript. WordPress setzt Templates zu HTML zusammen, wobei Themes, Erweiterungen oder ein kopfloser Aufbau viel verändern können.

Welchen Weg ein Projekt für eine einzelne Seite gewählt hat, verrät keine dieser Dokumentationen. Eine Rangfolge folgt daraus ebenfalls nicht: Sätze wie „Astro rankt besser“ finden in den verwendeten Quellen keine Stütze.

Vier Wege vom Projekt zum Empfänger

Genauer als „Welches Rendering hat die Website?“ ist die Frage, auf welchem Weg welcher Teil einer Seite ankommt: vorab erzeugt, serverseitig bei der Anfrage, erst im Browser oder, im üblichen Fall, gemischt.

Hydration: Bedienung kommt nachträglich dazu

Hydration meint einen einzigen Schritt: Bereits vorhandenes HTML wird mit JavaScript verbunden. Die React-Dokumentation beschreibt, wie React sich an serverseitig erzeugtes HTML hängt und diesen Bereich danach verwaltet. Bei Next.js heißt es, React binde Ereignisbehandlungen an das Dokument und mache das statische HTML so interaktiv.

Eine Seite kann also lesbar sein, bevor sie auf Klicks reagiert. Unternehmensname, Leistungen, Standort, erläuternde Texte, interne Links und Kontaktweg können schon vorher im Dokument stehen; Terminauswahl, Filter oder aufklappende Bereiche werden typischerweise erst danach aktiv. Hydration ist damit weder Vorteil noch Nachteil für die Auffindbarkeit. Entscheidend ist, was vor diesem Schritt vorliegt und welche Empfänger ihn überhaupt ausführen.

Wer die Seite abruft und was davon ankommt

Suchmaschinen

Google beschreibt für Seiten mit JavaScript drei Phasen: Crawling, Rendering, Indexierung. Antwortet eine Seite mit Status 200 und verbietet keine Robots-Anweisung das Indexieren, kommt sie in eine Warteschlange fürs Rendering. Dort kann sie nach Googles Angaben ein paar Sekunden oder auch länger bleiben, bis ein Chromium ohne sichtbare Oberfläche das JavaScript ausführt; das Ergebnis fließt ebenfalls in die Indexierung ein.

Trotzdem empfiehlt dieselbe Quelle Server-Rendering oder Vorab-Erzeugung, weil die Website dadurch für Menschen und Crawler schneller werde und nicht jeder Bot JavaScript ausführen könne. Daraus folgt weder, dass Google an JavaScript scheitert, noch dass serverseitig gerenderte Seiten besser platziert werden. Belastbar ist nur: Inhalte im ersten Dokument stehen auch Systemen offen, die den späteren Browserschritt auslassen.

KI-Abrufe

OpenAI nennt in seiner Übersicht mehrere getrennte Zugriffe, unter anderem für die Suche in ChatGPT, fürs Modelltraining und für Abrufe, die eine Person selbst anstößt. Für letztere heißt es dort, sie dienten nicht dem selbstständigen Durchforsten des Netzes, und robots.txt-Regeln würden dafür womöglich nicht greifen. Eine einheitliche „KI-Sicht“ auf Ihre Website gibt es also nicht; mehr dazu im Beitrag Wie KI Websites liest.

Wie die einzelnen Zugriffe eine Seite technisch verarbeiten, ist dort nicht vollständig beschrieben. Die pauschale Behauptung, KI-Systeme könnten grundsätzlich kein JavaScript verarbeiten, stützt keine der genannten Quellen. Umgekehrt heißt ein Inhalt, der nach Ausführung des Skripts im Dokumentbaum steht, noch nicht, dass ein konkretes Abrufsystem ihn zu sehen bekommt. Hilfreicher ist es, den Zugriff samt Kennung zu benennen, Anbieterdokumentation, eigene robots.txt und davor geschaltete Schutzmechanismen zu prüfen und den echten Abruf datiert zu beobachten, etwa in den Server-Logs.

Solange offen ist, welcher Empfänger welchen Weg geht, sollten zentrale öffentliche Angaben nicht ohne Grund an einer unbekannten Fähigkeit des Empfängers hängen. Das betrifft die Verträglichkeit, nicht Platzierungen oder Nennungen in KI-Antworten.

Browser-Agenten

Ein Agent soll auch handeln. Laut Playwright-Dokumentation lassen sich Elemente anhand von Rolle, Beschriftung oder zugänglichem Namen ansprechen; vor einer Aktion wird unter anderem geprüft, ob sie sichtbar, stabil und aktiv sind. Zugängliche Namen, Rollen und Zustände beschreibt die Web Accessibility Initiative des W3C, ursprünglich für assistive Technik. Andere Systeme arbeiten nach Angaben ihrer Anbieter mit Screenshots sowie Maus- und Tastatureingaben.

Echte Links und Schaltflächen, beschriftete Eingabefelder, eine stabile Bedienung und eine klar lesbare Erfolgs- oder Fehlermeldung sind deshalb eine tragfähige Basis, sichern aber kein bestimmtes Ergebnis. Barrierefreiheit hilft manchen Automationswegen, ist jedoch nicht gleichbedeutend mit Agententauglichkeit. Was erst nach erfolgreicher Ausführung im Browser existiert, steht einem Agenten auch erst dann zur Verfügung. Mehr dazu im Beitrag Agent-Readiness.

Ein Framework, zwei sehr verschiedene Seiten

Ein gedachtes Beispiel: Ein Elektrobetrieb aus Berlin-Pankow lässt seine Website zweimal mit Next.js bauen.

Variante 1: Schon die erste Serverantwort enthält den Firmennamen als Überschrift, die Leistung, die Anschrift und einen Kontaktlink. Menü, Filter und Terminauswahl werden danach bedienbar.
Variante 2: Die erste Antwort enthält im wichtigen Bereich nur Anwendungsrahmen, Ladehinweis und Skript. Name, Leistung und Kontaktweg entstehen erst, wenn JavaScript läuft und Daten nachlädt.

Das Framework ist dasselbe; den Unterschied zeigen nur die konkrete Adresse und ihr tatsächliches Verhalten.

Oft missverstanden wird die Angabe use client. Sie bedeutet nicht, dass kein HTML vom Server kommt: Laut Next.js werden auch Client-Komponenten mit den Serverdaten vorab zu HTML gerendert, sodass der erste Aufruf direkt etwas zeigt, nur noch ohne Interaktivität. Bei Navigationen innerhalb der bereits geladenen Anwendung entstehen sie dagegen komplett im Browser. Maschinelle Abrufe treffen in der Regel den ersten Fall. Wer wissen will, was ankommt, sollte deshalb das Dokument betrachten, das beim direkten Abruf der URL zurückkommt, statt sich durch die Seite zu klicken.

Woran Sie es bei Ihrer eigenen Seite erkennen

Entscheidend ist nicht die Wahl zwischen modernem Framework und klassischem Redaktionssystem, sondern was eine bestimmte Adresse ausliefert. Diese Fragen helfen:

Finden sich Unternehmensname, Leistung, Ort und die wichtigsten Aussagen bereits in der Antwort auf den direkten Abruf?
Sind Kontaktwege und Verweise auf andere Unterseiten echte Links, oder werden sie erst durch ein Skript klickbar?
Tragen Buttons und Eingabefelder eine passende Auszeichnung und Beschriftung, oder wirken sie nur optisch wie Bedienelemente?
Ist nach einer wichtigen Aktion klar erkennbar, ob sie geklappt hat?
Wurde die Auslieferung tatsächlich geprüft, oder wird sie nur aus dem Namen des Frameworks geschlossen?

Ein moderner wie ein klassischer Aufbau kann all das gut leisten, und mit beiden lassen sich schwache Lösungen bauen. Die Antwort steht in keinem Angebotstext, sondern in dem, was die Seite tatsächlich ausliefert.

Passende Prüfpunkte in der Analyse

In der Analyse von 360°Pixelkiez sehen wir uns bis zu sechs öffentliche Seiten persönlich an und fassen die Befunde in einem PDF-Bericht mit sieben Seiten zusammen. Zum Thema Auslieferung passen vor allem diese Prüfkriterien der Analyse:

Performance & Technik: Öffentlicher Technologie-Snapshot hält nur fest, was an Hinweisen auf CMS, Frameworks oder Auslieferung öffentlich erkennbar ist. Render-blockierende Ressourcen und Asset-Gewicht & Ressourcenlast betrachten unter anderem JavaScript-Abhängigkeiten und das Gewicht von Skripten.
SEO & Auffindbarkeit: Indexierbarkeit & Canonicals sowie Titles, Metas & Überschriften werden am HTML ausgewählter Seiten geprüft; Interne Verlinkung & Informationsarchitektur betrachtet Navigation und Verweise in einem begrenzten Ausschnitt.
GEO & AI Visibility: Entitätsklarheit und Leistung, Zielgruppe & Standort explizit fragen, ob Unternehmen, Leistungen und Standort klar benannt sind.
UX, Barrierefreiheit & Vertrauen: Semantische Struktur & Landmarks prüft Überschriften, Beschriftungen und HTML-Semantik stichprobenartig, Feedback- & Fehlerzustände betrachtet nur Rückmeldungen, die sicher sichtbar sind.

Welche Prüfpunkte passen, entscheiden wir je Website; nicht jeder Punkt kommt bei jeder Analyse zum Einsatz. Wir sehen uns die Seiten zu einem bestimmten Datum so an, wie sie öffentlich erreichbar sind. Wie sich einzelne Suchmaschinen, KI-Dienste oder Agenten später verhalten, kann eine solche Momentaufnahme nicht vorhersagen.

Was Ihre Website beim ersten Abruf tatsächlich ausliefert