JavaScript-SEO: Rendering-Probleme erkennen und Inhalte crawlbar machen

Moderne Websites laden Inhalte oft erst im Browser nach. Für Nutzer sieht die Seite korrekt aus. Für Crawler kann sie trotzdem fast leer sein.

Genau hier setzt der RankScan-Insight „Nur per JavaScript sichtbarer Inhalt“ an.

Der Insight weist darauf hin, dass wichtige Inhalte, Links, Metadaten oder strukturierte DatenSchema Markup ist Code, der den Inhalt einer Webseite strukturiert beschreibt, sodass Suchmaschinen ihn nicht nur als Text, sondern als eindeutige Informationen verstehen.Zum Glossareintrag → erst durch JavaScript erzeugt werden. Das ist besonders kritisch, wenn diese Informationen nicht bereits im initialen HTMLHyperText Markup Language (HTML) ist die Auszeichnungssprache für Webseiten. Mit ihr werden Struktur und Inhalt einer Seite definiert, etwa Überschriften, Absätze, Links und Bilder.Zum Glossareintrag → (Hypertext Markup Language, der Auszeichnungssprache für Webseiten) vorhanden sind.

Für klassische Suchmaschinenoptimierung (SEO)Suchmaschinenoptimierung (SEO) umfasst alle Maßnahmen, mit denen eine Website in den unbezahlten (organischen) Suchergebnissen besser sichtbar wird.Zum Glossareintrag → bedeutet das: Google muss die Seite nicht nur crawlenBeim Crawling ruft ein Suchmaschinen-Bot eine URL ab und lädt deren Inhalte herunter. Es ist der erste Schritt, bevor eine Seite indexiert werden kann.Zum Glossareintrag →, sondern auch rendernJavaScript-Rendering bezeichnet den Vorgang, bei dem ein Browser oder Crawler JavaScript-Code ausführt, um daraus die fertige, sichtbare Seite zu erzeugen. Erst nach diesem Schritt entstehen Inhalte, die nicht bereits im ausgelieferten HTML stehen.Zum Glossareintrag →.
Für die Sichtbarkeit bei Künstlicher Intelligenz (KI) bedeutet es: Viele KI-Crawler sehen möglicherweise nur das rohe HTML – und damit nicht den eigentlichen Inhalt.

Wichtig ist die richtige Einordnung:

JavaScript ist nicht schlecht für SEO. Problematisch ist JavaScript dann, wenn wichtige Inhalte nur clientseitig entstehen und für Crawler nicht zuverlässig verfügbar sind.

In diesem Artikel erfährst du, wie JavaScript-SEO funktioniert, welche Rendering-Strategien sinnvoll sind, wie du prüfst, was Crawler wirklich sehen, und was du nach einem RankScan-Fund konkret tun solltest.

Was bedeutet JavaScript-SEO? #

JavaScript-SEO umfasst alle technischen Massnahmen, die sicherstellen, dass JavaScript-basierte Websites von Suchmaschinen korrekt verarbeitet werden können.

Google beschreibt in der eigenen Dokumentation, dass Google Search JavaScript verarbeitet und dass Website-Betreiber sicherstellen sollen, dass Inhalte, Links und Metadaten für Google zugänglich sind.
Quelle: Google Search Central – Understand JavaScript SEO Basics

JavaScript-SEO ist besonders relevant bei:

• Single-Page Applications,
• React-, Vue- oder Angular-Websites,
• Headless-Setups eines Content-Management-Systems (CMSEin Content-Management-System (CMS) ist eine Software zur Erstellung, Verwaltung und Veröffentlichung von Webinhalten, meist ohne Programmierkenntnisse. Bekannte Beispiele sind WordPress oder Shopify.Zum Glossareintrag →), eines Systems zur Verwaltung von Webinhalten,
• Shop-Frontends,
• Produktfiltern,
• Dokumentationen,
• SaaS-Websites,
• interaktiven Landingpages,
• Websites mit nachgeladenen Inhalten,
• Seiten mit clientseitig erzeugten Meta-Daten.

Was bedeutet „Nur per JavaScript sichtbarer Inhalt“? #

Der RankScan-Insight „Nur per JavaScript sichtbarer Inhalt“ bedeutet: Relevante Inhalte oder SEO-Elemente erscheinen erst nach JavaScript-Ausführung.

Das kann betreffen:

• H1Die H1 ist die Hauptüberschrift einer Webseite. Sie benennt das zentrale Thema, ist für Nutzer sichtbar und sollte pro Seite in der Regel nur einmal vorkommen.Zum Glossareintrag →,
• Haupttext,
• Produktinformationen,
• Preise,
• Kategorien,
• interne Links,
• Canonical-Tags,
• Title-Tags,
• Meta-Descriptions,
• JSON-LD,
• BreadcrumbsEine Breadcrumb-Navigation zeigt den Pfad einer Seite innerhalb der Website-Hierarchie an. Sie verbessert die Orientierung der Nutzer und ergänzt die interne Verlinkung.Zum Glossareintrag →,
• FAQ-Inhalte (Frequently Asked Questions, also häufig gestellte Fragen),
• Paginierung,
• Filter-Links,
• Navigation.

Nicht jedes JavaScript ist problematisch. Unkritisch sind oft:

• Animationen,
• Tracking,
• Menüs,
• kleine Interaktionen,
• Formularvalidierung,
• Warenkorb-Interaktion,
• Personalisierung nach Login.

Kritisch wird es, wenn der Kerninhalt der Seite erst im Browser entsteht.

Warum JavaScript-Rendering für SEO riskant ist #

Suchmaschinen müssen bei JavaScript-Websites mehr tun als bei klassischen HTML-Seiten.

Bei einer klassischen Seite erhält der Crawler direkt:

<h1>SEO-Beratung für KMU</h1>
<p>Wir unterstützen Unternehmen bei technischer SEO, Content und Monitoring.</p>
<a href="/kontakt">Kontakt aufnehmen</a>

Bei einer reinen Client-Side-App erhält der Crawler möglicherweise nur:

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

Der eigentliche Inhalt entsteht erst, wenn JavaScript geladen, ausgeführt und Daten von Programmierschnittstellen (APIs, kurz für Application Programming Interface) geholt wurden.

Das ist riskant, weil:

• Rendering zusätzliche Ressourcen braucht,
• JavaScript fehlschlagen kann,
• APIs blockiert oder langsam sein können,
• Inhalte verspätet erkannt werden,
• interne Links erst später sichtbar werden,
• Crawler nicht immer wie ein echter Browser handeln,
• KI-Crawler häufig gar nicht rendern.

Wie Google JavaScript verarbeitet #

Google kann JavaScript verarbeiten. Trotzdem ist es sinnvoll, wichtige Inhalte so früh und einfach wie möglich bereitzustellen.

Google erklärt, dass Google Search Seiten crawlt, rendert und indexiert. JavaScript kann dabei verarbeitet werden, aber Website-Betreiber sollten sicherstellen, dass Inhalte im gerenderten HTML sichtbar sind und Ressourcen nicht blockiert werden.
Quelle: Google Search Central – Understand JavaScript SEO Basics

Wichtig für die Praxis:

• Google kann JavaScript ausführen.
• Google muss die Ressourcen abrufen dürfen.
• Google muss APIEine Application Programming Interface (API) ist eine Programmierschnittstelle, über die Software-Systeme miteinander kommunizieren und Daten austauschen. Sie definiert, wie Anfragen gestellt und beantwortet werden.Zum Glossareintrag →-Inhalte laden können.
• Fehler im JavaScript können Inhalte unsichtbar machen.
• Rendering ist ein zusätzlicher Schritt.
• Das initiale HTML bleibt für schnelle und robuste Erfassung wichtig.

Die alte Vorstellung einer strikt getrennten „Two-Wave Indexing“-Logik wird heute oft zu absolut dargestellt. Praktisch bleibt aber richtig: JavaScript-Rendering ist komplexer und fehleranfälliger als serverseitig ausgeliefertes HTML.

KI-Crawler und JavaScript: Vorsichtig planen #

Bei KI-Crawlern ist die Lage uneinheitlicher als bei Google.

OpenAI dokumentiert verschiedene Crawler und User-Agents, darunter GPTBotGPTBot ist der von OpenAI dokumentierte Crawler, der typischerweise für das Training künftiger Modelle Inhalte abruft. Er lässt sich über robots.txt gezielt erlauben oder blockieren.Zum Glossareintrag →, OAI-SearchBotOAI-SearchBot ist der von OpenAI dokumentierte Crawler für ChatGPT Search. Er ruft Inhalte ab, damit öffentliche Websites als Quelle in ChatGPT-Zusammenfassungen, Snippets und Antworten erscheinen können.Zum Glossareintrag → und ChatGPT-UserChatGPT-User ist der von OpenAI dokumentierte User-Agent für nutzerinitiierte Abrufe. Er ruft eine Seite ab, wenn ein Nutzer in ChatGPT eine konkrete URL oder Anfrage eingibt.Zum Glossareintrag →. Diese erfüllen unterschiedliche Zwecke und können über robots.txt gesteuert werden.
Quelle: OpenAI Platform – Overview of OpenAI Crawlers

Die OpenAI-Dokumentation sagt jedoch nicht, dass diese Crawler JavaScript wie ein Browser rendern. Deshalb solltest du für KI-Sichtbarkeit nicht davon ausgehen, dass clientseitig nachgeladene Inhalte zuverlässig gelesen werden.

Vercel veröffentlichte 2024 eine Analyse zu AI-Crawlern (AI, englisch für Künstliche Intelligenz) und JavaScript-Rendering. Laut dieser Untersuchung rendern grosse AI-Crawler wie OpenAI, Anthropic oder Meta JavaScript nicht wie klassische Browser.
Quelle: Vercel – The rise of the AI crawler

Für RankScan bedeutet das:

Wenn wichtige Inhalte erst durch Client-Side Rendering entstehen, sind sie für viele KI-Crawler potenziell unsichtbar.

Das ist kein Beweis, dass jede KI deine Seite ignoriert. Aber es ist ein starkes technisches Risiko.

Client-Side Rendering, Server-Side Rendering und Prerendering #

Die Rendering-Strategie entscheidet, wann und wo HTML entsteht.

Client-Side Rendering: Wann es problematisch wird #

Client-Side Rendering (CSR), also das Rendern im Browser, bedeutet: Der Server liefert nur ein Grundgerüst. Der Browser lädt JavaScript und erzeugt daraus die Seite.

Beispiel:

<!doctype html>
<html>
  <head>
    <title>SaaS Tool</title>
  </head>
  <body>
    <div id="root"></div>
    <script src="/bundle.js"></script>
  </body>
</html>

Für Nutzer kann das perfekt funktionieren. Für Crawler ist es riskant.

Problematisch ist CSR besonders, wenn:

• H1 fehlt im initialen HTML,
• Hauptinhalt fehlt im initialen HTML,
• Produktdaten erst per API kommen,
• interne Links erst per JS erzeugt werden,
• Meta-Daten clientseitig gesetzt werden,
• Canonicals clientseitig gesetzt werden,
• JSON-LD clientseitig injiziert wird,
• Inhalte erst nach Scroll, Klick oder Nutzerinteraktion geladen werden.

Server-Side Rendering: Die robuste Lösung #

Server-Side Rendering (SSR), also serverseitiges Rendern, bedeutet: Der Server erzeugt das fertige HTML, bevor die Seite an Browser oder Crawler ausgeliefert wird.

Beispiel:

<h1>JavaScript-SEO: Rendering-Probleme erkennen</h1>
<p>Dieser Guide erklärt, wie Inhalte für Google und KI-Crawler sichtbar bleiben.</p>
<a href="/kontakt">Kontakt aufnehmen</a>

Vorteile:

• Inhalte sind sofort im HTML,
• Crawler sehen Kerninhalte ohne Browser-Rendering,
• Meta-Daten sind direkt verfügbar,
• interne Links sind crawlbar,
• strukturierte Daten können serverseitig ausgegeben werden,
• bessere Basis für Performance und Core Web Vitals.

SSR ist besonders sinnvoll für:

• SaaS-Websites,
• Shops,
• Produktseiten,
• Kategorien,
• Ratgeber,
• Dokumentationen,
• News,
• wichtige Landingpages.

Static Site Generation und Prerendering #

Static Site Generation (SSG), also die statische Seitengenerierung, erzeugt fertige HTML-Dateien beim Build. Das eignet sich besonders für Inhalte, die sich nicht bei jedem Aufruf ändern.

Gut geeignet für:

• Blogartikel,
• Ratgeber,
• Dokumentationen,
• Glossare,
• Marketingseiten,
• Help Center,
• Landingpages.

Prerendering erzeugt HTML-Versionen von Seiten im Voraus oder bei Bedarf. Es kann eine sinnvolle Übergangslösung sein, wenn eine bestehende CSR-App nicht sofort auf SSR umgestellt werden kann.

Wichtig:

• prerendered HTML muss dem sichtbaren Inhalt entsprechen,
• keine veralteten Snapshots ausliefern,
• Canonicals und Meta-Daten müssen stimmen,
• interne Links müssen enthalten sein,
• Bot-Version und Nutzer-Version dürfen nicht inhaltlich widersprechen.

Dynamic Rendering: Warum es nur ein Workaround ist #

Dynamic Rendering bedeutet: Nutzer erhalten die normale JavaScript-App, Crawler erhalten eine gerenderte HTML-Version.

Google beschreibt Dynamic Rendering als Workaround für Websites, bei denen JavaScript-generierter Inhalt für Suchmaschinen nicht verfügbar ist. Google weist aber auch darauf hin, dass Dynamic Rendering keine empfohlene Lösung ist, weil es zusätzliche Komplexität und Ressourcen benötigt.
Quelle: Google Search Central – Dynamic Rendering as a workaround

Warum Dynamic Rendering problematisch ist:

• zwei Versionen müssen gepflegt werden,
• Bot-Erkennung ist fehleranfällig,
• neue KI-Crawler werden oft nicht erfasst,
• Inhalte können zwischen Nutzer- und Bot-Version abweichen,
• Cloaking-Risiko bei falscher Umsetzung,
• komplexes Monitoring.

Besser sind in den meisten Fällen:

• SSR,
• SSG,
• Incremental Static Regeneration (ISR),
• Edge Rendering,
• sauberes Prerendering.

Hydration: Wenn HTML interaktiv wird #

Viele moderne Frameworks kombinieren SSR oder SSG mit HydrationHydration bezeichnet den Vorgang, bei dem serverseitig geliefertes HTML im Browser durch JavaScript interaktiv gemacht wird. Das Markup ist bereits vorhanden, JavaScript fügt nur noch das Verhalten hinzu.Zum Glossareintrag →.

Ablauf:

1. Server liefert fertiges HTML.
2. Crawler kann Inhalte lesen.
3. Browser lädt JavaScript.
4. JavaScript macht die Seite interaktiv.

Das ist grundsätzlich gut. Probleme entstehen, wenn Hydration fehlschlägt.

Typische Ursachen für Hydration-Probleme:

• serverseitig andere Daten als clientseitig,
• Date.now() oder Zufallswerte im Render,
• unterschiedliche Locale-Ausgaben,
• API-Daten nicht synchron,
• Nutzerzustand wird zu früh berücksichtigt,
• Komponenten rendern serverseitig anders als clientseitig.

Ein Hydration-Mismatch kann dazu führen, dass Inhalte flackern, verschwinden oder im Browser anders aussehen als im ausgelieferten HTML.

Framework-Hinweise: React, Vue, Angular, Astro und SvelteKit #

React / Next.js #

Next.js unterstützt SSR, SSG und moderne Server Components. Für SEO-relevante Seiten sollten Inhalte, Metadaten, Canonicals und strukturierte Daten serverseitig erzeugt werden.

Wichtig:

• nicht alle Inhalte nur im Client Component nachladen,
• Metadata API sauber nutzen,
• interne Links mit echten <a href> ausgeben,
• strukturierte Daten serverseitig einbetten.

Vue / Nuxt #

Reines Vue kann clientseitig rendern. Für gute Vue JS SEO ist Nuxt mit SSR oder SSG meist die bessere Grundlage.

Wichtig:

• Universal Rendering nutzen,
• Head-/Meta-Daten serverseitig setzen,
• API-Daten serverseitig laden,
• wichtige Inhalte im initialen HTML ausgeben.

Angular #

Angular kann mit Angular Universal serverseitig rendern. Ohne SSR besteht bei reinen Angular-SPAs (Single Page Application) das Risiko, dass Inhalte erst clientseitig entstehen.

Astro #

Astro ist für contentlastige Websites stark, weil standardmässig wenig JavaScript ausgeliefert wird. Interaktive Komponenten können als Inseln eingebunden werden.

SvelteKit #

SvelteKit unterstützt SSR standardmässig. Wichtig ist, SSR nicht unbeabsichtigt für SEO-relevante Seiten zu deaktivieren.

Was muss im initialen HTML stehen? #

Für SEO- und KI-Sichtbarkeit sollten diese Elemente möglichst im initialen HTML vorhanden sein:

• Title-TagDer Title-Tag ist ein HTML-Element im einer Seite, das den Seitentitel definiert. Er erscheint im Browser-Tab und kann als klickbarer Titel im Suchergebnis verwendet werden.Zum Glossareintrag →,
• Meta-Description,
• Canonical,
• H1,
• Haupttext,
• wichtige H2/H3,
• interne Links,
• Navigation,
• Breadcrumbs,
• Produktname,
• Preis und Verfügbarkeit,
• zentrale Bilder mit Alt-TextEin Alt-Text ist eine Textalternative für ein Bild, die im alt-Attribut des img-Elements hinterlegt wird und Inhalt oder Funktion des Bildes beschreibt.Zum Glossareintrag →,
• strukturierte Daten,
• FAQ-Inhalte,
• Autorinformationen,
• Pagination-Links,
• hreflanghreflang ist ein HTML-Attribut, das Suchmaschinen die Sprache und Region einer Seite mitteilt. Es verknüpft sprachliche oder regionale Varianten derselben Inhalte miteinander.Zum Glossareintrag →-Links.

Nicht alles muss ohne JavaScript perfekt interaktiv sein. Aber die Bedeutung der Seite sollte ohne JavaScript erkennbar bleiben.

Echte Links statt JavaScript-Navigation #

Crawler brauchen echte Links.

Schlecht:

<button onclick="goTo('/leistungen')">Leistungen</button>

Besser:

<a href="/leistungen">Leistungen</a>

Google empfiehlt für Links ein <a>-Element mit href-Attribut, damit Google Links zuverlässig crawlen kann.
Quelle: Google Search Central – Links best practices

Das gilt besonders für:

• Hauptnavigation,
• Teaser,
• Produktkarten,
• Pagination,
• Breadcrumbs,
• interne Links im Content,
• Filterseiten mit SEO-Relevanz.

Meta-Daten und strukturierte Daten serverseitig setzen #

Title, Meta-Description, Canonical und JSON-LD sollten nicht erst nachträglich im Browser entstehen.

Problematisch:

document.title = 'Neue Seite';

oder JSON-LD nur per Tag Manager nachladen.

Besser:

• Title im serverseitigen Head ausgeben,
• Meta-Description im HTML ausgeben,
• Canonical serverseitig setzen,
• hreflang serverseitig setzen,
• JSON-LD direkt im HTML ausgeben.

Warum?

Crawler und KI-Systeme können dann die wichtigsten Signale ohne Rendering erfassen.

Lazy Loading, Tabs und Accordions #

JavaScript ist nicht nur beim ersten Rendern relevant. Auch spätere Interaktionen können Inhalte verstecken.

Lazy Loading #

Gut für:

• Bilder unterhalb des sichtbaren Bereichs,
• Videos,
• nicht kritische Module.

Riskant für:

• H1,
• Haupttext,
• Produktdaten,
• wichtige interne Links,
• Preise,
• FAQ-Inhalte.

Tabs und Accordions #

Unkritisch, wenn Inhalte bereits im HTML stehen und nur ein- oder ausgeblendet werden.

Riskant, wenn Inhalte erst nach Klick per API geladen werden.

Infinite Scroll #

Problematisch, wenn keine crawlbaren Pagination-URLs existieren.

Besser:

• eigenständige URLs,
• Pagination-Links,
• History API sauber nutzen,
• Inhalte serverseitig verfügbar machen.

Wie du prüfst, was Crawler sehen #

1. Quelltext anzeigen #

Im Browser:

Rechtsklick → Seitenquelltext anzeigen

Suche nach:

• H1,
• Haupttext,
• Produktname,
• Preis,
• internen Links,
• Canonical,
• JSON-LD.

Wichtig: „Seitenquelltext anzeigen“ ist nicht dasselbe wie „Untersuchen“. DevTools zeigt oft das bereits gerenderte Document Object Model (DOM)Das Document Object Model (DOM) ist die strukturierte Abbildung einer Webseite, mit der ein Browser deren Inhalt und Aufbau im Speicher darstellt. JavaScript kann das DOM verändern und so Inhalte hinzufügen oder entfernen.Zum Glossareintrag →, also die Struktur, mit der der Browser eine Seite abbildet.

2. JavaScript deaktivieren #

Deaktiviere JavaScript im Browser und lade die Seite neu.

Prüfe:

• Ist der Hauptinhalt sichtbar?
• Sind Links erreichbar?
• Ist Navigation vorhanden?
• Sind wichtige Texte lesbar?
• Gibt es eine leere Seite?

Das simuliert nicht perfekt jeden Crawler, zeigt aber typische Risiken.

3. Google Search Console URL-Prüfung #

Nutze das URL-Prüftool und den Live-Test.

Prüfe:

• Screenshot,
• gerendertes HTML,
• geladene Ressourcen,
• blockierte Ressourcen,
• Indexierbarkeit,
• JavaScript-Fehler.

4. cURL-Test #

Rufe die Seite ohne Browser auf:

curl -L https://example.ch/

Suche im Output nach Hauptinhalten.

Dieser Test zeigt, was einfache HTML-Clients und viele Bots zuerst erhalten.

5. Logfiles prüfen #

Server-Logs zeigen, welche Bots deine Seite abrufen und welche Statuscodes sie erhalten.

Prüfe:

• GooglebotDer Googlebot ist der Webcrawler von Google, der Webseiten abruft, um sie für die Google-Suche zu crawlen und zu indexieren.Zum Glossareintrag →,
• GPTBot,
• OAI-SearchBot,
• ChatGPT-User,
• ClaudeBotClaudeBot ist der von Anthropic genutzte Web-Crawler. Website-Betreiber können seinen Zugriff über die robots.txt steuern und bei Bedarf blockieren.Zum Glossareintrag →,
• PerplexityBotPerplexityBot ist der von Perplexity dokumentierte Crawler, der Websites in Perplexity-Suchergebnissen sichtbar machen und als Quelle verlinken soll. Laut Perplexity wird er nicht für das Training von Foundation Models genutzt.Zum Glossareintrag →,
• Statuscodes,
• Antwortgrössen,
• blockierte Ressourcen,
• 403/429-Fehler.

Priorisierung: Welche JavaScript-SEO-Probleme sind kritisch? #

Die wichtigste Regel:

Alles, was für Ranking, Verständnis, interne Verlinkung oder Conversion wichtig ist, sollte nicht ausschliesslich clientseitig erzeugt werden.

Content-Fehler oder Architektur-Fehler? #

Bei „Nur per JavaScript sichtbarer Inhalt“ ist meist nicht der Text das Problem, sondern die Auslieferung.

Content-/Komponentenproblem #

Beispiele:

• FAQ-Komponente lädt Antworten erst nach Klick,
• Produktpreise kommen nur clientseitig,
• Filterlinks sind Buttons ohne href,
• Autorenbox wird erst im Browser eingefügt,
• JSON-LD kommt nur über Tag Manager.

Lösung: Komponente serverseitig oder statisch ausgeben.

Architekturproblem #

Beispiele:

• komplette Website ist CSR,
• Marketingseiten sind in einer SPA ohne SSR,
• Headless-Shop rendert nur im Browser,
• Dokumentation wird per JS aus API gebaut,
• Prerendering fehlt oder ist veraltet.

Lösung: SSR, SSG, ISR, Prerendering oder Architekturänderung.

Architekturprobleme haben meist hohe Priorität, weil sie viele URLs betreffen.

Was tun nach einem RankScan-Fund? #

Wenn RankScan „Nur per JavaScript sichtbarer Inhalt“ meldet, solltest du strukturiert vorgehen.

Schritt 1: Betroffene Elemente identifizieren #

Prüfe:

• Fehlt der Haupttext?
• Fehlt die H1?
• Fehlen interne Links?
• Fehlen Produktdaten?
• Fehlen Meta-Daten?
• Fehlt JSON-LD?
• Fehlt Navigation?
• Fehlen FAQ-Inhalte?

Schritt 2: Seitentyp priorisieren #

Besonders wichtig sind:

• Startseite,
• Leistungsseiten,
• Produktseiten,
• Kategorien,
• Ratgeberartikel,
• Dokumentation,
• Landingpages,
• Standortseiten,
• FAQ- und Help-Seiten.

Eine clientseitige Animation ist weniger kritisch als eine Produktseite ohne Produktdaten im HTML.

Schritt 3: Rendering-Strategie prüfen #

Frage:

CSR, SSR, SSG, ISR, Prerendering oder Edge Rendering?

Wenn SEO-relevante Seiten rein clientseitig gerendert werden, solltest du eine robustere Strategie prüfen.

Schritt 4: Quick Fix oder Architektur-Fix wählen #

Schritt 5: Testen #

Nach dem Fix prüfen:

• Quelltext,
• gerendertes HTML,
• Live-Test der Google Search Console (GSC),
• cURL,
• Mobile-Friendly Rendering,
• Logfiles,
• RankScan Re-Crawl.

Worauf ein guter JavaScript-SEO-Check achtet #

Ein guter Check meldet nicht nur, dass JavaScript vorhanden ist. Entscheidend ist, ob wichtige Inhalte erst durch JavaScript entstehen.

Ein guter Check umfasst:

• Hauptinhalt im initialen HTML,
• H1 im initialen HTML,
• Title und Meta-Description serverseitig,
• Canonical serverseitig,
• JSON-LD im HTML,
• echte interne Links mit href,
• Navigation crawlbar,
• Produktdaten im HTML,
• Breadcrumbs im HTML,
• FAQ-Inhalte im HTML,
• Unterschied zwischen Quelltext und gerendertem DOM,
• blockierte JS- bzw. CSSCascading Style Sheets (CSS) ist die Sprache, mit der das Layout und die Gestaltung von Webseiten festgelegt werden. CSS bestimmt unter anderem Farben, Schriften, Abstände und Anordnung.Zum Glossareintrag →-Ressourcen (Cascading Style Sheets, die Sprache für das Layout von Webseiten),
• JavaScript-Fehler beim Rendering,
• API-Abhängigkeiten,
• HTTPHTTP (Hypertext Transfer Protocol) ist das Protokoll, über das Browser und Server Webinhalte austauschen. HTTPS ist die verschlüsselte, sichere Variante dieses Protokolls.Zum Glossareintrag →-Statuscodes (Hypertext Transfer Protocol) für Bots,
• AI-Crawler-Zugriffe in Logs,
• CSR-Muster wie leeres div#app.

So wird „Nur per JavaScript sichtbarer Inhalt“ zu einem klaren technischen Website-Health-Workflow.

Beispiel: Unsichtbare SaaS-Landingpage #

Ausgangslage #

Ein SaaS-Anbieter betreibt seine Marketingseite als reine React-SPA.

Der Quelltext zeigt:

<body>
  <div id="root"></div>
  <script src="/bundle.js"></script>
</body>

Im Browser sieht die Seite vollständig aus. RankScan meldet:

„Nur per JavaScript sichtbarer Inhalt“
„Fehlende H1“
„Fehlendes Schema-Markup“
„Geringe SuchsichtbarkeitSuchsichtbarkeit beschreibt, wie präsent und auffindbar eine Website in den organischen Suchergebnissen ist. Sie ist nicht dasselbe wie Traffic, sondern beschreibt die theoretische Auffindbarkeit.Zum Glossareintrag →“

Analyse #

• H1 fehlt im initialen HTML,
• Leistungsbeschreibung fehlt im initialen HTML,
• interne Links werden per Button-Navigation erzeugt,
• JSON-LD wird clientseitig eingefügt,
• KI-Crawler erhalten nur eine fast leere HTML-Hülle.

Lösung #

1. Marketingseiten auf SSR oder SSG umstellen.
2. H1, Haupttext und interne Links serverseitig ausgeben.
3. Title, Description und Canonical im HTML setzen.
4. JSON-LD serverseitig integrieren.
5. App nach dem Laden hydrieren.
6. Mit cURL, GSC und RankScan erneut prüfen.

Ergebnis #

Crawler erhalten direkt verständliches HTML. Die Seite ist robuster für Google, klassische Crawler und KI-Systeme.

Häufige Fehler bei JavaScript-SEO #

Fehler 1: Browseransicht mit Bot-Sicht verwechseln #

Nur weil die Seite im Browser funktioniert, ist sie nicht automatisch crawlbar.

Fehler 2: DevTools statt Quelltext prüfen #

DevTools zeigt das gerenderte DOM. Für den ersten Bot-Eindruck ist der rohe Quelltext entscheidend.

Fehler 3: Interne Links als Buttons bauen #

Ohne echte href-Links fehlen crawlbare Pfade.

Fehler 4: Meta-Daten clientseitig setzen #

SEO-Signale sollten nicht erst nach JavaScript-Ausführung entstehen.

Fehler 5: Hauptinhalt nach Scroll oder Klick laden #

Crawler interagieren nicht wie echte Nutzer. Wichtige Inhalte sollten nicht erst nach Nutzeraktion geladen werden.

Fehler 6: Dynamic Rendering dauerhaft als Lösung nutzen #

Dynamic Rendering kann helfen, ist aber komplex und laut Google nicht die empfohlene langfristige Lösung.

Fehler 7: KI-Crawler ignorieren #

Wer Inhalte nur clientseitig ausliefert, riskiert, dass viele KI-Crawler zentrale Inhalte nicht sehen.

Checkliste: JavaScript-SEO prüfen #

Nutze diese Checkliste:

• Ist der Hauptinhalt im Seitenquelltext vorhanden?
• Ist die H1 im initialen HTML?
• Sind Title, Description und Canonical serverseitig gesetzt?
• Sind wichtige interne Links echte <a href>-Links?
• Ist JSON-LD im HTML vorhanden?
• Sind Produktdaten im HTML?
• Sind Preise und Verfügbarkeit im HTML?
• Sind FAQ-Inhalte ohne Klick sichtbar oder im HTML vorhanden?
• Funktioniert die Seite mit deaktiviertem JavaScript grundsätzlich?
• Sieht Google im URL-Prüftool den Hauptinhalt?
• Gibt es blockierte JS- oder CSS-Ressourcen?
• Gibt es Rendering-Fehler?
• Gibt es leere App-Shells wie <div id="app"></div>?
• Gibt es Hinweise in Server-Logs, dass Bots nur kleine HTML-Antworten erhalten?
• Wurde nach dem Fix erneut gecrawlt?

Ergänzend dazu helfen semantisches HTML und AI Readiness Score, um die Ursache sauber einzugrenzen und die nächsten SEO-Massnahmen zu priorisieren.

Fazit: Was nicht zuverlässig im HTML steht, ist ein Sichtbarkeitsrisiko #

JavaScript ist nicht der Gegner von SEO. Aber rein clientseitig erzeugte Inhalte sind ein Risiko.

Für Google bedeutet JavaScript zusätzlichen Rendering-Aufwand. Für viele KI-Crawler bedeutet es möglicherweise: Der Inhalt wird gar nicht gesehen.

Der RankScan-Insight „Nur per JavaScript sichtbarer Inhalt“ ist deshalb ein High-Priority-Hinweis. Er zeigt nicht nur, dass JavaScript verwendet wird, sondern dass wichtige SEO-Elemente möglicherweise erst nach dem Rendern sichtbar werden.

Die beste Vorgehensweise lautet:

1. prüfen, was im initialen HTML steht,
2. wichtige Inhalte und Links serverseitig verfügbar machen,
3. Meta-Daten und Canonicals im HTML ausgeben,
4. JSON-LD serverseitig integrieren,
5. echte HTML-Links verwenden,
6. Rendering-Fehler beheben,
7. SSR, SSG, ISR oder Prerendering für wichtige Seiten nutzen,
8. mit GSC, cURL, Logs und RankScan erneut testen.

So wird JavaScript nicht zum Sichtbarkeitsproblem, sondern zu einer stabilen technischen Grundlage für SEO, Website Health und KI-lesbare Inhalte.

Quellen und weiterführende Informationen #

• Google Search Central – Understand JavaScript SEO Basics
• Google Search Central – Dynamic Rendering as a workaround
• Google Search Central – Links best practices
• OpenAI Platform – Overview of OpenAI Crawlers
• Vercel – The rise of the AI crawler