Il lancio di un sito web è uno degli eventi a più alto rischio per qualsiasi team di marketing. Con Trupeer, puoi risparmiare ore nella coordinazione del lancio iniziando con un modello di checklist gratuito per il lancio del sito web, personalizzandolo con le tue linee guida del brand e trasformando la checklist in una video presentazione che allinea i team di design, sviluppo, SEO e contenuti.

Che cos'è un modello gratuito di checklist per il lancio di un sito web?

Un modello gratuito di checklist per il lancio di un sito web è un elenco di tutto ciò che deve essere verificato e corretto prima, durante e dopo la messa online di un sito.

Non mancano di certo sul mercato. Quelle pubblicate contengono quindici, diciassette, cinquantotto elementi, raggruppati per area: contenuto, design, SEO, aspetti tecnici, legali, analitici. Sono ampiamente accurate e, insieme, coprono quasi tutto ciò che potrebbe andare storto.

Il problema non è la copertura, ma il fatto che ogni voce della lista sembra avere lo stesso peso.

La verifica del testo alternativo delle immagini si trova accanto alla configurazione dei reindirizzamenti. La correzione di bozze della pagina "Chi siamo" è affiancata alla verifica che il file robots.txt di produzione non sia quello di staging. Sotto la pressione del tempo, che caratterizza ogni lancio, qualcuno scorre l'elenco e ne completa la maggior parte, e gli elementi che vengono saltati dipendono semplicemente dalla loro posizione casuale nella lista.

Il modello in sé non è il problema. Ciò che determina se un lancio andrà male è sapere quali, tra i tuoi sessanta elementi, sono i nove che fungono realmente da blocco.

Il formato segue l'uso. La versione Excel di un modello gratuito di checklist per il lancio di un sito web è la scelta naturale, poiché una checklist è un elenco con responsabili, stati e prove. Un file Word è adatto per una versione stampata da utilizzare in una riunione di lancio, mentre un PDF è l'ideale come registro firmato di ciò che è stato verificato.

Cinquantotto elementi, tutti con lo stesso peso

Raggruppare una checklist di lancio per area è l'approccio standard, ma nasconde l'unica distinzione davvero importante.

Prendi in considerazione quattro elementi che compaiono in quasi tutte le liste pubblicate.

Un errore di ortografia su una pagina prodotto. Un attributo alt mancante su un'immagine. Un reindirizzamento non mappato da un vecchio URL. Un robots.txt di staging distribuito in produzione con un blocco globale (disallow).

Raggruppati per area, i primi due appartengono ai contenuti, il terzo alla SEO e il quarto agli aspetti tecnici. Tre sezioni diverse, nessuna indicazione sulla gravità relativa.

In pratica, non sono minimamente paragonabili. Il refuso viene notato entro un giorno e corretto in cinque minuti. L'attributo alt mancante è un problema minore di accessibilità e SEO senza alcuna urgenza. Il reindirizzamento non mappato fa perdere silenziosamente l'autorità che quell'URL aveva, recuperabile in mesi se qualcuno se ne accorge. E il robots.txt rimuove l'intero sito dai risultati di ricerca, non produce alcun errore, non rompe nulla che un visitatore umano possa vedere e può rimanere attivo per settimane.

Due proprietà li differenziano, e nessuna delle due compare in alcuna checklist pubblicata.

Si può rimediare? Alcuni errori sono completamente reversibili una volta individuati. Altri costano tempo che non potrai recuperare, perché il posizionamento e l'indicizzazione si riprendono secondo le tempistiche dei motori di ricerca, non le tue.

Te ne accorgeresti? Alcuni problemi si palesano da soli. Altri sono silenziosi, e quelli silenziosi sono tanto più pericolosi quanto più a lungo rimangono attivi.

Come personalizzare questo modello in Trupeer

Passo 1: Apri la sezione Modelli

Vai alla sezione Modelli dal menu di navigazione principale.

Passo 2: Seleziona e apri un modello

Fai clic su qualsiasi modello con cui desideri lavorare per aprirlo.

Passo 3: Espandi la visualizzazione del modello

Se necessario, espandi la visualizzazione del modello per vedere chiaramente l'intero layout e i dettagli.

Passo 4: Modifica il modello

Fai clic su Modifica per iniziare a modificare il modello selezionato.

All'interno dell'editor puoi:

• Aggiungere nuove sezioni

• Definire o aggiornare le regole di formattazione

• Aggiungere un logo e regolarne la posizione e le relative impostazioni

Passo 5: Salva il tuo modello personalizzato

Dopo aver apportato tutte le modifiche necessarie, fai clic su Salva per memorizzare il modello aggiornato come tuo.

Passo 6: Visualizza l'anteprima e perfeziona il modello

Quando vuoi vedere l'aspetto del tuo modello personalizzato, apri l'Anteprima.

Dalla schermata di anteprima, puoi continuare ad apportare modifiche direttamente se necessario, assicurandoti che il modello appaia esattamente come desideri.

Con un modello di checklist per il lancio del sito web puoi:

• Risparmiare ore di coordinamento: Evita di partire da zero grazie a una struttura già pronta per i lanci.

• Individuare i problemi in anticipo: I controlli integrati coprono contenuti, design, tecnologia, SEO e analisi dei dati.

• Rimanere in linea con il brand: Applica il tuo logo, i tuoi font e i tuoi colori utilizzando il kit del brand di Trupeer.

• Evitare figuracce: Checklist complete prevengono link interrotti, tracciamenti mancanti e disastri SEO.

• Standardizzare i lanci: Utilizza lo stesso modello per ogni sito, microsito e restyling.

• Raggiungere team globali: Traduci le checklist di lancio in oltre 65 lingue con un solo clic.

Ordinare per reversibilità e rilevabilità

Prendi la tua checklist, non importa quanto sia lunga, e inserisci ogni elemento in uno di quattro quadranti.

Irreversibile e invisibile. Il blocco. Questi elementi devono essere verificati prima del lancio da qualcuno diverso da chi ha eseguito il lavoro, allegando una prova. Di solito sono meno di dieci, e sono il motivo stesso per cui si usa una checklist.

Irreversibile e visibile. Importante e che si palesa da solo. Un passaggio DNS fallito o la cancellazione del vecchio sito sono evidenti in pochi minuti, quindi il rischio riguarda il piano di ripristino piuttosto che l'individuazione del problema. Prevedi un piano di rollback e stabilisci chi può avviarlo.

Reversibile e invisibile. Da controllare entro quarantotto ore anziché bloccare il lancio per questi elementi. Dati strutturati, invio della sitemap, attivazione di tag su eventi secondari. Mancare questi elementi costa poco ed è completamente risolvibile.

Reversibile e visibile. Da correggere dopo il lancio. Refusi, spaziatura, compressione delle immagini, testo alternativo. Vale sicuramente la pena farlo, ma non vale la pena ritardare un lancio per questo motivo; trattarli come blocchi per il lancio è il modo in cui si finisce per affrettare gli elementi della prima categoria.

Il valore di questa suddivisione non è la tassonomia in sé, ma il fatto che produce un breve elenco che un responsabile senior leggerà effettivamente e una lista molto più lunga che può essere gestita con calma nella settimana successiva.

Gli elementi che di solito bloccano il lancio

Il primo quadrante è più piccolo di quanto la gente si aspetti e ragionevolmente coerente in tutti i lanci. Nel caso di un rifacimento, questi sono i problemi ricorrenti.

Il file robots.txt di produzione. Non solo che il file esista e sia valido, ma che il suo contenuto sia quello corretto per la produzione. Le regole di disallow di staging caricate in produzione rappresentano il singolo errore di lancio invisibile e catastrofico più comune.

I meta tag noindex. Lo stesso errore ma in un punto diverso, e sopravvive anche dove il file robots.txt è corretto.

La mappa dei reindirizzamenti, verificata rispetto a una scansione del vecchio sito. Non rispetto all'elenco di URL che qualcuno ricorda. Una scansione, i log del server o un'esportazione dalla vecchia sitemap. Gli URL di contenuti della coda lunga sono il punto in cui si annida sempre la mancanza.

I tag canonical che puntano alla produzione. I canonical che fanno ancora riferimento al dominio di staging verranno presi per buoni dai motori di ricerca, penalizzando il sito reale.

L'attivazione di strumenti di analisi e tracciamento sulle pagine importanti. Non solo sulla homepage. Se il tracciamento delle conversioni è interrotto, perdi i dati in modo permanente e non potrai più ricostruirli.

L'invio di moduli che arrivano a una casella di posta presidiata da un essere umano. I moduli che sembrano inviati correttamente ma non vengono recapitati da nessuna parte sono silenziosi e possono rimanere in questo stato per settimane. Verifica la ricezione effettiva, non solo il messaggio di successo dell'invio.

L'invio di email transazionali dalla produzione. Lo stesso problema del punto precedente, ma ancora più grave su un sito di e-commerce.

Il certificato SSL che copre ogni nome host, comprese le varianti con e senza www e qualsiasi sottodominio in uso.

Il TTL del DNS abbassato prima del passaggio. Non è verificabile a posteriori, ed è questo che lo rende un elemento di blocco preventivo anziché un controllo successivo.

Questi sono nove elementi e, nella maggior parte dei lanci, corrisponderanno quasi del tutto alla tua lista personale. Tutto il resto della tua checklist di sessanta elementi appartiene a uno degli altri tre quadranti.

Cosa deve contenere una checklist per il lancio di un sito web

Sette componenti. Le colonne del quadrante e delle prove sono le vere aggiunte.

La colonna delle prove è ciò che distingue una checklist da una semplice lista di spunte. Un refuso viene trovato da chiunque. Se il robots.txt di produzione sia stato effettivamente controllato, da chi e cosa sia stato visto, è una domanda che ci si pone dopo un lancio fallito e a cui di solito non si sa rispondere.

Modello gratuito di checklist per il lancio di un sito web: la struttura da copiare

Compilata con un esempio reale anziché con segnaposto. Il lancio riguarda il rifacimento di un sito di e-commerce e contenuti.

Copia da qui.

Elementi di blocco. Irreversibili e invisibili. Tutti devono essere verificati da una seconda persona con prove allegate prima di procedere con il passaggio (cutover).

Irreversibile e visibile. Si applica il piano di rollback.

Passaggio del DNS. Dismissione del vecchio sito, che comunque non avviene prima di trenta giorni. Switch del gateway di pagamento sulle chiavi live. Ognuno di questi elementi ha una persona designata che può attivare un rollback senza dover chiedere approvazioni.

Reversibile e invisibile. Da controllare entro quarantotto ore.

Sitemap generata e inviata. Dati strutturati validi. Proprietà verificata su Search Console e Bing Webmaster per il nuovo sito. Tracciamento degli eventi secondari. Registrazione delle prestazioni del sito come baseline. Audit dei link interni per quelli che puntano ancora ai vecchi URL.

Reversibile e visibile. Da gestire nelle due settimane successive.

Lettura e correzione di bozze su tutte le pagine. Attributi alt delle immagini. Compressione delle immagini. Foglio di stile per la stampa. Problemi estetici cross-browser. Contenuto della pagina 404. Testo del banner dei cookie.

Rollback. Il DNS può essere ripristinato entro la finestra del TTL. Il vecchio sito rimane attivo e invariato sul suo host originale per trenta giorni. La decisione di ripristinare spetta al responsabile dello sviluppo senza necessità di approvazione.

Monitoraggio post-lancio. Sessioni organiche confrontate con lo stesso periodo dell'anno precedente, non con la settimana scorsa. Numero di pagine indicizzate controllato quotidianamente per le prime due settimane. Invii di moduli contati giornalmente rispetto alla media del mese precedente.

Copia fino a qui.

L'ultima riga sul confronto anno su anno esiste a causa dell'esempio seguente.

Esempio di checklist per il lancio di un sito web: diciannove giorni

Merrowdale Garden Centres gestisce undici sedi con un sito web di e-commerce e contenuti che fattura circa quattordici milioni di sterline online.

Il rifacimento è stato lanciato con una checklist di sessantuno elementi, raggruppati per area, e ogni elemento era stato spuntato.

Due dei sessantuno elementi erano stati spuntati in modo errato.

Il file robots.txt di staging, contenente un blocco globale (disallow), è stato distribuito in produzione. La voce della checklist riportava "controllare robots.txt". Uno sviluppatore ha verificato che il file esistesse e fosse sintatticamente valido, cosa che era vera, e ha messo la spunta. Nulla nella voce diceva di controllare cosa contenesse o di verificarlo sul dominio di produzione dopo il passaggio.

Separatamente, la voce relativa ai reindirizzamenti riportava "impostare reindirizzamenti". Ne erano stati configurati centonovanta, coprendo ogni URL che il team di marketing ricordava. Trecentocinquanta URL di contenuti di nicchia, per lo più vecchie guide alla coltivazione e articoli di consigli stagionali, non avevano alcun reindirizzamento. Nessuno aveva eseguito una scansione del vecchio sito, quindi nessuno sapeva che quegli URL esistessero.

Passarono diciannove giorni prima che qualcuno se ne accorgesse.

Il motivo è stato il monitoraggio, non l'errore in sé. Il traffico veniva confrontato con la settimana precedente, che includeva il blocco dei contenuti pre-lancio e una pausa intenzionale sulle campagne a pagamento, quindi un calo sembrava normale. Le sessioni organiche erano diminuite del settantuno percento ed era stato interpretato come "rumore da lancio".

L'errore è stato scoperto quando una campagna stagionale ha registrato risultati inferiori alle aspettative e qualcuno ha guardato il confronto anno su anno.

Il recupero ha richiesto circa quattro mesi per tornare ai livelli di traffico organico precedenti. La perdita stimata di entrate in quel periodo è stata di circa duecentoquarantamila sterline, e la componente principale era rappresentata dagli URL dei contenuti, che per anni avevano generato traffico in modo silenzioso e che nessuno aveva censito.

La rielaborazione della checklist non ha modificato gli elementi, ma ha cambiato il modo in cui sono stati ordinati.

Sessantuno elementi sono stati valutati in base a due domande: possiamo rimediare a questo errore e ce ne accorgeremmo? Nove sono finiti nel quadrante degli irreversibili e invisibili. Quei nove sono diventati un blocco che richiedeva la verifica da parte di una seconda persona, una delle quali doveva essere esterna al team che aveva svolto il lavoro, con prove allegate.

La voce del robots.txt è stata riscritta da "controllare robots.txt" a "fare uno screenshot del file robots.txt di produzione live dopo il passaggio e confermare l'assenza di disallow per il sito". La voce dei reindirizzamenti è stata riscritta per richiedere una scansione del vecchio sito confrontata con la mappa dei reindirizzamenti, con zero URL non mappati che restituiscono uno stato 200.

E il monitoraggio è passato a un confronto anno su anno, che è l'unica vista in cui un calo del settantuno percento risulta inequivocabile.

Sei mesi dopo hanno lanciato un brand secondario. Il confronto della scansione ha trovato quarantuno URL non mappati due giorni prima della messa online, che sono stati corretti in un'ora e che altrimenti sarebbero stati scoperti solo in un report trimestrale.

Come creare la checklist in sei passaggi

1. Parti da qualsiasi elenco pubblicato. Le versioni da quindici, diciassette o cinquantotto elementi sono davvero complete e non c'è alcun valore nel reinventarle. Anche i produttori di temi e page builder ne pubblicano di ottime, motivo per cui una ricerca per una checklist di lancio restituisce spesso risultati relativi ai modelli Astra per Elementor insieme a esse.

2. Ordina ogni elemento per reversibilità e rilevabilità. Quattro quadranti. Questa operazione richiede circa mezz'ora per sessanta elementi ed è l'intervento più importante.

3. Riscrivi gli elementi di blocco come condizioni con prove. Non "controllare robots.txt" ma cosa nello specifico deve essere visto, dove e quando.

4. Assegna un secondo verificatore per gli elementi di blocco, esterno al team che ha svolto il lavoro. Non per sfiducia, ma perché la persona che ha configurato qualcosa è la meno indicata per verificarla obiettivamente.

5. Imposta il monitoraggio prima del lancio, compreso il periodo di confronto. Anno su anno, non settimana su settimana.

6. Mantieni attivo il vecchio sito per trenta giorni. Non costa quasi nulla ed è ciò che fa la differenza tra il ripristino di un record DNS e il dover ricostruire da capo.

Il passaggio due rappresenta l'intero metodo e il passaggio tre è ciò che lo fa funzionare. Un elemento di blocco formulato come un'attività viene spuntato quando l'attività viene eseguita, il che non equivale a dire che la condizione sia stata effettivamente soddisfatta.

Pre-lancio, giorno del lancio e post-lancio

La struttura in fasi che ogni checklist pubblicata utilizza è un secondo asse utile, ma non sostituisce il primo.

Pre-lancio, settimane prima. Contenuti completati, mappa dei reindirizzamenti creata a partire da una scansione, tracciamento configurato sullo staging, SSL predisposto, TTL del DNS abbassato, piano di rollback concordato, conservazione del vecchio sito organizzata.

Giorno del lancio. Passaggio (cutover), poi le verifiche degli elementi di blocco in ordine, infine l'annuncio. L'annuncio va per ultimo, dopo che gli elementi di blocco sono stati confermati; un concetto ovvio ma che viene spesso invertito perché le pianificazioni di marketing vengono stabilite con settimane di anticipo.

Prime quarantotto ore. Sitemap inviata, indicizzazione verificata, moduli contati, gestione degli elementi reversibili e invisibili e monitoraggio quotidiano rispetto all'anno precedente.

Prime due settimane. L'elenco degli elementi reversibili e visibili. Problemi estetici, correzione di bozze, miglioramenti dell'accessibilità, ottimizzazione delle prestazioni.

Primo trimestre. Monitoraggio del recupero dell'indicizzazione, analisi dei report 404 per gli URL sfuggiti alla scansione e pulizia dei link interni che puntano ancora ai vecchi URL.

Un punto sulla sequenza temporale merita di essere sottolineato. Non programmare l'annuncio del lancio in modo automatico. Se un elemento di blocco fallisce, l'annuncio deve essere trattenuto, e un'email già inviata non può essere richiamata.

Cosa non può risolvere un modello gratuito di checklist per il lancio di un sito web

Voci formulate come attività. "Controllare i reindirizzamenti" viene spuntato quando qualcuno li guarda. Solo una condizione con prova viene spuntata quando è effettivamente corretta.

Una data di lancio che non può essere spostata. Laddove la data sia fissa a prescindere da tutto, la checklist documenta semplicemente cosa è stato saltato. Occasionalmente questa è la decisione aziendale corretta e dovrebbe essere dichiarata apertamente anziché essere mascherata come un controllo completato.

Un monitoraggio basato sul confronto errato. Nessun download gratuito di checklist per il lancio di un sito web imposterà il tuo periodo di confronto, e i diciannove giorni di Merrowdale sono dipesi da questo e non dalla checklist.

URL che nessuno conosce. Solo una scansione o i log del server possono individuarli. Un elenco di URL assemblato a memoria sarà sempre incompleto, e sarà incompleto proprio in quella coda lunga in cui risiede il valore accumulato nel tempo.

Rendi la verifica ripetibile

Gli elementi di blocco dipendono dal fatto che qualcuno controlli qualcosa in modo corretto, e questa è un'abilità più specifica di quanto sembri.

Lo sviluppatore di Merrowdale ha controllato il file robots.txt e ha inserito la spunta. Non è stato negligente. Ha verificato ciò che intendeva con quella voce, ovvero che il file fosse presente e valido. Cosa significasse "verificato" non era mai stato scritto, quindi significava qualunque cosa ognuno presupponesse.

La soluzione è definire il controllo piuttosto che l'attività, e il modo più economico per definire un controllo è mostrare come viene eseguito.

L'intelligenza artificiale di Trupeer si occupa di questo. Chiunque sappia come verificare ciascun elemento di blocco lo esegue una volta registrandolo, e l'output è una guida scritta con screenshot già catturati e posizionati, insieme a un video, con il branding della tua azienda. La persona che esegue il controllo la sera del lancio segue le stesse nove procedure ogni volta, e il requisito della prova diventa evidente anziché interpretabile.

Registralo. Personalizzalo con il tuo brand. Traducilo. Usa Trupeer.

Ne conseguono due punti importanti. I lanci sono poco frequenti, il che è esattamente il caso in cui le procedure scritte servono di più, poiché nessuno lo ha fatto abbastanza di recente da ricordarlo a memoria. E laddove un'agenzia e un cliente detengano entrambi parti della checklist, una verifica registrata significa che entrambe le parti stanno controllando la stessa cosa secondo lo stesso standard, anziché presumere ciascuna che se ne stia occupando l'altra.

La sequenza di passaggio vera e propria appartiene a un runbook, che copre come gestire un lancio che si estende su più turni di lavoro. Il materiale risiede nella tua knowledge base e funge anche da formazione per chiunque gestirà il prossimo. La coerenza tra i tuoi documenti è solo una questione di impostare il kit del brand una volta sola, e la configurazione è trattata nella guida alla configurazione del modello di documento.

Domande frequenti

Esiste una versione Excel del modello gratuito di checklist per il lancio di un sito web?

Excel è il formato naturale, perché una checklist di lancio è un elenco con responsabili, stati, verificatori e prove, e vorrai poter applicare dei filtri. Un file Excel gestisce al meglio questo aspetto.

Aggiungi due colonne a qualsiasi cosa tu scarichi. Una colonna per il quadrante, che indica se l'elemento è reversibile e se un eventuale errore sarebbe visibile, e una colonna per le prove relative agli elementi di blocco. L'ordinamento in base alla prima colonna produce l'elenco ristretto degli elementi che effettivamente bloccano il lancio.

Esiste una versione Word del modello gratuito di checklist per il lancio di un sito web?

Word è adatto per la versione stampata da utilizzare in una riunione di lancio e per il verbale finale che viene firmato. Un file Word funziona bene per questo scopo.

Tuttavia, tieni la copia di lavoro in un foglio di calcolo. Il giorno del lancio gli elementi vengono aggiornati da più persone contemporaneamente e un documento Word inviato via email produce solo tre versioni diverse con spunte differenti.

Esiste un PDF del modello gratuito di checklist per il lancio di un sito web?

Il PDF è ideale come registro di ciò che è stato verificato. Esporta un PDF della checklist una volta confermati gli elementi di blocco, riportando i nomi sia del responsabile che del verificatore per ciascuna voce, insieme alla data.

Vale la pena conservare quel registro per almeno un anno. Quando un problema di posizionamento emerge quattro mesi dopo il lancio, la prima domanda utile da porsi è cosa sia stato effettivamente controllato, e un PDF con i nomi associati ai nove elementi di blocco fornisce la risposta.

Esiste un download gratuito di un modello di checklist per il lancio di un sito web che valga la pena usare?

Sì, e questo è uno dei pochi tipi di documenti in cui gli elenchi pubblicati online sono realmente validi. Un download gratuito fornito da un'agenzia affidabile o da una fonte SEO autorevole sarà completo e reinventarlo da zero non aggiunge alcun valore.

Ciò che nessuno di essi fa, tuttavia, è distinguere gli elementi che bloccano realmente un lancio da quelli che possono essere sistemati la settimana successiva. Prendi una buona lista e dedica mezz'ora a ordinarla: è lì che risiede il vero valore.

Quali sono gli elementi più importanti in una checklist per il lancio di un sito web?

Quelli che non si possono annullare e di cui non ci si accorgerebbe. Il contenuto del file robots.txt di produzione, i tag noindex, la mappa dei reindirizzamenti verificata rispetto a una scansione del vecchio sito, i tag canonical che puntano alla produzione, il tracciamento di analisi e conversioni, il recapito dei moduli, le email transazionali, l'SSL su tutti i nomi host e il TTL del DNS abbassato prima del passaggio.

Nove elementi e, nella maggior parte dei lanci, rappresentano l'intero rischio. Tutto il resto in un elenco di sessanta elementi vale la pena farlo, ma non ti costerà quattro mesi di lavoro perso se rimandato.

Come faccio a verificare correttamente i reindirizzamenti prima di un lancio?

Scansiona il vecchio sito ed esporta ogni URL che restituisce uno stato 200. Confronta l'esportazione con la mappa dei reindirizzamenti e conferma che non vi siano URL non mappati. I log del server e la vecchia sitemap XML sono utili integrazioni.

Il metodo che fallisce sempre è chiedere al team quali siano gli URL importanti. In questo modo si ottengono solo le pagine che le persone ricordano di più, mentre la mancanza si trova sempre nella coda lunga dei contenuti più vecchi, dove di solito risiede il valore accumulato negli anni.

I modelli Astra per Elementor sono rilevanti per una checklist di lancio?

Non proprio, e questa ricerca compare accanto alle query sulla checklist di lancio solo perché una delle pagine posizionate per questo termine appartiene a una società di temi WordPress che pubblica entrambi i contenuti.

I modelli Astra per Elementor sono design di partenza per la creazione di siti WordPress, un compito diverso rispetto alla verifica di un sito prima della messa online. Se stai sviluppando su quella tecnologia, la checklist sopra descritta si applica comunque senza variazioni, poiché robots.txt, reindirizzamenti e tracciamento funzionano allo stesso modo indipendentemente da cosa ha creato le pagine.

Quanto tempo deve rimanere attivo il vecchio sito dopo il lancio?

Trenta giorni sul suo host originale, senza modifiche. Costa pochissimo ed è la differenza tra il ripristino rapido di un record DNS e il dover ricostruire qualcosa da capo.

Ti offre anche un punto di riferimento per tutto ciò che dovesse risultare mancante. I trecentocinquanta URL non mappati di Merrowdale sono stati ricostruibili solo perché il vecchio sito era ancora lì per essere scansionato.