Skip to content
· 6 Min. Lesezeit

Wie webvise Websites baut: Der Prozess von der Anfrage bis zum Launch

Was passiert zwischen "wir brauchen eine neue Website" und einer Live-Seite, die liefert? Der webvise-Prozess, Schritt für Schritt: keine vagen Agenturversprechen, sondern konkret, was und warum.

Web DevelopmentProcessCase Study
Teilen

Einer der häufigsten Frustrationspunkte von Unternehmern im Umgang mit Webagenturen ist die Black Box. Sie übergeben ein Briefing, im Hintergrund passiert etwas, und irgendwann erscheint ein Ergebnis. Manchmal ist es das, was gefragt war. Oft nicht.

Transparenz ist hier ein echter Wettbewerbsvorteil, für beide Seiten. Wer den Prozess versteht, bevor das Projekt startet, hat klare Erwartungen, braucht weniger Korrekturschleifen, und das Ergebnis ist besser. Deshalb: genau so läuft es ab.

Phase 1: Discovery (Woche 1)

Jedes Projekt beginnt mit einer strukturierten Discovery-Session. Kein vages "Erzählen Sie mir von Ihrer Marke", sondern ein konkreter Fragenkatalog, der die Entscheidungen herausarbeitet, die den gesamten Build prägen:

  • Für wen ist die Seite? Welche konkreten Kundentypen müssen überzeugt werden?
  • Welche Aktion sollen Besucher ausführen, und in welcher Reihenfolge?
  • Was funktioniert an der aktuellen Seite gut und muss erhalten bleiben?
  • Welches eine Geschäftsproblem soll die neue Seite vor allem lösen?
  • Wie sieht Erfolg in Zahlen aus, 6 Monate nach dem Launch?

Parallel dazu läuft ein technisches Audit der bestehenden Seite: Performance-Scores, SEO-Baseline, Analytics-Auswertung, Content-Inventar. Das zeigt, was das Projekt vorfindet und wo die größten Hebel liegen.

Ergebnis: ein Discovery-Dokument, das Umfang, Erfolgskennzahlen und die inhaltliche Kernstrategie der neuen Seite definiert. Sie prüfen und geben frei, bevor eine einzige Zeile Code geschrieben wird.

Phase 2: Architektur und Design (Wochen 2-3)

Vor dem Design steht die Informationsarchitektur: welche Seiten existieren, wie sie verbunden sind, wie die User Journey auf jeder Stufe aussieht. Die meisten Agenturen überspringen diesen Schritt. Hier passiert das nicht, denn ein ansprechendes Design auf einer schlecht strukturierten Seite ist immer noch eine schlecht performende Seite.

Design beginnt mit Wireframes, also strukturellen Layouts ohne visuelles Styling. Das hält die Reviews fokussiert: Macht diese Inhaltshierarchie Sinn? Nicht: Gefällt mir dieser Blauton? Erst wenn die Struktur freigegeben ist, kommt das Brand-System zum Einsatz.

Die Designarbeit findet in Figma statt. Sie können direkt in Echtzeit auf den Designs kommentieren. Kein Hin- und Herschicken von Screenshots per E-Mail. Feedback-Schleifen sind kurz.

Ebenfalls in dieser Phase entsteht die Component Library: die wiederverwendbaren Bausteine (Hero-Sections, Card-Grids, Testimonial-Layouts, CTAs), aus denen jede Seite aufgebaut ist. Spätere Content-Anpassungen werden dadurch schneller, visuelle Konsistenz ergibt sich automatisch.

Phase 3: Development (Wochen 3-6)

Gebaut wird auf Next.js mit einem headless CMS (in der Regel Sanity). Das ist eine bewusste technische Entscheidung mit konkreten geschäftlichen Konsequenzen:

  • Performance: Seiten werden vorgerendert und über ein globales CDN ausgeliefert. Ladezeiten liegen typischerweise unter einer Sekunde. Google honoriert das direkt im Ranking.
  • Sicherheit: Kein öffentlich zugängliches Admin-Panel, keine Plugin-Schwachstellen, keine PHP-Ausführung. Die Angriffsfläche eines dynamischen CMS mit Plugin-Ökosystem existiert in diesem Build nicht.
  • Wartbarkeit: Die Codebasis ist sauber, dokumentiert und auf Langlebigkeit ausgelegt. Keine verschachtelten Theme-Code-Pfade, keine Plugin-Kompatibilitätsfragen. Entwickler, die in zwei Jahren hinzukommen, können sie lesen und anpassen.
  • Redaktionelle Erfahrung: Inhalte werden im strukturierten Editor von Sanity gepflegt. Das ist schneller und vorhersehbarer als der Block-Editor von WordPress, und Inhalte lassen sich seitenübergreifend wiederverwenden.

Die Entwicklung verläuft in zwei Phasen: zuerst die Kernarchitektur (CMS-Schema, Seitenvorlagen, Component Library im Code), dann die Content-Integration (Vorlagen mit echten Inhalten befüllen, seitenspezifische Layouts bauen, QA über alle Geräte und Browser).

Ab Woche 3 steht eine Staging-Umgebung zur Verfügung. Das ist eine live und funktionale Vorschau der Seite auf jedem Entwicklungsstand, kein statischer Screenshot oder Mockup. Sie können durchklicken, Formulare testen und auf dem Smartphone prüfen, bevor irgendetwas live geht.

Phase 4: Content und Copy (Wochen 4-5, parallel)

Content ist im Website-Build oft der zeitkritischste Faktor. Je nach Projektumfang gibt es zwei Wege:

Kundenseitig gelieferter Content: Für jede Seite gibt es ein detailliertes Content-Briefing: was genau zu schreiben ist, in welchem Umfang und in welchem Format. Dieses Briefing entsteht aus der Discovery-Session und basiert auf Keyword-Recherche und Wettbewerbsanalyse. Sie schreiben; strukturiert und webgerecht wird es hier aufbereitet.

Von webvise geschriebener Content: Ist Copywriting Teil des Projektumfangs, werden zentrale Stakeholder befragt, bestehendes Vertriebsmaterial gesichtet und Seitentexte verfasst, die auf Suche und Conversion ausgelegt sind. Texte, die sowohl SEO-Intention als auch Überzeugungsstrategie vereinen, performen deutlich besser als generischer KI-Output oder Template-Content.

Content-Entwicklung läuft parallel zur technischen Entwicklung: Das CMS wird befüllt, während die Templates entstehen. So bleibt der Zeitplan eng.

Phase 5: QA und Launch-Vorbereitung (Woche 6)

Bevor etwas ausgeliefert wird, durchläuft die Seite eine systematische Qualitätsprüfung:

  • Performance-Audit: Zielwerte PageSpeed 90+ auf Mobile und Desktop, soweit Content-Gewicht und Drittanbieter-Skripte das erlauben.
  • Cross-Browser- und Cross-Device-Testing (Chrome, Firefox, Safari, Edge; iPhone, Android, Tablet, Desktop)
  • Alle Formulare end-to-end getestet: Absenden, Bestätigung und E-Mail-Zustellung
  • SEO-Checkliste: Title Tags, Meta Descriptions, Canonical URLs, Sitemap, robots.txt, strukturierte Daten
  • Analytics verifiziert: GA4, Search Console, Conversion-Ziel-Tracking alles aktiv
  • Content korrekturgelesen: Headlines, Fließtext, CTAs, rechtliche Seiten, alle Sprachversionen bei mehrsprachigen Projekten
  • Redirect-Map: Jede relevante alte URL leitet auf die korrekte neue URL weiter

Nichts geht live, ohne diese Checkliste zu bestehen. Zu viele Seiten gehen mit defekten Formularen, fehlendem Tracking oder ohne Redirects live: alles Probleme, die das Unternehmen von Tag eins an still Geld kosten.

Phase 6: Launch und Übergabe (Ende Woche 6)

Der Launch-Termin liegt in einem Zeitfenster mit geringem Traffic. Die Seite wird die ersten 24 Stunden überwacht, ein Rollback-Plan steht bereit. Dieser Plan ist bisher in keinem Produktivbetrieb zum Einsatz gekommen, aber er ist immer da.

Nach dem Launch erhalten Sie:

  • Eine aufgezeichnete Walkthrough-Session, wie das CMS für Content-Updates genutzt wird
  • Dokumentation der Component Library (was existiert und wie es eingesetzt wird)
  • Die vollständige Design-Datei in Figma
  • Zugang zu allen Accounts: Hosting, Analytics, Search Console, CMS
  • Ein 30-tägiges Post-Launch-Supportfenster für Probleme, die im Produktivbetrieb auftauchen

Was nach dem Launch passiert

Die meisten Kunden führen die Zusammenarbeit auf zwei Arten fort: ein monatliches Retainer für laufenden Content, SEO und Entwicklungsarbeit, oder eine bedarfsabhängige Beauftragung für konkrete Projekte. Retainer sind keine Pflicht: Die Arbeit soll für sich sprechen.

Kunden mit Retainer erhalten monatliche Performance-Berichte: organische Traffic-Entwicklung, Core Web Vitals, Ranking-Bewegungen und Conversion-Rate-Daten. Keine Eitelkeitsmetriken, sondern Kennzahlen, die mit Geschäftsergebnissen zusammenhängen.

Ist dieser Prozess der richtige für Sie?

Dieser Prozess funktioniert am besten für Unternehmen, die:

  • Ernsthaft in eine Website investieren, nicht die günstigste Option suchen
  • Verstehen wollen, was sie bekommen und warum jede Entscheidung so getroffen wurde
  • Ein klares Geschäftsziel haben, das die neue Seite unterstützen soll
  • Bereit sind, an Discovery und Content-Review mitzuwirken (insgesamt 3-5 Stunden Ihrer Zeit)

Wer aktuell auf WordPress läuft und nicht sicher ist, ob die Seite das volle Potenzial ausschöpft: eine kostenlose Analyse gibt schnell Klarheit. Das Tool prüft Core Web Vitals, PageSpeed-Score und technischen Zustand in 60 Sekunden. Hier starten: webvise.io/wp-health-report. Danach steht ein konkretes Gespräch offen, was ein neuer Build für Ihre Situation bedeuten würde.