Stellen Sie sicher, dass jede wichtige URL verwertbares HTML, den korrekten Status, einen Titel, ein Canonical und crawlbare Links liefert; JavaScript sollte den Inhalt verbessern, ohne eine versteckte Abhängigkeit für die Indexierung zu schaffen.
JavaScript kann eine schnelle interaktive Oberfläche schaffen, kann aber zugleich Inhalte für einen Crawler verzögern oder ganz verbergen, der das Skript nicht wie erwartet ausführt. Das größte Risiko ist nicht das Framework selbst, sondern die Abhängigkeit kritischer Texte, Links und Metadaten vom erfolgreichen Laden mehrerer Skripte und APIs.
JavaScript-SEO untersucht deshalb zwei Versionen: die ursprüngliche HTML-Antwort und das DOM nach dem Rendering. Wichtige Inhalte müssen zuverlässig verfügbar sein, URLs sollen korrekte Statuscodes zurückgeben und die interne Navigation soll Links verwenden. Die Architektur ist nach Produkt, Team und Betrieb zu wählen, nicht nach der Vorstellung, ein Rendering-Modus sei universell der beste.
Vergleichen Sie die Quellantwort mit dem gerenderten DOM
Öffnen Sie die Serverantwort ohne Ausführung von Skripten und prüfen Sie Haupttext, Überschrift, Links, Title und Meta-Robots. Vergleichen Sie anschließend das DOM nach dem Rendering. Enthält die ursprüngliche Antwort nur einen leeren Container und scheitert das Skript an einem Timeout, einer blockierten Ressource oder einem API-Fehler, erhält der Crawler möglicherweise keine verwertbare Seite.
Testen Sie sowohl anonyme als auch berechtigte Nutzer, einen mobilen User-Agent und eine langsamere Verbindung. Inhalte, die von Standort, Cookies oder localStorage abhängen, können einem Crawler eine andere Version zeigen. Ein Unterschied muss kein Fehler sein, wenn er beabsichtigt ist und die öffentliche Version vollständig bleibt. Dokumentieren Sie kritische Abhängigkeiten und überwachen Sie sie bei jedem Release.
SSR, statische Generierung und Hydration
Server-Side Rendering erzeugt HTML bei der Anfrage, statische Generierung während des Builds und clientseitiges Rendering erst im Browser. Ein hybrider Ansatz kann für verschiedene Routen unterschiedliche Modi verwenden. Entscheiden Sie anhand der Änderungshäufigkeit, Personalisierung, des Cachings, der Kosten und der Fähigkeit des Teams, sowohl Server als auch Client zu überwachen.
Die Hydration verbindet Interaktivität mit dem serverseitig erzeugten HTML. Erzeugen Server und Client unterschiedliche Inhalte, kann es zu Springen, Fehlern oder überschriebenen Links kommen. Stabile Komponenten, deterministische Daten und Tests verringern das Risiko. Dynamisches Rendering nur für Bots kann abweichende Versionen erzeugen und erhöht die betriebliche Komplexität; es sollte daher eher eine Übergangslösung sein.
- HTML bereits vor der Hydration verfügbar
- gleicher Hauptinhalt für Crawler und Menschen
- überwachte Server- und Client-Fehler
- pro Route dokumentierter Rendering-Modus
Links, Lazy Loading und Interaktionen
Die interne Navigation verwendet das Element a mit einem gültigen href. Ein klickbares div oder eine Schaltfläche mit Router ist nicht unbedingt ein auffindbarer Link und verschlechtert die Barrierefreiheit. Jede wichtige Route muss beim direkten Aufruf und beim Neuladen funktionieren. Endloses Scrollen benötigt separate paginierte URLs und Links.
Lazy Loading von Bildern und ergänzenden Inhalten ist nützlich, doch binden Sie den Haupttext und Links nicht ausschließlich an Scrollen oder IntersectionObserver ohne sichere Alternative. Ein Bild sollte Abmessungen, einen Alt-Text und je nach Implementierung eine echte Quelle haben. Testen Sie auch den Fall, dass ein Nutzer oder Crawler die erwartete Interaktion nie ausführt.
Statuscodes und Metadaten beim clientseitigen Routing
Der Server muss für eine nicht existierende Route 404 zurückgeben, nicht pauschal 200 mit einer clientseitigen Fehleranzeige. Führen Sie Weiterleitungen bei einer dauerhaften Änderung mit dem passenden HTTP-Status aus und überlassen Sie deren Logik nicht allein einem Skript. Prüfen Sie das Verhalten beim direkten Aufruf, da ein interner Router eine fehlerhafte Serverkonfiguration verschleiern kann.
Titel, Meta-Description, Canonical, Robots und Sprachalternativen müssen bereits in der zuverlässig verfügbaren Ausgabe zu jeder Route passen. Aktualisieren Sie bei einem Routenwechsel ohne vollständiges Neuladen auch diese Elemente und den Verlaufsstatus. Doppelte Canonical-Elemente von Server und Client können widersprüchliche Signale senden.
Testprozess für JavaScript-SEO
Prüfen Sie in automatisierten Tests den HTTP-Status, das Quell-HTML, die gerenderte Überschrift, den Canonical und die Anzahl wichtiger Links. Führen Sie Tests mit deaktiviertem JavaScript, langsamem Netzwerk und simuliertem API-Ausfall durch. Vergleichen Sie in den Tools der Suchmaschinen die geladene Seite und den Screenshot, verlassen Sie sich aber nicht nur auf eine einzige manuelle Prüfung.
Überwachen Sie clientseitige Fehler, Renderzeit, fehlgeschlagene Anfragen und Unterschiede zwischen Releases. Führen Sie nach einer Migration des Frameworks oder des Routings einen Crawl der Quell- und der gerenderten Website durch. Eine hochwertige Implementierung betrachtet SEO nicht als späteres Plugin; die Verfügbarkeit von Inhalten und korrekte URLs sind Abnahmekriterien für jede öffentliche Route.
- Vergleich von Server-HTML und finalem DOM
- Test der öffentlichen Route ohne gespeicherten Zustand
- Prüfung der Links bei deaktiviertem JavaScript
- Monitoring von API- und Hydration-Fehlern
- Regressions-Crawl nach einer Änderung des Routings oder Frameworks
Häufige Fragen
Kann eine Suchmaschine JavaScript ausführen?
Einige Suchmaschinen führen es aus, jedoch mit Verzögerung und Einschränkungen. Kritische Inhalte und Links dürfen daher nicht von einer fragilen Kette clientseitiger Anfragen abhängen.
Ist Server-Side Rendering immer notwendig?
Nein. Statische oder hybride Generierung kann besser geeignet sein. Entscheidend sind Aktualität, Personalisierung, Betriebskosten und die Zuverlässigkeit des öffentlichen HTML für die jeweilige Route.
Ist ein klickbarer Button ein Ersatz für einen internen Link?
Nicht für die Navigation zu einer anderen URL. Verwenden Sie einen Link mit href, der auch ohne Router funktioniert. Ein Button ist für eine Aktion im aktuellen Kontext gedacht.