JavaScript-SEO, Mobile-First-Indexierung und agentenlesbare Websites

Direkte Antwort

JavaScript ist nicht von Natur aus schlecht für SEO. Das Risiko entsteht, wenn essenzielle Inhalte, Links, Metadaten oder der Status von Code abhängen, den ein Crawler, Nutzer oder Agent nicht zuverlässig ausführen kann. Serverseitig gerendertes semantisches HTML ist die robusteste Grundlage, weil es Browsern, Crawlern, assistiven Technologien und Agenten schon nützliche Informationen liefert, bevor eine optionale Anreicherung überhaupt läuft.

Um eine JavaScript-Seite zu diagnostizieren, vergleiche die HTTP-Antwort, das gerenderte DOM, die Netzwerkanfragen, das mobile Layout, den Tastaturfluss und den Accessibility-Baum. Prüfe den tatsächlichen Status und das Canonical, bevor du das Framework beurteilst. Eine clientseitig gerenderte Seite kann indexiert werden. Eine SSR-Seite kann trotzdem an falschen Statuscodes, Hydrations-Fehlern, versteckten mobilen Inhalten oder defekten Links scheitern.

Frag nicht „Ist React gut für SEO?" Frag stattdessen „Was kann jeder Beobachter im tatsächlich ausgelieferten Zustand abrufen und bedienen?"

Was du danach kannst

Am Ende dieser Lektion kannst du:

• serverseitiges Rendering, statische Generierung, Hydration, clientseitiges Rendering und Prerendering voneinander unterscheiden;
• Quell-HTML mit dem gerenderten DOM vergleichen;
• fehlgeschlagene Abhängigkeiten, Soft 404s, verspätete Metadaten und nicht crawlbare Navigation diagnostizieren;
• mobile Content-, Metadaten- und Structured-Data-Parität überprüfen;
• Screenshot-, HTML-, DOM- und Accessibility-Baum-Beobachtungen von Agenten einordnen;
• den kleinsten vollständigen Rendering-Fix wählen, statt blind das Framework zu wechseln.

Wie Google JavaScript verarbeitet

Googles Grundlagen zu JavaScript-SEO beschreiben drei grobe Phasen:

1. Crawling;
2. Rendering;
3. Indexierung.

Eine erfolgreiche 200-Seite kann in eine Rendering-Warteschlange gelangen. Rendering kann Inhalte und Links sichtbar machen, die in der initialen Antwort nicht vorhanden waren.

Diese Fähigkeit garantiert nicht, dass jede Abhängigkeit gelingt, dass jeder Crawler JavaScript ausführt oder dass Inhalte, die erst nach einem Klick geladen werden, gefunden werden.

Die Rendering-Muster

Static Site Generation, oder SSG

Seiten werden während eines Builds als HTML erzeugt.

Gut geeignet für:

• redaktionelle Seiten;
• Dokumentation;
• Routen, die sich seltener ändern als Deployments.

Kompromiss:

• große Inventare können Builds teuer machen;
• frische Daten benötigen möglicherweise Revalidierung oder clientseitige Anreicherung.

Server-Side Rendering, oder SSR

Der Server erzeugt HTML für jede Anfrage oder für eine gecachte Anfrage.

Gut geeignet für:

• dynamische öffentliche Routen;
• personalisierte Shells mit öffentlichem Kerninhalt;
• häufig aktualisierte, indexierbare Seiten.

Kompromiss:

• Serverlatenz und -verfügbarkeit;
• Cache-Komplexität;
• Risiko von Mandanten- oder Autorisierungslecks bei falschen Cache-Keys.

Hydration

JavaScript hängt Verhalten an bereits serverseitig gerendertes HTML an.

Gut geeignet für:

• interaktive Steuerelemente auf einem bereits bedeutungsvollen Dokument.

Kompromiss:

• Hydration-Mismatch;
• doppelte Arbeit;
• verzögerte Interaktion;
• hohe Skriptkosten.

Client-Side Rendering, oder CSR

Die initiale Antwort enthält oft nur eine Application-Shell. JavaScript ruft Daten ab und baut die Seite auf.

Gut geeignet für:

• authentifizierte Anwendungen;
• stark interaktive Tools;
• Erlebnisse, bei denen Suchindexierung nicht erforderlich ist.

Kompromiss:

• öffentlicher Inhalt hängt von Skript, API, Authentifizierung und erfolgreichem Rendering ab;
• Fehlerrouten können den falschen Status liefern;
• Crawler außerhalb von Google führen den Code möglicherweise nicht gleich aus.

Prerendering oder dynamisches Rendering

Ein separates System erzeugt fertig gerenderte HTML-Schnappschüsse.

Das kann eine taktische Kompatibilitätsschicht sein, bringt aber zusätzliche Invalidierung, Paritäts-, Cloaking- und Betriebskomplexität mit sich. Bevorzuge, wo möglich, eine einzige wahrheitsgemäße Erfahrung.

Entscheidungstabelle für Rendering-Muster

Keine Zeile garantiert ein Ranking. Die Tabelle hilft, die passende Robustheit für die Aufgabe zu wählen.

Antwort-HTML gegen gerendertes DOM

Die HTTP-Antwort ist das, was ankommt, bevor Seiten-Skripte laufen. Das gerenderte DOM ist das vom Browser verarbeitete Dokument nach Skripten und Änderungen.

Prüfe beides auf:

• H1 und primäre Antwort;
• Title und Description;
• Canonical;
• Robots-Direktiven;
• Structured Data;
• interne Links;
• Produkt- oder Artikelinhalt;
• Fehlerzustand;
• Sprache und Alternates.

Wenn die Antwort leer, das gerenderte DOM aber vollständig ist, verarbeitet Google die Seite vielleicht trotzdem, aber du hast eine Rendering-Abhängigkeit geschaffen. Sind beide vollständig, Nutzer können aber nicht interagieren, liegt das Problem nicht bei der Indexierung. Es liegt bei Erlebnis und Accessibility.

Crawlbare Links

Verwende echte Anker:

<a href="/academy/core-web-vitals-inp/">Core-Web-Vitals-Lektion</a>

Ein Button mit einem onclick-Router-Aufruf mag für einen Browser bedienbar sein, liefert aber nicht dieselbe auffindbare URL-Beziehung.

Nutze die History-API für clientseitiges Routing und stelle sicher, dass jeder bedeutungsvolle Zustand über Folgendes verfügt:

• eine stabile URL;
• eine Serverantwort;
• einen direkten Reload-Pfad;
• den korrekten Status;
• teilbare Navigation.

Nur-Fragment-Routen wie /#/lesson sind eine schwache Standardwahl für öffentlichen kanonischen Inhalt.

Bedeutungsvolle Statuscodes in Single-Page-Anwendungen

Ein Router kann „nicht gefunden" anzeigen, während der Server für jede Route 200 liefert. Das ist ein Soft-404-Muster.

Der Server oder die Rendering-Plattform sollte liefern:

• 200 für eine echte Seite;
• eine direkte 3xx bei einem Umzug;
• 404 oder 410 für eine fehlende Route;
• wahrheitsgemäße temporäre Fehler bei Verfügbarkeitsausfällen.

Client-Text kann den HTTP-Zustand nicht mehr reparieren, nachdem ein Crawler die Antwort bereits erhalten hat.

Timing von Metadaten und Structured Data

Google dokumentiert, dass JavaScript Metadaten und JSON-LD während des Renderings ergänzen oder ändern kann. Die endgültigen gerenderten Daten müssen mit dem sichtbaren Inhalt übereinstimmen.

Das macht eine späte Injektion aber nicht zur sichersten Architektur. Erzeuge Title, Canonical, Sprache, Robots und zentrale Structured Data nach Möglichkeit stabil aus serverseitigen Routendaten.

Häufige Fehler:

• das Quell-Canonical zeigt auf A, das gerenderte Canonical auf B;
• ein Standard-Title wird indexiert, bevor er spät ersetzt wird;
• JSON-LD beschreibt Inhalte, die nicht gerendert werden konnten;
• ein clientseitiger Routenübergang behält die Metadaten der vorherigen Seite bei.

Lazy Loading, ohne Bedeutung zu verstecken

Lade Medien unterhalb des sichtbaren Bereichs lazy, um die anfängliche Arbeitslast zu reduzieren, aber verlange für essenziellen indexierbaren Text weder einen Klick noch ein Scroll-Ereignis. Nutze vom Browser unterstützte Bild-Ladestrategien und stabile Dimensionen.

Teste:

• einen frischen Ladevorgang ohne Interaktion;
• ein langsames Netzwerk;
• ein fehlgeschlagenes Skript;
• eine mobile Viewport-Größe;
• reduzierte Bewegung;
• die Tastaturnavigation.

Mobile-First-Indexierung bedeutet Content-Parität

Googles Best Practices zur Mobile-First-Indexierung besagen, dass die mobile Version für Indexierung und Ranking verwendet wird.

Die mobile Version sollte bewahren:

• den primären Inhalt;
• bedeutungsvolle Überschriften;
• Metadaten;
• Structured Data;
• Bildqualität und Alt-Text;
• crawlbare Links;
• den Robots-Zugriff auf benötigte Ressourcen.

Die responsive Darstellung darf sich ändern. Eine komplette Beweistabelle hinter einer kaputten Interaktion zu verstecken, verändert den zugänglichen Inhalt.

Platziere essenzielle Structured Data nicht nur auf Desktop. Kürze die mobile Seite nicht zu einer dünnen Zusammenfassung, während die Desktop-Seite die Belege enthält.

Agentenlesbare Oberflächen

Der web.dev-Artikel Agentenfreundliche Websites bauen, veröffentlicht im April 2026, erklärt, dass Browser-Agenten Oberflächen über Kombinationen aus Folgendem beobachten können:

• Screenshots;
• rohem HTML oder DOM;
• dem Accessibility-Baum.

Behandle das als Hinweis zur Interface-Gestaltung, nicht als Google-Rankingfaktor.

Eine robuste Aktion legt offen:

• einen klaren zugänglichen Namen;
• eine semantische Rolle;
• den aktuellen Zustand;
• einen stabilen Ort;
• ein vorhersehbares Ergebnis;
• Fehler-Feedback;
• Tastaturbedienung.

Ein Button, der nur mit einem Icon beschriftet ist, wirkt für Menschen visuell vertraut, ist im Accessibility-Baum aber möglicherweise namenlos. Ein individuelles Dropdown kann in einem Screenshot vollständig wirken und trotzdem weder mit der Tastatur noch von einem Agenten bedienbar sein.

Semantisches HTML schafft eine gemeinsame Grundlage. Es erlaubt nicht automatisch, private Aktionen automatisierten Agenten zugänglich zu machen. Autorisierung, Rate-Limits, Bestätigung, Idempotenz und Audit-Logs bleiben für folgenreiche Operationen notwendig.

Ein vollständiges Rendering-Audit

1. Die öffentliche Aufgabe definieren

Schreib auf, was anonyme Nutzer, Crawler und assistive Technologien lesen und tun können sollen.

2. Die Antwort abrufen

Notiere den finalen Status, die Header, das Antwort-HTML, das Canonical, Robots, Title, H1, Links und Structured Data.

3. In einem sauberen Browser rendern

Verwende keine eingeloggte Sitzung. Notiere Konsolen- und Netzwerkfehler, das gerenderte DOM, sichtbaren Inhalt und finale Metadaten.

4. Antwort- und gerenderten Zustand vergleichen

Klassifiziere Unterschiede als:

• beabsichtigte Anreicherung;
• akzeptabler verspäteter Inhalt;
• kritische Bedeutungsabhängigkeit;
• Konflikt;
• Fehlschlag.

5. Googles aktuelle Sicht testen

Nutze die URL-Prüfung für indexiertes HTML und einen Live-Test für den aktuellen Abruf. Denk daran, dass das Stichproben und verarbeitete Zustände sind.

6. Mobile Parität testen

Vergleiche bei einem 375-px-Viewport Text, Links, Metadaten, Structured Data, Medien und Bedienbarkeit.

7. Accessibility testen

Navigiere per Tastatur. Prüfe Überschriften, Landmarks, Namen, Rollen, Zustände, Fokusreihenfolge, Fehleransagen und den Zugriff auf Tabellen.

8. Fehlerzustände testen

Blockiere die Content-API, deaktiviere JavaScript, lade eine fehlende Route und simuliere langsame Verbindungen. Die korrekte Reaktion hängt vom öffentlichen Zweck der Seite ab.

9. Den ersten materiellen Fehler beheben

Wechsle nicht von React zu einem anderen Framework, wenn der tatsächliche Bug ein 401 auf einem öffentlichen Content-Endpunkt ist.

Durchgerechnetes Beispiel: die unsichtbare Lektion

Die Route /academy/rendering/ hat vier Mängel.

Mangel 1: App-Shell-Antwort

Die Antwort enthält nur:

<div id="app"></div>
<script src="/assets/app.js"></script>

Die Lektion kommt von /api/lesson/rendering.

Mangel 2: Die öffentliche API benötigt eine Sitzung

Die Redakteurin ist eingeloggt, deshalb wirkt die Seite vollständig. Ein sauberer Browser erhält 401. Das gerenderte DOM bleibt leer.

Kleinster vollständiger Fix: öffentliche Lektionsdaten ohne Konto-Autorisierung ausliefern und private Funktionen auf einem separaten authentifizierten Endpunkt belassen. Noch besser: die öffentliche Lektion bereits in der initialen Antwort rendern.

Mangel 3: Router-Fehler liefern 200

/academy/not-a-real-lesson/ zeigt eine Fehlermeldung an, liefert aber 200.

Fix: Die Serverroute soll 404 liefern und dabei hilfreiche Navigation erhalten.

Mangel 4: mobile Belege verschwinden

Die Beweistabelle steckt in einem individuellen, eingeklappten Panel. Der Umschalter ist nicht tastaturbedienbar, und der Inhalt wird aus dem Accessibility-Baum entfernt.

Fix: einen responsiven Tabellen-Wrapper oder ein zugängliches Disclosure-Element mit echtem Button, Namen, Zustand, Fokusverhalten und auf Mobilgeräten verfügbarem Inhalt verwenden.

Metadaten-Konflikt

Das Antwort-Canonical zeigt auf /academy/rendering-old/; JavaScript ändert es nach der Hydration.

Fix: das Canonical einmalig aus serverseitigen Routendaten erzeugen und clientseitige Übergänge konsistent halten.

Warum Schema und llms.txt das nicht beheben

Markup kann fehlenden sichtbaren Inhalt nicht erscheinen lassen. Eine spezielle Textdatei repariert weder eine fehlgeschlagene API noch einen falschen HTTP-Status noch eine unzugängliche Oberfläche.

Warum das trotzdem noch scheitern kann

Nachdem das Rendering behoben ist, kann die Lektion als Duplikat ausgeschlossen bleiben oder ihre Nutzeraufgabe verfehlen. Rendering schafft zuverlässige Beobachtbarkeit, aber keine garantierte Indexierung oder kein garantiertes Ranking.

SEOryon-Checkliste Antwort gegen gerendertes DOM

Lade die Checkliste Antwort vs. gerendertes DOM herunter.

Verwende nur öffentliche oder synthetische Eingaben. Baue kein serverseitiges Tool, das beliebige private URLs, interne Hosts, Metadaten-Endpunkte oder Mandanten-Seiten abruft. Das würde ein ernsthaftes Server-Side-Request-Forgery-Risiko schaffen.

Vergleiche für jeden Check:

• das Antwort-HTML;
• das gerenderte DOM;
• den mobilen Zustand;
• den Accessibility-Baum;
• den erwarteten Zustand;
• die Fehlerklasse;
• den kleinsten vollständigen Fix.

Häufige Irrtümer

„Google kann JavaScript rendern, also spielt Architektur keine Rolle"

Die Rendering-Fähigkeit beseitigt weder fehlgeschlagene Abhängigkeiten noch Warteschlangen-, Status- oder Paritätsrisiken.

„CSR rankt nie"

Das ist zu absolut. Diagnostiziere den tatsächlich ausgelieferten Inhalt und das tatsächliche System.

„SSR garantiert SEO"

SSR kann trotzdem dünnen Inhalt, defekte Canonicals, als 200 getarnte Fehler oder unzugängliche Interaktionen ausliefern.

Buttons, die als Links verwendet werden

Nutze Anker für Navigation und Buttons für Aktionen.

Primärer Inhalt erst nach Interaktion

Verlange keinen Klick oder Scroll, um essenzielle öffentliche Bedeutung zu erzeugen.

Bot-spezifischer substanzieller Inhalt

Crawlern und Nutzern inhaltlich wesentlich unterschiedliche Inhalte auszuliefern, kann Cloaking- und Betriebsrisiken erzeugen. Baue eine einzige wahrheitsgemäße Grundlage.

Übung: drei SPA-Fixtures

Fixture A

Die Antwort liefert 200 und eine App-Shell. Das Rendering gelingt. Die gesamte Lektionsnavigation nutzt Buttons mit Router-Handlern und kein href.

Fixture B

Die Antwort und die gerenderte Seite enthalten die Lektion. Das Canonical ist in der Quelle korrekt, aber Routenübergänge behalten JSON-LD und Title der vorherigen Seite bei.

Fixture C

Desktop enthält die vollständige Lektion samt Schema. Mobiles CSS entfernt das durchgerechnete Beispiel und die Quellen. Der Accessibility-Baum lässt sie ebenfalls aus.

Benenne für jede Fixture den Mangel, die Belege, die Auswirkung auf Nutzer oder Suche, und den kleinsten vollständigen Fix.

Lösungsschlüssel

• Fixture A: nicht crawlbare Navigationsbeziehung. Rendere echte semantische Anker mit realen URLs und reichere die Navigation danach an.
• Fixture B: Fehler im clientseitigen Metadaten-Lifecycle. Aktualisiere und entferne routenspezifische Metadaten bei jedem Übergang aus einer einzigen kanonischen Datenquelle und teste direkte Ladevorgänge.
• Fixture C: Paritätsfehler bei mobilem Inhalt und Structured Data. Bewahre substanziellen Inhalt und Schema auf Mobilgeräten und nutze responsive Darstellung statt Entfernung.

Eine bestandene Antwort stützt sich auf beobachtete Belege und empfiehlt keine vollständige Framework-Migration, ohne zu zeigen, warum sie nötig ist.

Abschließende Checkliste

• Die öffentliche Aufgabe ist für anonyme Nutzer definiert.
• Antwortstatus und Header stimmen mit dem sichtbaren Zustand überein.
• Der primäre Inhalt existiert im Antwort-HTML oder in einem zuverlässigen Rendering.
• Kritischer Inhalt hängt nicht von Authentifizierung ab.
• Quell- und gerenderter Title, Canonical, Robots und Sprache stimmen überein.
• JSON-LD stimmt mit dem sichtbaren Inhalt überein.
• Die Navigation nutzt crawlbare Anker.
• Jede öffentliche Route funktioniert beim direkten Reload.
• Fehlende Routen liefern bedeutungsvolle Fehler.
• Essenzieller Inhalt erfordert weder Scroll noch Klick.
• Mobil bleiben Inhalt, Metadaten, Links und Schema erhalten.
• Tastaturnavigation und Accessibility-Baum-Zustand sind nutzbar.
• Netzwerk- und Skriptfehlerzustände sind getestet.
• Kein Bot erhält inhaltlich wesentlich anderen substanziellen Inhalt.
• Private URL-Inspektionstools können keine beliebigen internen Ressourcen abrufen.

Häufig gestellte Fragen

Ist SSR besser als CSR für SEO?

SSR liefert eine robustere Grundlage für öffentlichen Inhalt, aber die richtige Wahl hängt von der Aufgabe ab. Teste Antwort, Rendering, Status, Links und Performance, statt nach Akronym zu wählen.

Führt Google JavaScript aus?

Google dokumentiert JavaScript-Rendering. Das bedeutet nicht, dass jeder Crawler rendert, jede Abhängigkeit gelingt oder nur per Interaktion erreichbarer Inhalt gefunden wird.

Kann ich JSON-LD per JavaScript injizieren?

Google dokumentiert, dass gerendertes JSON-LD verarbeitet werden kann, wenn es gültig ist und mit dem sichtbaren Inhalt übereinstimmt. Serverseitig erzeugte, stabile Daten lassen sich oft leichter steuern.

Bedeutet Mobile-First-Indexierung ein reines Mobile-Ranking?

Google nutzt hauptsächlich die mobile Version für Indexierung und Ranking. Desktop bleibt für Nutzer relevant, aber substanzielle mobile Parität ist unverzichtbar.

Ist agentenfreundliches Design ein Rankingfaktor?

Der web.dev-Artikel ist eine Design-Empfehlung, kein dokumentierter Beleg für einen Rankingfaktor. Semantische, zugängliche Oberflächen sind trotzdem wertvoll, für Menschen wie für verschiedenste Agenten.

Quellen und Methodik

Community-Recherche zeigte, dass Entwickler weiterhin fragen, ob SPA- und CSR-Seiten genauso effektiv indexiert werden können wie SSR-Seiten, und ob die Framework-Wahl allein die Performance von Wettbewerbern erklärt. Diese Fragen haben dieses evidenzbasierte Diagnoseformat geprägt. Community-Meinungen wurden nicht als Autorität herangezogen.

1. Google Search Central, Grundlagen zu JavaScript-SEO, aktualisiert am 4. März 2026 und geprüft am 28. Juli 2026. Offizielle Anleitung zu Crawling, Rendering, Status, Routing, Metadaten und JSON-LD.
2. Google Search Central, Best Practices zur Mobile-First-Indexierung, aktualisiert am 10. Dezember 2025 und geprüft am 28. Juli 2026. Offizielle Anleitung zur Parität von mobilem Inhalt und Metadaten.
3. Google Search Console, URL-Prüfungstool, geprüft am 28. Juli 2026. Offizieller Kontext zur indexierten und Live-Inspektion.
4. web.dev, Agentenfreundliche Websites bauen, veröffentlicht am 1. April 2026 und geprüft am 28. Juli 2026. Design-Empfehlung zur Beobachtung über Screenshot, HTML und Accessibility-Baum. Keine Quelle zu Rankingfaktoren.

Zurück: Indexierung, Canonicals, Weiterleitungen und HTTP-Status
Weiter: Core Web Vitals und Page-Experience-Diagnostik