← Alle Artikel

5 Fehler bei der Website-Modernisierung

Und genau deshalb sollte eine Modernisierung nicht mit der Frage beginnen:

„Wie soll die neue Website aussehen?“

Sondern mit der Frage:

„Was muss unsere Website in den nächsten Jahren leisten können?“

Denn ein neues Design lässt sich vergleichsweise schnell umsetzen. Eine falsche technische oder strukturelle Entscheidung begleitet ein Unternehmen dagegen möglicherweise über Jahre.

Hier sind fünf Fehler, die wir bei Website-Modernisierungen immer wieder sehen — und wie Sie sie vermeiden.

Fehler 1: Neuer Look statt neues Fundament

Der typische Ausgangspunkt:

„Unsere Website ist von 2018. Wir brauchen ein Redesign.“

Vielleicht.

Aber das Alter einer Website erkennt man nicht nur am Design.

Entscheidender sind Fragen wie:

  • Ist die technische Basis noch aktuell und sicher?
  • Funktioniert die Website auf allen relevanten Geräten?
  • Ist sie schnell genug?
  • Können Redakteure vernünftig damit arbeiten?
  • Sind Inhalte sinnvoll strukturiert?
  • Unterstützt das System strukturierte Daten?
  • Lassen sich neue Funktionen integrieren?
  • Gibt es saubere Schnittstellen zu anderen Systemen?
  • Ist die Plattform für die kommenden Anforderungen geeignet?

Eine ältere Website kann technisch hervorragend aufgestellt sein.

Und eine Website mit brandneuem Design kann auf einer problematischen technischen Basis stehen.

Der bessere Weg

Vor dem Redesign steht deshalb ein Technologie- und Anforderungs-Audit.

  1. Was funktioniert heute gut?
  2. Wo liegen technische oder redaktionelle Grenzen?
  3. Welche Funktionen werden in den kommenden Jahren benötigt?
  4. Welche bestehenden Inhalte und Daten müssen erhalten bleiben?
  5. Kann das aktuelle System diese Anforderungen sinnvoll abbilden?

Erst danach sollte entschieden werden, ob ein Redesign genügt, das bestehende System weiterentwickelt werden kann oder tatsächlich eine neue technische Basis sinnvoll ist.

Modernisierung ist mehr als Kosmetik.

Fehler 2: Die Technologie nach dem Einstiegspreis auswählen

WordPress, TYPO3, Shopify, Webflow, ein SaaS-System oder eine individuelle Entwicklung?

Darauf gibt es keine allgemeingültige Antwort.

WordPress kann für viele Websites eine ausgezeichnete Lösung sein. Shopify ist für zahlreiche Commerce-Projekte genau die richtige Plattform. Und eine Individualentwicklung wäre für eine einfache Unternehmenswebsite häufig unnötig teuer.

Problematisch wird es, wenn die Entscheidung ausschließlich nach dem Einstiegspreis getroffen wird.

„Mit System X bekommen wir die Website für 5.000 Euro weniger.“

Das kann eine gute Entscheidung sein.

Es kann aber auch bedeuten, dass spätere Anforderungen nur noch mit zusätzlichen Plugins, Apps, Workarounds oder individueller Entwicklung umgesetzt werden können.

Nicht nur Projektkosten betrachten

Deshalb sollte nicht nur der Preis bis zum Launch betrachtet werden, sondern die Total Cost of Ownership:

  • Entwicklung bzw. Einrichtung
  • Hosting
  • Wartung und Updates
  • Lizenzen
  • Plugins oder Apps
  • Support
  • Weiterentwicklung
  • Schnittstellen
  • Sicherheitsaufwand
  • mögliche spätere Migrationen

Ein System mit niedrigen Einstiegskosten kann langfristig sehr wirtschaftlich sein.

Ein zunächst teureres System ebenfalls.

Entscheidend ist, welches System zu den tatsächlichen Anforderungen passt.

Nicht der Name des CMS entscheidet über die Wirtschaftlichkeit, sondern die Passung zwischen Plattform, Anforderungen und erwarteter Weiterentwicklung.

Fehler 3: Verantwortlichkeiten sind nicht klar geregelt

Bei größeren Webprojekten arbeiten häufig mehrere Spezialisten zusammen.

Das ist grundsätzlich kein Problem.

Eine Branding-Agentur kann hervorragendes Design liefern, während ein spezialisiertes Entwicklerteam die technische Umsetzung übernimmt.

Problematisch wird es, wenn niemand die Gesamtverantwortung trägt.

Dann entstehen Situationen wie:

„Das ist ein Designproblem.“

„Das muss die Entwicklung lösen.“

„Dafür ist der Hoster zuständig.“

Für den Kunden ist diese Unterscheidung im Ernstfall wenig hilfreich.

Ein zentraler technischer Ansprechpartner

Deshalb sollte klar definiert sein:

  • Wer kennt die Gesamtarchitektur?
  • Wer koordiniert technische Änderungen?
  • Wer ist bei Problemen verantwortlich?
  • Wer dokumentiert Entscheidungen?
  • Wer betreut das System nach dem Launch?

Das muss nicht zwingend eine einzige Agentur sein.

Aber es sollte eine eindeutige technische Verantwortung geben.

Besonders wertvoll ist dabei Kontinuität: Menschen, die eine Website entwickelt haben und ihre Architektur kennen, können spätere Anforderungen meist wesentlich schneller einordnen als ein Dienstleister, der sich zunächst in ein fremdes System einarbeiten muss.

Fehler 4: Redakteure werden zu spät einbezogen

Die Website ist fertig.

Das Design wurde freigegeben.

Die Geschäftsführung ist zufrieden.

Dann bekommt die Redaktion Zugang zum CMS.

Und plötzlich zeigt sich:

„So können wir damit nicht arbeiten.“

Das ist kein Bedienungsproblem der Redaktion.

Es ist ein Planungsfehler.

Die Menschen, die später regelmäßig mit dem System arbeiten, sollten deshalb früh in die Entwicklung einbezogen werden.

Ein gutes CMS passt zu seinen Nutzern

Bereits während der Konzeption sollte geklärt werden:

  • Wer pflegt welche Inhalte?
  • Wie häufig werden Inhalte geändert?
  • Welche technischen Kenntnisse haben die Redakteure?
  • Welche Freiheiten benötigen sie?
  • Welche Fehler sollte das CMS automatisch verhindern?
  • Welche Arbeitsschritte wiederholen sich häufig?

Ein Redakteur sollte nicht verstehen müssen, wie die Website programmiert wurde.

Er sollte verstehen, wie er seinen Inhalt veröffentlicht.

Deshalb gehören reale Redakteure auch in die Testphase — und zwar nicht erst zwei Tage vor dem Launch.

Ein gutes CMS ist nicht das System mit den meisten Funktionen.

Es ist das System, in dem die Menschen, die damit arbeiten, ihre Aufgaben zuverlässig erledigen können.

Fehler 5: Nur die heutigen Anforderungen planen

Eine Website wird heute geplant, aber hoffentlich mehrere Jahre genutzt.

Deshalb reicht die Frage

„Was brauchen wir zum Launch?“

nicht aus.

Ebenso wichtig ist:

„Was könnte in den kommenden Jahren dazukommen?“

Das bedeutet nicht, heute schon jede denkbare Funktion zu entwickeln.

Im Gegenteil.

Eine gute Architektur baut nicht vorsorglich Funktionen, die vielleicht irgendwann benötigt werden.

Sie sorgt dafür, dass spätere Erweiterungen nicht unnötig schwierig werden.

Dazu können beispielsweise gehören:

  • zusätzliche Sprachen
  • neue Geschäftsbereiche
  • E-Commerce
  • Kunden- oder Partnerbereiche
  • externe Datenquellen
  • CRM- oder ERP-Anbindungen
  • Apps
  • APIs
  • strukturierte Daten
  • neue Suchfunktionen
  • KI-gestützte Funktionen
  • zusätzliche maschinenlesbare Ausgaben

Zukunftsfähigkeit bedeutet nicht, die Zukunft vorherzusagen

Niemand weiß heute genau, welche Anforderungen eine Website 2030 erfüllen muss.

Deshalb ist die richtige Strategie nicht:

Alles vorsorglich einbauen.

Sondern:

Abhängigkeiten reduzieren und Erweiterbarkeit ermöglichen.

Dazu gehören eine nachvollziehbare technische Architektur, strukturierte Inhalte, dokumentierte Schnittstellen und ein System, das sich sinnvoll weiterentwickeln lässt.

Was eine zukunftsfähige Website wirklich braucht

Die Anforderungen unterscheiden sich von Projekt zu Projekt.

Einige Grundsätze gelten jedoch fast immer:

  1. Eine technische Basis, die zu den Anforderungen passt
  2. Strukturierte Inhalte statt unkontrollierter Seitensammlungen
  3. Klare Verantwortlichkeiten für Betrieb und Weiterentwicklung
  4. Ein CMS, mit dem die Redaktion tatsächlich arbeiten kann
  5. Saubere Schnittstellen und Erweiterungsmöglichkeiten
  6. Eine nachvollziehbare Update- und Sicherheitsstrategie
  7. Möglichst geringe unnötige Abhängigkeiten

Auch beim Hosting gibt es keine pauschale Antwort.

Für manche Projekte ist Hosting in Deutschland oder der EU aufgrund von Datenschutz-, Compliance- oder Kundenanforderungen wichtig.

Für andere Anwendungen können internationale Cloud-Infrastrukturen sinnvoll sein.

Auch hier gilt:

Die Technologie muss zur Aufgabe passen — nicht umgekehrt.

Kaufen, mieten oder selbst entwickeln?

Auch diese Frage lässt sich nicht pauschal beantworten.

Ein Standardsystem ist sinnvoll, wenn die Anforderungen weitgehend Standard sind.

Eine SaaS-Plattform ist sinnvoll, wenn Geschwindigkeit, vorhandene Funktionen und ein klar definierter Leistungsumfang wichtiger sind als maximale technische Freiheit.

Eine individuelle Lösung wird interessant, wenn Prozesse oder Anforderungen so spezifisch werden, dass ein Standardsystem zunehmend durch Workarounds angepasst werden müsste.

Die beste technische Lösung ist deshalb nicht die mit den meisten Möglichkeiten.

Es ist diejenige, die heute angemessen ist und morgen nicht unnötig im Weg steht.

Und was ist mit KI?

Auch KI-Sichtbarkeit sollte heute bei einer Modernisierung mitgedacht werden.

Aber nicht in Form eines speziellen „KI-CMS“.

Die Grundlagen sind erstaunlich unspektakulär:

  • öffentlich erreichbare Inhalte
  • semantisch sauberes HTML
  • klare Informationsarchitektur
  • eindeutige Aussagen über Unternehmen und Leistungen
  • strukturierte Daten wie Schema.org
  • kontrollierbare Crawler-Regeln
  • zitierfähige Fachinhalte

Das sind keine exotischen KI-Funktionen.

Es sind Merkmale einer technisch und inhaltlich gut gebauten Website.

Und genau das macht sie wertvoll: Was Maschinen hilft, Informationen eindeutig zu verstehen, verbessert häufig auch Struktur, Wartbarkeit und Qualität für Menschen.

Fazit: Erst Anforderungen, dann Technologie, dann Design

Eine Website-Modernisierung ist mehr als eine Renovierung.

Sie ist eine Gelegenheit, die eigene digitale Infrastruktur zu überprüfen.

Nicht jede ältere Website muss ersetzt werden.

Nicht jedes WordPress-Projekt ist falsch.

Nicht jede individuelle Entwicklung ist besser.

Und nicht jede neue Technologie ist automatisch zukunftsfähig.

Die entscheidenden Fragen sind:

Was muss die Website heute leisten?

Was soll sie morgen ermöglichen?

Und welche technische Basis erreicht das mit möglichst wenig unnötiger Komplexität?

Wenn diese Fragen beantwortet sind, wird auch die Entscheidung über CMS, Plattform, Architektur und Design wesentlich einfacher.

Lassen Sie uns Ihre Technologie-Anforderungen besprechen

Lassen Sie uns Ihre Technologie-Anforderungen besprechen

← Alle Artikel

Kontakt

Projekt besprechen

Schreiben Sie uns kurz — wir melden uns zeitnah.

* Pflichtfelder