Ein Leitfaden zur Einrichtung einer eigenen Domain für Web-Apps: klare DNS-Schritte, SSL-Ausstellung, Redirects und ein risikoarmer Umstellungsplan, um Ausfallzeiten und Cookie-Probleme zu vermeiden.
Eine eigene Domain ist mehr als eine schönere URL. Sobald du von einer Plattform-Adresse (zum Beispiel einer App auf Koder.ai unter einer Plattform-Subdomain) zu deiner eigenen Domain wechselst, behandeln Browser und Netzwerke die Seite als eine andere Site. Das beeinflusst Routing, Sicherheit und das Verhalten von Nutzersessions.
Sobald du auf eine eigene Domain wechselst, ändern sich sofort ein paar Dinge:
www oder auf der Apex-Domain landen, und brauchst konsistente HTTP-zu-HTTPS-Regeln.old-platform.example funktioniert nicht automatisch auf app.yourdomain.com.Kurzfristige Ausfälle entstehen meist durch Timing. DNS kann anfangen, Traffic zur neuen Zieladresse zu schicken, bevor das SSL-Zertifikat fertig ist — dann gibt es Browser-Warnungen. Oder umgekehrt: SSL ist bereit, aber viele Nutzer treffen noch die alte Seite, weil ihr DNS-Cache nicht abgelaufen ist.
Redirects können Logins auf subtile Weise kaputtmachen. Ein Redirect, der den Hostnamen ändert (Apex → www oder umgekehrt), kann Cookies verlieren, wenn diese für den anderen Host gesetzt wurden. Auth-Anbieter können fehlschlagen, wenn deren Callback-URL noch auf die alte Domain zeigt.
Eine risikoarme Umstellung plant Überlappung: die alte URL weiter erreichbar lassen, die neue Domain parallel hochziehen, den Traffic zu einem vorhersehbaren Zeitpunkt umstellen und das Rollback so einfach wie möglich halten (z. B. DNS zurückändern).
Bevor du etwas änderst, schreibe genau auf, welche Namen Nutzer eintippen sollen und welche still redirecten. Die meisten "Warum funktioniert das nur halb?"-Momente entstehen, weil sich das Team nie auf eine einzige wahre Hostname geeinigt hat.
Beginne mit der großen Entscheidung: Apex (example.com) oder www (www.example.com) als Primärhost. Beides kann funktionieren, aber entscheide dich und behandle die andere Variante als Redirect. Das ist später auch wegen Cookies wichtig: Sessions sind meist am einfachsten, wenn die App auf einem konsistenten Host liegt.
Entscheide als Nächstes, welche Subdomains du jetzt brauchst und welche warten können. Ein übliches Muster ist app.example.com für die Web-App und api.example.com für APIs, mit admin.example.com oder assets.example.com später. Wenn du eine benutzerdefinierte Domain auf einer Plattform wie Koder.ai einrichtest, spiegeln sich diese Entscheidungen direkt in dem, was du für SSL verifizieren und in DNS zeigen musst.
Viele Leute kaufen eine Domain beim Registrar, aber DNS wird woanders gehostet. Kläre, wo die Einträge heute bearbeitet werden, wer Zugriff hat und ob Änderungen automatisiert werden (IT, Agentur oder ein Managed-DNS-Anbieter). Wenn du dich nicht einloggen kannst, um aktuelle Records zu sehen, halte an und behebe das zuerst.
Prüfe auch, was die Domain bereits nutzt. E-Mail ist die klassische Falle: Du kannst Mail-Zustellung kaputtmachen, wenn du Records löschst oder überschreibst.
Halte diese Entscheidungen schriftlich fest:
www) und Redirect-RichtungWenn Marketing bereits E-Mail über example.com nutzt, lass Mail-bezogene Records unangetastet und füge nur das hinzu, was die App braucht.
Der größte Teil des Risikos bei einer Domain-Umstellung ist nicht die App selbst. Es ist ein falscher DNS-Change, der Traffic ins Nichts sendet, E-Mail kaputtmacht oder SSL-Validierung scheitern lässt.
Ein A-Record zeigt einen Namen auf eine IP-Adresse: kurz gesagt „schick Leute zu diesem Server“. Er wird oft für die Apex-Domain (example.com) genutzt, wenn dein Provider eine feste IP gibt.
Ein CNAME-Record zeigt einen Namen auf einen anderen Namen: „behandle diesen Namen als Alias von jenem Hostname“. Häufig genutzt für www.example.com, das auf einen Plattform-Hostname zeigt.
Viele DNS-Anbieter bieten auch ALIAS/ANAME für den Apex an. Es verhält sich wie ein CNAME, funktioniert aber für example.com. Wenn dein Anbieter das unterstützt, ist das oft leichter zu verwalten, weil das Ziel sich bewegen kann, ohne dass du IPs anpassen musst.
Ein einfaches Modell:
Du wirst oft TXT-Records für Domain-Ownership-Checks (Plattform-Verifikation) und für SSL-Zertifikat-Validierung sehen (einige CAs validieren per TXT-Token). TXT wird auch für E-Mail-Policy wie SPF verwendet. Ein versehentliches Löschen oder Ersetzen eines bestehenden SPF-TXT kann Mail-Zustellung kaputtmachen.
TTL steuert, wie lange andere Systeme deine DNS-Antwort cachen. Senke einen Tag vor der Umstellung die TTL auf die Records, die du ändern willst (häufig 300–600 Sekunden). Wenn alles stabil ist, erhöhe sie wieder, um Abfragen zu reduzieren.
Exportiere oder mach Screenshots der aktuellen Zone, bevor du editierst. Schreibe zu jedem Record, den du änderst: alten Wert, neuen Wert und TTL. Rollback heißt, die vorherigen Werte wiederherstellen.
Das ist besonders wichtig, wenn deine Domain bereits MX, DKIM oder andere TXT-Records für E-Mail hat.
SSL (das Schloss) verschlüsselt Traffic zwischen Browser und App. Moderne Browser und viele APIs erwarten HTTPS standardmäßig. Ohne HTTPS kann es Warnungen, blockierte Anfragen und Probleme mit Features wie Service Workern, Geolocation oder bestimmten Zahlungsabläufen geben.
Zur Ausstellung eines Zertifikats muss die Zertifizierungsstelle verifizieren, dass du die Domain kontrollierst. Häufige Validierungsmethoden sind HTTP-Validierung und DNS-TXT-Validierung:
DNS-Validierung ist oft einfacher, wenn du ein CDN nutzt oder wenn deine App unter der neuen Domain noch nicht erreichbar ist.
Wer das Zertifikat ausstellt, hängt von deinem Setup ab. Manche Teams stellen Zertifikate direkt auf ihrem Hosting-Stack aus, manche beim CDN, und einige Plattformen, die Custom Domains unterstützen, übernehmen das für dich (zum Beispiel kann Koder.ai das Zertifikat während der Domain-Einrichtung verwalten). Entscheidend ist zu wissen, wer den Lebenszyklus des Zertifikats verwaltet, inklusive Erneuerungen.
Die Ausstellung ist nicht immer sofort. DNS-Propagation, Validierungsprüfungen und Rate-Limits können die Sache verzögern. Plane Wiederholungen ein und vermeide, die Umstellung auf den letzten möglichen Moment zu legen.
Ein praktischer Zeitplan:
Ein Zertifikat muss jeden Hostname abdecken, den Nutzer treffen. Prüfe die SAN-Liste (Subject Alternative Names). Wenn deine App auf example.com und www.example.com erreichbar sein soll, muss das Zertifikat beide Namen enthalten.
Wildcards (z. B. *.example.com) helfen bei vielen Subdomains, aber sie decken nicht die Apex-Domain (example.com) ab.
Konkretes Beispiel: Wenn du nur ein Zertifikat für www.example.com ausstellst, sehen Nutzer, die example.com eintippen, weiterhin Warnungen, es sei denn, du leitest auf einer Ebene um, die bereits ein gültiges Zertifikat für example.com hat.
Redirects klingen einfach, aber die meisten Domain-Probleme treten hier auf: Loops, Mixed Content und Nutzer, die ausgeloggt werden, weil sie zwischen Hosts springen.
Wähle einen kanonischen Host und bleib dabei: entweder www.example.com oder example.com (Apex). Der andere Einstiegspunkt sollte auf deinen gewählten Host weiterleiten, damit Cookies, Sessions und SEO-Signale konsistent bleiben.
Sichere Defaults:
http:// zu https:// für jede AnfrageFür HTTP → HTTPS vermeide Regeln, die Nutzer hin und her schicken. Der einfachste Weg, Loops zu verhindern, ist, die Entscheidung auf der Grundlage der tatsächlichen Anfrage zu treffen. Wenn deine App hinter einem Proxy oder CDN sitzt, konfiguriere es so, dass weitergeleitete Header respektiert werden (z. B. ein Header, der das ursprüngliche Scheme angibt). Ansonsten könnte deine App denken, jede Anfrage sei HTTP und ständig weiterleiten.
Behalte alte Pfade während eines Umzugs aktiv. Wenn du Routen änderst (z. B. /login zu /sign-in), füge explizite Redirects für diese Pfade hinzu. Verlass dich nicht auf eine pauschale Weiterleitung zur Startseite — das bricht Bookmarks und geteilte Links.
Setze HSTS zuerst nicht zu früh ein. Wenn du es aktivierst und später HTTP für Validierung oder Troubleshooting brauchst, verweigern Browser eventuell den Zugriff. Warte, bis HTTPS stabil ist und du die Subdomain-Abdeckung bestätigt hast.
Um Redirects zu testen, ohne alle zu beeinflussen, nutze einen temporären Test-Hostname, probiere echte Deep Links (inklusive Auth-Seiten) und führe eine Kommandozeilen-Anfrage aus, die jeden Redirect-Schritt und das finale Ziel zeigt.
Eine sichere Umstellung ist vor allem Timing. Du willst die neue Domain bereit und getestet haben, bevor echte Nutzer dorthin geleitet werden, und du willst DNS-Änderungen so schnell streuen, dass du bei einem Vorfall nicht lange warten musst.
Senke die DNS-TTL (für die zu ändernden Records) rechtzeitig. Mach das am besten einen Tag vorher und warte die alte TTL-Periode ab, damit Caches den niedrigeren Wert übernehmen.
Füge als Nächstes die Custom Domain im Hosting/Provider hinzu und erfülle die erforderliche Verifikation. Wenn du eine Plattform wie Koder.ai nutzt, füge die Domain dort zuerst hinzu, damit die Plattform Ownership bestätigen und Routing vorbereiten kann.
Stelle SSL früh aus. Zertifikate können Minuten oder länger dauern, abhängig von der Validierung — diese Verzögerung willst du nicht während des Wechsels haben.
Bevor die Domain öffentlich ist, führe einen privaten Test durch: rufe den neuen Endpunkt so auf, dass er nicht von öffentlichem DNS abhängt (z. B. temporärer Host-Eintrag auf deinem Rechner) und prüfe, ob die Seite über HTTPS mit dem richtigen Zertifikat lädt.
Nutze einen gestuften Ansatz, damit du schnell stoppen kannst, wenn etwas schief aussieht:
www), bevor du Nutzer umleitestWenn du kein echtes Canary auf DNS-Ebene machen kannst, kannst du trotzdem stufenweise vorgehen, indem du zuerst nur einen Hostnamen (z. B. www) umstellst und die Apex unberührt lässt, bis du sicher bist.
Schreibe genau auf, was du zurücksetzt (welche Records, welche Werte) und wer das macht. Rollback heißt meist, DNS wieder so herzustellen, wie es vorher war.
Stelle sicher, dass das alte Setup noch gültig ist (inklusive SSL auf der alten Domain), damit Nutzer sauber zurückfallen können, während du das neue Setup reparierst.
Eine Domain-Änderung ist nicht nur DNS. Bei vielen Apps hängt "eingeloggt sein" von Cookies ab, die der Browser an einen bestimmten Host bindet. Wenn du den Host änderst, schickt der Browser die alten Cookies möglicherweise nicht mehr und die App wirkt, als wären alle ausgeloggt.
Cookie-Einstellungen sind oft der Grund:
app.old.com wird nicht an app.new.com gesendet. Ein Cookie für .example.com funktioniert über app.example.com und www.example.com./api), sieht die Web-UI es vielleicht nicht.Lax reicht oft, aber bei manchen SSO- oder Zahlungs-Redirects braucht es None plus Secure.Um Risiko zu reduzieren, plane eine kurze Übergangszeit, in der beide Domains funktionieren. Lass die alte Hostname Anfragen beantworten und leite vorsichtig um, aber ermögliche das Auffrischen von Sessions auf der neuen Domain. Wenn möglich, nutze einen gemeinsamen Session-Store, sodass ein Nutzer, der eine der Hostnames trifft, wiedererkannt werden kann.
Wenn du SSO oder OAuth nutzt, aktualisiere Einstellungen vor dem Cutover: Callback-URLs, erlaubte Origins und Allowlists für Redirect URIs. Ansonsten schlägt der Login fehl, wenn der Identity-Provider zur alten Domain zurückleitet.
Teste zuerst die Flows, die häufig brechen: Registrierung (inkl. E-Mail-Verifikation), Login/Logout, Passwort-Reset, Checkout oder Zahlungs-Return und Multi-Tab-Sessions.
Beispiel: Wenn du www.example.com auf example.com weiterleitest, setze Cookies für .example.com (oder nutze konsistent einen Host), sonst verlieren Nutzer beim Wechsel die Session.
Die meisten Domain-Probleme sind keine "mysteriösen Internetprobleme". Es sind kleine Inkonsistenzen zwischen DNS, Zertifikaten und Redirect-Regeln, die erst unter Realbedingungen sichtbar werden.
Eine einfache Falle ist die Apex-Domain (example.com). Viele DNS-Anbieter erlauben keinen echten CNAME am Apex. Wenn du trotzdem versuchst, einen CNAME am Apex zu verwenden, kann das still scheitern, inkonsistent auflösen oder nur in manchen Netzwerken brechen. Nutze, was dein DNS-Host unterstützt (oft A/AAAA oder ein ALIAS/ANAME-ähnlicher Record).
Ein weiterer häufiger Grund für Ausfallzeiten ist, DNS zu ändern, bevor SSL am neuen Endpunkt bereit ist. Nutzer kommen an, die App lädt und der Browser blockiert wegen fehlendem oder nicht passendem Zertifikat. In der Praxis willst du meist, dass das Zertifikat sowohl example.com als auch www.example.com abdeckt, selbst wenn du eine der Varianten nur umleiten möchtest.
Häufige Fehler, die Ausfälle oder seltsames Verhalten verursachen:
www → Apex, dann Apex zurück zu www) oder HTTP an einer Stelle und HTTPS an einer anderen erzwingenhttp://-Verweise auf Assets, was zu Browser-Warnungen und gebrochenen Features führtSchnelle Kontrolle: Öffne beide Hostnames (www und Apex) über HTTPS, logge dich ein, lade neu und prüfe, dass die Adresszeile nie wieder auf HTTP wechselt.
Wenn du das auf einer Plattform wie Koder.ai machst, bestätige, dass Custom Domains verbunden und SSL ausgestellt sind, bevor du Produktions-DNS änderst, und halte eine Rollback-Option bereit, damit ein fehlerhafter Redirect oder Record nicht lange bestehen bleibt.
Eine gelassene Umstellung ist größtenteils Vorbereitung. Das Ziel ist einfach: Nutzer sollen weiter eingeloggt bleiben, Cookies sollen funktionieren und du musst schnell zurückrollen können, falls etwas nicht stimmt.
Mach diese Schritte, während der Traffic noch zur alten Domain geht. Gib dir, wenn möglich, einen Tag Zeit, damit DNS-Änderungen sich setzen können.
www, api, etc.) und wähle die SSL-Validierungsmethode (DNS oder HTTP).www → Apex (oder andersherum) und ein kanonischer Host.Behandle die erste Stunde nach dem Flip wie einen Incident-Drill. Beobachte echte Nutzerflüsse, nicht nur Status-Dashboards.
Auch wenn Koder.ai (oder eine andere Plattform) Custom Domains und SSL für dich handhabt, ist diese Checkliste weiterhin wichtig. Die meisten Probleme entstehen durch DNS und Redirects, nicht durch App-Code.
Deine App läuft auf einer temporären Plattform-Adresse wie myapp.koder.ai. Sie funktioniert, aber du willst, dass Kunden example.com nutzen, mit www.example.com, das auf die Apex umleitet, und alles erzwungen auf HTTPS.
Ein einfacher DNS-Plan hält das Risiko niedrig. Bevor du etwas änderst, notiere den aktuellen funktionierenden Zustand (falls deine Plattform Snapshots unterstützt, erstelle einen) und reduziere die DNS-TTL auf einen kurzen Wert einen Tag vorher.
Füge die neuen Records hinzu und lasse die bestehende Plattform-URL unangetastet:
example.com: A/ALIAS-Record, der auf das Hosting-Ziel zeigt, das deine Plattform bereitstelltwww.example.com: CNAME, der auf example.com (oder auf das Plattform-Ziel, je nach Provider) zeigtmyapp.koder.ai unverändert, damit du immer einen bekannten, funktionierenden Fallback hastSobald DNS steht, fordere SSL für beide Hostnames an (example.com und www.example.com). Schalte den Traffic erst um, wenn das Zertifikat ausgestellt und aktiv ist, sonst bekommen Nutzer Browser-Warnungen.
Cutover-Zeitplan mit klaren Checkpoints:
example.com im Inkognito-Fenster testen (Startseite, statische Assets, API-Aufrufe)www → Apex)Nach dem Wechsel: Cookie-Verhalten validieren. Einloggen, neu laden und prüfen, ob du auf www und Apex eingeloggt bleibst. Wenn Sessions brechen, liegt es meist an Cookie-Domain- oder SameSite-Einstellungen, die noch die alte Host-Annahme verwenden.
Nach einem erfolgreichen Cutover ist die Arbeit nicht vorbei. Viele Domain-Umstellungen scheitern später, weil niemand das langsame Abdriften bemerkt: ein fast ablaufendes Zertifikat, eine hastig geänderte DNS-Einstellung oder ein Redirect-Tweak, der einen Login-Flow kaputtmacht.
Richte eine kleine Monitoring-Routine ein, die du tatsächlich pflegst. Du brauchst kein Enterprise-Tool, aber ein paar verlässliche Signale: Availability-Checks für Schlüsselseiten (Start, Login und eine authentifizierte Seite), Zertifikats-Expiry-Alerts (z. B. bei 30 und 7 Tagen), Fehler-Rate-Tracking (achte auf 4xx/5xx-Spikes, nicht nur Uptime) und gelegentliche Redirect-Validierung (HTTP → HTTPS und der bevorzugte Host gewinnt).
Halte ein kurzes Rollback-Fenster bereit, selbst wenn alles gut aussieht. Für 24–72 Stunden behalte die vorherige Konfiguration bereit (alte DNS-Ziele, alte Hosting-Config, alte TLS-Einstellungen), damit du schnell zurückrollen kannst, wenn ein verstecktes Problem auftaucht, z. B. ein Payment-Callback oder ein OAuth-Provider, der noch auf die alte Domain zeigt.
Wenn du dir sicher bist, erhöhe die DNS-TTL wieder. Niedrige TTL ist während Änderungen nützlich, aber sie erhöht die Last auf Resolver und macht kleine Fehler später folgenreicher. Wähle einen normalen TTL-Wert passend zur Änderungsfrequenz (viele Teams wählen 1–4 Stunden).
Zum Schluss: Dokumentiere den finalen Zustand, solange alles noch frisch ist: welche Records bestehen (Typ, Name, Wert, TTL), welche Hostnames unterstützt werden und die genauen Redirect-Regeln. Notiere, wo Zertifikate ausgestellt werden, welche Namen sie abdecken (Apex, www, Subdomains) und wer die Erneuerungen verwaltet.
Wenn du auf einer Plattform entwickelst und deployst, ist es hilfreich, Domains als Feature zu behandeln und Rollbacks einfach zu machen. Auf Koder.ai sitzen Custom Domains neben Snapshots und Rollback-Funktionen, was zukünftige Domain- und Redirect-Änderungen weniger stressig macht, falls schnell etwas rückgängig gemacht werden muss.
Default: eine kanonische Hostname wählen und alle anderen dorthin umleiten.
example.com (Apex) oder www.example.com als „die echte“ Domain.Das sorgt für konsistente Cookies, Sessions und Lesezeichen und verhindert halb-funktionierendes Verhalten.
TTL am Tag vor dem Wechsel senken und dann lange genug warten, bis der alte TTL-Wert abgelaufen ist.
TTL nur für die Datensätze senken, die du auch wirklich ändern wirst.
Für viele App-Setups:
www.example.com oder app.example.com, wenn du auf einen Provider-Hostname zeigst.example.com.Schicke Nutzer nicht um, bevor HTTPS für die neuen Hostnames gültig ist.
Praktische Reihenfolge:
So vermeidest du Browser-Warnungen genau beim Cutover.
E-Mail-Probleme entstehen meist durch Löschen oder Überschreiben von MX- und TXT-Records.
Vor Änderungen:
Redirect-Ketten und -Schleifen entstehen oft durch widersprüchliche Regeln zwischen CDN/Proxy und App.
Sichere Defaults:
http:// → https://Wenn du hinter einem Proxy/CDN sitzt, achte darauf, dass deine App weitergeleitete Scheme-Header respektiert; sonst denkt sie, jede Anfrage sei HTTP und leitet endlos weiter.
Ja, das ist häufig der Fall, wenn Cookies auf den alten Host begrenzt sind.
Worauf du achten solltest:
old-host werden nicht an gesendetAktualisiere Identity-Einstellungen vor dem Cutover.
Typische Einträge, die genau mit der neuen Domain übereinstimmen müssen:
Wenn diese noch auf die alte Domain verweisen, kann der Login beim Anbieter zwar gelingen, scheitert aber beim Rücksprung zur App.
Ein Rollback heißt meist: die vorherigen DNS-Werte wiederherstellen.
Halte es einfach:
Wenn deine Plattform Snapshots/Rollback unterstützt (Koder.ai tut das), erstelle einen Snapshot vor dem Cutover, damit du zugehörige Konfigurationsänderungen schnell rückgängig machen kannst.
Teste reale Nutzerpfade, nicht nur die Startseite.
Teste auf dem kanonischen Host und auf dem umleitenden Host:
Prüfe außerdem, dass die Adresszeile auf endet und immer verwendet wird, ohne Mixed-Content-Warnungen.
Versuche nicht, einen CNAME am Apex zu erzwingen, wenn dein DNS-Anbieter das nicht unterstützt.
Ein schneller Sicherheitsschritt ist der Export oder ein Screenshot der aktuellen Zone, damit du sie bei Bedarf wiederherstellen kannst.
new-hostEine risikoarme Herangehensweise ist, die alte Hostname während der Übergangszeit weiter erreichbar zu lassen, damit Nutzer ihre Session auf der neuen Domain aktualisieren können.