Inizia dalle pagine desiderate e prova riutilizzabile
Elenca le pagine pubbliche che vuoi che gli utenti trovino tramite ricerca: prodotti chiave, articoli, categorie e URL spostati. Per ciascuna registra l'URL preferito, la risposta attesa, l'indexability, il template, l'owner e la priorità. Tieni separate le esclusioni legittime.
Cattura una risposta non autenticata, le intestazioni, il percorso dei redirect, il sorgente della pagina, la vista renderizzata, lo stato dei link interni e lo stato nella sitemap per URL rappresentativi. Campiona ogni template e pattern di URL. L'evidenza è datata: un'impostazione CDN, un deployment, un livello di consenso o una personalizzazione possono cambiarla in seguito.
Una homepage che passa i test non dimostra che listing, varianti prodotto o route localizzate funzionino.
Conserva intestazioni datate e prove renderizzate così da poter comparare correzioni e regressioni successive.
Rendi l'indicizzabilità una decisione deliberata
L'indicizzabilità significa che una pagina può essere inclusa in un indice di ricerca; non è la stessa cosa del crawling o del posizionamento. Controlla le direttive meta robots nell'HTML e l'intestazione di risposta X-Robots-Tag. La direttiva noindex dice ai motori di ricerca di non mostrare una pagina; X-Robots-Tag si applica anche a file non-HTML come PDF.
Revisiona robots.txt separatamente. Un crawler deve poter accedere a una pagina per trovare la direttiva noindex, quindi bloccare quell'URL può impedire che la direttiva venga vista. Verifica la risposta pubblica distribuita perché impostazioni CMS e flag di ambiente possono aggiungere regole. Noindex non è controllo di accesso: proteggi materiale sensibile con autenticazione e una revisione di sicurezza appropriata.
Segnala noindex, risposte di login, riferimenti a staging e asset essenziali bloccati sulle pagine destinate all'indicizzazione.
Un'intestazione HTTP può trasportare una direttiva anche quando non esiste un head HTML.
Mantieni un unico URL preferito coerente
La canonicalizzazione individua l'URL preferito tra versioni duplicate o molto simili, come HTTP e HTTPS, host differenti, parametri di tracciamento, filtri o pagine di stampa. Confronta l'elemento canonical, i link interni, l'URL in sitemap e la destinazione del redirect. Per una pagina indicizzabile dovrebbero normalmente identificarsi lo stesso URL preferito assoluto.
Usa un redirect permanente lato server quando ritiri un duplicato. Google descrive i redirect permanenti e rel=canonical come segnali forti, mentre l'inclusione in sitemap è un segnale più debole; segnali allineati rafforzano la preferenza. Non usare robots.txt per canonicalizzare né dare a una pagina canonicali concorrenti. Un canonical che si autoreferenzia aiuta a dichiarare la versione preferita, ma la selezione finale da parte del motore di ricerca resta fuori dal tuo controllo.
Documenta le varianti, il target preferito, il controllo richiesto e un owner.
Testa le mappature vecchio→nuovo prima di una migrazione e mantieni pronta una modifica di redirect reversibile.
Verifica codici di stato e comportamento dei redirect
I codici di stato dicono ai browser e ai crawler cosa è successo. Le pagine live importanti dovrebbero restituire una risposta 2xx significativa con il contenuto previsto. Una pagina senza un sostituto rilevante dovrebbe restituire un autentico 404 o 410; il contenuto spostato dovrebbe raggiungere il suo sostituto più pertinente. Una pagina 200 che mostra solo un errore può essere trattata come soft 404.
Registra ogni hop di redirect. Google in genere segue fino a 10 hop per il crawling generale, ma le catene aggiungono latenza e fragilità. Google segnala che risposte 5xx e 429 possono rallentare temporaneamente il crawling e che errori server persistenti possono infine rimuovere URL indicizzati. Indaga sulle cadute ricorrenti con l'owner di ingegneria attraverso application, CDN, origin, cache, dipendenze e layer di deployment.
Salva URL originale, hop, codici, URL finale e stato atteso.
Rimuovi regole sovrapposte di CMS, CDN, host, localizzazione o slash invece di aggiungere un altro hop.
Valida il rendering JavaScript e le route
Ispeziona sia l'HTML iniziale sia una vista renderizzata per i template chiave. Conferma che il contenuto principale, gli heading, i link, il canonical, le direttive robots e lo stato esistano dopo il rendering. Google descrive fasi separate di crawl, render e indicizzazione e dice che il contenuto non visibile nell'HTML renderizzato non può essere indicizzato.
Usa elementi anchor con valori href per la navigazione. Route basate solo su fragment che caricano contenuti distinti non sono affidabili per la scoperta. Richiedi direttamente prodotti, articoli e URL filtrati non esistenti. Le applicazioni client-side hanno bisogno di un reale stato di errore; Google documenta il routing verso un 404 server o l'aggiunta di noindex per evitare soft 404. Il rendering lato server o il prerendering possono aiutare, ma verifica la risposta effettivamente distribuita.
Controlla HTML di risposta, HTML renderizzato e la vista browser umana per differenze materiali.
Prediligi l'HTML sorgente; se il JavaScript lo imposta, assicurati che ci sia un solo canonical non conflittuale.
Mantieni sitemap e link interni puliti
Una sitemap è una mappa di scoperta, non un comando di indicizzazione. Includi URL preferiti canonical di successo e previsti; escludi redirect, errori, pagine noindex, duplicati di parametri e URL protetti. Google raccomanda URL assoluti completamente qualificati e tratta l'inclusione in sitemap come un suggerimento canonico, non una garanzia.
Valida la sitemap e confrontala con la lista delle pagine destinate all'indicizzazione e con la navigazione. Google documenta la codifica UTF-8 e un limite di 50 MB non compresso o 50.000 URL per sitemap. Per siti più grandi, suddividi in gruppi utili e usa un index. Aggiorna lastmod solo per modifiche significative e verificabili della pagina.
Indaga differenze significative tra URL previsti, voci di sitemap e link interni.
Controlla la sitemap generata e un campione di URL elencati dopo cambi di routing o del CMS.
Misura le prestazioni e istituzionalizza l'audit
Usa dati field quando disponibili e test di laboratorio controllati per investigare i Core Web Vitals: Largest Contentful Paint per il caricamento, Interaction to Next Paint per la reattività e Cumulative Layout Shift per la stabilità visiva. Segmenta per tipo di pagina e dispositivo perché le medie possono nascondere un template ad alto valore rotto.
Traccia consegne lente o instabili attraverso immagini, CSS e JavaScript, tag di terze parti, font, embed e caching. Fai una modifica misurata per volta, poi ricontrolla rendering e flussi utente. I dati field riflettono utenti reali; i dati lab aiutano nella riproduzione. Nessuno dei due predice ogni futuro crawler o visitatore. Ripeti un controllo di regressione focalizzato dopo rilasci rischiosi e un audit più completo dopo migrazioni o cambi di piattaforma.
Ripara i fallimenti sui template critici per i ricavi o ad alto utilizzo prima di piccoli guadagni di punteggio altrove.
Ricontrolla risposta, canonical, contenuto renderizzato, stato della sitemap e evidenze di performance rilevanti prima di chiudere.