JavaScript-SEO: Die wichtigsten Grundlagen

Eigentlich müsste man diesen Artikel mit „Willkommen im 21. Jahrhundert“ beginnen – aber wir sind ja längst im dritten Jahrzehnt davon, und trotzdem ist das Thema so aktuell wie nie. Kaum eine Woche vergeht, in der nicht irgendwo in der SEO-Bubble darüber diskutiert wird, ob Google mit JavaScript umgehen kann, wie viel Rendering-Budget wir verbrennen und ob die ganzen KI-Crawler da draußen unsere Single-Page-Apps überhaupt sehen. Genau diese Woche gab es übrigens gleich zwei Meldungen, die mitten ins Herz des JavaScript-SEO treffen: Google hat die neuen Generative-AI-Performance-Reports in der Search Console offenbar flächendeckend ausgerollt, und mit den neuen AI Controls kannst du als Website-Betreiber inzwischen selbst entscheiden, ob deine Inhalte in der KI-Suche auftauchen sollen. Und dann ist da noch die unbequeme Wahrheit, die Crawler-Analysen immer wieder bestätigen: Viele KI-Crawler rendern kein JavaScript.

Klingt nach einer Menge Baustellen? Ja. Aber keine Sorge: Nach diesem Artikel weißt du genau, worauf es ankommt – und wie du deine JavaScript-Seite sowohl für Google als auch für die neuen KI-Crawler fit machst.

Warum JavaScript überhaupt ein SEO-Problem ist

Kurzer Ausflug in die Vergangenheit: In den frühen 2010er-Jahren war die Lage noch simpel. Ein Bot kam auf deine Seite, las das HTML, folgte den Links – fertig. JavaScript wurde bestenfalls ignoriert. Das hat sich geändert, seit moderne Webanwendungen wie React, Vue oder Angular den Großteil ihrer Inhalte erst im Browser (oder im Server) zusammenschustern.

Heute sieht der Ablauf bei Google ungefähr so aus:

1. Crawlen: Der Googlebot lädt das rohe HTML deiner Seite.
2. Rendern: Die Web Rendering Service (WRS) genannte Rendering-Engine – ein Chromium-Headless-Browser – führt das JavaScript aus.
3. Indexieren: Erst der gerenderte DOM-Baum wird analysiert und indexiert.

Das Problem: Rendern kostet Ressourcen, kostet Zeit und braucht einen zweiten Crawl-Durchlauf. Ein Klassiker: Der Googlebot crawlt deine Seite, findet (noch) keine Inhalte, weil sie erst per JavaScript geladen werden, und schickt die URL später erneut in die Rendering-Queue. Ergebnis: Content wird spät oder gar nicht indexiert, und dein Crawl-Budget verbrennt. Genau das hat Google übrigens in seiner offiziellen Doku zu „Grundlagen von JavaScript-SEO“ erst vor ein paar Monaten wieder explizit erwähnt.

So sieht Google deine Seite wirklich

Viele Developer glauben, Google rendere wie ein normaler Browser. Fast – aber mit Einschränkungen. Google schaltet einige Dinge beim Rendering schlicht ab: Autoplay-Videos, Web-Notifications, Service Worker werden nur teilweise ausgeführt, und Animationen werden aus Energiegründen nicht durchgespielt. Und was am wichtigsten ist: Es gibt eine Warteschlange. Rendering ist eine begrenzte Ressource, die Google nicht unbegrenzt bereitstellt.

Ein gängiger Anfängerfehler ist deshalb der, alle Inhalte hinter JavaScript zu verstecken, nur weil es bequem ist. Kurze Faustregel:

Wenn dein wichtigster Content ohne JavaScript im HTML steht, hat Google nichts zu rechnen – und deine Seite ist maximal robust.

Der Elefant im Raum: KI-Crawler rendern kein JavaScript

Und jetzt kommt der Teil, der 2026 wirklich spannend ist. Während Google seit Jahren ein großes Rendering-Budget investiert, sieht das bei vielen anderen Bots anders aus. Analysen von Crawl-Logs zeigen immer wieder dasselbe Muster: Viele KI-Crawler – etwa von einzelnen LLM-Anbietern – laden nur das rohe HTML und führen kein JavaScript aus. Für eine reine Client-Side-Rendered-App heißt das: ChatGPT, Claude & Co. sehen schlicht eine leere Seite.

Das ist gerade in dieser Woche brandaktuell, weil Googles Generative-AI-Reports endlich sichtbar machen, wie viel Traffic aus AI Overviews und ähnlichen Flächen kommt. Und wenn du deine Sichtbarkeit in diesen Flächen willst, hilft es ungemein, wenn die Inhalte bereits im HTML stehen – nicht erst nach einem halben Dutzend fetch()-Aufrufen im Client.

Die drei Rendering-Strategien im Überblick

Es gibt mehrere Wege, JavaScript-Seiten suchmaschinenfreundlich zu bauen. Die wichtigsten drei:

1. Server-Side Rendering (SSR)

Dein Server rendert die Seite bei jedem Request und liefert fertiges HTML aus. Der Client übernimmt danach die Interaktivität (Hydration). Nachteil: höhere Serverlast, weil jede Anfrage neu gerendert wird.

2. Static Site Generation (SSG)

Die Seiten werden zur Build-Zeit ein einziges Mal gerendert und als statische Dateien ausgeliefert. Schnell, robust, ideal für Blogs und Marketing-Seiten. Der Preis: Für stark dynamische Inhalte ungeeignet.

3. Pre-Rendering / Dynamic Rendering

Du lieferst echten Bots ein vorgefertigtes HTML aus, während normale Nutzer die JavaScript-App bekommen. Mittelfinger-Setup-Alarm: Diese Lösung erfordert, dass du Bots zuverlässig erkennst – und gilt inzwischen vielerorts als verpönt, weil sie Pflegeaufwand und versteckte Risiken mit sich bringt. Lieber gleich auf SSR oder SSG setzen.

In React sieht SSG heute meist so aus (beispielhaft mit React Server Components):

export default async function BlogPost({ params }) {
  // Läuft auf dem Server, kommt als fertiges HTML raus
  const post = await getPost(params.slug);
  return (
    <article>
      <h1>{post.title}</h1>
      <p>{post.excerpt}</p>
    </article>
  );
}

Ein Next.js-Projekt mit SSG schreibst du ungefähr so:

export async function generateStaticParams() {
  const posts = await getAllPosts();
  return posts.map((post) => ({ slug: post.slug }));
}

export default async function Page({ params }) {
  const post = await getPost(params.slug);
  return (
    <article>
      <h1>{post.title}</h1>
      <div dangerouslySetInnerHTML={{ __html: post.html }} />
    </article>
  );
}

Das Resultat: fertiges HTML, das jedes Rendering überflüssig macht – von Google bis zum kleinsten KI-Crawler.

JavaScript-SEO zum Durchchecken: die Checkliste

Jetzt wird es praktisch. Hier ist die Liste, die ich bei jeder JavaScript-Seite abarbeite:

• Rendering-Art wählen: SSR, SSG oder ein Hybrid – und nicht alles im Client rendern.
• Wichtige Inhalte ins HTML: Titel, Meta-Description, H1s und der eigentliche Text dürfen nicht von JavaScript abhängen.
• Lazy Loading mit Bedacht: Bilder lazy zu laden ist gut, aber verstecke keine Artikeltexte hinter Intersection-Observer-Logik.
• Robots-Verhalten checken: Dürfen Bots dein JavaScript, CSS und deine API-Endpunkte erreichen? Ein übereifriges robots.txt-Disallow kann das Rendering killen.
• Crawl-Budget im Blick: Jede Render-Anfrage kostet. Baust du id-lastige URLs mit unzähligen Parametern, verbrennst du Budget für nichts.
• Hash-Routing vermeiden: example.com/#/produkt ist für Google ein Albtraum. Nutze saubere Pfade wie /produkt/.

Soft-404s, die stille Indexierungs-Falle

Ein Klassiker in JavaScript-Apps: Der Router fängt unbekannte Routen ab und rendert eine „Seite nicht gefunden“-Ansicht – mit HTTP-Status 200. Google indexiert dann fröhlich tausende Duplikate als „Soft-404s“. Der Fix ist simpel und gehört eigentlich in jede App:

export default function NotFound() {
  // Sorgt dafür, dass der Statuscode wirklich 404 ist
  return <h1>Seite nicht gefunden</h1>;
}

Im Next.js-App-Router liefert die not-found-Datei automatisch einen echten 404-Status. Bei selbst gebauten Setups musst du im Server-Code aktiv den Status setzen – sonst bleibt es bei 200 und einem SEO-Problem.

Wie du testest, ob Google deine Seite wirklich rendert

Das Gute: Du musst nicht raten. Googles offizielle Werkzeuge zeigen dir, ob dein JavaScript-Content ankommt:

• URL-Inspektion in der Search Console: Öffne die Seite, klicke auf „Getestete Seite anzeigen“ und wechsle auf „HTML“ bzw. „Screenshot“. Siehst du dort deinen Content, wurde gerendert. Leere Seite bedeutet: Rendering-Problem.
• „Test der URL“ live: Der testet übrigens nicht nur die gecrawlte Version, sondern rendert on demand.

Und für alle JavaScript-Apps gibt es einen schnellen Selbsttest per Kommandozeile – zum Beispiel mit curl, einfach einmal die Seite ohne JavaScript laden und schauen, ob die Inhalte drin sind:

curl -s https://deine-seite.de/blog/ | grep -i "<h1>"
# Kommt hier dein Artikel-Titel an? Dann bist du auf der sicheren Seite.
# Keine Ausgabe? Dann steckt dein Content im JavaScript. Handlungsbedarf!

Fazit: Kein JavaScript bashing, sondern Technologie verstehen

JavaScript ist nicht „böse“ für SEO – es ist nur anspruchsvoller als statisches HTML. Wer seine Seite versteht, weiß, wie Google sie versteht. Und in Zeiten von AI Overviews, Generative-AI-Reports und KI-Crawlern, die kein JavaScript rendern, zahlt sich ein solides Fundament doppelt aus: schnelleres Indexing, weniger Crawl-Budget-Verbrauch und Sichtbarkeit auch in den neuen Kanälen.

Die Devise lautet also: Rendern, wo es sinnvoll ist, Inhalte ins HTML bringen, was wichtig ist, und regelmäßig testen. Wenn du dir die drei Grundpfeiler – Server-Rendering für die Inhalte, saubere Statuscodes und ein aufgeräumtes Crawl-Setup – einmal verinnerlicht hast, ist JavaScript-SEO kein Hexenwerk mehr. Sondern einfach nur gutes Handwerk. Und genau das ist es, was Google, die KI-Crawler und am Ende auch deine Nutzer zu schätzen wissen.