Passare in live: migrazione dev-verso-prod, Search Console e performance

Panoramica

Hai costruito tutto lo stack: architettura, auth, dati, segreti e pagamenti. Ora lo passi in live e fai in modo che il mondo possa trovarlo. Passare in live non e un solo pulsante - e migrare ogni servizio dalla sua istanza di development alla produzione in un ordine accurato, puntare il tuo dominio via Cloudflare verso i posti giusti, dire a Google che il tuo sito esiste e renderlo veloce. Fallo nel giusto ordine, e il giorno di lancio e calmo. Fallo alla rinfusa, e ottieni il classico fallimento del giorno di lancio dove una chiave dimenticata mette i login o la fatturazione fuori servizio mentre i clienti guardano. Questa lezione ti da la versione calma.

Cosa imparerai

Imparerai un ordine sicuro per migrare Clerk e Convex dallo sviluppo alla produzione, come cablare il tuo dominio e il DNS con Cloudflare davanti alla tua app, come verificare il tuo sito nella Google Search Console e sottomettere il tuo sitemap per essere indicizzato, e quali basi di Lighthouse e di Core Web Vitals contano davvero per la velocita, il SEO e la conversione.

Prerequisiti

Uno stack completo da questo corso - auth, dati e pagamenti, tutti funzionanti in development - perche passare in live collega i tre. La lezione di deployment del Corso 1, perche Vercel, DNS e Cloudflare vi sono apparsi e questa lezione vi si appoggia. E le parti setup di produzione delle lezioni su Clerk, Stripe e i segreti, che ora metti insieme.

Il problema

La migrazione e dove i builder sicuri di se vengono umiliati. Ogni servizio ha i suoi mondi dev e prod (istanze Clerk, deployment Convex, modalita Stripe), e commutarli nell'ordine sbagliato o dimenticare una chiave lascia un'app a meta live dove gli utenti possono iscriversi ma i loro dati spariscono, o possono pagare ma non ottengono mai l'accesso. Nel frattempo, persino un lancio perfetto e invisibile se Google non sa che il tuo sito esiste e le tue pagine sono lente. I fondatori versano settimane nella costruzione poi mancano l'ultimo chilometro, cosicche il prodotto parte rotto o introvabile. Questa lezione e quest'ultimo chilometro, fatto in un ordine deliberato.

Un ordine di migrazione sicuro

Migra un servizio alla volta e verifica ciascuno prima del successivo, perche, se qualcosa si rompe, tu sappia esattamente quale passo l'ha causato. L'ordine sicuro e: dominio e DNS prima (perche l'indirizzo esista), poi Convex (perche i dati abbiano una casa), poi Clerk (perche l'auth punti verso il dominio live e il database live), poi Stripe (perche i pagamenti accordino l'accesso al sistema ormai live), poi deployare con tutte le chiavi live in atto. Dopo ogni commutazione, testa il vero flusso prima di avanzare. Il fallimento di gran lunga piu frequente e lasciare una chiave di test nell'ambiente in deploy, quindi fai un ultimo passaggio su ogni variabile d'ambiente e conferma che nessun sk_test, pk_test o webhook secret di test sopravviva in produzione.

• Dominio e DNS prima: registrare il dominio, puntarlo via Cloudflare verso la tua app e il tuo sito marketing.
• Convex poi: creare il deployment di produzione, porre le sue env var, deployarvi il tuo schema e le tue funzioni.
• Clerk poi: creare l'istanza di produzione, aggiungere i suoi DNS record, configurare Google OAuth, commutare verso pk_live / sk_live.
• Stripe per ultimo: attivare l'account, ricreare prodotti e prezzi in modalita live, registrare il webhook endpoint live, commutare verso le chiavi live.
• Ultimo passaggio: confermare che zero chiave di test resta nelle env var di produzione, poi deployare e testare il flusso completo iscrizione-verso-pagamento in live.

Dominio, DNS e Cloudflare davanti

Il tuo sito marketing e la tua app vivono ad indirizzi diversi, generalmente il dominio nudo (yoursite.com) per il marketing e un sottodominio (app.yoursite.com) per l'app, esattamente come la lezione d'architettura descriveva. Punti entrambi via DNS, e uno schema comune e solido e mettere Cloudflare davanti: gestire il DNS su Cloudflare, ottenere il suo HTTPS gratuito e il suo CDN globale e instradare ogni nome verso il posto giusto (tipicamente Vercel per entrambe le superfici). Ricorda i sottodomini Clerk della lezione 2 - quei CNAME record vogliono generalmente essere DNS-only (nuvola grigia) piuttosto che proxati, per non rompere l'handshake TLS dell'auth. Cloudflare davanti ti da velocita e protezione di base gratis, motivo per cui la maggior parte dei builder lo usa. Fai attenzione a non doppio-proxare ne gestire l'HTTPS in doppio, la trappola del Corso 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 e il tuo sitemap

Un sito live di cui Google non sa niente non riceve nessun traffico di ricerca. La Google Search Console e lo strumento gratuito che dice a Google che il tuo sito esiste, mostra come ti indicizza e rende visibili i problemi presto. Il flusso: aggiungi il tuo sito come property, verifica che ti appartiene (il metodo piu semplice e generalmente un DNS TXT record che la Search Console ti da e che aggiungi su Cloudflare), poi sottometti l'URL del tuo sitemap. Il tuo sitemap e la lista leggibile dalla macchina delle tue pagine - questo progetto ne genera gia uno con lo script generate:sitemaps - e sottometterlo dice a Google esattamente cosa crawlare. Poi, la Search Console diventa il tuo sistema d'allarme precoce: mostra la copertura d'indicizzazione, per quali query appari e ogni errore di crawl, perche tu colga i problemi SEO prima che ti costino traffico.

; Verificare la proprieta nella Search Console con un TXT record (valore che viene da Google)
; Type   Name   Value
TXT      @      google-site-verification=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

; Poi sottomettere l'URL del tuo sitemap nell'UI della Search Console :
; https://yoursite.com/sitemap.xml

L'indicizzazione non e istantanea. Dopo la sottomissione, Google impiega giorni fino a settimane per crawlare e indicizzare un nuovo sito, e la Search Console mostra il progresso. Sottomettere il sitemap e correggere ogni errore che segnala e l'azione SEO piu impattante che tu possa intraprendere al lancio.

Lighthouse e le basi di velocita di pagina che contano

Lighthouse e l'audit gratuito integrato in Chrome (ed eseguibile in CI) che valuta le tue pagine sulla performance, l'accessibilita, le best practice e il SEO. Le pagine veloci convertono meglio e rankano meglio - Google usa i Core Web Vitals come segnale di ranking, e i crawler di IA preferiscono anche le pagine veloci e pulite -, quindi trattare la velocita come parte del lancio paga doppio. Non devi rincorrere un 100 perfetto su ogni metrica, ma dovresti capire il pugno di cose che spostano davvero l'ago, perche la maggior parte delle pagine lente e lenta per le solite poche ragioni. Lancia Lighthouse soprattutto sui tuoi siti marketing, perche sono la porta d'ingresso del tuo funnel e dove la velocita conta di piu.

• Immagini: il colpevole numero uno. Consegna formati moderni (WebP/AVIF), dimensionale correttamente e fai lazy-load delle immagini sotto la linea di galleggiamento.
• JavaScript: consegnane di meno. E esattamente per questo che il sito marketing usa un framework content-first - meno script, pagine piu veloci.
• Largest Contentful Paint (LCP): quanto in fretta il contenuto principale appare. Ottimizza la tua immagine hero e i tuoi font per migliorarlo.
• Cumulative Layout Shift (CLS): le cose che saltano durante il caricamento. Riserva spazio per immagini e annunci, perche niente si muova.
• Font: caricali efficacemente ed evita i lampi di testo invisibile. Il self-hosting e il preloading aiutano.
• Caching e il CDN: Cloudflare davanti consegna gia gli asset statici in fretta in tutto il mondo - appoggiati a esso.

Errori frequenti

I classici del giorno di lancio: lasciare una chiave di test in produzione, cosicche i login o pagamenti falliscono in silenzio; migrare i servizi in un ordine confuso, cosicche non puoi dire cosa si e rotto; proxare i sottodomini di auth di Clerk via Cloudflare e rompere l'handshake TLS; dimenticare di registrare il webhook endpoint Stripe live, cosicche i pagamenti di produzione non accordano mai l'accesso; non verificare mai il sito nella Search Console ne sottomettere il sitemap, cosicche il lancio e invisibile per Google; e pubblicare immagini pesanti e non ottimizzate che fanno crollare Lighthouse e la conversione. Ognuno e evitato dalla checklist ordinata e un ultimo passaggio sulle variabili d'ambiente.

ROI business

L'ultimo chilometro e dove tutta la tua costruzione paga o fallisce in silenzio. Una migrazione pulita significa che il giorno di lancio e noioso invece di un guasto davanti ai tuoi primi clienti. La Search Console e il sitemap sono la differenza tra un prodotto che accumula traffico su mesi e uno che nessuno trova. E la velocita di pagina e una leva diretta sulla conversione e il ranking - le pagine piu veloci guadagnano letteralmente piu denaro e rankano piu in alto, ogni giorno che sono in live. Per un fondatore, fare bene l'ultimo chilometro protegge tutto l'investimento della costruzione del prodotto in primo luogo.

Checklist

Hai finito il Corso 3 quando tutto questo e vero sul prodotto live.

• Clerk, Convex e Stripe sono tutti in produzione, e zero chiave di test resta nelle env var di produzione.
• Il tuo dominio serve il sito marketing e l'app via HTTPS, con Cloudflare davanti e i sottodomini Clerk in DNS-only.
• Il tuo sito e verificato nella Google Search Console e il tuo sitemap e sottomesso.
• Lighthouse sui tuoi siti marketing e sano, con immagini e JavaScript ottimizzati.

Risorse

Tieni aperti le guide di deployment di produzione di Clerk e Convex, la checklist go-live di Stripe e la Google Search Console durante il lancio - ognuno e aggiornato, li dove questo corso rinvia a documentazione. Lancia Lighthouse dai Chrome DevTools o dal tuo CI su ogni sito marketing. La lezione di deployment del Corso 1 e il tuo riferimento per le basi di Vercel, DNS e Cloudflare. Ora puoi costruire e lanciare un prodotto completo e a pagamento end-to-end.

La tua missione

Passa in live un progetto di questo corso, anche piccolo. Migra Clerk e Convex verso la produzione nell'ordine sicuro, punta il tuo dominio via Cloudflare, fai l'ultimo passaggio sulle env var per uccidere ogni chiave di test, verifica il sito nella Search Console e sottometti il sitemap, poi lancia Lighthouse sulla tua homepage e correggi i due problemi piu grossi che segnala. Fare tutto l'ultimo chilometro una volta trasforma il lancio da un'incognita spaventosa in una checklist di routine per ogni prodotto che costruisci in seguito.

Prossima lezione

Ora puoi costruire e lanciare un vero prodotto a pagamento end-to-end: architettura, auth, dati, segreti, pagamenti e un passaggio in live pulito. Il Corso 4 va oltre una sola app, nell'automazione e nei sistemi agentici - n8n e gli strumenti di workflow, l'automazione di browser, le sandbox e la costruzione dei tuoi strumenti di IA che abbattono lavoro per te mentre dormi.