Internetauftritt programmieren: Der Planungsleitfaden von der ersten Zielklärung bis zum laufenden Betrieb

Wer einen Internetauftritt individuell programmieren lässt, trifft eine Projektentscheidung und keine Werkzeugwahl. Individuelle Entwicklung ersetzt die Konfiguration eines Standardthemes durch Eigenverantwortung: Architektur, Qualitätskriterien, Abnahme und Betrieb werden zu Aufgaben des eigenen Projekts, und genau dafür muss man gerüstet sein. Dieser Leitfaden begleitet Sie auf dem vollständigen Weg. Er beginnt bei den Geschäftszielen, übersetzt sie in einen belastbaren Anforderungskatalog, leitet daraus die Architektur ab, gliedert die Umsetzung in tragfähige Phasen und endet bei Abnahme, Go-live und Wartungsbudget. Programmierkurse, Vergleiche von Sprachen und allgemeine Website-Checklisten bleiben dabei bewusst außen vor. Es geht ausschließlich um die Entscheidungen, die ein individuelles Projekt langfristig erfolgreich machen.

Wann individuelle Programmierung die richtige Entscheidung ist

Die entscheidende Vorfrage lautet nicht “welche Technologie”, sondern “welcher Anteil unseres Auftritts muss wirklich individuell sein”. Ein Auftritt aus Startseite, Leistungsseiten, Kontaktbereich und Blog lässt sich mit einem Standardsystem sauber und wirtschaftlich abbilden. Individuelle Programmierung rechnet sich, sobald mindestens einer der folgenden Punkte zutrifft:

• Eigene Geschäftslogik im Web. Konfiguratoren, Preisrechner, Verfügbarkeitsprüfungen oder eine Terminbuchung mit eigenen Regeln.
• Integration in bestehende Systeme. ERP, CRM, Warenwirtschaft oder ein Lagerbestand sollen live in die Seiteninhalte einfließen.
• Eigene Datenmodelle. Die Inhalte sind weder Artikel noch Produkte, sondern etwa Objekte, Fahrzeuge, Projekte oder Standorte mit vielen eigenen Feldern und Beziehungen untereinander.
• Harte nichtfunktionale Ziele. Ladezeit, Barrierefreiheit oder Datenschutz sind vertraglich zugesagt und müssen nachweisbar erfüllt werden.
• Langfristige Unabhängigkeit. Der Auftritt soll über Jahre weiterwachsen, ohne von den Roadmap-Entscheidungen eines fremden Anbieters abzuhängen.

Trifft nichts davon zu, ist ein individuell programmierter Auftritt in der Regel teurer, ohne besser zu sein. Trifft ein Punkt zu, verändert sich die Fragestellung sofort: Nicht mehr “bauen oder kaufen”, sondern “welchen Teil bauen wir individuell und welchen setzen wir auf bewährte Bausteine”. Die meisten gelungenen Projekte sind solche Mischformen, etwa ein etabliertes Redaktionssystem für die Inhaltsseiten plus eine eigens programmierte Anwendung für den Kern der Wertschöpfung.

Schritt 1: Geschäftsziele in prüfbare Anforderungen übersetzen

Ein Anforderungskatalog, der mit Adjektiven wie “modern”, “professionell” und “benutzerfreundlich” beginnt, ist nicht abnahmefähig. Er wird es erst, wenn jedes Ziel eine Messgröße erhält. Die Übersetzung gelingt in drei Stufen.

Geschäftsziel. Was soll der Auftritt für das Unternehmen leisten? Anfragen erzeugen, Bewerbungen einsammeln, Supportaufwand reduzieren, Vertriebsgespräche vorbereiten. Notieren Sie zu jedem Ziel, wer im Unternehmen dafür verantwortlich ist.

Nutzeraufgabe. Welche konkrete Aufgabe erledigt ein Besucher, damit dieses Ziel erreicht wird? “Das passende Leistungspaket finden und unverbindlich anfragen” ist eine Aufgabe. “Sich über uns informieren” ist keine, weil sie weder beobachtbar noch abnehmbar ist.

Prüfbare Anforderung. Was muss die Software dafür leisten, und woran erkennt man, dass sie es tut? Aus der genannten Aufgabe wird zum Beispiel: Ein mehrstufiges Anfrageformular speichert Zwischenstände, validiert serverseitig, versendet eine Bestätigung und legt die Anfrage im CRM an. Die Abnahme prüft dies mit fünf definierten Testfällen, Fehlerfälle eingeschlossen.

Diese Kette ist der eigentliche Wert der Planungsphase. Sie verhindert die beiden häufigsten Projektschäden: Funktionen, die niemand bestellt hat, und Streit bei der Abnahme darüber, ob etwas “fertig” ist.

Ergänzen Sie die Kette um eine Priorisierung, die Verzicht erzwingt. Bewährt hat sich die Einteilung in “Start unmöglich ohne”, “Start möglich, Nachlieferung fest terminiert” und “Ideenspeicher”. Nur die erste Kategorie ist Vertragsgegenstand der ersten Ausbaustufe. Wer diese Trennung nicht durchzieht, startet mit einem Katalog, der drei Ausbaustufen zugleich umfasst, und wundert sich über die Angebote.

Schritt 2: Der technische Anforderungskatalog

Neben den fachlichen Anforderungen entscheidet ein zweiter Katalog über Qualität und Betriebskosten: die nichtfunktionalen Anforderungen. Sie sind der Teil, den Auftraggeber am häufigsten weglassen und am teuersten nachrüsten. Die folgende Tabelle zeigt die Kategorien, die in keinem Katalog fehlen dürfen, jeweils mit einem Beispiel für eine prüfbare Formulierung.

Vier dieser Zeilen verdienen eine genauere Begründung, weil sie die Architektur unmittelbar prägen.

Performance. Zu den Core Web Vitals gehören Largest Contentful Paint, Interaction to Next Paint und Cumulative Layout Shift. Sie bewerten Ladeleistung, Reaktionsfähigkeit und visuelle Stabilität (web.dev). Diese drei Größen sind kein Feinschliff am Ende, sondern eine Architekturentscheidung: Wie viel wird auf dem Server gerendert, wie viele Schriften und Skripte werden mitgeliefert, wie werden Bilder ausgespielt. Wer sie erst nach dem Go-live misst, repariert Grundsätzliches unter Zeitdruck.

Barrierefreiheit. Die WCAG 2.2 formuliert überprüfbare Erfolgskriterien für barrierefreie Webinhalte und ordnet sie den Konformitätsstufen A, AA und AAA zu (W3C). Genau diese Prüfbarkeit macht sie zum idealen Abnahmekriterium. Legen Sie die Zielstufe schriftlich fest, bevor die erste Vorlage entsteht. Fokusreihenfolge, Kontraste und Formularsemantik sind im Markup verankert und lassen sich nicht nachträglich aufpfropfen.

Sicherheit. HTTPS schützt HTTP-Verbindungen durch TLS-Verschlüsselung und unterstützt die Authentifizierung des angesprochenen Servers (MDN). Das ist heute Grundausstattung, doch der Katalog sollte weiter reichen: Wer erhält Zugang zum Redaktionssystem, wie werden Zugänge entzogen, wie schnell werden Sicherheitsaktualisierungen eingespielt, wer bemerkt einen Ausfall. Diese Fragen klingen organisatorisch, bestimmen aber technische Bausteine von der Benutzerverwaltung bis zum Updateprozess.

Datenschutz. Artikel 25 der Datenschutz-Grundverordnung verlangt Datenschutz durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen (EUR-Lex). Für ein Entwicklungsprojekt heißt das konkret: Welche Daten ein Formular erhebt, von wo Schriften und Karten geladen werden und welche Dienste ohne Einwilligung starten dürfen, gehört in den Anforderungskatalog und nicht in eine spätere Debatte mit der Rechtsabteilung.

Schritt 3: Architektur entscheiden

Die Architektur folgt aus dem Katalog, nicht aus Vorlieben des Teams. Vier Entscheidungen prägen das Projekt nachhaltig.

Rendering-Strategie

Die Kernfrage lautet: Wo entsteht das HTML? Serverseitig erzeugte Seiten liefern Inhalte, die sofort sichtbar und maschinell gut lesbar sind. PHP etwa wird auf dem Webserver ausgeführt und kann dynamische Inhalte erzeugen, bevor die fertige Antwort an den Browser gesendet wird (php.net). Dasselbe Prinzip gilt für serverseitig gerenderte JavaScript-Anwendungen und für vorab erzeugte statische Seiten.

Eine reine Anwendung im Browser, die ihre Inhalte erst nachlädt, ist für geschlossene Bereiche und Werkzeuge sinnvoll, für öffentliche Inhaltsseiten fast immer die teurere Variante. Ein pragmatischer Schnitt hat sich bewährt: Inhaltsseiten serverseitig oder vorgeneriert, interaktive Teilbereiche als eingebettete Komponenten. So bleiben Inhalt und Auffindbarkeit von der Laufzeitumgebung des Besuchers unabhängig.

Inhaltsmodell und Redaktion

Bevor eine Zeile Vorlage entsteht, sollte das Inhaltsmodell stehen: Welche Seitentypen gibt es, welche Felder hat jeder Typ, welche sind Pflicht, wie hängen die Typen zusammen. Dieses Modell entscheidet darüber, ob die Redaktion später selbstständig arbeitet oder für jede Änderung die Entwicklung benötigt. Die ehrlichste Probe ist ein Trockenlauf: Zwei echte Seiten mit echten Texten im Modell anlegen, bevor es festgeschrieben wird. Was dabei kippt, hätte sich sonst erst nach dem Relaunch gezeigt.

Frontend-Grundlagen

HTML beschreibt die Struktur und Bedeutung von Webinhalten, während CSS deren Darstellung und Layout steuert (MDN). JavaScript ergänzt Webseiten um programmierbares Verhalten und dynamische Interaktionen im Browser (MDN). Diese Arbeitsteilung ist mehr als eine Definition: Sie ist die Leitlinie, an der sich messen lässt, ob ein Auftritt robust gebaut ist. Alles, was für Verständnis und Bedienung nötig ist, gehört in Struktur und Darstellung. JavaScript veredelt, trägt aber nicht die Grundfunktion.

Responsive Layouts sind dafür der Standardfall. CSS Media Queries ermöglichen es, Darstellungsregeln an Eigenschaften wie die Breite des Viewports anzupassen, und bilden damit eine Grundlage responsiver Layouts (MDN). In der Praxis bedeutet das: Das Grundlayout funktioniert ohne jede Regel, Breakpoints ergänzen es nur dort, wo der Inhalt es verlangt. Ein Layout mit display: grid; gap: 2rem; kommt ohne jede Media Query aus; erst ab @media (min-width: 48rem) ergänzt grid-template-columns: 2fr 1fr; die zweispaltige Aufteilung.

Ein zweites kompaktes Beispiel zeigt, wie eng Struktur und Barrierefreiheit zusammenhängen. Nicht die Optik unterscheidet die beiden Varianten, sondern das, was Tastatur und Screenreader daraus machen: Ein div mit der Klasse btn und einem onclick-Attribut trägt keine Bedeutung, während ein echtes button-Element mit type="submit" fokussierbar, ansagbar und per Tastatur bedienbar ist.

Diese Beispiele sind bewusst knapp gehalten. Es geht nicht um einen Programmierkurs, sondern um das Prinzip: Struktur zuerst, Verhalten als Ergänzung. An diesem Prinzip können Sie auch als fachlicher Auftraggeber die Qualität einer Umsetzung ablesen.

Schnittstellen und Datenfluss

Sobald Fremdsysteme im Spiel sind, gehört pro Schnittstelle ein festes Fragenset in die Planung: Richtung des Datenflusses, Auslöser, Häufigkeit, Verhalten bei Ausfall des Gegenübers und die Frage, welches System die Wahrheit besitzt. Der letzte Punkt wird am häufigsten übersprungen und erzeugt später die hartnäckigsten Fehler, weil zwei Systeme denselben Datensatz unterschiedlich fortschreiben. Wer diese Fragen schriftlich beantwortet, bevor die Entwicklung beginnt, vermeidet die teuerste Fehlerklasse des gesamten Projekts.

Schritt 4: Umsetzung in Phasen

Ein individuell programmierter Internetauftritt entsteht nicht in einem Zug, sondern in Ausbaustufen mit jeweils sichtbarem Ergebnis. Bewährt hat sich diese Gliederung:

1. Fundament. Repository, Entwicklungsumgebung, Deployment-Strecke, Testumgebung, Inhaltsmodell. Am Ende dieser Phase steht eine leere, aber vollständig ausrollbare Anwendung.
2. Vertikaler Schnitt. Ein einziger vollständiger Seitentyp, von der Redaktionsmaske über die Vorlage bis zur ausgelieferten Seite, inklusive Messung von Ladeleistung und Tastaturbedienung. Dieser Schnitt deckt Architekturfehler auf, solange sie noch günstig zu korrigieren sind.
3. Breite. Die übrigen Seitentypen und Komponenten auf dem bestätigten Muster.
4. Fachlogik. Formulare, Rechner, Integrationen, also die Teile mit eigener Geschäftslogik und echten Fehlerfällen.
5. Härtung. Lasttest, Sicherheitsprüfung, Barrierefreiheitsprüfung, Inhaltsmigration, Weiterleitungskonzept.

Versionsverwaltung ist dabei kein Werkzeugdetail, sondern Voraussetzung für Nachvollziehbarkeit und geordnete Abnahme. Git speichert Änderungen als Versionen und ermöglicht es, Entwicklungsstände nachzuvollziehen, zu vergleichen und in separaten Branches zu bearbeiten (git-scm.com). Für das Projekt heißt das praktisch: Jede Anforderung wird in einem eigenen Branch umgesetzt, geprüft und zusammengeführt. So lässt sich zu jedem Zeitpunkt beantworten, was in der Testumgebung steht, was abgenommen ist und was live läuft.

Legen Sie außerdem eine gemeinsame Definition von “fertig” fest, die für jede Anforderung gilt: umgesetzt, automatisiert getestet, von einer zweiten Person geprüft, auf der Testumgebung durch den Auftraggeber bestätigt, dokumentiert. Ohne diese Liste verschiebt sich Aufwand systematisch in die Abnahmephase, wo er doppelt so teuer ist.

Schritt 5: Abnahme

Die Abnahme prüft nicht den Eindruck, sondern den Katalog aus Schritt 1 und 2. Drei Bestandteile machen sie belastbar.

Das Testprotokoll. Pro Anforderung ein Testfall mit Vorbedingung, Schritten und erwartetem Ergebnis, Fehlerfälle eingeschlossen. Ein Formular ist nicht abgenommen, wenn der Idealpfad funktioniert, sondern wenn auch eine ungültige Eingabe, ein doppelter Absendeversuch und ein nicht erreichbares Zielsystem definiert reagieren.

Die Messungen. Ladeleistung je Vorlage, Barrierefreiheitsprüfung gegen die vereinbarte Stufe, Kontrolle der Auslieferung über HTTPS, Sichtung der ausgelieferten Inhalte im Quelltext. Diese Ergebnisse gehören als Dateien ins Protokoll, nicht als Behauptung ins Protokollende.

Die Mängelklassen. Trennen Sie schriftlich zwischen Mängeln, die den Start verhindern, Mängeln mit Frist und Änderungswünschen. Letztere sind neue Anforderungen und gehören in die nächste Ausbaustufe, nicht in die laufende Abnahme. Diese Unterscheidung ist der wirksamste Schutz gegen eine Abnahme, die sich über Monate zieht.

Zur Abnahme gehören schließlich die Übergabegegenstände: Quellcode im Repository mit Zugriff für den Auftraggeber, dokumentierte Einrichtung, Zugangsverwaltung, Lizenzübersicht der eingesetzten Bausteine und eine Beschreibung der Deployment-Strecke. Ein Auftritt, den nur der bisherige Dienstleister ausrollen kann, ist technisch fertig und wirtschaftlich unfertig.

Schritt 6: Go-live

Der Start ist ein geplanter Vorgang mit Reihenfolge und Rückweg. Ein Cutover-Plan enthält mindestens:

• Zeitfenster und Rollen. Wer schaltet, wer prüft, wer entscheidet im Zweifel über den Rückweg.
• Inhaltsstand einfrieren. Ab wann wird im Altsystem nicht mehr redaktionell gearbeitet, und wie werden Änderungen aus dem Freeze-Fenster nachgezogen.
• Weiterleitungen. Jede bestehende URL bekommt ein Ziel oder eine bewusste Entscheidung dagegen. Dieser Punkt entscheidet darüber, ob vorhandene Sichtbarkeit den Relaunch überlebt.
• Technische Umschaltung. DNS-Vorlaufzeiten, Zertifikate, Caches, Suchmaschinenindexierung wieder freigeben. Der letzte Punkt ist der klassische Fehler: Eine Testumgebung war für Suchmaschinen gesperrt, und die Sperre wandert mit ins Produktivsystem.
• Prüfliste nach dem Start. Formulare mit echten Zielen testen, Zustellung der Benachrichtigungen bestätigen, Fehlerprotokolle beobachten, Messung der wichtigsten Vorlagen wiederholen.
• Rückweg. Unter welchen Bedingungen wird zurückgeschaltet, und wie lange bleibt diese Möglichkeit bestehen.

Planen Sie zusätzlich eine Stabilisierungsphase nach dem Start, in der das Entwicklungsteam kurzfristig verfügbar ist. Die ersten Tage im Echtbetrieb erzeugen Erkenntnisse, die keine Testumgebung liefert, weil erst echte Nutzer echte Eingaben machen.

Schritt 7: Wartung und Weiterentwicklung

Ein individuell programmierter Auftritt ist ein Produkt mit Lebenszyklus, kein abgeschlossenes Werk. Wer die Betriebsphase nicht budgetiert, erlebt nach etwa zwei Jahren den typischen Verfall: veraltete Abhängigkeiten, eine Redaktion, die sich nicht mehr traut, und einen Relaunch, der nur deshalb nötig wird, weil nie gepflegt wurde.

Regeln Sie schriftlich, was laufend passiert:

• Sicherheitsaktualisierungen mit definierter Reaktionszeit für kritische Lücken.
• Abhängigkeitspflege in festem Rhythmus, nicht erst bei Problemen.
• Backups mit geprüfter Wiederherstellung. Ein Backup, das nie zurückgespielt wurde, ist eine Annahme und keine Absicherung.
• Monitoring für Erreichbarkeit, Fehlerraten und Formularzustellung, mit benannter Alarmierung.
• Wiederkehrende Messung der vereinbarten Qualitätsziele, damit ein Rückschritt auffällt, bevor er wirkt.
• Ein kleines, festes Weiterentwicklungsbudget pro Quartal, damit Verbesserungen nicht jedes Mal ein eigenes Projekt brauchen.

Halten Sie zudem fest, wer welche Rolle besetzt: technischer Ansprechpartner, redaktionelle Verantwortung, Datenschutzverantwortung, Entscheidung über Budget. Projekte scheitern in der Betriebsphase selten an Technik und häufig daran, dass niemand zuständig ist.

Häufige Entscheidungsfehler und wie man sie vermeidet

Technologieauswahl vor Anforderungskatalog. Wird zuerst der Stack festgelegt, wird der Katalog anschließend so formuliert, dass er dazu passt. Die richtige Reihenfolge ist umgekehrt.

Design ohne Inhaltsmodell. Entwürfe mit Platzhaltertexten erzeugen Vorlagen, die mit echten Inhalten brechen. Setzen Sie echte Texte und echte Bilder in die ersten Entwürfe.

Nichtfunktionale Anforderungen als Schlussphase. Ladeleistung und Barrierefreiheit sind Architektureigenschaften. Nachträglich sind sie teuer und meist nur teilweise erreichbar.

Kein Weiterleitungskonzept. Der Relaunch, der bestehende URLs fallen lässt, verliert messbar Zugriffe. Die Ursache wird dann oft dem neuen Design zugeschrieben statt der fehlenden Umleitung.

Redaktion erst zum Schluss einbeziehen. Wer die späteren Pflegenden erst bei der Schulung sieht, erfährt zu spät, welche Felder fehlen und welche Abläufe im Alltag nicht funktionieren.

Abnahme ohne Nachweise. “Sieht gut aus” ist keine Abnahme. Jede zugesagte Eigenschaft braucht ein Dokument, das sie belegt.

Häufige Fragen

Was kostet es, einen Internetauftritt programmieren zu lassen?

Seriös beantwortbar ist das erst nach Schritt 1 und 2, denn der Preis hängt fast vollständig vom Umfang der Fachlogik, der Zahl der Seitentypen und der Zahl der Schnittstellen ab. Fragen Sie Angebote daher auf Basis des Anforderungskatalogs an, nicht auf Basis einer Seitenzahl. Vergleichbar werden Angebote erst, wenn alle Anbieter dieselbe Liste bepreisen.

Wie lange dauert ein solches Projekt?

Die Dauer wird meist weniger von der Entwicklung bestimmt als von Zulieferungen des Auftraggebers: Inhalte, Bilder, Freigaben, Zugänge zu Fremdsystemen. Planen Sie diese Zulieferungen mit Terminen und Verantwortlichen wie eigene Arbeitspakete, sonst werden sie zum stillen kritischen Pfad.

Individuelle Programmierung oder Redaktionssystem?

Beides schließt sich nicht aus. Der übliche gute Schnitt ist ein bewährtes System für Inhaltsseiten plus individuelle Entwicklung für die Teile mit eigener Geschäftslogik. Entscheidend ist, dass die Grenze zwischen beiden klar verläuft und dokumentiert ist.

Woran erkenne ich, dass sauber gearbeitet wurde?

An vier Dingen: Der Quellcode liegt in einer Versionsverwaltung, auf die Sie Zugriff haben. Die Einrichtung ist so dokumentiert, dass ein fremdes Team sie nachvollziehen kann. Es gibt automatisierte Tests für die Kernprozesse. Und die zugesagten Qualitätsziele sind gemessen, nicht behauptet.

Was gehört in den Vertrag?

Der Anforderungskatalog als Anlage, die Definition von “fertig”, die Abnahmekriterien mit Nachweisform, die Mängelklassen, die Übergabegegenstände samt Rechteeinräumung am Quellcode sowie die Konditionen der Wartungsphase. Diese sechs Punkte klären im Streitfall nahezu alles Wesentliche.

Zusammenfassung

Einen Internetauftritt individuell zu programmieren lohnt sich dort, wo eigene Geschäftslogik, eigene Datenmodelle, echte Systemintegration oder harte Qualitätszusagen im Spiel sind. Der Erfolg entscheidet sich vor der ersten Codezeile: in der Übersetzung von Geschäftszielen in prüfbare Anforderungen, in einem nichtfunktionalen Katalog mit Performance, Barrierefreiheit, Sicherheit und Datenschutz und in einer Architektur, die konsequent aus diesem Katalog folgt. Die Umsetzung läuft in Ausbaustufen mit einem frühen vertikalen Schnitt, die Abnahme prüft gegen Nachweise statt gegen Eindrücke, der Go-live ist ein geplanter Vorgang mit Rückweg, und die Wartung ist von Anfang an budgetiert. Wer diese sieben Schritte diszipliniert durchläuft, kauft kein Projektrisiko ein, sondern ein Produkt, das sich über Jahre weiterentwickeln lässt.