Typische Fehler bei der Website-Planung und wie man sie vermeidet

Ich habe in den letzten Jahren dutzende Website-Projekte begleitet. Manche liefen sauber durch. Viele nicht. Und fast immer lagen die Probleme nicht in der Umsetzung, sondern in der Planung. Bevor eine einzige Zeile Code geschrieben wurde, waren die Weichen schon falsch gestellt.

Das Frustrierende daran: Die meisten dieser Fehler sind vermeidbar. Sie passieren nicht aus Unwissenheit, sondern aus falschen Prioritäten, unklaren Zuständigkeiten oder schlicht weil niemand die unbequemen Fragen stellt. Hier sind zehn Fehler, die mir immer wieder begegnen — und was man konkret dagegen tun kann.

Der klassischste aller Fehler. Ein Unternehmen beschließt, seine Website neu zu machen. Der erste Schritt? Jemand öffnet Figma oder schickt eine Anfrage an eine Designagentur. Farben werden diskutiert, Layouts entworfen, Animationen geplant. Das fühlt sich produktiv an. Ist es aber nicht.

Ich habe das bei einem mittelständischen Maschinenbauer erlebt. Drei Monate Designarbeit, wunderschöne Screens, das Management war begeistert. Dann kam die Frage: Welche Inhalte kommen auf die Seite? Welche Zielgruppe sprechen wir an? Was soll ein Besucher tun, wenn er auf der Seite landet? Stille. Niemand hatte sich damit beschäftigt. Das Design wurde komplett überarbeitet, weil es auf Annahmen basierte, die niemand validiert hatte.

Strategie kommt vor Design. Immer. Das bedeutet: Zuerst die Fragen beantworten, die wehtun. Wer sind unsere Nutzer? Was wollen die auf unserer Seite? Welche Geschäftsziele verfolgen wir? Erst wenn das klar ist, macht Design Sinn. Sonst malt man hübsche Bilder ohne Fundament.

Eng verwandt mit dem ersten Fehler, aber nochmal eine eigene Kategorie. Die Website wird geplant, designed, entwickelt — und dann heißt es: „Jetzt brauchen wir noch die Texte.“ Noch. Als wäre Content ein Anhängsel. Ein Pflichtfeld, das man kurz vor Launch ausfüllt.

Bei einem SaaS-Unternehmen, mit dem wir zusammengearbeitet haben, war die technische Umsetzung fertig. Next.js-Frontend, Sanity als CMS, alles sauber aufgesetzt. Dann sollte das Marketing die Inhalte liefern. Sechs Wochen Verzögerung. Nicht weil das Team faul war, sondern weil niemand definiert hatte, welche Inhalte überhaupt nötig sind, wer sie erstellt und in welchem Format sie ins CMS müssen.

Content muss von Anfang an Teil des Projekts sein. Das heißt: Content-Audit zu Beginn, klare Verantwortlichkeiten für die Erstellung, und ein Content-Plan, der parallel zur Entwicklung läuft. Wer Content als letzten Schritt behandelt, verschiebt den Launch um Wochen oder geht mit halbfertigen Texten live. Beides schlecht.

„Wir brauchen eine neue Website.“ Warum? „Na, die alte sieht nicht mehr gut aus.“ Das ist kein Ziel. Das ist ein Gefühl. Und Gefühle sind eine schlechte Grundlage für ein Projekt, das leicht sechsstellig kosten kann.

Ohne messbare Ziele kann man nach dem Launch nicht sagen, ob das Projekt erfolgreich war. War die alte Seite schlecht, weil sie zu wenig Leads generiert hat? Weil die Absprungrate zu hoch war? Weil der Vertrieb kein vernünftiges Material zum Verschicken hatte? Jeder dieser Gründe führt zu einer anderen Website.

Ein Industriezulieferer wollte „mehr Sichtbarkeit“. Gut, aber was heißt das konkret? Nach einigem Nachbohren kamen die echten Ziele heraus: 30 Prozent mehr qualifizierte Anfragen über das Kontaktformular innerhalb von sechs Monaten nach Launch. Das ist ein Ziel, mit dem man arbeiten kann. Daraus ergibt sich die Seitenstruktur, die Call-to-Actions, das Tracking-Setup.

Definiert vor Projektstart zwei bis drei KPIs, die ihr nach dem Launch messen wollt. Conversion Rate, Verweildauer, Anfragen über bestimmte Formulare — was auch immer für euer Geschäft relevant ist. Baut die Website dann so, dass sie genau diese Ziele unterstützt.

„Wir nehmen WordPress, das kennt jeder.“ Diesen Satz höre ich regelmäßig. Und er ist der Anfang vieler Probleme. WordPress ist nicht per se schlecht. Aber es ist auch nicht per se die richtige Wahl. Schon gar nicht für B2B-Unternehmen mit komplexen Anforderungen.

Ein Handelsunternehmen hatte sich für WordPress mit einem Page Builder entschieden. Weil der Marketingmanager das von seinem vorherigen Job kannte. Zwei Jahre später: 47 Plugins installiert, die Seite lädt in über vier Sekunden, Sicherheitsupdates werden regelmäßig ignoriert, und der Page Builder erzeugt HTML, das kein Entwickler ohne Migräne anschauen kann. Die Entscheidung fiel nicht auf Basis der Anforderungen, sondern auf Basis von Gewohnheit.

Die CMS-Wahl sollte sich an konkreten Kriterien orientieren: Wie viele Redakteure arbeiten mit dem System? Braucht ihr strukturierte Inhalte für mehrere Kanäle? Soll die Website mit anderen Systemen wie einem PIM oder ERP integriert werden? Wie wichtig ist Performance? Für viele B2B-Szenarien im Mittelstand sind Headless-CMS-Lösungen wie Sanity oder Payload CMS die bessere Wahl. Nicht weil sie moderner klingen, sondern weil sie strukturierte Inhalte sauber verwalten und sich nahtlos in moderne Frontends mit Next.js oder ähnlichen Frameworks integrieren lassen.

Und ja, das bedeutet oft mehr Initialaufwand. Aber der zahlt sich aus, wenn man nicht nach zwei Jahren von vorne anfangen muss.

Eine Website ist kein Buch. Sie ist fertig geschrieben, gedruckt, erledigt? So denken viele. Aber eine Website ist eher wie ein Auto: Sie braucht regelmäßige Wartung, sonst bleibt sie irgendwann stehen.

Sicherheitsupdates, CMS-Updates, Hosting-Kosten, SSL-Zertifikate, Monitoring, Content-Pflege, Performance-Optimierung — das alles kostet Geld und Zeit. Und es wird in der Budgetplanung fast immer vergessen. Ein Kunde hatte ein Budget von 80.000 Euro für den Relaunch eingeplant. Für die laufenden Kosten danach: null. Nach einem Jahr war die Seite technisch veraltet, weil niemand die Updates eingespielt hatte.

Plant von Anfang an ein monatliches Budget für Wartung ein. Je nach Komplexität der Seite sind das zwischen 500 und 2.000 Euro im Monat. Das klingt nach viel, ist aber deutlich günstiger als alle drei Jahre einen kompletten Relaunch zu machen, weil die Seite nicht gepflegt wurde. Wer auf moderne Infrastruktur setzt — etwa Docker-Container auf Hetzner mit Coolify für Deployment — reduziert den manuellen Wartungsaufwand erheblich. Automatisierte Deployments und Infrastructure-as-Code machen Updates planbar statt chaotisch.

„Unsere Kunden sitzen am Schreibtisch, die nutzen Desktop.“ Das mag vor zehn Jahren gestimmt haben. Heute nicht mehr. Selbst im B2B-Bereich kommen je nach Branche 40 bis 60 Prozent des Traffics von mobilen Geräten. CTOs lesen morgens im Zug auf dem Tablet. Produktmanager checken abends auf dem Handy eine Anbieterseite. Einkäufer vergleichen auf dem Smartphone.

Ein Softwareunternehmen hatte eine aufwendige Desktop-Seite mit interaktiven Produktvergleichen, komplexen Tabellen und eingebetteten Demos. Auf dem Handy? Unbenutzbar. Die Tabellen liefen aus dem Viewport, die Demos luden nicht, und der Hauptnavigationspunkt war hinter einem Hamburger-Menü versteckt, das auf iOS nicht richtig funktionierte. Google hat die Seite in den mobilen Suchergebnissen entsprechend abgestraft.

Mobile-first ist kein Buzzword, sondern eine Entwicklungsstrategie. Das bedeutet: Zuerst für den kleinsten Bildschirm designen und entwickeln, dann nach oben skalieren. Mit Tailwind CSS ist das technisch trivial — die Utility-Klassen sind von Haus aus mobile-first aufgebaut. Die Herausforderung liegt im Denken, nicht in der Technik. Fragt euch bei jedem Element: Funktioniert das auf einem 375 Pixel breiten Screen?

Barrierefreiheit ist kein Nice-to-have. Seit dem Barrierefreiheitsstärkungsgesetz, das ab Juni 2025 gilt, ist sie für viele Unternehmen Pflicht. Aber selbst wenn es keine gesetzliche Verpflichtung gäbe: Es ist schlicht gutes Handwerk, eine Website so zu bauen, dass sie für alle Menschen nutzbar ist.

Ein Finanzdienstleister hatte eine neue Website gelauncht — optisch ansprechend, technisch solide. Dann meldete sich ein Großkunde, dessen Procurement-Abteilung einen Screenreader nutzte. Die Seite war nicht navigierbar. Keine Alt-Texte bei Bildern, keine semantischen HTML-Elemente, Formulare ohne Labels. Der Großkunde stellte ein Ultimatum: Entweder die Seite wird zugänglich, oder er wechselt den Anbieter. Drei Wochen Notfall-Sprint, um die grundlegendsten Accessibility-Features nachzurüsten.

Barrierefreiheit muss von Anfang an mitgedacht werden. Das beginnt bei der Farbwahl im Design — ausreichende Kontraste sind kein ästhetisches Detail, sondern eine Notwendigkeit. Es geht weiter bei semantischem HTML: Überschriftenhierarchien, ARIA-Labels, Fokus-Management für Tastaturnavigation. Und es endet bei regelmäßigen Audits mit Tools wie axe oder Lighthouse. Wer das von Anfang an macht, hat kaum Mehraufwand. Wer es nachträglich einbaut, zahlt doppelt.

Ein Website-Projekt betrifft viele Abteilungen. Marketing will die Marke stärken. Vertrieb will Leads. IT will Sicherheit und Wartbarkeit. HR will eine Karriereseite. Die Geschäftsführung will, dass es nicht zu viel kostet. Und der Betriebsrat will informiert werden. Das ist verständlich. Problematisch wird es, wenn alle gleichberechtigt mitreden und niemand entscheidet.

Bei einem mittelständischen Logistikunternehmen saßen in den Abstimmungsterminen regelmäßig zwölf Leute. Jeder hatte eine Meinung. Keiner hatte das Mandat, Entscheidungen zu treffen. Das Ergebnis: endlose Feedbackschleifen, widersprüchliche Anforderungen und ein Projekt, das statt sechs Monate vierzehn Monate dauerte. Das Budget war am Ende fast doppelt so hoch wie geplant.

Definiert vor Projektstart ein klares Governance-Modell. Wer ist Product Owner und hat die finale Entscheidungsgewalt? Wer liefert Input, hat aber kein Vetorecht? Wer wird informiert, sitzt aber nicht am Tisch? Das RACI-Modell hilft hier enorm: Für jede Entscheidung ist klar, wer verantwortlich ist, wer rechenschaftspflichtig ist, wer konsultiert wird und wer informiert wird. Klingt bürokratisch, spart aber Wochen.

Der Launch-Termin steht. Die Deadline drückt. Also wird am Ende alles, was nicht unbedingt nötig ist, gestrichen. Testing gehört leider oft dazu. „Das testen wir nach dem Launch.“ Spoiler: Das passiert dann meistens nicht. Und wenn doch, finden die Nutzer die Bugs vor dem Testteam.

Ein E-Commerce-naher B2B-Händler ging mit seinem neuen Produktkonfigurator live. Ohne ausgiebige Tests. Am ersten Tag stellte sich heraus: Wenn ein Kunde mehr als zehn Positionen konfigurierte, stürzte das Tool ab. Der Safari-Browser auf älteren iPads zeigte die Preise nicht an. Und das Kontaktformular schickte bei bestimmten Sonderzeichen im Firmennamen eine Fehlermeldung. Der erste Eindruck bei den Kunden war verheerend.

Testing ist kein Luxus, den man sich bei großzügigem Budget leistet. Es ist Pflicht. Dazu gehören funktionale Tests aller Formulare und interaktiven Elemente. Cross-Browser-Testing auf den relevanten Browsern und Geräten. Performance-Tests unter Last. Und — oft vergessen — Content-Review: Stimmen alle Links? Sind die Texte fehlerfrei? Zeigen die Bilder das Richtige? Plant mindestens zwei Wochen vor dem Launch für dediziertes Testing ein. Nutzt Staging-Umgebungen, die identisch zur Produktivumgebung sind. Und lasst echte Nutzer testen, nicht nur das Projektteam.

Das ist vielleicht der teuerste Fehler von allen. Eine Website wird wie ein Bauprojekt behandelt: Planen, bauen, fertig. Dann wird die Agentur verabschiedet, das interne Team kümmert sich um andere Dinge, und die Website steht drei Jahre lang unverändert da. Bis jemand sagt: „Die sieht ja schon wieder alt aus.“ Und der Zyklus beginnt von vorne.

Ein Technologieunternehmen hatte 2022 eine aufwendige Website gelauncht. Großes Projekt, sechs Monate Laufzeit, stolzes Budget. Danach passierte nichts mehr. Keine neuen Inhalte, keine technischen Updates, kein Monitoring. Als sie uns 2024 kontaktierten, war die Seite technisch auf dem Stand von zwei Jahren zuvor. Die Node.js-Version war veraltet, mehrere npm-Packages hatten bekannte Sicherheitslücken, und die Ladezeiten hatten sich durch fehlende Optimierung verdoppelt. Der „günstige“ Ansatz, nach dem Launch nichts mehr zu investieren, hatte eine komplette Neuentwicklung nötig gemacht.

Eine Website ist ein lebendiges Produkt. Sie muss kontinuierlich gepflegt, optimiert und weiterentwickelt werden. Das bedeutet nicht, dass man jeden Monat tausende Euro investieren muss. Aber ein festes Kontingent für technische Wartung, Content-Updates und datengetriebene Optimierungen ist essentiell. Schaut euch die Analytics-Daten an. Was funktioniert? Was nicht? Wo springen Nutzer ab? Welche Seiten konvertieren gut, welche schlecht? Eine Website, die auf Daten basiert statt auf Bauchgefühl, wird über die Zeit immer besser.

Wenn man sich die zehn Fehler anschaut, fällt ein Muster auf: Fast alle entstehen, weil Unternehmen eine Website als Designprojekt statt als Geschäftsprojekt betrachten. Sie denken in Pixeln statt in Prozessen. In Layouts statt in Nutzerreisen. In Features statt in Ergebnissen.

Die Unternehmen, mit denen wir die besten Projekte gemacht haben, hatten eines gemeinsam: Sie haben die Website als strategisches Werkzeug verstanden. Nicht als digitale Visitenkarte, nicht als „das muss man halt haben“, sondern als zentralen Touchpoint in ihrer Customer Journey. Diese Unternehmen investieren in Strategie, bevor sie in Pixel investieren. Sie definieren Verantwortlichkeiten, bevor sie Meetings einberufen. Und sie planen für die Zeit nach dem Launch, bevor der erste Sprint beginnt.

Gute Website-Projekte beginnen mit einem Workshop, nicht mit einem Briefing. In diesem Workshop werden die echten Geschäftsziele herausgearbeitet, die Zielgruppen definiert und die technischen Anforderungen geklärt. Welche Systeme müssen angebunden werden? Welche Daten fließen wohin? Wie sieht die Redaktionsarbeit im Alltag aus? Erst danach geht es an Wireframes — nicht an Designs, sondern an strukturelle Konzepte, die zeigen, wie Inhalte organisiert sind und wie Nutzer durch die Seite geführt werden.

Schlechte Projekte beginnen mit „Mach mal ein paar Entwürfe“. Der Unterschied in der Qualität des Ergebnisses ist enorm. Und der Unterschied in den Kosten auch — aber andersherum, als man denken würde. Die durchdachten Projekte sind am Ende fast immer günstiger, weil weniger Iterationsschleifen, weniger Nacharbeit und weniger böse Überraschungen anfallen.

Ein Punkt, der mir besonders am Herzen liegt: Die Wahl der Technologie ist keine rein technische Entscheidung. Sie hat direkte Auswirkungen auf Geschwindigkeit, Sicherheit, Wartbarkeit und langfristige Kosten. Wer sich für ein monolithisches CMS wie TYPO3 oder Sitecore entscheidet, kauft sich eine bestimmte Art von Abhängigkeit ein. Wer auf einen Headless-Ansatz mit Next.js und einem modernen CMS setzt, gewinnt Flexibilität — muss aber initial mehr in die Architektur investieren.

Für B2B-Unternehmen im Mittelstand empfehle ich fast immer einen Headless-Ansatz. Nicht aus technologischer Eitelkeit, sondern aus praktischen Gründen: Strukturierte Inhalte lassen sich über APIs für verschiedene Kanäle nutzen — Website, App, Kundenportal. Das Frontend kann unabhängig vom CMS aktualisiert werden. Und die Performance ist in der Regel deutlich besser als bei klassischen CMS-Lösungen, weil moderne Frameworks wie Next.js statische Generierung und serverseitiges Rendering kombinieren können.

Dazu kommt das Thema Hosting und Deployment. Wer seine Website auf einem klassischen Shared-Hosting-Paket betreibt, hat wenig Kontrolle über Performance und Skalierbarkeit. Mit Docker-Containern auf Hetzner-Servern und einer Deployment-Plattform wie Coolify bekommt man die Kontrolle zurück — zu einem Bruchteil der Kosten von AWS oder Azure. Das erfordert initial etwas mehr Setup, aber die laufenden Kosten sind niedriger und die Unabhängigkeit von großen Cloud-Anbietern größer.

Viele der genannten Fehler ließen sich durch Automatisierung entschärfen. Kein Testing? Automatisierte Tests fangen die schlimmsten Bugs ab, bevor sie live gehen. Vergessene Updates? CI/CD-Pipelines können Dependency-Updates automatisch testen und deployen. Content-Probleme? Workflows in Tools wie n8n können Redakteure automatisch erinnern, wenn Inhalte seit drei Monaten nicht aktualisiert wurden.

Das kostet initial Zeit und Geld. Aber es reduziert den manuellen Aufwand langfristig massiv und verhindert die schleichende Vernachlässigung, die so viele Websites nach dem Launch erleben.

Die beste Website ist nicht die mit dem schönsten Design oder der meisten Funktionalität. Es ist die, die auf einer soliden Strategie aufbaut, von Anfang an richtig geplant wurde und auch nach dem Launch kontinuierlich gepflegt wird. Das klingt unspektakulär. Ist es auch. Aber genau das macht den Unterschied zwischen einer Website, die Ergebnisse liefert, und einer, die nach zwei Jahren wieder abgerissen wird.

Wenn ihr gerade ein Website-Projekt plant: Nehmt euch die Zeit für die Planung. Stellt die unbequemen Fragen am Anfang, nicht am Ende. Und behandelt eure Website als das, was sie ist — ein zentrales Geschäftswerkzeug, das Aufmerksamkeit verdient. Nicht nur beim Launch, sondern jeden Tag danach.