Checklist SEO pre-pubblicazione

Il controllo qualità (QA) pre-pubblicazione è il gate di rilascio finale nel processo SEO . È il punto in cui si incontrano tre contratti: conformità al tipo di pagina, uso corretto degli elementi e completamento del lavoro preliminare di ricerca, prove, implementazione e revisione. Una pagina che non supera qualsiasi elemento applicabile viene restituita per correzione.

Gate: QA finale pre-pubblicazione. Timebox: 60–90 minuti per una pagina standard; aggiungi tempo specialistico per dichiarazioni regolamentate, di sicurezza, finanziarie, mediche o tecnicamente consequenziali. Responsabile: un editor, responsabile dei contenuti o responsabile SEO che non ha effettuato l’implementazione finale e ha l’autorità di bloccare il rilascio.

Una checklist morbida non è una checklist perché “quasi fatto” non ha un significato stabile. Con una scadenza, le formulazioni opzionali diventano un aiuto mnemonico e i controlli difficili scompaiono. Nomina l’autorità di rilascio prima dell’inizio della QA. Il responsabile QA può approvare o bocciare; solo il capo dei contenuti designato, il responsabile SEO o equivalente può approvare un’eccezione scritta o dichiarare un elemento non applicabile. Non possono derogare a una dichiarazione falsa, a un elemento obbligatorio mancante, a una risorsa segnaposto, a un canonico rotto o a un’indicizzabilità bloccata per rispettare una data.

Perché questo gate esiste e perché opera qui

Questo gate consuma le specifiche del tipo di pagina approvate, i contratti degli elementi, il registro delle fonti, la copia finale, il candidato implementato e le approvazioni specialistiche. Viene eseguito dopo che questi input sono stati congelati perché la QA non può verificare un bersaglio in movimento, e prima della pubblicazione perché un difetto può essere copiato non appena l’URL è live.

Una QA precedente certifica una bozza che potrebbe cambiare. Saltarla lascia gli auditor successivi incapaci di distinguere tra deriva della pagina, specifica modificata e pagina mai controllata. La QA post-pubblicazione trasforma correzioni economiche in difetti pubblici.

Input e output

L’output è un contratto, non un messaggio in chat. L’editore deve poter agire su di esso senza ricostruire la revisione.

La checklist

Ogni elemento seguente include l’azione, il motivo, il metodo, lo strumento e la condizione osservabile di completamento. “Controllato SEO” o “sembra a posto” non sono mai prove accettabili.

1. Conformità al tipo di pagina

Conferma il tipo di pagina e l’ambito selezionati. Cosa: abbina il candidato a una voce nella libreria dei tipi di pagina e rimuovi il materiale appartenente a un tipo correlato. Perché: il tipo di pagina determina intento, struttura, prove e comportamento di conversione. Come: etichetta ogni sezione con la decisione del lettore che supporta e confrontala con lo scopo e le esclusioni del tipo. Strumento: brief approvato, mappa tematica e pagine dei tipi di pagina. Completato quando: esattamente un tipo primario è registrato, l’apertura, il corpo e il CTA lo servono, e zero sezioni esistono esclusivamente per il compito di un altro tipo.

Traccia la struttura richiesta e le fasce di parole. Cosa: mappa ogni sezione richiesta sul candidato renderizzato e conta le sue parole rispetto alla fascia specificata. Perché: le sezioni mancanti creano domande senza risposta, mentre la lunghezza incontrollata nasconde lacune dietro il volume. Come: utilizza una matrice requisito-intestazione e conteggi automatizzati, quindi ispeziona manualmente i casi limite. Strumento: specifica del tipo di pagina, sorgente e pagina renderizzata. Completato quando: zero sezioni richieste sono mancanti e ogni sezione è all’interno del suo minimo e massimo dichiarati.

2. Conformità degli elementi

Verifica elementi, posizioni e parametri. Cosa: confronta la mappa degli elementi con la sorgente e il render. Perché: posizione e campi fanno parte della funzione; una risposta diretta sepolta non risponde più per prima, e parametri malformati possono rompere l’output. Come: ispeziona dall’alto verso il basso e convalida campi consentiti, valori, annidamento e sintassi. Strumento: specifiche degli elementi, validatore e browser. Completato quando: ogni elemento obbligatorio è nella sua posizione richiesta, ogni parametro è valido e nessun duplicato inspiegato rimane.

Applica la precedenza degli elementi tipizzati. Cosa: applica le regole di scrittura degli elementi ovunque un passaggio abbia uno scopo registrato. Perché: il testo libero può sembrare simile ma non può portare l’identità del componente, i campi, il comportamento di accessibilità o l’output strutturato. Come: indica il compito di ogni blocco come verbo — definire, avvisare, confrontare, istruire, riassumere — e verifica la presenza di un elemento corrispondente. Strumento: libreria degli elementi e ispettore della sorgente. Completato quando: zero passaggi utilizzano testo libero dove un elemento tipizzato è obbligatorio.

3. Qualità dei contenuti

Testa la risposta in isolamento. Cosa: leggi il blocco risposta diretta senza la sua intestazione o i paragrafi circostanti. Perché: i sistemi di ricerca e recupero AI possono estrarre solo quel passaggio. Come: verifica che nomini il soggetto, risponda alla domanda, includa la qualificazione necessaria e non si basi su “questo”, “esso” o “come sopra”. Strumento: vista testo isolato e revisore umano. Completato quando: la risposta è autonoma, accurata e all’interno della sua fascia specificata di 40–60 parole quando quell’elemento è richiesto.

Verifica dichiarazioni, linguaggio e unicità. Cosa: traccia le dichiarazioni sostanziali alle prove, spiega il gergo al primo utilizzo e confronta il candidato con pagine che servono lo stesso intento. Perché: le dichiarazioni non supportate danneggiano la fiducia, mentre i quasi-duplicati competono e derivano. Come: segnala nomi, date, numeri, dichiarazioni causali, comportamento del prodotto e candidati alla similarità; supporta, qualifica, consolida o rimuovili. Strumento: registro delle prove, fonti primarie, ricerca nel sito e report di similarità. Completato quando: zero dichiarazioni sostanziali mancano di supporto, zero termini specialistici rimangono inspiegati e nessuna pagina esistente risponde allo stesso intento e ambito senza un piano di consolidamento.

4. Frontmatter

Convalida i campi di identità e anteprima. Cosa: applica le specifiche del frontmatter a titolo, descrizione, parole chiave, entity e collegamenti al tipo di pagina. Perché: questi campi guidano il routing, le anteprime, gli schemi e le relazioni senza leggere il corpo. Come: esegui la convalida dei campi e della lunghezza, quindi confronta il significato con la pagina visibile. Strumento: linter per frontmatter e anteprima umana. Completato quando: il titolo è unico e accurato, la descrizione è di 150–160 caratteri, le parole chiave contengono 6–8 voci pertinenti e entity corrisponde al contratto del tipo di pagina.

Verifica i campi di governance e FAQ. Cosa: controlla date, autore, revisore, proprietà e struttura FAQ visibile rispetto al frontmatter. Perché: i record anonimi impediscono la responsabilità, mentre la deriva delle FAQ fa sì che le risposte visibili e strutturate siano in disaccordo. Come: confronta i campi con la traccia di rilascio e il testo visibile normalizzato. Strumento: parser della sorgente, tracker e pagina renderizzata. Completato quando: le date e i responsabili richiesti sono validi, il revisore umano è nominato dove richiesto, il conteggio delle FAQ soddisfa il minimo del tipo, ogni coppia corrisponde e zero voci nascoste o vuote rimangono.

5. Dati strutturati

Richiedi lo schema corretto. Cosa: conferma che il markup schema applicabile esista per la pagina e i suoi elementi visibili. Perché: un markup mancante o generico scarta il significato leggibile dalla macchina che il modello di contenuto già fornisce. Come: confronta i tipi e le proprietà emessi con i contratti del tipo di pagina e degli elementi. Strumento: HTML renderizzato e validatore schema. Completato quando: ogni tipo di schema richiesto è presente una volta, le proprietà richieste sono populate e nessun tipo non applicabile viene emesso.

Convalida la parità, non solo la sintassi. Cosa: confronta nomi, date, autore, entità, FAQ, passaggi e dichiarazioni dello schema con i contenuti visibili. Perché: una sintassi valida può comunque descrivere informazioni invisibili o contraddittorie. Come: valida JSON-LD, quindi confronta i valori con la pagina. Strumento: test dei dati strutturati e revisione umana. Completato quando: ci sono zero errori e zero fatti nello schema che contraddicono o superano i contenuti visibili.

6. Collegamenti interni

Collega verso l’alto e verso l’esterno. Cosa: fornisci un percorso alla pillar pertinente e percorsi contestuali ai nodi correlati. Perché: la gerarchia aiuta lettori e crawler a capire dove appartiene la pagina, mentre i collegamenti laterali proseguono il compito del lettore. Come: mappa ogni collegamento interno a una genuina domanda successiva piuttosto che riempire una quota. Strumento: grafo dei link e pagina renderizzata. Completato quando: la pagina ha almeno un collegamento alla sua pillar, almeno un collegamento laterale pertinente dove esiste un nodo correlato, e almeno una pagina esistente si collega ad essa prima o al momento della pubblicazione in modo che non sia orfana.

Ispeziona destinazioni e ancore. Cosa: apri ogni destinazione e rivedi il suo testo ancora . Perché: un URL plausibile potrebbe essere mancante, reindirizzato o non correlato, e le etichette generiche nascondono lo scopo della destinazione. Come: esegui un controllo dei collegamenti interni, quindi ispeziona manualmente le ancore nel contesto della frase. Strumento: crawler e browser. Completato quando: zero collegamenti interni restituiscono un errore, ogni destinazione supporta la dichiarazione circostante e nessun “clicca qui” isolato, URL grezzo o ancora di corrispondenza esatta fuorviante rimane.

7. Media

Verifica risorse, alternative e attualità. Cosa: conferma che ogni immagine esista, abbia un testo alt significativo o un’alternativa vuota giustificata, e rifletta l’interfaccia corrente. Perché: media rotti, vaghi, segnaposto o obsoleti rimuovono informazioni e possono rendere inutilizzabili le istruzioni. Come: disabilita le immagini, ispeziona i percorsi, riproduci i passaggi del prodotto e confronta etichette, valori, ritaglio e oscuramento. Strumento: controllo risorse, audit di accessibilità, prodotto live e browser. Completato quando: zero risorse sono mancanti o sono segnaposto, le alternative sono accurate e ogni screenshot rappresenta il passaggio corrente.

8. Rilascio tecnico

Verifica routing, indicizzabilità e sostituzione. Cosa: controlla slug, un URL canonico auto-referenziante, stato, comportamento robots, indicizzabilità e redirect. Perché: i contenuti non possono performare sulla route sbagliata, dietro noindex o dopo che vecchi URL sono stati abbandonati. Come: ispeziona l’head renderizzato e la risposta, confronta il registro e segui ogni route sostituita. Strumento: controllo header, mappa dei redirect, ispettore della sorgente e URL Inspection. Completato quando: l’URL approvato restituisce 200 con un canonico previsto e nessun blocco; ogni URL sostituito fa un salto permanente verso la sostituzione valida più vicina.

Testa la stabilità mobile. Cosa: ispeziona la lettura a larghezza ridotta, l’interazione, l’overflow e il Cumulative Layout Shift . Perché: i componenti che funzionano su desktop possono nascondere controlli, tagliare tabelle o spostare contenuti mentre i media si caricano. Come: testa larghezze mobili rappresentative e carica la pagina con limitazione della banda. Strumento: modalità dispositivo del browser e report delle prestazioni. Completato quando: tutti i contenuti e i controlli rimangono utilizzabili senza overflow orizzontale della pagina e il CLS misurato è 0,1 o inferiore.

9. Prontezza AI

Testa l’estrazione e l’HTML iniziale. Cosa: ispeziona risposte, definizioni, fatti chiave, confronti e conclusioni come passaggi indipendenti nell’HTML fornito dal server. Perché: i sistemi di recupero possono selezionare un passaggio e potrebbero non eseguire codice lato client. Come: recupera l’HTML iniziale, rimuovi il contesto circostante e verifica nomi di entità, qualificatori, unità e pronomi. Strumento: recupero HTML, estrattore di passaggi, browser e audit AmICited. Completato quando: ogni fatto prioritario è presente senza JavaScript e mantiene da solo il suo soggetto, significato e limitazioni.

Esponi la struttura procedurale. Cosa: verifica che le coppie FAQ e i passaggi ordinati siano codificati come campi riconoscibili e rimangano visibili. Perché: intestazioni e riquadri stilizzati possono sembrare corretti mentre le macchine ricevono prosa non strutturata. Come: confronta l’output degli elementi, la struttura accessibile e lo schema con la sequenza visibile. Strumento: albero di accessibilità e validatore dei dati strutturati. Completato quando: ogni FAQ richiesta è leggibile dalla macchina come coppia domanda-risposta e ogni procedura richiesta preserva i passaggi ordinati nell’output visibile e strutturato.

Strumenti in AmICited

Utilizza il prodotto per ispezionare il candidato e stabilire le prove di consegna; non sostituisce il giudizio umano.

1. Apri l’audit di prontezza per agenti insieme ad Accessibilità AI e prontezza per agenti per ispezionare accessibilità, raggiungibilità dei crawler, copertura della sitemap e contenuti leggibili dagli agenti.
2. Ispeziona l’URL candidato con URL Inspection per verificare lo stato dell’indice, l’usabilità mobile e il verdetto sui rich result. Assegna l’ispezione live nella consegna per un nuovo URL.
3. Apri l’audit di freschezza con Content Freshness per fornire alle pagine sensibili al tempo un segnale di manutenzione e una data di prossima revisione. La cronologia inizia quando inizia il tracciamento; nessuna cronologia non significa nessuna modifica.
4. Utilizza SEO MCP tramite la connessione dell’area di lavoro per controlli ripetibili di sola lettura su URL, freschezza, Web Vitals e accessibilità. Conserva l’output o l’identificativo dell’esecuzione.

Automazione: scripta i controlli deterministici, preserva le decisioni umane

Un controllo che può essere scriptato ma rimane manuale verrà saltato sotto pressione. Automatizza i risultati stabili e osservabili dalla macchina; richiedi un umano per scopo, verità e contesto.

L’automazione scrive prove, non approvazione. Un fallimento blocca il gate; uno script che passa non approva le colonne umane.

Regole decisionali

“Negativo” deve essere osservabile. Utilizza queste soglie a meno che il tipo di pagina o l’elemento selezionato non ne definisca una più restrittiva; il contratto più specifico prevale.

N/A non è un superamento più morbido. È valido solo quando l’elemento realmente non si applica — ad esempio, nessun redirect è necessario perché nessun URL viene sostituito — e il registro ne spiega il motivo. Un’eccezione deve nominare la regola modificata, la ragione aziendale, il rischio, l’approvatore, il responsabile della correzione e la scadenza. L’autorità di rilascio la firma; il revisore QA non auto-approva.

Documento consegnabile: il registro di superamento

Allega un registro immutabile al candidato esatto. Un audit successivo deve poter distinguere “mai controllato” da “controllato e superato con la versione 1 delle specifiche”. Memorizza campi strutturati piuttosto che uno screenshot di spunte verdi.

Percorso / canonico della pagina:
ID del candidato al rilascio o hash del contenuto:
Tipo di pagina ed entità:
Versione delle specifiche:
Responsabile QA:
Autorità di rilascio:
Iniziato / completato (timestamp):

Controlli:
- Gruppo / elemento:
- Risultato: PASS | FAIL | N/A
- Prove: output del validatore, posizione nella fonte, destinazione o osservazione
- Controllato da / il:

Eccezioni:
- Regola e ambito:
- Motivo e rischio:
- Approvatore:
- Responsabile correzione / scadenza:

Decisione: PASS — PUBBLICA | FAIL — BLOCCA
Responsabile verifica live e scadenza:
Prossima data di revisione manutentiva:

Un registro di superamento è solo aggiuntivo. Una specifica o un candidato modificato ricevono un nuovo audit, non una cronologia riscritta.

Cosa succede in caso di fallimento

Il fallimento avvia un ciclo di correzione, non una negoziazione nel thread di revisione.

1. Il responsabile QA segna il candidato come FAIL — BLOCCA, registra le prove e si ferma al punto in cui continuare significherebbe testare una versione destinata a cambiare.
2. Il responsabile dei contenuti corregge i fallimenti di tipo di pagina, elementi, copia, metadati e prove. Il responsabile dell’implementazione corregge i fallimenti di schema, link, media, routing, rendering e automazione. Uno specialista ricontrolla le dichiarazioni nel proprio dominio.
3. Il correttore identifica ogni superficie modificata. Il responsabile QA riesegue l’elemento fallito, i suoi elementi dipendenti e qualsiasi gruppo interessato dalla modifica. Una risposta riscritta, ad esempio, riapre dichiarazioni, conformità degli elementi, parità dello schema ed estrazione AI.
4. Il responsabile QA crea un nuovo risultato con timestamp. La pubblicazione rimane bloccata fino a quando ogni elemento applicabile non supera e ogni N/A o eccezione ha un’autorità valida.

L’autore non certifica la propria correzione. La QA possiede il registro, la produzione possiede le correzioni, gli specialisti possiedono l’approvazione del dominio e l’autorità di rilascio possiede le eccezioni.

Cosa va storto

• Trattare il gate come correzione di bozze. La grammatica può essere impeccabile mentre la pagina utilizza il tipo di pagina sbagliato, contraddice il suo schema o non può essere indicizzata.
• Testare la sorgente invece del candidato al rilascio. Un Markdown valido non prova che i template abbiano emesso il canonico previsto, la struttura accessibile o il layout responsive.
• Rendere ogni elemento manuale. I revisori cliccano ripetutamente controlli deterministici finché una scadenza non insegna loro a saltare la lista.
• Rendere ogni elemento automatizzato. Un validatore verde non può decidere se le prove supportano una dichiarazione causale o se un confronto risponde alla decisione del lettore.
• Accettare “risolveremo dopo il lancio”. Questo trasforma un gate pre-pubblicazione in un backlog non documentato e cancella il significato di PASS.
• Permettere alla stessa persona di implementare e approvare. L’autoverifica trascura le supposizioni perché il revisore ricorda il comportamento previsto piuttosto che osservare l’output effettivo.

Passaggio di consegne

Lo stato successivo è la pubblicazione e la verifica live. La QA consegna il candidato approvato, il registro PASS, la route canonica, la mappa dei redirect, la finestra di rilascio e le eccezioni approvate. L’editore restituisce l’URL live e l’orario di deployment; il responsabile della verifica live ripete i controlli su stato, canonico, indicizzabilità, redirect, schema, link, media, mobile e CTA.

Se la produzione differisce, i controlli interessati vengono riaperti. Se corrisponde, aggiungi l’URL live e le prove senza sovrascrivere il risultato del candidato. Gli audit successivi utilizzano la versione delle specifiche memorizzata per distinguere la deriva da uno standard modificato.

FAQ

Domande frequenti

PASS significa che il candidato è conforme al contratto corrente con prove ispezionabili. Qualsiasi altra cosa è un blocco. Il CTA di chiusura del layout academy segue questa FAQ.