JavaScript-SEO: Warum Google Ihre Inhalte nicht sieht

Die Seite funktioniert in Chrome einwandfrei, doch Google indexiert einen leeren Titel und einige Footer-Zeilen. Entwickler sagen, moderne Crawler führten JavaScript aus; das SEO-Team sieht URLs ohne Sichtbarkeit. Beide Seiten haben nur halb recht.

Google kann JavaScript rendern, aber nicht jede JavaScript-Anwendung wird deshalb schnell gecrawlt, korrekt verstanden und vollständig indexiert. Prüfen Sie die Seite anhand der drei tatsächlichen Google-Phasen: HTML crawlen, JavaScript rendern und das Ergebnis indexieren.

Wie Google JavaScript-Seiten verarbeitet

Phase 1: Crawling

Googlebot ruft die URL ab und liest HTTP-Status, Header, Robots-Anweisungen und ursprüngliches HTML. Bereits dabei kann er <a>-Links, Canonicals, Titel und vorhandene Inhalte aus der Antwort extrahieren.

Liefert der Server 404, 500, eine Crawling-Sperre oder noindex, endet die Verarbeitung möglicherweise, bevor die Anwendung läuft.

Phase 2: Rendering

Eine 200-Seite kann in eine Rendering-Warteschlange gelangen. Eine Chromium-Version ohne Oberfläche führt JavaScript aus, lädt erlaubte Ressourcen und erstellt den gerenderten DOM. Die Wartezeit hängt von den Crawler-Ressourcen ab.

Phase 3: Indexierung

Google liest Inhalte und Links aus dem gerenderten HTML und bewertet Canonicals, Qualität, Duplikate und Indexierbarkeit. Erfolgreiches Rendering garantiert dennoch keine Indexierung; die Seite muss Mehrwert und schlüssige Signale bieten.

Schnellster Test: JavaScript deaktivieren

Prüfen Sie die HTML-Antwort über den Seitenquelltext oder curl. Verlassen Sie sich nicht ausschließlich auf DevTools Elements, das den DOM nach der Skriptausführung zeigt.

Achten Sie auf fünf Punkte:

1. Sind Titel und Meta-Beschreibung vorhanden?
2. Sind H1 und Haupttext sichtbar?
3. Sind interne Pfade echte <a href>-Links?
4. Stimmen Canonical und Robots-Tags sofort?
5. Liefert der Server den richtigen Status?

Enthält die Antwort nur <div id="app"></div>, hängt die Entdeckung vom Rendering ab. Das ist nicht automatisch defekt, macht Indexierung und Fehlersuche aber unnötig langsam.

Sieben häufige JavaScript-SEO-Probleme

1. Inhalte erscheinen erst nach Nutzerinteraktion

Googlebot muss keine Tabs anklicken, Akkordeons öffnen, endlos scrollen oder „Mehr laden“ drücken. Inhalte, die erst nach einer Aktion abgerufen werden, bleiben möglicherweise unentdeckt.

Rendern Sie wichtige Inhalte im HTML oder bieten Sie eine eigene URL und einen crawlbaren Link für jeden indexierungswürdigen Zustand. Ein Akkordeon mit bereits im DOM vorhandenem Inhalt ist sicherer als eines, das erst nach einem Klick lädt.

2. Client-Routen liefern immer 200

Eine SPA kann „Nicht gefunden“ anzeigen, während der Server 200 liefert, und so einen Soft 404 erzeugen. Auch das Gegenteil kommt vor: Eine gültige Route erhält einen Server-404, bevor der Frontend-Router startet.

Jede indexierbare URL benötigt einen aussagekräftigen Serverstatus. Fehlende Seiten liefern 404, verschobene Inhalte leiten weiter und vorübergehende Anwendungsfehler liefern 5xx.

3. Links sind nicht crawlbar

Das sieht für Nutzer wie Navigation aus, ist jedoch kein zuverlässiger Crawl-Pfad:

<span onclick="goTo('/products')">Products</span>

Verwenden Sie:

<a href="/products">Products</a>

Ein Client-Router kann die Navigation weiterhin abfangen, solange der Anker eine echte URL enthält.

4. JavaScript schreibt Canonical um

Canonical sollte im HTML-Quelltext stehen und stabil bleiben. Zeigt die Quelle auf URL A und ändert ein Skript sie auf B, erhält der Crawler je Phase widersprüchliche Signale. Erwarten Sie ebenso wenig, dass JavaScript noindex entfernt: Google kann die Anweisung erkennen und das Rendering auslassen.

5. Robots-Regeln blockieren Bundles oder APIs

Die Anwendung benötigt möglicherweise JavaScript, CSS oder eine öffentliche API zum Inhaltsaufbau. Kann Googlebot diese Ressourcen nicht laden, bleibt die Darstellung leer oder unvollständig.

Schützen Sie private APIs. Prüfen Sie öffentliches Rendering und Ressourcen mit den Netzwerkwerkzeugen des Browsers und der URL-Prüfung in Search Console; die Erkennung von Cloudflare prüft keine privaten WAF-Richtlinien.

6. Rendering hängt von lokalem Speicher, Cookies oder Standort ab

Googlebot kommt wie ein neuer Besucher. Erscheinen Hauptinhalte erst nach einem localStorage-Token, einem besonderen Zustimmungscookie oder einem Standortergebnis, erhält der Crawler möglicherweise einen Leerzustand.

Liefern Sie eine nützliche Standardversion. Personalisierung sollte sie verbessern und nicht das gesamte Thema der URL ersetzen.

7. Hydration schlägt fehl

SSR liefert möglicherweise vollständiges HTML, danach löscht ein Hydration-Fehler Inhalte oder erzeugt einen anderen DOM. Die Suche kann die Antwort weiterhin lesen, doch Nutzererfahrung und Links nach dem Rendering können beschädigt sein.

Überwachen Sie Konsolenfehler, Hydration-Mismatch-Warnungen und fehlgeschlagene Anfragen in Produktion. Probleme bei Bots oder langsameren Geräten werden in routinemäßiger Qualitätssicherung leicht übersehen.

CSR, SSR, SSG und hybrides Rendering

Blogs, Landingpages, Kategorien und Dokumentation profitieren meist von SSR oder SSG. Ein angemeldetes Dashboard muss nicht indexiert werden; dort ist CSR völlig angemessen.

Dynamisches Rendering wurde genutzt, um Bots spezielles HTML zu liefern. Zwei Versionen zu pflegen erzeugt jedoch Abweichungen und Kosten. Liefern Sie Nutzern und Crawlern möglichst dieselben vorgerenderten Kerninhalte.

JavaScript-SEO-Audit Schritt für Schritt

Schritt 1: Drei Versionen vergleichen

Stellen Sie diese nebeneinander:

• HTML-Quelltext;
• im Browser gerenderter DOM;
• gerendertes HTML oder Screenshot aus der URL-Prüfung.

Alles, was nur in Ihrem Browser vorhanden ist und in der URL-Prüfung fehlt, ist ein starker Hinweis.

Schritt 2: Anfragen und Ressourcen prüfen

Suchen Sie Ressourcen mit 403, 404, CORS-Fehlern, Zeitüberschreitungen oder Robots-Sperren. Eine einzige fehlerhafte API kann einen gesamten Inhaltsbereich entfernen, obwohl das Hauptbundle lädt.

Schritt 3: Metadaten prüfen

Titel, Beschreibungen, Canonicals, Robots-Anweisungen und strukturierte Daten müssen zur Route passen. SPAs behalten häufig Metadaten der vorherigen Route oder leiten Canonicals aus nicht normalisierten URLs ab.

Der Meta Tag Checker zeigt Titel, Canonical, Open-Graph-Tags und Überschriften einer URL.

Schritt 4: Links und Sitemaps kontrollieren

Interne Links benötigen href, Sitemaps sollten nur kanonische URLs enthalten und jede gelistete URL muss den vorgesehenen Status liefern. Eine Sitemap ersetzt keine crawlbare Navigation.

Schritt 5: Leistung messen

Große Bundles und lange Aufgaben beeinträchtigen Nutzer und verteuern das Rendering. Führen Sie den Page Speed Checker aus und beachten Sie LCP, INP, TBT und ungenutztes JavaScript.

Schritt 6: Vorlagen statt nur die Startseite testen

Prüfen Sie stichprobenartig Beitrag, Kategorie, Produkt, Filterergebnis, Paginierung und eine fehlende URL. Die meisten JavaScript-SEO-Fehler stecken in selten manuell geöffneten Routen.

Ein typischer Fehler

Eine Stellenwebsite verwendet Vue, um Jobkarten nach dem Mounten der Kategoriekomponente abzurufen. Die H1 der Kategorie steht im Quelltext, jede Jobkarte wird aber per JavaScript erzeugt. Jede Karte nutzt @click auf einem <div> ohne href.

Besucher können normal nach Jobs suchen. Google findet Stellendetails jedoch schwer, weil die Sitemap zwar Job-URLs nennt, crawlbare Pfade und interne Links aber fehlen. Verbessern Sie die Entdeckung mit dem XML Sitemap Checker.

Die Lösung ist nicht, Vue zu entfernen. Das Team stellt Karten auf <a href> um, rendert die Anfangsliste serverseitig, behält interaktive Filter im Client und liefert echte 404 für abgelaufene Jobs. Die Architektur bleibt modern, die Entdeckung hängt nicht mehr vom Zufall ab.

Checkliste vor der Veröffentlichung

• Hauptinhalt steht im HTML oder wird zuverlässig gerendert.
• Gültige Routen liefern 200, entfernte Routen 404/410.
• Wichtige Navigation verwendet <a href>.
• Canonical und Robots-Anweisungen stehen stabil im Quelltext.
• Erforderliche CSS-, JavaScript- und API-Ressourcen sind crawlbar.
• Leerzustände für neue Besucher ersetzen keine Kerninhalte.
• Metadaten aktualisieren sich bei Navigation korrekt.
• Strukturierte Daten erscheinen im gerenderten HTML.
• Mobil und Desktop liefern gleichwertige Hauptinhalte.
• Die URL-Prüfung sieht dieselben Inhalte wie Besucher.

JavaScript-SEO nach der Veröffentlichung überwachen

Eine einmalige Prüfung erkennt offensichtliche Fehler, doch JavaScript-Anwendungen ändern sich häufig. Ergänzen Sie einige Produktionsprüfungen, damit SEO-Probleme vor einem sichtbaren Search-Console-Trend auffallen.

Überwachen Sie repräsentative öffentliche Routen auf HTML-Ebene:

• erwarteter Titel und Canonical stehen in der Antwort;
• Hauptüberschrift und ein erkennbares Inhaltsfragment sind vorhanden;
• Statuscode passt zum Routenzustand;
• mindestens ein wichtiger interner Link besitzt ein echtes href;
• Robots-Anweisungen ändern sich nicht unerwartet.

Führen Sie für berechtigt von Hydration abhängige Inhalte zusätzlich eine Prüfung im rendernden Browser durch. Erfassen Sie Konsolenfehler, fehlgeschlagene Netzwerkanfragen, endgültigen Canonical, strukturierte Daten und Screenshot. Der HTML-Test schützt Crawler-Grundlagen, der gerenderte Test die eigentliche Anwendung.

Wählen Sie URLs nach Vorlage statt nur nach Traffic. Ein Startseitenmonitor kann grün bleiben, während Produktdetails, Paginierung oder lokalisierte Routen ausfallen. Pflegen Sie einen stabilen Testfall pro indexierbarer Vorlage und einen negativen Testfall, der 404 liefern muss.

Veröffentlichungsvermerke sind ebenso hilfreich. Sinken indexierte Seiten oder Impressionen, verkürzt die genaue Kenntnis von Änderungen an Router, Consent-Manager, Rendering-Framework oder API die Diagnose. Ohne diesen Verlauf machen Teams oft ein Algorithmusupdate für eine selbst verursachte Verschlechterung verantwortlich.

Vergleichen Sie bei größeren Websites Quell-HTML und gerenderten DOM automatisch. Warnen Sie bei großen Text- oder Linkverlusten oder wenn Inhalte erst nach einer verzögerten Nutzeraktion erscheinen. Diese Prüfungen ersetzen die URL-Prüfung nicht, erkennen aber täglich vermeidbare Fehler.

Gesamtprüfung: Verwenden Sie den SEO Checker für eine repräsentative URL und ein kostenloses SEO-Audit, um wiederkehrende Probleme über mehrere Vorlagen zu erkennen.

Fazit

JavaScript lässt SEO nicht scheitern. Tatsächlichen Schaden verursachen Inhalte erst nach Klicks, falsche Statuscodes, Links ohne href und spät wechselnde Metadaten. Gestalten Sie die erste Antwort aussagekräftig, halten Sie URLs und Statuscodes korrekt und verbessern Sie mit JavaScript die Erfahrung, statt Kerninhalte zu verstecken.

Quelle: Google Search Central – JavaScript SEO basics.