13. September 2026 14 Min.
Warum eine Firmenwebsite nicht immer WordPress oder TYPO3 braucht
Eine Firmenwebsite braucht nicht immer WordPress oder TYPO3. Wie Astro fertige Seiten ausliefert und damit typische Angriffswege über Erweiterungen und CMS-Anmeldungen vermeidet, zeigt ravok.de selbst.
Ein Handwerksbetrieb möchte seine Leistungen und einige Referenzen zeigen. Eine Kanzlei braucht Informationen zum Team, zu ihren Tätigkeitsgebieten und zur Kontaktaufnahme. Ein Dienstleister ergänzt gelegentlich einen Ratgeberbeitrag. Keiner dieser Auftritte braucht deshalb automatisch WordPress oder TYPO3.
WordPress und TYPO3 sind Content-Management-Systeme, kurz CMS: Mit solcher Software lassen sich Inhalte über eine Verwaltungsoberfläche bearbeiten und veröffentlichen. Das kann sehr nützlich sein. Welche Technik eine Firmenwebsite dafür braucht, hängt davon ab, was Besucher dort tun sollen und wie das Unternehmen seine Inhalte pflegt.
Die Website, die Sie sich gerade ansehen, ist ein Beispiel für einen anderen Weg: ravok.de wurde mit Astro erstellt und wird vollständig statisch ausgeliefert. Dazu gehören auch der Blog, das Glossar, die Leistungsseiten und die Preisübersicht. Wir brauchen für diesen Auftritt keine Verarbeitung von Besuchereingaben im Backend. Deshalb laufen auf dem öffentlichen Webserver weder WordPress noch TYPO3, deren Erweiterungen, ein PHP-Interpreter oder eine Inhaltsdatenbank. Das verkleinert die Angriffsfläche und den laufenden Pflegeaufwand.
Was eine Firmenwebsite leisten muss
Viele Besucher wollen zunächst wenige Dinge wissen: Was bietet das Unternehmen an? Passt es zu meinem Anliegen? Gibt es nachvollziehbare Erfahrung? Wie erreiche ich jemanden? Gute Texte, passende Bilder, eine verständliche Gliederung und eine auf dem Smartphone gut bedienbare Seite helfen dabei unmittelbar.
Für Leistungen, Referenzen, Öffnungszeiten, Downloads und Kontaktdaten genügt häufig eine statische Website. Auch ein Blog mit regelmäßig neuen Beiträgen lässt sich so betreiben. Entscheidend ist, wo Daten verarbeitet werden müssen: im Browser des Besuchers, dem Frontend, oder in einer Anwendung auf einem Server, dem Backend.
Im Frontend können beispielsweise eine Suche, ein Filter oder ein unverbindlicher Preisrechner laufen. Auch individuelle Berechnungen machen eine Website also noch nicht zu einer Backend-Anwendung. Der Browser hat die dafür benötigten Daten und führt den mitgelieferten Programmcode aus. Besucher können diesen Code und seine Ergebnisse allerdings einsehen und verändern. Geheimnisse wie Zugangsdaten zu einem Zahlungsdienst gehören deshalb nicht in ausgelieferte Dateien.
Eine Preisliste mit festen Preisen braucht kein Backend. Auch ein Rechner kann im Browser die Summe mehrerer Positionen anzeigen. Sobald eine Onlinebestellung verarbeitet wird, muss der Server den Preis jedoch anhand der eigenen Produktdaten berechnen. Er darf einen vom Browser übermittelten Gesamtbetrag nicht ungeprüft übernehmen, denn Besucher können diesen Wert verändern. Ebenso prüft ein Backend Berechtigungen, Zahlungsergebnisse und verfügbare Bestände. OWASP beschreibt diese Prüfung von Preisen und Berechtigungen auf dem Server.
Ein ganzer Webshop setzt weitere Dinge voraus: Bestellungen müssen gespeichert, Zahlungen zugeordnet und gegebenenfalls Lagerbestände aktualisiert werden. Die Produktauswahl und ein Warenkorb können zunächst im Browser liegen; die Verarbeitung einer Bestellung braucht ein zuständiges Backend. Ähnliches gilt für Kundenkonten oder die Buchung tatsächlich verfügbarer Termine. Wer diese Funktionen nicht benötigt, muss die dazugehörige Technik auch nicht vorsorglich mitbetreiben.
Eine feste Preisliste lässt sich statisch ausliefern. Bei einer Onlinebestellung berechnet der Server den Preis selbst und prüft, ob die Bestellung ausgeführt werden kann.
Im Browser
FrontendSeiten lesen, Produkte filtern und Summen berechnen.
Besucher können Werte und Programmcode in ihrem Browser verändern.
Auf dem Server
Backend- Preis und Rabatte selbst berechnen
- Berechtigung und Bestand prüfen
- Bestellung speichern
Der übermittelte Gesamtbetrag ist keine verlässliche Grundlage.
Die Auswahl wird übergeben, die Prüfung bleibt beim Server.Das Backend kann zum eigenen Shop gehören oder von einem angebundenen Dienst bereitgestellt werden.
Was „statisch“ bei Astro bedeutet
Astro kann die Seiten eines Webauftritts vorab erzeugen. Texte, Bilder und Gestaltungsvorlagen werden bei diesem Erstellen zusammengesetzt. Das Ergebnis sind fertige Dateien: HTML für den Seiteninhalt, CSS für die Gestaltung und bei Bedarf JavaScript für Funktionen im Browser.
Diese Dateien werden auf den Webserver übertragen. Ruft jemand eine Seite auf, liefert der Server sie aus. Er muss dafür weder Texte aus einer Inhaltsdatenbank holen noch die Seite mit einer laufenden CMS-Anwendung zusammensetzen. Bei einer Änderung wird die Website neu erzeugt und der aktualisierte Stand bereitgestellt.
Statische Auslieferung bedeutet dabei keine doppelte Inhaltspflege. Eine Telefonnummer, Öffnungszeiten oder ein Leistungsbaustein lassen sich einmal zentral hinterlegen und auf mehreren Seiten verwenden. Ändert sich die Information, passen wir sie nur einmal an. Beim nächsten Erstellen übernimmt Astro den neuen Stand automatisch auf allen Seiten, die diesen Baustein verwenden. Die einzelnen fertigen Seiten müssen nicht von Hand angepasst werden. Dafür bietet Astro wiederverwendbare Komponenten.
Die Erstellung der Seiten und ihr Abruf sind zwei getrennte Vorgänge.
Vor der Veröffentlichung und nach Änderungen
- Inhalte und BausteineInformationen einmal zentral pflegen.
- Astro erstellt die SeitenÄnderungen automatisch auf alle passenden Seiten übernehmen.
Bei jedem Seitenaufruf
Für diese Auslieferung braucht ravok.de weder eine Inhaltsdatenbank noch eine laufende CMS-Anwendung.
Bei einer üblichen WordPress- oder TYPO3-Installation laufen dagegen ein PHP-Interpreter und ein Datenbankdienst auf dem Server. Der Interpreter führt den PHP-Programmcode des CMS und seiner Erweiterungen aus. Ein Seitencache kann bereits erzeugte Seiten wiederverwenden und damit viele Aufrufe beschleunigen. Das CMS, seine Verwaltung und die Datenbank bleiben für die Inhaltspflege dennoch Bestandteil dieses Systems.
Astro lässt sich ebenfalls mit serverseitigen Funktionen einsetzen. Für unsere Website haben wir die vollständig statische Variante gewählt, weil unsere Inhalte, Suche und interaktiven Grafiken keine Backend-Verarbeitung beim Besuch benötigen. Ein zusätzlicher Anwendungsserver hätte hier keine Aufgabe, die seinen Betrieb rechtfertigt.
Der Sicherheitsvorteil: weniger Angriffsfläche
TYPO3 wird auch für öffentliche Stellen in Deutschland eingesetzt, etwa beim Government Site Builder 11 des Bundes, der auf TYPO3 basiert. Die TYPO3 Association mit Sitz in der Schweiz koordiniert und finanziert die langfristige Weiterentwicklung des Projekts. Damit ist TYPO3 auch organisatorisch im deutschsprachigen Raum verankert. Begonnen wurde das Projekt 1997 vom dänischen Entwickler Kasper Skårhøj.
WordPress und TYPO3 sind verbreitete Systeme, allerdings mit unterschiedlichem regionalem Gewicht. W3Techs erfasst am 13. September 2026 WordPress auf 40,3 Prozent aller untersuchten Websites und TYPO3 auf 0,3 Prozent. Betrachtet man nur Websites mit erkanntem CMS, ergeben sich folgende Anteile:
| Domainraum | WordPress | TYPO3 |
|---|---|---|
| Weltweit | 58,8 % | 0,5 % |
| .de | 54,1 % | 6,7 % |
Quellen: W3Techs zu WordPress, TYPO3 und Websites unter .de, Stand 13. September 2026. Die .de-Auswertung zeigt den Unterschied im deutschen Domainraum; sie erfasst nicht sämtliche deutschen Unternehmen und Behörden unter anderen Domainendungen.
Bei verbreiteter Software können Angreifer dieselbe bekannte Schwachstelle auf vielen Websites ausprobieren. Der Sicherheitsanbieter Wordfence dokumentiert in seinem Bericht für das vierte Quartal 2025 zahlreiche Angriffsversuche auf WordPress-Plugins. Solche Versuche lassen sich automatisieren. Ein kleiner Betrieb ist deshalb nicht automatisch uninteressant: Dafür muss niemand seine Website persönlich ausgewählt haben.
Ein einziges verwundbares WordPress-Plugin bzw. eine verwundbare TYPO3-Extension kann als Einfallstor genügen. Solche Erweiterungen ergänzen etwa Formulare oder Gestaltungsfunktionen. Bei einer ausnutzbaren Sicherheitslücke können Angreifer je nach Fehler Inhalte verändern, Daten auslesen oder eigenen Schadcode auf dem Server ausführen. Dafür ist nicht immer ein gültiges Benutzerkonto erforderlich. Über manipulierte Kontakt- oder Bestellformulare können Angreifer zudem sensible Kundendaten wie persönliche Angaben oder Zahlungsinformationen direkt bei der Eingabe abgreifen.
Eine klassische WordPress- oder TYPO3-Installation verarbeitet Anfragen mit Programmcode auf dem Server und greift auf eine Datenbank zu. Jede zusätzliche Komponente vergrößert den Umfang der Software, die sicher gehalten werden muss. Dazu gehören das CMS, Erweiterungen, Gestaltungsvorlagen, PHP und der Datenbankdienst. Sicherheitsmeldungen, Aktualisierungen und die Verträglichkeit der Komponenten müssen im Blick bleiben. Das macht eine solche Website nicht automatisch unsicher, verursacht aber zusätzliche Arbeit. Hinweise dazu geben das WordPress-Handbuch zur Absicherung und die TYPO3-Dokumentation zu Sicherheitsupdates.
Bei einer vollständig statischen Website wie ravok.de fehlen diese Anwendungen im öffentlichen Betrieb. Es gibt dort keine WordPress- oder TYPO3-Anmeldung, keine laufenden Plugins oder Extensions und keine Inhaltsdatenbank. Eine Sicherheitslücke in einer solchen CMS-Komponente kann hier nicht zum Ändern der Website ausgenutzt werden, weil die entsprechende Komponente gar nicht vorhanden ist. Diese Angriffswege entfallen vollständig. Genau darin liegt für uns der wesentliche Sicherheitsvorteil.
Dieselben drei Bausteine im Vergleich: klassisches WordPress oder TYPO3 und die statische Auslieferung von ravok.de.
Auch automatisierte Versuche, bekannte Sicherheitslücken auszunutzen.
WordPress oder TYPO3
Eine CMS-Anwendung arbeitet auf dem Server.
Konten und Anmeldefunktionen von WordPress oder TYPO3 absichern.
Ein PHP-Interpreter führt das CMS, Plugins oder Extensions aus. Sicherheitsupdates und Prüfungen gehören dazu.
Das CMS liest und schreibt Inhalte. Datenbankdienst und Zugriffsrechte brauchen Pflege.
Zusätzliche Pflege und AngriffswegeEine ausnutzbare Lücke kann unberechtigte Änderungen oder Schadcode ermöglichen.
Statisch wie ravok.de
Der Webserver liefert fertige Dateien aus.
Hier gibt es keinen CMS-Zugang, dessen Passwort angegriffen werden könnte.
Kein PHP-Interpreter, keine Plugins oder Extensions für die Website. Deren Sicherheitslücken sind hier nicht ausnutzbar.
Kein Datenbankdienst für die Website und kein Zugriff darauf über eine CMS-Anwendung.
Diese Angriffswege entfallenDie entsprechende CMS-Anwendung ist hier gar nicht vorhanden.
Webserver, Verwaltungszugänge, Erstellungswerkzeuge und ausgelieferte Skripte brauchen immer Betreuung. Bei WordPress oder TYPO3 kommt die CMS-Pflege hinzu. Ein extern angebundenes CMS oder ein Formulardienst müsste bei Vorhandensein ebenfalls abgesichert werden.
Webserver, Hosting- und Veröffentlichungszugänge müssen bei allen drei Varianten abgesichert werden. Diese Aufgaben entfallen bei WordPress oder TYPO3 genauso wenig wie bei Astro; die CMS-Pflege kommt dort aber hinzu. Wer den Hostingzugang übernimmt, könnte sowohl eine CMS-Website als auch statische Dateien verändern. Ebenso bleiben die Werkzeuge zur Erstellung und ausgelieferte Skripte zu pflegen. Eine zusätzlich angebundene Inhaltsverwaltung oder ein Formulardienst müsste ebenfalls abgesichert werden. Die kleinere Angriffsfläche betrifft die öffentlich ausgelieferte Website, macht ihre Umgebung insgesamt aber nicht unangreifbar. Die Zahl der möglichen Angriffswege ist durch die entfallenen CMS-Komponenten deutlich geringer.
Statisch heißt nicht unbeweglich
Eine statische Website kann Menüs, aufklappbare Antworten, Animationen und interaktive Grafiken haben. Solche Funktionen können direkt im Browser laufen. Sie benötigen nicht zwangsläufig eine Anwendung, die auf dem Server für jeden Besucher arbeitet.
Auf ravok.de durchsucht die Seitensuche beispielsweise einen vorab erzeugten Suchindex. Sie lädt dazu eine Datei und wertet die Suchbegriffe im Browser aus. Auch der Themenfilter im Ratgeber und die Auswahl zwischen hellem und dunklem Erscheinungsbild funktionieren dort. Die eigentlichen Inhalte stehen bereits in den ausgelieferten Seiten.
Für eine gewöhnliche Kontaktanfrage brauchen wir kein Formular. Auf ravok.de stehen Telefonnummer und E-Mail-Adresse bereit. Ein E-Mail-Link öffnet das eingerichtete Mailprogramm; wer Webmail verwendet, kann die Adresse kopieren. Die Nachricht lässt sich mit den gewohnten Werkzeugen schreiben, mit Anhängen versehen und im eigenen Gesendet-Ordner wiederfinden. Ein Formular mit Name, E-Mail-Adresse und Freitext würde für diesen Ablauf kaum etwas hinzufügen.
Ein Formular, das Nachrichten direkt über die Website versendet, braucht dafür einen Dienst. Dieser muss gegen automatisierte Einsendungen und Missbrauch geschützt, gewartet und auf Zustellprobleme geprüft werden. Dazu kommen je nach Umsetzung Mengenbegrenzungen, Spamfilter oder CAPTCHAs. Externe Schutzdienste können Kosten und zusätzliche Abhängigkeiten verursachen. Ein kostenloses Angebot ist etwa Cloudflare Turnstile. Dessen kostenloser Tarif erlaubt nach Stand vom 13. September 2026 bis zu 20 Widgets je Konto und zehn Hostnamen je Widget. Die Zahl der Prüfungen ist dabei unbegrenzt; das Kontingent betrifft die eingerichteten Widgets und Hostnamen. Auch E-Mail braucht Spamfilter, ein zusätzlicher Formulardienst schafft jedoch einen weiteren Eingang, der abgesichert werden muss.
Solche CAPTCHAs bedeuten aber, dass man einen Drittanbieter einbinden muss. Bei Turnstile erhält Cloudflare Besucherdaten wie die IP-Adresse und technische Browsermerkmale. Ein extern betriebener Formulardienst verarbeitet zusätzlich die übermittelten Nachrichten und Kontaktdaten. Über diese Datenverarbeitung, die jeweiligen Empfänger, Zwecke und Rechtsgrundlagen muss die Datenschutzerklärung informieren, wie es Artikel 13 DSGVO vorsieht.
Auch eine strukturierte Anfrage lässt sich ohne eigenen Formulardienst vorbereiten. Ein Formular kann die Angaben im Browser sammeln und daraus einen E-Mail-Link mit vorausgefülltem Betreff und Nachrichtentext erzeugen. Dafür sieht das mailto-Format die Felder subject und body vor. Es öffnet einen Entwurf im eingerichteten Mailprogramm; der Besucher prüft und versendet ihn selbst. Das eignet sich für überschaubare Textangaben. Anhänge ergänzt der Besucher im Mailprogramm. Bei langen Texten oder fehlender Mailprogramm-Zuordnung ist eine Möglichkeit zum Kopieren der Angaben sinnvoll.
Ein Formulardienst kann sinnvoll sein, wenn Besucher direkt auf der Website Nachrichten versenden, Dateien hochladen oder Vorgänge mit einer Eingangsbestätigung anstoßen sollen. Ein solcher Dienst lässt sich auch mit einer statischen Website verbinden. Für unsere einfache Kontaktaufnahme ist dieser zusätzliche Betrieb nicht erforderlich.
Entscheidend ist, wer die Angaben übernimmt und die Nachricht abschickt.
Direkt auf der Website senden
Ein Dienst verarbeitet die Einsendung.
- Angaben im Browser sammeln
Ein Formular erfasst Texte und bei Bedarf Dateien.
- Formulardienst ansprechen
Der Dienst prüft Eingaben und schützt den Eingang vor Missbrauch.
- Nachricht zustellen
Der Dienst versendet die Nachricht oder legt einen Vorgang an.
Versand, Missbrauchsschutz und Fehlerbehandlung gehören zum Betrieb.
E-Mail vorbereiten
Das Mailprogramm übernimmt den Versand.
- Angaben im Browser sammeln
Ein Formular kann die benötigten Textangaben ordnen.
- Mailentwurf öffnen
Ein mailto-Link übergibt Betreff und Nachrichtentext.
- Selbst prüfen und senden
Der Besucher ergänzt bei Bedarf Anhänge und versendet die E-Mail.
Ein eingerichtetes Mailprogramm wird benötigt. Die Angaben können zusätzlich zum Kopieren angeboten werden.
Weniger laufende Technik, weniger Pflegeaufgaben
Der geringere Umfang laufender Software vereinfacht auch die Betreuung. Bei WordPress gehören Aktualisierungen des Systems, seiner Plugins und Themes zum Betrieb, bei TYPO3 entsprechend des Systems und seiner Extensions. Automatische Aktualisierungen können Arbeit abnehmen; Sicherungen und die Kontrolle, ob die Website danach noch funktioniert, bleiben nötig. Bei unserer statischen Website entfällt diese laufende CMS-Pflege auf dem Webserver.
Domain, Zertifikate, Webserver und Verwaltungszugänge brauchen weiterhin Betreuung. Von den Texten, Bildern und dem Programmcode der Website brauchen wir wiederherstellbare Sicherungskopien, damit der aktuelle Stand bei Verlust oder versehentlichen Änderungen wieder aufgebaut werden kann. Auch die Werkzeuge zum Erstellen der Website werden gepflegt. Der Unterschied liegt darin, welche Software dauerhaft im öffentlichen Betrieb benötigt wird.
Die fertige Seite liegt schon vor dem ersten Besuch bereit. Auch ohne zusätzlichen Seitencache muss der Server weder PHP-Programmcode noch Datenbankabfragen für den Seitenaufbau ausführen. Gegenüber einer ungecachten CMS-Seite entfällt damit ein wesentlicher Teil der Arbeit und Wartezeit auf dem Server. Die statische Website bringt das Ergebnis bereits mit, das ein Seitencache sonst erst speichern müsste.
Bei WordPress oder TYPO3 muss ein Seitencache zunächst gefüllt und nach Änderungen erneuert werden. Liefert er dauerhaft dieselben vollständigen Seiten an alle Besucher, ist das ein guter Anlass zu prüfen, ob sich diese Seiten gleich vorab erzeugen lassen. Ein gut eingerichteter Cache kann sie ähnlich effizient ausliefern; Warenkörbe, Konten und andere individuelle Vorgänge brauchen weiterhin ihre Verarbeitung. Statische Dateien sind außerdem leicht auf einen anderen Webserver übertragbar. Für die Ladezeit im Browser bleiben bei jeder Variante Bildgrößen, Skripte und Fremdinhalte entscheidend.
Wer ändert später die Texte?
Diese Frage sollte vor der technischen Entscheidung geklärt sein. Auf unserer Website liegen Texte und Inhalte in Dateien. Wir ändern sie, prüfen die Vorschau und erstellen anschließend den neuen Stand. Für uns passt das zum Arbeitsablauf.
Für einen Betrieb, der nur gelegentlich neue Bilder, Leistungen oder Öffnungszeiten einpflegt, kann eine Betreuung nach Bedarf ebenso passen. Möchten mehrere Mitarbeiter täglich selbst Beiträge verfassen, Bilder verwalten und Veröffentlichungen abstimmen, hat eine gute Redaktionsoberfläche dagegen einen konkreten Nutzen.
Astro lässt sich dafür mit einem Headless CMS verbinden. „Headless“ bedeutet hier, dass die Inhaltsverwaltung von der Darstellung der Website getrennt ist: Das CMS bietet die Redaktionsoberfläche und stellt die Inhalte bereit. Astro übernimmt die Gestaltung und erzeugt daraus die Seiten. Die Astro-Dokumentation zur CMS-Anbindung beschreibt diese Möglichkeit und verschiedene passende Systeme.
Die Redaktion kann so Texte und Bilder selbst pflegen, ohne die Dateien der Website bearbeiten zu müssen. Für eine weiterhin vollständig statische Auslieferung ruft Astro die freigegebenen Inhalte beim Erstellen ab. Nach Änderungen werden die Seiten neu erzeugt und bereitgestellt. Beim Besuch werden weiterhin fertige Dateien ausgeliefert; das CMS muss dafür nicht bei jedem Seitenaufruf angesprochen werden.
Eine Redaktionsoberfläche setzt weder WordPress noch TYPO3 voraus. Auch häufige Änderungen und mehrere Bearbeiter lassen sich mit Astro und einem passenden Headless CMS abbilden. Welche Inhaltsverwaltung geeignet ist, richtet sich nach den benötigten Bearbeitungs- und Freigabeabläufen.
Drei typische Anforderungen und ihre Folgen für die Auswahl. Sie können auch gemeinsam auftreten.
- Informieren und Anfragen erhalten
Leistungen, Referenzen, Kontakt und gelegentliche Beiträge.
Statische Website prüfenFertige Seiten reichen oft aus. Inhaltspflege und Aktualisierung werden vorher vereinbart.
- Inhalte im Team selbst pflegen
Häufige Änderungen, mehrere Bearbeiter und abgestimmte Veröffentlichungen.
Astro mit Headless CMS verbindenDas CMS verwaltet die Inhalte getrennt von der Website. Astro erzeugt daraus fertige Seiten. So bleibt die Website statisch, während das Team Inhalte über eine Redaktionsoberfläche pflegt.
- Bestellungen oder Buchungen verarbeiten
Warenkorb, Zahlung, Kundenkonto oder verbindliche Terminvergabe.
Ein Shopsystem wie WooCommerce prüfenWooCommerce ergänzt WordPress um einen selbst betriebenen Shop mit vielen Zahlungs- und Anbindungsmöglichkeiten. Produkte, Varianten und laufende Kosten bestimmen die Eignung. Für Termine kommt ein passendes Buchungssystem infrage.
Statische Auslieferung und gemeinsame Inhaltspflege passen zusammen. Eine Redaktionsoberfläche setzt weder WordPress noch TYPO3 voraus.
Wann WordPress oder TYPO3 die passende Wahl ist
WordPress oder TYPO3 können sinnvoll sein, wenn ein Unternehmen bereits gut mit dem jeweiligen System arbeitet oder benötigte Funktionen durch passende Erweiterungen wirtschaftlich umsetzen kann. Eine Redaktion oder mehrere Bearbeiter allein geben dabei nicht den Ausschlag; das ist auch mit Astro und einem Headless CMS möglich.
Eine gut betreute WordPress- oder TYPO3-Website muss daher nicht ersetzt werden, nur weil eine statische Variante möglich wäre. Ein Wechsel kostet ebenfalls Arbeit: Inhalte und Adressen müssen erhalten, Weiterleitungen eingerichtet und vorhandene Funktionen geprüft werden. Diese Arbeit sollte einen nachvollziehbaren Nutzen haben.
Für einen neuen Firmenauftritt lohnt sich dagegen die offene Frage: Welche Funktionen brauchen wir wirklich und welche würden nur mitlaufen, weil man es immer so gemacht hat?
Für einen selbst betriebenen Webshop ist WooCommerce oft eine naheliegende Wahl. Die Open-Source-Shopsoftware für WordPress hat einen kostenlosen Kern und eine große Auswahl an Erweiterungen, etwa für Zahlungsarten, Versand und Schnittstellen. Ein Shop lässt sich so ohne Bindung an eine gemietete Komplettplattform aufbauen. Gerade bei üblichen Produkten und vorhandener WordPress-Erfahrung kann das einen günstigen Einstieg ermöglichen. Hosting, Betreuung, Zahlungsgebühren und gegebenenfalls kostenpflichtige Erweiterungen gehören dennoch in die Rechnung.
Auch PrestaShop und die Shopware Community Edition sind selbst betreibbare Open-Source-Alternativen. Ob sie für einen Kunden ebenso leicht zu bedienen und insgesamt günstiger sind, prüfen wir an seinen Produkten, benötigten Anbindungen und Arbeitsabläufen. Der kostenlose Kern allein entscheidet das nicht.
Wenn Produktvarianten den günstigen Einstieg teuer machen
Wie schnell sich Produktvarianten vervielfachen, lässt sich an Kontaktlinsen zeigen. Bei Linsen zur Korrektur von Astigmatismus können neben Sphäre, Zylinder und Achse auch Basiskurve und Durchmesser variieren. Bei multifokalen torischen Linsen kommt die Addition für den Nahbereich hinzu. Solche Parameter beschreiben etwa Menicon für individuelle Linsen und CooperVision für multifokale torische Linsen. Sind die angebotenen Werte miteinander kombinierbar, multiplizieren sich ihre Anzahlen. So können aus einem Linsenmodell mehrere Tausend bis über eine Million Varianten werden.
Linsenvarianten werden als eigenständige Handelsartikel mit eigenen GTINs geführt. Bei Biofinity Toric Multifocal zeigen das beispielsweise zwei unterschiedliche Ausführungen in der 6er-Packung mit den GTINs 195033021600 und 195033065598. Die GTIN, häufig noch EAN genannt, kennzeichnet den konkreten Handelsartikel einschließlich seiner Ausführung und Packungsgröße. GS1 erläutert diese eindeutige Artikelkennzeichnung.
Der Shop muss die gewählte Parameterkombination dem richtigen Artikel zuordnen. Der Augenoptiker bestellt die benötigte Linse beim Hersteller in genau dieser Ausführung. Er kann eine gelieferte Linse nicht nachträglich auf eine andere Stärke, Achse oder Krümmung ändern. Deshalb müssen Linsenmodell, Parameter, Packungsgröße und Artikelkennung vom Warenkorb über die Herstellerbestellung bis zur Auslieferung zusammenpassen. Auch Verfügbarkeit und gegebenenfalls Lagerbestände beziehen sich auf die konkrete Ausführung. Zusätzliche Auswahlfelder erfüllen diese Aufgabe nur, wenn ihre Werte zuverlässig zum passenden Artikel führen und an die nachfolgenden Systeme übergeben werden.
Ein Variantenkatalog dieser Größenordnung muss vor der Systemwahl mit realistischen Artikeldaten geprüft werden. Dazu gehören auch Datenimporte, die Suche nach der passenden Ausführung und die Anbindung an Lieferanten oder Warenwirtschaft. Wie das Shopsystem die angebotenen Ausführungen abbildet, speichert und abfragt, beeinflusst Verwaltung und Seitenaufbau erheblich. Ein Cache kann die Auslieferung beschleunigen, ändert aber das zugrunde liegende Produktmodell nicht. Die Eignung von WooCommerce hängt deshalb auch davon ab, wie der Katalog aufgebaut ist.
Bei Kontaktlinsen können viele Parameter zusammenkommen. Sind alle angebotenen Werte miteinander kombinierbar, multiplizieren sich ihre Anzahlen.
Die Beispiele verwenden die Parameterbereiche von Biofinity toric und Menicon Vintage multifokal torisch.
Eigene GTINs für konkrete LinsenvariantenBei Biofinity Toric Multifocal sind unterschiedliche Ausführungen mit eigenen GTINs belegt. Der Shop muss die gewählten Parameter und die Packungsgröße dem richtigen Artikel zuordnen, damit Herstellerbestellung, Lieferung und Bestandsführung zusammenpassen.
Rechnerische Kombinationen für jeweils eine Packungsgröße. Maßgeblich sind die angebotenen Ausführungen und die Bestellvorgaben des Herstellers.
Die laufenden Kosten gehören zur Entscheidung
Vergleichen Sie beim Angebot nicht nur den Preis für die Erstellung. Fragen Sie auch, was spätere Textänderungen kosten, wer Aktualisierungen übernimmt, wie Sicherungen funktionieren und wie Sie die Website bei einem Anbieterwechsel mitnehmen können. Eine günstige Vorlage kann im Betrieb Aufwand verursachen; eine individuell erstellte statische Seite kann bei häufigen Änderungen durch den Dienstleister ebenfalls teuer werden.
Für ravok.de passt Astro, weil wir Informationen veröffentlichen und Anfragen erhalten möchten, ohne einen Shop oder Kundenkonten auf der Website zu betreiben. Wir brauchen dafür keine ständig laufende Inhaltsverwaltung auf dem Webserver. Dass ein solcher Auftritt trotzdem einen Blog, ein Glossar, eine Suche und Infografiken haben kann, sehen Sie auf diesen Seiten.
Bei Ihrem Unternehmen beginnen wir deshalb mit den Inhalten, den benötigten Funktionen und der späteren Pflege. Daraus ergibt sich die passende Technik. Mehr zu Gestaltung und Betreuung finden Sie unter Webauftritte und Onlineshops.
Weiterlesen
12. September 20263 Min.
Für viele Datenträger gibt es Angaben zur Belastbarkeit und erwarteten Haltbarkeit. Wann ein einzelnes Laufwerk ausfällt, lässt sich daraus jedoch nicht vorhersagen. Was das für Backups bedeutet und warum eine Sicherung auch zurückgespielt werden muss.
Weiterlesen12. September 20262 Min.
Ein Sturz, ein Wasserschaden, ein vergessener Code, und das mobile Büro ist weg. Was sich retten lässt, was nicht, und wie man es so einrichtet, dass der Verlust des Geräts kein Verlust der Daten ist.
SmartphoneDatensicherungDatenrettung
Weiterlesen12. September 20264 Min.
Zwei Steuerberater gründen eine Kanzlei. Welche technischen Entscheidungen sie früh treffen sollten und wie Datenwege, Zugriffsrechte und die Abstimmung mit Dienstleistern zusammenhängen.
Weiterlesen