Wissen / Website-Grundlagen

Warum ein Website-Entwurf noch keine fertige Website ist.

Kurz gesagt: Ein Website-Entwurf ist eine visuelle und konzeptionelle Vorlage. Eine fertige Website ist technisch umgesetzt, mit echten Inhalten und vereinbarten Funktionen geprüft sowie für den Livegang freigegeben. Erst daran lassen sich Bedienung, Barrierefreiheit, Formulare, technische Suchvoraussetzungen und Datenschutz konkret prüfen. Reale Nutzungsdaten entstehen nach der Veröffentlichung.

Veröffentlicht am / Redaktion: Ruhrstack / 13 Minuten Lesezeit

01 / BEGRIFFE

Fünf Stände, die oft denselben Namen bekommen.

„Entwurf“ kann eine Bleistiftskizze, eine ausgearbeitete Desktopansicht oder einen klickbaren Prototyp meinen. Für ein Angebot und eine Abnahme ist diese Unschärfe zu groß.

Wireframe
Eine Strukturskizze. Sie ordnet Bereiche, Inhalte und Wege, trifft aber noch keine vollständige Aussage zu Farben, Typografie, Bildern oder Feindetails.
Visueller Entwurf oder Mockup
Eine ausgearbeitete Ansicht des geplanten Erscheinungsbilds. Sie kann sehr realistisch wirken, bleibt aber zunächst eine Darstellung und kein belastbarer Funktionsnachweis.
Klickbarer Prototyp
Verknüpfte Ansichten simulieren ausgewählte Wege. Ein Klick kann zur nächsten Fläche führen, ohne dass Navigation, Formular, Suche oder Datenverarbeitung wirklich gebaut sind.
Testseite oder Staging
Eine echte technische Umsetzung in einer nicht öffentlichen Umgebung. Hier können Funktionen, Inhalte und Darstellung geprüft werden. Produktionskonfiguration, echte Domain und laufender Betrieb können trotzdem noch fehlen.
Veröffentlichte Website
Die freigegebene Version unter ihrer vorgesehenen Adresse, verbunden mit Hosting, Sicherheitskonfiguration, Rechtstexten, Zuständigkeiten und einem Verfahren für Änderungen und Störungen.
Was sich an welchem Stand tatsächlich beurteilen lässt
Stand Lässt sich gut beurteilen Ist noch nicht belegt
Entwurf Informationsgewichtung, Stil, Raster, beispielhafte Anordnung Bedienung, Ladezeit, Browser-Verhalten, technische Auffindbarkeit
Prototyp Ausgewählte Nutzerwege, Reihenfolge, Rückmeldungen zum Bedienkonzept Echte Funktionen, Tastaturbedienung, Formulardaten, Betrieb
Staging Code, Inhalte, Funktionen, responsive Zustände und viele technische Tests Produktions-DNS, reale Felddaten, endgültige Betriebsabläufe
Live Gesamtes System unter realen Bedingungen Keine dauerhafte Fehlerfreiheit. Wartung und Beobachtung bleiben nötig

02 / ENTWURF

Was ein guter Entwurf bereits leisten muss.

Der Unterschied zur fertigen Website macht den Entwurf nicht unwichtig. Im Gegenteil: Hier werden Entscheidungen günstig sichtbar, bevor sie auf viele Seitentypen und Funktionen übertragen werden.

Er ordnet echte Inhalte, nicht nur Platzhalter.

Eine Startseite mit drei kurzen Beispielzeilen kann fast immer ruhig aussehen. Die belastbare Probe beginnt mit realen Leistungen, langen Überschriften, konkreten Ansprechpartnern, Formularhinweisen und den Bildern, die tatsächlich verfügbar sind. Erst dann zeigt sich, ob Hierarchie und Raster tragen.

Ein guter Entwurf beantwortet deshalb mindestens: Welche Frage klärt die Seite zuerst? Welche Handlung ist an dieser Stelle sinnvoll? Was ist Hauptinhalt, was Nachweis und was Ergänzung? Welche wiederkehrenden Bausteine werden gebraucht? Diese Entscheidungen bestimmen später auch die semantische Struktur und die interne Verlinkung.

Er zeigt ein System und nicht nur eine schöne Einzelansicht.

Eine Website besteht selten nur aus einer Startseite. Benötigt werden außerdem Leistungsseiten, Artikelseiten, Formulare, Fehlermeldungen, Navigation, Footer und oft weitere Seitentypen. Der Entwurf sollte erkennbar machen, wie Typografie, Abstände, Farben, Karten, Schaltflächen und Medien in diesen Situationen zusammenarbeiten.

Auch Zustände gehören zur Gestaltung: Was passiert beim Tastaturfokus? Wie sieht eine Fehlermeldung aus? Was bleibt sichtbar, wenn ein Bild fehlt? Wie bricht eine lange Überschrift auf einem schmalen Bildschirm um? Wenn solche Fragen erst während der Entwicklung auftauchen, muss die Umsetzung zwangsläufig gestalten. Das ist nicht grundsätzlich falsch, sollte aber im Leistungsumfang benannt sein.

03 / UMSETZUNG

Der Entwurf zeigt Flächen. Die Umsetzung braucht Regeln.

Entwicklung bedeutet nicht, Pixel möglichst genau nachzuzeichnen. Sie übersetzt die Absicht des Entwurfs in Regeln, Inhalte, Zustände und technische Abhängigkeiten.

Struktur und Semantik

Überschriften, Navigation, Hauptinhalt, Listen, Tabellen, Formulare und ergänzende Hinweise brauchen im HTML eine nachvollziehbare Bedeutung. Das hilft Browsern, assistiven Technologien und Suchsystemen. Eine Überschrift, die im Entwurf nur durch Größe auffällt, muss im Code trotzdem an der richtigen Stelle der Dokumentstruktur stehen.

Zur Umsetzung gehören außerdem URLs, Seitentitel, Beschreibungen, Canonicals, interne Links, Weiterleitungen und strukturierte Daten, soweit sie zum sichtbaren Inhalt passen. Google nennt als technische Mindestvoraussetzungen für eine mögliche Indexierung unter anderem einen HTTP-Status 200, nicht blockierten Zugriff für Googlebot und indexierbaren Inhalt. Auch dann ist eine Indexierung nicht garantiert. Ein Entwurf kann keine dieser Bedingungen erfüllen oder prüfen [1]. Wie Ruhrstack diesen Schritt abgrenzt, steht bei der Website-Entwicklung.

Responsive Verhalten statt verkleinerter Desktopansicht

Zwischen einer schmalen Mobilansicht und einem breiten Desktop liegen viele mögliche Breiten. Elemente müssen umbrechen, ihre Reihenfolge ändern oder eine andere Bedienform annehmen, ohne dass Inhalt verloren geht. Die Navigation wird auf kleinen Displays einblendbar und per Tastatur bedienbar, eine breite Tabelle erhält eine nutzbare schmale Lösung und ein Zweispalter wird zu einer sinnvollen Reihenfolge.

Das ist auch für Auffindbarkeit relevant, weil Google die mobile Version einer Website für Indexierung und Bewertung heranzieht [2]. Eine freigegebene Desktopgrafik belegt daher weder mobile Vollständigkeit noch mobile Nutzbarkeit.

Funktionen, Daten und Fehlerfälle

Ein Kontaktformular braucht echte Eingabefelder, verständliche Beschriftungen, Validierung, eine sichere Übertragung, Spam-Schutz und eine Rückmeldung bei Erfolg oder Fehler. Ein CMS benötigt Rollen, Bearbeitungswege und definierte Inhaltsfelder. Externe Dienste brauchen eine technische und datenschutzrechtliche Einordnung. All das kann ein Prototyp andeuten, aber nicht durch seine Optik lösen.

Gerade die unsichtbaren Fälle unterscheiden einen Vorführstand von einer belastbaren Website: Was passiert ohne JavaScript, bei langsamer Verbindung, mit einer fehlerhaften Eingabe, einem sehr langen Namen oder einem ausgefallenen Drittanbieter? Eine Umsetzung ist erst dann prüfbar, wenn diese Zustände tatsächlich existieren.

04 / PRÜFUNG

Was vor der Veröffentlichung geprüft werden sollte.

Eine Abnahme wird belastbar, wenn nicht nur „sieht gut aus“ vereinbart ist, sondern konkrete Prüfbereiche, Geräte, Funktionen und Verantwortlichkeiten.

Darstellung und Bedienung

Geprüft werden sinnvolle Bildschirmbreiten, aktuelle Zielbrowser, Zoom, Hoch- und Querformat sowie mindestens ein reales Mobilgerät. Die Gerätesimulation im Browser ist hilfreich, wird von Chrome selbst aber nur als Annäherung beschrieben. Bei Zweifeln soll auf echter Hardware geprüft werden [3].

Zur Bedienprüfung gehören Tastaturreihenfolge, sichtbarer Fokus, Sprunglink, Menü, Akkordeons, Pausemöglichkeiten für Bewegung, Formulare und Fehlermeldungen. Automatische Prüfungen finden viele technische Probleme, aber nicht, ob ein Ablauf verständlich ist. Deshalb braucht Qualitätssicherung beides: Werkzeuge und menschliche Nutzung [11].

Barrierefreiheit

Die WCAG 2.2 ordnet Anforderungen den vier Prinzipien wahrnehmbar, bedienbar, verständlich und robust zu [4]. Dazu zählen nicht nur Farbkontraste. Ebenso wichtig sind Textalternativen, semantische Beziehungen, Tastaturbedienung, Fokus, verständliche Beschriftungen, Statusmeldungen und die Nutzung mit assistiven Technologien.

Für normale Textseiten beschreibt das Reflow-Kriterium, dass Inhalte bis zu einer Breite von 320 CSS-Pixeln ohne Informations- oder Funktionsverlust und grundsätzlich ohne zweidimensionales Scrollen nutzbar bleiben sollen. Ausgenommen sind Inhalte, deren Bedeutung eine zweidimensionale Darstellung erfordert [5]. Das lässt sich an einer Desktopansicht nicht ablesen.

Performance unter realistischen Bedingungen

Ladezeit entsteht erst aus Dateien, Serverantwort, Browser, Gerät, Netz und Laufzeitverhalten. Die Core Web Vitals betrachten Ladeerlebnis, Reaktionsfähigkeit und visuelle Stabilität. Als „gut“ gelten am 75. Perzentil LCP bis 2,5 Sekunden, INP bis 200 Millisekunden und CLS bis 0,1 [6].

Ein Labortest ist eine reproduzierbare Diagnose und wichtig vor dem Start. Felddaten zeigen später, was reale Besucher mit ihren Geräten und Verbindungen erleben [12]. Ein guter Einzelwert ist deshalb weder eine Garantie für jedes Gerät noch eine Rankinggarantie [13]. Er ist ein Messpunkt, aus dem konkrete Verbesserungen folgen können. Die Verbindung aus technischer Auffindbarkeit und Ladeverhalten ist im Leistungsbereich SEO und Performance eingeordnet.

Eine kompakte Prüfmatrix für die technische Abnahme
Bereich Beispiel für einen Nachweis Aus einem Entwurf ableitbar?
Funktion Formular erreicht den vorgesehenen Empfänger und zeigt Fehler verständlich an Nein
Responsive Textseiten bleiben bei 320 CSS-Pixeln nutzbar; Zoom wird gesondert geprüft Nur als Zielbild
Barrierefreiheit Kernwege sind per Tastatur nutzbar, Namen und Status sind programmatisch verständlich Teilweise
Performance Messbericht für die ausgelieferte Seite, später ergänzt durch Felddaten Nein
SEO Status 200, Canonical, nicht blockierter Zugriff und indexierbarer sichtbarer Inhalt; die Sitemap unterstützt nur die URL-Erkennung Nein

05 / RECHT

Rechtliches ist kein Block für den letzten Nachmittag.

Welche Pflichten gelten, hängt vom Anbieter, vom Angebot und von den eingesetzten Diensten ab. Genau deshalb muss die Klärung vor dem Start stattfinden.

Anbieterangaben und Datenschutzinformationen

Für geschäftsmäßige, in der Regel entgeltlich angebotene digitale Dienste verlangt § 5 DDG bestimmte Anbieterinformationen, die leicht erkennbar, unmittelbar erreichbar und ständig verfügbar sein müssen [7]. Welche Angaben im Einzelfall dazugehören, hängt unter anderem von Rechtsform, Registereintrag und Beruf ab.

Werden über ein Kontaktformular personenbezogene Daten erhoben, müssen die betroffenen Personen zum Zeitpunkt der Erhebung unter anderem über Verantwortliche, Zwecke, Rechtsgrundlage und Speicherdauer oder deren Kriterien informiert werden. Das folgt aus Artikel 13 DSGVO [8]. Eine Einwilligungscheckbox ist nicht automatisch die passende Rechtsgrundlage für jede Anfrage. Das muss passend zum tatsächlichen Vorgang bewertet werden.

Bei einem regelmäßig gepflegten Wissensbereich ist zusätzlich zu klären, ob Angebote mit journalistisch-redaktionell gestalteten Inhalten im Sinne von § 18 Absatz 2 MStV entstehen. Falls die Vorschrift greift, muss eine verantwortliche natürliche Person mit Namen und Anschrift benannt werden. Ob das der Fall ist, hängt von Inhalt und redaktioneller Ausgestaltung ab [14].

Kein Cookiebanner nach dem Gießkannenprinzip

§ 25 TDDDG betrifft das Speichern von Informationen in einem Endgerät oder den Zugriff auf bereits gespeicherte Informationen. Eine Einwilligung ist unter anderem dann nicht nötig, wenn Speicherung oder Zugriff unbedingt erforderlich sind, damit der Anbieter einen vom Nutzer ausdrücklich gewünschten digitalen Dienst zur Verfügung stellen kann [9]. Entscheidend sind daher die tatsächlich eingesetzten Technologien. Ein Banner bei ausschließlich einwilligungsfreien Vorgängen ist ebenso wenig eine Qualitätsgarantie wie ein fehlendes Banner bei einwilligungspflichtigem Tracking.

Barrierefreiheit: Qualität immer, Pflicht nicht pauschal

Barrierefreiheit verbessert Zugang und Bedienbarkeit unabhängig von einer gesetzlichen Pflicht. Das Barrierefreiheitsstärkungsgesetz erfasst im privatwirtschaftlichen Bereich jedoch bestimmte Produkte und Dienstleistungen, darunter bestimmte Dienstleistungen im elektronischen Geschäftsverkehr. Eine gewöhnliche Unternehmenswebsite fällt nicht allein durch ihre Existenz automatisch darunter. Auch Ausnahmen, etwa für Kleinstunternehmen bei Dienstleistungen, müssen berücksichtigt werden [16]. Die Bundesfachstelle Barrierefreiheit erläutert den Anwendungsbereich für E-Commerce im Detail [10].

Für Websites öffentlicher Stellen gelten eigene Vorschriften des Bundes und der Länder. Auf Bundesebene konkretisiert die BITV 2.0 die barrierefreie Gestaltung von Websites und mobilen Anwendungen öffentlicher Stellen. Diese Regeln sind vom privatwirtschaftlichen BFSG-Anwendungsbereich zu unterscheiden [15].

06 / BETRIEB

Eine Website wird veröffentlicht und danach betrieben.

Beim Livegang werden nicht nur Dateien kopiert. Inhalte und Code treffen auf Domain, Server, Sicherheit, Beobachtung und klare Zuständigkeiten.

Vor dem Umschalten

Domain und DNS müssen auf die richtige Umgebung zeigen, HTTPS muss funktionieren und Produktionszugänge dürfen nicht aus Testwerten bestehen. Bei einem Relaunch kommen Weiterleitungen von alten auf neue Adressen hinzu. Formulare werden unter der echten Domain erneut geprüft. Suchmaschinen dürfen keine Testumgebung indexieren, die fertige Seite aber auch nicht versehentlich gesperrt bleiben.

Zur Übergabe gehören nicht nur Zugangsdaten. Ebenso wichtig sind Zuständigkeiten: Wer pflegt Inhalte? Wer aktualisiert Komponenten? Wo liegen Backups? Wer reagiert auf eine Störung? Welche externen Konten gehören dem Unternehmen? Ohne Antworten bleibt die Website zwar sichtbar, aber organisatorisch unfertig.

Nach dem Start

Direkt nach dem Livegang werden wichtige URLs, Weiterleitungen, Formulare, Indexierbarkeit und Darstellungsfehler erneut kontrolliert. Später kommen Updates, Backups, Verfügbarkeitskontrolle, Sicherheitsbeobachtung und die Auswertung echter Nutzung hinzu. Neue Inhalte können weitere Seitentypen oder Navigationsentscheidungen nötig machen.

„Fertig“ bedeutet bei einer Website daher nicht „wird nie wieder angefasst“. Es bedeutet: Der vereinbarte Stand ist funktionsfähig, geprüft, dokumentiert und für den geregelten Betrieb übergeben. Änderungen danach sind Weiterentwicklung und kein Ersatz für eine fehlende Erstabnahme. Zuständigkeiten für Server, Umzug und laufende Betreuung gehören deshalb als eigener Punkt zur Hosting-Einordnung.

07 / ANGEBOT

So erkennen Sie, was wirklich angeboten wird.

Ein gutes Angebot muss nicht jede technische Einzelheit vorwegnehmen. Es sollte aber Ergebnis, Grenzen, Prüfweg und Zuständigkeiten so benennen, dass beide Seiten denselben Endstand meinen.

  1. Seitentypen und Umfang klären. Stehen nur Startseite und ein Designsystem im Angebot oder auch Leistungsseiten, Artikel, Formulare und rechtliche Seiten?
  2. Inhalte zuordnen. Wer liefert, überarbeitet, prüft und pflegt Texte, Bilder, Downloads, Metadaten und Übersetzungen?
  3. Entwurfsstände benennen. Welche Breiten, Zustände und Seitentypen werden gestaltet? Ist ein Prototyp nur zur Abstimmung oder bereits Teil der technischen Leistung?
  4. Funktionen konkretisieren. Was tun Formulare, CMS, Suche, Newsletter, Karten oder externe Schnittstellen tatsächlich?
  5. Prüfmaßstab vereinbaren. Welche Browser, Geräte, Kernwege, Barrierefreiheitsziele und Performance-Messungen gehören zur Abnahme?
  6. Livegang und Übergabe abgrenzen. Wer kümmert sich um Domain, Hosting, E-Mail-Zustellung, Weiterleitungen, Backups, Dokumentation und Zugänge?
  7. Betrieb nach dem Start regeln. Ist Wartung enthalten, separat buchbar oder vollständig beim Unternehmen angesiedelt?

08 / KURZANTWORTEN

Die wichtigsten Fragen in einem Absatz.

Für die schnelle Einordnung, ohne die entscheidenden Grenzen wegzulassen.

Ist ein Figma-Entwurf bereits eine Website?

Nein. Ein Figma-Entwurf kann Struktur, Aussehen und ausgewählte Abläufe sehr genau zeigen. Er hat aber keine produktive Webadresse, verarbeitet keine echten Formulardaten und belegt weder Ladezeit noch Browser- oder Suchmaschinenverhalten.

Ist ein klickbarer Prototyp mehr als ein Entwurf?

Ja, weil er Nutzerwege und Interaktionen besser prüfbar macht. Er bleibt dennoch eine Simulation, solange die zugrunde liegenden Funktionen, Inhalte und Schnittstellen nicht real umgesetzt sind.

Kann KI aus einem Entwurf eine fertige Website bauen?

KI kann zum Beispiel Varianten vergleichen, Menücode erzeugen oder Routinetests vorbereiten. Sie entscheidet aber nicht, ob die versprochene Leistung fachlich stimmt, ob ein Formular beim echten Empfänger ankommt oder wer nach dem Start ein Sicherheitsupdate einspielt. Diese Punkte brauchen klare Zuständigkeiten und eine geprüfte Website-Umsetzung.

Wann ist eine Website bereit für den Livegang?

Wenn der vereinbarte Inhalt vollständig ist, Kernfunktionen und relevante Geräte geprüft wurden, technische Suchvoraussetzungen stimmen, rechtliche und datenschutzbezogene Punkte geklärt sind und Hosting, Domain, Übergabe sowie Zuständigkeiten feststehen.

Ist eine Website nach dem Livegang endgültig fertig?

Sie kann vollständig abgenommen und betriebsbereit sein. Trotzdem bleiben Updates, Backups, Beobachtung und spätere Inhaltsänderungen. Das ist normaler Betrieb und kein Zeichen dafür, dass der veröffentlichte Stand nur ein Entwurf war.

09 / QUELLEN

Quellen und redaktioneller Stand.

Amtliche und fachlich maßgebliche Quellen für die überprüfbaren technischen und rechtlichen Aussagen. Der Artikel wurde am 27. August 2026 veröffentlicht.

Redaktion
Ruhrstack, Dortmund
Veröffentlicht
Quellen geprüft
  1. Google Search Central: Technical requirements, abgerufen am 27. August 2026.
  2. Google Search Central: Mobile-first indexing best practices, abgerufen am 27. August 2026.
  3. Chrome for Developers: Simulate mobile devices with device mode, abgerufen am 27. August 2026.
  4. W3C Web Accessibility Initiative: Web Content Accessibility Guidelines 2.2, W3C Recommendation, abgerufen am 27. August 2026.
  5. W3C Web Accessibility Initiative: Understanding Success Criterion 1.4.10 Reflow, abgerufen am 27. August 2026.
  6. web.dev: How the Core Web Vitals metrics thresholds were defined, aktualisiert am 7. Mai 2025.
  7. Bundesministerium der Justiz und Bundesamt für Justiz: § 5 Digitale-Dienste-Gesetz, abgerufen am 27. August 2026.
  8. Europäische Union: Datenschutz-Grundverordnung, insbesondere Artikel 13, abgerufen am 27. August 2026.
  9. Bundesministerium der Justiz und Bundesamt für Justiz: § 25 Telekommunikation-Digitale-Dienste-Datenschutz-Gesetz, abgerufen am 27. August 2026.
  10. Bundesfachstelle Barrierefreiheit: FAQ zu Dienstleistungen im elektronischen Geschäftsverkehr, abgerufen am 27. August 2026.
  11. W3C Web Accessibility Initiative: Selecting Web Accessibility Evaluation Tools, aktualisiert am 21. Dezember 2022.
  12. web.dev: Why lab and field data can be different, aktualisiert am 26. Juni 2025.
  13. Google Search Central: Understanding page experience in Google Search results, aktualisiert am 10. Dezember 2025.
  14. Landesanstalt für Medien NRW: Transparenz im Internet, abgerufen am 27. August 2026.
  15. Bundesministerium der Justiz und Bundesamt für Justiz: Barrierefreie-Informationstechnik-Verordnung, abgerufen am 27. August 2026.
  16. Bundesministerium der Justiz und Bundesamt für Justiz: § 3 Barrierefreiheitsstärkungsgesetz, insbesondere Absatz 3, abgerufen am 27. August 2026.

Redaktioneller Hinweis: Dieser Beitrag dient der allgemeinen Information und ersetzt keine Einzelfallprüfung. Trotz sorgfältiger Recherche wird keine Gewähr für Vollständigkeit und fortdauernde Aktualität übernommen. Eine Haftung nach zwingenden gesetzlichen Vorschriften bleibt unberührt. Redaktionelle Einordnung.

Entwurf, Angebot oder bestehende Website einordnen?

Eine URL, ein Entwurf oder eine kurze Beschreibung genügt. Wir sagen, welcher Stand vorliegt und welche nächsten Schritte sinnvoll wären.

Stand gemeinsam klären