Wix, WordPress, Webflow oder individuelle Entwicklung: Die falsche Frage kostet später am meisten

Zwei Offerten, zwei «Nur so macht man das» – am selben Vormittag

Ein fiktives Beispiel für eine typische Situation: Sandra Aeschbacher führt eine kleine Physiotherapie-Praxis in Biel/Bienne, zweisprachig wie die Stadt selbst: Patientinnen und Patienten schreiben ihr auf Deutsch und auf Französisch, oft in derselben Woche. Ihre bestehende Website ist acht Jahre alt, sieht auch so aus, und sie will das ändern. An einem Vormittag im Frühling führt sie zwei Beratungsgespräche. Der erste Anbieter, ein lokaler Freelancer, ist nach zehn Minuten fertig: «Für eine Einzelpraxis reicht ein Baukasten wie Wix locker, alles andere ist rausgeschmissenes Geld.» Der zweite, Verkäufer einer Webagentur, ist genauso schnell überzeugt: «Bei Ihrem Anspruch kommt nur eine individuelle Website infrage, alles andere wirkt bei Patientinnen unprofessionell.»

Beide Aussagen klingen erfahren. Beide wurden getroffen, bevor irgendjemand gefragt hat, wie oft Sandra ihre Öffnungszeiten selbst ändert, ob sie auf Französisch genauso gut gefunden werden will wie auf Deutsch, wie viel Budget tatsächlich vorhanden ist, oder wer die Website pflegt, falls sie die Praxis in fünf Jahren verkauft. Das ist das eigentliche Problem an der Frage «Wix, WordPress, Webflow oder individuell?» – sie hat keine allgemeingültige Antwort, weil sie die falsche Frage ist. Die richtige Frage lautet: Welche Plattform-Kategorie erfüllt meine tatsächlichen Anforderungen am besten – und welche Kompromisse bin ich im Gegenzug bereit, in Kauf zu nehmen?

Die sechs Fragen, die vor der Plattformwahl kommen

Jede der vier Plattform-Kategorien – Baukästen wie Wix, WordPress, Webflow und individuelle Entwicklung – ist in irgendeiner Konstellation die richtige Wahl. Keine ist grundsätzlich überlegen, weil «Plattform» kein einzelnes Merkmal ist, sondern ein Bündel aus sechs Faktoren, die je nach Betrieb unterschiedlich stark gewichtet werden müssen.

• Eigentum und Portabilität – Gehören Ihnen Code und Inhalte wirklich, und können Sie beides mitnehmen, falls Sie Anbieter oder Agentur wechseln wollen?
• Performance – Wie schnell kann die Seite technisch werden, und wovon hängt das tatsächlich ab?
• Bearbeitbarkeit – Kann jemand in Ihrem Team ohne Entwickler:in Texte, Bilder und Öffnungszeiten selbst aktualisieren?
• Sicherheit und Wartung – Wer ist dafür verantwortlich, dass Software-Updates, Backups und Sicherheitslücken nicht liegen bleiben?
• Mehrsprachiges SEO – Wie sauber lassen sich Deutsch, Französisch, Italienisch und Englisch technisch trennen, ohne dass Google eine Sprache als Duplikat einer anderen behandelt?
• Gesamtkosten über die Zeit – Was kostet die Website nicht nur beim Start, sondern im dritten, fünften und zehnten Betriebsjahr?

Eigentum und Portabilität: Was bleibt Ihnen, wenn Sie gehen wollen?

Diese Frage stellt sich niemand gerne beim Start eines Projekts – und genau deshalb wird sie am häufigsten übersehen. Sie entscheidet aber, wie teuer ein späterer Wechsel wird.

• Baukästen wie Wix: Wix ist als SaaS-System gebaut und läuft ausschliesslich auf der Infrastruktur des Anbieters; ein Export von Website-Code oder -Design ist laut Wix' eigenem Hilfe-Center nicht vorgesehen. Exportierbar sind einzelne strukturierte Inhalte – etwa Produktlisten, Bestellungen oder CMS-Collections als CSV –, nicht aber Blogbeiträge zu anderen Plattformen oder die Website als Ganzes. Ein Anbieterwechsel bedeutet in der Praxis: neu bauen, nicht umziehen.
• WordPress: Hier zählt eine Unterscheidung, die im Verkaufsgespräch selten fällt. Selbst gehostetes WordPress (WordPress.org) ist quelloffene Software unter GPL-Lizenz, die Sie auf jedem Hosting installieren dürfen – Code und Datenbank gehören vollständig Ihnen, ein Hosterwechsel ist eine technische Aufgabe, kein Rechtsproblem. WordPress.com dagegen ist ein gehosteter Dienst mit eigenen Einschränkungen, die dem Baukasten-Modell näherstehen als der offenen Variante. Wer «WordPress» hört und automatisch volle Portabilität annimmt, sollte zuerst klären, von welcher der beiden Varianten überhaupt die Rede ist.
• Webflow: Teilweise portabel, und das ist die ehrliche, etwas unbequeme Antwort. Auf kostenpflichtigen Workspace-Plänen lässt sich laut Webflow University der HTML-, CSS- und JavaScript-Code exportieren. Was dabei nicht mitkommt, sind dynamische CMS-Inhalte – also genau die Collection-Seiten, aus denen ein inhaltsreicher Firmenauftritt meist grösstenteils besteht. Portabel ist damit die Hülle, nicht zwingend das, was die Website inhaltlich ausmacht.
• Individuelle Entwicklung: Grundsätzlich gehören Ihnen Code und Datenmodell vollständig, weil beides eigens für Sie entsteht. Das ist aber kein Automatismus für Portabilität – wenn nur eine einzelne Entwickler:in oder Agentur den Aufbau versteht und keine Dokumentation existiert, ist ein «individuell gebautes» Projekt beim Anbieterwechsel manchmal so schwer zu übernehmen wie ein Baukasten, nur ohne dessen Exportfunktionen für einzelne Inhalte.

Performance: Eine Obergrenze ist kein Versprechen

«Wie schnell wird meine Seite?» ist eine der meistgestellten Fragen – und eine, bei der die Plattform-Kategorie nur die Obergrenze setzt, nicht das Ergebnis.

• Baukästen: Die Seite läuft über die gemeinsame Infrastruktur und Rendering-Logik des Anbieters. Für die meisten kleinen Websites ausreichend schnell, aber nicht durch eigene technische Eingriffe weiter optimierbar – Sie sind an das gebunden, was der Anbieter an Kontrolle freigibt.
• WordPress: Die grösste Spannbreite aller vier Kategorien. Ein schlank gehaltenes WordPress mit sauberem Theme, wenigen Plugins und vernünftigem Hosting kann sehr schnell sein. Dieselbe Software mit einem schwergewichtigen Page-Builder, einem Dutzend Plugins und günstigem Massen-Hosting kann spürbar langsam werden. Die Kategorie liefert kein Performance-Versprechen mit, sondern eine Baustelle, die gut oder schlecht gepflegt werden kann.
• Webflow: Für klassische, überwiegend statische Marketing-Seiten in der Regel ein sauberes, schlankes Ergebnis. Je mehr CMS-Logik, Interaktionen und dynamische Elemente dazukommen, desto mehr Komplexität und JavaScript wächst mit.
• Individuelle Entwicklung: Die höchste erreichbare Obergrenze, weil jedes ausgelieferte Byte eine bewusste Entscheidung des Entwicklungsteams ist. Eine Obergrenze ist aber kein Ergebnis – ein schlecht geplantes individuelles Projekt kann langsamer sein als eine solide konfigurierte Baukasten-Seite. Weissmann liefert die eigenen Projekte beispielsweise auf einem modernen Static-Stack mit Astro und Netlify aus, der vorgerenderte Seiten mit minimalem JavaScript ausliefert – ein Beispiel dafür, was diszipliniert umgesetzte individuelle Entwicklung leisten kann, keine Aussage darüber, was jedes individuelle Projekt automatisch liefert.

Bearbeitbarkeit: Wer aktualisiert in zwei Jahren die Öffnungszeiten?

Die Website, die heute gebaut wird, braucht in zwei Jahren einen neuen Feiertag, ein geändertes Leistungsangebot oder ein neues Teamfoto – meistens ohne dass dafür wieder eine Rechnung gestellt werden soll. Wer das später erledigt, ist eine Entscheidung, die beim Bau getroffen wird, nicht danach.

• Baukästen: Für Laien in aller Regel die zugänglichste Option – Texte, Bilder und einfache Seiten lassen sich direkt im visuellen Editor anpassen, ohne Entwickler:in und ohne Admin-Bereich, der erst erklärt werden muss.
• WordPress: Der Block-Editor deckt einfache Textänderungen brauchbar ab. Sobald die Seite mit einem Page-Builder-Plugin aufgebaut wurde – was in der Praxis häufig vorkommt –, hängt die Bearbeitbarkeit stark davon ab, wie sauber dieser Aufbau ist und wie gut das Team eingeführt wurde.
• Webflow: Editor und Designer sind getrennt. Wer nur Texte in bereits angelegten CMS-Feldern ändert, kommt gut zurecht; wer neue Seitentypen oder Layout-Strukturen braucht, bewegt sich im Designer – und der ist näher an einem Gestaltungswerkzeug als an einer einfachen Textbox gebaut.
• Individuelle Entwicklung: Komplett offen, im guten wie im schlechten Sinn. Ein sauber gebautes Redaktionssystem kann genauso einfach sein wie ein Baukasten-Editor. Ohne ein eigens dafür beauftragtes Redaktionssystem bedeutet «individuell» aber oft: Jede Änderung geht über die Entwickler:in. Das ist keine Randnotiz, sondern ein Punkt, den man explizit bestellen muss.

Sicherheit und Wartung: Die Frage ist nicht ob, sondern wer patcht

Jede Website-Software braucht irgendwann ein Update. Die Kategorien unterscheiden sich nicht darin, ob das passiert, sondern darin, wer dafür verantwortlich ist – und ob diese Verantwortung überhaupt sichtbar irgendwo landet.

• Baukästen: Der Anbieter patcht die Plattform zentral für alle Kund:innen gleichzeitig. Für den Betrieb bedeutet das spürbar weniger eigenen Aufwand – im Gegenzug sind Sie von der Sicherheitspraxis und der Geschäftskontinuität dieses einen Anbieters abhängig.
• WordPress: Kern, Theme und jedes einzelne Plugin brauchen eigenständig Updates. Das ist eine der am besten dokumentierten Ursachen für gehackte WordPress-Seiten überhaupt – nicht weil die Software unsicher wäre, sondern weil die laufende Pflege im Alltag untergeht, wenn niemand explizit dafür zuständig ist.
• Webflow: Da der Anbieter hostet, liegt die Plattform-Wartung ähnlich wie bei einem Baukasten zentral beim Anbieter – niedriger Aufwand für den Betrieb, mit derselben Abhängigkeit von einem einzelnen Unternehmen.
• Individuelle Entwicklung: Keine automatische Plugin-Update-Tretmühle, wenn schlank gebaut wurde – aber die Verantwortung verschwindet nicht, sie verschiebt sich vollständig zu Ihnen oder Ihrer Agentur, inklusive Hosting-Überwachung, Zertifikaten und Rechenzentrums-Wahl. Wer diese Verantwortung nicht vertraglich klar zuordnet, hat sie am Ende meistens niemand übernommen.

Mehrsprachiges SEO: Der Faktor, den Schweizer KMU am häufigsten unterschätzen

Für ein Unternehmen wie Sandras Praxis in Biel/Bienne ist das kein Nice-to-have, sondern die Grundlage: Wer auf Deutsch und Französisch gefunden werden will, braucht mehr als übersetzten Text. Google muss erkennen, welche Sprachversion zu welcher gehört – über eigene URLs pro Sprache, korrekte hreflang-Auszeichnung und je eine eigenständige, nicht bloss automatisch übersetzte Seite.

• Baukästen: Eingebaute Mehrsprachigkeits-Funktionen existieren, unterscheiden sich aber deutlich darin, wie viel Kontrolle sie über URL-Struktur und hreflang tatsächlich zulassen. Für zwei bis drei Sprachen mit einfacher Struktur oft ausreichend, für eine wachsende, differenzierte Seitenarchitektur schnell einschränkend.
• WordPress: Ein ausgereiftes Ökosystem an Mehrsprachigkeits-Plugins erlaubt sehr feine Kontrolle über Sprach-URLs, hreflang und pro Sprache eigenständige Inhalte – auf Kosten von zusätzlicher Plugin-Komplexität, Lizenzkosten und wiederum eigener Wartung.
• Webflow: Eine native Lokalisierungsfunktion mit Subdirectory- oder Domain-Optionen existiert; da sich Umfang und Konditionen solcher Zusatzfunktionen bei jedem Anbieter über die Zeit ändern können, lohnt sich vor einer Entscheidung ein aktueller Blick in die Preisliste des Anbieters statt sich auf eine Momentaufnahme zu verlassen.
• Individuelle Entwicklung: Die höchste erreichbare Kontrolle über URL-Architektur, hreflang und Sprachtrennung – aber nichts davon passiert automatisch. Diese Basis muss explizit eingeplant und umgesetzt werden; «individuell» korrigiert kein schlecht durchdachtes Sprachkonzept von selbst.

Gesamtkosten über die Zeit: Der Angebotspreis ist die falsche Zahl

Ein Vergleich, der nur den Preis für den Bau selbst betrachtet, vergleicht die falsche Zahl. Relevanter ist, was in den folgenden drei bis zehn Jahren tatsächlich anfällt – eine ausführliche Drei-Jahres-Rechnung mit eigenen Zahlen ist ein eigenes Thema für sich, aber die Kategorien, die Sie dafür erfragen sollten, gehören schon in dieses Gespräch.

• Baukästen: Niedriger Einstieg, planbare, meist monatliche oder jährliche Abo-Kosten. Diese Kosten wachsen typischerweise mit jeder zusätzlichen App oder Funktion, die dazugebucht wird – prüfen Sie vor der Entscheidung, was der reguläre Preis nach einer allfälligen Einführungsaktion tatsächlich ist, nicht nur den Startpreis.
• WordPress: Die Software selbst ist kostenlos, dafür fallen Hosting, häufig ein Premium-Theme oder kostenpflichtige Plugins und – wenn Sie es nicht selbst machen – eine Wartungspauschale an. Die Summe dieser Einzelposten wird beim ersten Angebot gerne unterschätzt.
• Webflow: Keine separate Hosting-Rechnung, dafür ein Plan-Preis, der bei wachsendem Content-Umfang – etwa durch CMS-Item-Limits – in eine teurere Stufe wechseln kann.
• Individuelle Entwicklung: Die höchste Anfangsinvestition der vier Kategorien. Sie zahlt sich nur über einen längeren Zeitraum aus und nur, wenn der Umfang beim Bau tatsächlich kontrolliert wurde – diese Kategorie ist auch am stärksten jener Kostenexplosion ausgesetzt, die im nächsten Abschnitt beschrieben wird.

Wann ein Baukasten wie Wix die richtige Antwort ist

Diese Aufzählung ist kein Pflichtabschnitt, den jeder Ratgeber aus Höflichkeit einbaut – sie beschreibt einen sehr realen, sehr häufigen Fall in der Schweizer KMU-Landschaft.

Ein Baukasten wie Wix ist die ehrlich richtige Wahl, wenn mehrere dieser Punkte gleichzeitig zutreffen: eine überschaubare Anzahl Seiten, die sich in den nächsten Jahren nicht grundlegend verändert; ein Betrieb an einem einzigen Standort in ein oder zwei Sprachen, ohne den Anspruch, in jeder davon differenziert für Suchmaschinen sichtbar zu sein; ein Budget, das eine grössere individuelle Investition schlicht nicht hergibt; eine Inhaberin oder ein Inhaber, die oder der Texte selbst pflegen will, ohne je wieder eine Agentur anrufen zu müssen; und ein Zeitplan, der eine Website in Tagen statt Wochen verlangt. Für einen Coiffeursalon, eine Einzelpraxis mit einem Standort oder einen Handwerksbetrieb mit fünf klaren Seiten ist das nicht die zweitbeste Lösung, die man sich mangels Budget erlaubt – es ist die Lösung, die zur Anforderung passt. Individuelle Entwicklung für dieses Profil zu empfehlen, ist derselbe Fehler wie ein Baukasten für ein Unternehmen mit komplexer, mehrsprachiger Architektur: eine Plattform-Vorliebe, die als Anforderungsanalyse verkleidet wird.

Was in jeder Kategorie schiefgehen kann

Jede der vier Kategorien hat einen eigenen, typischen Fehlerfall – keiner davon ist hypothetisch.

• Baukasten: Das Unternehmen wächst aus der Plattform heraus – etwa weil eine mehrsprachige Buchungsfunktion nötig wird, die der Baukasten nicht sauber abbildet – und stellt erst dann fest, dass «Umzug» faktisch «Neubau» bedeutet, weil Design und Struktur nicht exportierbar sind.
• WordPress: Updates werden über Monate aufgeschoben, bis eine veraltete Plugin-Version zum Sicherheitsproblem wird – oder die Agentur, die den ursprünglichen Plugin-Stack konfiguriert hat, existiert nicht mehr, und niemand versteht mehr vollständig, was die zwölf installierten Plugins im Zusammenspiel eigentlich tun.
• Webflow: Der Designer-Zugang liegt ausschliesslich bei der Agentur, und der Kunde merkt erst beim Streit über die Rechnung, dass er selbst keinen strukturellen Zugriff hat. Oder: Man verlässt sich auf «wir können ja jederzeit exportieren» und stellt beim tatsächlichen Wechsel fest, dass genau die CMS-Inhalte fehlen, aus denen die Seite grösstenteils bestand.
• Individuelle Entwicklung: Der Klassiker ist der Projektumfang, der während der Umsetzung wächst, bis das Budget aufgebraucht ist, bevor die Website live geht. Der zweite, leisere Fehlerfall: Das Projekt startet zwar, aber nur eine einzige Person versteht am Ende den gesamten Aufbau – ohne Dokumentation wird jede spätere Änderung zum Risiko, unabhängig davon, wie sauber der Code ursprünglich geschrieben wurde.

Sechs Fragen für Ihre eigene Entscheidung

Die sechs Faktoren aus diesem Artikel lassen sich in sechs konkrete Fragen übersetzen, die Sie sich – oder besser: mit Ihrem Team – vor jedem Angebotsgespräch stellen sollten:

• Muss ich Code und Inhalte jemals vollständig mitnehmen können, auch wenn das heute unwahrscheinlich klingt?
• Wie wichtig ist mir Ladezeit wirklich – für das Suchmaschinen-Ranking, für die Nutzererfahrung, oder eher symbolisch?
• Wer in meinem Team wird die Website in zwei Jahren tatsächlich anfassen – und mit welchem technischen Vorwissen?
• Bin ich bereit, laufend Zeit oder Geld für Wartung einzuplanen, oder brauche ich ein System, das mir diese Sorge abnimmt?
• Verkaufe ich heute oder in absehbarer Zeit über eine Sprachgrenze hinweg – und wie differenziert muss ich dafür pro Sprache auffindbar sein?
• Rechne ich in Franken für dieses eine Jahr, oder für die nächsten fünf?

Fazit: Die Reihenfolge der Fragen entscheidet

Sandra aus Biel/Bienne hat sich am Ende weder für den Baukasten noch für die individuelle Entwicklung entschieden, weil ein Berater überzeugender war, sondern weil sie ihre sechs Antworten kannte, bevor sie ein drittes Gespräch führte: zweisprachiger Betrieb mit dem Anspruch, in beiden Sprachen einzeln gefunden zu werden, mittleres Budget, eine Website, die sie selbst mit Texten pflegen will, aber kein Interesse an eigenem Server-Management. Das Ergebnis dieser Anforderungen wird in diesem Artikel bewusst nicht vorweggenommen – weil es für Ihr Unternehmen andere Antworten geben kann als für ihres. Der nächste Schritt ist nicht, sich für eine Plattform zu entscheiden, sondern die sechs Fragen oben für Ihr eigenes Unternehmen ehrlich zu beantworten, bevor Sie das nächste Beratungsgespräch führen.