ONMA Ratgeber

Webseite programmieren lernen: der 12-Wochen-Plan mit Etappen und Selbsttests

Vier Etappen von HTML bis Deployment, acht Stunden pro Woche, dazu je ein Selbsttest, an dem Sie merken, ob die Etappe wirklich sitzt.

Frau vor einer Wand mit bunten Haftnotizen, davor sechs Personen mit Laptops an einem Besprechungstisch

Wer diesen Begriff sucht, will meistens keine Methode vergleichen und kein Tutorial nachtippen. Die Frage ist eine andere: In welcher Reihenfolge lerne ich was, wie lange dauert jede Etappe, und woran merke ich, dass ich sie wirklich kann. Genau das liefert dieser Plan: zwölf Wochen, vier feste Etappen, ein überprüfbarer Meilenstein je Etappe und ein Selbsttest, den man besteht oder eben nicht. Keine Sprachempfehlung, kein Schritt-für-Schritt-Tutorial, keine Berufsberatung.

Auf einen Blick: Etappe 1 (Woche 1 bis 3) HTML, Meilenstein eine Seite ohne Vorlage in 45 Minuten. Etappe 2 (Woche 4 bis 6) CSS und Layout, Meilenstein dasselbe Layout zweimal gebaut. Etappe 3 (Woche 7 bis 10) JavaScript, Meilenstein eine eigene interaktive Komponente. Etappe 4 (Woche 11 bis 12) Deployment, Meilenstein eine öffentliche URL in unter 30 Minuten. Rechnerisch acht Stunden pro Woche, rund 96 Stunden gesamt.

Warum die Reihenfolge feststeht, nicht die Sprachwahl

Wer neu einsteigt, verbringt oft Wochen mit der Frage, welche Sprache die richtige sei. Google spielt dazu passend die Frage “Welche Programmiersprache lernen für Webseiten?” als eine der meistgestellten Nutzerfragen zu diesem Thema aus. Dieser Plan beantwortet sie bewusst nicht, denn die Reihenfolge ist technisch vorgegeben, nicht verhandelbar: Der Browser lädt ein Dokument (HTML), stellt es nach Regeln dar (CSS) und führt darin Verhalten aus (JavaScript). Anschließend muss das Ergebnis auf einen Server, sonst sieht es niemand. Diese vier Schichten bauen aufeinander auf, keine lässt sich überspringen, ohne dass die nächsthöhere zur Blackbox wird.

Wer mit JavaScript beginnt, weil es “die eigentliche Programmierung” sei, sitzt in Woche drei an einem Problem, das eigentlich ein CSS-Problem ist, und merkt es nicht. Wer mit einem Framework beginnt, lernt das Framework, nicht das Web. Ein praktischer Vorteil kommt dazu: HTML wird von der WHATWG als HTML Living Standard fortlaufend gepflegt, es gibt keine nummerierten Nachfolgeversionen mehr. Sie müssen also nicht entscheiden, “welches HTML” Sie lernen, und kein Lehrbuch mit Versionsnummer im Titel suchen. Als Nachschlagewerk für alle drei Sprachen reichen die MDN Web Docs, die Mozilla pflegt und die je Feature dokumentieren, in welchen Browsern es funktioniert. Genau diese Kompatibilitätsangabe macht MDN einer beliebigen Blogsuche überlegen.

Das Zeitbudget, ehrlich gerechnet

Zwölf Wochen bedeuten in diesem Plan acht Stunden pro Woche, rund 96 Stunden insgesamt, bewusst nicht optimistisch gerechnet. Wichtiger als die Gesamtzahl ist die Verteilung: Vier Blöcke à zwei Stunden schlagen einen Block à acht Stunden am Wochenende deutlich, weil zwischen den Sitzungen etwas passiert, das nur die Pause leistet, das Gehirn sortiert im Hintergrund weiter.

Was 96 Stunden bringen: eine mehrseitige, ordentlich strukturierte, responsive Webseite mit einfacher Interaktivität selbst bauen und veröffentlichen. Was sie nicht bringen: als Entwickler arbeiten, komplexe Anwendungen bauen, eine fremde Codebasis übernehmen. Diese Unterscheidung fehlt in vielen Kursbeschreibungen und ist der häufigste Grund für Enttäuschung nach dem Abschluss. Die zweite Frage, die Google zum Thema häufig zeigt, “Wie schwer ist es, eine Website zu programmieren?”, lässt sich damit ehrlich beantworten: Erste sichtbare Ergebnisse kommen in Stunden, ein solides Fundament in Monaten, und dazwischen liegt eine Phase, in der es sich anfühlt, als ginge man rückwärts. Diese Phase ist eingeplant, siehe die Abbruchanalyse weiter unten.

Der Lernpfad im Überblick

EtappeWocheThemaMeilensteinSelbsttest
11 bis 3HTML und DokumentstrukturFünfteilige Seite ohne VorlageAus dem Kopf in 45 Minuten, Validator ohne Fehler
24 bis 6CSS, Layout, ResponsivitätDasselbe Layout mit Flexbox und mit GridVon 360 bis 1440 Pixel ohne horizontales Scrollen
37 bis 10JavaScript und DOMInteraktive Komponente ohne FrameworkOhne Tutorial in 90 Minuten, inklusive Fehlerfall
411 bis 12Deployment und MessungÖffentliche URL mit eigenem ProjektLeeres Repository bis live in unter 30 Minuten

Etappe 1, Woche 1 bis 3: Struktur vor Aussehen

Drei Wochen ausschließlich HTML klingen nach zu viel, bis man sieht, wie viele CSS-Probleme in Wahrheit Strukturprobleme sind. Diese Etappe deckt Dokumentaufbau, semantische Elemente, Formulare, Bilder mit sinnvollem Alternativtext ab und die Fähigkeit, eine Seite so zu bauen, dass sie auch ganz ohne Stylesheet noch lesbar und in der richtigen Reihenfolge ist.

Meilenstein: eine Seite mit fünf inhaltlichen Abschnitten, einem Formular und einer Navigation, komplett ohne CSS. Sie darf hässlich sein. Sie darf nicht unstrukturiert sein.

Selbsttest: Bauen Sie dieselbe Seite ein zweites Mal, ohne Vorlage, ohne Copy-Paste, Zeitlimit 45 Minuten. Danach durch den Validator des W3C schicken. Null Fehler, und Sie mussten nicht nachschlagen, wo eine Überschriftenebene hingehört: Etappe bestanden. Mussten Sie an derselben Stelle wie beim ersten Mal nachschlagen, wiederholen Sie den Test in einer Woche mit anderem Inhalt.

Etappe 2, Woche 4 bis 6: Layout, das nicht zufällig funktioniert

CSS ist die Etappe, in der die meisten Menschen anfangen, Werte auszuprobieren, bis es passt. Genau das soll dieser Abschnitt verhindern. Drei Wochen reichen für Boxmodell, Flexbox, Grid, relative Einheiten und Media Queries. Weglassen können Sie in dieser Phase: Präprozessoren, Utility-Frameworks, Animationen. Alle drei setzen voraus, dass Sie verstehen, was sie abkürzen.

Meilenstein: ein Layout mit Kopfbereich, Inhaltsspalte, Seitenleiste und Fußbereich, zweimal gebaut, einmal mit Flexbox und einmal mit Grid, dazu ein Satz, welche Variante Sie warum bevorzugen.

Selbsttest: Öffnen Sie das Layout in den Entwicklerwerkzeugen des Browsers und ziehen Sie die Breite von 360 auf 1440 Pixel. Kein horizontales Scrollen, kein überlappender Text, kein Bild, das aus seinem Container läuft. Zweiter Teil: Nehmen Sie eine beliebige Eigenschaft aus dem Stylesheet heraus und sagen Sie vorher, was passiert, bevor Sie neu laden. Liegen Sie dreimal richtig, arbeiten Sie nicht mehr nach Gefühl.

Etappe 3, Woche 7 bis 10: JavaScript, vier Wochen statt drei

Diese Etappe bekommt bewusst eine Woche mehr, weil hier zum ersten Mal Konzepte dazukommen, die nichts mit dem Web zu tun haben: Variablen, Bedingungen, Schleifen, Funktionen, Datenstrukturen. Danach kommt der spezifische Teil: das DOM ändern, auf Ereignisse reagieren, Daten von einer Schnittstelle holen und den Fall behandeln, dass diese Schnittstelle nicht antwortet.

Für diese Etappe sind kostenlose, strukturierte Kurse den Videosammlungen überlegen, weil sie Aufgaben stellen statt Lösungen vorzuführen. freeCodeCamp stellt seine Lernpfade und Zertifizierungen zu Responsive Web Design und JavaScript kostenlos bereit und wird in der einschlägigen Community, etwa in r/learnprogramming, regelmäßig als erste Empfehlung für Selbstlerner genannt. Nutzen Sie es als Übungsstrecke parallel zum eigenen Projekt, nicht als Ersatz dafür.

Meilenstein: eine funktionierende interaktive Komponente im eigenen Projekt, ohne Framework, ohne fertigen Baustein. Ein Filter, eine Suche über eine Liste, ein Formular mit eigener Eingabeprüfung.

Selbsttest: eine zweite, andersartige Komponente, ohne Tutorial, Zeitlimit 90 Minuten. Nachschlagen in der Referenz ist erlaubt, das machen Berufstätige auch. Bedingung fürs Bestehen: der Fehlerfall ist mitgebaut, also das Verhalten bei leerer Eingabe, bei keinem Treffer, bei ausbleibender Antwort. Wer nur den Erfolgsfall baut, hat nur den angenehmen Teil der Etappe erledigt.

Etappe 4, Woche 11 bis 12: Veröffentlichen und messen

Die kürzeste Etappe wird am häufigsten aufgeschoben, dabei ist sie der Punkt, an dem aus einem Ordner auf dem eigenen Rechner eine Webseite wird. Statisch erzeugte Seiten lassen sich ohne Servermiete über GitHub Pages oder Netlify veröffentlichen, beide mit kostenfreiem Kontingent für private Projekte. Dazu kommen Versionsverwaltung mit Git, ein eigener Domainname, falls gewünscht, und die Pflichtangaben, die eine öffentlich erreichbare Seite in Deutschland braucht.

Der zweite Teil ist die Messung. Lighthouse ist in die Chrome-Entwicklertools integriert und liefert Werte zu Ladezeit und Barrierefreiheit, mit denen Sie das eigene Projekt objektiv prüfen statt nach Gefühl zu bewerten. Das ist der Übergang vom Lernen zum Arbeiten: Sie bewerten das Ergebnis nicht mehr danach, ob es Ihnen gefällt, sondern anhand von Zahlen, die jemand anderes reproduzieren kann.

Meilenstein: Ihr Projekt ist unter einer öffentlichen Adresse erreichbar, eine Änderung im Code ist nach dem Hochladen innerhalb weniger Minuten live.

Selbsttest: ein leeres Repository bis zur öffentlichen URL in unter 30 Minuten, mit einem neuen Miniprojekt. Danach einen Lighthouse-Wert messen, gezielt eine Änderung vornehmen, erneut messen und den Unterschied erklären können. Wer das schafft, hat den vollständigen Kreislauf einmal geschlossen, und genau dieser Kreislauf ist das eigentliche Ergebnis der zwölf Wochen.

Wo Menschen abbrechen, und was dagegen hilft

Abbrüche verteilen sich nicht zufällig, sondern häufen sich an vier vorhersehbaren Stellen.

Woche 2, Langeweile. HTML fühlt sich nicht nach Programmieren an, das Ergebnis sieht nach nichts aus. Gegenmittel: von Tag eins an am eigenen Projekt arbeiten, nicht an Übungsdateien. Eine hässliche eigene Seite motiviert länger als eine schöne fremde.

Woche 5, Frust. Etwas sitzt nicht dort, wo es sitzen soll, und die dritte gefundene Lösung im Netz macht es schlimmer. Gegenmittel: nach 20 Minuten erfolglosem Probieren die Referenz zur betroffenen Eigenschaft von oben lesen, statt weiter zu raten.

Woche 8, Überforderung. JavaScript bringt abstrakte Konzepte mit, der Abstand zwischen “Tutorial verstanden” und “selbst geschrieben” wird zum ersten Mal spürbar. Gegenmittel: Umfang halbieren, Zeitplan strecken. Diese Etappe darf sechs Wochen dauern, ohne dass der Plan gescheitert ist.

Woche 11, Vermeidung. Veröffentlichen macht das eigene Ergebnis kritisierbar, deshalb wird es unbewusst verschoben und stattdessen weiter am Detail gefeilt. Gegenmittel: einen festen Termin setzen und mit einem bewusst kleinen Projekt live gehen, nicht mit dem Hauptprojekt.

Eine Abgrenzung, die Sie sich sparen können

Bei den bekannten Ratgebern zu diesem Thema treten Homepage-Baukästen wie Wix oder Webflow bei zwei von vier untersuchten Wettbewerbern als beworbene Alternative auf, oft direkt neben dem Lernplan. Das ist kein Widerspruch, sondern ein anderes Ziel. Wer in zwei Wochen eine funktionierende Seite braucht, nimmt einen Baukasten oder ein CMS. Wer verstehen will, was dort passiert, und in zwölf Wochen selbst bauen will, folgt diesem Plan. Die Entscheidung zwischen beidem ist eine Frage des Ziels, nicht der Qualität.

Ein Blick auf die vier zum Keyword analysierten Wettbewerberseiten zeigt, warum ein reiner Umfangsvergleich wenig hergibt: Sie liegen zwischen 290 und 3.842 Wörtern bei einem Median von 1.965. Keine strukturiert den Einstieg als datierten Lernplan mit Etappen und Selbsttests, die Gliederungen vergleichen Methoden oder listen Lernplattformen auf. Das erklärt auch die Suchnachfrage: “webseite programmieren lernen” wird hierzulande rund zehnmal im Monat gesucht, “website erstellen” dagegen etwa 22.200 Mal. Die überwältigende Mehrheit will eine Seite haben, nicht eine bauen lernen. Wer zur kleineren Gruppe gehört, hat einen Vorteil: ein klares Ziel, und zwölf Wochen sind eine Investition in Können, nicht in ein einzelnes Ergebnis.

Nach der zwölften Woche

Der Plan endet bewusst dort, wo der erste vollständige Kreislauf geschlossen ist: bauen, veröffentlichen, messen, verbessern. Was danach sinnvoll ist, hängt vom nächsten Projekt ab, nicht mehr von einem Lehrplan. Wiederholen Sie den Kreislauf drei bis vier Mal mit unterschiedlichen Projekten, bevor Sie ein Framework, eine Serversprache oder ein Datenbankthema anfangen. Diese Themen sind leichter zu lernen, wenn ein konkretes Problem sie erfordert. Ohne dieses Problem lernen Sie sie zweimal.