Domain abgelaufen, Website offline: was jetzt passiert

Am Freitag lief deine App noch. Am Montag ist da eine ganzseitige Browserwarnung, oder gar nichts mehr, und an deinem Code hat sich nichts geändert. Jemand schickt dir einen Screenshot, und du tippst die Wörter darauf in ein Suchfeld: Domain abgelaufen, Website offline.

Hier ist der Teil, den die meisten Ratschläge dazu falsch machen. Diesen Morgen können zwei verschiedene Ausfälle erzeugen, sie laufen auf zwei verschiedenen Uhren, und der billiger klingende ist der ernste. Ein abgelaufenes Zertifikat ist laut, peinlich und heute noch zu ersetzen. Eine abgelaufene Domain ist zunächst leise, und wenn du sie lange genug liegen lässt, ist deine App nicht offline. Sie gehört jemand anderem.

Zwischen deiner App und den Leuten, die sie nutzen, stehen zwei Dinge. Die Domain ist der Mietvertrag für den Laden: der Name über der Tür und das Recht, ihn weiter zu führen. Das Zertifikat ist die Zulassung im Fenster, die sagt, dass dieser Laden wirklich der auf dem Schild ist. Du mietest beides. Beides verlängert sich an einem Datum, das du einmal gesetzt und seither nicht mehr angesehen hast.

Was passiert, wenn meine Domain abläuft?

Deine App geht offline, und dann läuft eine Uhr in drei Phasen.

Bei .com und den anderen generischen Domains kommt der Fahrplan von der ICANN und nicht von deinem Registrar, er ist also weitgehend derselbe, egal wo du den Namen gekauft hast.

Noch deins, schon aus. Dein Registrar hält den Namen für einen Zeitraum seiner Wahl zum normalen Preis verlängerbar, meist ein paar Wochen. Die Expired Registration Recovery Policy der ICANN verlangt, dass er in dieser Zeit dein DNS abschaltet: mindestens die letzten acht Tage, in denen der Name noch verlängerbar ist, darf er nirgendwohin mehr zeigen. Deine App geht also lange offline, bevor der Name irgendwohin geht, und genau so merken es Inhaber normalerweise.

Gelöscht, und trotzdem rückholbar. Wenn der Registrar die Registrierung endgültig löscht, beginnt eine 30-tägige Redemption Grace Period. Die ICANN verlangt sie von fast jedem generischen Registry. Nur du kannst den Namen in dieser Zeit zurückholen, nur über den Registrar, der ihn gelöscht hat, und du zahlst zusätzlich zur Verlängerung eine Wiederherstellungsgebühr. Die ICANN legt diese Gebühr nicht fest, und sie liegt weit über einer Verlängerung.

Pending Delete. Etwa fünf Tage, in denen weder du noch dein Registrar irgendetwas ausrichten. Danach wird der Name freigegeben.

Dieselbe Richtlinie sagt, dass dein Registrar dir schreiben muss: zweimal bevor die Registrierung abläuft, ungefähr einen Monat und eine Woche vorher, und nochmal innerhalb von fünf Tagen danach. Wenn also je eine Domain von dir ohne Vorwarnung abgelaufen ist, gehört nicht der Kalender überprüft. Sondern welche Adresse in deinem Registrar-Konto hinterlegt ist.

Länderdomains haben ihre eigenen Fahrpläne. .io, .co.uk, .de und der Rest fallen nicht unter diese Richtlinie, und manche davon sind deutlich weniger nachsichtig. Wenn deine App auf einer davon läuft, lies die Lifecycle-Seite deines Registrys statt diesen Abschnitt.

Kann jemand meine Domain übernehmen, nachdem sie abgelaufen ist?

Ja, sobald sie freigegeben ist, und genau das unterscheidet diesen Fall von allem anderen in einem Sicherheitsbericht.

Jeder andere Befund ist ein Fehler in etwas, das dir gehört. Du kannst hingehen und ihn beheben. Eine freigegebene Domain verlässt deinen Besitz vollständig: der Name ist auf jemand anderen registriert, und alles, was auf deine App gezeigt hat, zeigt jetzt auf diese Person. Lesezeichen. Der Link in deiner Willkommens-E-Mail. Die Adresse auf der Karte, die du auf einer Konferenz verteilt hast. Der Link zum Zurücksetzen des Passworts, den du letzte Woche verschickt hast.

Namen werden auch schnell weggeschnappt. Es gibt Firmen, deren ganzes Produkt darin besteht, eine Domain in der Sekunde anzufragen, in der sie frei wird, und darum bleibt ein Name mit irgendeinem Traffic selten lange unregistriert.

Du kannst trotzdem versuchen, ihn zurückzukaufen. Du verhandelst dann mit demjenigen, der zuerst da war, zu dem Preis, den er nennt. Ein Zertifikat, das heute Morgen abgelaufen ist, lässt sich heute Morgen ersetzen; eine Domain, die letzten Monat freigegeben wurde, steht vielleicht gar nicht zum Verkauf.

Warum sagt meine Website „nicht sicher", wo gestern alles in Ordnung war?

Das können zwei verschiedene Dinge sein, und welches davon du hast, steht auf dem Bildschirm.

Ein Hinweiswort in der Adressleiste ist dein Browser, der sagt, dass die Seite über einfaches HTTP kam, ganz ohne Zertifikat. Deine Seite lädt darunter weiter. Nichts ist abgelaufen. Irgendetwas liefert deine Website ohne HTTPS aus, und das ist ein eigenes Problem, nicht dieses.

Ein abgelaufenes oder nicht vertrauenswürdiges Zertifikat ist kein Hinweis. Es ist eine Wand. Deine App wird durch eine ganze Seite ersetzt: in Chrome der Hinweis, dass die Verbindung nicht privat ist, in Firefox die Warnung vor einem möglichen Sicherheitsrisiko. Um auf deine Website zu kommen, muss man einen Erweitert-Knopf finden und sich durch eine Warnung klicken, die die Seite als unsicher bezeichnet. Die meisten Besucher tun das nicht.

Lies den Code unter der Warnung, bevor du irgendetwas änderst, denn er sagt dir, welche Reparatur du brauchst:

Die letzte Zeile lohnt sich, bevor du bei deinem Hoster suchst. Eine einzelne Person, die eine Zertifikatswarnung meldet, kann der Laptop dieser Person sein.

Warum ein HTTPS-Zertifikat aufhört sich zu erneuern, ohne dass etwas kaputtgeht

Weil die Erneuerung einen Monat vor dem Ablauf passieren soll und eine gescheiterte Erneuerung nichts ändert, was du sehen kannst.

Die meisten so gebauten Apps werden von einem Hoster ausgeliefert, der Zertifikate von Let's Encrypt holt und sie für dich erneuert. Let's Encrypt stellt 90-Tage-Zertifikate aus und empfiehlt, alle 60 Tage zu erneuern, der Vorgang, der deine Website am Leben hält, soll also mit 30 Tagen Restzeit fertig sein.

Um ein neues zu bekommen, muss dein Hoster der Zertifizierungsstelle beweisen, dass er deinen Namen weiterhin kontrolliert: entweder indem er unter deiner Domain eine angeforderte Datei ausliefert, oder indem er einen Eintrag in dein DNS schreibt. Alles, was diesen Beweis kaputt macht, macht die Erneuerung kaputt. Ein Umzug deines DNS zu einem anderen Anbieter. Ein Proxy vor der App. Den Namen kurz woanders hinzeigen lassen und wieder zurück. Ein CAA-Eintrag, ein DNS-Eintrag also, der benennt, welche Stellen für deine Domain ausstellen dürfen, und der stillschweigend jede Stelle verbietet, die er nicht nennt.

Nichts davon legt deine Website lahm. Das Zertifikat, das du schon hast, funktioniert weiter, die App bleibt also online und das Schloss bleibt da, während die Erneuerung einen Monat lang jeden Tag wieder scheitert, ohne dass jemand hinsieht.

Auch der Brief, der früher kam, bleibt aus. Let's Encrypt hat seine Ablaufbenachrichtigungen am 4. Juni 2025 eingestellt und es im Januar desselben Jahres angekündigt: die Erneuerung läuft bei den meisten inzwischen automatisch, und Millionen von E-Mail-Adressen an Ausstellungsdaten gebunden zu halten war ein Datenschutzpreis, den sie lieber nicht zahlen wollten. Beide Gründe sind gut. Es hat trotzdem die eine Nachricht entfernt, die einen Menschen erreichte, wenn die Automatik aufhörte.

Erneuern Lovable oder Vercel mein Zertifikat für mich?

Solange deine App auf der eigenen Subdomain des Builders läuft, gehören beide Daten ihnen, und bei keinem davon kannst du etwas falsch machen.

Bei deineapp.lovable.app oder einer Adresse auf vercel.app oder netlify.app besitzt die Plattform den Namen, verlängert die Registrierung und stellt das Zertifikat aus und erneuert es. Unsere eigene Domain-Prüfung schlägt diese gar nicht erst nach. Sie meldet, dass die App auf einer verwalteten Plattform-Domain läuft und es hier für dich nichts zu überwachen gibt.

Wenn du eine eigene Domain verbindest, wandert eines der beiden sicher zu dir und das andere manchmal:

Die Zeile mit der Verlängerung ist die, über die Leute stolpern. Nichts im Builder sagt es an. Du fügst eine Domain hinzu, die App lädt darauf, und du besitzt jetzt einen Kalendereintrag, den du nie gemacht hast.

Wie prüfe ich jetzt sofort beides?

Von außen, ohne dich irgendwo anzumelden.

Das Zertifikat. Öffne deine App, klick auf das Schloss in der Adressleiste, öffne die Zertifikatsdetails und lies das Ablaufdatum. Bei einem normalen 90-Tage-Zertifikat heißt alles über 30 Tage, dass die Erneuerung funktioniert. Weniger als 30 Tage heißt, dass die Erneuerung, die längst hätte passieren sollen, nicht passiert ist.

Die Domain. Melde dich bei deinem Registrar an und lies drei Dinge. Das Ablaufdatum. Ob die Karte hinter der automatischen Verlängerung noch gültig ist, denn automatische Verlängerung mit einer toten Karte ist der häufigste Weg, wie das jemandem passiert, der sich sicher war, dass es nicht passieren kann. Und die E-Mail-Adresse im Konto, denn dorthin geht jede Warnung, die dir zusteht.

Beides auf einmal. Unser kostenloser Scan liest beides von außen, zusammen mit sieben weiteren Prüfungen, in etwa 20 Sekunden und ohne Konto: scanne deine App. Er gibt das Enddatum des Zertifikats aus und, bei einer selbst registrierten Domain, das der Registrierung. Auf einer Builder-Subdomain sagt er das, statt dir ein Datum zu erfinden.

Was wir bei 30.998 Apps gefunden haben

Beide Befunde sind selten, und jeder einzelne davon gehörte jemandem, der eine eigene Domain verbunden hatte.

Zwischen dem 12. und 14. August 2026 haben wir dieselben neun externen Prüfungen über 30.998 aktive Apps laufen lassen, gebaut mit Lovable, Bolt, v0, Replit und Base44. Von den Apps, bei denen die jeweilige Prüfung eine Antwort bekam, hatten 55 von 30.980 eine abgelaufene oder bald ablaufende Domain, und 32 von 30.851 ein abgelaufenes, bald ablaufendes oder nicht vertrauenswürdiges Zertifikat. Die vollständigen Zahlen stehen in unserem Scan-Bericht.

Das sind 87 Apps, was nach einem Rundungsfehler klingt, bis man fragt, wer sie waren. 1.090 der Scans in diesem Durchlauf liefen auf einer App, deren Inhaber die Domain selbst registriert hatte. Alle 87 waren in dieser Gruppe, und nicht eine einzige App auf einer Builder-Subdomain trug einen der beiden Befunde. Unter den Apps, die dieses Problem überhaupt haben können, ist das ungefähr eine von zwölf.

Das meiste in dieser Spalte ist eine Warnung und kein Ausfall, und das ist der nützliche Teil: jemand hatte noch Zeit. Fünf der Domains waren innerhalb von sieben Tagen, und eine war schon weg. Dreizehn der Apps zeigten in dem Moment, in dem wir hinsahen, jedem Besucher eine Browserwarnung, fünf mit einem abgelaufenen Zertifikat und acht mit einem, dem nichts vertraut.

Bei beiden geht ein Datum vorbei, während niemand hinsieht, und das ist genau die Art Problem, für die etwas taugt, das stündlich nachsieht.

Reeve Monitor lässt alle neun Prüfungen stündlich auf bis zu drei Apps laufen, prüft die Erreichbarkeit alle 60 Sekunden und schickt einen Monatsbericht. Bei diesen beiden Befunden tut es etwas, das es sonst nirgends tut: es schreibt dir, dass ein Zertifikat oder eine Registrierung ausläuft, auch wenn sich deine Note nicht geändert hat. Monitor kostet laut Liste €12 im Monat, mit sieben Tagen kostenlos vor der ersten Abrechnung, und die Preisseite liegt manchmal unter dem Betrag hier und nie darüber.

Monitor sieht zu und mehr nicht. Wenn du zusätzlich eine Kopie deiner Datenbank an einem Ort willst, an den dein Builder nicht kommt, dafür gibt es Care, und es deckt Supabase ab.

Was du jetzt tun solltest

Keines von beiden ist ein Fehler, den jemand in deiner App gemacht hat, und darum lässt man sie so leicht von der Liste. Setz sie drauf. Wenn du lieber alles auf einmal durchgehst: die Sicherheits-Checkliste in 10 Minuten deckt alle neun Prüfungen in der Reihenfolge ab, in der sie sich lohnen.