Report Rendimento Search Console: come leggerlo e cosa decidere

Il cliente apre Search Console, guarda i quattro numeri in cima al report Rendimento - clic, impressioni, CTR medio, posizione media - e mi fa sempre la stessa domanda: “quindi, va bene o va male?”. Non esiste una risposta a quella domanda, e non perché i dati siano poveri: perché quei quattro numeri sono una media di tutto, e una media di tutto non fa cambiare idea a nessuno. Search Console diventa utile nel momento esatto in cui smetti di guardarla per sapere come stai e inizi a interrogarla per decidere cosa toccare lunedì mattina.

Questo pezzo è il metodo che uso sulle proprietà che seguo: quali filtri metto, quali stati di indicizzazione fanno scattare un intervento e quali no, come distinguo un calo di clic dovuto alle risposte AI da una perdita di posizione, e perché i numeri di Search Console e quelli di Analytics non torneranno mai. Ogni affermazione tecnica qui sotto ha accanto la fonte primaria di Google: dove il dato è mio e non di Google, lo dico.

✅ Proprietà dominio o prefisso URL: la scelta che decide cosa vedrai

Prima ancora dei report c’è una decisione che quasi nessuno rifà una volta sbagliata, perché i dati non sono retroattivi. La documentazione sui tipi di proprietà è netta: una proprietà dominio “includes all subdomains (m, www, and so on) and multiple protocols (http, https, ftp)”, mentre una proprietà con prefisso URL “includes only URLs with the specified prefix, including the protocol (http/https)”.

Tradotto in pratica: se hai verificato solo https://www.tuosito.it e una parte del traffico atterra su un sottodominio o su una vecchia versione senza www, quel traffico dai tuoi grafici non lo vedi e non lo vedrai mai per il periodo passato. La proprietà dominio richiede la verifica via DNS (“DNS record verification only”), che è l’unico motivo per cui in tanti la evitano: dieci minuti dal pannello del registrar contro trenta secondi di file caricato via FTP.

Cosa faccio io su ogni nuovo cliente: proprietà dominio come contenitore principale, più eventuali proprietà a prefisso URL solo quando serve segmentare per percorso, che è l’altro caso previsto da Google (“if you need to limit your data by URL path segments or by protocol”). Su un e-commerce la seconda proprietà tipica è quella sulla sezione blog o magazine, perché ha un comportamento completamente diverso dal catalogo e mediarli insieme nasconde entrambi.

🛠️ Report Rendimento: i filtri con cui lo leggo

La vista di default - ultimi 3 mesi, tipo di ricerca Web, tutto aggregato - serve solo a controllare che il tracciamento esista. Il lavoro comincia con quattro passaggi, sempre gli stessi.

Primo: scendere di livello. Si apre la scheda Pagine, si sceglie una pagina, si torna alla scheda Query. Adesso stai guardando le ricerche che portano impressioni a quella singola pagina, che è l’unico livello a cui puoi decidere qualcosa di concreto, perché è l’unico livello a cui esiste un title da riscrivere.

Secondo: confrontare due periodi. Il filtro data ha la modalità Confronta: 28 giorni contro i 28 precedenti tiene fuori la stagionalità settimanale meglio di qualunque altra finestra. Un numero da solo non ha senso, la differenza fra due numeri sì.

Terzo: usare le regex sulle query. Nel filtro Query, l’opzione “Personalizzata (regex)” permette di isolare famiglie di ricerche: le domande, le ricerche con il brand contro quelle senza, le query con il nome di una città. Resta il modo più veloce per scoprire che una pagina sta prendendo impressioni su un intento diverso da quello per cui l’hai scritta.

Quarto: sapere cosa non puoi concludere. Qui i limiti sono dichiarati e vanno detti al cliente prima, non dopo. La pagina About Search Console data mette in fila i vincoli: le tabelle mostrano al massimo mille righe (“our tables can show a maximum of 1,000 rows, so some rows might be omitted”), alcune ricerche non vengono conservate affatto (“we might not track some queries that are made a very small number of times or those that contain personal or sensitive information”), il dato arriva con un ritardo di due o tre giorni e il giorno di calendario è quello della California, non il tuo. Se ti serve la coda lunga oltre il tetto delle mille righe, la strada è un’altra: le API di Search Console e il bulk export su BigQuery, a cui dedico un pezzo a parte.

Le query in posizione 5-15 (striking distance): la zona di rimonta

Zona di rimonta: le query per cui una pagina ha posizione media compresa fra 5 e 15. In inglese si trovano come keyword in striking distance, ma il nome conta poco: sono la prima cosa che filtro, per un motivo aritmetico: stanno in prima o seconda pagina, quindi la pagina risulta già considerata pertinente, ma raccolgono una frazione minima dei clic disponibili. Muoverle di tre posizioni costa un intervento di poche ore, mentre portare in prima pagina una query in posizione 40 costa mesi e spesso un contenuto nuovo.

Un avvertimento sulla metrica: la posizione media è, testualmente, “the average position of the topmost result from your site”, cioè la media del tuo risultato più in alto, calcolata solo sulle ricerche in cui sei effettivamente comparso. Non è la tua posizione “vera” su quella keyword e non va mai riportata al cliente come se lo fosse.

Cosa si decide con questa vista: quale title e quale meta description riscrivere. Il candidato tipico è la query con molte impressioni, posizione media intorno a 7 e CTR sotto la media delle sue vicine.

Su un e-commerce di forniture industriali che seguo l’intervento è stato massivo: 596 schede prodotto avevano il title generato dal gestionale, cioè il codice articolo in maiuscolo, e sono state riscritte mettendo davanti la famiglia di prodotto con il modificatore che le persone digitano davvero, i metri, la sezione, il grado di protezione. Il dettaglio che rende misurabile l’operazione non è la riscrittura: è che l’elenco delle URL toccate è stato salvato in un file prima di toccarle, con la data dell’intervento. Senza quella lista, in Search Console quelle pagine si confondono con le altre migliaia del catalogo e il confronto non si può fare. CTR sulle sole URL del campione: da [DATO-ENRICO: CTR medio del campione nei 28 giorni precedenti al 13/07/2026] a [DATO-ENRICO: CTR medio nei 28 giorni successivi, con la posizione media dei due periodi].

Un title si riscrive quando i dati dicono che il posto ce l’hai e i clic no. Se la pagina sta in posizione 30, il title non è il problema.

⚠️ Le impression aumentano ma i clic no in Search Console: sono le AI Overviews?

È il pattern che nell’ultimo anno mi arriva più spesso, e la diagnosi automatica “è colpa dell’AI” è sbagliata quanto negarla a priori. Prima le regole di conteggio, che sono pubbliche e cambiano il modo di leggere il grafico.

Google documenta come vengono contate AI Overviews e AI Mode nel report Rendimento. Tre frasi decidono tutto:

• la posizione: “an AI Overview occupies a single position in search results, and all links in the AI Overview are assigned that same position”. Tutti i link dentro una AI Overview ereditano la stessa posizione, quella del blocco;
• l’impressione: “standard impression rules apply. To be counted as an impression, the link must be scrolled or expanded into view”. Se il tuo link resta nella parte compressa e l’utente non espande, non conta nemmeno come impressione;
• il clic: “clicking a link to an external page in the AI Overview counts as a click”, quindi i clic ci sono e stanno nei totali, non finiscono in una categoria a parte.

La conseguenza pratica è che AI Overviews e AI Mode rientrano nei numeri complessivi del tipo di ricerca Web: non esiste nessun grafico “prima dell’AI” da confrontare. Quello che si può isolare, se la tua proprietà ce l’ha, è la vista dedicata alle funzionalità di AI generativa uscita a giugno 2026, di cui ho scritto quando è arrivata nel pezzo sulla visibilità AI in Search Console.

Il metodo di verifica, in assenza di quella vista, procede per esclusione e usa tre grafici sovrapposti sullo stesso periodo:

1. le posizioni tengono? Se la posizione media della pagina è stabile e i clic scendono, la perdita non è di ranking. Se scende anche la posizione, hai un problema di ranking e l’AI non c’entra;
2. le impressioni salgono? Impressioni in crescita a posizione stabile e clic fermi è la firma tipica della comparsa dentro un blocco generativo, che aggiunge presenza senza aggiungere clic;
3. su quali query? Le ricerche informative in forma di domanda si comportano diversamente da quelle transazionali. Se lo scollamento si concentra sulle prime e le seconde restano intatte, il quadro è coerente.

Un caso vero, dalla Search Console di un e-commerce di arredamento che seguo: sei mesi contro i sei precedenti, export di luglio 2026. Sul totale della proprietà i numeri dicono il contrario della vulgata: impressioni -24,3%, clic -6,1%, CTR da 0,978% a 1,213%, posizione media desktop da 27,1 a 14,3. Chi si fosse fermato ai quattro numeri in cima avrebbe concluso “abbiamo perso visibilità” oppure “va tutto bene”, e in nessuno dei due casi avrebbe deciso qualcosa.

La forbice esiste, ma vive dentro tre segmenti e si vede solo isolandoli:

• schede commercianti: impressioni da 31.522 a 48.059 (+52,5%), clic da 2.323 a 1.818 (-21,7%), CTR da 7,37% a 3,78%. È l’unica delle tre superfici tracciate che cresce in visibilità e contemporaneamente perde clic;
• blog (97 pagine): impressioni +32,8% e clic +24,0% in valore assoluto, ma CTR in calo del 6,7% mentre la posizione media pesata migliora da 14,14 a 8,32. È l’unico insieme del sito col CTR che scende, e scende mentre il ranking sale di quasi sei posizioni: nel resto del sito, con lo stesso tipo di miglioramento, il CTR sale del 23%;
• pagine di marchio: le tre più nette passano da +31% a +100% di impressioni con i clic dimezzati e la posizione in miglioramento di otto posizioni.

Da notare bene, perché è il punto che ribalta il metodo: qui la posizione non è ferma, migliora. Sali in classifica, ti mostrano il doppio delle volte e i clic si dimezzano. Il blog resta il caso più solido dei tre proprio perché il miglioramento di posizione è misurato e il CTR scende lo stesso.

Due cautele che vanno dette insieme al dato, altrimenti il dato mente. La prima: è una proprietà sola, serve a mostrare la forma del fenomeno, non la sua entità sul tuo sito. La seconda: un calo di impressioni ha spiegazioni alternative buone, dalla pulizia dell’indice al catalogo che cambia, quindi la conclusione difendibile è “guarda i tuoi segmenti, la media di mercato non ti dice niente”, non “l’AI ha fatto questo”.

Una cosa che il grafico non dirà mai: se quella persona, senza la risposta generata, avrebbe cliccato. Presenza non significa causalità, e chiunque ti quantifichi il “traffico rubato dall’AI” ti sta vendendo una certezza che lo strumento non contiene.

📊 Gli stati di indicizzazione, tradotti in decisioni

Il rapporto Indicizzazione delle pagine l’ho descritto nella checklist su cosa controllare dopo un Core Update, quindi non lo rispiego: qui trovi solo la parte che manca quasi ovunque, cioè la traduzione da stato a intervento. Le definizioni nella colonna centrale sono citate testualmente dalla documentazione del rapporto.

Le tre righe che valgono la maggior parte del lavoro sono le prime due e l’ultima. Le altre, finché il numero non esplode, restano rumore fisiologico.

Perché una pagina risulta “Rilevata: attualmente non indicizzata”

È la query diagnostica che mi arriva più spesso, e la risposta ufficiale sta in una frase che quasi nessuno cita: “typically, Google wanted to crawl the URL but this was expected to overload the site; therefore Google rescheduled the crawl”. Non è un giudizio sul contenuto, perché il contenuto Google non l’ha ancora letto: nel report la data di ultima scansione risulta vuota.

Le tre cause che trovo nella pratica, in ordine di frequenza: il server risponde lento sotto carico e Google rallenta da solo; la pagina non ha link interni che la raggiungano, quindi sta in sitemap ma non nell’architettura del sito; la sitemap contiene molti più URL di quanti il sito ne meriti, tipicamente su un catalogo con combinazioni generate. La prima si misura dal rapporto Statistiche di scansione (tempo medio di risposta), la seconda si vede in dieci secondi provando ad arrivare alla pagina navigando, la terza confrontando il numero di URL inviati con quello delle pagine reali.

“Scansionata: attualmente non indicizzata” e perché non va reinviata

Qui il contenuto Google l’ha letto e ha deciso di non metterlo in indice, per ora. La documentazione risulta esplicita anche sulla reazione corretta: “no need to resubmit this URL for crawling”. Reinviare la stessa pagina tre volte in Ispezione URL non cambia la valutazione, consuma la quota giornaliera e fa perdere un pomeriggio.

Le domande da farsi sono altre due: quella pagina dice qualcosa che le altre cinquanta pagine dello stesso sito non dicono, e c’è qualcosa nel sito che ci punta come se fosse importante? Su un catalogo, questo stato in massa sulle schede prodotto significa quasi sempre descrizioni corte e uguali fra loro, non un problema tecnico.

⚠️ Quante pagine escluse sono normali, e il caso PrestaShop

Nessuna soglia universale esiste, e Google si tiene lontano dal darne una. Quello che dice, testualmente, è che “don’t expect every URL on your site to be indexed. Some URLs might be duplicates or might not contain meaningful information”, con l’unica raccomandazione che conta: “just be sure that the key pages on your site are indexed”. Nella stessa pagina compare anche una soglia sotto la quale il report serve a poco: “if your site has fewer than 500 pages, you probably don’t need to use this report”.

Ne segue il modo giusto di leggere il rapporto, che è l’unico numero a cui guardo davvero: non il totale delle escluse, ma la copertura delle pagine che hai dichiarato importanti. Il rapporto ha un filtro apposta, “all submitted pages”, che mostra solo gli URL presenti nelle sitemap inviate. Su un e-commerce sano quella vista risulta quasi tutta verde; il resto del report, cioè le migliaia di URL che Google conosce e non indicizza, per la maggior parte non doveva essere indicizzato in partenza.

Search Console e PrestaShop: le pagine filtro non indicizzate

Su PrestaShop la navigazione a faccette produce combinazioni di URL con parametri di filtro in numero che cresce in modo combinatorio: taglia per colore per marca per fascia di prezzo. Quegli URL finiscono comunque nel rapporto, quasi sempre come duplicati o come pagine escluse, e il pannello mostra un totale che spaventa il cliente senza descrivere un problema. Il rischio vero non riguarda l’indicizzazione ma il crawl budget bruciato: la parte tecnica su faccette e parametri l’ho trattata nella checklist post Core Update linkata sopra.

La distinzione operativa fra fisiologico e bug la faccio così: sono fisiologiche le esclusioni su URL con parametri di filtro, sugli ordinamenti e sulla paginazione oltre la prima; è un bug ogni esclusione che colpisce una categoria, una scheda prodotto attiva o una pagina informativa presente in sitemap.

Quanti siano davvero quegli URL, però, Search Console non te lo dice bene: te lo dicono i log del server. Su un negozio PrestaShop che seguo, ventiquattro ore di log grezzi contenevano 6.240 richieste su URL con il parametro di filtro, corrispondenti a 6.099 URL distinti: praticamente ogni combinazione richiesta era un indirizzo nuovo mai visto prima. Nelle stesse ventiquattro ore quel sito serviva 5.801 risposte 503, di cui 5.047 su una sola categoria. Il rapporto Indicizzazione non conteneva niente di tutto questo con quella chiarezza: mostrava solo un totale di escluse che cresceva.

Cosa è stato fatto, in ordine, e perché nessuna di queste azioni passa da Search Console: redirect 301 verso l’indirizzo pulito sulle richieste a pagina piena con i parametri, noindex, follow sui filtri (in quel tema era già previsto), canonical sempre verso la versione base, sitemap generata senza nemmeno un URL parametrico. Il risultato immediato misurabile è stato sui 503, azzerati dalla sera dell’intervento, non sul numero di pagine indicizzate: quello si muove nelle settimane successive e va letto sul filtro delle sole pagine inviate, non sul totale.

🛠️ Ispezione URL: il problema è Google o è il tuo sito?

È lo strumento che risponde alla domanda più binaria di tutte, e va usato sapendo che mostra due cose diverse nella stessa schermata. Il dato in alto è quello che Google ha in indice, potenzialmente vecchio di settimane. Il test dal vivo è un’altra cosa: “this is a live test: the tool fetches and examines the URL in real time”, come spiega la documentazione dello strumento.

La lettura incrociata dei due risultati dà la risposta:

• indice dice non presente, test dal vivo dice pagina disponibile: il tuo sito sta funzionando, manca il passaggio di Google. Qui una richiesta di indicizzazione ha senso;
• indice dice non presente, test dal vivo fallisce: il problema è tuo. Blocco robots, noindex, risposta 5xx, redirect, contenuto costruito solo via JavaScript che non arriva nel rendering;
• indice dice presente ma con canonical diverso da quello che hai dichiarato: Google ha scelto un’altra pagina come versione principale, e questo è un problema di duplicazione interna, non di indicizzazione.

Sul pulsante “Richiedi indicizzazione” due frasi ufficiali evitano molte illusioni: “there is a daily limit to how many index requests you can submit” e soprattutto “submitting a request does not guarantee that the page will appear in the Google Index”. Sui tempi Google si tiene larga: “indexing typically takes only a day or so, but can take much longer in some cases”, e per volumi grossi rimanda alla sitemap (“if you want many pages indexed, try submitting a sitemap to Google”). Anche il test dal vivo positivo va ridimensionato: “a positive result is not a guarantee that it will appear in Search results”.

Sui tempi di attesa non ti do un numero mio, perché un numero serio richiederebbe un registro sistematico di richieste e comparse che non tengo. Quello che vale è la frase ufficiale sopra: di solito un giorno o poco più, a volte molto di più, e nessuna garanzia. Chi ti promette l’indicizzazione in ventiquattro ore sta descrivendo il caso migliore come se fosse una regola.

📊 Differenza fra Search Console e Google Analytics: perché i dati sono diversi

Domanda ricorrente in ogni riunione: perché i clic di Search Console e le sessioni da organico di GA4 non coincidono mai? Perché contano cose diverse, e le ragioni stanno documentate una per una nella pagina About Search Console data:

• unità di misura diverse: un clic è un clic sulla SERP, una sessione è una visita registrata sul sito. Chi clicca e chiude prima che lo script parta compare nel primo numero e non nel secondo;
• elaborazione diversa: Search Console “does some additional data processing - for example, to eliminate duplicates and visits from robots”;
• JavaScript: gli strumenti di analytics “track traffic only from users who have enabled JavaScript in their browser”, e a questo oggi si aggiunge il consenso ai cookie, che in Europa toglie un pezzo alla misurazione lato sito e non a quella lato SERP;
• giorno diverso: Search Console usa il giorno della California, GA4 il fuso impostato nella proprietà. Su un confronto giornaliero questo da solo basta a far ballare i numeri;
• latenza: i dati diventano visibili “in 2-3 days”, quindi confrontare gli ultimi due giorni non ha senso.

Va detto anche cosa Google non dice: da nessuna parte nella documentazione compare una percentuale di scarto dichiarata “normale”. Le soglie che girano nei manuali italiani, tipo il classico 10-20%, non hanno una fonte primaria dietro, e non ne ho una mia da mettere al loro posto: misurare uno scarto medio credibile richiede un campione di proprietà confrontabili per configurazione di consenso e di tagging, che è esattamente la variabile che sposta il numero. Una percentuale di riferimento presa da un manuale e riportata al cliente come soglia di normalità è un numero inventato due volte.

La regola operativa che ne ricavo: i due strumenti non vanno confrontati in valore assoluto, ma in andamento. Se salgono e scendono insieme, la misurazione funziona. Se uno si muove e l’altro no, hai un problema di tracciamento, non di SEO.

✅ I primi 30 minuti su una proprietà nuova: otto passi

Questa è la sequenza che eseguo quando ricevo l’accesso a una Search Console mai vista prima, e prima di dire qualunque cosa al cliente.

1. Verifica il tipo di proprietà: se è a prefisso URL, controlla che copra la versione con cui il sito risponde davvero, e valuta di aggiungere subito la proprietà dominio, che da quel momento in avanti accumula storico.
2. Sitemap: apri il rapporto Sitemap, controlla data dell’ultima lettura, stato ed eventuali errori. Una sitemap letta mesi fa o in errore rende inaffidabile metà del resto.
3. Rendimento, ultimi 3 mesi, confronto con i 3 precedenti: qui cerchi la forma della curva, non i valori. Gradino netto, discesa lenta o piatta stabile portano a indagini diverse.
4. Scheda Pagine, prime venti: verifica se il traffico arriva dalle pagine che il cliente considera importanti. Molto spesso no, ed è una conversazione che conviene aprire subito.
5. Zona di rimonta: filtra le query in posizione fra 5 e 15 con impressioni sopra la media, e segna i tre candidati a una riscrittura del title.
6. Indicizzazione, filtro sulle sole pagine inviate: quante delle pagine dichiarate importanti stanno davvero in indice. Questo è il numero che riporti, non il totale delle escluse.
7. Ispezione URL su due pagine campione: la home e la pagina più importante del catalogo, per verificare canonical scelto da Google e data dell’ultima scansione.
8. Annotazioni: se il cliente ha fatto interventi recenti, segnali sul grafico alle date giuste. Fra tre mesi sarà l’unica memoria disponibile di cosa era successo quel giorno.

Quello che deliberatamente non guardo nella prima mezz’ora: Core Web Vitals, Sicurezza e azioni manuali (le apro, ma richiedono trenta secondi e o c’è un allarme o non c’è), e tutti i report sui dati strutturati. Non perché non contino, ma perché nessuno di quei report cambia la decisione della prima settimana, mentre i sei passi centrali la cambiano quasi sempre.

Cosa decide il report, e cosa decidi tu

La sintesi in tre righe. Search Console non dice se stai andando bene: dice dove esiste uno scarto fra quanto vieni mostrato e quanto vieni scelto, e quello scarto rimane l’unico posto dove un intervento ha un ritorno rapido. Gli stati di indicizzazione non sono voti, sono istruzioni, e metà di loro chiede esplicitamente di non fare niente. I numeri che non tornano con Analytics non sono un errore da correggere: sono due misurazioni di due cose diverse, e vanno confrontate come andamenti.

Il resto è disciplina: un intervento alla volta, l’annotazione sul grafico alla data giusta, e la pazienza di rimisurare dopo quattro settimane invece che dopo tre giorni. Se hai un e-commerce e vuoi che questa lettura la faccia qualcuno che poi mette anche le mani sul sito, è esattamente il lavoro che faccio come tecnico PrestaShop. Scrivimi da uno dei canali qui sotto.