Astro Agentur für Websites, die ohne Ballast ausliefern.

Den Rahmen bestimmen drei Dinge: die Anzahl echter Seitentypen (nicht Seiten), die Tiefe des Inhaltsmodells und die Integrationen – CMS, Formulare, CRM, Shop-Anbindung. Eine fokussierte Marketing-Website liegt deutlich unter einem Relaunch mit Redaktionssystem, Mehrsprachigkeit und Datenübernahme. Nach dem Erstgespräch bekommen Sie eine nachvollziehbare Schätzung mit Annahmen. Wie sich der Preis zusammensetzt, haben wir unter Astro-Kosten offengelegt.

Astro ist für content-getriebene Websites gebaut: Marketing-Auftritte, Blogs, Dokumentation, Portale mit vielen strukturierten Inhalten. Dort spielt es seine Stärke aus, weil der Browser vor allem HTML bekommt. Für Produkte mit Login, Rollen und viel Zustand im Browser ist es die falsche Grundlage – dann empfehlen wir eine individuelle Web-Anwendung oder, bei rein visueller Pflege, Webflow.

Ja, wenn wir es so aufsetzen. Zwei Wege: Inhalte liegen als Markdown im Repository und werden über Content Collections typsicher eingelesen – gut für technikaffine Teams und seltene Änderungen. Oder Sie bekommen ein Headless CMS mit Redaktionsoberfläche, Vorschau und Rechten. Welcher Weg passt, entscheiden wir nach Ihrem Redaktionsalltag, nicht nach Technikvorliebe.

Nicht, wenn die Migration geplant wird. Wir übernehmen URL-Struktur oder legen eine vollständige Redirect-Karte an, migrieren Inhalte inklusive Metadaten und strukturierten Daten, und wir messen Sichtbarkeit und Ladezeiten vor und nach dem Wechsel in Ihrem eigenen Projekt. Details zum Ablauf, zu Risiken und zu den Fällen, in denen ein Wechsel sich nicht lohnt, stehen unter WordPress zu Astro.

Faustregel: Je mehr Ihr Projekt eine Anwendung ist, desto eher Next.js. Je mehr es eine Website ist, desto eher Astro. Astro ist als Multi-Page-Architektur mit Server-Rendering angelegt und entfernt clientseitiges JavaScript, solange keins angefordert wird. Next.js bringt das App-Modell mit, das Sie bei Dashboards und eingeloggten Bereichen ohnehin brauchen. Die ausführliche Gegenüberstellung steht unter Astro vs. Next.js.

Nicht zwingend. Standardmäßig wird die gesamte Website vorgerendert, und statische HTML-Seiten gehen an den Browser – das läuft auf jedem statischen Hosting oder CDN. Sobald einzelne Routen zur Laufzeit rendern sollen, etwa für personalisierte Inhalte oder Formularverarbeitung, kommt ein Adapter für die Ziellaufzeit dazu; offiziell gepflegt sind unter anderem Node, Vercel und Cloudflare. Wir entscheiden das pro Route, nicht pauschal.

Astro folgt Semantic Versioning, und für genau eine vorherige Major-Version gibt es noch Sicherheits-Fixes. Da innerhalb eines Jahres zwei Major-Versionen erschienen sind, planen wir Upgrades als wiederkehrende kleine Aufgabe statt als Großprojekt: Abhängigkeiten regelmäßig aktualisieren, Änderungen im Build sichtbar machen, Upgrade in einem Branch testen. Das ist Teil unserer Support- und Wartungsleistung.

Beides. Termine und Workshops vor Ort sind im DACH-Raum machbar – Dresden, Leipzig, Chemnitz, Berlin und weiter. Die Projektarbeit selbst läuft remote, und wir arbeiten auch mit Kunden außerhalb Europas, auf Deutsch und Englisch. Welche Märkte, Zeitzonen und Sprachen wir abdecken, steht auf der Seite Märkte.

Drei kombinierbare Wege. Ein Headless CMS mit Oberfläche, Vorschau und Rechten für alle, die täglich redigieren. Markdown im Repository über Content Collections, wenn Inhalte selten und strukturiert entstehen. Oder Pflege per Chat: Ein Agent schreibt in dasselbe schema-validierte Inhaltsmodell, erzeugt einen nachvollziehbaren Commit und schickt eine Vorschau zurück – Text ändern, Beitrag anlegen, Bild tauschen als Nachricht statt als CMS-Sitzung. Chat-Agenten sind bei uns Tagesgeschäft; der Beleg ist unser eigener WhatsApp-KI-Agent. Was der Chatweg nicht ersetzt: Freigabe-Workflows großer Redaktionen und strukturelle Layout-Änderungen.

Nein, weil nicht umgeschaltet wird, solange die neue Seite nicht steht. Die neue Website entsteht parallel auf einer eigenen Umgebung, Inhalte werden per Skript übernommen statt von Hand kopiert, und die Weiterleitungen werden dort getestet, bevor jemand die Domain anfasst. Der Wechsel selbst ist eine Deployment- und DNS-Änderung; die alte Umgebung bleibt in den ersten Tagen erreichbar, damit ein Rückweg existiert. Was wir nicht versprechen: eine Garantie auf null Sekunden – die DNS-Propagierung liegt nicht in unserer Hand.

Ab Kickoff bis Go-live: vier bis sechs Wochen für eine fokussierte Marketing-Website mit drei bis fünf Seitentypen und vorhandenen Inhalten. Acht bis zwölf Wochen für eine Unternehmens-Website mit Redaktionsbetrieb, modelliertem CMS und ein bis zwei Integrationen. Vierzehn bis zwanzig Wochen für einen Relaunch mit Migration, mehreren Sprachen oder großem Archiv. Bewegt wird die Spanne von der Zahl echter Seitentypen, der Inhaltsmenge, der Frage ob Inhalte übernommen oder neu geschrieben werden, den Sprachen, den Integrationen – und Ihren Freigabezyklen.

Vier Dinge, und keins davon ist technisch. Eine Person, die entscheiden darf, statt eines Gremiums, das jede Runde neu eröffnet. Inhalte in dem Zustand, in dem sie erscheinen sollen – oder die klare Ansage, dass wir sie schreiben. Zugänge zu Domain, Hosting, Analytics und Altsystem am Anfang und nicht in Woche sechs. Und Rückmeldungen binnen weniger Arbeitstage. Wo die Abstimmung über mehrere Abteilungen läuft, übernehmen wir auf Wunsch die Projektleitung mit.

Ein Stück weit ja, und das sagen wir offen: Es gibt weniger Lebensläufe mit „Astro“ darin als mit WordPress oder React. Der Aufwand ist trotzdem kleiner, als es klingt. Astro-Komponenten sind HTML, CSS und TypeScript; interaktive Inseln schreiben Sie in React, Preact, Svelte, Vue, SolidJS oder Alpine.js. Sie stellen also aus dem allgemeinen JavaScript-Markt ein, nicht aus einem Astro-Markt. Einarbeitung heißt Dokumentation plus Repository, nicht ein halbes Jahr Framework-Schule. Bei einer selbst gebauten Hausarchitektur wäre dieses Risiko deutlich größer.

Sie behalten alles, was das Projekt ausmacht. Das Repository gehört Ihnen ab der ersten Woche, Hosting- und CMS-Zugänge laufen auf Ihren Namen, die Domain ohnehin. Es gibt keine Lizenz, keinen Baustein und keinen Editor, der an uns gebunden wäre – Astro ist quelloffen unter der MIT-Lizenz. Im Repository liegt eine README, die Build, Deployment und Inhaltsmodell erklärt. Jedes Team, das mit JavaScript und Git arbeitet, kann übernehmen. Ein Wechsel bleibt unangenehm, aber er ist keine Neuentwicklung.

Wir. Was wir gebaut haben und was nicht so funktioniert, wie es vereinbart war, reparieren wir im Rahmen der gesetzlichen Gewährleistung ohne neue Rechnung. Davon zu trennen ist der Änderungswunsch: Eine neue Funktion oder ein neuer Seitentyp ist eine Beauftragung, kein Mangel – und in welche der beiden Kategorien eine Meldung fällt, sagen wir, bevor wir anfangen, nicht hinterher. Feste Reaktions- und Wiederherstellungszeiten vereinbaren wir schriftlich, wenn Ihr Einkauf sie braucht; sie gehören in die Wartungsvereinbarung.

Dass die klassische Angriffsfläche einer Content-Website hier weitgehend entfällt. Eine vorgerenderte Astro-Seite hat im Auslieferungspfad keine Datenbank, kein Admin-Login und kein Plugin-Ökosystem – der übliche Weg über eine verwundbare Erweiterung existiert damit nicht. Was bleibt und wirklich geprüft gehört: Rechte auf Repository und Build-Pipeline, Herkunft der npm-Abhängigkeiten, Formular- und API-Endpunkte, ein Headless CMS als eigenes System mit eigener Anmeldung sowie Domain- und Hosting-Konten. Wir arbeiten mit Zwei-Faktor-Pflicht, minimalen Rechten und regelmäßigen Abhängigkeits-Updates und dokumentieren, wo Geheimnisse liegen.

Astro ist ein Framework und verarbeitet selbst keine personenbezogenen Daten – die Frage entscheidet sich an Hosting, Formularen, Analytics und CMS. Ein statischer Build lässt sich bei einem Anbieter in der EU oder in Deutschland betreiben. Schriften binden wir selbst ein statt über fremde Server, für Analytics gibt es Varianten ohne Cookies, und der Formular-Endpunkt wird bewusst gewählt statt mitgeliefert. Wir benennen jeden eingesetzten Dienstleister, damit Ihr Datenschutzbeauftragter die Auftragsverarbeitungsverträge schließen kann. Rechtsberatung leisten wir nicht; die Freigabe bleibt bei Ihnen.

Kein Framework macht eine Website barrierefrei. Das entsteht in Markup, Kontrasten, Fokusreihenfolge, Formularen und Tastaturbedienung. An einer Stelle hilft Astro strukturell: Es liefert serverseitig gerendertes HTML aus, das ohne JavaScript-Ausführung lesbar ist, und die eingebaute Bildkomponente setzt Alternativtext-Attribut, Ladeverhalten und Maße mit. Alles Weitere behandeln wir als Anforderung im Projekt statt als Nacharbeit: semantische Struktur, vollständige Tastaturbedienung, Prüfung mit Screenreader. Eine rechtsverbindliche Konformitätserklärung stellen wir nicht aus – wir liefern den Stand, den Ihre Prüfung bewerten kann.

Ja, und wir sagen es lieber, als es zu verschweigen. KI-gestützte Werkzeuge beschleunigen Routinearbeit; verantwortlich bleibt ein Mensch. Jede Änderung läuft durch Review, Typprüfung und Build in der Continuous Integration, bevor sie irgendwo landet. Zugangsdaten, personenbezogene Kundendaten und vertrauliche Dokumente gehören nicht in solche Werkzeuge – das ist bei uns Regel, nicht Ermessensfrage. Wenn Ihre Richtlinie den Einsatz einschränkt oder ausschließt, halten wir uns daran und schreiben es in den Vertrag.

Ja, wenn im Team jemand mit HTML, CSS, JavaScript und Git arbeitet. Sie bekommen dafür: das Repository mit vollständiger Historie, dokumentierte Build- und Deployment-Schritte, eine überschaubare Komponentenbibliothek statt hundert Einzelseiten und eine Einweisung für Redaktion und Entwicklung. Auf Wunsch begleiten wir die ersten Wochen im Pairing und ziehen uns dann zurück. Will dagegen niemand im Haus Deployments anfassen, ist der ehrliche Vorschlag ein anderer: entweder Webflow oder eine Wartungsvereinbarung, die die Verantwortung eindeutig bei uns lässt.

Weil wir das lieber so sagen, als eine zu erfinden. Ein öffentlich zeigbares Astro-Kundenprojekt haben wir bislang nicht. Was wir haben: eine gebaute und betreute Webflow-Referenz, eigene Produkte, die wir selbst entwickelt und veröffentlicht haben, und Jahre an Software-Entwicklung mit Repository, Continuous Integration und Betrieb. Das Framework ist der kleinere Teil dieser Arbeit. Prüfen können Sie uns günstig: Die Ersteinschätzung kostet nichts, das Repository gehört Ihnen ab Tag eins, und gemessen wird vor und nach dem Launch in Ihrem eigenen Projekt.

Ja. Astro ist quelloffene Software unter der MIT-Lizenz; für das Framework selbst fällt keine Lizenzgebühr an. Kosten entstehen bei Design, Umsetzung, Inhalten, Hosting und Betrieb – und, falls Sie eins einsetzen, beim Headless CMS.

Ein quelloffenes Projekt, das öffentlich auf GitHub entwickelt wird. Die MIT-Lizenz weist das Copyright von 2021 auf Fred K. Schott aus. Gepflegt und weiterentwickelt wird Astro von einem Kernteam und einer Community aus Beitragenden, aktuell in der Astro-7-Linie.

Ja, das ist einer der Fälle, für die es gebaut wurde. Beiträge liegen als Markdown oder MDX in einer Content Collection mit Schema, Abfragen laufen typsicher über getCollection(), und das eingebaute Caching ist ausdrücklich für Sammlungen mit Tausenden Einträgen gedacht.

Die technische Grundlage ist gut: Standardmäßig wird jede Seite vorgerendert, Suchmaschinen bekommen fertiges HTML und müssen dafür kein JavaScript ausführen. Rankings entstehen davon allein nicht – die kommen aus Inhalt, Struktur und Verlinkung. Wo es hakt, findet ein SEO Audit.

Ja. Es gibt offizielle Integrationen für React, Preact, Svelte, Vue, SolidJS und Alpine.js, und mehrere davon dürfen auf derselben Seite vorkommen – allerdings nur innerhalb einer .astro-Datei. Bestehende Komponenten lassen sich so oft übernehmen, statt sie neu zu schreiben.