SSR-Checker

So funktioniert es

1. Die URL wird zweimal parallel und ohne JavaScript abgerufen: einmal mit dem User-Agent eines Desktop-Chrome, einmal als Googlebot
2. Weiterleitungen werden verfolgt (max. 5); finale URL, HTTP-Status, Time to First Byte und Antwort-Header (Server, CDN, Cache-Status) werden erfasst
3. Das rohe HTML wird geparst: Title, Meta-Description, Canonical, lang, Robots-Anweisungen, H1, <a href>-Links, Bilder, JSON-LD-Typen, Meta-Refresh
4. Scripts, Styles, noscript, Templates und SVG werden entfernt, dann werden die Wörter des sichtbaren Textes gezählt — das, was ein Crawler der ersten Welle indexiert
5. Der Stack wird an Markup-Spuren erkannt: __NEXT_DATA__ / self.__next_f (Next.js), __NUXT_DATA__ (Nuxt), __remixContext, ng-version + ng-server-context (Angular), astro-island, SvelteKit, Qwik, CMS-Generator-Tags und leere <div id="root"> / <div id="app">-Hüllen
6. Beide Antworten werden verglichen: 403/429 für Googlebot heißt, Bots werden blockiert; deutlich mehr Text für Googlebot heißt Dynamic Rendering
7. Score 0–100 aus Inhalt (bis 40), gefülltem App-Container, Title, H1, Links, Canonical, JSON-LD, lang und Script-Anteil; Urteil: serverseitig, teilweise oder clientseitig gerendert

Über serverseitiges Rendering und SEO

Serverseitiges Rendering (SSR) bedeutet, dass das HTML, das Ihr Server zurückgibt, die Seite bereits enthält — Überschriften, Text, Produktdaten, Links. Clientseitiges Rendering (CSR) bedeutet, dass der Server eine fast leere Hülle liefert und der Browser die Seite erst durch Ausführen von JavaScript zusammensetzt. Für einen Menschen mit modernem Browser sehen beide gleich aus. Für alles, was HTML liest, ohne Scripts auszuführen, sehen sie völlig unterschiedlich aus: die erste Welle des Google-Crawlers, Bing, Link-Vorschauen in Slack, WhatsApp und LinkedIn, die meisten KI-Crawler und Answer Engines und ein großer Teil der SEO-Tools.

Google führt JavaScript aus, aber in einem zweiten, verzögerten Durchgang, der vom Crawl-Budget abhängt und Stunden oder Tage nach dem ersten Abruf liegen kann. Eine CSR-Seite wird daher später indexiert, ihre Links werden später entdeckt, und jede Störung in der Rendering-Pipeline — ein blockiertes Script, ein Timeout, eine API, die ein Cookie braucht — lässt die Seite als die leere Hülle im Index, als die sie ausgeliefert wurde. Frameworks wie Next.js, Nuxt, Remix, SvelteKit, Astro und Angular lösen genau das, indem sie zuerst auf dem Server rendern und dann im Browser hydrieren; dieser Checker sagt Ihnen, ob Ihr Produktiv-Deployment das tatsächlich tut.

Das Tool liest das rohe HTML und beantwortet damit die Frage, die ein gerenderter Screenshot nicht beantworten kann: Was steht im Dokument, bevor irgendein Script läuft? Es zählt die Wörter des sichtbaren Textes, prüft, dass der App-Container (#root, #app, #__next, #__nuxt) nicht leer ist, verifiziert die Head-Elemente, die im initialen HTML stehen müssen — Title, Meta-Description, Canonical, lang — und liest den Rendering-Modus an den Spuren ab, die Frameworks hinterlassen, etwa Next.js' __NEXT_DATA__ mit seinen gssp/gsp-Flags oder die React-Server-Components-Payload in self.__next_f.

Der zusätzliche Abruf als Googlebot zeigt zwei Dinge, die eine einzelne Anfrage nicht zeigen kann. Bekommt der Bot 403 oder 429, während der Browser die Seite erhält, blockiert eine WAF- oder Bot-Schutz-Regel Crawler — eine erstaunlich häufige Ursache für Seiten, die nicht indexiert werden. Bekommt der Bot deutlich mehr Text als der Browser, nutzt die Seite Dynamic Rendering oder einen Prerender-Dienst für Crawler; das ist legitim, muss aber mit der echten Seite synchron bleiben. Alles passiert bei uns im Arbeitsspeicher: Das HTML wird analysiert und verworfen, zurück kommen nur die abgeleiteten Zahlen und eine Textprobe von 500 Zeichen.

Häufige Fragen

Woran erkenne ich, ob meine Seite serverseitig gerendert wird?

Fügen Sie die URL hier ein. Enthält das HTML bereits Ihre Überschriften, Texte und Links — der Checker zeigt Hunderte Wörter, einen gefüllten App-Container und einen Title — ist die Seite serverseitig gerendert oder statisch generiert. Zeigt er eine Handvoll Wörter und ein leeres #root oder #app, wird der Inhalt per JavaScript im Browser aufgebaut. Manuell prüfen Sie das über „Seitenquelltext anzeigen“ (nicht den DevTools-Inspector, der das gerenderte DOM zeigt) oder indem Sie JavaScript deaktivieren.

Führt der Checker JavaScript aus?

Nein, absichtlich nicht. Er zeigt, was der Server sendet — genau das, was Crawler der ersten Welle, Link-Vorschau-Bots, die meisten KI-Fetcher und viele SEO-Tools sehen. Googles Test für Rich-Suchergebnisse und die URL-Prüfung in der Search Console zeigen das Ergebnis nach JavaScript; nutzen Sie beide Sichten zusammen: diese, um zu wissen, was ausgeliefert wird, Googles, um zu wissen, was gerendert wird.

Was bedeutet „teilweise gerendert“?

Das HTML enthält eine Hülle mit etwas Inhalt — oft Header, Footer und Navigation vom Server, während der Hauptinhalt (Produktliste, Artikeltext, Suchergebnisse) nach dem Laden per JavaScript geholt und gezeichnet wird. Dasselbe Urteil bekommt eine Next.js-getStaticProps-Seite, die als Fallback-Hülle ausgeliefert wird, oder eine Seite, deren sichtbarer Text im Verhältnis zur Script-Last winzig ist. Prüfen Sie in der Textprobe, welcher Inhalt fehlt, und bringen Sie ihn ins initiale HTML.

Warum bekommt Googlebot ein anderes Ergebnis als der Browser?

Drei übliche Gründe. Eine WAF- oder Bot-Schutz-Regel blockiert den Googlebot-User-Agent (HTTP 403/429/503) — der echte Googlebot verifiziert zusätzlich per IP, aber eine UA-basierte Sperre ist ein starker Hinweis. Ein Dynamic-Rendering-Setup (Rendertron, Prerender.io, ein CDN-Worker) liefert vorgerendertes HTML nur an Crawler. Oder die Seite personalisiert nach User-Agent und Sprache. Das Erste muss behoben werden; das Zweite ist in Ordnung, solange beide Versionen denselben Inhalt tragen; das Dritte sollten Sie auf Cloaking-Risiko prüfen.

Ist eine clientseitig gerenderte Seite immer schlecht für SEO?

Nicht immer, aber immer langsamer und riskanter. Google rendert und indexiert sie in der Regel irgendwann; Bing und die meisten anderen Suchmaschinen, Social-Vorschauen und KI-Crawler nicht. Für Seiten, die ranken oder geteilt werden sollen — Landingpages, Produktseiten, Artikel — gehört der Inhalt ins initiale HTML. Dashboards hinter einem Login und App-Screens, die nie indexiert werden müssen, können clientseitig bleiben.

Welche Frameworks und Plattformen werden erkannt?

Next.js (App Router vs. Pages Router, getServerSideProps vs. getStaticProps), Nuxt 2 und 3, Remix, React Router 7, Gatsby, Astro, Docusaurus, SvelteKit, SolidStart, Qwik, Angular (mit und ohne SSR), reine React- und Vue-Apps über ihren Mount-Point sowie die üblichen serverseitigen Plattformen: WordPress, Shopify, Wix, Webflow, Squarespace, Framer, HubSpot, Drupal, Joomla, Ghost, Magento, Hugo, Jekyll, Eleventy und die türkischen E-Commerce-Plattformen Ticimax, IdeaSoft und T-Soft. Alles andere wird rein nach seinem HTML-Inhalt beurteilt.

Werden URL oder Seiteninhalt gespeichert?

Nein. Die Seite wird in den Arbeitsspeicher geladen, analysiert und verworfen; der Endpunkt setzt no-store, führt kein URL-Log und antwortet nur auf Anfragen von insighthackerz.com. Was Sie auf dieser Seite sehen — Zählwerte, Header, eine Textprobe von 500 Zeichen — ist alles, was den Server verlässt.