Eine Website veröffentlichen und warten

Eine Website benötigt einen Projektordner mit allen Dateien, die Besucher verwenden. Das ist das Website-Wurzelverzeichnis. Die Veröffentlichung ist viel einfacher, wenn dieser Ordner eine vollständige, übertragbare Website enthält: keine Bilder aus dem Downloads-Ordner und kein Stylesheet im Ordner eines anderen Projekts.

Gib jeder Dateiart einen Platz

Eine kleine Reparaturwerkstatt könnte diese Struktur verwenden:

riverside-bikes/
  index.html
  prices.html
  contact.html
  404.html
  css/styles.css
  scripts/menu.js
  images/logo.svg
  images/workshop-800.jpg
  images/workshop-1600.jpg
  blog/index.html
  blog/winter-checklist.html

Die HTML-Seiten enthalten die Inhalte, css/ enthält Stylesheets, scripts/ enthält JavaScript-Dateien und images/ die für Besucher vorbereiteten Bilder. Eine Website ohne Skripte benötigt keinen Skriptordner. Getrennte Ordner erleichtern das Auffinden zusammengehöriger Dateien, ohne zu ändern, wie ein Browser sie verwendet.

Die meisten Webserver senden index.html, wenn ein Besucher einen Ordner anfragt. Die Adresse https://www.example.com/ öffnet die Startseite im Wurzelverzeichnis. Die Adresse https://www.example.com/blog/ öffnet blog/index.html. Eine Datei namens home.html ist zwar ebenfalls eine Seite, aber der Server wählt sie für die Website-Adresse ohne weiteren Pfad normalerweise nicht aus.

Wähle Namen vor der Veröffentlichung

Verwende Kleinbuchstaben, Bindestriche zwischen Wörtern und die richtige Dateinamenerweiterung. opening-hours.html und team-photo.jpg sind klare Namen. Leerzeichen können in URLs als %20 erscheinen und eine Adresse schwerer lesbar und eintippbar machen. Namen werden Teil der öffentlichen Adressen der Website. Wähle sie daher passend zu den Inhalten, die sie bezeichnen.

Die Erweiterung sollte zur Datei passen: .html für HTML, .css für CSS, .js für Skripte und eine passende Bilderweiterung wie .jpg, .webp oder .svg. Der Server sendet einen Content-Type-Header, der das Format der Datei beschreibt. Hosting-Systeme wählen diesen Typ häufig anhand der Erweiterung. Wenn du ein Foto von .jpg in .webp umbenennst, wird sein Inhalt nicht umgewandelt. Exportiere es mit einem Bildbearbeitungswerkzeug im neuen Format.

Die meisten Server unterscheiden zwischen Groß- und Kleinschreibung. Ein Link auf Logo.svg kann fehlschlagen, wenn die hochgeladene Datei logo.svg heißt, selbst wenn er auf einem Computer mit einem Dateisystem ohne diese Unterscheidung funktioniert hat. Wenn du Namen grundsätzlich kleinschreibst, vermeidest du diesen Unterschied in neuen Projekten.

Trenne öffentliche Dateien von Arbeitsdateien

Bewahre Kameraoriginale, Designdateien und Notizen außerhalb des Website-Wurzelverzeichnisses auf, zum Beispiel in riverside-bikes-originals/. Exportiere nur die vorbereiteten Webbilder nach images/. Dateien im veröffentlichten Ordner können heruntergeladen werden, selbst wenn keine Seite darauf verlinkt. Halte Passwörter, private Dokumente und persönliche Daten aus diesem Ordner fern.

Prüfe vor dem Hochladen, ob jedes verlinkte lokale Asset innerhalb des Projekts liegt. Ein Foto unter einer persönlichen file://-Adresse existiert auf deinem Computer; es wird nicht mit der Website übertragen, wenn du es nicht in den veröffentlichten Ordner kopierst. Aktualisiere nach dem Verschieben den Link und teste ihn erneut.

Eine stabile Struktur schützt Links auch nach der Veröffentlichung. Wenn du prices.html an eine neue Adresse verschiebst, funktionieren alte Lesezeichen nicht mehr, sofern der Hostinganbieter die alte Adresse nicht auf die neue Seite weiterleitet.

Ein Pfad gibt dem Browser an, wo er nach einer Datei suchen soll. Um ihn richtig zu schreiben, bestimme sowohl die angeforderte Datei als auch den Ausgangspunkt, von dem aus der Browser den Pfad auflöst.

Beginne im Ordner der verweisenden Datei

Ein relativer Pfad beginnt im Ordner der aktuellen Seite. Auf der Website der Fahrradwerkstatt verlinkt index.html mit href="prices.html" auf prices.html, mit src="images/logo.svg" auf das Logo und mit href="blog/winter-checklist.html" auf einen Beitrag.

Von blog/winter-checklist.html aus ändert sich der Weg:

<link rel="stylesheet" href="../css/styles.css">
<a href="../index.html">Home</a>
<img src="../images/logo.svg" alt="Riverside Bike Repair">
<a href="autumn-tips.html">Autumn tips</a>

Für das Logo gehst du zuerst mit ../ von blog/ aus nach oben und wechselst dann in images/. Für eine Datei im selben Ordner genügt ihr Name. Zwei Ebenen nach oben erreichst du mit ../../. Verwende in Webpfaden immer normale Schrägstriche /, auch wenn du unter Windows arbeitest.

Ein Pfad in einer CSS-Datei beginnt im Ordner der CSS-Datei. In css/styles.css führt die Regel background-image: url("../images/pattern.svg"); von css/ nach oben und dann in images/. Sie beginnt nicht bei der HTML-Seite, die das Stylesheet gerade lädt.

Unterscheide drei Adressformen

Eine absolute URL enthält das URL-Schema und den Hostnamen. Verwende sie für eine andere Website. Relative Pfade erlauben es, deine eigene Website zwischen einem lokalen Server, einer Vorschauadresse und ihrer endgültigen Domain zu verschieben, ohne in jedem Link die Domain zu ersetzen.

Ein führender Schrägstrich hat eine bestimmte Bedeutung. Unter https://username.github.io/riverside-bikes/ fordert /css/styles.css die Adresse https://username.github.io/css/styles.css an. Der Projektordner entfällt aus der Adresse. Von der Seite im Wurzelverzeichnis der Website aus behält css/styles.css diesen Ordner bei und erreicht die gewünschte Datei.

Teste die Adresse, die der Browser tatsächlich verwendet

Wenn du HTML direkt von der Festplatte öffnest, entsteht eine file://-Adresse. Ordnerlinks und Pfade, die mit / beginnen, können sich dort anders verhalten. Starte einen lokalen Entwicklungsserver vom Website-Ordner aus, zum Beispiel mit python3 -m http.server, oder nutze die Live-Vorschau eines Code-Editors. Öffne dann die lokale HTTP-Adresse, die er bereitstellt.

Auf einem Server öffnet href="blog/" die Datei blog/index.html. Funktioniert ein Link oder Bild nicht, öffne vor dem Neuladen die Entwicklerwerkzeuge und suche die zugehörige Anfrage im Netzwerkbereich. Ein 404 bedeutet, dass die angeforderte Ressource nicht gefunden wurde. Lies die vollständige angefragte URL und vergleiche jeden Ordner, jeden Schrägstrich, jeden Buchstaben und jede Erweiterung mit den hochgeladenen Dateien. Ein Großbuchstabe oder ein fehlendes ../ genügt, um den Browser an einen anderen Ort zu schicken. Ein aus einem Dateimanager kopierter persönlicher Computerpfad kann Besucher nicht mit Dateien versorgen; ersetze ihn durch einen Pfad innerhalb der Website.

Browser versuchen, Seiten auch dann anzuzeigen, wenn der Code Fehler enthält. Diese Fehlerbehandlung ist für Besucher nützlich, kann aber Probleme vor dem Autor verbergen. Die Validierung prüft HTML oder CSS anhand der Regeln des jeweiligen Standards, unabhängig davon, ob die Seite zufällig richtig aussieht.

Verwende das passende Prüfwerkzeug

Der W3C Nu Html Checker prüft HTML. Der W3C CSS Validation Service prüft CSS. Du kannst eine veröffentlichte URL angeben, eine Datei hochladen oder Code einfügen. Die integrierten Prüfungen eines Editors sind beim Schreiben nützlich; mit den Prüfwerkzeugen im Web kannst du auch die veröffentlichte Kopie prüfen.

Lies die Zeilen- und Spaltenangabe zu jeder Meldung. Ein Fehler verletzt eine Regel und muss behoben werden. Eine Warnung oder Informationsmeldung verlangt Aufmerksamkeit, kann aber erlaubten Code beschreiben. Lies die Meldung, bevor du entscheidest, ob eine Änderung nötig ist.

Arbeite vom ersten Fehler an nach unten und führe das Prüfwerkzeug nach der Korrektur erneut aus. Ein fehlendes Anführungszeichen oder ein falsch geschlossenes Element kann dazu führen, dass späterer Code an einer Stelle zu stehen scheint, an die er nicht gehört. Dadurch können viele Folgemeldungen entstehen.

Korrigiere die Struktur in HTML

Betrachte falsch verschachtelte Elemente:

<p>Open <strong>daily</p></strong>

Das innere <strong> muss vor dem äußeren <p> geschlossen werden:

<p>Open <strong>daily</strong></p>

Gib für ein aussagekräftiges Foto ein alt-Attribut an, das seinen relevanten Inhalt beschreibt, etwa alt="Mechanic adjusting the brakes of a city bike". Ein dekoratives Bild erhält ein leeres alt="". Jede id muss außerdem innerhalb ihrer Seite eindeutig sein. Verwende eine gemeinsame Klasse, wenn mehrere Elemente denselben Stil benötigen.

Weitere nützliche Prüfpunkte sind die Dokumenttypdeklaration, ein Seitentitel, vollständige Anführungszeichen bei Attributwerten und Listeneinträge innerhalb einer Liste. Ein <div> darf nicht innerhalb eines Absatzes stehen. Der Browser schließt den Absatz vor dem div-Element, und ein späteres </p> kann zu einem verwaisten End-Tag werden. Die vom Browser korrigierte Struktur kann sich von dem Text unterscheiden, den du geschrieben hast.

Korrigiere Deklarationen in CSS

Eine Zahl und ihre CSS-Einheit gehören zusammen: Schreibe width: 100px; ohne Leerzeichen zwischen 100 und px. Die Eigenschaft für die Textfarbe heißt color. Eine unbekannte Eigenschaft wird ignoriert.

Ein fehlendes Semikolon kann auch die nächste Deklaration beeinträchtigen:

.card {
  margin: 10px
  padding: 5px;
}

Der Browser liest die beiden Zeilen als eine ungültige Deklaration. Ergänze das fehlende Semikolon nach 10px und prüfe erneut. Browser überspringen ungültige Deklarationen normalerweise, ohne auf der Seite einen Fehler anzuzeigen.

Kombiniere Codeprüfungen mit Seitenprüfungen

Eine bestandene Validierung belegt nicht, dass die Seite barrierefrei, schnell, nützlich oder sachlich korrekt ist. Probiere die Tastaturnavigation aus, untersuche das Layout in Browsern und prüfe den Inhalt selbst. Wenn das CSS-Prüfwerkzeug eine sehr neue Funktion als problematisch markiert, prüfe deren Spezifikation und die Unterstützungsinformationen auf MDN, bevor du funktionierenden Code entfernst; Prüfwerkzeuge können neueren Funktionen hinterherhinken.

Validiere nach größeren Änderungen und vor der Veröffentlichung. Gib nach dem Hochladen die veröffentlichte Adresse ein und prüfe, ob die neuesten Inhalte sichtbar sind. Eine valide ältere Seite kann die Prüfung genauso bestehen wie die aktualisierte.

Entwicklerwerkzeuge, oft DevTools genannt, zeigen, wie der Browser deine Seite interpretiert. Klicke mit der rechten Maustaste auf ein Element und wähle „Untersuchen“. Du kannst unter Windows und Linux auch F12 oder Strg+Umschalt+I und unter macOS Cmd+Wahltaste+I verwenden. Aktiviere in Safari zuerst unter „Einstellungen“, „Erweitert“ die Option „Funktionen für Webentwickler anzeigen“.

Untersuche die Struktur des Browsers

Der Bereich „Elemente“, in Firefox Inspektor genannt, zeigt das DOM: die aus dem HTML aufgebaute Struktur. Der Browser kann invaliden HTML-Quelltext korrigiert haben, sodass dies nicht immer eine direkte Kopie des Quelltexts ist. Ein innerhalb eines Absatzes geschriebenes <div> erscheint im DOM außerhalb des Absatzes, weil der Browser den Absatz zuerst beendet.

Wähle das Element mit dem Problem aus. Der Stilbereich listet passende CSS-Regeln auf und verweist auf ihre Quelldateien und Zeilennummern. Eine durchgestrichene Deklaration ist nicht aktiv. Eine andere Regel kann sich gegen sie durchsetzen oder ein Warnsymbol kann anzeigen, dass die Deklaration ungültig ist. Der Bereich „Berechnet“ zeigt die endgültigen Eigenschaftswerte, nachdem der Browser diese Regeln ausgewertet hat.

Verfolge eine unterlegene Farbregel

Angenommen, dieser Link erscheint dunkelblau, obwohl seine Schaltflächenklasse Weiß vorgibt:

<a class="btn" href="contact.html">Contact us</a>

#main a { color: navy; }
.btn { color: white; }

Beide Regeln passen, wenn sich der Link innerhalb von id="main" befindet. Der ID-Selektor macht #main a spezifischer: Seine Spezifität beträgt (1, 0, 1), gegenüber (0, 1, 0) für .btn. Bei diesen gewöhnlichen Regeln gleicht eine spätere Position von .btn diesen Unterschied nicht aus.

Eine gezielte Korrektur ist #main .btn mit der Spezifität (1, 1, 0). Eine andere besteht darin, die breit gefasste ID-Regel durch eine Linkklasse wie .nav-link zu ersetzen. Zwei Selektoren mit je einer Klasse haben dieselbe Spezifität, sodass ihre Reihenfolge über die Farbe entscheiden kann. Wenn du #main a in .main a änderst, bleibt die Spezifität (0, 1, 1), die .btn übertrifft. Untersuche die tatsächlich maßgebliche Regel, bevor du die kleinste sinnvolle Korrektur wählst.

Miss die gesamte Box

Das Boxmodell-Diagramm trennt Inhalt, Innenabstand, Rahmen und Außenabstand. Bei box-sizing: content-box ergeben eine Inhaltsbreite von 300 px, ein Innenabstand von 20 px auf jeder Seite und Rahmen von 2 px:

Das ist eine Rahmenbox von 344 px, ohne Außenabstände. Bei box-sizing: border-box bleibt die gesamte Rahmenbox 300 px breit; ihre Inhaltsbreite beträgt:

Nutze das Diagramm, um einen Abstand oder Überlauf zu erklären, statt Breiten wiederholt auf Verdacht zu ändern. Flexbox- und Grid-Symbole können ebenfalls Rasterspuren, Linien und Abstände des Layouts anzeigen.

Probiere eine Änderung aus und speichere sie

Deaktiviere im Stilbereich eine Deklaration, bearbeite einen Wert oder ergänze eine Regel. Erzwinge :hover oder :focus, um einen Zustand zu untersuchen, ohne Zeiger oder Tastatur an der betreffenden Stelle halten zu müssen. Diese Änderungen sind vorübergehend: Die gewöhnliche Bearbeitung in den Entwicklerwerkzeugen aktualisiert deine Projektdateien nicht. Übernimm die funktionierende Änderung in den Quelltext, speichere und lade neu. Verschwindet die Korrektur, wurde sie noch nicht in der Kopie gespeichert, die der Browser lädt.

Eine Seite wird aus mehreren Anfragen zusammengesetzt. Das HTML kann erfolgreich eintreffen, während ein Stylesheet oder Bild nicht geladen wird. Konsolenmeldungen und der Netzwerkbereich zeigen diese unterschiedlichen Ergebnisse.

Öffne die Werkzeuge vor dem Neuladen

Die Konsole meldet Fehler und Warnungen, darunter Skriptfehler, fehlende Ressourcen und gemischte Inhalte. Meldungen verweisen oft auf die betroffene Datei und Zeile. Auch eine Website aus HTML und CSS kann nützliche Konsolenmeldungen haben.

Der Netzwerkbereich zeichnet die Anfragen der Seite auf, solange die Entwicklerwerkzeuge geöffnet sind. Öffne sie, lade neu und filtere dann nach CSS, Bildern oder Schriftarten, um die Liste zu verkleinern. Lies die angeforderte URL, den Status, den Typ, die Größe und die Zeit. Wähle einen Eintrag aus, um seine Antwortheader und Inhalte zu untersuchen.

Ein Status im 400er-Bereich betrifft die Anfrage, einer im 500er-Bereich den Server. Ein 404 ist kein Beleg dafür, dass du das CSS-Layout ändern musst.

Verfolge ein fehlendes Logo

Auf der veröffentlichten Seite ist eine leere Bildfläche zu sehen. Im Netzwerkbereich lautet die zugehörige Anfrage https://www.example.com/images/Logo.svg und gibt 404 zurück. Die hochgeladene Datei heißt images/logo.svg. Das angefragte große L stimmt nicht mit dem tatsächlichen kleingeschriebenen Namen überein. Korrigiere den HTML-Pfad, stelle die Seite bereit und prüfe, ob die Anfrage nun erfolgreich ist.

Untersuche eine Seite ohne Gestaltung

Suche zuerst nach der CSS-Anfrage. Erscheint keine Anfrage, untersuche das <link>-Element einschließlich rel="stylesheet". Gibt die Anfrage 404 zurück, vergleiche ihre URL mit dem Speicherort der hochgeladenen Datei.

Ein 200 bedeutet nur eine erfolgreiche Antwort und bestätigt nicht, dass diese CSS enthält. Prüfe die Konsole und den Content-Type der Antwort, der text/css lauten sollte. Ein Hostinganbieter kann versehentlich eine HTML-Fehlerseite mit dem Status 200 zurückgeben; der Browser wird sie nicht als Stylesheet anwenden. Sobald das richtige CSS mit dem richtigen Typ eingetroffen ist, untersuche ungültige Deklarationen und Selektoren, die nicht zum betroffenen Element passen.

Schließe die gespeicherte Kopie des Browsers als Ursache aus

Ein Cache speichert Dateien zur erneuten Verwendung. Das spart Downloadzeit, aber eine alte Kopie kann den Eindruck erwecken, eine erfolgreiche Aktualisierung fehle. Aktiviere bei geöffneten Entwicklerwerkzeugen im Netzwerkbereich „Cache deaktivieren“ und lade neu. In Chrome, Edge und Firefox erzwingt Strg+Umschalt+R unter Windows und Linux beziehungsweise Cmd+Umschalt+R unter macOS ein vollständiges Neuladen. Untersuche den zurückgegebenen Inhalt, bevor du auf einen fehlgeschlagenen Upload schließt.

Die Spalten für Größe und Zeit helfen auch bei Geschwindigkeitsproblemen. Ein Bild mit 3,6 MB zwischen winzigen Textdateien ist ein nützlicher Ausgangspunkt. Netzwerkdrosselung simuliert eine langsamere Verbindung. Fordert eine HTTPS-Seite eine Datei mit http:// an, kann das eine Warnung zu gemischten Inhalten auslösen. Untersuche die genaue URL der Ressource, um den unsicheren Verweis zu finden.

Ein nützlicher Fehlerbericht beschreibt einen beobachtbaren Unterschied: „Bei 360 px Breite lässt sich die Kontaktseite seitlich scrollen.“ Das lässt sich leichter untersuchen als „Das Layout auf Mobilgeräten ist kaputt“. Halte Seitenadresse, Browser, Bildschirmbreite, tatsächliches Ergebnis und erwartetes Ergebnis fest.

Gehe anhand von Hinweisen in fünf Schritten vor

1. Reproduzieren. Lass das Problem unter denselben Bedingungen erneut auftreten.
2. Hinweise sammeln. Lies Konsole und Netzwerkbereich, validiere den Code und untersuche das betroffene Element.
3. Eingrenzen. Deaktiviere eine Regel oder entferne vorübergehend ein kleines Stück Code, um die Ursache einzugrenzen.
4. Eine Sache ändern. Teste, ob diese Änderung das Ergebnis erklärt.
5. Speichern und erneut testen. Übernimm die Korrektur in den Quelltext, lade neu und prüfe andere Bedingungen.

Wenn du mehrere Dinge gleichzeitig änderst, ist das Ergebnis schwer zu deuten. Eine Änderung kann das ursprüngliche Problem lösen, während eine andere ein neues verursacht. Halte den fehlschlagenden Fall verfügbar, damit du vorher und nachher vergleichen kannst.

Untersuche einen Überlauf bei schmalem Bildschirm

Eine Seite passt auf einen Laptop, lässt sich aber bei einem 360 px breiten Viewport seitlich scrollen. Öffne den responsiven Modus bei dieser Breite. Fahre im Bereich „Elemente“ mit dem Mauszeiger über Elemente und beobachte ihre hervorgehobenen Boxen. Ein Bild ist breiter als seine Spalte; sein HTML gibt eine große intrinsische Breite vor und kein CSS begrenzt sie.

Probiere diese Regel aus:

img {
  max-width: 100%;
  height: auto;
}

Durch die maximale Breite kann das Bild auf die Größe seines Containers schrumpfen. Die automatische Höhe erhält seine Proportionen. Verschwindet der Überlauf, speichere die Regel im richtigen Stylesheet und lade neu. Teste das Bild anschließend auch bei größeren Breiten. Wenn du den horizontalen Überlauf der Seite ausblendest, könnte ein Teil des Bildes verborgen werden, ohne dass es passend verkleinert wird.

Bewirkt die Änderung nichts, grenze anhand der Hinweise den nächsten Schritt ein. Erscheint die Regel im Stilbereich? Wird sie überschrieben? Hat der Browser die bearbeitete Datei geladen? Häufige Ursachen sind nicht übereinstimmende Klassennamen, falsche Pfade, fehlende Klammern oder Semikolons, nicht gespeicherte Dateien und zwischengespeicherte Kopien.

Teste Browser-Engines und Fenstergrößen

Der responsive Modus ändert die Viewport-Breite und kann Touchbedienung simulieren, bildet aber nicht jedes Detail der Geschwindigkeit, Schriftarten oder Darstellung eines echten Smartphones nach. Prüfe die Breakpoints der Medienabfragen und die Breiten dazwischen und nutze dann mindestens ein echtes Smartphone.

Chrome und Edge verwenden Blink, Firefox verwendet Gecko und Safari verwendet WebKit. Zwei Browser mit derselben Engine bieten keine so breite Testabdeckung wie Browser mit unterschiedlichen Engines. Safari ist besonders relevant für die vielen iPhone-Browser, die WebKit verwenden. Prüfe die Unterstützungsinformationen auf MDN, bevor du dich auf eine neuere Funktion verlässt.

Prüfe die veröffentlichte Version

Das Serververhalten kann Fehler sichtbar machen, die auf der Festplatte verborgen bleiben: Namen, bei denen Groß- und Kleinschreibung unterschieden wird, fehlende Uploads und Pfade, die einen Projektunterordner auslassen. Öffne die veröffentlichte Adresse, folge den Links und untersuche dort fehlgeschlagene Anfragen.

Validiere vor der Veröffentlichung HTML und CSS, untersuche Konsolenfehler, prüfe auf unbeabsichtigte 404-Fehler, probiere Smartphone-, Tablet- und Desktopbreiten aus und prüfe mindestens zwei Browser-Engines. Folge der Navigation mit der Tastatur und aktiviere Steuerelemente. Wiederhole die Prüfungen nach der Bereitstellung auf der veröffentlichten Website dort, wo die geänderte Funktion verwendet wird.

Ein optimiertes Bild ist eine kleine Datei, die bei ihrer Anzeigegröße noch gut aussieht. Beginne mit Format, Pixelmaßen und Kompression. Wenn du ein übergroßes Foto mit CSS verkleinerst, ändert sich seine Darstellung, aber der Browser lädt und dekodiert weiterhin die Originaldatei.

Wähle das Format passend zum Inhalt

Rastergrafiken speichern Pixel. Wenn du eine kleine Rastergrafik vergrößerst, wird sie unscharf, weil keine zusätzlichen Details entstehen. SVG speichert Formen und Linien und eignet sich daher für ein Logo, aber nicht für ein Kamerafoto. Aktuelle gängige Browser unterstützen WebP und AVIF. Für Animationen ergibt ein modernes Bildformat oder ein kurzes Video oft eine kleinere Datei als GIF.

Verlustfreie Kompression erhält die Pixelwerte. Verlustbehaftete Kompression entfernt einige Details, um mehr Byte zu sparen. Eine niedrigere Qualität führt irgendwann zu blockartigen Flächen oder unscharfen Kanten. Vergleiche den Export in seiner tatsächlichen Anzeigegröße. Erstelle jeden neuen Export aus dem Original und vermeide es, eine bereits komprimierte Kopie wiederholt verlustbehaftet zu speichern.

Passe die Größe an die größte Verwendung an

Ein Foto, das höchstens 800 CSS-Pixel breit angezeigt wird, benötigt auf einem Bildschirm mit Standardpixeldichte etwa 800 Bildpixel und auf einem Bildschirm mit zwei Gerätepixeln pro CSS-Pixel 1.600. Bereite geeignete Alternativen vor, statt allen Besuchern das Kameraoriginal zu senden.

Das Original der Fahrradwerkstatt hat 4.000 × 3.000 Pixel und 3,6 MB. Ein Export mit 1.600 × 1.200 Pixeln hat:

Pixel, also 16 % der ursprünglichen 12 Millionen. Ein JPEG-Export mit Qualität 80 könnte etwa 240 KB groß sein; die tatsächliche Größe hängt vom Foto ab. In diesem Beispiel werden etwa 93 % der Datei-Byte eingespart.

Bei 10 Mbit/s beträgt die ideale Übertragungszeit des Originals mit dezimalen MB:

Sekunden. Der Export mit 0,24 MB benötigt etwa 0,19 Sekunden. Das sind nur Übertragungszeiten; beim tatsächlichen Laden kommen Verzögerungen durch Verbindung und Server hinzu. Bei einer Dekodierung mit 4 Byte pro Pixel sinkt der Speicherbedarf von 48 MB auf 7,68 MB. Eine kleinere kodierte Datei und weniger dekodierte Pixel sind zwei verschiedene Vorteile.

Exportiere eine öffentliche Kopie

Nutze die Exportfunktionen eines Bildbearbeitungsprogramms oder ein Werkzeug wie Squoosh. Bewahre das Original außerhalb des veröffentlichten Ordners auf und gib den Exporten eindeutige Namen wie workshop-800.jpg und workshop-1600.jpg. Entferne beim Export Kamerametadaten; sie können das Datum des Fotos, Kameraangaben und den GPS-Standort enthalten.

Bei einer SVG-Datei entfernt ein Optimierungswerkzeug wie SVGO Reste des Zeichenprogramms. Textkompression auf dem Server kann ihre Übertragungsgröße weiter verringern. Untersuche bei jedem Format das fertige Bild: Ein als PNG gespeichertes Foto kann unnötig groß sein, während ein textreiches, als JPEG gespeichertes Logo verwaschene Kanten haben kann.

Ein Bild kann klein genug für einen schnellen Download sein und trotzdem eine Seite springen lassen. Der Browser muss seine Proportionen kennen, bevor das Bild eintrifft, und benötigt geeignete Auswahlmöglichkeiten für unterschiedliche Bildschirme.

Reserviere Platz mit Maßangaben

Schreibe numerische width- und height-Attribute ohne Einheiten:

<img src="images/workshop-800.jpg"
     width="800" height="600"
     alt="Mechanic adjusting the brakes of a city bike">

Diese Maße teilen dem Browser das Seitenverhältnis 4:3 mit. Mit max-width: 100%; height: auto; im CSS schrumpft das Bild passend zu einer schmalen Spalte. In einer 360 px breiten Spalte beträgt seine Höhe:

Pixel. Wenn dieser Platz reserviert wird, bewegt sich der darunterliegende Text beim Laden des Bildes nicht nach unten. Fehlende Maße können Layoutverschiebungen verursachen, die unerwarteten Bewegungen, die CLS misst.

Biete Breiten zur Auswahl durch den Browser an

Verwende für dasselbe Foto in zwei Größen Breitendeskriptoren und eine Beschreibung seiner Anzeigebreite:

<img src="images/workshop-800.jpg"
     srcset="images/workshop-800.jpg 800w,
             images/workshop-1600.jpg 1600w"
     sizes="(max-width: 840px) 100vw, 800px"
     width="800" height="600"
     alt="Mechanic adjusting the brakes of a city bike">

800w und 1600w geben die tatsächlichen Dateibreiten an. In diesem Layout besagt sizes, dass das Bild bis 840 px die Viewport-Breite einnimmt und darüber 800 px breit ist. Der Browser wählt anhand der deklarierten Anzeigebreite, der Pixeldichte des Bildschirms und seiner Auswahlregeln eine Datei aus. Stimme sizes auf das tatsächliche Layout ab; die Angabe, dass das Bild den gesamten Viewport ausfüllt, kann bei einer viel schmaleren Spalte zu unnötigen Downloads führen.

Biete Formate mit einem Ersatz an

<picture>
  <source srcset="images/workshop.avif" type="image/avif">
  <source srcset="images/workshop.webp" type="image/webp">
  <img src="images/workshop.jpg" width="800" height="600"
       alt="Mechanic adjusting the brakes of a city bike">
</picture>

Der Browser wählt das erste unterstützte Quellformat. Das erforderliche <img> liefert den Ersatz, die Maße und den Alternativtext. Hier geht es um die Formatauswahl; srcset mit Breitendeskriptoren löst das verwandte Problem, eine geeignete Pixelbreite auszuwählen.

Lade noch nicht benötigte Bilder verzögert

Verwende loading="lazy" für Bilder weiter unten auf einer Seite. Der Browser kann warten, bis der Besucher in ihre Nähe gelangt, und so Daten für Bilder sparen, die nie erreicht werden. Lade Bilder, die beim ersten Aufruf sichtbar sind, sofort, besonders das große Hero-Bild. Wenn dieses Bild verzögert geladen wird, verzögert sich der Inhalt, den Besucher sehen möchten. Ein Hero-Bild im HTML wird früh gefunden; fetchpriority="high" kann eine höhere Abrufpriorität dafür anfordern.

Schreibe den alt-Text passend zum Zweck des Bildes im Kontext. Ein dekoratives Bild erhält alt="". Aussagekräftige Fotos und Diagramme gehören als Bilder ins HTML; ein CSS-Hintergrund eignet sich zur Dekoration und hat weder ein alt-Attribut noch ein natives loading-Attribut.

Die Seitengröße ist die gesamte Datenmenge, die für eine Seite heruntergeladen wird. Das HTML führt zu Anfragen für CSS, Bilder, Skripte und Schriftarten. Dateigrößen, Anzahl der Anfragen, Verbindungsgeschwindigkeit und Geräteleistung tragen alle zum Nutzungserlebnis bei.

Finde den größten Anteil

Die Startseite der Fahrradwerkstatt lädt 15 KB HTML, 30 KB CSS, zwei Schriftdateien mit je 40 KB, ein Hero-Bild mit 2.400 KB und drei Fotos mit je 350 KB herunter:

KB. Auf Bilder entfallen 3.450 KB, etwa 96,5 %. Mit einem Hero-Bild von 220 KB und drei Fotos mit je 45 KB ergibt sich insgesamt:

KB, etwa 87 % weniger. Bei 10 Mbit/s sinkt die ideale Übertragungszeit von etwa 2,86 Sekunden auf 0,38 Sekunden. Serverantwort und Verbindungsaufbau benötigen zusätzliche Zeit. Das Entfernen einiger Leerzeichen aus CSS hätte neben dieser Einsparung bei Bildern wenig Wirkung.

Lies die Kennzahlen zum Nutzungserlebnis

Die Core Web Vitals messen, Stand Oktober 2026, verschiedene Probleme:

Für eine gute Leistung unter realen Bedingungen muss jede Kennzahl am 75. Perzentil ihren Schwellenwert einhalten. CLS kann auch ein Banner erfassen, das Inhalte nach dem Laden verschiebt, nicht nur ein Bild, das während des ersten Ladens eintrifft.

Lighthouse in Chrome oder Edge führt einen Labortest mit Bewertungen und Verbesserungsvorschlägen durch. PageSpeed Insights führt Tests online aus und zeigt, wenn genügend Beobachtungen vorliegen, Felddaten aus echten Chrome-Besuchen. Eine Laborbewertung ist ein einzelner Test unter gewählten Bedingungen. Wiederhole Vergleiche mit denselben Einstellungen und betrachte, sofern verfügbar, echte Besuche.

Verbessere zuerst die größten Kostenfaktoren

Bereite zuerst Bilder und den zugehörigen HTML-Quelltext vor. Reduziere dann unnötige Schriftfamilien und Schriftschnitte, nutze WOFF2-Schriftarten und verwende font-display: swap, damit Text in einer Ersatzschrift erscheint, während die Schrift lädt. Ergänze bei geeigneten externen Skripten defer, damit der Download das Parsen des HTML nicht blockiert und die Ausführung auf das Parsen folgt. Große Karten, Videoplayer und andere Einbettungen von Drittanbietern können bei Bedarf geladen werden.

Minifizierung entfernt Leerzeichen und Kommentare aus Code. Kompression mit gzip oder Brotli verringert die übertragenen Text-Byte. Das hilft, aber bereits komprimierte JPEG-, WebP- und AVIF-Bilder profitieren kaum von einer weiteren Kompression wie bei Text.

Caching ermöglicht wiederkehrenden Besuchern, Dateien erneut zu verwenden; es wird über Header wie Cache-Control gesteuert. Ein CDN hält Kopien in verschiedenen Regionen bereit, um den Weg der Anfragen zu verkürzen. Ändert sich eine lange zwischengespeicherte Ressource, sorgt ein Name wie styles-v2.css oder eine Adresse wie styles.css?v=2 für eine neue Anfrage. Teste mit Netzwerkdrosselung und auf einem Smartphone; ein schneller Laptop im WLAN kann ein langsames Nutzungserlebnis auf Mobilgeräten verbergen.

Jede Seite sollte ihren eigenen Zweck in ihrem HTML erklären. Suchmaschinen lesen diesen HTML-Quelltext; auch Browser-Tabs, Lesezeichen und Screenreader sind davon abhängig. Eine klare Struktur beginnt bei den Inhalten, die Besucher tatsächlich lesen können.

Benenne die Seite im head-Element

Das <title>-Element gehört in <head>. Gib jeder Seite einen eigenen aussagekräftigen Titel, mit dem Namen der Website nach dem konkreten Thema:

<title>Repair Prices – Riverside Bike Repair</title>
<meta name="description"
      content="Prices for flat repairs, brake adjustments and full services at Riverside Bike Repair. Walk in Monday to Saturday or book online.">

Der Titel erscheint im Browser-Tab und in Lesezeichen und bildet meist die Überschrift in Suchergebnissen. HTML legt keine Längenbegrenzung für Titel fest, aber Suchanzeigen schneiden Text passend zur verfügbaren Breite ab. Setze deshalb die aussagekräftigen Wörter an den Anfang. Ein allgemeiner Titel wie „Startseite“ liefert wenig Information, wenn er losgelöst von der Website erscheint.

Die Meta-Beschreibung ist eine gut lesbare Zusammenfassung der Seite in einem oder zwei Sätzen. Suchmaschinen können sie für den Textausschnitt eines Ergebnisses verwenden, aber auch Seitentext auswählen. Stimme die Beschreibung auf den Inhalt der jeweiligen Seite ab. Wenn du eine Beschreibung auf jede Seite kopierst, verbirgt das die Unterschiede zwischen ihnen; eine Liste wiederholter Schlüsselwörter ist keine nützliche Zusammenfassung. Google ignoriert das alte keywords-Meta-Tag.

Deklariere Sprache und Zeichen

Verwende <html lang="en"> für eine englischsprachige Seite. Das hilft Screenreadern bei der Wahl der Aussprache und Browsern bei Sprachfunktionen. Google erkennt die Sprache anhand des sichtbaren Textes und ignoriert dieses Attribut. Betrachte es daher nicht als Spracheinstellung für Google.

Setze <meta charset="utf-8"> weit vorn in das head-Element, damit Zeichen wie é und ein Halbgeviertstrich korrekt angezeigt werden. Ergänze das Viewport-Meta-Tag für responsive Seiten:

<meta name="viewport" content="width=device-width, initial-scale=1">

Stimme die Gliederung auf die Inhalte ab

Verwende ein eindeutiges <h1> für das Hauptthema der Seite, <h2> für ihre Hauptabschnitte und <h3> für Unterabschnitte. Auf der Preisseite ist „Services“ eine h2-Überschrift, darunter stehen „Basic service“ und „Full service“ als h3-Überschriften. Wähle Überschriftenebenen nach dieser Beziehung und passe ihre sichtbare Größe mit CSS an.

Semantische Elemente kennzeichnen Aufgaben: <nav> für die Navigation, <main> für den Hauptinhalt und passende <header>-, <article>-, <section>- und <footer>-Elemente. Verwende echte Listen, Links zur Navigation und Schaltflächen für Aktionen. Eine Seite aus allgemeinen div-Elementen verliert diese Signale über die Aufgaben der Bereiche. Belasse wichtige Wörter wie Preise, Öffnungszeiten und Überschriften als HTML-Text, wo sie Besuchern und Werkzeugen als Text zur Verfügung stehen.

Richte eine nützliche Vorschau für geteilte Links ein

Open Graph-Tags beschreiben eine Linkvorschau in sozialen Netzwerken und Chat-Apps. Gängige Eigenschaften sind og:title, og:description und og:image:

<meta property="og:title" content="Repair Prices">
<meta property="og:image"
      content="https://www.example.com/images/workshop-800.jpg">

Verwende für das Vorschaubild eine vollständige HTTPS-URL. Diese Tags beschreiben die geteilte Karte; sie ersetzen weder die sichtbaren Seitenüberschriften noch den gewöhnlichen Titel und die Beschreibung der Seite.

Crawling ist das Abrufen von Seiten, oft durch das Folgen von Links. Indexierung ist das Speichern von Informationen über diese Seiten für Suchergebnisse.

Sorge dafür, dass jede Seite erreichbar ist

Verlinke jede Seite von mindestens einer anderen Seite aus mit einem gewöhnlichen <a href>-Link. Aussagekräftiger Text wie „Reparaturpreise“ sagt Besuchern und Crawlern, was die Zielseite enthält. Ein lesbarer Pfad wie /blog/winter-checklist.html liefert mehr Kontext als /page7.html.

Eine Sitemap listet die vollständigen bevorzugten URLs auf, die gefunden werden sollen. Ein XML-Eintrag kann so aussehen:

<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://www.example.com/prices.html</loc>
    <lastmod>2026-10-01</lastmod>
  </url>
</urlset>

Das optionale Datum der letzten Änderung sollte eine wesentliche Änderung angeben. Aktualisiere die Sitemap, wenn sich Seiten ändern. Eine kleine, gut verlinkte Website kann auch ohne Sitemap gefunden werden.

Halte die Steuerung von Crawling und Indexierung auseinander

Eine robots.txt-Datei im Wurzelverzeichnis der Domain teilt Crawlern, die sich an die Vorgaben halten, mit, welche Pfade sie nicht abrufen sollen:

User-agent: *
Disallow: /drafts/
Sitemap: https://www.example.com/sitemap.xml

Das sperrt den Ordner nicht. Menschen können seine Adressen öffnen, und eine blockierte URL kann weiterhin in Ergebnissen erscheinen, wenn andere Seiten darauf verlinken. Ohne robots.txt-Datei dürfen Crawler Seiten abrufen. Ein kopiertes Disallow: / blockiert das Crawling auf der gesamten Website. Entferne daher vor der Veröffentlichung eine Sperre von der Testwebsite, wenn die Website gecrawlt werden soll.

Um den Ausschluss aus Suchergebnissen anzufordern, setze Folgendes in das head-Element der Seite:

<meta name="robots" content="noindex">

Der Crawler muss die Seite abrufen, um diese Anweisung zu lesen. Wenn du dieselbe URL in robots.txt blockierst, kann er noindex möglicherweise nicht entdecken. Keine der beiden Einstellungen macht eine Seite privat: Private Inhalte benötigen eine Zugriffskontrolle oder müssen von der öffentlichen Website fernbleiben.

Wähle eine Adresse für doppelte Inhalte

Eine Seite kann unter HTTP- und HTTPS-Adressen, mit und ohne www oder sowohl unter /blog/ als auch unter /blog/index.html erreichbar sein. Ein kanonischer Link kennzeichnet die bevorzugte Adresse:

<link rel="canonical" href="https://www.example.com/blog/">

Verwende die vollständige absolute URL. Die kanonische Angabe ist ein starker Hinweis; eine Weiterleitung, die Besucher tatsächlich zur bevorzugten Adresse sendet, ist ein stärkeres Signal. Stimme interne Links und Sitemap-URLs auf diese bevorzugte Adresse ab, um widersprüchliche Signale zu vermeiden.

Prüfe, was Suchmaschinen sehen können

Google Search Console und Bing Webmaster Tools nehmen Sitemaps entgegen und zeigen Probleme bei Indexierung und Crawling, nachdem du die Kontrolle über die Website bestätigt hast. Eine Suche nach site:example.com gibt einen groben Überblick über indexierte Seiten. Neue Websites erscheinen möglicherweise erst nach Tagen oder Wochen. Weder eine Sitemap noch sauberer HTML-Quelltext oder eine Zahlung können eine hohe Platzierung garantieren; diese Werkzeuge helfen dir, technische Hindernisse zu finden und zu verstehen, was verarbeitet wurde.

Eine statische Website liefert vorbereitete HTML-, CSS-, Bild- und Skriptdateien aus. Ihr Inhalt kann immer dann aktualisiert werden, wenn du neue Dateien veröffentlichst; „statisch“ beschreibt, wie der Hostinganbieter sie ausliefert. Der Hostingserver liefert sie weiter aus, wenn dein eigener Computer ausgeschaltet ist.

Erfahre, was der Hostinganbieter bereitstellt

Eine dynamische Website erstellt Antworten auf dem Server, oft aus einer Datenbank. Eine kleine Informationswebsite oder ein mit HTML und CSS erstelltes Portfolio kann statisches Hosting ohne serverseitige Programmierung nutzen. Der HTML-Quelltext eines Kontaktformulars allein schafft noch keinen Dienst, der Einsendungen speichert oder per E-Mail versendet. Dafür ist eine Formularverarbeitung durch den Hostinganbieter oder ein separater Dienst nötig.

Anbieter für statisches Hosting stellen gewöhnlich eine vorläufige Adresse, Veröffentlichungsfunktionen und HTTPS bereit. Viele liefern Dateien über ein Content Delivery Network aus, das regionale Kopien vorhält. GitHub Pages, Netlify, Cloudflare Pages und Vercel sind Beispiele mit unterschiedlichen Tarifbedingungen und Arbeitsabläufen. Shared Hosting ist eine weitere Möglichkeit und unterstützt oft die sichere Dateiübertragung.

Eine statische Seite kann weiterhin JavaScript im Browser des Besuchers ausführen, etwa für die Bedienung eines Menüs. Der Hostinganbieter liefert weiterhin eine vorbereitete Skriptdatei aus. Da auf dem Server weder Anwendungscode der Website noch eine Datenbank läuft, gibt es weniger Anwendungskomponenten, die angegriffen werden können; das Hostingkonto und die öffentlichen Dateien müssen trotzdem geschützt werden.

Eine GitHub-Pages-Benutzerwebsite nutzt die Stammadresse https://username.github.io/ aus einem Repository namens username.github.io. Eine Projektwebsite nutzt einen Unterordner wie /riverside-bikes/. Diese Adressstruktur ist beim Testen wurzelrelativer Asset-Pfade wichtig.

Vergleiche den Bedarf mit dem aktuellen Tarif

Lies vor der Auswahl die Grenzen und Bedingungen des Tarifs. Prüfe:

• Speicherplatz und monatlich erlaubte Datenübertragung.
• Ob der Tarif kommerzielle Nutzung erlaubt.
• Unterstützung eigener Domains und automatisches HTTPS.
• Eine Veröffentlichungsmethode, die du zuverlässig nutzen kannst.
• Eigene Fehlerseiten, Weiterleitungen und Wiederherstellung früherer Bereitstellungen.
• Formularverarbeitung, falls Besucher Informationen übermitteln müssen.
• Wie leicht du deine Dateien zu einem anderen Hostinganbieter mitnehmen kannst.

Das sechsseitige Portfolio eines Fotografen mit 40 vorbereiteten Fotos passt von der Größe her in viele kostenlose statische Tarife. Wenn es jedoch bezahlte Aufträge einbringt, ist auch sein kommerzieller Zweck relevant. Die Größe allein belegt nicht, dass ein kostenloser Tarif es erlaubt. Bedingungen ändern sich. Prüfe daher den tatsächlichen Dienst und Tarif, statt dich auf einen alten Vergleich zu verlassen.

Wähle einen handhabbaren Veröffentlichungsweg

Die Veröffentlichung per Ziehen und Ablegen kann für ein kleines Projekt geeignet sein: Du lädst den Ordner über die Oberfläche des Hostinganbieters hoch. Eine Repository-Anbindung veröffentlicht aus einer ausgewählten gespeicherten Codequelle und kann Aktualisierungen bereitstellen, wenn Änderungen per Push übertragen werden. Kommandozeilenwerkzeuge bieten einen weiteren Weg. Shared Hosting unterstützt oft SFTP, eine verschlüsselte Methode zur Dateiübertragung. Einfaches FTP legt Zugangsdaten und Dateien während der Übertragung offen; nutze daher einen sicheren Weg.

Bei GitHub Pages im kostenlosen Tarif ist die Veröffentlichung aus öffentlichen Repositorys möglich. Jeder kann die Repository-Dateien lesen. Veröffentlichte Assets sind ebenfalls öffentlich, selbst wenn die Navigation nicht auf sie verweist. Beschränke den Upload auf die vorgesehenen öffentlichen Dateien und schütze das Hostingkonto mit Zwei-Faktor-Authentifizierung.

Prüfe eine Funktion in ihrem tatsächlichen Ablauf

Enthält die Website ein Kontaktformular, finde den Formularendpunkt oder die Funktion des Hostinganbieters, die dessen Daten entgegennimmt. Prüfe, ob der Tarif diese Funktion enthält, und sende nach der Veröffentlichung eine Testeinsendung. Ein Formular, das vollständig aussieht, kann trotzdem kein Ziel für seine Daten haben. Wenn eine eigene 404-Seite oder dauerhafte Weiterleitung wichtig ist, prüfe die genaue Einrichtung beim Hostinganbieter, bevor du dich darauf verlässt.

Bereitstellen bedeutet, die aktuellen Website-Dateien bei einem Hostinganbieter zu veröffentlichen. Das Veröffentlichungsverzeichnis wird online zum Wurzelverzeichnis der Website. Für reines HTML und CSS gibt es keinen Build-Schritt: Wähle den Ordner mit der fertigen index.html und den zugehörigen Assets.

Veröffentliche die erste Version

Bei einem Hostinganbieter mit Ziehen und Ablegen:

1. Öffne den Ordner, den du veröffentlichen möchtest, und prüfe, ob index.html direkt darin liegt.
2. Validiere die Seiten und teste ihre Links und ihr Layout über einen lokalen Server.
3. Lade diesen Ordner über die Veröffentlichungsoberfläche des Hostinganbieters hoch.
4. Warte, bis der Hostinganbieter meldet, dass die Bereitstellung veröffentlicht ist.
5. Öffne die bereitgestellte Webadresse und prüfe die Website dort.

Erscheint die Startseite nur unter /riverside-bikes/index.html, hast du möglicherweise den übergeordneten Ordner eine Ebene zu hoch hochgeladen. Das vorgesehene Veröffentlichungsverzeichnis ist riverside-bikes/, nicht der Ordner, der es enthält. Korrigiere die Verzeichnisauswahl und veröffentliche erneut; wenn du Besucher lediglich zur verschachtelten Adresse verlinkst, bleibt die Startadresse ohne weiteren Pfad fehlerhaft.

Veröffentliche aus einem Repository

Öffne bei GitHub Pages die Einstellungen des Repositorys und dort „Pages“. Wähle „Deploy from a branch“, dann den Branch und den Veröffentlichungsordner, entweder dessen Wurzelverzeichnis oder /docs, und speichere. Wenn eine neue Version per Push an diese Veröffentlichungsquelle übertragen wird, stellt Pages sie erneut bereit. Prüfe nach Abschluss der Bereitstellung die angezeigte Pages-Adresse. Eine Projekt-URL kann den Repository-Namen enthalten, teste die Pfade daher an diesem tatsächlichen Ort.

Andere Hostinganbieter haben eigene Einstellungen für die Repository-Anbindung und das Verzeichnis. Füge bei einer Website aus einfachen Dateien keinen Build-Befehl hinzu, nur weil die Oberfläche ein Feld dafür anbietet.

Prüfe die ausgelieferte Version

Öffne jede Seite, folge internen Links und suche in Konsole und Netzwerkbereich nach fehlgeschlagenen Ressourcen. Erzwinge ein vollständiges Neuladen, damit du zwischengespeicherte Dateien nicht mit der neuen Version verwechselst. Probiere die Website auf einem echten Smartphone aus. Prüfe die sichtbare Änderung, die du veröffentlichen wolltest, und nicht nur, ob eine Fehlermeldung ausbleibt.

Richte eine eigene 404.html ein, wo der Hostinganbieter dies unterstützt. Sie sollte Besuchern mitteilen, dass die Adresse nicht gefunden wurde, und einen hilfreichen Weg zur Startseite bieten. Prüfe anhand einer erfundenen, fehlenden Adresse, ob der Anbieter sie tatsächlich verwendet. Eine hilfreiche Fehlerseite ersetzt keine Weiterleitung, wenn der Inhalt verschoben wurde.

Bewahre eine wiederherstellbare Quelle auf

Das lokale Projekt oder das verbundene Repository ist die maßgebliche Quelle: die Kopie, aus der künftige Versionen erstellt werden. Eine schnelle Korrektur im Webeditor eines Hostinganbieters kann beim nächsten Upload verschwinden, wenn du sie nicht auch in diese Quelle übernimmst.

Nutze eine Vorschaubereitstellung, falls verfügbar, um eine Aktualisierung zu testen, bevor Besucher sie erhalten. Macht eine Aktualisierung die veröffentlichte Website unbrauchbar, kann ein Rollback des Hostinganbieters eine frühere Bereitstellung wiederherstellen. Korrigiere dann auch die Quelle, sonst kann die nächste Version den Fehler erneut einführen.

Wenn sich die Adresse einer Seite ändert, richte über die Weiterleitungsregeln des Hostinganbieters eine dauerhafte 301-Weiterleitung von der alten URL zur neuen ein. Teste die alte Adresse nach der Veröffentlichung: Sie sollte zur gewünschten neuen Seite führen. Bei Netlify ist eine _redirects-Datei eine Möglichkeit zur Einrichtung; andere Hostinganbieter verwenden andere Einstellungen.

Ein Domainname ist ein lesbarer Name wie example.com. DNS verknüpft diesen Namen mit Informationen wie der IP-Adresse eines Hosts. Die Registrierung gibt dir das Recht, den Namen für einen Zeitraum zu nutzen; sie ist kein dauerhafter Kauf.

Lies eine Webadresse

In https://www.example.com/prices.html ist https das URL-Schema, www.example.com der Hostname und /prices.html der Pfad. Lies die DNS-Labels von rechts nach links: .com ist die Top-Level-Domain oder TLD; example ist der darunter registrierte Name; www ist eine Subdomain.

Zu den generischen TLDs gehören .com, .org, .net, .dev, .shop und .studio. Länderspezifische TLDs bestehen aus zwei Buchstaben, etwa .de, .fr, .jp, .ca und .au. Manche Namen werden unter einer Kategorie zweiter Ebene registriert, etwa .co.uk.

Für manche Endungen gelten Zulassungsvoraussetzungen. .ca verlangt einen Bezug zu Kanada; .eu akzeptiert berechtigte Staatsangehörige, Einwohner und niedergelassene Organisationen der EU oder des EWR; .us verlangt einen Bezug zu den USA. Prüfe die Regeln der Registry, bevor du eine eingeschränkte Endung wählst. Die Endungen .dev und .app setzen in Browsern HTTPS voraus.

Erfahre, wer die Registrierung übernimmt

Ein Registrar meldet deine Registrierung bei der Registry, die die TLD betreibt. ICANN koordiniert das System der generischen TLDs und akkreditiert deren Registrare; länderspezifische Registrys legen ihre eigenen Regeln fest. Registrierungen laufen gewöhnlich ein bis zehn Jahre und müssen verlängert werden.

Wähle einen Namen, der kurz, leicht auszusprechen und zu schreiben ist und dem Projekt- oder Unternehmensnamen nahesteht. Vermeide verwirrende Zahlen und Bindestriche und prüfe, ob der Name eine fremde Marke verwendet. Ist ein gewünschter .com-Name vergeben, vergleiche einen klaren längeren Namen, eine geeignete lokale Endung oder eine passende generische Endung. Die Verfügbarkeit allein erlaubt nicht, den Namen eines anderen Unternehmens zu verwenden.

Vergleiche die laufenden Verpflichtungen

Prüfe neben dem Angebot für das erste Jahr auch den Verlängerungspreis. Für Zusatzdienste, darunter E-Mail, können gesonderte Gebühren anfallen. Domain und Website-Hosting können von verschiedenen Unternehmen stammen; die Registrierung einer Domain lädt für sich genommen keine Website hoch.

Gib korrekte Eigentümer- und Kontaktangaben an und reagiere auf die Bestätigungs-E-Mail des Registrars. Unbestätigte Kontaktdaten können zu einer Sperrung führen. Für Registrierungsinformationen generischer TLDs wurde RDAP im Januar 2025 zum maßgeblichen öffentlichen Abfrageweg und ersetzte die bisherigen Anforderungen an den WHOIS-Dienst. Bei öffentlichen Abfragen werden persönliche Angaben gewöhnlich verborgen; der Registrar benötigt dennoch korrekte Daten.

Belasse die Kontrolle beim Eigentümer

Der Eigentümer des Projekts oder Unternehmens sollte das Konto des Domaininhabers kontrollieren, auch wenn ein Designer die Website erstellt. Aktiviere Zwei-Faktor-Authentifizierung und halte die Angaben zur Kontowiederherstellung aktuell. Um den Registrar zu wechseln, befolge das Transferverfahren; dazu gehören ein Transfercode und das Entsperren der Domain, sofern der Transfer zulässig ist.

Notiere das Ablaufdatum, aktiviere die Verlängerung und halte das Zahlungsmittel gültig. Eine abgelaufene Registrierung kann die Website und die Domain-E-Mail unterbrechen; nach den geltenden Nachfristen und Löschungsfristen kann eine andere Person den Namen registrieren. Sicherungskopien beim Hostinganbieter können eine ausgelaufene Domainregistrierung nicht erhalten.

Das Domain Name System, kurz DNS, speichert Einträge für Namen. Ein Resolver fragt diese Einträge ab und hält eine Antwort oft im Cache. Die autoritativen Nameserver sind die Server, die für die DNS-Informationen der Domain zuständig sind. Nimm Änderungen bei dem Anbieter vor, dessen Nameserver die Domain tatsächlich bedienen.

Wähle den Eintragstyp

Die IP-Adressen und der .example-Name hier sind Werte für Dokumentationszwecke. Verwende für eine echte Verbindung die Werte, die dein Hostinganbieter für deine Website vorgibt.

Die Apex-Domain ist der registrierte Wurzelname, etwa example.com. Standard-DNS erlaubt dort keinen CNAME, weil die Apex-Domain auch andere Einträge benötigt, darunter NS. Verwende die A- und AAAA-Werte des Hostinganbieters oder eine vom Anbieter unterstützte ALIAS-, ANAME- oder CNAME-Flattening-Funktion. Eine Subdomain wie www verwendet häufig einen CNAME.

Verbinde zwei Formen einer Adresse

Angenommen, ein Hostinganbieter verlangt einen A-Eintrag für die Apex-Domain und einen CNAME für www. Ein Anbieter, der @ für die Apex-Domain verwendet, könnte Folgendes anzeigen:

Type    Name    Value                           TTL
A       @       192.0.2.44                       3600
CNAME   www     riverside-bikes.pages.example    3600

Trage die eigene Domain auch in den Hosting-Einstellungen ein. Der Hostinganbieter muss den angefragten Namen erkennen und der Website zuordnen. Wähle die Hauptadresse und richte für die andere Form eine Weiterleitung dorthin ein.

Lies die Anweisungen des Anbieters zum Namensfeld. Wenn er automatisch example.com ergänzt, kann die Eingabe von www.example.com zu www.example.com.example.com führen. Entferne beim Wechsel des Hostinganbieters veraltete Adresseinträge; bleiben alte und neue Werte bestehen, können Besucher zu unterschiedlichen Servern gelangen.

Lass zwischengespeicherte Antworten ablaufen

Die TTL, Time to Live, gibt an, wie viele Sekunden eine DNS-Antwort zwischengespeichert werden darf. Eine TTL von 3.600 entspricht einer Stunde; 86.400 entspricht 24 Stunden. Nach einer Aktualisierung können verschiedene Besucher vorübergehend unterschiedliche Antworten erhalten. Es kann 24 Stunden oder länger dauern, bis Änderungen überall sichtbar sind.

Senke bei einem geplanten Umzug die TTL mindestens eine alte TTL-Periode vor der Umstellung auf 300 Sekunden. Eine Senkung zum Zeitpunkt der Umstellung kann die Lebensdauer einer bereits unter der alten TTL zwischengespeicherten Antwort nicht verkürzen.

Ziehe DNS um, ohne andere Dienste zu verlieren

Du kannst DNS beim Registrar belassen und Einträge bearbeiten oder die Nameserver zu einem neuen Anbieter ändern. Ein Nameserverwechsel kopiert keine Einträge. Erstelle und prüfe die benötigten MX-, TXT- und sonstigen Einträge vor der Umstellung beim neuen Anbieter erneut, besonders wenn Domain-E-Mail bereits funktioniert.

Prüfe Antworten mit nslookup www.example.com, dig example.com A +short oder einem DNS-Abfragedienst und vergleiche sie mit den Einstellungen des Hostinganbieters. Ergänze Wildcard-Einträge nur bewusst und dort, wo der Hostinganbieter sie unterstützt. Entferne beim Löschen einer gehosteten Website auch DNS-Einträge, die auf sie verweisen; ein vergessener Alias kann es einer anderen Person ermöglichen, das aufgegebene Hostingziel zu beanspruchen.

HTTPS überträgt HTTP über eine verschlüsselte TLS-Verbindung. Es schützt Vertraulichkeit und Integrität der übertragenen Daten und ermöglicht dem Browser, den Server für die angefragte Domain zu authentifizieren. Einfaches HTTP legt Daten gegenüber Personen offen, die die Verbindung beobachten können.

Ein Zertifikat identifiziert die Domain

Ein TLS-Zertifikat bindet einen Domainnamen an einen öffentlichen Schlüssel und ist von einer vertrauenswürdigen Zertifizierungsstelle, kurz CA, signiert. Es listet die abgedeckten Namen und sein Ablaufdatum auf. Wenn Besucher sowohl example.com als auch www.example.com verwenden, muss das Zertifikat beide Namen abdecken, selbst wenn einer auf den anderen weiterleitet: Der Browser stellt die sichere Verbindung her, bevor er diese Weiterleitung erhält.

Eine HTTPS-Verbindung sagt nichts über die Ehrlichkeit eines Unternehmens aus. Eine betrügerische Website kann ein Zertifikat für einen Namen erhalten, den sie kontrolliert. Der Schutz der Verbindung und die Vertrauenswürdigkeit der Website sind getrennte Fragen.

Lass den Hostinganbieter das Zertifikat ausstellen und erneuern

Viele Anbieter für statisches Hosting beantragen automatisch ein kostenloses Zertifikat, oft bei Let's Encrypt, sobald DNS auf den Hostinganbieter verweist und die Domain eingerichtet ist. Die Zertifizierungsstelle prüft die Kontrolle über den Namen, etwa anhand eines DNS-Eintrags oder einer über das Web abgerufenen Datei. Die Ausstellung kann wenige Minuten bis etwa einen Tag dauern.

Stand Oktober 2026 haben neu ausgestellte öffentlich vertrauenswürdige TLS-Serverzertifikate nach den seit dem 15. März 2026 geltenden Regeln eine maximale Laufzeit von 200 Tagen. Das Maximum sinkt im März 2027 auf 100 Tage und im März 2029 auf 47 Tage. Die klassischen Standardzertifikate von Let's Encrypt gelten derzeit 90 Tage; kürzere Profile sind ebenfalls verfügbar. Durch die automatische Erneuerung muss diese Arbeit nicht wiederholt manuell erledigt werden.

Ein Beispiel für 90 Tage: Ein am 1. März 2026 ausgestelltes Zertifikat läuft am 30. Mai ab. Eine Erneuerung bei 30 verbleibenden Tagen würde um den 30. April erfolgen. Das tatsächliche Ablaufdatum und der Erneuerungsstatus sind beim Hostinganbieter oder in den Zertifikatsdetails verfügbar; geh nicht davon aus, dass ein Zertifikat aktuell ist, nur weil die Domainregistrierung funktioniert.

Leite auf HTTPS um und korrigiere unsichere Assets

Aktiviere beim Hostinganbieter das Erzwingen von HTTPS. Es leitet http://-Anfragen auf die HTTPS-Adresse um, gewöhnlich mit Status 301 oder 308. Wähle außerdem einen Haupthostnamen mit oder ohne www und leite den anderen darauf um.

Gemischte Inhalte entstehen, wenn eine HTTPS-Seite eine Ressource über http:// anfordert. Browser blockieren unsichere Skripte, Stylesheets, Frames und Schriftarten. Bei manchen Medienanfragen versuchen sie, diese auf HTTPS umzustellen. Das schlägt fehl, wenn die Quelle kein HTTPS bereitstellen kann. Prüfe Konsolenmeldungen und durchsuche den Code nach http://. Verwende relative Pfade für eigene Dateien und funktionierende HTTPS-URLs für externe Ressourcen.

HSTS, HTTP Strict Transport Security, weist Browser an, für einen festgelegten Zeitraum HTTPS zu verwenden. Aktiviere es, wenn HTTPS zuverlässig funktioniert; Browser, die die Richtlinie erhalten haben, fallen während dieses Zeitraums nicht auf einfaches HTTP zurück. Für die Endungen .dev und .app ist die ausschließliche HTTPS-Nutzung vorab festgelegt.

Erscheint nach dem Verbinden einer Domain eine Zertifikatswarnung, prüfe DNS, Ausstellungsstatus und abgedeckte Namen. Die Domain ohne Zusatz kann funktionieren, während www fehlschlägt, wenn nur der Name ohne Zusatz abgedeckt ist. Korrigiere die Konfiguration und warte gegebenenfalls auf die Ausstellung; Besucher sollten eine Zertifikatswarnung nicht umgehen.

Eine veröffentlichte Website verändert sich auch dann, wenn ihre Dateien unverändert bleiben. Externe Links ändern ihr Ziel, Kontaktdaten veralten, Domains nähern sich ihrem Ablaufdatum und Widgets von Drittanbietern ändern sich. Wartung hält den Inhalt korrekt und die Auslieferung zuverlässig.

Gehe bei jeder Aktualisierung gleich vor

Bearbeite das lokale Projekt oder Repository, teste im Browser, validiere den betroffenen Code, stelle ihn bereit und prüfe die veröffentlichten Seiten. Erstelle eine Vorschau, wenn der Hostinganbieter sie unterstützt. Prüfe eine erfolgreiche Korrektur in der Kopie, die für künftige Versionen verwendet wird, damit sie beim nächsten Upload nicht verloren gehen kann.

Eine Inhaltsänderung verdient auch eine Inhaltsprüfung. Vergleiche Daten, Öffnungszeiten, Preise und Kontaktdaten mit ihrer aktuellen Quelle. Weise Seiten einen Verantwortlichen oder ein Prüfdatum zu. Entferne oder ersetze Informationen, die das Angebot nicht mehr zutreffend beschreiben; ein alter Veranstaltungshinweis kann Besucher irreführen, selbst wenn jedes Tag valide ist.

Prüfe Links und Aufgaben der Besucher

Linkverfall ist das allmähliche Ausfallen von Links, wenn Zielseiten verschoben werden oder verschwinden. Nutze einen Linkprüfer wie den W3C Link Checker und überprüfe und repariere anschließend die gemeldeten Fehler. Wenn deine eigene Seite verschoben wurde, erhält eine Weiterleitung alte eingehende Links. Aktualisiere bei einer externen Seite das Ziel oder entferne den Link, wenn es keinen nützlichen Ersatz gibt.

Probiere tatsächliche Aufgaben von Besuchern aus. Sende einen Test über das Kontaktformular und prüfe, ob er ankommt. Folge der Navigation mit einer Tastatur. Teste ein Smartphone-Layout. Eine Verfügbarkeitsprüfung, die eine Seite erhält, kann nicht belegen, dass ein Formular oder die Navigation funktioniert.

Bewahre wiederherstellbare Kopien auf

Sichere den Quelltext und benötigte Assets an mindestens zwei Orten, etwa auf einem Computer und zusätzlich auf einem externen Laufwerk, in einem Cloudspeicher oder in einem Repository. Ein Problem mit dem Hostingkonto oder eine versehentliche Bereitstellung kann die veröffentlichte Kopie entfernen. Der Anbieter der veröffentlichten Website ist daher nicht deine einzige Sicherungskopie. Eine Versionshistorie kann frühere Versionen wiederherstellbar machen. Bewahre genügend Informationen auf, um die Domain erneut zu verbinden und die Website wieder zu veröffentlichen.

Sichere Verlängerungen und Kontozugriff

Aktiviere die automatische Domainverlängerung und halte das Zahlungsmittel gültig. Prüfe das Ablaufdatum und Bestätigungsmeldungen. Stelle sicher, dass Registrar- und Hostingkonten Zwei-Faktor-Authentifizierung und aktuelle Angaben zur Kontowiederherstellung nutzen. Auch die Zertifikatserneuerung hängt von einer funktionierenden Domainkonfiguration ab. Prüfe daher HTTPS nach DNS-Änderungen.

Ein Verfügbarkeitsmonitor prüft die Website wiederholt und warnt dich, wenn sie nicht mehr antwortet. Webmaster-Tools können Crawling-Fehler und 404-Fehler durch alte Adressen aufdecken. Sieh dir diese Berichte an und untersuche dann das zugrunde liegende Problem, statt bei jeder Warnung dieselbe Ursache anzunehmen.

Plane Arbeiten nach Art der Änderung

Schriftarten, Skripte, Karten und andere Einbettungen von Drittanbietern können unabhängig von deiner Website langsamer werden, sich ändern oder verschwinden. Halte ihre Anzahl gering und prüfe, ob sie noch benötigt werden. Wo eine Lizenz es erlaubt, kann die eigene Bereitstellung einer lokalen Kopie eines Assets die Abhängigkeit von einem anderen Server verringern. Prüfe beim Ersetzen erneut die Lizenz und ob Aktualisierungen nötig sind.