Risposte
Correggere un link interno verso una pagina che non esiste
Un link interno che punta a una pagina inesistente si corregge decidendo prima cosa è successo alla destinazione: se la pagina è stata spostata, eliminata o sostituita. Da quella scelta dipendono la nuova destinazione, il tipo di correzione e la riga da annotare nel registro.
La regola decisionale è una sola: prima di toccare il link, stabilisci cosa è successo alla pagina di destinazione. Se è stata spostata, il link va aggiornato verso il nuovo URL. Se è stata eliminata, il link va rimosso o sostituito con un riferimento pertinente. Se è stata sostituita da un contenuto diverso, il link va ripuntato solo se il nuovo contenuto risponde allo stesso bisogno di chi clicca. Senza questa distinzione, aggiornare e redirigere diventano la stessa azione e il problema torna. Un esempio: un articolo linka /guide/impostazioni-api, che restituisce 404; la guida è stata spostata in /guide/configurazione-api, quindi il link si aggiorna e si annota la modifica.
Un caso concreto: dal 404 alla riga di registro
Immagina un articolo sui limiti delle API che contiene un link verso /guide/impostazioni-api. Aprendo l'URL si ottiene un 404. La prima verifica non è tecnica ma di contenuto: la guida esiste ancora con un altro indirizzo? Se sì, si tratta di uno spostamento e la correzione è l'aggiornamento del link. Se la guida è stata eliminata e nessuna pagina copre lo stesso argomento, il link va tolto o sostituito con un rimando a una pagina realmente pertinente. Se al vecchio indirizzo ora vive un contenuto diverso, il link va ripuntato solo quando quel contenuto serve a chi legge la frase che lo contiene.
La riga di registro, compilata, può essere questa: URL sorgente /articoli/limiti-api; link /guide/impostazioni-api; esito 404; causa: pagina spostata; scelta: aggiornare; nuova destinazione /guide/configurazione-api; stato: corretto. La stessa riga, con causa «eliminata» e scelta «rimuovere», descrive un caso diverso senza ambiguità.
La checklist compilata, non solo elencata
RankAI propone questa checklist operativa, da intendere come metodo di lavoro e non come standard universale. Compilata sul caso precedente, diventa: (1) il link è stato aperto e restituisce 404? Sì. (2) La destinazione esiste con un altro URL? Sì, /guide/configurazione-api. (3) Il contenuto di destinazione risponde allo stesso bisogno della frase che linka? Sì, parla delle stesse impostazioni. (4) La scelta è aggiornare, non redirigere? Sì, perché il link è interno e va corretto alla fonte. (5) La riga di registro riporta sorgente, vecchio URL, esito, causa, scelta e nuova destinazione? Sì. (6) Il link corretto è stato riaperto per verifica? Sì, risponde 200. Una checklist lasciata a metà, con la sola casella «404 risolto», non distingue uno spostamento da una eliminazione e non aiuta la correzione successiva.
Il punto distintivo è che la correzione di un link interno non è un intervento di manutenzione isolato: è una decisione editoriale registrata. Aggiornare, rimuovere o ripuntare sono tre esiti diversi, e il registro serve a rendere leggibile quale dei tre è stato scelto e perché. Se il registro si limita a segnare «corretto», la prossima persona che incontra lo stesso URL non sa se la pagina è stata spostata o cancellata.
Cosa non promettiamo
Non possiamo garantire che una correzione elimini ogni link non valido del sito né che il registro resti allineato senza controlli successivi. La verifica verificabile è una sola: dopo la modifica, il link interno apre una pagina esistente e la riga di registro indica causa, scelta e nuova destinazione. Per il contesto più ampio sulle domande ricorrenti, vedi la pagina di approfondimento.
Perché un confronto non è più leggibile se cambiano i prompt