Metodo
Cosa guardare nel diff prima di accettare una revisione
Prima di accettare una revisione, il diff va letto come un controllo di modifica, non come una misura di visibilità: si verificano riga per riga cosa cambia, perché cambia e se il cambiamento è coerente con la richiesta. Qui trovi una checklist operativa proposta da RankAI per leggere un diff senza fermarsi al colore verde o rosso.
Prima di accettare una revisione, nel diff si guarda una cosa sola: cosa cambia rispetto alla versione precedente e se quel cambiamento è coerente con la richiesta. Il diff è un controllo di modifica, non una misura di visibilità: non dice quanto un contenuto sia visibile nei motori, dice solo quali righe sono state toccate. In concreto, se un collaboratore propone una modifica a una pagina, apri il diff, leggi le righe aggiunte e rimosse, e chiediti se ognuna risponde a un'istruzione precisa. Se una riga cambia senza una ragione riconducibile alla richiesta, quella riga va discussa prima di accettare.
Perché il diff non è una misura di visibilità
Chi lavora sui contenuti tende a confondere due controlli diversi. Il diff risponde alla domanda «cosa è cambiato nel testo?». La visibilità risponde alla domanda «come appare quel testo a chi cerca?». Sono due osservazioni separate e non si sostituiscono. Anche la frase di ricerca di riferimento, come si misura la visibilità AI, appartiene al secondo controllo: non si ricava leggendo un diff. Noi di RankAI teniamo distinti i due piani, perché mescolarli porta ad accettare modifiche per impressione invece che per verifica.
La checklist operativa proposta da RankAI
Quella che segue è una proposta operativa di RankAI, non uno standard universale: serve a rendere il controllo del diff ripetibile. Ogni passo ha un criterio verificabile, così la decisione non dipende dal gusto di chi legge.
- Leggi le righe rimosse prima di quelle aggiunte. Criterio: per ogni riga rimossa devi poter indicare la frase della richiesta che la giustifica. Se non la trovi, la rimozione è fuori perimetro e va segnalata.
- Verifica che ogni aggiunta abbia un riferimento nella richiesta. Criterio: nessuna riga aggiunta deve introdurre affermazioni, numeri o nomi che la richiesta non prevede. Se compare un dato non richiesto, va rimosso o giustificato esplicitamente.
- Controlla la coerenza tra titolo, apertura e corpo. Criterio: la modifica non deve spostare il significato dell'apertura rispetto al titolo. Se il titolo promette una cosa e il nuovo testo ne dice un'altra, il diff è incoerente anche se ogni singola riga sembra corretta.
- Isola le modifiche non testuali. Criterio: spazi, formattazione e ritorni a capo vanno separati dalle modifiche di contenuto. Un diff pieno di rumore visivo nasconde i cambiamenti reali e va ripulito prima della lettura.
- Registra la decisione. Criterio: dopo l'accettazione devi poter dire, per ogni blocco modificato, se è stato accettato, rifiutato o rinviato. Se non sai ricostruire questa mappa, il controllo non è concluso.
Il punto che spesso sfugge è che il diff non è un documento di qualità: è una fotografia delle differenze. Una modifica può essere tecnicamente pulita, con poche righe toccate e nessun errore di formattazione, eppure essere sbagliata rispetto all'obiettivo editoriale. Per questo la nostra proposta separa due giudizi: la lettura del diff, che è meccanica e verificabile riga per riga, e la valutazione del contenuto, che richiede di conoscere la richiesta e il contesto della pagina. Chi accetta una revisione guardando solo il colore verde o rosso sta saltando il primo giudizio e fingendo di aver fatto il secondo. Un diff letto bene, invece, lascia una traccia: sai quali righe sono cambiate, perché, e cosa hai deciso. È questa tracciabilità, non l'impressione di aver letto tutto, che rende una revisione accettabile. Se manca, la revisione va riaperta prima di procedere.
Un limite da tenere presente
Il diff mostra solo ciò che è cambiato tra due versioni: non dice se la modifica migliora la pagina per chi legge, né se il testo sarà visibile in un motore. Quelle domande richiedono altri controlli, e vanno poste separatamente. Quando una misura di visibilità non c'è, noi la mostriamo come N/D, mai come zero: l'assenza di un dato non è un dato negativo. Lo stesso vale per il diff: l'assenza di una riga nella richiesta non autorizza a inventarne il motivo.
Per capire come RankAI tratta questi controlli separati, vedi la pagina di approfondimento.