Live gehen: Dev-zu-Prod-Migration, Search Console und Performance

Überblick

Du hast den ganzen Stack gebaut: Architektur, Auth, Daten, Secrets und Payments. Jetzt nimmst du ihn live und sorgst dafür, dass die Welt ihn finden kann. Live-Gehen ist kein einzelner Knopf - es ist, jeden Dienst von seiner Development-Instanz zur Produktion in einer sorgfältigen Reihenfolge zu migrieren, deine Domain über Cloudflare auf die richtigen Stellen zu zeigen, Google zu sagen, dass deine Seite existiert, und sie schnell zu machen. Mach es in der richtigen Reihenfolge, und der Launch-Tag ist ruhig. Mach es ad hoc, und du bekommst den klassischen Launch-Tag-Fehlschlag, bei dem ein verpasster Key Logins oder Billing lahmlegt, während Kunden zusehen. Diese Lektion gibt dir die ruhige Version.

Was du lernst

Du lernst eine sichere Reihenfolge, um Clerk und Convex von Development zu Produktion zu migrieren, wie du deine Domain und DNS mit Cloudflare vor deiner App verdrahtest, wie du deine Seite in der Google Search Console verifizierst und deine Sitemap einreichst, damit du indexiert wirst, und welche Lighthouse- und Core-Web-Vitals-Grundlagen wirklich für Tempo, SEO und Conversion zählen.

Voraussetzungen

Ein kompletter Stack aus diesem Kurs - Auth, Daten und Payments, alle in Development funktionierend - denn Live-Gehen verbindet alle drei. Die Deploy-Lektion aus Kurs 1, denn Vercel, DNS und Cloudflare tauchten dort auf und diese Lektion baut darauf auf. Und die Produktions-Setup-Teile aus den Lektionen zu Clerk, Stripe und Secrets, die du jetzt zusammenbringst.

Das Problem

Migration ist, wo selbstbewusste Builder gedemütigt werden. Jeder Dienst hat seine eigenen Dev- und Prod-Welten (Clerk-Instanzen, Convex-Deployments, Stripe-Modi), und sie in der falschen Reihenfolge umzuschalten oder einen Key zu vergessen hinterlässt eine halb-live App, in der sich Nutzer registrieren können, aber ihre Daten verschwinden, oder sie zahlen können, aber nie Zugang bekommen. Derweil ist selbst ein perfekter Launch unsichtbar, wenn Google nicht weiss, dass deine Seite existiert, und deine Seiten langsam sind. Gründer giessen Wochen ins Bauen und vermasseln dann die letzte Meile, sodass das Produkt kaputt oder unauffindbar startet. Diese Lektion ist diese letzte Meile, in einer bewussten Reihenfolge gemacht.

Eine sichere Migrationsreihenfolge

Migriere einen Dienst nach dem anderen und verifiziere jeden vor dem nächsten, sodass du, wenn etwas bricht, genau weisst, welcher Schritt es verursacht hat. Die sichere Reihenfolge ist: Domain und DNS zuerst (damit die Adresse existiert), dann Convex (damit Daten ein Zuhause haben), dann Clerk (damit Auth auf die Live-Domain und die Live-Datenbank zeigt), dann Stripe (damit Payments Zugang zum nun-live System gewähren), dann mit allen Live-Keys an Ort und Stelle deployen. Nach jeder Umstellung teste den echten Flow, bevor du weitergehst. Der mit Abstand häufigste Fehlschlag ist, einen Test-Key in der deployten Umgebung zu lassen, also mach einen finalen Durchlauf über jede Umgebungsvariable und bestätige, dass kein einziges sk_test, pk_test oder Test-Webhook-Secret in Produktion überlebt.

• Domain und DNS zuerst: die Domain registrieren, sie über Cloudflare auf deine App und Marketing-Seite zeigen.
• Convex als Nächstes: das Produktions-Deployment erstellen, seine env vars setzen, dein Schema und deine Funktionen darauf deployen.
• Clerk als Nächstes: die Produktions-Instanz erstellen, ihre DNS-Records hinzufügen, Google OAuth konfigurieren, auf pk_live / sk_live umstellen.
• Stripe zuletzt: den Account aktivieren, Produkte und Preise im Live-Modus neu erstellen, den Live-Webhook-Endpoint registrieren, auf Live-Keys umstellen.
• Finaler Durchlauf: bestätige, dass null Test-Keys in den Produktions-env-vars verbleiben, dann deploye und teste den vollen Signup-zu-Payment-Flow live.

Domain, DNS und Cloudflare davor

Deine Marketing-Seite und deine App leben an verschiedenen Adressen, meist der nackten Domain (yoursite.com) fürs Marketing und einer Subdomain (app.yoursite.com) für die App, genau wie die Architektur-Lektion beschrieb. Du zeigst beide über DNS, und ein häufiges, starkes Muster ist, Cloudflare davorzusetzen: DNS bei Cloudflare verwalten, sein kostenloses HTTPS und globales CDN bekommen und jeden Namen an die richtige Stelle routen (typischerweise Vercel für beide Oberflächen). Erinnere dich an die Clerk-Subdomains aus Lektion 2 - diese CNAME-Records wollen meist DNS-only (graue Wolke) sein statt proxied, damit sie den Auth-TLS-Handshake nicht brechen. Cloudflare davor gibt dir Tempo und grundlegenden Schutz gratis, weshalb die meisten Builder es nutzen. Pass auf, dass du nicht doppelt proxst oder HTTPS doppelt handhabst, der Gotcha aus Kurs 1.

; Example DNS layout (real targets come from Vercel / Clerk)
; Type   Name      Value / target            Proxy
CNAME    @         cname.vercel-dns.com      proxied   ; marketing site
CNAME    app       cname.vercel-dns.com      proxied   ; the app
CNAME    clerk     frontend-api.clerk.services  DNS only ; auth - do NOT proxy
CNAME    accounts  accounts.clerk.services      DNS only ; auth - do NOT proxy

Google Search Console und deine Sitemap

Eine Live-Seite, von der Google nichts weiss, bekommt keinen Suchtraffic. Die Google Search Console ist das kostenlose Tool, das Google sagt, dass deine Seite existiert, zeigt, wie es dich indexiert, und Probleme früh sichtbar macht. Der Ablauf: füg deine Seite als Property hinzu, verifiziere, dass sie dir gehört (die einfachste Methode ist meist ein DNS-TXT-Record, den die Search Console dir gibt und den du bei Cloudflare hinzufügst), reich dann deine Sitemap-URL ein. Deine Sitemap ist die maschinenlesbare Liste deiner Seiten - dieses Projekt generiert bereits eine mit dem generate:sitemaps-Skript - und sie einzureichen sagt Google genau, was zu crawlen ist. Danach wird die Search Console dein Frühwarnsystem: sie zeigt die Indexierungs-Abdeckung, für welche Queries du erscheinst, und alle Crawl-Fehler, sodass du SEO-Probleme fängst, bevor sie dich Traffic kosten.

; Eigentum in der Search Console mit einem TXT-Record verifizieren (Wert kommt von Google)
; Type   Name   Value
TXT      @      google-site-verification=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

; Dann deine Sitemap-URL in der Search-Console-UI einreichen:
; https://yoursite.com/sitemap.xml

Indexierung ist nicht sofort. Nach dem Einreichen braucht Google Tage bis Wochen, um eine neue Seite zu crawlen und zu indexieren, und die Search Console zeigt den Fortschritt. Die Sitemap einzureichen und alle Fehler zu beheben, die sie meldet, ist die wirkungsvollste SEO-Aktion, die du beim Launch unternehmen kannst.

Lighthouse und die Page-Speed-Grundlagen, die zählen

Lighthouse ist das kostenlose Audit, das in Chrome eingebaut ist (und in CI lauffähig), das deine Seiten auf Performance, Barrierefreiheit, Best Practices und SEO bewertet. Schnelle Seiten konvertieren besser und ranken besser - Google nutzt Core Web Vitals als Ranking-Signal, und KI-Crawler bevorzugen ebenfalls schnelle, saubere Seiten -, also zahlt es sich doppelt aus, Tempo als Teil des Launches zu behandeln. Du musst keine perfekte 100 bei jeder Metrik jagen, aber du solltest die Handvoll Dinge verstehen, die wirklich etwas bewegen, denn die meisten langsamen Seiten sind aus denselben wenigen Gründen langsam. Fahr Lighthouse besonders auf deinen Marketing-Seiten, denn die sind die Eingangstür deines Funnels und wo Tempo am meisten zählt.

• Bilder: der Hauptschuldige Nummer eins. Liefere moderne Formate (WebP/AVIF), dimensioniere sie korrekt und lazy-loade Bilder unterhalb der Falz.
• JavaScript: liefere weniger davon. Genau darum nutzt die Marketing-Seite ein content-first Framework - weniger Skripte, schnellere Seiten.
• Largest Contentful Paint (LCP): wie schnell der Hauptinhalt erscheint. Optimiere dein Hero-Bild und deine Fonts, um es zu verbessern.
• Cumulative Layout Shift (CLS): Dinge, die beim Laden der Seite herumspringen. Reserviere Platz für Bilder und Anzeigen, damit nichts verrutscht.
• Fonts: lade sie effizient und vermeide Blitze unsichtbaren Texts. Selbst-Hosting und Preloading helfen.
• Caching und das CDN: Cloudflare davor liefert statische Assets bereits weltweit schnell aus - lehn dich darauf.

Typische Fehler

Die Launch-Tag-Klassiker: einen Test-Key in Produktion lassen, sodass Logins oder Payments still fehlschlagen; Dienste in einer verworrenen Reihenfolge migrieren, sodass du nicht sagen kannst, was gebrochen ist; Clerks Auth-Subdomains durch Cloudflare proxen und den TLS-Handshake brechen; vergessen, den Live-Stripe-Webhook-Endpoint zu registrieren, sodass Produktionszahlungen nie Zugang gewähren; die Seite nie in der Search Console verifizieren oder die Sitemap einreichen, sodass der Launch für Google unsichtbar ist; und schwere, unoptimierte Bilder shippen, die Lighthouse und Conversion abstürzen lassen. Jeder davon wird durch die geordnete Checkliste und einen finalen Umgebungsvariablen-Durchlauf verhindert.

Business-ROI

Die letzte Meile ist, wo all dein Bauen sich entweder auszahlt oder still scheitert. Eine saubere Migration heisst, der Launch-Tag ist langweilig statt ein Ausfall vor deinen ersten Kunden. Search Console und die Sitemap sind der Unterschied zwischen einem Produkt, das über Monate Traffic aufaddiert, und einem, das nie jemand findet. Und Page-Speed ist ein direkter Hebel auf sowohl Conversion als auch Ranking - schnellere Seiten verdienen buchstäblich mehr Geld und ranken höher, jeden einzelnen Tag, den sie live sind. Für eine Gründerin schützt es die gesamte Investition des Produktbaus überhaupt, die letzte Meile richtig hinzubekommen.

Checkliste

Du hast Kurs 3 abgeschlossen, wenn all das am Live-Produkt stimmt.

• Clerk, Convex und Stripe sind alle in Produktion, und null Test-Keys verbleiben in den Produktions-env-vars.
• Deine Domain liefert die Marketing-Seite und App über HTTPS aus, mit Cloudflare davor und Clerk-Subdomains DNS-only.
• Deine Seite ist in der Google Search Console verifiziert und deine Sitemap ist eingereicht.
• Lighthouse auf deinen Marketing-Seiten ist gesund, mit optimierten Bildern und JavaScript.

Ressourcen

Halt die Clerk- und Convex-Produktions-Deployment-Guides, die Stripe-Go-Live-Checkliste und die Google Search Console während des Launches offen - jeder ist aktuell, wo dieser Kurs auf Docs verweist. Fahr Lighthouse aus den Chrome DevTools oder deiner CI auf jeder Marketing-Seite. Die Deploy-Lektion aus Kurs 1 ist deine Referenz für Vercel-, DNS- und Cloudflare-Grundlagen. Du kannst jetzt ein komplettes, bezahltes Produkt von Anfang bis Ende bauen und launchen.

Deine Aufgabe

Nimm ein Projekt aus diesem Kurs live, auch ein kleines. Migriere Clerk und Convex in der sicheren Reihenfolge zu Produktion, zeig deine Domain über Cloudflare, mach den finalen env-var-Durchlauf, um jeden Test-Key zu töten, verifiziere die Seite in der Search Console und reich die Sitemap ein, fahr dann Lighthouse auf deiner Homepage und behebe die zwei grössten Probleme, die es meldet. Die volle letzte Meile einmal zu machen verwandelt den Launch von einer beängstigenden Unbekannten in eine Routine-Checkliste für jedes Produkt, das du danach baust.

Nächste Lektion

Du kannst jetzt ein echtes, bezahltes Produkt von Anfang bis Ende bauen und launchen: Architektur, Auth, Daten, Secrets, Payments und ein sauberes Live-Gehen. Kurs 4 geht über eine einzelne App hinaus in Automation und agentische Systeme - n8n und Workflow-Tools, Browser-Automation, Sandboxes und das Bauen eigener KI-Tools, die Arbeit für dich erledigen, während du schläfst.