Astro E-Commerce: schnelle Storefront, ehrliche Architektur.

Ehrliche Antwort: oft nicht. Wenn Ihre Storefront konvertiert, Ihr Team damit arbeiten kann und die Ladezeiten in Ordnung sind, ist ein Wechsel ein Risiko ohne Gegenwert. Sinnvoll wird es, wenn Sie an konkrete Grenzen stoßen: ein Theme, das unter Erweiterungen ächzt, Content und Shop in zwei getrennten Welten, oder ein Marketing, das für jede Landingpage Entwickler braucht. Dann rendert Astro die Oberfläche neu, während Shopify Katalog, Warenkorb und Checkout behält. Wir prüfen das im Erstgespräch – und sagen auch, wenn die Antwort „lassen Sie es“ lautet.

Das ist die richtige Frage, und sie entscheidet über die Architektur. Standardmäßig rendert Astro alles vorab – bei sehr großen oder häufig wechselnden Katalogen wird der komplette Build irgendwann zur Bremse. Der Ausweg steht im Framework: Einzelne Routen bekommen über eine explizite Einstellung On-Demand-Rendering, während Kategorien, Inhalte und Landingpages statisch bleiben. Wo genau diese Grenze liegt, legen wir anhand Ihrer Änderungsfrequenz fest, nicht anhand der Artikelzahl allein. Bei minütlich wechselnden Beständen ist die Grenze weiter vorne als bei einem stabilen Sortiment.

Technisch ja, sinnvoll oft nein. Einzelne personalisierte Elemente lassen sich über Server Islands nachrendern, ohne die gecachte Seite zu blockieren – ein Kundenpreis-Hinweis oder ein Warenkorb-Zähler funktioniert so gut. Wenn aber das gesamte Sortiment, die Sichtbarkeit von Artikeln und jeder Preis pro Kunde variieren, ist praktisch keine Seite mehr cachebar. Dann haben Sie den größten Vorteil von Astro aufgegeben und tragen trotzdem den Aufwand. In diesem Fall empfehlen wir eine Commerce-Plattform mit B2B-Funktionen oder eine individuelle Anwendung.

Nein, und wir raten in fast allen Fällen davon ab. Der Checkout ist der Ort, an dem Zahlungsabwicklung, Betrugsprüfung, Steuerlogik und rechtliche Anforderungen zusammenkommen. Diesen Teil lassen wir beim Commerce-System oder beim Zahlungsanbieter, wo er gepflegt und zertifiziert wird. Astro übernimmt alles davor: Kategorie, Produkt, Vergleich, Ratgeber, Warenkorb-Ansicht. Der Übergang in den Checkout ist ein bewusster Schnitt in der Architektur – und einer der Gründe, warum eine Astro-Storefront überschaubar bleibt.

Mit einer Sequenz, nicht mit einem Versprechen. Zuerst ein vollständiges Inventar aller URLs inklusive Paginierung, Filter- und Query-Varianten. Dann Ranking- und Backlink-Analyse, um zu wissen, welche Seiten tatsächlich Umsatz und Autorität tragen. Dann ein 1:1-Mapping alt zu neu, 301-Weiterleitungen, Prüfung von Metadaten und Produkt-Auszeichnung im Staging, Sitemap, Search-Console-Setup, IndexNow und Monitoring in den ersten Wochen. Wir messen vorher und nachher in Ihrem eigenen Projekt. Was wir nicht sagen: dass dabei nie etwas passiert. Bewegung in den ersten Wochen ist normal.

Ja, wenn wir es so anlegen. Wir bauen eine Bibliothek aus Bausteinen – Hero, Produktraster, Vergleichstabelle, Testimonial-Block, FAQ, Kampagnenbanner – die im CMS oder in einer Collection zusammengesetzt werden. Neue Seiten entstehen dann aus vorhandenen Teilen, ohne Deployment-Wissen. Was Entwicklungsarbeit bleibt: neue Seitentypen, neue Bausteine und alles Strukturelle. Wenn Ihr Team lieber vollständig visuell und ohne Repository arbeitet, ist unsere Webflow-Agentur-Leistung ehrlicherweise der bessere Vorschlag.

Ihr ERP oder PIM bleibt die Quelle. Wir kopieren keinen Katalog in ein zweites System, weil zwei Quellen für dieselbe Zahl früher oder später auseinanderlaufen – und dann verkaufen Sie, was nicht mehr da ist. Produktdaten fließen über die Schnittstelle Ihres Commerce-Systems in die Storefront. Im Repository oder im CMS liegen ausschließlich redaktionelle Inhalte: Ratgeber, Kampagnen, Lookbooks, Pflegehinweise. Wie Auftragseingang, Bestandsführung und Versand sauber zusammenspielen, ist ein eigenes Thema – dafür gibt es die E-Commerce-Prozessberatung.

Zuerst eine Trennung der Fragen: Wollen Sie das Shopsystem wechseln, oder nur die Oberfläche? Das sind zwei Projekte mit unterschiedlichem Risiko. Wenn WooCommerce funktional trägt und nur die Storefront langsam und schwer pflegbar ist, kann Astro die Oberfläche übernehmen und WordPress im Headless-Betrieb die Inhalte liefern – der Weg dorthin steht unter WordPress als Headless CMS. Wenn das System selbst das Problem ist, gehört der Plattformwechsel zuerst entschieden. Die generelle Gegenüberstellung finden Sie unter Astro vs. WordPress.

Der Vorteil einer Storefront ohne gewachsenes Erweiterungs-Ökosystem ist, dass Sie wissen, was geladen wird – es gibt keine App, die still ein Skript einbindet. Consent-Management, Analytics, Pixel und Zahlungsanbieter werden bewusst eingebunden, mit dokumentierten Empfängern und Zwecken. Was wir nicht liefern, ist Rechtsberatung: Datenschutzerklärung, Auftragsverarbeitung und Cookie-Klassifizierung gehören zu Ihrer Rechtsabteilung oder Ihrem Anwalt. Wir setzen technisch um, was dort entschieden wurde, und dokumentieren, welches Skript unter welcher Bedingung lädt.

Die Sorge ist berechtigt und lässt sich prüfen, statt beruhigen. Astro ist quelloffen unter MIT-Lizenz, Ihr Code liegt in Ihrem Repository, und der größte Teil einer Astro-Storefront ist HTML, CSS und TypeScript – nichts davon ist exotisch. Interaktive Komponenten schreiben wir in einem Framework, das Sie ohnehin kennen; Astro integriert React, Preact, Svelte, Vue, SolidJS und Alpine.js offiziell. Das Wissen, das wirklich projektspezifisch ist, steckt im Inhaltsmodell und in der Anbindung – und das dokumentieren wir im Repository, nicht in unseren Köpfen.

Sie bekommen von Anfang an das, was einen Wechsel möglich macht: Ihr eigenes Repository, Ihre eigenen Hosting- und Commerce-Zugänge, dokumentierten Code, ein beschriebenes Inhaltsmodell und eine Einweisung für Ihr Team. Wir bauen keine proprietäre Schicht ein, die nur wir bedienen können. Wenn Sie die Betreuung intern übernehmen oder an eine andere Agentur geben, ist das ein Übergabetermin und kein Neubau. Das ist bei einer kleinen Einheit wie uns keine Nettigkeit, sondern die Bedingung dafür, dass ein größeres Unternehmen überhaupt mit uns arbeiten kann.

Weil wir das offen sagen, statt eine Fallstudie zu erfinden. Was wir belegen können: Wir bauen mit Astro, wir haben E-Commerce-Prozesse in der Praxis umgebaut – bis hin zu Packtischen und Etikettendruckern in einer echten Halle – und wir haben Marktplatz- und ERP-Schnittstellen im Tagesbetrieb betrieben. Für die Storefront selbst überzeugen wir mit Verfahren: Ersteinschätzung, Architekturentscheidung, Messung vorher und nachher. Wenn Ihnen eine belegte Shop-Referenz wichtiger ist als eine ehrliche Einschätzung, sind wir nicht die richtige Wahl – und auch das sagen wir lieber jetzt.

Redaktionelle Inhalte ja, Produktdaten nein. Weil das Inhaltsmodell typisiert und über Zod schema-validiert ist, kann ein KI-Agent strukturiert hineinschreiben: Kampagnentext, Ratgeberbeitrag, Bildwechsel, Aktionszeitraum – als Nachricht an einen Telegram-Bot, mit Vorschau und nachvollziehbarem Commit. Preise, Bestände und Varianten laufen bewusst nicht darüber, die haben genau eine Quelle. Mehr dazu unter Website per Chat pflegen; den Beleg, dass Chat-Agenten hier Tagesgeschäft sind, liefert unser WhatsApp-KI-Agent.

Storefront an einem bestehenden Commerce-System: typischerweise acht bis vierzehn Wochen. Content-Website mit leichtem Checkout: vier bis acht Wochen. Mit mehreren Sprachen, B2B-Logik oder einer Datenmigration aus einem gewachsenen System: sechzehn Wochen und mehr. Den Rahmen bewegen vor allem Sortimentsstruktur, Anzahl echter Seitentypen, Märkte und Sprachen, B2B-Anforderungen und die Backoffice-Integration. Preise nennen wir erst, wenn diese Variablen geklärt sind – dann aber als nachvollziehbare Schätzung mit ausgeschriebenen Annahmen. Die Kostenfaktoren stehen unter Astro-Kosten.

Nein. Astro ist ein quelloffenes Webframework für content-getriebene Websites und übernimmt im E-Commerce die Storefront. Katalog, Bestand, Preise, Steuern, Warenkorb-Logik und Checkout brauchen ein Commerce-System oder zumindest einen Zahlungsanbieter dahinter – Astro rendert davor.

Ja, das ist das übliche Headless-Muster: Shopify bleibt die Engine für Katalog, Warenkorb und Checkout, Astro holt die Daten über die dokumentierte Schnittstelle und rendert die Storefront. Der Checkout bleibt dabei in aller Regel bei Shopify.

Der Kopf – die sichtbare Storefront – wird vom Commerce-System getrennt. Die Plattform liefert Daten und Bestellabwicklung über eine Schnittstelle, das Frontend wird eigenständig gebaut. Sie gewinnen Gestaltungsfreiheit und geben dafür die Bequemlichkeit eines fertigen Themes auf.

Ja. Für kleine Sortimente ist genau das das zweite Muster auf dieser Seite: Produkte als typisierte Inhalte in der Website, Zahlung und Bestellabwicklung beim Anbieter. Ohne Shopsystem, ohne dessen Updates – und mit deutlich weniger Technik, die betrieben werden muss.

Nur für die Routen, die es wirklich brauchen. Standardmäßig wird die Website vorgerendert und läuft auf statischem Hosting oder einem CDN. Sobald Warenkorb oder Konto zur Laufzeit rendern, kommt ein Adapter für die Ziellaufzeit dazu – offiziell gepflegt sind unter anderem Node, Vercel und Cloudflare.

Ja, die Bildoptimierung ist eingebaut. Die Image-Komponente setzt Ladeverhalten und Dekodierung, leitet die Maße ab und vermeidet damit Layout-Sprünge; eine Picture-Komponente erzeugt mehrere Formate und Größen. Bilder aus fremden CDNs müssen in der Konfiguration freigegeben werden.

Das Framework ist quelloffen unter MIT-Lizenz, es fallen also keine Lizenzkosten an. Kosten entstehen durch Umsetzung, Hosting und die Systeme dahinter – Commerce-Plattform, CMS und Zahlungsanbieter rechnen unabhängig davon ab.