Eine Webflow-Website muss technisch überarbeitet werden, wenn routinemäßige Änderungen Stunden statt Minuten in Anspruch nehmen, das Stylesheet Hunderte ungenutzter CSS-Klassen enthält, sich die Ladegeschwindigkeit der Seiten trotz „Korrekturen“ immer weiter verschlechtert und nur eine einzige Person versteht, wie die Website tatsächlich aufgebaut ist. Das sind keine harmlosen Probleme. Sie müssen angegangen werden.
Eine Studie von Webflow aus dem Jahr 2026 ergab: 97 % der technischen Führungskräfte geben an, dass technische Schulden ihre Fähigkeit zur Verwaltung der Website erheblich beeinträchtigen. 95 % der Marketing-Führungskräfte erklären, dass aktuelle Governance-Praktiken ihre Arbeit aktiv behindern. Kommt euch das bekannt vor? Unser Service Webflow Rebuild kann die technische Grundlage sanieren.
Neuaufbau vs. Neugestaltung vs. Schnelllösung
Bevor ihr eine Diagnose für eure Website erstellt, ist es hilfreich, drei verschiedene Probleme voneinander zu unterscheiden, die ständig in einen Topf geworfen werden.
Ein Redesign verändert das Erscheinungsbild und die Kommunikation eurer Website – neues Layout, neue Botschaften, neue visuelle Identität.
Ein Relaunch bewahrt euer bestehendes Design, euren Content und eure Struktur. Er ersetzt jedoch die zugrunde liegende technische Basis: übersichtliche Components, ein strukturiertes CMS und solide Leistung.
Unsere eigene Einschätzung, basierend auf Dutzenden solcher Projekte: Die meisten Unternehmen entscheiden sich für ein Redesign, obwohl sie eigentlich einen kompletten Neuaufbau benötigen. Wenn euer Design bei eurer Zielgruppe nach wie vor Anklang findet und eure Botschaften weiterhin zum Kauf führen, wird eine Änderung der visuellen Gestaltung ein langsames, anfälliges CMS nicht beheben. Sie wird lediglich die gleichen technischen Schulden mit einem neuen Anstrich überdecken.
Anzeichen 1: Einfache Änderungen dauern Stunden statt Minuten
Das ist das eindeutigste Signal. Bei einer gut strukturierten Webflow-Website sollte das Ändern einer Überschrift, das Austauschen eines Bildes oder das Duplizieren eines Abschnitts nur wenige Minuten dauern. Ohne dass ihr euch Sorgen machen müsst, dass dadurch eine andere Seite beschädigt wird. Wenn dieselbe Aufgabe einen Entwickler 30 bis 60 Minuten kostet, weil eine Änderung in einem Abschnitt unerwartet Auswirkungen auf drei andere hat, hat die Komponentenarchitektur der Website bereits versagt.
Der „State of the Website Report 2026“ von Webflow ergab: 92 % der befragten Unternehmen melden wachsende Anforderungen an Umfang und Komplexität bei Website-Aktualisierungen. Nur 28 % der Unternehmen liefern Webprojekte konsequent pünktlich und im Budget. Diese Kluft zwischen euren Anforderungen und dem, was die technische Basis leisten kann, ist das Symptom einer Website, die über ihre ursprüngliche Struktur hinausgewachsen ist.
Anzeichen 2: Überladene CSS-Klassen und ungenutztes CSS häufen sich an
Mit dem visuellen Editor von Webflow ist es ganz einfach, eine neue CSS-Klasse zu erstellen, anstatt eine bestehende wiederzuverwenden. Auf lange Sicht kann diese Bequemlichkeit jedoch zu einer übermäßigen Verbreitung von CSS-Klassen, uneinheitlichen Bezeichnungen, stilistischen Konflikten und einem Stylesheet führen, dessen Pflege immer schwieriger wird.
Eine aufgeblähte CSS-Klassenstruktur entsteht selten durch eine einzige Fehlentscheidung. Sie wächst meist schrittweise. Entwickler, Freiberufler und interne Marketingmitarbeiter fügen „nur noch eine weitere CSS-Klasse“ hinzu, statt Vorhandenes wiederzuverwenden oder umzustrukturieren. Bleibt dies unkontrolliert, entsteht eine Website, die zwar weiterhin ansprechend aussieht, deren Bearbeitung jedoch langsamer und riskanter wird.
Je größer die Website wird, desto gravierender werden die Auswirkungen auf das Geschäft. Bloomwell wandte sich mit einem stark gepatchten, maßgeschneiderten CMS an Designbase, das das Team daran hinderte, selbst grundlegende Aktualisierungen vorzunehmen. Anstatt weiterhin Notlösungen auf einer ungeeigneten Grundlage zu entwickeln, haben wir die Website in Webflow mit 123 modularen Components neu aufgebaut und den über 850 Produkte umfassenden Katalog des Unternehmens durch eine sich selbst aktualisierende Synchronisierung automatisiert.
Ohne diese Neugestaltung wäre Bloomwell angesichts des stetig wachsenden Produktkatalogs weiterhin auf ein anfälliges CMS und manuelle Produktaktualisierungen angewiesen gewesen. Das neue System bot dem Team eine Grundlage, die es erweitern, neu gestalten und skalieren konnte. Es sparte dabei schätzungsweise mehr als 100 Stunden manuelle Arbeit pro Jahr ein.
Die Erkenntnis ist ganz einfach: Ein aufgeblähtes CSS-Klassensystem ist nicht nur ein Problem, das sich durch eine Bereinigung im Designer beheben lässt. Es ist ein Frühwarnzeichen dafür, dass das gesamte Website-System die Arbeitsweise des Unternehmens möglicherweise nicht mehr unterstützt.
Anzeichen 3: Die Seitengeschwindigkeit sinkt trotz „Korrekturen“ weiter
Wenn euer Team bereits Bilder komprimiert, nicht verwendete Skripte entfernt oder andere vereinzelte Verbesserungen vorgenommen hat, die Seitenladegeschwindigkeit aber weiterhin abnimmt, liegt das Problem wahrscheinlich eher systemweit und nicht an einem einzelnen Element.
Wenn eure Webflow-Website wächst, können zusätzliche Integrationen, Custom Code, Animationen, Schriftarten, Medien und Skripte von Drittanbietern das Seitengewicht nach und nach erhöhen und die Darstellung verlangsamen. Jede einzelne Ergänzung mag für sich genommen harmlos erscheinen. In ihrer Gesamtheit können sie jedoch zu einer spürbar langsameren Nutzererfahrung führen, insbesondere auf mobilen Geräten.
Webflow identifiziert große oder falsch dimensionierte Bilder, JavaScript, das das Rendern blockiert, sowie Skripte von Drittanbietern als häufige Ursachen für eine verlangsamte Website-Leistung. In seinen Empfehlungen wird geraten, Bilddateien zu optimieren, unnötige Skripte zu reduzieren und nicht kritischen Code asynchron oder nur dort zu laden, wo er benötigt wird.
Aus diesem Grund können wiederholte Maßnahmen zur Geschwindigkeitsoptimierung das zugrunde liegende Problem oft nicht lösen. Wenn Leistungsprobleme über die Assets, den Code, die Interaktionen und die Seitenstruktur der Website verteilt sind, besteht die Lösung nicht in einer weiteren isolierten Anpassung. Möglicherweise ist eine umfassendere technische Überprüfung oder eine Neugestaltung erforderlich, bei der die gesamte Systemarchitektur im Blick genommen wird.
Anzeichen 4: Nur eine Person weiß, wie die Website funktioniert
Hier handelt es sich um ein Governance-Problem, das als technisches Problem getarnt ist. Wenn ein einzelner Entwickler (in der Regel der ursprüngliche Freiberufler) die einzige Person ist, die Änderungen sicher vornehmen kann, ohne dass dabei etwas kaputtgeht, hat das Unternehmen einen operativen Single Point of Failure – und nicht die Website.
Eine groß angelegte Studie von Webflow untermauert dies: 91 % der technischen Führungskräfte berichten von Reibungen zwischen technischen und nicht-technischen Teams bei Änderungen an der Website. 92 % sind der Meinung, dass die Zusammenarbeit zwischen Marketing und Entwicklung verbessert werden muss.
Unserer Erfahrung nach ist dies oft der Moment, in dem ein Unternehmen tatsächlich eine Agentur beauftragt – nicht, weil die Website schlecht aussieht, sondern weil die Person, die sie erstellt hat, das Unternehmen verlassen hat, zu viel zu tun hat oder nun einen Stundensatz für Änderungen berechnet, die eigentlich nur wenige Minuten dauern sollten.
Anzeichen 5: Das CMS passt nicht zur Arbeitsweise des Unternehmens
Ein Webflow CMS, das für 20 Produkte oder 5 Case Studies entwickelt wurde, hält den Anforderungen eines Unternehmens, das auf 200 Produkte oder 40 Case Studies angewachsen ist, selten stand. Zu den typischen Warnzeichen zählen doppelte Sammlungen, fest codiertes Content, das eigentlich dynamisch sein sollte, inkonsistente Felder bei ähnlichen Inhaltstypen sowie Vorlagen, die nicht mehr funktionieren, sobald das Content nicht mehr den ursprünglichen Annahmen entspricht.
Das Problem wird besonders deutlich, wenn Marketingteams Seiten nicht ohne die Mitwirkung von Entwicklern erstellen oder anpassen können. Crewmeister führte ein mehrstelliges Programm zur bezahlten Kundenakquise über eine Website ohne CMS durch. Jede Änderung an einer Landing Page, jeder Test einer Überschrift und jede Anpassung einer Kampagne erforderte einen Entwickler. Das Marketingteam hatte keine Eigenständigkeit. Die Kosten dieser Abhängigkeit stiegen mit jedem Kampagnenzyklus weiter an.
Designbase hat die Website mit 47 modularen Webflow-Components neu aufgebaut. Jede Component bietet konfigurierbare Inhalte, mehrere Designs und flexible Layouts. Das neue System ermöglichte es dem Team, Landing Pages eigenständig zusammenzustellen und zu testen. Für routinemäßige Kampagnenarbeiten musste niemand Code schreiben. Das Projekt verzeichnete innerhalb von sechs Monaten eine Steigerung der Konversionsrate um 50 % bei Werbeausgaben in Höhe von 1,4 Mio. €.
Anzeichen 6: Technische Schulden sind mittlerweile ein Budgetproblem und nicht mehr nur ein Ärgernis
Seid hier ganz offen: Technische Schulden sind teuer. Die Daten zeigen, dass sich die Situation verschlechtert, nicht verbessert. Unternehmen, die maßgeschneiderte Websites betreiben, überschreiten laut einer Studie von Webflow aus dem Jahr 2026 in 60 % der Fälle ihr Budget und in 66 % der Fälle ihren Zeitplan – Zahlen, die deutlich über dem ohnehin schon besorgniserregenden Durchschnitt von 53 % für Website-Projekte im Allgemeinen liegen. Nur 28 % der Unternehmen schaffen es überhaupt, Webprojekte termingerecht und im Rahmen des Budgets fertigzustellen.
Unsere Meinung dazu: Aus diesem Grund unterbreiten wir für Neugestaltungen einen festen, transparenten Preis. Er basiert auf einer tatsächlichen Analyse der Website – unter Berücksichtigung der tatsächlichen Seitenanzahl, der tatsächlichen Vorlagen und der tatsächlichen Komplexität des CMS. Wir geben keinen unbestimmten Stundensatz an. Wenn das zugrunde liegende Problem in unvorhersehbaren technischen Schulden liegt, verlagert ein Auftrag mit unbestimmter Laufzeit diese Unvorhersehbarkeit lediglich auf euer Budget.
Wie sich das in konkreten Projekten auswirkt
Case Studies sind hier hilfreich. Sie zeigen, wie die Situation „vorher“ in der Praxis aussah – nicht nur in der Theorie.
- Bloomwell: Ersetzte ein geflicktes, maßgeschneidertes CMS durch ein Webflow-System mit 123 Components und automatisierte einen Katalog mit über 850 Produkten, wodurch jährlich über 100 Stunden manueller Arbeit eingespart wurden.
- Crewmeister: Auf Basis eines modularen Systems aus 47 Components mit konfigurierbaren Inhalten und hellen bzw. dunklen Designs neu aufgebaut, was innerhalb von sechs Monaten zu einer Steigerung der Konversionsrate um 50 % bei Werbeausgaben in Höhe von 1,4 Mio. € führte.
- Paybyrd: Neuentwicklung auf Basis eines aus 196 Komponenten bestehenden, stapelbaren Systems unter Verwendung des Lumos-Frameworks mit maßgeschneiderten GSAP-Animationen; innerhalb von sechs Wochen bereitgestellt, um eine visuelle Qualität auf Fintech-Niveau zu erreichen.
- talque: Eine 88-seitige Neugestaltung in zwei Sprachen mit über 65 eigens angefertigten Illustrationen, die den visuellen Ansprüchen eines Produkts mit einer Bewertung von 4,6 Sternen gerecht wird.
In jedem dieser Fälle ging es von einer Website aus, die mit dem Geschäftswachstum nicht mehr Schritt halten konnte – nicht wegen eines schlechten Designs, sondern weil die technische Grundlage an ihre Grenzen gestoßen war.
Was ein Umbau eigentlich beinhaltet
Bei Designbase durchläuft eine technische Neugestaltung vier Phasen:
- In der Audit- und Scope-Phase führen wir einen Crawl der Website durch. Wir zählen die Seiten und Vorlagen. Dann erstellen wir eine Übersicht über das CMS. So ermitteln wir auf Grundlage realer Zahlen einen Festpreis.
- Phase des Kernumbaus, in der die Seiten auf einem neuen System mit Components neu erstellt werden, während die Live-Website davon unberührt bleibt.
- Die Detail-, QA- und SEO-Phase, in der alles zweimal getestet wird.
- Go-live- und Übergabephase mit Überwachung der Rankings und Schulung des Teams zur neuen Plattform.
Die Preise beginnen bei 10.000 €. Die meisten Projekte kosten zwischen 12.000 € und 22.000 €. Die Umsetzung dauert vier bis sechs Wochen. Dabei bleibt euer Design erhalten. Es ist kein vollständiger Relaunch.
Ein praktisches Modell zur Entscheidung über den Wiederaufbau
Eine Neuentwicklung sollte nicht allein deshalb genehmigt werden, weil eine Website veraltet wirkt. Sie sollte genehmigt werden, wenn die Kosten für die Weiterführung des aktuellen Systems die Kosten und Risiken einer Erneuerung der Basis übersteigen. Am sinnvollsten lässt sich diese Entscheidung treffen, indem ihr die Reibungsverluste in vier Bereichen messt: Veröffentlichungszeit, technische Qualität, betriebliche Abhängigkeiten und wirtschaftliches Risiko.
Die Vier-Faktoren-Bewertungsmatrix
Bewertet jede Kategorie mit einer Punktzahl von 0 bis 3:
| Kategorie | 0 Punkte | 1 Punkt | 2 Punkte | 3 Punkte |
|---|---|---|---|---|
| Reibungsverluste bei der Veröffentlichung | Routinemäßige Bearbeitungen dauern weniger als 15 Minuten | Bei einigen Bearbeitungen wird Hilfe benötigt | Für die meisten neuen Seiten wird ein Entwickler benötigt. | Fast jede Veränderung erfordert Unterstützung von außen |
| Technische Schulden | Klare CSS-Klassen und Components | Einige Überschneidungen | Wiederholte Überschreibungen und ungenutzte Stile | Kein zuverlässiges System oder keine zuverlässige Dokumentation |
| Leistung | Durchweg gute Core Web Vitals-Werte | Gelegentliche Warnungen | Wichtige Vorlagen sind langsam | Auch nach vereinzelten Korrekturen bestehen weiterhin Geschwindigkeitsprobleme |
| Geschäftliche Abhängigkeit | Die Website kann von mehreren Personen verwaltet werden | Eine Person verfügt über den größten Teil des Wissens | Das Team wartet auf einen Spezialisten | Die Seite ist blockiert, wenn diese Person nicht erreichbar ist. |
Ein Wert von 0–3 deutet in der Regel auf Wartungsarbeiten oder gezielte Bereinigungsmaßnahmen hin. Ein Wert von 4–7 legt ein Audit und möglicherweise eine teilweise Neuentwicklung nahe. Ein Wert von 8–12 spricht eindeutig für eine Neuentwicklung, insbesondere wenn die höchsten Werte auf Probleme bei der Veröffentlichung und geschäftlichen Abhängigkeiten zurückzuführen sind und nicht auf rein visuelle Probleme.
Dies ist weder ein wissenschaftlicher Maßstab noch ein Ersatz für einen Crawl. Es ist unsere interne Methode, um aus einem vagen Gespräch eine Entscheidung zu machen, die ein Marketingleiter, ein Gründer und ein Vertreter der Finanzabteilung gemeinsam bewerten können.
Die Verzögerungskosten hinzufügen
Die finanzielle Situation wird deutlicher, wenn ihr die Kosten eines blockierten Kampagnenzyklus schätzt. Verwendet dazu diese einfache Berechnung:
monatliche Kampagnenmöglichkeiten × verlorene Stunden pro Möglichkeit × gemittelte Stundenkosten
Wenn beispielsweise ein B2B-SaaS-Team vier wirkungsvolle Kampagnen pro Monat startet, pro Kampagne sechs Stunden aufgrund der Abhängigkeit von Webflow verliert und die kombinierte Zeit von Marketing und Entwicklern mit 100 Dollar pro Stunde bewertet, betragen die direkten Betriebskosten:
4 × 6 × 100 $ = 2.400 $ pro Monat
Dabei bleiben die Opportunitätskosten außer Acht, die entstehen, wenn die Markteinführung zu spät erfolgt, ein Zeitfenster für bezahlte Akquise verpasst wird, ein A/B-Test verzögert wird oder Traffic auf eine Seite geleitet wird, die nicht zum aktuellen Vertriebskonzept passt.
Bei 2.400 Dollar pro Monat entspricht eine Neuentwicklung im Wert von 12.000 Dollar einer direkten Zeitersparnis von fünf Monaten. Noch bevor die Auswirkungen auf die Konversion oder die Pipeline berücksichtigt werden. Zur Klarstellung: Hierbei handelt es sich um ein Beispielmodell, nicht um eine garantierte Rendite.
Rohdaten, die sich für einen Vergleich eignen
Eine Entscheidung für eine Neuentwicklung ist fundierter, wenn sie auf einer Vorher-Nachher-Vergleichsgrundlage basiert. Wir empfehlen, vor Beginn der Arbeiten die folgenden Zahlen zu erfassen:
- Gesamtzahl der indexierbaren URLs und Gesamtzahl der Seiten im CMS.
- Anzahl der CMS-Sammlungen, Sammlungsvorlagen und manuell duplizierter Seitenabschnitte.
- Anzahl der nicht verwendeten CSS-Klassen, veralteten Interaktionen und eingebetteten Custom Codes aus früheren Versionen.
- Seitengröße und JavaScript-Umfang der Startseite und der Seiten mit den höchsten Konversionsraten.
- „Largest Contentful Paint“, „Interaction to Next Paint“ und „Cumulative Layout Shift“ auf Mobilgeräten und Desktop-Computern.
- Median der Zeit, die für die Veröffentlichung einer neuen Landing Page oder die Aktualisierung einer wichtigen Seite benötigt wird.
- Anzahl der Personen, die bauliche Veränderungen sicher vornehmen können.
- Organische Sitzungen, Konversionen und Platzierungen für die 20 umsatzrelevanten URLs mit dem höchsten Umsatz.
Der „2025 Web Almanac“ von HTTP Archive liefert einen nützlichen externen Anhaltspunkt für die Performance. Die mobile Startseite wog im Median 2,56 MB. Die Desktop-Startseite wog im Median 2,86 MB. Bilder machten auf Mobilgeräten 911 KB und auf dem Desktop 1.058 KB aus, JavaScript auf Mobilgeräten 632 KB und auf dem Desktop 697 KB. Aus demselben Datensatz ging hervor, dass 70 % der Desktop-Startseiten unter 1 MB die Core Web Vitals-Bewertung bestanden, verglichen mit 38 % der Seiten mit 5 MB oder mehr.
Die Seitengröße allein ist noch kein Beweis dafür, dass eine Neuentwicklung nötig ist. Eine Seite kann wegen gezielt eingesetzter Videos, Produktvisualisierungen oder Analyseanforderungen groß sein. Die Entscheidung wird erst sinnvoll, wenn große Dateien mit doppelter Struktur, langsamer Bearbeitung und unklaren Zuständigkeiten einhergehen.
Vorschlag für eine Vergleichstabelle
| Kennzahl | Vor der Neuentwicklung | Ziel nach der Neuentwicklung | Warum das wichtig ist |
|---|---|---|---|
| Erstellung einer neuen Landing Page | Ermittle deinen aktuellen Median | Standardseiten noch am selben Tag | Kampagnengeschwindigkeit |
| Gewichtung der Startseite | Auf Mobilgeräten und am Desktop aufzeichnen | Soweit möglich unter dem entsprechenden Branchenmedian | Benutzererfahrung und CWV-Risiko |
| Nicht verwendete CSS-Klassen | Crawlen und zählen | Veraltete Stile entfernen oder dokumentieren | Wartbarkeit |
| CMS-Sammlungen | Aktuelle Struktur erfassen | Eine eindeutige Sammlung pro wiederverwendbarem Inhaltsmodell | Redaktionelle Leitung |
| Entwickler für routinemäßige Änderungen benötigt | Anzahl der benötigten Personen | Null für genehmigte Änderungen an Seitenlayout und Content | Autonomie des Teams |
| Weiterleitungsabdeckung | Prozentualer Anteil zugeordnet | 100 % der geänderten wichtigen URLs | Sicherheit bei der Migration |
Die Zielspalte sollte im Rahmen der Anforderungserfassung abgestimmt werden, anstatt sie einfach blind zu kopieren. Eine komplexe B2B-Website, eine mehrsprachige Plattform oder eine produktorientierte Website kann durchaus mehr Skripte und Vorlagen erfordern als eine kleine Portfolio-Website.
Der Marktkontext von Webflow
W3Techs berichtete im August 2026, dass Webflow von 1,2 % der Websites genutzt wurde, deren Content-Management-System sich identifizieren ließ. Das entspricht 0,8 % aller Websites in ihrem Datensatz. Unter den eine Million meistbesuchten Websites lag der Anteil von Webflow laut einem W3Techs-Vergleich aus dem Jahr 2026 bei 1,6 %.
Diese Zahlen beweisen nicht, dass Webflow schneller, besser oder automatisch wartungsfreundlicher ist als jede andere Alternative. Sie zeigen jedoch, dass Webflow eine ernstzunehmende Plattform mit einem Ökosystem ist, das groß genug ist, um ein gut strukturiertes Projekt an erfahrene Fachkräfte zu übergeben, anstatt weiterhin vom ursprünglichen Entwickler abhängig zu bleiben. Dieser Unterschied ist wichtig für etablierte Unternehmen, die einen Website-Lebenszyklus von drei bis fünf Jahren planen.
Unsere Haltung ist einfach: Die Wahl der Plattform ist zweitrangig gegenüber der Systemqualität. Eine schlecht strukturierte Webflow-Website kann durchaus zu technischer Verschuldung werden. Eine disziplinierte Neuentwicklung sollte daher eine dokumentierte Komponentenarchitektur, vorhersehbare Namenskonventionen, wiederverwendbare Abschnitte, klare Zuständigkeiten für das CMS und einen Übergabeprozess schaffen, der die Rolle der ursprünglichen Agentur im Laufe der Zeit reduziert.
Was wir während der Discovery-Phase messen
Eine glaubwürdige Empfehlung für eine Neuentwicklung sollte auf Fakten beruhen und nicht auf Verkaufsinteressen. Bevor wir einen Scope vorschlagen, prüfen wir normalerweise Folgendes:
Aufbau
- Auf wie vielen Seiten werden einmalig verwendete Abschnitte anstelle von wiederverwendbaren Components eingesetzt?
- Ob die CSS-Klassen einem einheitlichen Framework folgen oder organisch gewachsen sind.
- Wo Combo-CSS-Klassen und Überschreibungen unerwartete Nebeneffekte verursachen.
- Ob sich die Responsive-Regeln in den wichtigsten Vorlagen einheitlich verhalten.
CMS
- Ob Content-Redakteure neue Elemente hinzufügen können, ohne die Layout-Logik zu verändern.
- Ob ähnliche Content-Typen auf mehrere Sammlungen verteilt sind.
- Ob SEO-Felder, Slugs, Bilder, Referenzen und Taxonomien einheitlich modelliert sind.
- Ob die derzeitige Struktur das geplante Wachstum des Contents bewältigen kann.
Integrationen
- Formulare, CRM-Weiterleitung, Analysen, Einwilligungsmanagement, Chat, benutzerdefinierte APIs usw.
- Welche Skripte werden global geladen und welche werden nur auf einzelnen Seiten benötigt?
- Ob der Custom Code dokumentiert und getestet ist und ob er noch benötigt wird.
- Ob die Website über ein sicheres Fallback verfügt, falls sich ein Drittanbieter-Dienst ändert.
SEO und Analytics
- Aktuelle Platzierungen und organische Conversions für kommerzielle URLs.
- Weiterleitungen, Canonical-Tags, das Verhalten der Sitemap, die Indizierbarkeit und strukturierte Daten.
- Qualität der Metadaten auf statischen und CMS-gesteuerten Seiten.
- Ob die Analyse- und CRM-Ereignisse noch den aktuellen Trichter widerspiegeln.
Eine Neuentwicklung ist nur dann erfolgreich, wenn sich diese Kennzahlen verbessern, ohne dass dabei Rankings, Conversion-Pfade oder redaktionelle Kontrolle beeinträchtigt werden.
Neuentwicklung oder Umgestaltung?
Nicht jede problematische Website muss komplett neu aufgebaut werden. Ein Refactoring kann sinnvoll sein, wenn die Kernarchitektur solide ist, das CMS zu den Geschäftsanforderungen passt und sich die Probleme auf eine kleine Anzahl von Vorlagen oder CSS-Klassen konzentrieren. Beim Refactoring kann es darum gehen, nicht verwendete Stile zu entfernen, Components zusammenzufassen, ein paar Skripte zu ersetzen und das bestehende System zu dokumentieren.
Eine Neuentwicklung ist in der Regel sinnvoller, wenn die Probleme miteinander zusammenhängen: Das CMS ist fehlerhaft, Seiten sind doppelt vorhanden, CSS-Klassen sind inkonsistent, die Leistung ist schlecht und das Marketing-Team kann die Website nicht sicher bearbeiten. Wenn ihr nur eine Ebene behebt, ohne die anderen anzugehen, entstehen oft neue Inkonsistenzen.
Unsere Faustregel lautet: Nach einer Refaktorisierung sollte das Team ein System vorfinden, das es getrost weiter ausbauen kann. Wenn die vorgeschlagene Bereinigung zukünftige Entwickler immer noch dazu zwingt, den ursprünglichen Aufbau nachzuvollziehen, reicht sie wahrscheinlich nicht aus.
Beispiele für die Neuentwicklung von Designbase
Bloomwell: Automatisierung als Teil der Neuentwicklung
Bloomwell brauchte nicht nur ein neues Design. Das Unternehmen hatte ein zusammengeflicktes, maßgeschneidertes CMS und mehr als 850 Produkte. Die Verfügbarkeit und die Produktdaten mussten regelmäßig aktualisiert werden. Designbase hat die Website mit 123 wiederverwendbaren Components neu aufgebaut und den Produkt-Feed über n8n angebunden. So entstand ein sich selbst aktualisierendes System, das schätzungsweise mehr als 100 Stunden manuelle Arbeit pro Jahr einspart.
Crewmeister: Abhängigkeiten reduzieren unter dem Druck kostenpflichtiger Akquise
Crewmeister führte ein kostenpflichtiges Akquisitionsprogramm mit mehreren Zielgruppen über eine Website ohne CMS durch. Jede Änderung an der Landing Page und jeder Test der Überschriften erforderte einen Entwickler. Die Kosten für diese Abhängigkeit waren direkt mit den Kampagnenausgaben verbunden. Designbase erstellte 47 modulare, auf Konversion ausgerichtete Components, ermöglichte eine schrittweise Einführung und richtete A/B-Tests mit Webflow Optimize ein.
Das Projekt erzielte Berichten zufolge innerhalb von sechs Monaten eine Steigerung der Konversionsrate um 50 %. Strategie, Design, Entwicklung, Tests und Implementierung dauerten insgesamt 10 Wochen. Das bedeutet zwar nicht, dass jede Neuentwicklung eine Steigerung um 50 % bringt, aber es zeigt, warum das Pflichtenheft für eine Neuentwicklung nicht nur die Technologie, sondern auch das Betriebsmodell und den Testablauf umfassen sollte.
talque: Komplexität ist keine Entschuldigung für ein anfälliges System
Der Relaunch von talque umfasste 88 Seiten in zwei Sprachen und über 65 maßgeschneiderte Illustrationen. Mehrsprachige und mit Content angereicherte Websites decken oft Schwachstellen im System auf, da sich jede Unstimmigkeit über alle Vorlagen und Sprachen hinweg vervielfacht.
Für DACH-Unternehmen ist das besonders interessant. Plant eure Neuentwicklung von Anfang an mit regionalem Content, lokalisierten Metadaten, unterschiedlichen Seitenlängen und der zukünftigen redaktionellen Verantwortung. Baut Deutsch nicht erst nach, wenn die englische Website fertig ist.
Fünf-Minuten-Audit
Beantwortet diese Fragen ehrlich:
- Kann ein Marketingmanager eine Standard-Landing-Page veröffentlichen, ohne dass ein Entwickler nötig ist?
- Kann ein zweiter Webflow-Spezialist das CSS-Klassensystem in weniger als einem Tag verstehen?
- Kann das Team feststellen, zu welcher CMS-Sammlung die einzelnen wiederverwendbaren Content-Typen gehören?
- Könnt ihr erklären, welche benutzerdefinierten Skripte unverzichtbar sind und wer sie pflegt?
- Könnt ihr die Core Web Vitals und die organischen Conversions dieses Monats mit einem Referenzwert vergleichen?
- Kann das Team eine Kampagne starten, ohne zu prüfen, ob dadurch eine Seite, die nichts damit zu tun hat, nicht mehr funktioniert?
- Kann das Unternehmen die ursprünglich beauftragte Agentur ersetzen, ohne dabei das betriebliche Know-how zu verlieren?
Wenn die Antwort auf eine Frage „nein“ lautet, geht der Sache auf den Grund. Wenn die Antwort auf vier oder mehr Fragen „nein“ lautet, hat die Website wahrscheinlich strukturelle Mängel, die ein formelles Audit rechtfertigen.
FAQs
Ihre Website benötigt möglicherweise einen Rebuild, wenn regelmäßige Aktualisierungen zu lange dauern, das CMS nicht mehr zu Ihren Inhalten passt, die Performance kontinuierlich nachlässt oder nur eine Person die Website sicher warten kann. Treten mehrere dieser Anzeichen gleichzeitig auf, deutet das meist auf ein strukturelles Problem und nicht auf einen einzelnen Fehler hin.
Einzelne Workarounds können kurzfristig helfen, führen aber oft zu weiteren doppelten Styles, individuellem Code und zusätzlichem Wartungsaufwand. Mit der Zeit werden Kampagnenstarts langsamer, die Abhängigkeit von Entwicklern steigt und regelmäßige Änderungen können teurer werden als ein Neuaufbau der technischen Grundlage.
Ja. Ein Rebuild kann wiederverwendbare Komponenten, eine skalierbare CMS-Struktur, klarere Inhaltsbeziehungen und Integrationen schaffen, die wachsende Mengen an Seiten, Produkten, Case Studies oder Kampagnen unterstützen. Ziel ist eine Website, die mit Ihrem Unternehmen wächst, ohne dass Sie sie erneut von Grund auf neu aufbauen müssen.
Das sollte nicht der Fall sein, wenn der Rebuild eine vollständige URL-Bestandsaufnahme, ein Redirect-Mapping, die Prüfung von Metadaten, die Kontrolle interner Verlinkungen und ein Monitoring nach dem Go-live umfasst. Wir ordnen alte URLs neuen Zielseiten zu und setzen 301-Weiterleitungen ein, um den SEO-Wert bei URL-Änderungen bestmöglich zu erhalten.
Webflow Rebuilds bei Designbase starten bei 10.000 €, kosten typischerweise zwischen 12.000 € und 22.000 € und dauern vier bis sechs Wochen. Der genaue Umfang hängt unter anderem von der Seitenanzahl, der CMS-Komplexität, den Integrationen, mehrsprachigen Anforderungen, dem SEO-Risiko und individuellen Interaktionen ab.
