Seit dem 21. Oktober 2026 bekommen wir eine Frage häufiger: „Könnt ihr unseren Shop auch statisch machen?" Die ehrliche Antwort lautet nein – und das ist keine Frage des Aufwands oder des Preises, sondern der Sache. Dieser Beitrag erklärt, warum ein Onlineshop nicht statisch sein kann, und welche drei Wege Shopbetreiber stattdessen haben.
Warum es nicht geht
Eine statische Website besteht aus fertigen Dateien. Kommt ein Besucher, wird die Datei ausgeliefert – nichts wird berechnet.
Ein Shop lebt vom Gegenteil. Zwischen „Artikel ansehen" und „Bestellung abgeschlossen" liegt eine Kette von Vorgängen, die alle in dem Moment stattfinden müssen, in dem der Kunde handelt:
- Warenkorb: gehört genau diesem Besucher, niemandem sonst
- Verfügbarkeit: der Bestand muss jetzt stimmen, nicht heute früh
- Preis: Staffelpreise, Kundengruppen, Rabatte, Versandkosten nach Land
- Kasse: Adressprüfung, Steuersatz, Zahlungsabwicklung
- Bestellung: muss gespeichert, ans Lager gemeldet, bestätigt werden
- Kundenkonto: Anmeldung, Bestellhistorie, Rechnungen
Jeder dieser Punkte erfordert, dass auf dem Server etwas passiert, wenn der Kunde klickt. Eine fertige Datei kann das nicht – sie ist fertig.
Wer Ihnen einen „statischen Shop" anbietet, meint entweder einen Katalog ohne Bestellfunktion oder eine Lösung, bei der der Shop-Teil von woanders kommt. Letzteres ist ein gangbarer Weg, hat aber einen anderen Namen.
Dann ist der Shop also ungeschützt?
Nein. Er braucht nur eine andere Antwort als eine Visitenkarten-Website.
Bei PHP2Shell war der Punkt nicht, dass Shops besonders gefährdet wären – es war, dass praktisch jede PHP-Anwendung betroffen war. Sicherheitsforscher nannten Magento ausdrücklich. Der Unterschied zur Firmenwebsite ist nicht die Lücke, sondern was auf dem Spiel steht: Bei einem Shop liegen Kundendaten, Adressen, Bestellhistorie und je nach Anbindung Zahlungsvorgänge im Zugriff. Daraus folgen im Schadensfall Meldepflichten und Haftungsfragen.
Ein Shop braucht deshalb nicht weniger, sondern mehr Betreuung als eine normale Website.
Weg 1: Den Shop ordentlich betreiben
Der unspektakuläre, in den meisten Fällen richtige Weg. Was dazugehört:
Updates ohne Verzug. Bei einem Shop ist das keine Fleißaufgabe. Kritische Sicherheitsupdates gehören innerhalb von Stunden eingespielt, nicht beim nächsten Wartungsfenster. Das setzt ein Testsystem voraus, auf dem sich das vorher prüfen lässt – ein Shop, der nach einem Update nicht mehr bestellbar ist, kostet sofort Umsatz.
Eine vorgelagerte Absicherung. Eine Web Application Firewall vor dem Shop erkennt bekannte Angriffsmuster und verschafft Zeit, wenn eine Lücke bekannt wird, bevor der Patch da ist. Genau diese Lage gab es am 21. Oktober.
Überwachung, die auffällt. Nicht nur „ist der Shop erreichbar", sondern: Haben sich Dateien geändert? Gibt es neue Administratorkonten? Laufen ungewöhnliche Prozesse? Worauf dabei zu achten ist, steht in PHP2Shell-Angriff erkennen.
Getrennte Systeme. Shop, Warenwirtschaft und Firmenwebsite gehören nicht auf denselben Server. Wer den Shop übernimmt, soll nicht automatisch alles andere mit haben.
Geprüfte Sicherungen. Täglich, außerhalb des Shopservers, mindestens einmal im Jahr probeweise zurückgespielt.
Weg 2: Headless Commerce
Der Weg, der dem „statischen Shop" am nächsten kommt, ohne zu behaupten, er sei einer.
Die Idee: Der sichtbare Teil – Startseite, Kategorien, Produktseiten, Inhalte – wird statisch erzeugt und ausgeliefert. Nur Warenkorb und Kasse sprechen über eine Schnittstelle mit dem Shop-System im Hintergrund, das nicht als Website öffentlich steht.
Was das bringt: Der weitaus größte Teil der Seitenaufrufe wird aus fertigen Dateien bedient – sehr schnell, mit sehr kleiner Angriffsfläche. Das Shop-System ist nicht mehr direkt als Website erreichbar.
Was es nicht bringt: Das Shop-System läuft weiter und braucht weiter Updates und Betreuung. Die Angriffsfläche schrumpft, sie verschwindet nicht.
Was es kostet: Das ist ein Umbau, kein Umzug. Monate, nicht Tage. Für einen Shop mit fünfzig Artikeln lohnt sich das selten; ab einer gewissen Größe und bei hohen Anforderungen an Geschwindigkeit wird es interessant.
Weg 3: Gehosteten Shop nutzen
Statt einen Shop selbst zu betreiben, einen Dienst mieten, bei dem der Anbieter Betrieb und Updates übernimmt.
Was dafür spricht: Sie sind das Thema Sicherheitsupdates los – der Anbieter patcht, und zwar für alle Kunden gleichzeitig. Für kleinere Shops ist das oft die wirtschaftlichste Lösung.
Was dagegen spricht: Weniger Freiheit bei Gestaltung und Abläufen, laufende Gebühren oft umsatzabhängig, Abhängigkeit vom Anbieter. Und Ihre Kundendaten liegen dort – was geklärt und im Verzeichnis der Verarbeitungstätigkeiten festgehalten gehört.
Was für die Seiten drumherum gilt
Ein Punkt, der oft übersehen wird: Viele Unternehmen haben einen Shop und eine Firmenwebsite, häufig beide auf demselben System oder demselben Server.
Das muss nicht sein. Die Firmenwebsite – Über uns, Leistungen, Referenzen, Kontakt – kann statisch werden, auch wenn der Shop bleibt. Dann liegt wenigstens der Teil außerhalb der Schusslinie, der nichts zu berechnen hat. Technisch sind das zwei Bereiche unter einer Domain, für Besucher ein Auftritt.
Das ist in der Praxis oft die beste Antwort: nicht alles oder nichts, sondern jedem Teil die Technik, die er braucht. Was dabei geht und was nicht, steht in Was eine statische Website kann und was nicht.
Checkliste: erste Schritte
- PHP- und Shop-Version feststellen, beide auf aktuellen Stand bringen
- Prüfen, ob Shop, Warenwirtschaft und Website auf demselben Server liegen
- Administratorkonten im Shop durchzählen und Unbekanntes entfernen
- Vorgelagerte Absicherung prüfen – gibt es eine, und greift sie?
- Sicherungen prüfen: täglich, außerhalb, wann zuletzt zurückgespielt?
- Testsystem einrichten, falls keines da ist
- Zuständigkeit für kritische Updates schriftlich festlegen, mit Zeitvorgabe
- Firmenwebsite getrennt vom Shop betrachten
Wie DAVINCI unterstützt
Wir betreuen Shop-Server mit getrennten Systemen, vorgelagerter Absicherung und geprüften Sicherungen – und sagen Ihnen offen, wenn ein gehosteter Dienst für Ihre Größe die bessere Wahl wäre. Die Firmenwebsite drumherum können wir unabhängig davon auf eine statische Fassung umstellen. Bei einem Verdacht auf einen Zugriff übernimmt unser Incident Response. Kontakt über die Kontaktseite.
Häufige Fragen
Kann man wenigstens die Produktseiten statisch machen?
Ja, das ist der Kern von Headless Commerce. Kategorien und Produktseiten kommen als fertige Dateien, nur Warenkorb und Kasse sprechen mit dem Shop-System. Verfügbarkeitsanzeigen müssen dann allerdings nachgeladen werden, sonst zeigen sie einen veralteten Stand.
Unser Shop ist klein. Lohnt sich der ganze Aufwand?
Die Größe ändert nichts an der Pflicht. Ein Shop mit dreißig Artikeln verarbeitet dieselben personenbezogenen Daten wie einer mit dreitausend. Bei kleinen Shops ist deshalb ein gehosteter Dienst oft die vernünftigere Entscheidung als ein selbst betriebenes System ohne Betreuung.
Was ist mit WooCommerce auf WordPress?
Dasselbe in Grün: Das ist WordPress mit Shop-Erweiterung, läuft auf PHP, braucht Updates und war am 21. Oktober genauso betroffen. Es gelten die Wege aus diesem Beitrag, nicht die Umstellung auf statisch.
Müssen wir einen Vorfall im Shop melden?
Wenn personenbezogene Daten betroffen sind, gelten Fristen – und bei einem Shop sind sie es fast immer. Klären Sie das mit Ihrem Datenschutzbeauftragten oder Ihrer Rechtsberatung, bevor Sie handeln, nicht danach.
Wie schnell müssen Shop-Updates eingespielt werden?
Bei als kritisch eingestuften Sicherheitsupdates: am selben Tag. Das klingt streng, entspricht aber der Realität – Angriffe auf bekannte Shop-Lücken beginnen oft Stunden nach der Veröffentlichung, weil Shops automatisiert gesucht werden.
Verwandte Themen: Wer hier weiterdenkt, liest bei Headless CMS, TYPO3 ablösen und statische Website weiter.
