Astro-SEO

TL;DR — Astro ist eine gute Wahl für SEO. Standardmäßig erstellt Astro Ihre Seiten im Voraus als einfache HTML-Dateien. Wenn Google (oder ein anderer Bot) auftaucht, ist Ihr Inhalt also bereits vorhanden — Sie müssen nicht warten, bis JavaScript ausgeführt wird. Außerdem ist Astro sehr schnell. Wichtig ist nur: Astro liefert sauberes HTML, fügt Ihre Seitentitel, Sitemap oder Canonical-Tags aber nicht automatisch hinzu. Sie richten diese selbst ein (das ist einfach).

Was „Astro SEO“ bedeutet

Astro ist ein Webframework zum Erstellen von Websites. Die Grundidee lautet „weniger JavaScript“. Während Frameworks wie React oder Next.js die Seite oft mit JavaScript im Browser aufbauen, erstellt Astro Ihre Seiten zur Build-Zeit als einfache HTML-Dateien und liefert fast kein JavaScript aus, sofern ein Seitenteil es nicht tatsächlich benötigt. Evidence for this claim Astro prerenders pages as static HTML by default and only sends client JavaScript for explicitly hydrated components. Scope: Astro default static output and islands architecture. Confidence: high · Verified: 2026-07-14 Astro: Why Astro

Dieser eine Unterschied macht Astro so suchmaschinenfreundlich. Wenn eine Suchmaschine eine Seite crawlt, möchte sie Ihren Inhalt lesen. Bei einer JavaScript-lastigen Website ist der Inhalt manchmal noch nicht in der Seite vorhanden — der Bot muss zuerst JavaScript ausführen, und das kann verzögert werden. Bei Astro ist der Inhalt bereits in dem Moment im HTML, in dem die Seite geladen wird. Es gibt nichts abzuwarten.

Ich betreibe meine eigene Website patrickstox.com mit Astro — das ist für mich also keine Theorie. Es ist der Stack, auf dem ich tatsächlich aufbaue.

Warum Astro gut für SEO ist

• Der Inhalt ist sofort im HTML. Keine Rendering-Verzögerung, kein fehlender Inhalt.
• Astro ist schnell. Astro-Seiten sind leichtgewichtig und erzielen bei Googles Metriken zur Seitenerfahrung (Core Web Vitals) meist sehr gute Werte.
• Jede Seite hat eine eigene echte URL. Kein ausgefeiltes Single-Page-App-Routing, das Crawler verwirren kann.
• JavaScript wird nur geladen, wo es benötigt wird. Eine Fotogalerie oder ein Suchfeld kann interaktiv sein, ohne den Rest der Seite zu verlangsamen.

Was Astro NICHT für Sie erledigt

Das führt oft zu Missverständnissen. „Astro ist für SEO optimiert“ stimmt nur zur Hälfte. Astro bietet eine saubere Grundlage, fügt aber nicht automatisch Folgendes hinzu:

• Ihre Titel und Meta-Beschreibungen schreiben.
• Eine Sitemap erzeugen (dafür fügen Sie ein kostenloses offizielles Plugin hinzu). Evidence for this claim Astro's official sitemap integration generates sitemap files from statically generated routes. Scope: Astro @astrojs/sitemap integration. Confidence: high · Verified: 2026-07-14 Astro: Sitemap integration
• Canonical-Tags hinzufügen (sie teilen Google die „offizielle“ Version einer Seite mit).
• Strukturierte Daten hinzufügen (der Code, der Rich Results ermöglicht).
• Eine robots.txt-Datei erstellen.

Nichts davon ist schwierig — Sie müssen es nur selbst einrichten. Stellen Sie sich Astro als eine großartige Küche vor: Die Geräte sind ausgezeichnet, aber kochen müssen Sie trotzdem selbst.

Die einfache Start-Checkliste

• Fügen Sie mit dem offiziellen Plugin @astrojs/sitemap eine Sitemap hinzu.
• Setzen Sie auf jeder Seite eine title-, description- und canonical-URL (normalerweise aus einer gemeinsamen Layout-Datei).
• Verwenden Sie für Fotos Astros integrierte Komponente <Image /> — sie sorgt für schnelles Laden und verhindert, dass die Seite springt.
• Legen Sie eine robots.txt-Datei in Ihrem Ordner public/ ab.

Möchten Sie die ausführliche Version — Server Islands, View Transitions, statisches Rendering gegenüber Server-Rendering und die genauen Fehler, die Sie vermeiden sollten? Wechseln Sie zum Tab Fortgeschritten. Für das größere Bild davon, wie Suchmaschinen mit JavaScript umgehen, siehe JavaScript SEO.

TL;DR — Astro ist architektonisch gut für SEO aufgestellt: Seiten und Endpunkte werden standardmäßig als statisches HTML prerendered, sodass Sie für diesen Inhalt nicht auf eine Rendering-Welle warten müssen — das ist aber ein Standard und keine universelle Garantie. Statisches oder serverseitiges HTML beweist für Ihre produktiven URLs nicht automatisch Crawlability, Indexierung, Rankings oder Core Web Vitals. Die Islands-Architektur hydratisiert nur die Komponenten, die Sie mit einer client:*-Direktive markieren — alles andere liefert HTML ohne eigene Hydration-JS aus, auch wenn Seitenskripte, andere Islands und Router-Erweiterungen an anderer Stelle noch JavaScript hinzufügen können. Astro erzeugt Meta-Tags, Canonicals, Sitemaps oder strukturierte Daten nicht automatisch — richten Sie diese ausdrücklich ein, idealerweise validiert durch Content Collections und Zod. Server Islands (für die ein Adapter erforderlich ist) liefern im Anfangsdokument die statische Hülle mit Fallback-Inhalt und rufen den zurückgestellten Inhalt danach unabhängig ab — prüfen Sie, was ein konkreter Crawler tatsächlich abruft, statt es anzunehmen. View Transitions verwenden history.pushState und sind SEO-sicher; Google crawlt die zugrunde liegenden MPA-Seiten normal. Ich betreibe patrickstox.com mit Astro, und die folgenden Funktionen sind die, die ich tatsächlich nutze — validiert gegen die bereitgestellte Website, nicht nur gegen die lokale Entwicklungsumgebung.

Wie Astro das JavaScript-Rendering-Problem vollständig umgeht

Der gesamte Grund, warum JavaScript-SEO schwierig ist, liegt in der zweiten Welle. Google ruft zuerst Ihr rohes HTML ab und stellt die Seite später in einem Headless-Chromium zur Darstellung in eine Warteschlange — und genau diese Warteschlange ist das Risiko. Googles eigene Dokumentation beschreibt es so: “Googlebot queues all pages with a 200 HTTP status code for rendering unless a robots meta tag tells Google not to index the page. The page may stay on this queue for a few seconds, but it can take longer than that.” (Übersetzung) „Googlebot stellt alle Seiten mit einem HTTP-Statuscode 200 zur Darstellung in eine Warteschlange, sofern ein robots-Meta-Tag Google nicht anweist, die Seite nicht zu indexieren. Die Seite kann einige Sekunden in dieser Warteschlange bleiben, aber es kann auch länger dauern.“ Bei einer clientseitig gerenderten SPA existiert Ihr Inhalt erst, wenn diese Rendering-Welle ausgeführt wird.

Astros standardmäßiger Ausgabemodus ist static: Seiten und Endpunkte werden zur Build-Zeit in eine vollständige HTML-Datei prerendered. Für eine Route in diesem Standardmodus ist das rohe HTML also die gerenderte Seite. Evidence for this claim Astro uses static output and prerenders routes at build time by default. Scope: Astro default output mode; routes can opt out of prerendering. Confidence: high · Verified: 2026-07-14 Astro: On-demand rendering Es gibt für diese Route keine zweite Welle abzuwarten, weil nichts mehr ausgeführt werden muss. Googlebot sieht den vollständigen Inhalt beim ersten Abruf. Wie Joost de Valk (Gründer von Yoast) sagt: „Aus SEO-Sicht ist statisches HTML auf einem CDN ein besserer Ausgangspunkt, als ihn die meisten CMS jemals bieten werden.“

Das ist allerdings der Standard — keine universelle Eigenschaft jeder Route. Setzen Sie output: 'server', wechselt der Standard zu On-Demand-Rendering (mehr dazu weiter unten). Auch in einem Projekt mit statischem Standardmodus kann ein Adapter einer einzelnen Route mit export const prerender = false den Ausstieg ermöglichen. Nichts davon wird allein durch die Architektur garantiert: Statisches oder serverseitiges HTML, Islands und Adapter garantieren für sich genommen weder Crawlability, Indexierung, Rankings noch Core Web Vitals — das hängt von der bereitgestellten Route und dem konkreten Crawler ab. Prüfen Sie es, statt anzunehmen, dass das Framework es erledigt.

Das hilft auch bei den Crawlern, die überhaupt nicht rendern können. Google weist ausdrücklich darauf hin, dass “not all bots can run JavaScript” (Übersetzung) „Nicht alle Bots können JavaScript ausführen“ — und das ist 2026 für die meisten KI-Crawler und viele Tools von Drittanbietern Realität. Astros HTML-first-Ausgabe ist überall dort, wo tatsächlich prerendered wird, für alle diese Bots lesbar, nicht nur für Googlebot. (Das ist derselbe Punkt, den ich in SEO für ein Headless CMS mache: Der Rendering-Modus ist das Produkt.)

Islands-Architektur: JS nur dort, wo Sie es anfordern

Astro rendert Ihre Komponenten zu HTML und liefert in den eigenen Worten “just HTML & CSS, stripping out all client-side JavaScript automatically.” (Übersetzung) „Nur HTML und CSS, wobei sämtliches clientseitiges JavaScript automatisch entfernt wird“. Interaktivität ist optional. Sie markieren eine Komponente mit einer client:*-Direktive — client:load, client:idle oder client:visible — und nur dieses Island wird mit JavaScript hydratisiert. Alles andere bleibt statisches HTML. Evidence for this claim Astro client directives selectively hydrate interactive islands while other components remain static HTML. Scope: Astro islands and client directives. Confidence: high · Verified: 2026-07-14 Astro: Islands

Für SEO ist das nahezu ideal. Der Inhalt, den Googlebot indexieren muss, ist einfaches HTML, und Ihre interaktiven Widgets ziehen ihn nicht herunter. client:visible ist besonders nützlich: Eine Komponente unterhalb des sichtbaren Bereichs beginnt erst mit der Hydration, wenn sie in den sichtbaren Bereich scrollt, und blockiert daher niemals Ihr LCP. Das Konzept stammt von Jason Miller (dem Erfinder von Preact), der „das Rendern von HTML-Seiten auf dem Server und das Einfügen von Platzhaltern oder Slots um hochdynamische Bereiche“ für selektive Hydration beschrieben hat.

Zwei Nuancen verdienen eine präzise Darstellung, weil Berichte von Wettbewerbern sie häufig verwischen:

• client:only ist etwas anderes. Anders als client:load/client:idle/client:visible überspringt eine client:only-Komponente das serverseitige Rendering vollständig — sie erzeugt auf dem Server überhaupt kein HTML. Alles Indexierbare, das nur in einer client:only-Komponente liegt, ist nicht in dem Dokument enthalten, das Googlebot abruft; es existiert erst, nachdem der Browser es hydratisiert hat. Legen Sie dort keine primären Inhalte ab.
• Das ist selektive Hydration, keine Resumability. Astro führt den Client-Code jedes Islands im Browser von Grund auf neu aus. Es setzt keinen Ausführungszustand fort, der auf dem Server serialisiert wurde, wie es ein Resumability-Modell (zum Beispiel das von Qwik) tut. In Texten werden beide Konzepte vermischt — sie sind nicht derselbe Mechanismus.

Und eine nicht hydratisierte Komponente ist nicht das gesamte JavaScript-Bild einer Seite. „Zero JS“ beschreibt eine Komponente ohne client:*-Direktive — Astro kann trotzdem Seitenskripte in <script>-Tags, den View-Transitions-Router und andere Islands an anderer Stelle derselben Seite ausliefern. Beschreiben Sie, was pro Komponente bzw. Route ausgeliefert wird, nicht pauschal, was auf der ganzen Seite geschieht.

Was Astro nicht automatisch erledigt

Astro erzeugt sauberes semantisches HTML — und in Bezug auf SEO sonst nichts. Es gibt standardmäßig keine Metadaten, keine Canonical-URL, keine Sitemap und keine strukturierten Daten. Der Mythos, „Astro sei automatisch für SEO optimiert“, ist genau das: ein Mythos. Sie sind zuständig für:

• Meta-Tags (Titel, Beschreibung, Open Graph, Twitter)
• Canonical-URLs
• Die Sitemap (über die offizielle Integration)
• Strukturierte Daten / JSON-LD
• robots.txt

Astro ist die beste Grundlage, die ich bisher verwendet habe, aber es ist eine Grundlage und kein fertiges Haus.

Die Sitemap: @astrojs/sitemap

Installieren Sie die Sitemap mit npx astro add sitemap. Sie crawlt Ihre statisch erzeugten Routen und gibt zur Build-Zeit eine sitemap-index.xml sowie aufgeteilte sitemap-0.xml-Dateien aus. Zwei Dinge bereiten Probleme:

• Sie müssen site: in astro.config.mjs setzen. Ohne diese Angabe erzeugt die Integration stillschweigend nichts. Das ist die häufigste Ursache für „Wo ist meine Sitemap?“
• Sie müssen die Sitemap-Zeile selbst zu robots.txt hinzufügen. Astro erledigt das nicht.

Für Kontrolle schließt filter() Routen aus (Preview-/Draft-Seiten — genau dafür verwende ich es auf dieser Website), mit serialize() können Sie lastmod/changefreq/priority setzen, und die Option i18n gibt hreflang-Einträge in der Sitemap aus. Das ist in der aktuellen Dokumentation von @astrojs/sitemap so festgelegt — prüfen Sie es gegen Ihre installierte Version, wenn Sie eine ältere Version verwenden; das Verhalten von Integrationen hat sich zwischen Major-Versionen bereits geändert.

Der Umfang, der oft übersehen wird: Die Integration entdeckt statisch erzeugte Routen. Wenn einige Ihrer URLs nur zur Laufzeit existieren — serverseitig gerenderte Routen (output: 'server') oder Routen, die bei Bedarf statt zur Build-Zeit erzeugt werden — nehmen Sie nicht an, dass sie in der Sitemap stehen. Fügen Sie sie mit customPages ausdrücklich hinzu und öffnen Sie nach einem Build tatsächlich sitemap-index.xml, um ihre Aufnahme zu bestätigen. Vertrauen Sie „die Integration erledigt das“ nicht für etwas, das keine statische Build-Zeit-Route ist.

Meta-Tags und Canonicals: das BaseLayout-Muster

Astro hat keine spezielle <Head>-Komponente — Sie steuern <head> direkt in .astro-Dateien. Das Standardmuster (und das, was ich verwende) ist ein einzelnes BaseLayout.astro, das title, description und canonicalURL als Props übernimmt und den Head schreibt. Setzen Sie den Canonical auf jeder Seite ausdrücklich und halten Sie ihn mit og:url konsistent. Sie brauchen keine Bibliothek, aber das Community-Paket astro-seo (npm) ist ein praktischer Wrapper aus einer Komponente für Titel/Beschreibung/OG/Twitter/Canonical, wenn Sie einen möchten.

Content Collections als SEO-Sicherheitsnetz

Das ist Astros unterschätztes SEO-Feature. Content Collections sind eine typsichere Inhaltsschicht für Markdown/MDX/JSON mit Zod-Schemavalidierung. Dadurch können Sie title und description zu Pflichtfeldern machen — fehlt eines auf einer Seite, schlägt der Build fehl. Sie können nicht versehentlich eine Seite ohne Titel ausliefern. Abfragefunktionen (getCollection(), getEntry()) erzeugen zur Build-Zeit statische Seiten, sodass die Ausgabe bei der Bereitstellung einfaches HTML ist. Und weil MDX rohes Markdown als Quelle der Wahrheit bewahrt, sind diese Dateien auch saubere Quellinhalte für KI-Crawler und Muster im Stil von llms.txt. Diese Website selbst basiert auf Content Collections mit Zod-validiertem Frontmatter.

astro:assets: Bilder richtig verwenden (mit einer Falle)

Die Komponente <Image /> konvertiert automatisch in WebP, ermittelt Abmessungen, um „Cumulative Layout Shift (CLS) zu vermeiden“, setzt standardmäßig loading="lazy" und verlangt alt — ein fehlendes alt ist ein Compile-Fehler. <Picture /> erweitert dies um AVIF/WebP-/Fallback-<source>-Elemente.

Die Falle: Das automatische loading="lazy" ist für Ihr LCP-Bild (normalerweise das Hero-Bild) falsch. Lazy Loading Ihres wichtigsten Bildes verzögert es. Überschreiben Sie bei Bildern oberhalb des sichtbaren Bereichs die Werte mit loading="eager" und fetchpriority="high". Remote-Bilder benötigen ausdrücklich width und height.

Server Islands: Was Crawler tatsächlich sehen

Server Islands (Astro 4.12+) sind die Funktion, die in den meisten Wettbewerberleitfäden falsch beschrieben wird. Mit server:defer rendert eine Komponente unabhängig von der Hauptseite auf dem Server. Die statische Hülle wird sofort ausgeliefert; laut Astros Dokumentation wird „Ihre Seite sofort mit jedem angegebenen Fallback-Inhalt als Platzhalter gerendert. Anschließend wird der eigene Inhalt der Komponente auf dem Client abgerufen und angezeigt, sobald er verfügbar ist.“

Zwei Dinge müssen präzise sein. Erstens benötigen Server Islands einen Adapter — sie sind eine On-Demand-Funktion und werden nicht von selbst durch einen rein statischen Build erzeugt. Zweitens lautet die Abfolge: Das Anfangsdokument wird mit dem von Ihnen konfigurierten Fallback-Inhalt ausgeliefert, und der echte Inhalt des Islands ist eine separate, unabhängige Anfrage, die nach dem Laden der Seite über einen eigenen Endpunkt abgerufen wird. Das setzt eine klare Untergrenze für den Inhalt des ersten Dokuments — ohne direkte Tests Ihrer bereitgestellten URLs würde ich daraus nichts Allgemeines über das weitere Verhalten jedes konkreten Crawlers ableiten.

Die SEO-Folge ist konkret: Das statische HTML, das ein Crawler beim ersten Abruf liest, enthält Ihren Fallback-Inhalt, nicht den zurückgestellten Inhalt des Islands. Das ist ideal für das, wofür Server Islands gedacht sind — personalisierte, sitzungsbezogene Dinge (Anmeldestatus, Warenkorbanzahl, Empfehlungen), die ohnehin nicht gecacht oder indexiert werden sollten. Für primäre indexierbare Inhalte ist es falsch. Legen Sie alles, was ranken soll, in die Hauptvorlage von Astro und überlassen Sie den dynamischen Teil den Server Islands.

Ausgabemodi: static vs. server und das Überschreiben pro Route

Astros standardmäßiger Ausgabemodus ist static — Seiten und Endpunkte werden zur Build-Zeit als HTML prerendered. Setzen Sie output: 'server' in astro.config.mjs, wechselt der Standard zu On-Demand-Rendering: Seiten werden pro Anfrage gerendert (mit einem Adapter), was für Authentifizierung, Echtzeitdaten oder Personalisierung jenseits der Möglichkeiten von Server Islands nützlich ist. In beiden Modi können Sie den Standard pro Route überschreiben: In einem Projekt mit statischem Standardmodus aktiviert export const prerender = false für eine Route On-Demand-Rendering; in einem Projekt mit Server-Standardmodus aktiviert export const prerender = true für eine Route wieder das Rendering zur Build-Zeit. „Meine Website ist statisch“ oder „meine Website verwendet SSR“ stimmt daher selten für jede Route — prüfen Sie die Einstellung pro Route und nicht nur die Konfiguration auf oberster Ebene.

Aus rein SEO-technischer Sicht sind prerendered und On-Demand-HTML gleichwertig — beide liefern beim ersten Abruf vollständiges HTML an einen Crawler, sobald Sie tatsächlich bestätigt haben, dass die Route einen 200-Status mit vollständigem Markup zurückgibt. On-Demand-Routen können ihr HTML streamen, und langsame Daten oder Netzwerkbedingungen können spätere Abschnitte verzögern. Eine gestreamte Antwort ist daher kein automatischer Beweis, dass jeder Inhalt angekommen ist — prüfen Sie es, statt es anzunehmen. Der echte Unterschied zwischen den Modi ist operativer Natur: Prerendered-Inhalt bleibt bis zum nächsten Build (oder einer separat eingerichteten Aktualisierung zur Laufzeit) unverändert und wird direkt vom CDN-Rand ausgeliefert; On-Demand-Inhalt ist stets aktuell, hängt aber davon ab, dass Adapter und Laufzeit in Produktion funktionieren. Behandeln Sie dies nicht als SEO-Entscheidung — wählen Sie nach Datenaktualität und Betrieb und validieren Sie danach die bereitgestellten Routen, Statuscodes, Weiterleitungen und Response-Header, statt von einem lokalen Entwicklungserfolg auszugehen.

View Transitions: trotz SPA-Gefühl SEO-sicher

Astros <ClientRouter /> (früher <ViewTransitions />) bietet eine SPA-ähnliche weiche Navigation mit der View-Transitions-API des Browsers und der History API. Der entscheidende Punkt: Die Navigation verwendet history.pushState, genau das, was Google für clientseitige Navigation empfiehlt — Google warnt, dass fragmentbasierte (#hash-)URLs etwas sind, das es „nicht zuverlässig auflösen kann“. Entscheidend ist: View Transitions sind eine browserseitige Erweiterung. Wenn Googlebot crawlt, fordert er jede URL an und erhält eine normale, vollständige HTML-Seite — die darunterliegende MPA bleibt unverändert. Die Übergänge beeinflussen nur, was ein Mensch im Browser sieht.

Nein, View Transitions machen Ihre Astro-Website nicht zu einer SPA und sie beschädigen SEO nicht. Eine erwähnenswerte Lücke: Astros Dokumentation zu View Transitions enthält keinen SEO-Abschnitt — vermutlich hält sich deshalb der Mythos, dass die Funktion SEO schadet. Rufen Sie zur Prüfung Ihrer eigenen Website einige URLs direkt ab und bestätigen Sie, dass jede vollständiges HTML zurückgibt — vertrauen Sie nicht darauf, prüfen Sie Ihre eigene Bereitstellung.

Häufige Astro-SEO-Fehler

1. Annehmen, dass Astro SEO für Sie erledigt. Astro erledigt HTML. Meta, Canonicals, Sitemap und Schema sind Ihre Aufgabe.
2. site: in der Konfiguration vergessen — Ihre Sitemap wird stillschweigend nicht erzeugt.
3. Die Sitemap nicht zu robots.txt hinzufügen — Astro tut das nicht.
4. Das LCP-Bild lazy laden — überschreiben Sie beim Hero-Bild eager + fetchpriority.
5. Indexierbare Inhalte in ein Server Island legen — Crawler sehen den Fallback statt des Inhalts, und Server Islands benötigen zunächst überhaupt einen Adapter.
6. Einem perfekten Lighthouse-Score hinterherlaufen und dort aufhören. Geschwindigkeit ist ein Ranking-Signal, nicht das Ranking-Signal. Eine schnelle leere Seite rankt nicht — Inhalt, Links und E-E-A-T leisten weiterhin die Hauptarbeit.
7. Indexierbare Inhalte nur in eine client:only-Komponente legen. Anders als die übrigen client:*-Direktiven überspringt client:only das serverseitige Rendering vollständig — für diese Komponente gibt es bis zur Hydration durch den Browser kein HTML.
8. „Astro ist statisch/schnell“ als Ergebnisgarantie behandeln. Statisches oder On-Demand-HTML, Islands und Adapter sind Mechanismen — sie garantieren für sich genommen weder Crawlability, Indexierung, Rankings noch Core Web Vitals. Validieren Sie die bereitgestellte Route und nicht das Architekturdiagramm.

Wo dies in den Cluster passt

Astro ist eine konkrete, ungewöhnlich SEO-freundliche Antwort auf die Fragen zu Rendering, die JavaScript SEO aufwirft, und ein beliebtes Frontend für Headless-CMS-Setups. Die Performance-Seite ist direkt mit Core Web Vitals im Web-Performance-Cluster verbunden, und die Disziplin, zu prüfen, ob der Inhalt tatsächlich im HTML steht, ist dieselbe wie in den Crawling- und Indexierungs-Clustern.

Astro-SEO-Anti-Patterns

Konkrete Fehler, die ich auf Astro-Websites tatsächlich sehe — keine hypothetischen. Jeder Punkt dient der Vorbeugung, nicht der Diagnose: Fangen Sie ihn ab, bevor er ausgeliefert wird.

Astro standardmäßig als „SEO-optimiert“ behandeln

Astro liefert schnelles, sauberes statisches HTML und verschafft Ihnen damit tatsächlich einen großen Vorsprung — aber das ist nicht dasselbe wie Meta-Tags, Canonicals, eine Sitemap oder strukturierte Daten. Warum das falsch ist: Teams liefern Seiten ohne Variation bei <title>, ohne Canonical und ohne Sitemap aus, weil „Astro SEO erledigt“, und wundern sich dann, warum nichts wie erwartet indexiert wird. Was Sie stattdessen tun: Binden Sie am ersten Tag Props für Titel/Beschreibung/Canonical in BaseLayout.astro ein, fügen Sie @astrojs/sitemap hinzu und behandeln Sie diese als erforderliche Build-Schritte, nicht als Standards.

site: in astro.config.mjs vergessen

Dies ist die häufigste Meldung „Warum ist meine Sitemap leer?“. Warum das falsch ist: @astrojs/sitemap benötigt eine absolute Website-URL, um absolute <loc>-Einträge zu erstellen — ohne gesetztes site: erzeugt die Integration stillschweigend nichts (keinen Fehler, keine Warnung). Was Sie stattdessen tun: Setzen Sie site: in astro.config.mjs, bevor Sie die Sitemap-Integration installieren, und prüfen Sie nach dem nächsten Build, ob sitemap-index.xml tatsächlich URLs enthält.

Die Sitemap aus robots.txt weglassen

Die Installation von @astrojs/sitemap fügt keine Sitemap:-Zeile in robots.txt hinzu — das ist ein separater manueller Schritt, den viele fälschlich für automatisch halten. Warum das falsch ist: Suchmaschinen können die Sitemap weiterhin finden, wenn Sie die Sitemap in der Search Console einreichen, aber Sie verlieren den passiven Entdeckungspfad, auf den sich andere Bots (und Bing-/IndexNow-nahe Crawler) verlassen. Was Sie stattdessen tun: Fügen Sie Sitemap: https://yoursite.com/sitemap-index.xml in Ihrer robots.txt unter public/ hinzu und bestätigen Sie nach der Bereitstellung, dass sie aufgelöst wird.

Das standardmäßige loading="lazy" beim Hero-Bild beibehalten

Astros <Image />-Komponente lädt standardmäßig lazy — das ist für Bilder unterhalb des sichtbaren Bereichs richtig und für das eine Bild falsch, das normalerweise Ihr LCP-Element ist. Warum das falsch ist: Lazy Loading des Hero-Bildes verzögert den Beginn seiner Anfrage durch den Browser und verschlechtert dadurch direkt Ihren Largest Contentful Paint. Was Sie stattdessen tun: Überschreiben Sie beim Hero- bzw. Bild oberhalb des sichtbaren Bereichs ausdrücklich loading="eager" und fetchpriority="high"; alle übrigen Bilder lassen Sie beim Lazy-Standard.

Indexierbare Inhalte in ein Server Island legen

server:defer ist für personalisierte, sitzungsbezogene Inhalte gedacht — Warenkorbanzahl, Anmeldestatus und Empfehlungen — und nicht für etwas, das ranken soll. Warum das falsch ist: Das statische HTML, das ein Crawler liest, enthält den für das Island angegebenen Fallback-Inhalt und nicht das, was nach dem Laden der Seite clientseitig abgerufen wird. Primäre Inhalte, die dort liegen, sind für Suchmaschinen beim ersten Crawling unsichtbar. Was Sie stattdessen tun: Halten Sie Ranking-Inhalte in der Hauptvorlage von Astro und reservieren Sie Server Islands ausschließlich für dynamische, personalisierte Bestandteile, die ohnehin nicht indexiert werden sollen.

Einen schnellen Lighthouse-Score als Ziellinie betrachten

Astro-Seiten erzielen fast standardmäßig starke Core Web Vitals, und es ist verlockend, dort aufzuhören. Warum das falsch ist: Geschwindigkeit ist eines von vielen Ranking-Signalen — eine schnelle, leere oder dünne Seite übertrifft keine langsamere Seite mit besseren Inhalten, Links und thematischer Tiefe. Was Sie stattdessen tun: Betrachten Sie Performance als Grundvoraussetzung, die Astro Ihnen kostenlos liefert, und verwenden Sie den eigentlichen Optimierungsaufwand auf Inhaltsqualität, interne Verlinkung sowie die strukturierten Daten und Meta-Arbeit, die Astro nicht für Sie erledigt.

„Statisch als Standard“ für jede Route annehmen

Astros statischer Ausgabemodus ist der Standard, aber ein Standard und keine universelle Eigenschaft — output: 'server' dreht ihn um, und prerender kann pro Route in beide Richtungen gesetzt werden. Warum das falsch ist: Teams beschreiben ihre gesamte Website anhand der Konfiguration auf oberster Ebene als „statisch“ oder „SSR“ und prüfen nie einzelne Routen. Dann sind sie überrascht, wenn sich eine Route in Produktion anders verhält. Was Sie stattdessen tun: Prüfen Sie für alles, worüber Sie eine Aussage treffen, die prerender-Einstellung pro Route und validieren Sie die tatsächliche Antwort (Statuscode, vollständiges Markup, Weiterleitungsverhalten) auf der bereitgestellten URL statt in der Konfigurationsdatei.

Inhalte nur in eine client:only-Komponente legen

client:only ist nicht dasselbe wie client:load/client:idle/client:visible — es überspringt das serverseitige Rendering vollständig. Warum das falsch ist: Eine Komponente mit client:only erzeugt auf dem Server kein HTML. Alles Indexierbare, das nur dort liegt, ist für einen Crawler, der die Rohantwort liest, unsichtbar. Außerdem greift man leicht aus „Einfachheit“ zu client:only, ohne die SEO-Kosten zu bedenken. Was Sie stattdessen tun: Rendern Sie primäre Inhalte in einer serverseitig gerenderten Komponente oder der Seitenvorlage und reservieren Sie client:only für Widgets, die nur Interaktion bieten und keine indexierbaren Inhalte enthalten.

AI summary

Eine komprimierte Zusammenfassung der Advanced-Version:

• Astros standardmäßiger Ausgabemodus prerendered zur Build-Zeit als statisches HTML — für eine Route in diesem Standardmodus ist das rohe HTML die fertige Seite, sodass das Problem der Google-Rendering-Warteschlange (die „zweite Welle“) dort nicht greift. Das ist ein Standard und keine universelle Eigenschaft: output: 'server' dreht ihn um und prerender kann pro Route in beide Richtungen überschreiben.
• Die Islands-Architektur hydratisiert nur Komponenten, die mit client:* markiert sind. Eine Komponente ohne diese Direktive liefert HTML ohne eigene Hydration-JS aus (auch wenn Astro an anderer Stelle Seitenskripte, andere Islands und Router-JS hinzufügen kann). client:only ist die Ausnahme — es überspringt das serverseitige Rendering vollständig; indexierbare Inhalte sollten daher nicht nur dort liegen. Das ist selektive Hydration, keine Resumability. client:visible verhindert, dass JS unterhalb des sichtbaren Bereichs das LCP blockiert.
• Astro erzeugt in Bezug auf SEO nichts automatisch — Meta-Tags, Canonicals, Sitemap, strukturierte Daten und robots.txt sind allesamt bewusste Build-Schritte. „Astro ist automatisch für SEO optimiert“ ist ein Mythos.
• @astrojs/sitemap entdeckt statisch erzeugte Routen — Sie müssen aber site: in der Konfiguration setzen (sonst geschieht stillschweigend nichts), die Sitemap-Zeile selbst zu robots.txt hinzufügen und alle URLs, die nur zur Laufzeit existieren, ausdrücklich über customPages ergänzen.
• Content Collections + Zod können title/description zu Pflichtfeldern machen und den Build fehlschlagen lassen, wenn sie fehlen — ein SEO-Sicherheitsnetz.
• astro:assets <Image> konvertiert in WebP, setzt Abmessungen (verhindert CLS), lädt standardmäßig lazy und verlangt alt. Überschreiben Sie beim LCP-Bild loading="eager" + fetchpriority="high".
• Server Islands (server:defer) benötigen einen Adapter, liefern die statische Hülle samt Fallback sofort im Anfangsdokument aus und rufen das Island danach unabhängig ab. Crawler, die dieses erste Dokument lesen, sehen den Fallback, nicht das Island — legen Sie indexierbare Inhalte niemals dort ab.
• Statische und On-Demand-(Server-)Ausgabe sind nach der Prüfung SEO-gleichwertig — beide liefern Crawlern beim ersten Abruf vollständiges HTML, aber On-Demand-Routen können streamen. Bestätigen Sie daher, dass die Antwort tatsächlich vollständig ankommt; wählen Sie den Modus nach Datenaktualität und Betrieb und nicht nach SEO.
• View Transitions (<ClientRouter />) verwenden history.pushState und sind SEO-sicher; Google crawlt die zugrunde liegenden MPA-Seiten normal. Sie sind eine browserseitige Erweiterung und keine Umwandlung in eine SPA.
• Nichts davon ist eine Ergebnisgarantie — statisches/serverseitiges HTML, Islands und Adapter sind Mechanismen und kein Beweis für Crawlability, Indexierung, Rankings oder Core Web Vitals. Validieren Sie die bereitgestellte Route.
• Astro erzielt in seinem eigenen Benchmark von 2023 starke Core Web Vitals. Mehr als 50 % der Astro-Seiten bestanden die CWV-Prüfung von Google und lagen damit deutlich über dem damaligen Branchenwert; behandeln Sie dies als datierten Datenpunkt und nicht als aktuelle Garantie.

Offizielle Dokumentation

Primärquellen-Dokumentation von Astro und den Suchmaschinen.

Astro

• Islands-Architektur — wie Astro clientseitiges JavaScript entfernt und nur interaktive Komponenten hydratisiert.
• Referenz für Template-Direktiven — client:load/idle/visible/only und server:defer, einschließlich dessen, was client:only überspringt.
• Bildoptimierung (astro:assets) — die Komponenten <Image>/<Picture>, WebP, Abmessungen und CLS.
• @astrojs/sitemap — automatische Sitemap-Erzeugung, filter, serialize und i18n.
• Server Islands — server:defer, Adapter-Anforderung, Fallback-Inhalt und verzögerter Client-Abruf.
• On-Demand-Rendering — die Ausgabemodi static/server, prerender pro Route und HTML-Streaming.
• Routing-Referenz — wie Seiten und Endpunkte standardmäßig prerendered werden.
• Referenz der Astro Runtime API — Umgang mit Response/Weiterleitungen und Standardstatuscodes.
• Content Collections — typsichere Inhalte mit Zod-Schemavalidierung.
• View Transitions — <ClientRouter /> und Navigation über die History API.

Google

• JavaScript-SEO-Grundlagen verstehen — die Rendering-Warteschlange, crawlbare Links, die History API und der Hinweis, dass nicht alle Bots JavaScript ausführen.
• Ausführlicher Leitfaden zur Funktionsweise der Google-Suche — Crawling → Rendering → Indexierung und wie SSG den Rendering-Schritt entfernt.

Bing / Microsoft

• IndexNow / indexnow.org — das Push-Protokoll, das gut zu einer statischen Astro-Bereitstellung passt (verbinden Sie es mit Ihrem Veröffentlichungs-Schritt, damit Bing und Yandex sofort von neuen statischen Seiten erfahren).

Zitate aus der Quelle

Wörtliche Aussagen aus Astros Dokumentation, von Google und von benannten Praktikern. Jeder Link zu einer Suchmaschine und Dokumentation führt direkt zur zitierten Passage auf der Quellseite.

Google — die Rendering-Warteschlange, die Astro umgeht

• “Googlebot queues all pages with a 200 HTTP status code for rendering unless a robots meta tag tells Google not to index the page. The page may stay on this queue for a few seconds, but it can take longer than that.” (Übersetzung) „Die deutsche Übersetzung steht im Haupttext.“ Zum Zitat
• “not all bots can run JavaScript” (Übersetzung) „Die deutsche Übersetzung folgt im Haupttext.“ — warum HTML-first-Ausgabe über Googlebot hinaus hilft. Zum Zitat

Astro-Dokumentation — Islands, Bilder, Sitemaps und Server Islands

• “just HTML & CSS, stripping out all client-side JavaScript automatically.” (Übersetzung) „Nur HTML und CSS, wobei sämtliches clientseitiges JavaScript automatisch entfernt wird“ — zur Islands-Architektur. Zum Zitat
• „ermittelt Bildabmessungen, um Cumulative Layout Shift (CLS) zu vermeiden“ — zur Image-Komponente. Zum Zitat
• “Your page will be rendered immediately with any specified fallback content as a placeholder. Then, the component’s own contents are fetched on the client and displayed when available.” (Übersetzung) „Ihre Seite wird sofort mit jedem angegebenen Fallback-Inhalt als Platzhalter gerendert. Anschließend wird der eigene Inhalt der Komponente auf dem Client abgerufen und angezeigt, sobald er verfügbar ist.“ — zu Server Islands. Zum Zitat

Jason Miller (Erfinder von Preact, prägte den Begriff „Islands-Architektur“)

• Selektive Hydration funktioniert durch „das Rendern von HTML-Seiten auf dem Server und das Einfügen von Platzhaltern oder Slots um hochdynamische Bereiche“. — zitiert in Astro-Dokumentation: Islands-Architektur

Joost de Valk (Gründer von Yoast SEO)

• „Aus SEO-Sicht ist statisches HTML auf einem CDN ein besserer Ausgangspunkt, als ihn die meisten CMS jemals bieten werden.“ — Joost.blog: Astro SEO Complete Guide

Astro-SEO-Checkliste

Ein Durchgang, um zu bestätigen, dass eine Astro-Website tatsächlich für die Suche eingerichtet ist — und nicht nur auf einer guten Grundlage sitzt:

• site: ist in astro.config.mjs gesetzt (ohne diese Angabe wird die Sitemap stillschweigend nicht erzeugt).
• @astrojs/sitemap ist installiert und der Sitemap-Verweis wurde manuell zu robots.txt hinzugefügt.
• robots.txt existiert in public/ und blockiert nichts, was Sie indexieren lassen möchten.
• Jede Seite setzt einen eindeutigen title und eine eindeutige description (idealerweise über ein gemeinsames BaseLayout.astro).
• Auf jeder Seite befindet sich ein selbstreferenzierender Canonical, der mit og:url übereinstimmt.
• Content Collections verwenden ein Zod-Schema, das title/description verlangt (der Build schlägt bei Fehlen fehl).
• Bilder verwenden <Image />/<Picture />; alle haben alt (ein fehlendes Attribut ist ohnehin ein Compile-Fehler).
• Das LCP-/Hero-Bild überschreibt das standardmäßige Lazy Loading mit loading="eager" und fetchpriority="high".
• Kein indexierbarer Inhalt liegt in einem Server Island (server:defer) — Crawler sehen den Fallback, und Server Islands benötigen einen Adapter.
• Kein indexierbarer Inhalt liegt nur in einer client:only-Komponente — sie überspringt das serverseitige Rendering, sodass bis zur Hydration keine HTML-Ausgabe dafür existiert.
• Bei jeder Route mit output: 'server' oder einer routebezogenen Einstellung prerender = false bestätigen, dass URLs nur zur Laufzeit ausdrücklich zur Sitemap hinzugefügt wurden (customPages) — die automatische Sitemap-Erkennung zielt auf statisch erzeugte Routen.
• Strukturierte Daten (JSON-LD) stehen im serverseitig gerenderten <head>.
• Wenn <ClientRouter /> aktiviert ist, prüfen Sie stichprobenartig, ob jede URL bei einem direkten Abruf weiterhin vollständiges HTML zurückgibt.
• On-Demand-/Server-Routen: Rufen Sie eine Live-Produktions-URL direkt ab und bestätigen Sie Statuscode, Weiterleitungsverhalten und vollständiges Antwort-HTML — leiten Sie nichts aus der lokalen Entwicklungsumgebung ab, da sich Adapter- und Laufzeitverhalten unterscheiden können.

Die mentalen Modelle

1. Das rohe HTML ist die fertige Seite — für den Standard dieser Route. Astros statischer Ausgabemodus bedeutet, dass Sie für eine prerendered Route nicht auf eine Rendering-Welle warten müssen — was Googlebot abruft, wird indexiert. Das ist ein Standard pro Route und keine Garantie für die gesamte Website (output: 'server' und prerender pro Route können dies ändern). Prüfen Sie deshalb die Route und nicht nur die Konfiguration auf oberster Ebene. Wenn dieser Modus gilt, ist „Quelltext anzeigen“ die Wahrheit (das Gegenteil einer CSR-SPA) — bestätigen Sie aber zuerst, dass er gilt, bevor Sie es als Tatsache behandeln.

2. Grundlage, nicht Abschluss und keine Ergebnisgarantie. Astro liefert Ihnen sauberes HTML und starke Performance-Mechaniken kostenlos. Alles, was Suchmaschinen Bedeutung signalisiert — Meta, Canonical, Sitemap und Schema — ist ein bewusster Schritt, den Sie ergänzen. „Gute Architektur“ ≠ „fertig“, und beides ist kein Beweis für Crawlability, Indexierung oder Rankings — diese müssen weiterhin auf der bereitgestellten Website validiert werden.

3. Islands sind additiv — außer client:only. Interaktivität liegt bei client:load/client:idle/client:visible auf dem HTML und nie darunter: Diese Direktiven fügen einer Komponente JS hinzu, ohne Inhalte aus der crawlbaren Grundlage zu entfernen. client:only durchbricht dieses Muster — es überspringt das serverseitige Rendering vollständig und ist daher nicht additiv, sondern eine echte Lücke im statischen HTML, sofern Sie nicht dafür planen. Die Hydration der Islands ist selektiv und keine Resumability — vermischen Sie beides nicht.

4. Die statische Hülle ist das, was Crawler sehen. Bei Server Islands liest der Crawler den Fallback in der statischen Hülle und nicht den zurückgestellten Inhalt. Entscheidungsregel: Indexierbare Inhalte gehören in die Hauptvorlage; personalisierte bzw. dynamische Inhalte gehören ins Island.

5. Browser-Erweiterung ≠ strukturelle Änderung. View Transitions verändern das Browser-Erlebnis (weiche Navigation über history.pushState), nicht aber das Crawl-Erlebnis (jede URL ist weiterhin eine vollständige HTML-Seite). Erweiterungen, die eine zugrunde liegende MPA intakt lassen, sind SEO-sicher.

6. Zur Build-Zeit validieren. Content Collections + Zod machen aus „Denk daran, einen Titel hinzuzufügen“ die Aussage „Der Build wird ohne Titel nicht ausgeliefert“. Verschieben Sie SEO-Anforderungen in das Typsystem; dann können sie nicht mehr einfach vergessen werden.

Astro SEO — Kurzüberblick

Was automatisch geschieht und was Sie erledigen müssen

Ausgabemodi

Islands-Direktiven

• client:load — sofort hydratisieren.
• client:idle — hydratisieren, wenn der Browser untätig ist.
• client:visible — hydratisieren, wenn der Bereich sichtbar wird (am besten für Inhalte unterhalb des sichtbaren Bereichs; schützt LCP).
• client:only — überspringt das serverseitige Rendering vollständig. Für diese Komponente gibt es bis zur Hydration durch den Browser kein HTML; anders als die übrigen Direktiven ist dies nicht additiv.

Schnelle Regeln

• site: fehlt → keine Sitemap (still).
• Indexierbare Inhalte in einem Server Island → Crawler sieht den Fallback; Server Islands benötigen einen Adapter.
• Indexierbare Inhalte nur in client:only → überhaupt kein HTML dafür.
• Sitemap umfasst statische Routen → reine Laufzeit-URLs über customPages hinzufügen.
• View Transitions verwenden history.pushState → SEO-sicher, MPA darunter.
• Statische/serverseitige Ausgabe und Islands sind Mechanismen, keine Garantien — Route, Statuscode und vollständiges HTML vor jeder Ergebnisaussage validieren.
• Eine schnelle leere Seite rankt weiterhin nicht — Geschwindigkeit ist ein Signal, nicht das Signal.

Astros erzeugtes HTML prüfen

Führen Sie dies nach astro build aus. Es prüft das von Crawlern empfangene Artefakt und nicht den Quellbaum der Komponenten:

find dist -name '*.html' -type f | while IFS= read -r file; do
  canonicals=$(grep -Eio '<link[^>]+rel=["'"']canonical["'"'][^>]*>' "$file" | wc -l | tr -d ' ')
  titles=$(grep -Eio '<title>[^<]*</title>' "$file" | wc -l | tr -d ' ')
  if [ "$canonicals" -ne 1 ] || [ "$titles" -ne 1 ]; then
    printf '%s\ttitles=%s\tcanonicals=%s\n' "$file" "$titles" "$canonicals"
  fi
done

Ein leeres Ergebnis bedeutet, dass jede erzeugte HTML-Datei genau einen Titel und einen Canonical hat; es validiert nicht, ob deren Werte korrekt sind — prüfen Sie diese separat stichprobenartig. Dies prüft nur das Build-Artefakt und sagt nichts über On-Demand-Routen (output: 'server') oder Server Islands aus, die nicht als statische Dateien existieren.

Live-Routen in Produktion stichprobenartig prüfen

Für alles, was On-Demand gerendert wird — output: 'server'-Routen, prerender = false pro Route oder Server Islands — gilt die Prüfung der Build-Ausgabe oben nicht. Prüfen Sie stattdessen die tatsächliche bereitgestellte Antwort:

# Replace with your real URLs
for url in "https://example.com/" "https://example.com/some-server-route/"; do
  echo "== $url =="
  curl -sS -D - -o /dev/null "$url" | grep -Ei '^(HTTP|location|cache-control):'
done

Achten Sie auf den erwarteten Statuscode (200 für eine aktive Seite, einen echten Weiterleitungscode bei einer Weiterleitung — nehmen Sie nicht ohne Prüfung 302 statt 301 an) und bestätigen Sie mit curl -sS "$url" vollständiges Markup statt einer Fallback-Hülle, wenn Sie eine Seite mit einem Server Island prüfen. Tun Sie dies gegen die Produktion und nicht gegen astro dev — Adapter- und Laufzeitverhalten können sich von der lokalen Umgebung unterscheiden.

Tools für eine Astro-Website

• @astrojs/sitemap — die offizielle Sitemap-Integration (astro add sitemap). Vergessen Sie site: in der Konfiguration nicht.
• astro-seo (npm) — optionale Community-Komponente, die Titel, Beschreibung, Open Graph, Twitter Cards und Canonical in einem Tag bündelt.
• astro-seo-schema (npm) — typsichere Hilfe für strukturierte JSON-LD-Daten in Astro.
• astro:assets <Image> / <Picture> — integrierte Bildoptimierung (WebP/AVIF, Abmessungen, Lazy Loading, alt-Pflicht).
• URL Inspection (Google Search Console) — bestätigen Sie, dass Ihr Inhalt im gecrawlten HTML steht (bei Astro sollte er bereits in „View Source“ stehen — eine schnelle Plausibilitätsprüfung).
• Ein Crawler mit JS-Rendering — Ahrefs Site Audit oder Screaming Frog, um die Parität zwischen rohem und gerendertem DOM auf der Website zu prüfen (auf prerendered Routen sollte sie übereinstimmen — bestätigen Sie es, nehmen Sie es nicht an, und prüfen Sie On-Demand- oder Server-Island-Routen separat).
• IndexNow — mit Ihrem Deploy-/Veröffentlichungsschritt verbinden, damit Bing und Yandex sofort von neuen statischen Seiten erfahren.

Testen Sie sich selbst: Astro SEO

Fünf kurze Fragen dazu, wie sich Astros Architektur auf SEO auswirkt. Wählen Sie jeweils eine Antwort und prüfen Sie anschließend.

Ressourcen, die Ihre Zeit wert sind

Meine verwandten Texte

• JavaScript SEO: A Definitive Guide — die Rendering-Grundlagen hinter dem Vorteil von Astros HTML-first-Ausgabe.
• The Beginner’s Guide to Technical SEO — wo die Framework-Wahl in das größere Bild passt.

Meine Vorträge

• How Search Works (SlideShare) — meine Einführung in Crawling, Rendering, Indexierung und Ranking — die Pipeline, die Astros SSG-Standardmodus abkürzt. (Dauerhafter Hinweis: „Das ist mein Verständnis von Systemen … nicht vollständig oder zu 100 % korrekt.“)

Aus der Branche

• Astro Docs: Islands Architecture — die maßgebliche Erklärung, wie Astro clientseitiges JS entfernt.
• Astro Docs: @astrojs/sitemap — offizielle Einrichtung, die site:-Anforderung und die Optionen filter/serialize/i18n.
• Astro Docs: Server Islands — server:defer, Fallback-Inhalt und das clientseitige Abrufverhalten, das Crawler nicht sehen.
• Joost de Valk: Astro SEO Complete Guide — der maßgebliche Leitfaden eines Praktikers, geschrieben vom Yoast-Gründer; stark bei modernen KI-fähigen Mustern und IndexNow.
• Google Search Central: Understand JavaScript SEO Basics — die Rendering-Warteschlange, crawlbare Links und die History-API-Empfehlung, der Astros View Transitions folgen.
• Astro: 2023 Web Framework Performance Report — die Core-Web-Vitals-Daten im Vergleich von Astro mit anderen Frameworks.
• Search Engine Journal: Core Web Vitals, WordPress und Astro — unabhängige Berichterstattung über den Performance-Vergleich von Astro und WordPress.

Statistiken, die sich zitieren lassen

Alle folgenden Zahlen stammen aus Astros Web Framework Performance Report von 2023 (und der Berichterstattung von SEJ dazu). Betrachten Sie die Zahlen als Benchmarks aus der Zeit um 2023 und nicht als aktuelle Zahlen.

• Über 50 % der Astro-Seiten bestehen Googles Core Web Vitals Assessment — mehr als der Branchendurchschnitt von etwa 40,5 %, wobei Astro und SvelteKit die einzigen großen Frameworks waren, die diesen Ausgangswert übertrafen (Next.js etwa 25 %, Nuxt etwa 20 %). Quelle
• INP-Bestandsrate von 68,8 % für Astro — zugeschrieben der MPA-Architektur (keine JS-gesteuerte Navigation), die den Main Thread frei hält. Quelle
• Medianes Seitengewicht von 1,65 MB — das niedrigste im Datensatz. Quelle
• LCP: Astro etwa 0,44 s gegenüber WordPress etwa 0,81 s — im Vergleich des Berichts ungefähr 46 % schneller. Berichterstattung

Änderungsprotokoll