La risposta in breve
La pubblicazione di un sito è una decisione aziendale di accettazione, non un semplice rilascio tecnico. Nominate chi decide, stabilite in anticipo problemi bloccanti e condizioni di ripristino, raccogliete prove prima e dopo la messa online e testate richieste reali. Assegnate inoltre i responsabili dei controlli previsti nei primi 30 giorni. Un elenco firmato delle eccezioni mantiene visibili i difetti minori senza lasciare che quelli critici passino inosservati.
- Definite criteri di accettazione osservabili e problemi bloccanti prima del giorno della pubblicazione.
- Testate dominio, moduli e conferme nell’ambiente di produzione, senza affidarvi soltanto alle prove nell’ambiente di test.
- Dopo il rilascio controllate indicizzazione, URL canonici, reindirizzamenti e sitemap.
- Organizzate verifiche programmate per i primi 30 giorni, con responsabili nominati e correzioni ordinate per priorità.
In questa pagina
Definite i criteri di accettazione e chi autorizza la pubblicazione
Un sito è pronto quando le attività concordate per gli utenti funzionano in produzione e le persone responsabili accettano i rischi noti. L’elenco delle attività di sviluppo completate costituisce una prova utile, ma non sostituisce la decisione aziendale.
Nominate una persona che prenda la decisione finale, un responsabile tecnico, un responsabile dei contenuti e un referente per la ricezione dei contatti. Stabilite l’orario della decisione, le condizioni per ripristinare la versione precedente e il canale di comunicazione. Decidete cosa impedisce la pubblicazione prima che aumenti la pressione.
Per un sito destinato a generare contatti, un modulo non funzionante, un dominio errato, una limitazione dell’ambiente di test ancora attiva o la perdita di URL importanti devono bloccare il rilascio. Una lieve incoerenza grafica può invece entrare in un elenco di interventi successivi con una scadenza, purché non ostacoli l’attività dell’utente.
- Nominate chi ha l’autorità finale di procedere o fermare il rilascio.
- Assegnate la responsabilità del ripristino e fissate l’ultimo orario utile per decidere.
- Distinguete i problemi bloccanti dagli interventi successivi già accettati.
- Conservate le prove accanto a ogni criterio di accettazione.
| Elemento | Responsabile | Prova | Regola per la decisione | Nuovo test |
|---|---|---|---|---|
| Modulo di contatto | Responsabile delle vendite | Messaggio ricevuto dalla produzione | Un errore blocca la pubblicazione | Obbligatorio |
| Dominio canonico | Responsabile tecnico | Controllo dell’intestazione e del reindirizzamento | Un host errato blocca la pubblicazione | Obbligatorio |
| Problema minore di spaziatura | Responsabile del design | Schermata | Può entrare nell’elenco degli interventi successivi | Programmato |
| Informativa sulla privacy | Responsabile aziendale | Pagina di produzione approvata | La mancata approvazione blocca la pubblicazione | Obbligatorio |
Approvate contenuti e percorsi degli utenti
Esaminate il sito dal punto di vista di un potenziale cliente. Verificate descrizioni dei servizi, ambito dell’offerta, contatti, sedi e inviti all’azione. Seguite navigazione e collegamenti interni su dispositivi mobili e computer, compresi gli stati vuoti e le pagine di errore.
Definite percorsi precisi invece di limitarvi a una generica revisione visiva. Un visitatore riesce a capire l’offerta, valutare se è adatta, trovare prove pertinenti e inviare una richiesta? Il personale sa spiegare ciò che è stato promesso? Controllate anche documenti scaricabili, numeri di telefono ed email.
Bloccate le modifiche ai testi essenziali durante la finestra di rilascio. Le variazioni dell’ultimo momento prive di revisione possono reintrodurre collegamenti interrotti e affermazioni non approvate.
- Approvate affermazioni, recapiti, inviti all’azione e informazioni legali.
- Controllate menu, ricerca interna se presente, documenti scaricabili e pagine di errore.
- Testate contenuti lunghi e versioni tradotte.
- Registrate le omissioni intenzionali e i relativi responsabili.
| Percorso | Punto di partenza | Esito positivo | Prova |
|---|---|---|---|
| Nuovo potenziale cliente | Pagina di destinazione | Richiesta accettata e conferma ricevuta | Test su mobile e computer |
| Cliente abituale | URL di un servizio salvato | Dettagli aggiornati del servizio | Controllo del reindirizzamento e del contenuto |
| URL errato | Percorso inesistente | Pagina di errore utile con vero codice 404 | Risposta HTTP e revisione della pagina |
| Cambio di lingua | Servizio localizzato | Pagina equivalente nella lingua scelta | Test dell’insieme delle versioni linguistiche |
Verificate che i problemi di accessibilità più gravi siano risolti
Eseguite una verifica manuale mirata dei percorsi principali. Il focus da tastiera deve essere visibile e seguire un ordine logico, i controlli devono rimanere accessibili, le etichette e gli errori dei moduli devono essere comprensibili e lo zoom non deve nascondere azioni essenziali.
Gli Easy Checks del W3C sono volutamente preliminari. Aiutano a individuare le priorità prima della pubblicazione, ma non certificano la conformità. Affiancateli ai risultati dei controlli automatici, ai test dei componenti e a una valutazione più ampia, adeguata al progetto.
Registrate i problemi irrisolti nel documento di approvazione, indicando l’effetto sugli utenti e un responsabile. Percorsi di navigazione che intrappolano l’utente, moduli inutilizzabili e azioni nascoste sono problemi bloccanti, non semplici imperfezioni estetiche.
- Completate il percorso usando la tastiera.
- Controllate focus, titoli, testi alternativi, contrasto e recupero dagli errori dei moduli.
- Testate zoom, adattamento a schermi stretti e contenuti in movimento.
- Verificate nuovamente le correzioni in produzione.
Controllate tecnologia e responsabilità nell’ambiente di produzione
Controllate HTTPS, reindirizzamenti verso l’host canonico, impostazioni dell’ambiente di produzione, gestione degli errori, backup e monitoraggio. Censite i servizi esterni, come moduli, strumenti per il consenso, mappe, video, caratteri e collegamenti al CRM, quindi indicate chi possiede ogni account.
Eseguite i test al di fuori delle sessioni autenticate del team di progetto. Credenziali memorizzate e cookie di amministrazione possono nascondere alcuni errori. Quando possibile, usate una finestra privata del browser e una rete mobile.
Il passaggio di consegne deve comprendere dominio, hosting, repository, account di analisi e strumenti per i motori di ricerca, procedure di recupero, contatti dei fornitori e responsabilità per i rinnovi. Evitate che il sito funzioni soltanto finché è disponibile un determinato collaboratore esterno.
- Controllate il comportamento del dominio e del certificato.
- Verificate i backup e nominate chi possa effettivamente eseguire un ripristino.
- Testate pagine di errore e dipendenze esterne.
- Documentate titolarità degli account e date di rinnovo.
| Risorsa | Responsabile aziendale | Accesso tecnico | Metodo di recupero | Rinnovo o verifica |
|---|---|---|---|---|
| Dominio | Ruolo aziendale nominato | Amministratori presso il registrar | Contatto di recupero documentato | Prima della scadenza |
| Hosting | Ruolo aziendale nominato | Team della piattaforma | Procedura di ripristino e assistenza | Trimestrale |
| Repository | Ruolo aziendale nominato | Manutentori | Amministratore di recupero protetto | A ogni cambiamento del personale |
| Ricezione dei moduli | Responsabile delle vendite | Amministratori tecnici e della posta | Canale di contatto alternativo | Dopo ogni rilascio |
Proteggete la visibilità sui motori di ricerca al momento della pubblicazione
Gli ambienti di sviluppo spesso impediscono la scansione o contengono direttive noindex. Prima della pubblicazione preparate le regole robots previste per la produzione e un elenco preciso delle pagine dalle quali rimuovere noindex. Non eliminate invece le protezioni dall’ambiente di test.
Controllate URL canonici in produzione, mappa dei reindirizzamenti, hreflang se utilizzato, dati strutturati e sitemap. Per i cambiamenti definitivi di URL, Google consiglia reindirizzamenti permanenti lato server. Le pagine eliminate senza una sostituzione pertinente devono restituire un vero codice 404 o 410, invece di rimandare tutte alla homepage.
Verificate le proprietà pertinenti in Search Console e inviate la sitemap. Google precisa che l’invio costituisce un’indicazione, non una garanzia di scansione o indicizzazione. Per un numero ristretto di pagine prioritarie, lo strumento Controllo URL può aiutare nella diagnosi e nell’invio.
- Rimuovete dalla produzione i blocchi di scansione e le direttive noindex non intenzionali.
- Convalidate host canonico, reindirizzamenti e collegamenti interni.
- Inserite nella sitemap URL canonici completi.
- Mantenete accesso e verifica di Search Console dopo la pubblicazione.
Testate misurazione, consenso e ricezione dei contatti
La misurazione deve rispondere a domande aziendali senza promettere una precisione superiore a quella consentita dalla configurazione. Controllate in produzione gli strumenti di analisi, il comportamento del consenso, l’esclusione del traffico interno e gli eventi che rappresentano azioni rilevanti.
Inviate una richiesta realistica attraverso il sito in produzione, dall’inizio alla fine. Verificate convalida, gestione degli errori, stato di accettazione, consegna alla casella o al CRM previsto e procedura di risposta del personale. L’accettazione da parte del fornitore tecnico può non dimostrare l’arrivo nella casella finale: quando possibile, controllate direttamente la destinazione.
Usate dati di prova riconoscibili e sicuri. Non inserite nei moduli password, dati dei clienti o informazioni riservate.
- Verificate che il consenso corrisponda alla configurazione approvata.
- Controllate visualizzazioni di pagina ed eventi di conversione concordati.
- Testate un invio riuscito e un percorso di errore del modulo.
- Accertatevi che il team destinatario riconosca i nuovi contatti e sappia gestirli.
| Segnale | Test in produzione | Interpretazione aziendale | Responsabile |
|---|---|---|---|
| Modulo accettato | Inviare e controllare la conferma | Il sistema ha accettato la richiesta di consegna | Responsabile tecnico |
| Messaggio ricevuto | Controllare la destinazione prevista | Il passaggio operativo funziona | Responsabile delle vendite |
| Evento di conversione | Controllare il debug o il rapporto di analisi | La misurazione si è attivata con il consenso previsto | Responsabile dell’analisi |
| Consegna non riuscita | Simulare un errore sicuro, se supportato | L’utente riceve indicazioni sincere per proseguire | Responsabile tecnico |
Decidete se procedere dopo una verifica in produzione
Organizzate la verifica in due fasi. Prima del rilascio, approvate contenuti, regole di migrazione, configurazione e percorsi. Dopo il rilascio, controllate risposte HTTP effettive, dominio canonico, moduli, consenso, sitemap e reindirizzamenti prioritari. Le prove nell’ambiente di test non sostituiscono quelle in produzione.
La verifica deve essere abbastanza breve da poter essere eseguita e abbastanza rigorosa da servire davvero. Ogni riga deve indicare responsabile, stato e collegamento alla prova. Uno stato sconosciuto non equivale a un esito positivo.
Se il ripristino causasse più danni di una correzione controllata, chi decide può scegliere un rilascio limitato. In tal caso devono essere espliciti l’eccezione, l’impatto sugli utenti e la scadenza per risolverla.
- Prima fase: configurazione, contenuti, migrazione e preparazione dell’accettazione.
- Seconda fase: risposte in produzione, attività degli utenti e consegna dei messaggi.
- Richiedete una prova per ogni stato positivo.
- Condividete l’elenco firmato delle eccezioni con il team operativo.
Gestite i primi 30 giorni sulla base di dati concreti
La pubblicazione apre un periodo operativo. Seguite un calendario prestabilito, invece di osservare continuamente i pannelli di controllo o aspettare i reclami. Il programma seguente è un modello organizzativo, non una tempistica universale di recupero.
Il primo giorno controllate errori critici, ricezione dei moduli, reindirizzamenti principali e strumenti di analisi in produzione. Nella prima settimana esaminate segnali di scansione e indicizzazione, commenti degli utenti e difetti ad alto impatto. Al quattordicesimo e al trentesimo giorno date priorità ai problemi ricorrenti, alle lacune nei contenuti e ai dati sulle prestazioni.
I dati sul campo dei Core Web Vitals si accumulano grazie alle visite reali e vanno interpretati considerando percentile e gruppo di pagine appropriati. Non promettete che la visibilità sui motori di ricerca si stabilizzi entro una data fissa. Google segnala che le migrazioni possono richiedere tempo mentre le pagine vengono nuovamente scansionate e indicizzate.
- Giorno 1: verificate percorsi principali e monitoraggio degli errori.
- Giorni da 2 a 7: controllate contatti, reindirizzamenti, segnali di scansione e segnalazioni urgenti.
- Giorno 14: valutate problemi ricorrenti e responsabili.
- Giorno 30: chiudete la gestione del lancio e approvate l’elenco degli interventi migliorativi.
| Frequenza | Verifica | Condizione di escalation | Risultato |
|---|---|---|---|
| Giorno della pubblicazione | Moduli, errori, reindirizzamenti, dominio | Un’attività essenziale non funziona | Correzione, ripristino o limitazione documentata |
| Prima settimana | Segnali di indicizzazione, richieste, commenti | Pagine importanti o contatti non funzionano | Problema prioritario |
| Giorno 14 | Difetti ricorrenti e lacune nei contenuti | Il problema influenza le decisioni degli utenti | Piano di intervento con un responsabile |
| Giorno 30 | Prestazioni, ricerca, qualità dei contatti, interventi aperti | Un rischio resta senza responsabile | Revisione operativa e nuove priorità |
LE VOSTRE DOMANDE, LE RISPOSTE
Domande frequenti
Quali problemi devono bloccare la pubblicazione di un sito?
Gli errori nelle attività essenziali degli utenti, nella ricezione di contatti o pagamenti, nella configurazione del dominio canonico, nell’approvazione della privacy, nella sicurezza o nella conservazione di URL importanti giustificano spesso la decisione di fermarsi. Definite in anticipo i problemi bloccanti specifici del progetto.
È sufficiente testare il modulo di contatto nell’ambiente di prova?
No. Testate in produzione l’intero percorso, la conferma e la destinazione effettiva, perché impostazioni e collegamenti per la consegna possono cambiare tra gli ambienti.
L’invio di una sitemap garantisce l’indicizzazione?
No. Google descrive l’invio della sitemap come un’indicazione. Aiuta la scoperta e il monitoraggio delle pagine, ma non garantisce la scansione o l’indicizzazione.
Quanto tempo serve perché il posizionamento si stabilizzi dopo il rifacimento?
Non esiste un termine garantito. I tempi di nuova scansione e indicizzazione dipendono dal sito e dalle modifiche. Controllate i segnali tecnici e i risultati per gli utenti senza inventare una scadenza per il recupero.
Cosa deve comprendere la verifica dei primi 30 giorni?
Errori critici, ricezione dei contatti, reindirizzamenti, segnali di indicizzazione, commenti degli utenti, dati sulle prestazioni e un elenco di interventi con responsabili. Adattate la frequenza dei controlli al rischio e al traffico.
PER APPROFONDIRE
Fonti e riferimenti
- Google Search Central: spostamenti di siti con modifiche agli URL
- Google Search Central: pubblicazione di un nuovo sito di e-commerce
- Google Search Central: creare e inviare una sitemap
- Google Search Central: risolvere gli errori di scansione
- web.dev: definizione delle soglie dei Core Web Vitals
- W3C WAI: Easy Checks
