JavaScript SEO Schweiz: 9-Schritte-Audit für SPA & React

Ein JavaScript SEO Schweiz Audit prüft eine simple Frage. Sehen Suchmaschinen und KI-Crawler die Inhalte deiner SPA wirklich — oder nur eine leere HTML-Hülle? Die kurze Antwort vorweg: Google rendert JavaScript inzwischen zuverlässig. Aber die Crawler hinter ChatGPT, Claude und Perplexity tun das nicht. Genau dort geht 2026 Sichtbarkeit verloren. Dieser Artikel zeigt dir das komplette Audit in neun Schritten. Dazu Curl-Befehle, die richtigen Screaming-Frog-Einstellungen und eine Fallstrick-Tabelle für Headless-CMS wie Storyblok, Sanity und Contentful. Wenn deine wichtigsten Inhalte erst nach dem JavaScript erscheinen, ist das kein Detail. Es ist dein Ranking.

Der Mythos: «Google rendert JavaScript, also ist meine SPA sicher»

Lange galt eine simple Regel: Wenn Google deine Inhalte rendert, ist alles gut. Diese Regel stimmt sogar — und führt trotzdem in die Irre. Denn sie beantwortet die falsche Frage. Die Frage ist nicht mehr, ob Google rendern kann. Sondern ob deine Inhalte schon im rohen HTML stehen, bevor irgendein Script läuft. Darum dreht sich jedes JavaScript SEO Schweiz Audit.

Zwei Dinge haben sich verschoben. Erstens rendert Google zwar, aber zeitversetzt und mit Budget — dazu gleich mehr. Zweitens kommt der Bruch. Die KI-Crawler bestimmen einen wachsenden Teil deiner Sichtbarkeit. Und sie rendern kein JavaScript. Beeindruckend, wie schnell sich das gedreht hat. Und ehrlich gesagt ein bisschen beunruhigend. Die meisten technischen Audits in der Schweiz prüfen JavaScript-SEO nämlich noch immer rein aus Googlebot-Sicht. Das ist 2026 zu kurz gesprungen. Deshalb gehört in jedes JavaScript SEO Schweiz Audit beides: Googlebot und KI-Crawler.

Was Googlebot wirklich sieht — und mit welcher Verzögerung

Google verarbeitet eine Seite in drei Schritten: crawlen, rendern, indexieren. Der erste Schritt holt das rohe HTML, und zwar sofort. Der zweite Schritt, das eigentliche Rendering, läuft in einem separaten System namens Web Rendering Service (WRS). Dieser WRS nutzt seit 2019 ein «evergreen» Chromium, also praktisch die aktuelle Chrome-Engine. Moderne Syntax wie ES6, async/await oder die Fetch-API ist damit kein Problem mehr. Doch genau hier wird es heikel.

Das Rendering ist eine Warteschlange, kein Sofortvorgang

Hier kommt der Haken. Das Rendering passiert nicht sofort, sondern in einer Queue. Mal nach Sekunden, mal nach Tagen — je nach Autorität und Crawl-Budget deiner Domain. Onely hat das gemessen. In der tiefsten Ebene ihrer Testkette brauchte Google für JS-Inhalte rund 313 Stunden, für reines HTML nur 36. Das ist also Faktor neun. Für eine zeitkritische Produktseite heisst das konkret: Sie kann tagelang unindexiert bleiben. Wer hier sauber arbeiten will, sollte ausserdem die Indexierung sauber steuern und kritische Seiten auf dem Server ausliefern.

Zwei aktuelle Änderungen machen das brisanter. Im Dezember 2025 stellte Google klar: Nur Seiten mit dem HTTP-Status 200 wandern in die Render-Queue. Liefert deine Seite einen anderen Status, wird das Rendering womöglich übersprungen. Im März 2026 entfernte Google zudem den Abschnitt «Design for accessibility» aus der JavaScript-Doku. Die Empfehlung, Seiten auch ohne JavaScript funktionsfähig zu halten, galt plötzlich als veraltet. Ein klares Signal, wohin die Reise geht.

Noch ein Detail, das in Audits fast nie auftaucht: Der WRS läuft ohne Service Worker und mit endlichem Render-Budget. Ein Script, das auf einen Service Worker oder eine Browser-Extension angewiesen ist, scheitert im WRS still. Im echten Browser funktioniert dasselbe Script tadellos. Das Ergebnis ist dann eine Seite, die ausgerechnet für Googlebot leer bleibt. Dabei merkt das im Alltag niemand.

Der blinde Fleck 2026: KI-Crawler rendern kein JavaScript

Das ist der Teil, der über die nächsten Jahre entscheidet. Denn Vercel und MERJ haben über 500 Millionen Abrufe des OpenAI-Crawlers GPTBot ausgewertet, in einer gemeinsamen Analyse von Vercel und MERJ. Das Ergebnis: kein einziger Hinweis auf ausgeführtes JavaScript. GPTBot lädt zwar JS-Dateien, rund 11,5 Prozent der Abrufe, führt sie aber nicht aus. Bei Anthropics ClaudeBot sind es sogar 23,84 Prozent geladene, aber ebenfalls nicht ausgeführte Scripte.

Das gilt nicht nur für einen Bot. Keiner der grossen KI-Crawler rendert JavaScript: GPTBot, OAI-SearchBot und ChatGPT-User von OpenAI, ClaudeBot von Anthropic, PerplexityBot, Bytespider von ByteDance sowie Meta-ExternalAgent. Die einzige Ausnahme ist Googles Gemini, und das auch nur, weil es die Googlebot-Technik mitnutzt. Anders gesagt: Wer in KI-Antworten auftauchen will, kommt um echtes HTML nicht herum. Genau deshalb beginnt ein JavaScript SEO Schweiz Audit immer beim rohen HTML.

Das Split-Visibility-Problem

Daraus entsteht eine geteilte Sichtbarkeit, die viele Teams nicht auf dem Schirm haben. Deine React-SPA rankt bei Google ordentlich, weil Googlebot rendert. Gleichzeitig sieht ChatGPT nur eine leere Hülle — und zitiert dich nie. Für ein Schweizer SaaS ist Client Side Rendering damit kein neutrales Detail mehr. Es ist eine Bremse für deine Sichtbarkeit. Konkret macht ein JavaScript SEO Schweiz Audit genau diese Lücke sichtbar. Wenn dir die ganzheitliche SEO-Sichtbarkeit wichtig ist, gehört dieser Punkt ganz nach oben.

Der Test dafür ist erstaunlich simpel. Deaktiviere JavaScript im Browser und lade deine Seite neu. Fehlen jetzt Produkttexte, Preise oder FAQ-Antworten, dann sehen die KI-Crawler exakt dasselbe Nichts. Kurz gesagt: Was ohne JavaScript verschwindet, existiert für sie nicht.

JavaScript SEO Schweiz Audit: die 9 Schritte

Jetzt zum Handwerk. Ein JavaScript SEO Schweiz Audit prüfst du in neun Schritten, vom rohen HTML bis zu den KI-Crawler-Logs. Du brauchst dafür nur zwei Werkzeuge: das Terminal mit curl und den Screaming Frog SEO Spider. Beides reicht, um zu sehen, was Googlebot und die KI-Crawler tatsächlich bekommen. Die folgende Übersicht fasst den Ablauf zusammen, danach gehen wir die Befehle und Einstellungen durch.

Schritt 1 bis 3: Sieht der Bot deine Inhalte überhaupt?

Jedes JavaScript SEO Schweiz Audit startet beim rohen HTML. Mit einem einzigen Curl-Befehl siehst du genau das, was Googlebot und jeder KI-Crawler im ersten Schritt bekommen — ganz ohne ausgeführtes JavaScript.

curl -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" -L https://deine-domain.ch/ -o raw.html

Öffne dann raw.html. Steht dein Haupttext drin, ist die Basis gesund. Findest du dagegen nur ein leeres <div id=”root”> und ein Script-Tag, läuft die Seite auf Client Side Rendering. Danach kommt der Abgleich mit dem gerenderten DOM. Dafür setzt du den Screaming Frog SEO Spider ein. Stell unter Configuration > Spider > Rendering den Modus auf «JavaScript». Erhöhe den AJAX-Timeout von 5 auf 10 Sekunden. Aktiviere unter Extraction «Store HTML» plus «Store Rendered HTML». Im unteren Fenster vergleichst du dann beide Versionen direkt.

Der dritte Schritt ist der schnellste. Öffne die DevTools, deaktiviere JavaScript und lade neu. Was jetzt fehlt, fehlt auch bei den KI-Crawlern. So trennst du in zwei Minuten echtes Rendering-Problem von blossem Bauchgefühl.

Schritt 4 bis 9: Tags, Status, Routing und Logs

Jetzt prüfst du die SEO-relevanten Tags direkt im Quelltext. Ein kurzer Grep zeigt dir, ob Canonical, hreflang, robots und Open-Graph-Tags schon im rohen HTML liegen oder erst per JavaScript nachgeladen werden.

curl -sL https://deine-domain.ch/ | grep -iE 'canonical|hreflang|name="robots"|og:title'

Kommt nichts zurück, werden diese Tags client-seitig gesetzt — und das ist riskant. Schritt fünf prüft die HTTP-Status. Eine gelöschte Seite zeigt per JavaScript «nicht gefunden», liefert aber trotzdem Status 200. Das ist eine klassische Soft-404. Behandle Fehlerzustände deshalb serverseitig, nicht in React. Schritt sechs nimmt die interne Verlinkung unter die Lupe. Echte <a href>-Links sind Pflicht, denn KI-Crawler folgen reiner JS-Navigation nicht.

Die letzten drei Schritte sichern die Basis ab. Stelle sicher, dass robots.txt weder JS noch CSS blockiert. Prüfe die Konsole auf Hydration-Warnungen. Filtere zuletzt deine Server-Logs nach GPTBot, OAI-SearchBot und ClaudeBot. So siehst du schwarz auf weiss, ob die KI-Crawler echten Inhalt erhalten oder ins Leere greifen. Kurz gesagt: Diese neun Schritte sind dein komplettes JavaScript SEO Schweiz Audit.

React SEO Schweiz, Next.js und Vue: wo es konkret bricht

Frameworks sind nicht das Problem. Die Render-Strategie ist es. Eine klassische Create-React-App liefert von Haus aus CSR — also genau die leere Hülle. Next.js dagegen kann serverseitig rendern (SSR), statisch generieren (SSG) oder per ISR nachladen. Genau deshalb taucht der Begriff «Next.js SEO Audit» so häufig auf. Der Wechsel von CSR zu Next.js mit SSR ist oft der schnellste Hebel überhaupt. Im JavaScript SEO Schweiz Audit ist genau das meist der erste grosse Befund. Das ist auch der Kern, wenn jemand nach React SEO Schweiz sucht.

Bei Vue gilt dasselbe über Nuxt, bei Angular über Angular Universal. Das Muster bleibt immer gleich. Im JavaScript SEO Schweiz Audit prüfst du die Render-Strategie pro Framework. Ohne Server- oder Static-Rendering steht dein Content nicht im rohen HTML, und schon bist du wieder beim Split-Visibility-Problem. Wichtig ist dabei: Server-Rendering verbessert oft auch die Ladezeit, weshalb sich der Blick auf Core Web Vitals parallel lohnt.

Ein eigener Fallstrick ist die Hydration. Der Server liefert HTML, das Client-JavaScript «hydriert» es zu einer interaktiven Seite. Stimmen beide Versionen nicht überein, entsteht ein Hydration-Mismatch. Das passiert etwa, wenn der Server «2024» rendert und der Client «2025» berechnet. React, Vue und Svelte werfen dann eine Warnung und machen trotzdem weiter. Meist ist das harmlos. Sitzt der Mismatch aber im Title oder in der H1, wird aus dem Detail ein echtes Ranking-Problem. Deshalb lohnt der Blick in die Konsole.

Headless-CMS-Fallstrick: Storyblok, Sanity und Contentful

Ein verbreiteter Irrtum lautet: «Wir nutzen ein modernes Headless-CMS, also ist SEO abgedeckt.» Es ist genau umgekehrt. Ein Headless-CMS liefert Inhalte als JSON über eine API — sonst nichts. Ob daraus indexierbares HTML wird, entscheidet allein dein Frontend. Anders als WordPress mit Yoast oder RankMath gibt es hier keine Leitplanken. Meta-Tags, Canonicals, Sitemaps und strukturierte Daten musst du selbst im Datenmodell anlegen und im Frontend ausgeben. Dabei hilft dir kein Plugin.

Das CMS selbst ist also nie «schlecht für SEO». Der Fallstrick steckt im Standard-Setup vieler Integrationen. Es setzt oft auf Client Side Rendering, vor allem wegen der Live-Vorschau im visuellen Editor. Auch das gehört in ein gründliches JavaScript SEO Schweiz Audit. Die folgende Tabelle zeigt die typischen Stolpersteine pro System und den jeweiligen Fix.

Ein zweiter, teurer Klassiker sind doppelte URLs. Wird das Slug-Feld pro Content-Typ unabhängig definiert, erscheint dieselbe Seite unter zwei Pfaden. Ohne sauberes Canonical splittet Google dann die Linkkraft. Und es rankt im Zweifel die falsche Variante. Solche Fehler entstehen im Datenmodell, nicht im Frontend. Genau deshalb gehört das Schema in jedes ernsthafte JavaScript SEO Schweiz Audit.

Vorher–Nachher: ein anonymisierter CH-SaaS-Fall

Wie sieht das in Zahlen aus? Hier ein anonymisierter, echter Fall aus unseren JavaScript SEO Schweiz Audits. Die Grössenordnungen sind typisch, die exakten Werte variieren je nach Projekt. Ein Schweizer B2B-SaaS lief auf einer reinen React-SPA mit Client Side Rendering. Googlebot rendert zwar, aber wegen der Render-Queue blieben hunderte Routen monatelang unindexiert. In ChatGPT und Perplexity tauchte das Produkt praktisch nie auf. Also ging dort viel verloren.

Nach der Migration auf Next.js mit SSR und ISR stand der Content im rohen HTML — für Googlebot und für die KI-Crawler. Das Ergebnis zeigte sich über rund fünf Monate. Konkret: deutlich mehr indexierte Seiten, ein klarer Anstieg der organischen Sessions und erstmals messbare Erwähnungen in KI-Antworten. Kein Wunder, kein Trick. Nur Inhalte, die der Bot vom ersten Byte an sieht.

SSR, SSG oder dynamic rendering — was du 2026 wählst

Unsere klare Empfehlung: Bau auf SSR, SSG oder Hydration, nicht auf reines CSR. Das löst beide Probleme auf einmal, Googlebot und KI-Crawler. Dynamic Rendering, also unterschiedliche Auslieferung an Bots und Nutzer, ist kein Neubau-Konzept mehr. Google selbst nennt es in der Doku einen «Workaround». Empfohlen wird stattdessen Server- oder Static-Rendering.

Trotzdem hat Dynamic Rendering eine Nische. Weil KI-Crawler kein JavaScript ausführen, kann es als Übergang sinnvoll sein, bis SSR steht. Nur die Werkzeuge dafür haben sich verändert. Rendertron, Googles eigene Open-Source-Lösung, ist seit Oktober 2022 archiviert und nur noch lesbar. Prerender.io hat seinen Gratis-Tarif im Oktober 2025 gestrichen. Und Achtung: Läuft die Integration aus, ohne dass du sie entfernst, bleiben Crawler-Anfragen unbeantwortet. Das trifft genau deine Sichtbarkeit. Darum prüfst du sie regelmässig.

Am Ende ist JavaScript-SEO keine Glaubensfrage, sondern eine Frage der Architektur. Prüf dein rohes HTML, bevor du über Rankings spekulierst. Wenn du dabei eine zweite Meinung willst, schau dir unser JavaScript SEO Schweiz Audit an — oder geh die neun Schritte oben einfach selbst durch. Beides bringt dich weiter als jede Vermutung.

Häufige Fragen zum JavaScript SEO Schweiz Audit

Quellen

1. Vercel — The rise of the AI crawler
2. Google Search Central — Dynamic rendering as a workaround
3. Screaming Frog — How to crawl JavaScript websites
4. Prerender.io — Changes to pricing (2025)
5. Storyblok — SEO in times of headless CMS and SPA