Warum wir Websites mit Astro bauen

Astro ist ein Web-Framework, das HTML statt JavaScript ausliefert. Standardmäßig landet null Kilobyte JS im Browser, interaktive Teile lädst du gezielt als sogenannte „Islands” nach. Genau deshalb bauen wir bei Rocket-Monkeys Marketing-Websites, Landingpages, Dokumentationen und Blogs mit Astro: Sie sind schneller, besser crawlbar für Google und für KI-Suchmaschinen wie ChatGPT oder Perplexity – und im Betrieb deutlich pflegeleichter als ein WordPress-Setup mit drei Page-Buildern und siebzehn Plugins.

TL;DR

• Astro liefert per Default Zero JS – der Browser bekommt sauberes HTML, nicht ein React-Bundle, das sich erst rendern muss.
• Islands Architecture: Interaktivität (Suche, Theme-Toggle, Chat) wird inselweise und lazy nachgeladen, der Rest bleibt statisch.
• Das ergibt bessere Core Web Vitals, sauberes Markup für Crawler und maximale Zitierbarkeit in LLM-Antworten.
• WordPress/Page-Builder sind nicht „schlecht” – aber für die meisten Content-Sites die schwerere, langsamere und teurere Lösung.
• Astro ist nicht für jede hochinteraktive App die richtige Wahl. Wir sagen ehrlich, wann nicht.

Das Problem mit dem JavaScript-Standard

Die meisten modernen Websites werden gebaut, als wären sie Apps. Ein Marketing-Blog, der eigentlich nur Text, ein paar Bilder und ein Kontaktformular zeigt, schickt dem Browser trotzdem ein komplettes React- oder Next.js-Bundle. Der Browser lädt das JavaScript, parst es, führt es aus, baut das DOM nach – und erst dann ist die Seite wirklich benutzbar. Für eine App, in der man stundenlang arbeitet, ist das ein fairer Deal. Für eine Seite, die jemand drei Minuten liest, ist es Verschwendung.

Wir sehen das ständig in Audits: Eine simple Unternehmensseite zieht 400 KB JavaScript, nur um eine Navigation aufzuklappen und ein Cookie-Banner zu zeigen. Auf dem teuren MacBook im Café fällt das nicht auf. Auf einem drei Jahre alten Android-Handy im Zug mit zwei Balken Empfang fällt es brutal auf. Und genau dort sind viele eurer Nutzer.

Astro dreht die Default-Annahme um. Nicht „alles ist interaktiv, es sei denn, du sagst was anderes”, sondern: „nichts schickt JavaScript, es sei denn, du verlangst es explizit.” Das ist kein Marketing-Slogan, das ist die tatsächliche Architektur.

Wie Astro funktioniert: Islands und Zero-JS-by-default

Beim Build rendert Astro deine Komponenten zu statischem HTML. Eine .astro-Komponente, die nur Inhalt darstellt, hinterlässt im fertigen Output keine einzige Zeile clientseitiges JavaScript. Punkt.

Interaktivität kommt über Islands rein – inselartige, klar abgegrenzte Bereiche, die hydratisiert werden. Und du steuerst, wann:

---
import ThemeToggle from '../components/ThemeToggle.astro';
import ChatWidget from '../components/ChatWidget.astro';
---

<!-- statisch, kein JS -->
<article>{content}</article>

<!-- Insel: erst laden, wenn sichtbar -->
<ChatWidget client:visible />

Diese client:-Direktiven sind der Kern. client:load hydratisiert sofort, client:idle wartet, bis der Browser nichts Wichtigeres zu tun hat, client:visible lädt erst, wenn die Komponente in den Viewport scrollt. Ein Chat-Widget ganz unten in der Seite muss nicht beim ersten Pixel mitgeladen werden – client:visible, fertig.

Auf unserer eigenen Seite ist genau das gelebte Praxis. Der Großteil – Hero, Services, Approach, Footer, der ganze Blog – ist reines, statisches HTML. Nur eine Handvoll Dinge sind echte Islands: der Theme-Toggle, der Sprachumschalter, das Chat-Widget. Der Effekt: Eine Blogseite kommt mit minimalem JavaScript aus, statt mit dem Komplett-Bundle, das ein typisches CMS-Theme mitschleppt.

Und das Schöne daran: Du bist nicht an ein UI-Framework gebunden. Astro nimmt React, Vue, Svelte, Solid – oder eben gar keins. Die meisten unserer Komponenten sind schlichte .astro-Dateien. Brauchen wir an einer Stelle echte React-Logik, kapseln wir sie als Island und der Rest der Seite bleibt unberührt. Kein „entweder alles React oder nichts”.

Performance ist kein Nice-to-have, es ist Geschäft

Performance klingt nach Entwickler-Hobby. Ist es nicht. Es ist Conversion, SEO-Ranking und Markenwahrnehmung in einem.

Google bewertet Core Web Vitals – Largest Contentful Paint, Interaction to Next Paint, Cumulative Layout Shift – als Ranking-Signal. Eine Astro-Seite, die fertiges HTML ausliefert, hat es hier strukturell leichter: Es gibt kein „leeres div, das auf JavaScript wartet”, der LCP-Inhalt steht sofort im Markup. INP profitiert davon, dass schlicht kaum JavaScript da ist, das den Main Thread blockieren könnte. Du musst nicht gegen ein Framework optimieren, das dir die Performance erst weggenommen hat.

Konkret aus unserem Alltag: Wir verlinken im <head> nichts, was nicht sein muss, laden Schriften lokal via Fontsource statt über Google-Fonts-Requests, und Astros Bild-Pipeline spuckt automatisch moderne Formate und korrekte width/height-Attribute aus, damit nichts springt. Das sind Kleinigkeiten – aber sie summieren sich, und Astro stellt sich dir dabei nicht in den Weg.

SEO und KI-Lesbarkeit: warum sauberes HTML wieder zählt

Hier wird es für uns als AEO/SEO-Agentur richtig interessant. Crawler – egal ob Googlebot oder der Bot von ChatGPT/Perplexity – wollen am liebsten fertiges HTML. Server-gerendertes Markup, das den Inhalt direkt enthält, wird zuverlässig erfasst. Bei client-gerenderten SPAs ist das eine Wette: Vielleicht rendert der Crawler das JavaScript aus, vielleicht mit Verzögerung, vielleicht unvollständig. Warum sollte man diese Wette eingehen, wenn man sie nicht muss?

Astro liefert per Definition das fertige HTML. Der Inhalt ist da, bevor irgendein Skript läuft. Für AEO – Answer Engine Optimization ist das Gold wert: KI-Antwortmaschinen extrahieren Passagen aus deinem Markup und zitieren sie. Wenn deine Kernaussage sauber als <p> im ersten Absatz steht und nicht in einer JavaScript-gerenderten Komponente versteckt ist, steigt die Chance, zitiert zu werden, erheblich.

Dazu kommt strukturierte Auszeichnung. Wir setzen JSON-LD als simple Inline-Komponente ein:

<script type="application/ld+json" set:html={JSON.stringify(data)} is:inline />

Article, FAQPage, BreadcrumbList, Organization – sauber typisiert, beim Build erzeugt, ohne Plugin-Wildwuchs. Astros Content Collections geben uns dabei ein Zod-Schema, das jeden Blogpost validiert: Titel, Description, Kategorie, Tags, Sprache. Vergisst jemand die Meta-Description, bricht der Build – nicht das Ranking drei Wochen später. Diese Art von „SEO-Hygiene per Schema” ist mit einem klassischen CMS-Workflow kaum so robust hinzubekommen.

Und weil i18n in Astro nativ verdrahtet ist, kommen hreflang-Tags und ein korrektes Sitemap-Mapping zwischen Sprachversionen quasi geschenkt – auf unserer Seite läuft das über die @astrojs/sitemap-Integration mit de-DE/en-US-Locales.

Astro vs. WordPress vs. Page-Builder

Lass uns ehrlich sein, statt Lager zu bilden. WordPress betreibt einen riesigen Teil des Webs, aus guten Gründen: Redakteure kennen es, es gibt für alles ein Plugin, und ein Marktplatz an Themes. Das Problem entsteht selten an Tag eins. Es entsteht nach achtzehn Monaten, wenn fünf Plugins sich gegenseitig blockieren, ein Update das Layout zerschießt und der Page-Builder 600 KB CSS für eine Spalte mit drei Boxen generiert.

	Astro	WordPress + Page-Builder	Headless CMS + Next.js
JS im Browser (Default)	~0 KB	hoch, oft 300 KB+	mittel bis hoch
Core Web Vitals	sehr gut	stark vom Theme/Plugins abhängig	gut, aber tuning-intensiv
Hosting	statisch, günstig (CDN)	PHP-Server, Wartung nötig	Node-Runtime/Serverless
Angriffsfläche	minimal (kein Live-Backend)	groß (Plugins, Login, DB)	mittel
Redakteur-Komfort	Markdown/MDX, optional Headless-CMS	sehr hoch (WYSIWYG)	hoch
Ideal für	Content, Marketing, Docs, Blogs	redaktionslastige Sites, Shops	große, dynamische Apps

Der Punkt zum Mitnehmen: Eine Astro-Seite ist im Kern eine Sammlung statischer Dateien. Es gibt kein PHP-Backend, das gehackt werden kann, keine Datenbank, die umkippt, kein wp-admin, das im Quartalsrhythmus Sicherheitsupdates verlangt. Du deployst auf ein CDN, und die Seite ist schnell und stabil, egal ob zehn oder zehntausend Leute draufschauen. Das senkt nicht nur die Ladezeit, sondern auch die laufenden Kosten und das Risiko.

Wer Redaktionskomfort braucht, kombiniert Astro mit einem Headless-CMS wie Storyblok, Sanity oder einem Git-basierten Editor. Die Redaktion bekommt eine Oberfläche, die Auslieferung bleibt statisch. Beste aus beiden Welten.

Wann Astro passt – und wann nicht

Wir verkaufen Astro nicht als Allheilmittel. Das wäre unseriös. Es gibt klare Fälle, in denen wir abraten.

Astro ist die richtige Wahl, wenn:

• die Seite überwiegend Inhalt ist: Marketing, Blogs, Dokus, Portfolios, Landingpages, Knowledge-Bases.
• SEO und Ladezeit geschäftskritisch sind.
• du eine mehrsprachige Content-Site brauchst.
• du Inhalte aus verschiedenen Quellen (Markdown, CMS, APIs) beim Build zusammenführst.

Astro ist die falsche Wahl, wenn:

• du eine hochinteraktive Anwendung baust – ein Dashboard mit Echtzeitdaten, einen Editor, eine Trading-Oberfläche. Dann ist eine SPA mit Next.js, Remix oder einem dedizierten Stack ehrlicher. Astro kann das über Islands, aber wenn 80 % deiner Seite interaktiv sind, kämpfst du gegen die Architektur statt mit ihr.
• dein Team ausschließlich auf ein bestimmtes Framework und dessen Ökosystem festgelegt ist und keine neue Build-Konvention lernen will.
• du extrem dynamische, pro-Request personalisierte Inhalte hast, die sich nicht sinnvoll vorrendern lassen. Astro hat dafür einen SSR-Modus, aber dann verlierst du einen Teil des Zero-JS-Vorteils und solltest die Wahl bewusst treffen.

Die Faustregel, die wir intern benutzen: Frag dich, wie viel der Seite sich nach dem Laden noch bewegt. Bleibt das meiste stehen und der Nutzer liest, scrollt, klickt mal? Astro. Tippt der Nutzer ständig, zieht Dinge herum, sieht Live-Updates? Dann reden wir über etwas anderes.

Was das in der Praxis bedeutet

Unsere eigene Website ist der Beweis nach Hausmacherart: Astro 5, statischer Output, MDX für die Artikel, Content Collections mit Zod-Validierung, Tailwind v4 über das Vite-Plugin, native i18n für Deutsch und Englisch, JSON-LD inline, Sitemap automatisch. Interaktivität exakt dort, wo sie Mehrwert bringt – nicht überall. Das Ergebnis lädt schnell, rankt sauber und lässt sich von KI-Systemen problemlos lesen und zitieren. Genau das, was wir auch für dich bauen würden.

Wenn du eine bestehende Seite hast, die zäh lädt, im Wartungs-Hamsterrad steckt oder in KI-Antworten schlicht nicht auftaucht, lohnt sich ein nüchterner Blick. Manchmal ist die Antwort ein Astro-Rebuild. Manchmal ist es etwas ganz anderes – und das sagen wir dir dann auch. Schreib uns für ein unverbindliches Erstgespräch an info@rocket-monkeys.com, und wir schauen gemeinsam, was zu deinem Projekt wirklich passt.