Una skill per analizzare il mio sito

Da un po’ di tempo avevo in testa un’idea abbastanza semplice: capire cosa succede su ai-know.pro andando oltre la raccolta separata dei dati che mi danno Google Analytics e Google Search Console, aggregando i dati delle due piattaforme per ottenere qualcosa che nessuna delle due produce da sola.

Il problema che volevo risolvere è che da una parte Analytics ti dice come si comportano i visitatori una volta arrivati sul sito (quante sessioni, quanto tempo restano, da dove vengono, quali pagine leggono), dall’altra Search Console ti dice cosa succede prima, nel momento in cui il sito appare nei risultati di ricerca (quante volte viene mostrato, per quali query, quante volte qualcuno ci clicca sopra). Sono due fotografie dello stesso fenomeno prese da angolazioni diverse, e la foto interessante è quella che le unisce.

Ad esempio una pagina con un bounce rate alto, diciamo che il 70% dei visitatori la abbandona subito, puoi avere almeno tre spiegazioni diverse. Il contenuto non corrisponde a quello che le persone si aspettavano. Il titolo nei risultati di ricerca promette qualcosa che l’articolo non mantiene. Oppure stai comparendo per query che non coerenti con i tuoi contenuti e chi arriva non è il tuo pubblico. Le tre spiegazioni richiedono interventi completamente diversi, i dati di Search Console servono per distinguer.

C’era però un secondo problema, meno ovvio del primo, anche con entrambi gli strumenti aperti in parallelo si ricevono comunque numeri, non interpretazioni. Analytics e Search Console fanno quello per cui sono stati costruiti, raccogliere e organizzare dati. Il ragionamento su quei dati è sempre stato un passaggio separato, affidato a chi li consulta o a strumenti di analisi dedicati.

Nell’universo Google esiste Looker Studio, che permette di connettere GA4 e Search Console in un unico pannello e di costruire visualizzazioni personalizzate. Avvicina i dati, ma non li interpreta: sei ancora tu a dover leggere e ragionare su quello che vedi. Il passaggio dall’aggregazione all’analisi contestuale rimane un gap che nessuno strumento nativo di Google colma

Mi serviva uno strumento capace di fare anche questo passaggio, prendere i dati, incrociarli e produrre un’analisi che tenesse conto di tutto insieme. Un’analisi come quella che farebbe un consulente che conosce bene il sito, non un report automatico.

La soluzione è stata costruire una skill per Claude. Non un nuovo software, non un’integrazione personalizzata, ma un file di istruzioni che descrive il problema da risolvere, definisce la sequenza con cui raccogliere i dati dai due strumenti e specifica come ragionare su quello che emerge. Claude gestisce il resto, con le sue capacità di comprensione del contesto riconosce le anomalie e produce una diagnosi in linguaggio normale invece di un export da interpretare.

La scelta degli strumenti

Il primo passaggio è stato capire come collegare Claude a Google Analytics e a Search Console. Per questo esistono i server MCP, i connettori che permettono a Claude Desktop di interrogare servizi esterni in modo diretto.

Per Search Console la scelta è ricaduta su mcp-gsc di AminForou, un progetto della comunità con 19 tool disponibili: query di ricerca, ispezione degli URL, gestione delle sitemap, confronto tra periodi. Stabile, ben documentato, fa esattamente quello che serve.

Per Google Analytics la situazione era più articolata. Esiste un server MCP ufficiale di Google, ma per le mie esigenze presentava un limite rilevante: l’autenticazione richiede un flusso OAuth interattivo, il che lo rende meno adatto a un uso quotidiano integrato in Claude Desktop. Ho scelto invece google-analytics-mcp di surendranb, un progetto della comunità che si autentica tramite service account e che si configura una volta e poi funziona senza interruzioni. Meno ufficiale, ma più pratico per l’uso che ne volevo fare. Dà accesso a oltre 200 dimensioni e metriche GA4, più che sufficienti.

La configurazione di entrambi i server ha richiesto un po’ di lavoro lato Google Cloud Console, come creare credenziali, abilitare API, assegnare permessi. Non è la parte più semplice, ma si fa una volta sola.

Il lavoro sulla skill

Con i due server attivi, il passo successivo è stato costruire la skill: un file di istruzioni che dice a Claude come usarli insieme, in quale sequenza recuperare i dati, come interpretarli e come strutturare la risposta.

Il processo di costruzione è stato quello che ormai chiamo col termine vibe coding, anche se qui non si trattava di codice ma di logica e documentazione. Hai un’idea di cosa vuoi ottenere, la descrivi, Claude abbozza una struttura, tu la testi, ti accorgi di cosa manca o non funziona, correggi, rilanci. L’iterazione va avanti finché il risultato fa quello che deve fare.

Il mio ruolo è stato quello del committente e del tester: definire i casi d’uso, specificare come volevo che venissero presentati i risultati, testare le analisi su dati reali e segnalare quando la diagnosi mancava di qualcosa. Claude ha gestito la stesura e il raffinamento progressivo dei file.

La skill è organizzata in tre modalità operative.

• Panoramica del sito: interroga entrambe le piattaforme, costruisce un quadro del periodo (di default gli ultimi 28 giorni), identifica il rapporto tra traffico organico e traffico da altri canali, elenca le query e le pagine principali, e segnala al massimo tre punti di attenzione prioritari. Non una lista di numeri, ma un ragionamento sui numeri.

• Analisi della singola pagina: prende un URL specifico, recupera i dati GA4 di engagement e il breakdown GSC delle query che portano traffico a quella pagina, e applica una logica diagnostica per identificare la causa più probabile di eventuali problemi. CTR basso con posizione buona? Problema di title o meta description. Bounce rate alto con durata bassa? Il contenuto non corrisponde alle aspettative. Ogni diagnosi viene accompagnata da un’azione concreta suggerita.

• Ricerca di opportunità SEO: identifica le pagine già in posizione 8-20 nei risultati di ricerca che mostrano buon engagement quando il traffico arriva. Queste sono le pagine su cui vale la pena intervenire, perché richiedono un miglioramento minore per ottenere un risultato visibile.

La prima analisi: cosa funziona e cosa no

Ho testato la skill subito dopo averla completata, usando solo i dati di Analytics. In uno dei test ho chiesto un’analisi qualitativa basata sui dati degli ultimi sei mesi, mi ha risposto così:

Il sito racconta due storie sovrapposte, e non è detto che tu ne sia pienamente consapevole.

La prima è la storia di un esperto che costruisce in pubblico il proprio percorso di esplorazione di Claude e dell’ecosistema Anthropic. Gli articoli più ricchi di engagement, quelli che le persone leggono davvero, non solo aprono, hanno tutti questa caratteristica: sono scritti da qualcuno che ha fatto le cose, non da qualcuno che le ha lette. L’installazione di Claude Desktop, la connessione con NotebookLM, l’MCP per Ollama, GIMP integrato con Claude: sono documentazione di pratica reale. Il lettore lo sente, e si ferma.

La seconda storia è quella di un osservatore del settore che commenta l’attualità AI. Questa parte del sito funziona in modo completamente diverso: genera traffico immediato, spesso significativo, ma non costruisce una relazione duratura con il lettore. Chi arriva su un articolo di news legge, magari condivide, e non torna. Non è un problema in sé, ma è importante sapere che queste due tipologie di contenuto costruiscono cose diverse.

C’è poi un terzo elemento, più sottile, gli esperimenti come il simulatore della digestione, il simulatore gravitazionale, il cuore interattivo. Questi contenuti non assomigliano a niente di quello che normalmente si trova su un blog di divulgazione AI italiano. Portano traffico da Facebook in modo significativo, ma il dato che conta di più è che chi li visita tende ad esplorarli con una certa attenzione. Hanno una funzione diversa dagli altri contenuti: dimostrano, non spiegano. Mostrano cosa è possibile fare senza richiedere al lettore nessuna competenza tecnica per capirlo.

Guardando il sito dall’esterno, si percepisce una tensione non risolta tra queste anime. Il posizionamento Google sta andando chiaramente nella direzione “Claude + ecosistema Anthropic”, ed è lì che si sta costruendo l’audience organica che cresce in modo autonomo. Il contenuto fotografico e quello di ampio respiro sull’AI in generale è ancora presente, forse per continuità con il percorso precedente, ma non sembra che stia costruendo qualcosa di distinto nel tempo.

La cosa più interessante è questa: il tuo pubblico più fedele, quello diretto, quello di Substack, quello che torna, sta chiaramente cercando qualcosa di specifico. Non vuole il blog generalista di AI, vuole la guida pratica all’ecosistema Claude scritta da qualcuno che lo usa davvero. Il fatto che le pagine-indice /tutorial/ e /manuali/ abbiano i bounce rate più bassi di tutto il sito dice che chi arriva lì non vuole un articolo, vuole orientarsi in un corpus. È un segnale che vale la pena prendere sul serio.

Cosa cambierà con Search Console attivo

Search Console ha bisogno di tempo per accumulare dati sufficienti. Quando saranno disponibili, l’analisi potrà diventare quella per cui la skill è stata costruita, e cambierà il tipo di domande a cui sarà possibile rispondere.

Con i soli dati di Analytics si capisce cosa succede dentro il sito, quali contenuti tengono l’attenzione, quali vengono abbandonati subito, quali generano esplorazione. È già molto, ma manca tutto quello che succede prima che qualcuno arrivi sul sito.

Con Search Console attivo sarà possibile chiudere il ciclo. Si potrà capire, per esempio, se un articolo con bounce rate alto attira traffico sbagliato, persone che cercano qualcosa di diverso da quello che trovano, oppure se il problema è nel contenuto stesso. Due situazioni che in Analytics sembrano identiche ma che richiedono interventi opposti, nel primo caso si lavora sul titolo che appare nei risultati di ricerca, nel secondo sul testo dell’articolo.

L’analisi qualitativa riportata sopra è stata prodotta senza questi dati. Con Search Console sarà possibile verificare se le interpretazioni reggono, e dove invece i dati di ricerca raccontano una storia diversa da quella che il comportamento degli utenti suggerisce.

In conclusione

Vale la pena spiegare cosa rende questo approccio diverso dall’uso diretto di Analytics e Search Console, perché la differenza non è solo di comodità.

Gli strumenti ufficiali di Google sono costruiti per rispondere a domande standard, come quante sessioni, quali pagine, quali query. Rispondono bene, ma richiedono che tu sappia già cosa chiedere, che tu sappia dove guardare e che tu faccia da solo il lavoro di collegare quello che vedi in uno strumento con quello che vedi nell’altro. Il risultato dipende da quanto sei esperto nell’interpretare i dati, e anche in quel caso rimane un’attività separata dalla gestione del sito.

Con la skill il processo funziona diversamente. Puoi descrivere in linguaggio normale quello che vuoi capire e ricevere un’analisi invece di un insieme di tabelle. Le domande che si possono fare vanno da “perché questo articolo ha un engagement così basso” a “quali contenuti vale la pena aggiornare”, fino al “come sta andando il sito negli ultimi tre mesi”. Le risposte che si ottengono non sono generiche ma calibrate sul sito specifico, con quella storia specifica, scritto da quella persona per quel pubblico.

Questa personalizzazione è la differenza sostanziale. Un report automatico non sa che il sito ha attraversato una transizione tematica, non sa che certi contenuti sono stati scritti per un pubblico di fotografi e altri per professionisti che usano Claude, non sa che alcune pagine con bounce rate alto sono intenzionalmente di lettura rapida. Claude lo sa, perché fa parte del contesto in cui l’analisi viene chiesta.

Il secondo elemento è la capacità di riconoscere quello che i numeri non dicono direttamente. Nell’analisi riportata in questo articolo la conclusione più interessante non era un dato ma era l’osservazione sulle due anime del sito che i numeri mostravano indirettamente, ma che nessun dashboard avrebbe mai formulato in quel modo. Quel tipo di lettura richiede comprensione del contesto, non solo accesso ai dati.