Audit tecnico di base

Fase P2 · Stadio A — Comprendere
Timebox: 2–4 ore per un passaggio leggero, 1–2 giorni lavorativi per un passaggio standard o 3–8 giorni lavorativi per un passaggio approfondito.
Responsabile: il responsabile SEO tecnico. I responsabili di ingegneria, analytics, contenuti e localizzazione contribuiscono con evidenze e accettano le correzioni nei loro ambiti.

Un audit tecnico di base stabilisce se i motori di ricerca possono raggiungere, interpretare e selezionare gli URL che l’azienda si aspetta vengano mostrati. Il suo ambito copre i controlli di crawl, le risposte HTTP, l’indicizzazione, i canonical, i link, il rendering, il targeting internazionale e la consegna sicura. Il risultato è un registro prioritizzato dei riscontri con responsabili nominati e test di accettazione, non un punteggio.

Perché questa fase si trova qui

Pubblicare su un sito con problemi di crawl o indicizzazione aggrava il danno. I motori di ricerca spesso scoprono un difetto ripetuto su nuovi URL più velocemente di quanto valutino e ricompensino il contenuto. Un template canonical errato può puntare ogni articolo altrove; una regola robots può nascondere una directory; una navigazione renderizzata lato client può creare orfani per un client non JavaScript. Ogni nuova pagina ingrandisce l’insieme interessato e rende la riparazione più rischiosa.

Correggi prima le fondamenta. L’ordine è crawlability → indicizzabilità → qualità dei contenuti → performance perché ogni strato è un cancello. Crawlability significa che un crawler può scoprire e richiedere un URL; indicizzabilità significa che l’URL raggiungibile è idoneo per l’inclusione. Solo allora si dovrebbero giudicare qualità dei contenuti e performance. Una pagina veloce bloccata da robots.txt non può competere, e i meta title non contano su pagine irraggiungibili.

Questa fase consuma l’ambito, i percorsi prioritari, i mercati e i rischi provenienti da Scoperta e obiettivi . Eseguirla troppo presto produce un crawl senza contesto di business. Saltarla permette a ricerca e produzione di puntare a template che non possono entrare affidabilmente nell’indice.

Input e output

Gli input definiscono il sito previsto, non solo ciò che un crawler trova. Gli output dicono al prossimo responsabile quali URL sono sicuri da testare e quali rimangono bloccati.

Scegli la profondità dell’audit

Seleziona la profondità prima del crawling. Le stime presuppongono che l’accesso sia pronto ed escludono l’implementazione.

La checklist

Lavora in ordine. Un cancello fallito può invalidare i campioni successivi, quindi registra il fallimento e il suo ambito prima di continuare.

1. Conferma che il target sia la produzione

Cosa fare: verifica schema, host, file robots, proprietà analytics, proprietà Search Console e host della sitemap. Perché è importante: lo staging può sembrare pulito mentre la produzione rimane danneggiata. Come farlo: risolvi l’host canonical concordato, confronta le pagine prioritarie e gli header di risposta e registra l’origine del crawl. Strumento: browser, configurazione del crawler, selettore Search Console. Completato quando: il registro nomina l’origine di produzione e la proprietà confermate, senza hostname di staging nei seed o negli export.

2. Testa robots.txt prima del crawling

Cosa fare: ispeziona /robots.txt di ogni host di produzione e le sitemap referenziate. Perché è importante: una regola di disallow impedisce il crawling prima che il contenuto possa essere valutato. Come farlo: confronta i pattern Disallow con l’inventario previsto, testa URL corrispondenti e non corrispondenti e distingui un blocco di crawl da noindex. Strumento: risposta grezza e tester robots. Completato quando: robots restituisce 200, i blocchi previsti hanno motivazioni, i campioni indicizzabili sono consentiti e un blocco non intenzionale genera un riscontro critico.

3. Riconcilia le sitemap con gli URL reali

Cosa fare: confronta le sitemap inviate con l’inventario canonical e indicizzabile. Perché è importante: una sitemap dovrebbe nominare URL che il sito vuole selezionati, non redirect, errori o duplicati. Come farlo: normalizza le voci, confronta i conteggi per template, quindi campiona aggiunte e omissioni in Sitemap e Indicizzazione . Strumento: https://app.amicited.com/reports/google-search/sitemaps-indexing ed export del crawl. Completato quando: la copertura è almeno del 95%, 0 voci reindirizzano o danno errore e ogni lacuna ha una motivazione o un responsabile.

4. Misura la distribuzione dei codici di stato

Cosa fare: classifica le risposte come 2xx, 3xx, 4xx o 5xx. Perché è importante: gli errori impediscono il recupero e i redirect aggiungono salti. Come farlo: segui e segnala i redirect, segmenta per template e confronta con Crawl Bing . Strumento: https://app.amicited.com/reports/bing-webmasters/crawl, crawler e monitoraggio. Completato quando: gli URL indicizzabili restituiscono 200; errori interni, loop e catene sono zero; e i redirect intenzionali sono documentati.

5. Rimuovi catene e loop di redirect

Cosa fare: traccia i redirect fino alla loro risposta finale. Perché è importante: i salti rallentano la scoperta; un loop non raggiunge mai il contenuto. Come farlo: esporta i percorsi, aggiorna i link interni ai canonical finali e consolida le regole. Strumento: report dei redirect e controlli degli header. Completato quando: i link interni vanno diretti, i redirect legacy fanno un solo salto e non rimangono loop o catene.

6. Stabilisci il rapporto di indicizzazione idoneo

Cosa fare: confronta lo stato dell’indice di Google con gli URL deliberatamente idonei. Perché è importante: includere redirect, filtri, duplicati o pagine noindex rende il rapporto privo di significato. Come farlo: costruisci il denominatore idoneo, ispeziona campioni prioritari in Ispezione URL e raggruppa le esclusioni per template. Strumento: https://app.amicited.com/reports/google-search/url-inspection, Search Console e inventario. Completato quando: almeno il 90% è indicizzato o ogni lacuna ha un responsabile della causa principale; sotto l'80% è un riscontro importante.

7. Verifica la correttezza dei canonical

Cosa fare: confronta i canonical dichiarati, finali e selezionati da Google. Un canonical è la versione preferita tra URL simili. Perché è importante: uno sbagliato consolida i segnali lontano dalla pagina prevista. Come farlo: testa gli auto-riferimenti di pagine uniche, i cross-canonical deliberati e la coerenza tra HTML, sitemap, redirect e link. Strumento: report canonical e https://app.amicited.com/reports/google-search/url-inspection. Completato quando: il 100% delle pagine indicizzabili uniche nomina un canonical assoluto, 200, indicizzabile, con ogni discrepanza selezionata spiegata.

8. Trova cluster duplicati e quasi-duplicati

Cosa fare: raggruppa URL con contenuti principali identici o sostanzialmente sovrapposti e lo stesso scopo di ricerca. Perché è importante: i duplicati dividono i segnali interni e costringono i motori di ricerca a scegliere una versione che l’azienda potrebbe non preferire. Come farlo: confronta hash esatti, similarità testuale normalizzata, titoli, canonical, parametri e scopo del template; poi scegli consolidamento, differenziazione, noindex o rimozione. Strumento: report duplicati del crawler, inventario pagine e Pagine di Ricerca Google . Completato quando: nessun cluster contiene più di un URL canonical indicizzabile non spiegato che serve lo stesso intento, e ogni variante accettata ha uno scopo distinto registrato.

9. Trova orfani e misura la profondità dei link

Cosa fare: unisci gli URL del crawler con sitemap, analytics, Search Console, export CMS e backlink per trovare pagine senza un link interno crawlable. Misura il percorso di click più breve dalla homepage. Perché è importante: un orfano può apparire in una sitemap ma ricevere scarso contesto interno o autorità; una profondità eccessiva rende la scoperta fragile. Come farlo: confronta le fonti, ispeziona i pattern delle directory in Vista Directory e traccia navigazione, breadcrumb, hub e link contestuali. Strumento: https://app.amicited.com/reports/directory e un crawl multi-fonte. Completato quando: il numero di orfani previsti è zero, le pagine prioritarie sono entro tre click dalla homepage, le altre pagine indicizzabili previste entro cinque, e ogni eccezione ha un percorso di scoperta deliberato.

10. Confronta HTML renderizzato e non JavaScript

Cosa fare: confronta la risposta iniziale del server con la pagina dopo l’esecuzione di JavaScript. Perché è importante: un browser può visualizzare contenuti e link che un client non JavaScript non riceve mai. Come farlo: recupera pagine rappresentative con script disabilitati, ispeziona l’HTML grezzo, poi confronta titoli, testo principale, link, canonical, direttive robots, dati strutturati e stato dopo il rendering. Strumento: crawler in modalità HTML e renderizzata più strumenti di sviluppo del browser. Completato quando: la risposta iniziale contiene il contenuto principale, il canonical, le direttive di indicizzazione e la navigazione crawlable necessaria per scoprire le pagine prioritarie; qualsiasi dipendenza solo-JavaScript è accettata esplicitamente e testata su tutti i template.

11. Valida hreflang dove applicabile

Cosa fare: verifica le annotazioni che collegano equivalenti linguistici o regionali. Perché è importante: cluster incompleti o contrastanti possono far sì che i motori di ricerca ignorino il targeting e mostrino la versione di mercato sbagliata. Come farlo: testa codici lingua-regione validi, URL canonical assoluti, auto-riferimenti, link di ritorno reciproci, x-default dove ha un vero ruolo di fallback e l’indicizzabilità di ogni target. Strumento: report hreflang del crawler e campioni URL. Completato quando: codici non validi, auto-riferimenti mancanti, ritorni mancanti, target non canonical, redirect ed errori sono tutti zero. Se il sito non ha equivalenti localizzati, registra “non applicabile” invece di inventare annotazioni.

12. Testa paginazione e percorsi di crawl

Cosa fare: verifica che le sequenze multi-pagina di categorie o archivi espongano link crawlable e URL unici utili. Perché è importante: lo scroll infinito o il caricamento solo tramite pulsante possono nascondere elementi più profondi, mentre canonicalizzare ogni pagina alla pagina uno può rimuovere inventario distinto dalla scoperta. Come farlo: disabilita JavaScript, segui i link successivi e numerati, ispeziona stato, canonical e direttive robots, e testa l’ultima pagina e i parametri fuori intervallo. Strumento: crawl non renderizzato e browser. Completato quando: ogni elemento previsto è raggiungibile tramite link anchor, ogni pagina utile si auto-canonicalizza, i numeri di pagina non validi restituiscono un errore appropriato anziché un soft 200, e nessuna sequenza crea uno spazio URL illimitato.

13. Controlla la parità mobile

Cosa fare: confronta la consegna mobile e desktop per contenuti, link, metadati, direttive, dati strutturati e stato della risposta. Perché è importante: Google valuta principalmente la rappresentazione mobile; nascondere contenuti o link significativi solo su mobile cambia ciò che può comprendere. Come farlo: esegui il crawl con user agent desktop e smartphone e confronta template rappresentativi, non solo screenshot visivi. Strumento: crawl accoppiati, ispezione URL mobile e modalità responsive del browser. Completato quando: tutti i contenuti indicizzabili e i link crawlable necessari per significato e scoperta sono equivalenti, con zero blocchi solo-mobile, differenze canonical o risposte di errore.

14. Applica HTTPS e rimuovi i contenuti misti

Cosa fare: verifica la consegna sicura, i redirect dell’host, i certificati, lo schema canonical, gli URL interni e le risorse caricate su HTTP. Il contenuto misto significa che una pagina HTTPS richiede una risorsa non sicura. Perché è importante: le richieste non sicure possono essere bloccate, esporre gli utenti e creare segnali URL incoerenti. Come farlo: esegui il crawl di tutte le varianti HTTP, ispeziona la copertura dei certificati e gli errori di sicurezza del browser e cerca le richieste di risorse renderizzate. Strumento: crawler, pannello di sicurezza del browser e configurazione del server. Completato quando: ogni pagina HTTP reindirizza una volta al suo URL HTTPS corrispondente, tutti i canonical e i link interni usano HTTPS, i certificati sono validi per ogni host live e le richieste di contenuti misti attivi o passivi sono zero.

Strumenti in AmICited

Usa i report di prodotto come prove per la checklist, non come sostituto del crawl.

• Sitemap e Indicizzazione su https://app.amicited.com/reports/google-search/sitemaps-indexing mostra lo stato delle sitemap inviate, avvisi, errori e azioni di indicizzazione.
• Ispezione URL su https://app.amicited.com/reports/google-search/url-inspection fornisce il verdetto live di Google per URL campionati e il canonical selezionato.
• Crawl Bing su https://app.amicited.com/reports/bing-webmasters/crawl mostra l’attività del crawler di Bing e i problemi a livello di URL.
• Pagine di Ricerca Google su https://app.amicited.com/reports/pages aiuta a selezionare landing page ad alto valore e separa le pagine con visibilità dalle pagine assenti dai dati di ricerca.
• Vista Directory su https://app.amicited.com/reports/directory rivela pattern a livello di sezione e supporta indagini su profondità e orfani.
• Salute dei Dati su https://app.amicited.com/features/data-health/ registra se le prove collegate sono sufficientemente complete per supportare decisioni sicure.

Regole decisionali

Le soglie creano riscontri; non sostituiscono il giudizio. Segmenta per template e importanza di business: dieci fallimenti nella categoria checkout possono essere più rilevanti di mille tag archivio rotti.

Dai priorità con impatto × sforzo × confidenza. Valuta l’impatto da 1 a 5 in base agli URL idonei interessati e ai percorsi di business. Valuta lo sforzo da 1 a 5 come fattore di facilità, dove 5 significa un cambiamento piccolo e reversibile e 1 significa un programma grande e rischioso; registra anche la stima onesta in ore o giorni. Valuta la confidenza come 0,5 per un’ipotesi plausibile, 0,75 per prove ripetute o 1,0 per una causa riprodotta. Il prodotto fornisce un aiuto all’ordinamento, non una falsa precisione.

Applica l’override delle dipendenze: una correzione che sblocca altro lavoro supera un punteggio più alto che non lo fa. Rimuovere un blocco robots prima del lancio viene prima di perfezionare i title tag indicizzati. Allo stesso livello di dipendenza, affronta le cause a livello di template prima dei sintomi.

Risultato finale: il registro prioritizzato dei riscontri

Consegna un unico registro condiviso, non un export del crawler. Usa una riga per causa principale e allega campioni URL separatamente.

Il registro è completo quando i riscontri critici e importanti hanno responsabili e stime, i blocchi hanno una sequenza, le ipotesi sono etichettate e la decisione di pubblicazione è esplicita.

Cosa va storto

Un report di 200 elementi su cui nessuno può agire

Gli export del crawler confondono le osservazioni con le decisioni. Raggruppa gli URL ripetuti sotto il template o la regola che li causa, fornisci un campione rappresentativo e assegna un unico responsabile. Duecento URL rotti prodotti da un componente di navigazione sono un unico riscontro di causa principale con un ambito misurabile, non duecento attività.

Segnalare sintomi invece di cause

“Pagina non indicizzata” è un sintomo. La causa può essere un canonical non intenzionale, un template orfano, varianti sottili di parametri, un errore mobile o un link solo-JavaScript. Un riscontro non è pronto per la prioritizzazione finché non identifica la causa controllabile o etichetta chiaramente il prossimo test diagnostico.

Auditing dello staging per errore

Lo staging può avere regole robots diverse, autenticazione, dati, template, feature flag e comportamento dell’host. Registra l’origine di produzione e la proprietà Search Console all’inizio di ogni export. Se un crawl deve essere eseguito contro lo staging per garanzia di rilascio, etichettalo come confronto separato e non unire mai le sue metriche nella baseline di produzione.

Evita anche di contare le esclusioni deliberate come perdite, trattare l’inclusione nelle sitemap come prova di indicizzazione, testare solo la homepage o dare priorità solo in base al conteggio degli URL. Definisci l’insieme idoneo, segmenta per template e conserva le prove di accettazione.

Fase successiva

La fase successiva, Accessibilità AI e prontezza per gli agenti , necessita di un campione tecnicamente stabile. Consegna l’inventario degli URL indicizzabili previsti, URL rappresentativi puliti per ogni template prioritario, confronti HTML grezzo e renderizzato, prove di robots e risposte, decisioni canonical, esclusioni note e il registro dei riscontri aperti.

Non affermare che il sito è “tecnicamente in salute.” Dichiara quali template hanno superato i cancelli di crawl e indice, quali rimangono bloccati e se la pubblicazione può procedere. Il prossimo responsabile accetta quando può testare user agent AI-specifici e l’estrazione senza riscoprire difetti di crawl di ricerca irrisolti.

FAQ

Con quale frequenza dovremmo ripetere un audit tecnico di base?

Eseguito prima di una migrazione, riprogettazione, cambio di dominio o programma editoriale su larga scala, poi ripeti i controlli interessati dopo il rilascio. Monitora continuamente e ripeti un passaggio standard quando cambiano template, navigazione, rendering o regole canonical.

Quale rapporto di indicizzazione dovrebbe avere un sito in buona salute?

Per gli URL deliberatamente idonei, il 90% o più è l’aspettativa di partenza, l'80–90% necessita di spiegazione e sotto l'80% è un riscontro. Escludi redirect, duplicati, filtri e pagine noindex intenzionali dal denominatore.

Possiamo pubblicare contenuti mentre le correzioni tecniche sono in corso?

Solo quando i nuovi URL sono crawlable, indicizzabili, canonicalizzati, collegati internamente e non influenzati dal difetto. Se la scoperta o la selezione è bloccata, sospendi; i nuovi URL espandono solo la pulizia.

Abbiamo bisogno di un crawler se Search Console è collegata?

Sì. Search Console riporta ciò che Google ha osservato; un crawler testa il sito attuale e rivela link, risposte, profondità, canonical e duplicati. Nessuno dei due sostituisce l’altro.

Chi possiede le correzioni trovate nell’audit?

Il responsabile SEO possiede il registro e i criteri di accettazione. Di solito l’ingegneria possiede le correzioni di server, rendering, redirect, canonical e HTTPS; i team di contenuti possono possedere i problemi di duplicazione e collegamento. Ogni elemento necessita di una persona nominata.