Nuova regola 2025: Perché le sitemap XML non vengono ancora indicizzate dopo l’invio｜3 motivi da sapere

Il tuo sito ha inviato una sitemap XML, ma dopo settimane o addirittura mesi, cercando su Google con “site:iltuodominio.com” vengono mostrati pochissime pagine?

Non preoccuparti, non sei un caso isolato.

I dati ufficiali di Google mostrano che, in media, una nuova URL inviata impiega da qualche giorno a qualche settimana per essere scoperta e infine indicizzata.

In effetti, i report di Search Console mostrano che più del 60% dei webmaster che inviano una Sitemap hanno sperimentato un alto numero di URL “scoperte ma non indicizzate” dopo il primo invio della Sitemap.

L’analisi di numerosi casi ha identificato che i principali ostacoli alla mancata indicizzazione da parte di Google si concentrano in tre livelli specifici e azionabili:

La tua sitemap, Google non riesce a “leggerla” o a usarla

Secondo i dati di Search Console, in media 1 sito su 5 che invia una Sitemap incontra l’errore “Impossibile recuperare” (Couldn’t Fetch).

Cosa significa questo? Significa che il robot di Google non riesce nemmeno ad aprire questo “indice” che hai inviato, oppure si blocca mentre cerca di leggerlo.

Peggio ancora, anche se la Sitemap mostra “Elaborata con successo”, più della metà dei link contenuti potrebbero essere “vicoli ciechi” (errore 404) o “percorsi errati” (pagine di reindirizzamento).

Accessibilità della Sitemap

Problema centrale: Hai inviato il link della Sitemap (ad esempio iltuosito.com/sitemap.xml), ma quando il robot di Google visita questo indirizzo, il server non apre la porta!

Scenario reale e dati:

• 404 Not Found: Il report della Sitemap in Search Console mostra direttamente “Impossibile recuperare”. Questo caso rappresenta circa il 25-30% degli errori di invio. Cause comuni: percorso del file errato (case sensitive!), file eliminato, aggiornamento del sito senza aggiornare il percorso, errore di configurazione del server.
• 500 Internal Server Error / 503 Service Unavailable: Il server era inattivo o c’era un errore interno. Google riproverà, ma se il server è spesso instabile, lo stato della Sitemap rimarrà in errore a lungo. Molti tentativi consecutivi falliti influenzano la “salute” complessiva del sito agli occhi di Google.
• Problemi di permessi di accesso: Il file Sitemap si trova in una directory che richiede login o whitelist IP. Il robot di Google è un “visitatore anonimo” e non può accedere.

Come verificare?

• Il modo più diretto: apri manualmente nel browser il link della Sitemap che hai inviato. Il contenuto XML viene visualizzato correttamente?
• Report Sitemaps in Search Console: Trova la Sitemap inviata e verifica se lo stato è “Successo” o “Impossibile recuperare”. Se è “Impossibile recuperare”, il messaggio di errore è di solito specifico (404? 500? permessi?).

Cosa fare subito:

• Assicurati che l’URL della Sitemap inviata sia 100% corretto.
• Conferma che questo URL sia accessibile anche in una finestra anonima del browser (senza login).
• Risolvere i problemi di stabilità del server. Se incontri errori 500, controlla immediatamente i log del server.

Validità del contenuto

Problema centrale: Gli URL elencati nella Sitemap sono “link morti” o pagine che richiedono un reindirizzamento, causando uno spreco di risorse del robot di Google e nessun contenuto utile.

Punti critici e dati: Nel report della Sitemap in Search Console, accanto al numero di URL “inviati”, viene indicato chiaramente quanti URL presentano “errori” o “avvisi”.

Molti siti hanno un tasso di errore che facilmente supera il 50%, arrivando fino all’80%! Tipologie principali:

• 404 Not Found: La più comune! La pagina è stata rimossa ma la Sitemap non è stata aggiornata; prodotti fuori catalogo ma URL ancora presenti; variazioni nei parametri URL; errori di battitura. Il robot di Google visita URL inutili; questo errore ha alta priorità.
• 301/302 Redirects: La Sitemap contiene un vecchio URL A (che fa un redirect 301 verso il nuovo URL B). Qual è il problema?
  • Google deve scansionare A una volta in più per sapere che deve andare a B.
  • Google preferisce che nella Sitemap sia presente direttamente l’URL finale B, per usare al meglio il proprio budget di scansione.
  • Molti di questi errori rallentano la velocità di scansione e indicizzazione delle pagine importanti del sito.
• Pagine che richiedono login o bloccate: Ad esempio, area membri, cronologia ordini, pagine di amministrazione incluse nella Sitemap. Google è un visitatore anonimo e non ha permessi per vedere queste pagine, quindi non sono utili.

Come verificare?

• Controlla attentamente il rapporto Sitemap in Search Console! Elenca gli URL specifici con errori e il tipo di errore (404, redirect, ecc.).
• Usa regolarmente strumenti di crawling come Screaming Frog per scansionare gli URL nel tuo file Sitemap e verificare i codici di stato. Presta particolare attenzione a quelli con codice diverso da 200.

Cosa fare subito:

• Pulisci regolarmente il tuo Sitemap! Rimuovi tutti gli URL che restituiscono 404 o che richiedono il login.
• Assicurati che gli URL nel Sitemap puntino all’indirizzo finale! Verifica che tutti gli URL in uso restituiscano direttamente lo status 200 OK. Se una pagina fa un redirect, aggiorna il Sitemap per puntare all’URL di destinazione finale.
• Non inserire URL irrilevanti o non validi: Inserisci solo pagine pubbliche che desideri che Google indicizzi e mostri agli utenti, con contenuti effettivi.

Norme di formattazione

Problema principale: Il file Sitemap non rispetta lo standard XML o il protocollo Sitemap, causando l’incapacità del parser di Google di estrarre correttamente le informazioni degli URL.

Errori comuni:

• Errori di sintassi XML:
  • Tag non chiusi: Esempio: https://... manca il
  • Caratteri non validi: Per esempio il simbolo & nell’URL non è stato convertito in &. Alcuni caratteri speciali devono essere convertiti.
  • Problemi di codifica: La dichiarazione o la codifica del file (UTF-8, GBK, ecc.) è errata o incoerente, causando la visualizzazione errata di caratteri speciali come il cinese.
• Errori nella struttura del protocollo:
  • Mancano tag radice necessari come o .
  • Mancano tag obbligatori o ordine errato: ogni voce deve contenere obbligatoriamente il tag . Altri tag opzionali (, , ) devono essere nella posizione corretta se usati.
  • Uso di tag o attributi non supportati dal protocollo Sitemap.

Quanto è grave l’impatto? Anche un 0,5% di errore (per esempio 5 errori su 1000 URL) può far sì che Google consideri il Sitemap come “parzialmente errato” o addirittura lo rifiuti, impedendo la corretta lettura di tutti gli URL. I log di Google spesso indicano dove l’errore di parsing si è fermato.

Come verificare?

• Usa strumenti professionali di validazione Sitemap: Come un validadore XML online o strumenti ufficiali dei motori di ricerca (Google Search Console può verificare URL singoli ma ha limitazioni per file Sitemap interi).
• Controlla manualmente dei campioni: Apri il file Sitemap in un editor di testo (come VSCode) e verifica che i tag siano chiusi correttamente e che i caratteri speciali siano convertiti, specialmente per URL aggiunti o modificati recentemente. Gli editor spesso mostrano errori di sintassi XML.

Cosa fare subito:

• Usa strumenti o plugin affidabili per generare Sitemap (come plugin SEO, CMS integrati, generatori professionali) per evitare errori manuali.
• Dopo la generazione, convalida il formato con strumenti appositi.
• Se modifichi manualmente, segui rigorosamente la sintassi XML e il protocollo Sitemap.

Il file è troppo grande?

Problema principale: Google ha un limite chiaro: un singolo file Sitemap può essere al massimo di 50MB (non compresso) o contenere 50.000 URL (quello che si verifica prima). File oltre questo limite possono essere ignorati o processati solo parzialmente.

Esperienza pratica:

• Siti di e-commerce, forum grandi o siti di contenuti multimediali sono i più inclini a superare questo limite.
• Molti plugin CMS generano Sitemap di default che superano questo limite, richiedendo di dividerli in più file.
• Anche se il file non supera il limite, Sitemap molto grandi con decine di migliaia di URL vengono processati più lentamente da Google, rallentando l’indicizzazione.

Come controllare?​​

• Controlla le proprietà del file: supera i 50MB?
• Usa uno strumento o uno script per contare il numero di URL nel file. Sono più di 50.000?

Da fare immediatamente:​​

• ​I grandi siti devono sicuramente usare la Sitemap indice!​​
  • Crea un file indice principale (ad esempio, sitemap_index.xml) che non contiene direttamente URL, ma elenca i percorsi dei tuoi piccoli file Sitemap (ad esempio, sitemap-posts.xml, sitemap-products.xml).
  • ​Invia questo file indice (sitemap_index.xml) al Google Search Console.​
• Dividi i diversi tipi di URL (articoli, prodotti, categorie, ecc.) in Sitemap più piccoli separati.
• Assicurati che ogni piccolo file Sitemap rispetti i limiti di dimensione e numero di URL.

Sitemap indice

Problema principale:​​ Hai inviato la Sitemap indice (sitemap_index.xml), ma le Sitemap elencate all’interno (sitemap1.xml, sitemap2.xml) hanno problemi (percorsi errati, inaccessibili, errori di formato, ecc.). È come se l’indice fosse corretto, ma i capitoli fossero mancanti o danneggiati.

Errori comuni:​​

• I percorsi delle Sitemap nel file indice sono relativi (es. <loc>/sitemap1.xml</loc>), ma devono essere URL assoluti e completi (es. <loc>https://www.tuosito.com/sitemap1.xml</loc>).
• I file Sitemap elencati possono avere uno qualsiasi dei problemi sopra citati (404, 500, errore di formato, dimensione eccessiva, ecc.).

​Impatto:​​ Se le Sitemap elencate hanno problemi, Google potrebbe non essere in grado di eseguire la scansione degli URL elencati, equivalendo a non averli inviati tramite Sitemap.

Come controllare?​​

• Dopo aver inviato la Sitemap indice nel Search Console, verifica lo stato. Se è stata elaborata correttamente, ma il numero di “URL trovati” è molto inferiore al totale previsto, probabilmente ci sono problemi con le Sitemap elencate.
• ​Controlla il rapporto dettagliato della Sitemap indice, che mostra lo stato di ogni Sitemap elencata!​​ Esamina ciascuna Sitemap per eventuali errori.

Da fare immediatamente:​​

• Assicurati che ogni Sitemap elencata nel file indice abbia un URL completo e assoluto.
• Assicurati che ogni file Sitemap indicato sia sano (accessibile, senza link rotti, formato corretto, dimensione conforme).

Il crawler di Google non riesce a “raggiungere” le tue pagine

La Sitemap è stata inviata con successo, ma nel report di copertura di Search Console, le pagine risultano ancora con stato “Trovata – Non indicizzata” o “Scansionata – Non indicizzata”?

Il problema probabilmente è qui: il crawler di Google non è riuscito ad accedere ai contenuti reali delle tue pagine.

Non è un’esagerazione — secondo la nostra analisi, oltre il 40% dei problemi di indicizzazione si bloccano nella fase di scansione.

Il file robots.txt blocca il crawler?

Problema principale:​​ Il file robots.txt è come un manuale di istruzioni per la sicurezza all’ingresso. Una riga errata di Disallow: può bloccare il crawler di Google (Googlebot) dall’intero sito o da directory chiave, lasciandolo con l’indirizzo ma senza “permesso di entrare”.

Errori comuni e avvisi:​​

• ​Blocco totale del sito – disastro: Disallow: / (una sola barra!). Questo è uno degli errori più comuni e gravi, spesso causato da configurazioni di test dimenticate o errori umani. Se nel report di copertura di Search Console molte URL appaiono “bloccate” o non compaiono, questa è la causa principale.
• ​Blocco di risorse o directory chiave:

Come verificare facilmente?

Apri il browser e visita: https://tuo-dominio/robots.txt. Leggi attentamente ogni riga.

Strumento di test robots.txt in Search Console:

1. Inserisci il contenuto del tuo robots.txt o carica il file.
2. Seleziona di testare per lo user-agent Googlebot.
3. Inserisci alcune URL delle tue pagine principali (homepage, pagina prodotto, articolo).
4. Il risultato è “Allowed” (Consentito)? Se appare “Blocked” (Bloccato), trova subito la regola Disallow corrispondente!

Cosa fare immediatamente:

• Controlla urgentemente le regole Disallow:: Assicurati che nessuna regola blocchi accidentalmente l’intero sito (/) o le directory core di contenuto/risorse.
• Blocchi precisi, evita l’uso eccessivo di caratteri jolly: Blocca solo i percorsi che devono essere realmente bloccati (come backend, bozze di privacy policy, pagine di risultati di ricerca). Per URL con parametri, usa preferibilmente rel="canonical" o la gestione parametri in Search Console invece di bloccare tutto.
• Testa prima di pubblicare: Dopo aver modificato il robots.txt, usa lo strumento di test di Search Console per assicurarti che le pagine core risultino “Allowed” prima di pubblicare online.

Crash o caricamento molto lento delle pagine

Problema principale: Googlebot arriva all’indirizzo, ma la porta è chiusa (server crash), oppure apre troppo lentamente (timeout), oppure apre e trova la stanza vuota (rendering fallito). Non ottiene contenuto reale.

Manifestazioni reali di fallimento di crawl e dati correlati:

• Errori 5xx del server (503, 500, 504): Comuni nei log di crawl di Google. In particolare il 503 (Servizio non disponibile), che indica sovraccarico temporaneo o manutenzione. Fallimenti ripetuti fanno diminuire la priorità di crawl di Google. Molto comune in siti ad alto traffico o con risorse limitate.
• Timeout di connessione/lettura: Il bot invia la richiesta ma non riceve risposta completa entro 30 secondi o meno. Comune in configurazioni server errate (processi PHP bloccati), query lente al database, risorse che bloccano l’host. Search Console mostra pagine lente e tassi di errore nella sezione “Page Experience” o nei log.
• Errori 4xx lato client (eccetto 404): Come 429 (Too Many Requests) – politiche anti-bot o limiti di traffico bloccano Googlebot. Necessario modificare o consentire gli IP del bot.
• Rendering JavaScript “pagina bianca”: Siti che dipendono molto da JS per mostrare il contenuto principale, ma il bot smette di aspettare l’esecuzione JS o incontra errori JS che impediscono il rendering. Vede solo una struttura HTML vuota.

Strumenti di verifica:

Google Search Console > Strumento di controllo URL: Inserisci un URL specifico e verifica lo stato nel “rapporto di copertura”, se è “indicizzato” o altro? Clicca su “Testa URL dal vivo” per testare il crawl e rendering in tempo reale! Il punto centrale è controllare se lo “screenshot” e l’“HTML indicizzato” contengono tutto il contenuto principale dopo il rendering.

Search Console > Metriche Web Core & Rapporto esperienza pagina: Una alta percentuale di pagine con “FCP/LCP cattivi” indica aree di performance lente.

Analisi dei log del server:

1. Filtra le richieste con User-agent che contengono Googlebot.
2. Controlla i codici di stato: registra i 5xx, 429, 404 (404 imprevisti).
3. Esamina i tempi di risposta: calcola il tempo medio di risposta per le visite dei bot e individua le pagine lente oltre i 3 o 5 secondi.
4. Usa strumenti di monitoraggio dei log: per analizzare in modo più efficiente lo stato dell’attività del crawler di Google.

Test di velocità in ambiente reale:

Google PageSpeed Insights / Lighthouse: Fornisce punteggi di performance, valori core metrics e suggerimenti specifici per l’ottimizzazione, inclusa una valutazione rigorosa di FCP (First Contentful Paint), LCP (Largest Contentful Paint), TBT (Total Blocking Time).

WebPageTest: Simula il caricamento completo della pagina in diverse regioni/dispositivi/reti (inclusa la timeline dettagliata e la cascata di rete), identificando precisamente i “colpevoli” del caricamento bloccato (uno specifico JS? un’immagine grande? una API esterna?).

Azioni urgenti (in ordine di priorità):

• Monitora e risolvi errori 5xx: ottimizza risorse server (CPU, memoria), query database, e correggi errori di programma. Se usi CDN o servizi cloud, controlla il loro stato.
• Verifica errori 429: controlla se il server limita attivamente le richieste. Regola la strategia anti-crawler o permetti l’accesso agli IP dei crawler di Google (Google ha pubblicato la lista degli IP dei crawler).
• Ottimizza al massimo la velocità delle pagine:
  • Migliora la risposta del server: ottimizzazione server, accelerazione CDN, ottimizzazione cache (Redis/Memcached).
  • Riduci la dimensione delle risorse: comprimi immagini (preferibilmente in formato WebP), comprimi e unisci CSS/JS, elimina codice non usato.
  • Ottimizza il caricamento JS: caricamento asincrono, ritarda il caricamento dei JS non critici, utilizza code splitting.
  • Ottimizza il percorso di rendering: evita CSS/JS che bloccano il rendering, inserisci inline i CSS critici.
  • Migliora il caricamento delle risorse: assicurati che il CDN funzioni bene, usa il prefetch DNS (dns-prefetch) e il preload delle risorse critiche (preload).
• Garantisci affidabilità del rendering JS: considera il rendering lato server (SSR) o rendering statico per assicurare che i crawler ricevano HTML completo con il contenuto principale. Anche se usi client-side rendering (CSR), assicurati che il JS venga eseguito correttamente entro i limiti di timeout dei crawler.

Struttura del sito disorganizzata, efficienza crawler molto bassa

Problema principale: anche se il crawler entra dalla homepage o da una pagina di ingresso, i link interni del sito sono come un labirinto complesso, che non permette di trovare un percorso efficace verso le pagine importanti. Può raggiungere solo poche pagine, molte pagine profonde, anche se esistenti, sono come isole isolate e irraggiungibili.

Caratteristiche della struttura scadente & dati impattanti:

• Bassa “densità di link interni” nelle homepage/pagine canale: contenuti importanti (novità, buoni articoli) non hanno link di ingresso evidenti. Dati Google mostrano che la probabilità di indicizzazione cala molto se la profondità clic da homepage a pagina contenuto supera 4 livelli.
• Abbondanza di pagine isolate: molte pagine hanno pochi o nessun link da altre pagine (soprattutto link HTML tradizionali, non generati da JS o solo presenti in Sitemap). Queste quasi mai vengono trovate dai crawler che “girano a caso”.
• Link nascosti dietro JS o controlli interattivi: link importanti appaiono solo dopo clic su menu complessi, esecuzione di funzioni JS o ricerca. I crawler non possono “cliccare” questi controlli!
• Mancanza di una logica efficace di categorizzazione/tag/relazione: contenuti poco organizzati, impossibile trovare tutto il materiale correlato tramite navigazione gerarchica.
• Sistema di paginazione disordinato: mancano link chiari “pagina successiva” o lo scrolling infinito impedisce ai crawler di arrivare in fondo.
• Mancanza o cattiva struttura del Sitemap: anche se c’è un Sitemap (come descritto nel capitolo precedente), se è disorganizzato o solo un indice, aiuta poco i crawler nel seguire i percorsi.

Come valutare?

• Usa strumenti di crawling del sito (es. Screaming Frog):
  • Simula la scansione partendo dalla homepage.
  • Controlla il report “numero di link interni”: verifica se la homepage ha abbastanza link (verso categorie/contenuti importanti).
  • Controlla il report “profondità link”: quante pagine importanti sono a profondità 4 o più? La percentuale è troppo alta?
  • Identifica “pagine isolate” (Inlinks = 1): sono pagine importanti ma senza link?
• Guarda il report “link” in Search Console: sotto la tab “link interni”, verifica il numero di link interni ricevuti dalle pagine target principali. Se le pagine importanti hanno pochi o nessun link interno, è un problema.
• Disabilita JS per una navigazione manuale: disattiva JavaScript nel browser per simulare la vista del crawler. Il menu di navigazione funziona ancora? I link nelle aree principali sono visibili e cliccabili? I pulsanti di paginazione funzionano?

Azioni da fare immediatamente:

• Rafforzare il peso dei link interni nella homepage/navigazione principale: Assicurarsi di mostrare in posizione evidente sulla homepage i link alle sezioni importanti (nuovi articoli, prodotti più venduti, categorie principali) usando link HTML standard. Evitare di nascondere tutti i link importanti dietro elementi che richiedono interazioni.
• Creare una struttura chiara del sito:
  • Homepage > Categoria principale (supporto breadcrumb) > Sottocategoria/Tag > Pagina contenuto specifica.
  • Assicurarsi che ogni livello abbia link interni ricchi e rilevanti che si collegano tra loro.
• Colmare i “pagine-isola”: Aggiungere link a queste pagine importanti ma poco collegate nelle pagine correlate, nelle sidebar delle categorie, o nella sitemap HTML.
• Gestire con attenzione la navigazione generata da JS: Per navigazioni/paginazioni/caricamenti “carica altro” basati su JS, fornire una versione HTML alternativa (ad esempio paginazione tradizionale) oppure assicurarsi che i link principali siano presenti nel codice HTML già al caricamento iniziale (non caricati tramite AJAX dopo).
• Usare bene la navigazione breadcrumb: Mostrare chiaramente la posizione dell’utente e fornire indicazioni gerarchiche ai crawler.
• Creare e inviare Sitemap XML: Non può sostituire una buona struttura di link interni, ma aiuta i crawler a scoprire pagine profonde (assicurarsi che la sitemap sia funzionante).

Contenuti web che Google considera “non degni” di essere indicizzati

Secondo i dati ufficiali di Google, oltre il 30% delle pagine che sono state correttamente scansionate ma non indicizzate sono state filtrate a causa di contenuti di basso valore o problemi di qualità.

Analizzando il report “Copertura” di Search Console, gli URL etichettati come “duplicati”, “pagine alternative con pagina canonica” o “contenuti di bassa qualità” indicano quasi sempre problemi seri nel contenuto stesso:

• Informazioni scarse, come un foglio bianco
• Contenuto copiato senza originalità
• Testi pieni di parole chiave incomprensibili per gli utenti

Il compito principale di Google è fornire risultati utili, unici e affidabili agli utenti.

Mancanza di informazioni, nessun valore reale

Problema principale: La pagina contiene informazioni molto limitate, prive di originalità e incapaci di risolvere problemi reali degli utenti, come un “foglio trasparente”. L’algoritmo di Google la giudica “contenuto a basso valore” (Low-value Content).

Tipologie frequenti di “pagine inutili” e segnali di allarme:

Pagine “segnaposto”: pagine come “Prodotto in arrivo”, “Pagina categoria senza prodotti”, “Presto disponibile” senza contenuti sostanziali. Possono essere incluse nella sitemap ma sono solo gusci vuoti.

Pagine di “fine processo”: pagine di ringraziamento dopo un form (solo testo di ringraziamento senza indicazioni o contenuti correlati), pagine di “conferma ordine” (solo numero ordine senza link a spedizione o FAQ). L’utente “usa e va”, quindi Google non le indicizza.

Pagine eccessivamente “modulari”/“spezzettate”: per aumentare il numero di pagine, si dividono contenuti che potrebbero stare in una sola pagina (es. specifiche diverse di un prodotto) in molte pagine quasi vuote. Search Console le segnala spesso come “pagine alternative con pagina canonica”.

Pagine “generate automaticamente” di bassa qualità: generate in massa da software, con testi sconnessi o assemblati male (tipiche di network spam).

Pagine “navigazione” senza contenuto: liste di link o directory senza testo esplicativo che descriva il valore o il rapporto tra i link. Sono solo trampolini di lancio.

Fatti correlati:

• Nel modello EEAT di Google (Esperienza, Competenza, Autorità, Affidabilità), manca il primo “E” (Esperienza) perché la pagina non dimostra esperienza nel fornire informazioni o servizi utili.
• Nel report “Copertura” di Search Console lo stato può essere “contenuto duplicato”, “non selezionato per l’indice – pagina alternativa” o “scansionato – non indicizzato”, con dettagli che indicano “bassa qualità del contenuto” o “poco valore della pagina” (i nomi specifici possono variare a seconda della versione).

Come capire se una pagina è “sottile”?

• La quantità di testo non è assoluta, ma un indicatore: pagine con meno di 200-300 parole e senza altri elementi di valore (grafici, video, strumenti interattivi) sono ad alto rischio. Conta la “densità informativa”.
• Auto-valutazione con tre domande:
  1. L’utente può risolvere un problema specifico o imparare qualcosa di nuovo da questa pagina? (No? Pagina inutile)
  2. Questa pagina può esistere da sola senza dipendere da altre pagine? (Sì? Ha valore)
  3. Il “cuore” della pagina è qualcosa oltre la navigazione o i link di reindirizzamento? (Sì? Contenuto valido)
• Controllare il tasso di rimbalzo / tempo di permanenza sulla pagina: Se lo strumento di analisi mostra che la pagina ha un tasso di rimbalzo molto alto (>90%) e un tempo medio di permanenza molto breve (<10 secondi), è una prova chiara che gli utenti (e Google) la trovano inutile.

Azioni da fare immediatamente:

• Unire o eliminare le “pagine inutili”: Unire le “pagine vuote di specifiche” eccessivamente frammentate nella pagina principale del prodotto; eliminare o noindex le pagine generate automaticamente che sono spam o placeholder senza contenuto.
• Migliorare il valore delle pagine “fine processo”: Alla pagina di ringraziamento aggiungere il tempo previsto / le istruzioni sui passaggi di conferma / link di aiuto correlati; alla pagina di checkout aggiungere l’accesso al tracciamento dell’ordine, la politica di reso e le FAQ.
• Inserire valore esplicativo nelle pagine di “navigazione”: Aggiungere in cima alle pagine di categoria / liste di link un testo introduttivo che spieghi lo scopo della categoria, cosa contiene e a chi è destinata. Questo aumenta immediatamente la percezione di valore.
• Arricchire le pagine di contenuto principale: Assicurarsi che le pagine di prodotto o articolo contengano descrizioni sufficientemente dettagliate, informazioni e risposte alle domande comuni.

Diffusione di contenuti duplicati o altamente simili

Problema principale: Più URL mostrano contenuti quasi identici o altamente simili (somiglianza > 80%). Questo spreca risorse dei motori di ricerca e infastidisce gli utenti (risultati diversi mostrano lo stesso contenuto). Google sceglie solo un “rappresentante” (URL canonico), mentre gli altri possono essere ignorati.

Tipi principali e impatto:

Inquinamento da parametri (problema grave nei siti e-commerce): Lo stesso prodotto genera moltissimi URL a causa di diversi parametri di ordinamento, filtro e tracciamento (product?color=red&size=M, product?color=red&size=M&sort=price). Secondo strumenti SEO, il 70% dei contenuti duplicati nei siti e-commerce proviene da questo.

Pagine di stampa / versione PDF: La pagina articolo article.html e la sua versione di stampa article/print/ o PDF article.pdf sono quasi identiche.

Adattamento inadeguato per regione / lingua: Pagine di diverse regioni (us/en/page, uk/en/page) hanno differenze minime nei contenuti.

Pagine con più percorsi di categoria: Un articolo con più tag in diverse categorie genera URL diversi, ma con contenuto identico (/news/article.html, /tech/article.html).

Copie su larga scala (interne / esterne): Copia e incolla di interi paragrafi o pagine.

Dati:

• I report di Search Console spesso mostrano lo stato “Indice non selezionato – pagina alternativa ha una canonica” o “Duplicato”. Indica chiaramente quale URL Google ha scelto come versione principale.
• Gli strumenti di crawling (come Screaming Frog) generano report di “similarità contenuti” per individuare gruppi di URL altamente simili.

Come identificare e controllare:

Controllo URL in Search Console: Verificare stato e motivazioni dettagliate.

Screaming Frog crawler:

1. Eseguire la scansione completa del sito.
2. Report > “Contenuti” > report “Contenuti simili”.
3. Impostare la soglia di similarità (ad esempio 90%) e visualizzare i gruppi di URL molto simili.

Confronto manuale: Selezionare alcune URL sospette (ad esempio con parametri diversi), aprirle nel browser e confrontare il contenuto principale.

Azioni da fare immediatamente (in ordine consigliato):

• Priorità: specificare un URL canonico chiaro (rel=canonical):
  • In ogni pagina sospetta di duplicazione, nel tag HTML <head>, specificare un unico URL autorevole come canonico.
  • Sintassi: <link rel="canonical" href="https://www.example.com/this-is-the-main-page-url/" />
  • Google raccomanda fortemente questo metodo!
• Opzione alternativa: utilizzo dello strumento di gestione dei parametri di Google:
  • Configurare in Google Search Console > Ispezione URL > Parametri URL.
  • Indicare a Google quali parametri (ad esempio sort, filter_color) sono usati per filtrare/ordinare contenuti (scegliere il tipo “ordinamento” o “filtro”), Google solitamente ignora i duplicati generati da questi parametri.
• Redirect 301: Per URL vecchi, obsoleti o chiaramente non principali, applicare un redirect permanente 301 verso l’URL più autorevole. È particolarmente utile dopo una ristrutturazione del sito per eliminare vecchi percorsi.
• Tag noindex: Per pagine non principali che non devono essere scansionate né indicizzate (ad esempio pagine di sola stampa, pagine con parametri di tracciamento specifici), aggiungere nel <head> della pagina il meta tag <meta name="robots" content="noindex">. Attenzione però: non risolve il problema dello spreco di crawl (i bot visiteranno comunque la pagina), non è efficiente quanto il tag canonico.
• Rimuovere o unire contenuti: Per articoli o pagine interne con contenuti altamente duplicati, unire o eliminare le versioni ridondanti direttamente.

Scarsa leggibilità, incoerenza di intento, bassa affidabilità

Problema principale: Layout del contenuto confuso, frasi rigide e difficili da capire, keyword stuffing, informazioni errate o obsolete, o non allineate con l’intento di ricerca dell’utente, che portano a una pessima esperienza di lettura per utenti reali (e Google), con difficoltà a trovare informazioni utili, quindi difficilmente indicizzabili.

Caratteristiche che Google “odia” maggiormente:

• Disastro di leggibilità:
  • Paragrafi lunghi senza suddivisione: tutta la pagina è un unico blocco di testo.
  • Linguaggio confuso e poco scorrevole: molti errori ortografici, frasi errate, tono da traduzione automatica.
  • Termini tecnici senza spiegazione: linguaggio tecnico senza chiarimenti per utenti comuni.
  • Scarsa formattazione: mancanza di titoli (H1-H6), liste, grassetto ecc., causando affaticamento visivo.
• Incoerenza di intento (molto grave!):
  • L’utente cerca “come riparare un tubo”, la pagina mostra solo pubblicità di prodotti per tubi.
  • L’utente cerca “confronto A vs B”, la pagina presenta solo A.
• Informazioni obsolete/errate:
  • Leggi cambiate ma contenuti non aggiornati.
  • I passaggi descritti non corrispondono alla pratica reale.
• “Keyword stuffing”: Inserimento eccessivo di parole chiave che danneggia la naturalezza della lettura.
• Pubblicità/popup invadenti: contenuto principale nascosto sotto annunci, disturbando la lettura.

Dati e punti di riferimento per la valutazione:

Core Web Vitals (CWV) correlati indirettamente: benché questi metriche siano focalizzate su velocità/risposta, problemi gravi di caricamento che peggiorano la latenza di interazione (come FID/TBT alti) peggiorano l’esperienza di lettura.

Metriche utenti reali (RUM): alto bounce rate + tempo di permanenza quasi zero sono segnali forti di “rifiuto del contenuto”.

Linee guida di valutazione qualità di Google: Google ha pubblicato ampiamente dimensioni di valutazione della qualità e EEAT (Expertise, Authoritativeness, Trustworthiness), focalizzate su “il contenuto soddisfa l’intento di ricerca dell’utente?” + “il contenuto è affidabile?”. Queste linee guida non sono formule di ranking, ma la loro filosofia coincide molto con gli algoritmi.

Come autocontrollare l’esperienza contenutistica?

• Leggere impersonando l’utente target, con una domanda in mente:
  • Hai trovato la risposta che cercavi nella pagina?
  • È stato difficile da leggere? Hai dovuto cercare avanti e indietro?
  • Sei stato interrotto da pubblicità o popup?
• Controllare la leggibilità e il layout:
  • La info principale è chiara nei primi 250 caratteri? (titolo H1 + primo paragrafo)
  • La gerarchia dei titoli (H2-H6) è chiara e logica?
  • Informazioni complesse sono presentate con liste, diagrammi di flusso o tabelle?
  • I paragrafi sono lunghi 3-5 frasi? Lo spazio bianco è sufficiente?
• Verifica della corrispondenza dell’intento di ricerca:
  • Qual è la parola chiave target? (vedi report “prestazioni ricerca” in Search Console)
  • Il contenuto principale risponde in modo diretto e completo ai bisogni dell’utente per quella parola chiave?
  • Il titolo e il primo paragrafo rispondono chiaramente alla domanda principale?
• Verifica di affidabilità:
  • I dati e fatti hanno fonti affidabili? (Sono linkati?)
  • Il creatore o autore del contenuto mostra credenziali rilevanti? (Expertise/Authoritativeness in EEAT)
  • La data di pubblicazione o aggiornamento è chiara? Il contenuto appare obsoleto?

Azioni da fare subito:

• Riscrivere completamente i paragrafi poco scorrevoli: scrivi in modo naturale come parla una persona reale!
• Formattare l’informazione: usare tag H, liste, tabelle per organizzare i punti chiave.
• Risolvi fortemente l’incoerenza di intento: analizza le parole chiave target (vedi keyword con ranking alto in Search Console), assicurati che il contenuto principale rispecchi esattamente la necessità dell’utente. Se serve, cambia il focus o crea nuove pagine.
• Aggiorna regolarmente e pulisci i contenuti: segna la rilevanza temporale. Aggiorna o archivia contenuti obsoleti. Rimuovi o reindirizza contenuti totalmente inutilizzabili.
• Riduci le pubblicità invasive: controlla quantità e posizione degli annunci, evita che coprano il contenuto principale.
• Rafforza i segnali EEAT (importante ma a lungo termine):
  • Mostra credenziali e background in “Chi siamo” o “Autore”.
  • Cita e collega fonti autorevoli.
  • Mostra chiaramente la data di ultimo aggiornamento.

L’indicizzazione inizia con una mappa precisa, prospera su un percorso scorrevole e si completa con contenuti di valore.