Ich bekomme regelmäßig Anfragen, die so beginnen: "Wir brauchen eine neue Website." Und fast immer stellt sich im ersten Gespräch heraus, dass das eigentliche Problem ein anderes ist. Die Leadgenerierung funktioniert nicht. Der Vertrieb weiß nicht, was Marketing gerade macht. Inhalte werden produziert, aber nirgendwo systematisch ausgespielt. Die Website ist dabei oft Symptom, nicht Ursache – und eine neue Oberfläche löst das strukturelle Problem nicht.
Digitale Infrastruktur denkt in Systemen
Eine Website ist kein isoliertes Artefakt. Sie ist ein Knotenpunkt in einem größeren System – und wer sie plant, ohne dieses System zu kennen, baut auf Sand. Das gilt für ein Startup genauso wie für ein Mittelstandsunternehmen mit 200 Mitarbeitern. Die Fragen, die vor dem ersten Wireframe beantwortet sein müssen, sind keine Design-Fragen: Welche Daten fließen wohin? Was passiert, wenn jemand ein Formular ausfüllt? Wer bekommt welche Information, wann und in welchem Format?
Ein konkretes Beispiel: Ein B2B-Unternehmen betreibt HubSpot als CRM, nutzt aber eine WordPress-Installation, die keinerlei strukturierte Daten ausgibt. Kontaktformulare landen per E-Mail beim Vertrieb, der sie manuell einpflegt. Das kostet Zeit, erzeugt Fehler und macht systematisches Lead-Scoring unmöglich. Die neue Website kann dieses Problem lösen – aber nur, wenn sie von Anfang an als Teil des CRM-Prozesses gedacht wird, nicht als Broschüre mit Kontaktformular.
Der Stack ist keine technische Entscheidung – er ist eine strategische
Wenn ich heute eine digitale Infrastruktur für ein Unternehmen aufbaue, lande ich fast immer bei einer Kombination aus Next.js als Frontend, Sanity als Headless CMS, Supabase für strukturierte Daten und Auth, n8n für Automatisierungen und Hetzner mit Coolify für das Hosting. Das ist keine religiöse Überzeugung, sondern eine pragmatische: Diese Kombination ist wartbar, skalierbar und lässt sich ohne Vendor-Lock-in zusammenbauen.
Was diese Kombination vor allem ermöglicht: Die Website ist nicht mehr der Ort, an dem Inhalte leben, sondern der Ort, an dem sie ausgespielt werden. Inhalte werden in Sanity gepflegt und können gleichzeitig auf der Website, in einem Newsletter, in einer App oder in einem internen Dashboard erscheinen. n8n verbindet Formular-Submissions mit dem CRM, triggert Slack-Benachrichtigungen, schickt Bestätigungs-E-Mails und erstellt Aufgaben im Projektmanagement-Tool – alles ohne zusätzliche SaaS-Abonnements für jeden einzelnen Use Case.
Warum isolierte WordPress-Installationen das falsche Fundament sind
WordPress ist nicht per se das Problem. Das Problem ist die isolierte Installation: ein Monolith, der Content, Darstellung, Authentifizierung und Geschäftslogik in einem System bündelt, das für genau dieses Zusammenwachsen nicht gebaut wurde. Wer heute eine API-First-Architektur aufbaut, hat morgen die Möglichkeit, Inhalte an beliebige Kanäle zu liefern. Wer heute einen WordPress-Monolithen aufbaut, zahlt in zwei Jahren für die Migration – oder bleibt in einem System gefangen, das mit den Anforderungen des Unternehmens nicht mitwächst.
Content-Distribution ist kein Nachgedanke
Ein häufig unterschätzter Aspekt der Gesamtstrategie ist die Frage, wie Inhalte verteilt werden. Viele Unternehmen betreiben einen Blog, der im Prinzip gut ist, aber kaum gelesen wird – weil er auf der Website existiert und nirgendwo sonst. Eine durchdachte Content-Strategie denkt von Anfang an in Kanälen: Welche Inhalte eignen sich für LinkedIn? Was wird als Newsletter ausgespielt? Welche Teile landen in einem Kundenportal?
Sanity eignet sich hier sehr gut als zentrale Content-Plattform, weil die Inhalte strukturiert vorliegen und über die Content Lake API flexibel abgerufen werden können. Ein Blogpost kann automatisch als Newsletter-Entwurf in ein E-Mail-Tool übertragen werden. Ein Produktupdate wird sowohl auf der Website als auch in einem internen Changelog ausgespielt. Diese Verknüpfungen herzustellen ist technisch nicht schwer – aber sie müssen von Anfang an mitgeplant werden.
Was strategische Website-Planung konkret bedeutet
Bevor ein einziger Pixel gesetzt wird, sollten folgende Fragen beantwortet sein: Welche Systeme existieren bereits – CRM, ERP, Newsletter-Tool, Projektmanagement? Welche Daten müssen zwischen diesen Systemen fließen? Wer sind die tatsächlichen Nutzer der Website, und was sollen sie dort tun? Welche Inhalte werden wie oft aktualisiert, und wer ist dafür verantwortlich?
Die Antworten auf diese Fragen definieren die Architektur – nicht umgekehrt. Ein Unternehmen, das täglich neuen Content produziert und an drei Kanäle ausliefert, braucht eine andere Infrastruktur als ein Unternehmen, das einen statischen Produktkatalog pflegt und Anfragen per Telefon abwickelt. Beide Lösungen können mit demselben Stack gebaut werden. Aber sie sehen sehr unterschiedlich aus – und das ist auch richtig so.
Was ich in der Praxis immer wieder sehe: Unternehmen, die diesen Prozess überspringen, zahlen später dafür – in Form von teuren Nacharbeiten, manuellen Prozessen, die niemand dokumentiert hat, und Systemen, die nicht miteinander reden. Eine Website ist kein Endprodukt. Sie ist der sichtbare Teil einer digitalen Infrastruktur, die im Hintergrund die eigentliche Arbeit erledigt.
