HTML-Datei online stellen

HTML-Datei in drei Schritten online stellen

Prüfung und Vorschau passieren auf dieser Seite; veröffentlicht wird mit zwei Befehlen im Terminal oder direkt aus deinem Coding-Agenten heraus. Hochgeladen wird hier nichts — der Prüfer ist ein Skript in deinem eigenen Browser.

1. Datei öffnen. Zieh die .html-Datei auf das Feld, wähl sie über den Dateidialog oder füg den Quelltext ein. Gelesen wird lokal mit dem FileReader, gerendert in einem Sandbox-Frame — du siehst also genau das, was ein Besucher sähe.
2. Blocker abräumen. Jeder Befund trägt eine Zeilennummer. Blocker sind die Dinge, die sich anders verhalten, sobald die Datei über HTTPS von einer Domain kommt: Verweise auf die eigene Festplatte, Subressourcen über http://, ein fehlender viewport oder Titel. Die Prüfpunkte sind das, was sich lohnt, bevor jemand die Seite verlinkt.
3. Veröffentlichen. Leg die Datei als index.html in einen Ordner, sicher dir mit clize claim einen kostenlosen Handle und lass clize deploy auf den Ordner laufen. Die HTTPS-Adresse steht in derselben Minute, und derselbe Ordner lässt sich beliebig oft neu deployen.

Was kaputtgeht, sobald die Datei deinen Rechner verlässt

Eine Datei, die du unter file:///Users/du/Schreibtisch/seite.html öffnest, und dieselbe Datei, ausgeliefert von https://deinname.clize.app/, leben nicht in derselben Welt. Die vier Unterschiede unten erklären fast jedes „lokal sah das noch gut aus", und der Prüfer auf dieser Seite findet sie alle, ohne deine Datei irgendwohin zu schicken.

Zwei weitere Punkte meldet der Prüfer, weil sie unsichtbar bleiben, bis es zu spät ist: ein fehlender <title>, der zum Linktext jeder Verlinkung wird, die je auf die Seite zeigt, und ein fehlendes og:image, weshalb manche Links im Chat eine Vorschaukarte bekommen und deiner nicht. Und ein deutscher Sonderfall, den der Prüfer als Warnung führt: ohne <meta charset="utf-8"> werden aus Umlauten und dem ß nach dem Ausliefern Zeichensalat — lokal fällt das nicht auf, weil dein Browser die Datei anders errät als der Server sie deklariert.

Willst du die Datei nur anschauen statt sie zu veröffentlichen, rendert der HTML-Viewer genauso, mit drei Vorschaubreiten und ohne das ganze Veröffentlichen-Thema.

Bevor eine deutsche Seite online geht: Impressum, Datenschutz, Google Fonts

Das ist die Liste, die auf englischen Anleitungen zu diesem Thema nie steht, in Deutschland aber vor dem Deploy kommt — nicht danach. Der Prüfer oben findet technische Fehler; die folgenden Punkte sind rechtlicher Natur, und dafür bist du zuständig. Wir erzeugen weder ein Impressum noch eine Datenschutzerklärung, und diese Seite ist keine Rechtsberatung. Wir sagen dir nur, wonach du suchen musst.

• Impressumspflicht (§ 5 DDG, seit Mai 2024 der Nachfolger des TMG). Geschäftsmäßige digitale Dienste brauchen ein leicht erkennbares, unmittelbar erreichbares Impressum mit Name, Anschrift, E-Mail-Adresse und, wo einschlägig, Registereintrag und Umsatzsteuer-ID. „Geschäftsmäßig" fängt früher an, als die meisten denken: eine Seite mit Werbung, Affiliate-Links oder Auftragsakquise zählt schon dazu. Rein privates ohne jede Einnahmeabsicht bleibt außen vor — die Grenze ist dünn.
• Verantwortlicher nach § 18 Abs. 2 MStV. Sobald die Seite journalistisch-redaktionelle Inhalte hat — ein Blog mit regelmäßigen Beiträgen reicht — kommt zusätzlich ein benannter Verantwortlicher mit Anschrift dazu.
• Datenschutzerklärung. Sobald personenbezogene Daten verarbeitet werden, und dazu gehört schon die IP-Adresse im Server-Log, brauchst du eine Datenschutzerklärung nach Art. 13 DSGVO. Eine reine Statikseite ist davon nicht automatisch befreit.
• Google Fonts vom Google-Server. Der Klassiker. Ein <link> auf fonts.googleapis.com überträgt die IP-Adresse jedes Besuchers in die USA, ohne dass er gefragt wurde. Das LG München I hat dafür am 20.01.2022 (Az. 3 O 17493/20) 100 € Schadensersatz zugesprochen, und danach ging eine Abmahnwelle durchs Land. Die Lösung ist banal: Schriftdatei herunterladen, neben die Seite legen, per @font-face lokal einbinden — dann steht in der Findeliste oben ein Host weniger.

Genau dafür ist der Befund „Lädt von N fremden Hosts" im Prüfer nützlich: Diese Liste ist, Zeile für Zeile, deine Liste der Drittanbieter — Fonts, CDN-Skripte, eingebettete Karten, Zählpixel. Was da nicht drinsteht, kann auch nichts übertragen. Was drinsteht, muss entweder in die Datenschutzerklärung, hinter eine Einwilligung nach § 25 TDDDG oder lokal neben die Seite.

Praktisch heißt das: Deine Seite ist selten eine einzelne Datei, sondern mindestens drei — index.html, impressum.html, datenschutz.html. Das ist kein Problem, denn clize deploy nimmt einen Ordner: Alles, was drinliegt, geht mit hoch, und /impressum/ oder /impressum.html ist danach genauso erreichbar wie die Startseite.

Zwei Befehle, und die Datei hat eine Adresse

Veröffentlichen ist hier kein Formular. Einmal installieren, danach sind ein kostenloser Handle und ein Deploy je ein Befehl — dieselben zwei Befehle, die dein Coding-Agent ausführt, wenn du ihn bittest, die Seite online zu stellen, weil es dieselbe CLI ist.

$ npm i -g @clize/clize && clize login
      
      $ clize claim ravensberg
      ✓ ravensberg.clize.app gehört dir; die Platzhalterseite steht.
      
      $ clize deploy ./seite --domain ravensberg.clize.app
      {
        "host": "ravensberg.clize.app",
        "url": "https://ravensberg.clize.app",
        "files": 3,
        "notFound": "spa (auto)",
        "geo": { "sitemap": "…/sitemap.xml", "llms": "…/llms.txt", "robots": "…/robots.txt" }
      }

Der Handle wird nach Reihenfolge vergeben und bleibt deiner, bis du ihn freigibst. clize deploy erwartet einen Ordner, leg deine Datei also in einen und nenn sie index.html — mehr Zeremonie hat die „Einzeldatei" nicht. Bind den Ordner einmal mit clize init --handle ravensberg, dann brauchen spätere Deploys kein --domain mehr. Alle Befehle stehen in der Befehlsübersicht (englisch).

Was „kostenloses HTML-Hosting" hier genau umfasst

Kostenlos heißt: der Handle, das Zertifikat und die Deploys — kein Testzeitraum. Die ganze Fläche auf einen Blick, damit du entscheiden kannst, bevor du irgendetwas tippst:

• Eine echte Adresse. deinname.clize.app über HTTPS, Zertifikat automatisch ausgestellt. Eine eigene Domain kannst du später darauf zeigen lassen, ohne die Dateien anzufassen.
• Ganze Sites, nicht nur eine Seite. Was im Ordner liegt, geht hoch: Seiten, CSS, Bilder, Schriften. Eine Datei bis 90 MB, eine Site bis 5 GB — genug für lokal eingebundene Schriften statt Google Fonts.
• Echte 404er, wenn du sie willst. Leg eine 404.html dazu, und unbekannte Pfade antworten mit echtem 404; ohne sie fallen sie auf index.html mit 200 zurück, was eine Single-Page-App genau so braucht. --not-found überschreibt beides.
• Saubere URLs. /impressum/ liefert direkt /impressum/index.html, ohne Umleitung. Antworten werden fünf Minuten öffentlich gecacht.
• Eine maschinenlesbare Fläche, ohne Zutun. Jeder Deploy beantwortet /sitemap.xml, /llms.txt und /robots.txt aus der Dateiliste; leg eigene Dateien mit diesen Namen dazu, und deine gewinnen.
• Auf Wunsch ein Postfach unter demselben Namen. clize claim deinname --email öffnet zusätzlich support@deinname.clize.app für eingehende Mail — praktisch, weil das Impressum ohnehin eine erreichbare E-Mail-Adresse verlangt.

Was es nicht ist: Es gibt keinen visuellen Editor, und vor deiner Seite steht kein Werbe-Interstitial. Du schreibst oder generierst das HTML — von Hand oder indem du den Agenten fragst, den du ohnehin benutzt — und der Deploy veröffentlicht genau diese Bytes.

$ npm i -g @clize/clize && clize login
$ clize claim deinname
$ clize deploy ./seite --domain deinname.clize.app