Dopo aver inviato la sitemap丨Perché Google ha indicizzato solo alcune pagine

Quando il proprietario del sito invia una sitemap tramite Google Search Console e si accorge che il numero effettivo di pagine indicizzate è molto inferiore al numero previsto, spesso cade nell’errore di aumentare a caso il numero di invii o modificare ripetutamente il file.

Secondo i dati ufficiali del 2023, oltre il 67% dei problemi di indicizzazione sono dovuti principalmente a tre cause: configurazione errata della sitemap, blocco del percorso di scansione e difetti nella qualità delle pagine.

Problemi nel file sitemap

Se la sitemap inviata non viene completamente acquisita da Google, in circa il 50% dei casi la causa è un problema tecnico nel file stesso.

Abbiamo esaminato la sitemap.xml inviata da una piattaforma di e-commerce e abbiamo scoperto che, poiché i parametri dinamici degli URL delle pagine dei prodotti non erano stati filtrati, 27.000 link duplicati contaminavano il file, causando la situazione in cui Google indicizzava solo la home page.

▍Problema 1: Errore di formato che interrompe l’analisi

Sorgente dei dati: Rapporto di audit del sito Ahrefs 2023

Caso tipico: La sitemap di un sito medico, utilizzando la codifica Windows-1252, ha causato l’impossibilità di analizzare 3.200 pagine da parte di Google, riconoscendo solo la home page (Search Console mostra l’avviso “Impossibile leggere”)

Errore frequente：

✅ I tag XML non sono stati chiusi correttamente (43% degli errori di formato)
✅ Simboli speciali non sono stati escapati (come l’uso diretto del simbolo & senza sostituirlo con &)
✅ Manca la dichiarazione del namespace xmlns (<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"> mancante)

Soluzioni d’emergenza：

• Utilizzare Sitemap Validator per verificare la struttura gerarchica
• Installare il plugin XML Tools in VSCode per il controllo della sintassi in tempo reale

▍Problema 2: Link morti che causano una crisi di fiducia

Indagine settoriale: Statistiche dei dati di Screaming Frog su 500.000 siti

Dato preoccupante：

✖️ In media, ogni sitemap contiene il 4,7% di link con errore 404/410
✖️ Sitemap con più del 5% di link morti, la loro percentuale di indicizzazione diminuisce del 62%

Caso reale: La sitemap di una piattaforma turistica conteneva pagine di prodotti fuori vendita (che rimandavano alla home page tramite un redirect 302), causando a Google di ritenere che stesse manipolando deliberatamente l’indicizzazione, con un ritardo di 117 giorni nell’indicizzazione delle pagine principali

Passaggi di prevenzione：

1. Utilizzare uno strumento di crawling per impostare l’User-Agent come “Googlebot” e simulare la scansione di tutti gli URL nella sitemap
2. Esportare i link con codice di stato diverso da 200 e aggiungere in massa <robots noindex> o rimuoverli dalla sitemap

▍Problema 3: Dimensione del file superiore al limite che causa troncamento

Limite di avviso ufficiale di Google：

⚠️ Una sitemap che supera i 50 MB o le 50.000 URL verrà automaticamente interrotta

Caso catastrofico: La sitemap.xml di un sito di notizie, che conteneva 82.000 link a articoli, è stata effettivamente processata da Google solo per i primi 48.572 link (verificato tramite analisi dei log)

Strategia di divisione：
🔹 Divisione per tipo di contenuto: /sitemap-articles.xml, /sitemap-products.xml
🔹 Divisione per data: /sitemap-2023-08.xml (adatta per siti con aggiornamenti frequenti)

Monitoraggio delle dimensioni：

Contare il numero di righe del file ogni settimana utilizzando uno script Python (wc -l sitemap.xml) e attivare un avviso di divisione quando si raggiungono le 45.000 righe.

▍Problema 4: Frequenza di aggiornamento che inganna i motori di ricerca

Meccanismo di difesa contro i bot：

🚫 L’abuso del campo <lastmod> (come segnare la data odierna per tutte le pagine) rallenta la velocità di indicizzazione del 40%

Lezione appresa: Un forum ha aggiornato ogni giorno la data lastmod di tutta la sitemap, e dopo tre settimane, la copertura dell’indicizzazione è crollata dal 89% al 17%

Operazioni conformi：

✅ Aggiornare <lastmod> solo per le pagine effettivamente aggiornate (preciso fino al minuto: 2023-08-20T15:03:22+00:00)
✅ Per le pagine storiche impostare <changefreq>monthly</changefreq> per ridurre la pressione sul crawling

Struttura del sito che blocca il percorso di scansione

Anche se la sitemap è perfetta, la struttura del sito potrebbe comunque diventare un “labirinto” per i crawler di Google.

Se le pagine realizzate con il framework React non sono pre-renderizzate, il 60% del contenuto verrà riconosciuto da Google come “pagina vuota”.

Quando la distribuzione del link interno è sbilanciata (ad esempio, con 150+ link esterni nella home page), la profondità di scansione sarà limitata ai primi 2 livelli, e le pagine prodotto più profonde rimarranno permanentemente fuori dall’indice.

▍

Il file robots.txt blocca le pagine principali

Scenario tipico：

• La regola predefinita di WordPress Disallow: /wp-admin/ blocca erroneamente i percorsi degli articoli correlati (ad esempio /wp-admin/post.php?post=123)
• Utilizzando Shopify, la generazione automatica di Disallow: /a/ blocca le pagine del centro membri

Impatto dei Dati：

✖️ Il 19% dei siti web perde oltre il 30% dell’indice a causa di un errore di configurazione del robots.txt
✖️ Quando il bot di Google incontra una regola Disallow, in media impiega 14 giorni per riesaminare il percorso

Soluzioni：

1. Verifica l’impatto delle regole utilizzando lo strumento di test del robots.txt
2. Evita di bloccare URL con parametri dinamici come ?ref= (a meno che tu non sia sicuro che non contengano contenuti)
3. Per le pagine erroneamente bloccate, dopo aver rimosso le restrizioni dal robots.txt, invia manualmente per un nuovo crawl tramite lo strumento di ispezione URL

▍ Rendering JS che causa vuoto di contenuti

Rischi del Framework：

• Applicazioni a pagina singola React/Vue (SPA): senza pre-rendering, Google può rilevare solo il 23% degli elementi DOM
• Immagini lazy load: su dispositivi mobili, c’è una probabilità del 51% che il meccanismo di caricamento non venga attivato correttamente

Caso reale：

Una piattaforma di e-commerce ha usato Vue per renderizzare dinamicamente i prezzi e le specifiche, causando una lunghezza media del contenuto di solo 87 caratteri nelle pagine indicizzate da Google (dovrebbe essere di 1200+ caratteri), con una diminuzione diretta del 64% nel tasso di conversione.

Misure di emergenza：

1. Verifica la completezza del rendering utilizzando lo strumento di test per dispositivi mobili
2. Implementa il rendering lato server (SSR) per le pagine SEO principali, o usa Prerender.io per generare snapshot statici
3. Inserisci contenuti chiave nel tag <noscript> (almeno H1 + 3 righe di descrizione)

▍ Distribuzione sbilanciata del peso dei link interni

Limite di profondità di scansione：

• Se la home page ha più di 150 link in uscita, la profondità media di scansione scende a 2.1 livelli
• Se la profondità di clic della pagina principale è maggiore di 3 livelli, la probabilità di indicizzazione scende al 38%

Strategie di ottimizzazione della struttura：

✅ La navigazione a briciole di pane deve includere obbligatoriamente i livelli di categoria (ad esempio: Home> Elettronica> Cellulari> Huawei P60)
✅ Aggiungi un modulo “Pagine importanti” nelle pagine di elenco, per aumentare manualmente il peso dei link interni delle pagine target
✅ Usa Screaming Frog per trovare le pagine orfane (Orphan Pages) senza link in ingresso, quindi collega queste alle pagine correlate

▍ Abuso di paginazione / tag canonical

Operazioni autolesionistiche：

• Usare il tag rel="canonical" nelle pagine di prodotto per indirizzarle alla home page: il 63% delle pagine viene fuso e rimosso
• Pagine dei commenti senza i tag rel="next"/"prev": il peso della pagina principale viene diluito

Filtraggio causato dalla qualità del contenuto

Il rapporto dell’algoritmo di Google 2023 ha confermato che il 61% delle pagine con bassa indicizzazione sono state eliminate a causa di problemi con la qualità del contenuto.

Quando le pagine modello con somiglianza superiore al 32% diventano troppo comuni, il tasso di indicizzazione scende al 41%. Le pagine che impiegano più di 2,5 secondi a caricarsi sui dispositivi mobili vedono ridursi la priorità di scansione.

Contenuti duplicati che causano una crisi di fiducia

Limite di blacklist per settore：

• Quando la somiglianza delle pagine generate dallo stesso modello (come le pagine dei prodotti) supera il 32%, il tasso di indicizzazione scende al 41%
• Verifica del contenuto duplicato: Copyscape segnala come duplicato un paragrafo che ha più del 15% di somiglianza

Caso reale：

Un sito di vendita all’ingrosso di abbigliamento ha creato 5200 pagine prodotto con la stessa descrizione. Google ha indicizzato solo la pagina principale (Search Console ha mostrato un avviso di “pagina alternativa”), con una perdita di traffico organico del 89% in una settimana.

Soluzioni definitive：

1. Usa la libreria difflib di Python per calcolare la somiglianza delle pagine e rimuovere quelle con somiglianza superiore al 25%
2. Per le pagine simili necessarie (come le sottodomeni delle città), aggiungi descrizioni differenziate nel <meta name="description">
3. Aggiungi il tag rel="canonical" nelle pagine duplicate, indirizzandole alla versione principale

<link rel="canonical" href="https://example.com/product-a?color=red" />  

▍ Prestazioni di caricamento oltrepassano il limite tollerabile

Core Web Vitals – Linea di vita o di morte：

• FCP (First Contentful Paint) su mobile ＞ 2,5 secondi → Priorità di scansione ridotta
• CLS (Cumulative Layout Shift) ＞ 0,25 → Ritardo nell’indicizzazione aumenta 3 volte

Lezione appresa：

Un sito di notizie non ha compresso le immagini nella schermata principale (media di 4,7 MB), il che ha causato un LCP (Largest Contentful Paint) di 8,3 secondi su dispositivi mobili, e 12.000 articoli sono stati contrassegnati da Google come “contenuti a basso valore”.

Elenco di ottimizzazione rapida：

✅ Usare il formato WebP invece di PNG/JPG, comprimere in massa con Squoosh fino a ≤150KB
✅ Caricare il CSS della prima schermata in modo inline, caricare JS non essenziali in modo asincrono (aggiungere gli attributi async o defer)
✅ Ospitare gli script di terze parti su localStorage per ridurre le richieste esterne (ad esempio, utilizzare GTM per ospitare Google Analytics)

▍ La mancanza di dati strutturati riduce la priorità

Regole di ponderazione per la scansione：

• Pagine con schema FAQ → Velocità di indicizzazione accelerata del 37%
• Assenza di marcatura strutturata → Tempo di attesa nell’indicizzazione aumenta fino a 14 giorni

Studio di caso：

Un sito medico ha aggiunto il markup dei dettagli della malattia MedicalSchema nella pagina dell’articolo, aumentando la copertura dell’indicizzazione dal 55% al 92%, con un miglioramento del 300% nel posizionamento delle parole chiave a coda lunga.

Codice pratico：

<script type="application/ld+json">  
{  
  "@context": "https://schema.org",  
  "@type": "FAQPage",  
  "mainEntity": [{  
    "@type": "Question",  
    "name": "Come migliorare l'indicizzazione su Google?",  
    "acceptedAnswer": {
"@type": "Answer",  
"text": "Ottimizzare la struttura della sitemap e la velocità di caricamento delle pagine"  
}  
}]  
}  
</script>  

La configurazione del server influisce sull’efficienza di crawling

Abuso del parametro Crawl-delay

Meccanismo di risposta di Googlebot：

• Impostando Crawl-delay: 10 → la quantità massima di pagine crawlate giornalmente scende da 5000 a 288
• Nel caso predefinito senza limiti → Googlebot fa in media 0,8 pagine al secondo (si regola automaticamente in base al carico del server)

Esempio reale：

Un forum ha impostato Crawl-delay: 5 nel file robots.txt per evitare sovraccarichi sul server, il che ha fatto crollare il numero di pagine crawlate da Google da 820.000 a 43.000 al mese, con un ritardo di 23 giorni nell’indicizzazione dei nuovi contenuti.

Strategia di correzione：

1. Rimuovere la dichiarazione Crawl-delay (Google ignora chiaramente questo parametro)
2. Usare limiti per bot specifici, come Googlebot-News
3. Configurare un rate limit intelligente su Nginx:

# Consenti solo Googlebot e Bingbot
limit_req_zone $anti_bot zone=googlerate:10m rate=10r/s;  

location / {  
    if ($http_user_agent ~* (Googlebot|bingbot)) {  
        limit_req zone=googlerate burst=20 nodelay;  
    }  
}  

Blocco errato delle gamme di IP

Caratteristiche delle gamme IP di Googlebot：

• Gamma IPv4: 66.249.64.0/19, 34.64.0.0/10 (aggiunto nel 2023)
• Gamma IPv6: 2001:4860:4801::/48

Esempio di errore：

Un sito di e-commerce ha erroneamente bloccato la gamma di IP 66.249.70.* tramite il firewall Cloudflare (erroneamente identificata come un attacco bot), impedendo a Googlebot di eseguire il crawling per 17 giorni consecutivi e riducendo l’indice del 62%.
Aggiungi una regola nel firewall di Cloudflare: (ip.src in {66.249.64.0/19 34.64.0.0/10} and http.request.uri contains "/*") → Allow

Bloccare risorse critiche per il rendering

Elenco di blocco：

• Bloccare *.cloudflare.com → Impedisce il caricamento del 67% di CSS/JS
• Bloccare Google Fonts → Il tasso di errore nel layout mobile arriva al 89%

Esempio：

Una piattaforma SAAS ha bloccato il dominio jquery.com, causando un errore JS durante il rendering della pagina da parte di Googlebot, con una percentuale di analisi dell’HTML nella pagina di documentazione ridotta al 12%.

Soluzione per il sblocco：

1. Aggiungere alla whitelist nella configurazione di Nginx:

location ~* (jquery|bootstrapcdn|cloudflare)\.(com|net) {
allow all;
add_header X-Static-Resource "Unblocked";
}  

2. Aggiungere l’attributo crossorigin="anonymous" per le risorse caricate in modo asincrono:

<script src="https://example.com/analytics.js" crossorigin="anonymous">script> 

Timeout di risposta del server

Limiti di tolleranza di Google：

• Tempo di risposta > 2000ms → La probabilità che la sessione venga interrotta anticipatamente aumenta dell’80%
• Elaborazione delle richieste al secondo < 50 → Il budget di scansione viene ridotto al 30%

Caso di fallimento：

Un sito WordPress non ha abilitato OPcache, causando un tempo di query al database di 4,7 secondi, con un tasso di timeout di Googlebot che è salito al 91% e l’indicizzazione si è fermata.

Ottimizzazione delle prestazioni：
1. Configurazione di ottimizzazione PHP-FPM (aumentare la concorrenza di 3 volte):

pm = dynamic
pm. max_children = 50
pm. start_servers = 12
pm. min_spare_servers = 8
pm. max_spare_servers = 30

2. Ottimizzazione forzata degli indici MySQL:

ALTER TABLE wp_posts FORCE INDEX (type_status_date);

Utilizzando il metodo sopra, puoi mantenere la differenza dell’indice stabile al di sotto del 5%.
Se desideri aumentare la velocità di indicizzazione di Google, consulta il nostro GPC Crawler Pool.