Static Site SEO: Jamstack, SSG und Auffindbarkeit

TL;DR: Static-Site-SEO beginnt mit einem entscheidenden Vorteil: Wichtiges Content-Material kann als vorgerendertes HTML ankommen – statt erst auf die Ausführung von JavaScript zu warten. Aber Astro, Hugo, 11ty, Gatsby, Jekyll und statische Next.js-Exports lösen die Themen Canonicals, Metadaten, strukturierte Daten, Redirects, interne Links oder client-gerenderte Widgets, die Inhalte vor Crawlern verstecken, nicht automatisch. Beurteile das bereitgestellte HTML – nicht das Framework-Label.

Was statische Sites tatsächlich „von selbst“ mitbringen

Ein Static-Site-Generator wie Astro, Hugo, 11ty, Jekyll, Gatsby oder Next.js im Static-Export-Modus führt Templates und Content während des Builds aus. Er erzeugt HTML-Dateien plus die für jede Seite benötigten CSS-, JavaScript- und Asset-Dateien. Die Hosting-Schicht kann diese Dateien ausliefern, ohne bei jeder Anfrage eine Datenbank abzufragen oder die Seite serverseitig zu rendern.

Das ist wichtig, weil Google Seiten über Crawling, Rendering, Indexierung und Serving verarbeitet. Unser Guide zu wie Google Indexierung funktioniert erklärt diese Phasen im Detail. Der Vorteil statischer Sites ist dabei simpler: Wenn Copy und Links bereits im heruntergeladenen HTML stehen, muss Google kein JavaScript ausführen, um sie zu entdecken.

„Behalte im Hinterkopf, dass serverseitiges oder pre-rendering trotzdem eine großartige Idee ist, weil es deine Website für Nutzer und Crawler schneller macht – und nicht alle Bots JavaScript ausführen können.“

Das ist die Formulierung von Google Search Central in Understand the JavaScript SEO basics. Das ist auch das stärkste Argument für Static-Site-SEO: Pre-rendering entfernt eine Abhängigkeit. Es erzeugt keine Relevanz, keine Authority, kein nützliches Schreiben und keine kohärente Architektur (ich würde die vier Punkte gern per Build-Command delegieren).

Statische Dateien lassen sich außerdem leicht an CDN-Edges cachen. Wenn du pro Anfrage kein Rendering mehr brauchst, entfernst du eine Quelle für Latenz und Ausfälle. In der Web-Vitals-Dokumentation von Google wird „gute“ Performance so definiert: LCP innerhalb von 2,5 Sekunden, INP von 200 Millisekunden oder weniger sowie CLS von 0,1 oder weniger. Diese Schwellenwerte werden am 75. Perzentil bewertet – getrennt für Mobile- und Desktop-Traffic.

Übersetze das nicht in „statische Sites bestehen automatisch die Core Web Vitals“. Ein 3-MB-Hero-Image, render-blockierende Fonts, Third-Party-Skripte und ein großer Hydration-Bundle können LCP oder INP trotzdem noch kaputtmachen. Statische Architektur verschafft dir Spielraum, um gut zu performen. Sie erzwingt aber kein Asset-Budget.

Und auch: Geschwindigkeit allein sorgt nicht dafür, dass eine irrelevante Seite rankt. Geschwindigkeit ist Infrastruktur – kein Ersatz für Nachfrage, Content oder Links.

Der View-Source-Test erwischt den größten Jamstack-SEO-Fehler

Eine statische Site kann immer noch eine JavaScript-App sein – nur mit „statischem Shell“-Anschein.

Astro-Islands, React-Widgets, client-geholte Produkt-Grid-Ansichten, Review-Components, Kommentare und „Load more“-Listen füllen sich möglicherweise erst nach dem Hydrieren. Wenn SEO-relevanter Content über eine API-Anfrage im Browserside-Kontext kommt, fehlt er in der ursprünglichen Antwort. Dann bist du wieder im JavaScript-SEO-Terrain, auch wenn beim Deployment HTML-Dateien enthalten sind.

Google beschreibt das App-Shell-Problem ganz direkt: „Das initiale HTML enthält nicht den eigentlichen Content“, weshalb Google JavaScript ausführen muss, bevor es den generierten Content sehen kann. In der Dokumentation heißt es außerdem, dass eine Seite „für ein paar Sekunden in der Rendering-Queue bleiben kann, aber auch länger dauern“ kann. Einige Bots können JavaScript gar nicht ausführen.

Öffne die ausgelieferte URL und nutze „View source“. Verlass dich nicht auf das Elements-Panel in DevTools, weil es den DOM zeigt, nachdem Skripte ihn verändert haben. Suche im Quelltext nach der Headline, mehreren markanten Sätzen, wichtigen Links, Produktdetails sowie Image-Alt-Attributen.

Wenn sie fehlen, verlagere die Daten in den Build. Hole sie beim Generieren und rendere den Artikel, die Liste, Reviews oder Produktinformationen direkt in das ausgegebene HTML. Halte Browser-JavaScript für Interaktion zurück – nicht für den primären Content. Unser Framework-Guide erklärt, wie du Next.js-, React- und Nuxt-Content auf der richtigen Seite dieser Grenze hältst.

Ich habe diesen Test schon auf Seiten scheitern sehen, die in Chrome komplett wirkten. Der Browser hatte die Daten schnell genug nachgeladen, sodass bei der Durchsicht nichts auffällig war – aber „view-source“ enthielt kaum mehr als ein Root-Element und Script-Referenzen. Ein grünes Deployment-Checkmark ist kein Indexing-Test (und leider auch kein „works on my machine“).

Das ist die Unterscheidung, die mir über alle statischen Sites hinweg bei SEOJuice am wichtigsten ist. Framework-Auswahl bekommt viel Aufmerksamkeit, aber der Crawler erhält eine HTTP-Antwort – nicht deine Architektur-Absichten.

Die SEO-Arbeit, die dein Generator bei dir lässt

XML-Sitemap erzeugen und prüfen

Das Verhalten von Sitemaps unterscheidet sich je nach Generator. Hugo generiert sitemap.xml standardmäßig; in der Dokumentation gibt es sogar einen Abschnitt zum Deaktivieren der Sitemap-Generierung – ein Hinweis, dass sie aktiv ist, solange du sie nicht abschaltest.

Astro geht einen anderen Weg. In der Sitemap-Dokumentation steht, dass @astrojs/sitemap die URL der deployed Site braucht, bevor es eine Sitemap generieren kann. Sobald konfiguriert, ergänzt die Integration Sitemap-Index- und Sitemap-Dateien im Output-Ordner.

Bei anderen Generatoren solltest du die aktuelle Dokumentation und das Plugin-Ökosystem prüfen, statt anzunehmen, dass eine Sitemap existiert. Der Test besteht nicht darin, ob eine Abhängigkeit in deiner Package-Datei auftaucht. Der Test ist: Lädt die ausgelieferte Sitemap, liefert sie den richtigen Content-Type zurück und enthält sie die Produktions-URLs, die du wirklich indexieren lassen willst?

Danach prüfe ein Beispiel. Achte auf Staging-Hosts, nicht-kanonische Slash-Varianten, Parameter-URLs, fehlende Abschnitte und Seiten, die ausgeschlossen sein sollten. Eine Sitemap kann syntaktisch korrekt sein – aber eine falsche Site beschreiben.

Astro verdient besondere Aufmerksamkeit, weil die konfigurierte Site-URL auch hilfreich ist, um absolute URLs zu bauen. Unser Astro SEO-Checkliste geht bei Sitemaps, Canonicals und island-spezifischen Problemen noch tiefer ins Detail.

Canonicals aus der Produktions-URL ableiten

Static-Site-Generatoren entscheiden in der Regel nicht automatisch für dich, welche Canonical-URLs gelten sollen. Dein Layout muss für jede indexierbare Seite eine Canonical erzeugen – mithilfe der Produktions-Base-URL und des normalisierten Pfads der Seite. Eine Staging-Domain oder ein localhost-Wert, der in die Produktion hineinkompiliert ist, zeigt Suchmaschinen auf die falsche Version.

Relative Canonicals sind eine weitere vermeidbare Mehrdeutigkeit. Erzeuge absolute URLs und definiere dann eine Policy für abschließende Slashes, Indexdateien und die Groß-/Kleinschreibung von URLs. Deine Canonical, internen Links, Sitemap-Einträge und Redirect-Regeln sollten konsistent zueinander passen.

Wir haben SEOJuice im Januar 2026 von seojuice.io auf seojuice.com umgestellt. Die sichtbare Navigation war der einfache Teil. Die eigentliche Migrationsoberfläche umfasste Canonical-Tags, Sitemap-Einträge, interne Links, strukturierte-Daten-URLs, Asset-Referenzen und Redirects auf Host-Ebene. Eine alte Hostname-Variante, die in einem geteilten Template steckt, kann unbemerkt vor dem Deploy in jede generierte Seite kopiert werden (eine wunderbar effiziente Methode, um einen Fehler zu skalieren).

Ich vertraue keiner universellen Canonical-Komponente, die zwischen Frameworks kopiert wird. Base-Paths, Slash-Verhalten, URL-Helper und Environment-Variablen unterscheiden sich. Prüfe das finale HTML unter der finalen URL. Templates sind Implementationsdetails; das ausgelieferte Output-Ergebnis ist das, was Crawler erhalten.

Nicht überall denselben Titel ausspielen

Seitentitel, Meta-Descriptions, Open-Graph-Felder und Social-Tags kommen meistens aus Front Matter, das in ein gemeinsames Layout übergeben wird. Wenn das Front Matter fehlt oder das Fallback zu allgemein ist, können Hunderte Seiten denselben generischen Titel erben.

Lege essenzielle Metadaten explizit im Content-Modell fest. Gib jeder indexierbaren Seite einen eindeutigen, beschreibenden Titel und eine passende Beschreibung. Definiere Fallback-Logik für vorhersehbare Fälle, aber lass keine Site-weite Brand-Zeichenkette stillschweigend zum Titel jeder Seite werden.

Crawle anschließend die generierte Site auf Duplikate, leere Werte, fehlerhafte Tags und unerwartet lange Inhalte. Statische Generierung erzeugt Konsistenz – inklusive konsistenter Fehler.

Strukturierte Daten direkt auf der echten Seite hinzufügen

Google Search Central definiert strukturierte Daten als „ein standardisiertes Format, um Informationen über eine Seite bereitzustellen und den Inhalt der Seite zu klassifizieren.“ Google empfiehlt JSON-LD und sagt, dass das Markup auf der Seite platziert werden soll, die es beschreibt.

Das Objekt muss zum sichtbaren Content passen und alle erforderlichen Properties enthalten, damit es für Enhanced Presentations in Search in Frage kommt. Die Eignung ist keine Garantie für ein Rich Result. Schema klärt Bedeutung für Maschinen; es zwingt Google nicht dazu, ein Ergebnis auszuschmücken.

Erzeuge strukturierte Daten möglichst aus derselben Quelle wie der sichtbare Content. Wenn du Produktnamen, Preise, Daten und Autorinformationen in getrennten manuellen Feldern duplizierst, entsteht Drift. Validere repräsentative Seitentypen nach dem Deployment – nicht nur das JSON-LD-Template isoliert.

Schreibe die unsexy Basics sauber

Du brauchst weiterhin eine korrekte robots.txt-Datei, nützlichen Image-Alt-Text, konsistente Heading-Hierarchien, beschreibende Anchors und interne Links. Static Generation verhindert keine verwaisten Seiten. Eine URL kann im Output-Ordner und in der Sitemap existieren, aber dennoch von den Pfaden getrennt sein, denen Nutzer und Crawler folgen.

Was wir über Sites hinweg sehen, die SEOJuice nutzen, ist: Genau hier hört die „saubere Architektur“ oft auf, hilfreich zu sein. Die Site baut schnell und liefert schnell aus, aber verwandte Seiten sind nicht miteinander verbunden, die Metadatenabdeckung ist ungleichmäßig, und alter Content liegt mehrere Ebenen entfernt von jeder aktuellen Seite. Keine dieser Schwächen erfordert eine Framework-Migration. Sie braucht Pflege.

Viele davon sind lästige Handarbeit. Meistens. Aber eben mit echten Auswirkungen.

Redirects gehören in Host oder CDN

Ein rein statisches Deployment hat keinen serverseitigen Application-Router, der pro Anfrage läuft. Redirects gehören deshalb in die Hosting- oder CDN-Schicht – nicht in eine Client-Side-Component.

Netlifys Dokumentation sagt, dass sein Redirects-Engine die erste passende Regel von oben nach unten verarbeitet und standardmäßig 301 nutzt. Die Reihenfolge ist entscheidend. Eine breite Wildcard oberhalb einer spezifischen Migrationsregel kann die Anfrage als Erstes abfangen.

Vercel macht Redirects, Clean URLs und das Verhalten bei abschließenden Slashes als Projektkonfiguration sichtbar. Cloudflare Pages unterstützt ebenfalls eine _redirects-Datei, aber standardmäßig ist es 302 statt Netlifys 301. Setze den Status explizit, wenn du eine permanente Weiterleitung meinst (ich musste diesen Unterschied zweimal prüfen; identische Dateinamen fördern die falsche Annahme).

Halte die Redirect-Map neben der Quelle und teste alte URLs nach dem Deployment. Decke umbenannte Seiten, konsolidierte Artikel, Domain-Varianten, Protokollwechsel und deine gewählte Slash-Policy ab. Teste den zurückgegebenen Status und das Ziel – inklusive Redirect-Ketten.

Ein Client-Side-Router, der einen alten Pfad sieht und die Browser-URL ändert, ist nicht dasselbe. Die ursprüngliche Antwort bleibt 200 oder 404, und Clients ohne JavaScript bekommen den beabsichtigten Redirect nie.

Dynamic Features sind ok – solange sie nicht im primären Content-Pfad hängen

Formulare können eine Host-Funktion, einen Third-Party-Endpoint oder eine serverlose Funktion nutzen. Die Interaktion beim Absenden ist kein indexierbarer Content, aber die Seite sollte vorgerenderten Text enthalten, der erklärt, was das Formular macht.

Client-seitige Suche kann einen lokalen Index oder eine gehostete API verwenden. Suchergebnisse sollten in der Regel nicht der einzige Entdeckungsweg für deinen Content sein. Jedes wichtige Ergebnis braucht seine eigene statische URL und mindestens einen crawlbaren internen Link außerhalb der Suchoberfläche.

Kommentare und Review-Widgets erfordern mehr Sorgfalt. Wenn sie erst nach dem Laden hydrieren, ist ihr Content möglicherweise nicht im ursprünglichen HTML vorhanden. Wenn Reviews eine Produktseite wirklich inhaltlich stützen, rendere die relevanten Review-Inhalte während des Builds und generiere die passenden strukturierten Daten aus derselben Quelle.

Personalisierung, Empfehlungen und Experimente können clientseitig bleiben, sofern die primäre Seite nicht von ihnen abhängt. Meine Regel ist ziemlich klar: Entscheide indexierbaren Content während des Builds; ergänze optionale Interaktion im Browser.

Ein Release-Prozess, der statische SEO-Defekte erkennt

1. Build mit Produktionskonfiguration. Prüfe, ob der echte Hostname und der Base Path für Templates verfügbar sind.
2. Rohes HTML prüfen. Kontrolle auf Titel, Beschreibungen, Canonicals, Headings, Links, Alt-Text, JSON-LD und den primären Content.
3. Sitemap und robots.txt öffnen. Verifiziere, dass beides deployed ist und intern konsistent ist.
4. JavaScript deaktivieren. Bestätige, dass die wichtigsten Informationen und die Navigation verfügbar bleiben.
5. Alte URLs testen. Verifiziere, dass der Host den gewünschten Status und das finale Ziel liefert.
6. Repräsentative Seiten messen. Vergleiche sie mit den LCP-, INP- und CLS-Schwellenwerten, statt anzunehmen, „statisch“ bedeutet automatisch schnell.
7. Nach dem Deployment crawlen. Finde doppelte Metadaten, fehlende Canonicals, verwaiste Seiten, kaputte Links und unerwartete Statuscodes.

Durchlaufe diesen Prozess für Seitentypen – nicht nur für die Startseite. Blogbeiträge, Produktseiten, Pagination, Tag-Archive, Dokumentationsseiten und Landingpages nutzen oft unterschiedliche Layouts. Eine gesunde Startseite sagt dir über Tausend generierte URLs fast nichts.

Für Migrationen behalte die alte URL-Liste und teste sie nach dem Release automatisiert. Beim SEOJuice-Domain-Move haben wir gelernt: Migrationschecks müssen auch abdecken, was Nutzer nicht sehen können – genau so wie das, was sie sehen. Canonicals und strukturierte-Daten-Identifiers sind bei einer rein visuellen Prüfung leicht zu übersehen.

Wo SEOJuice passt – und wo nicht

SEOJuice setzt fortlaufend interne Links, Meta-Titel und -Beschreibungen, Schema-Markup sowie Image-Alt-Text auf eine Live-Site. Du kannst es über ein JavaScript-Snippet oder ein WordPress/CMS-Plugin installieren, und es gibt einen kostenlosen Tarif ohne Kreditkarte.

Für statische Sites gibt es eine wichtige Grenze. Per Snippet injizierte Metadaten, Schema und Links hängen von Client-Side-Rendering ab – daher sind sie nicht Teil des ursprünglichen Crawl-Schritts im HTML und können für Nicht-JavaScript-Bots nicht verfügbar sein. Halte primären Content, Canonicals, essentielle Titel und Beschreibungen sowie kritisches JSON-LD im generierten HTML, solange du den Build kontrollierst. Nutze das Snippet für On-Page-Arbeit im Incremental-Stil, die bei Problemen sinnvoll degradieren kann – nicht als Ausrede, eine leere Shell auszuliefern.

SEOJuice ersetzt außerdem nicht deine Sitemap, CDN-Redirects, Build-Architektur oder Content-Strategie. Wenn du sehen willst, welche Teile der On-Page-Schicht fehlen, starte mit der kostenlosen SEO-Analyse. Behebe zuerst strukturelle Probleme im Build, und automatisiere dann die wiederkehrende Schicht, wenn genau dieser Trade-off sinnvoll ist.

Häufig gestellte Fragen

Sind statische Sites gut für SEO?

Ja – als Startarchitektur. Vorgerendertes HTML entfernt die Abhängigkeit vom JavaScript-Rendering für Content, der in der Quelle vorhanden ist, während die CDN-Auslieferung starke Performance leichter macht. Du brauchst trotzdem relevanten Content, Metadaten, Canonicals, eine Sitemap, strukturierte Daten, interne Links und Redirects.

Brauchen statische Sites eine XML-Sitemap?

Ja. Hugo generiert sitemap.xml standardmäßig, während Astro sein Sitemap-Integrationsteil und eine konfigurierte Site-URL benötigt. Andere Generatoren brauchen möglicherweise projektbezogene Einstellungen oder ein Plugin. Prüfe die ausgelieferte Sitemap, statt anzunehmen, der Build hätte sie korrekt erstellt.

Ist Jamstack gut für SEO?

Jamstack kann die gleichen Vorteile liefern wie andere statische Architekturen: vorgerenderte Markups und CDN-Delivery. Das Risiko entsteht, wenn wichtiger Content über browserseitige APIs geladen wird. Wenn er im gebauten HTML fehlt, muss Google JavaScript rendern, um ihn zu sehen – und andere Bots könnten ihn komplett verpassen.

Wie richte ich Redirects auf einer statischen Site ein?

Konfiguriere sie im Host oder im CDN. Netlify unterstützt _redirects und netlify.toml, Vercel nutzt Projektkonfiguration und Cloudflare Pages unterstützt eine _redirects-Datei. Permanente Statuscodes musst du bewusst setzen, Regeln gehören in die Versionierung, und teste die HTTP-Antwort nach dem Deployment.

Indexiert Google JavaScript auf statischen Sites?

Google kann JavaScript rendern, aber das Rendering passiert nach dem Crawling und kann aufgeschoben sein. Google weist außerdem darauf hin, dass nicht alle Bots JavaScript ausführen können. Wenn primärer Content erst nach dem Hydrieren erscheint, rendere ihn in das gebaute HTML – statt dich auf das Ausführen im Browser zu verlassen.

Brauchen statische Sites weiterhin Meta-Tags und Canonical-Tags?

Ja. Static-Site-Generatoren erfinden nicht zuverlässig eindeutige Titel, Beschreibungen, Open-Graph-Tags oder Canonical-URLs für jedes Projekt. Generiere sie aus den Seitendaten, nutze die Produktions-Base-URL für absolute Canonicals, und prüfe das finale HTML auf Duplikate oder Staging-Werte.