LCP da 5,5 secondi a 3,5; performance score da 67 a 88; impressioni settimanali da 180 a oltre 4.000 in 11 settimane. Architettura di interlink recuperata su 21 post in un pomeriggio.
Questi sono i risultati misurati sul mio sito – giovanniliguori.it —, un ecosistema di automazioni AI costruito in 11 settimane.
Ma i numeri iniziali sono solo metà della storia. La parte interessante è quello che succede dopo: un sistema che ogni giorno monitora, identifica problemi, corregge errori e adatta la strategia. Non un audit one-shot, un ciclo continuo di miglioramento automatizzato.
Indice degli argomenti:
Il contesto
Claude Code (Anthropic) è un agente AI a riga di comando che opera direttamente sul codebase di un progetto: legge il codice, identifica problemi, implementa fix e committa su git. Per la SEO tecnica, questo comprime un ciclo audit-ticket-sviluppo-deploy da 2-4 settimane a 2-3 giorni, a patto di avere competenza tecnica per supervisionare l’output.
A marzo 2026, giovanniliguori.it — Next.js 15, Sanity v3, Vercel — aveva 540 impressioni totali in 3 mesi su Google Search Console, 25 click totali, e un solo articolo che generava il 70% del traffico. L’audit tecnico ha rivelato:
- LCP 5,5 secondi su mobile (zona rossa per i Core Web Vitals)
- H1 mancanti su 2 pagine chiave
- Zero schema FAQPage sui blog post
- Architettura di interlink assente sul 55% degli articoli
- Zero link esterni autorevoli sui top 5 post
- Meta robots non ottimizzato
Lo stack tecnico era solido. Il problema era nell’ottimizzazione SEO del codice e dei contenuti.
Perché la gestione manuale non scalava
Il punto non è la velocità di esecuzione dei singoli fix — un SEO specialist competente li avrebbe fatti in un paio di mesi. Il problema è quello che succede dopo.
Un sito con 80+ post pubblicati genera ogni settimana nuovi problemi: un articolo che perde posizioni, un competitor che pubblica su una keyword presidiata, un contenuto che finisce live senza meta description, un cluster tematico sbilanciato. Nella gestione manuale, questi problemi restano invisibili fino al report mensile. Quando li scopri, hai già perso 4 settimane di ranking.
Il differenziale dell’automazione non è “faccio le stesse cose più velocemente”. È: monitoring in tempo reale + azione correttiva autonoma + feedback loop che chiude il ciclo. È la differenza tra un termostato e alzarsi ogni ora a controllare la temperatura.
Fase: i 6 fix tecnici iniziali
1. Fix performance: LCP da 5,5s a 3,5s
Il Largest Contentful Paint era la priorità assoluta. Google lo usa come Core Web Vital per il ranking mobile. L’agente ha analizzato il componente Hero della homepage: immagine principale senza priority né fetchpriority=“high”, animazioni GPU che consumavano risorse, CSS non ottimizzato per il critical rendering path. In 3 iterazioni: priority + preload sull’immagine LCP, rimozione effetti GPU, conversione in WebP, lazy loading sul below-the-fold.
Risultato verificato su PageSpeed Insights (15 aprile 2026, 18:48 CEST, mobile): LCP 3,4s, FCP 1,2s, Performance score 91, CLS 0, SEO 100. Nota: la prima misurazione post-fix (27 marzo) restituiva LCP 1,4s e score 97; successive modifiche al codebase hanno causato una regressione parziale, corretta il 15 aprile con risultati leggermente inferiori. Snapshot di controllo del 13 maggio 2026 conferma il sistema stabile a 4 settimane di distanza: Performance 88, LCP 3,5s, FCP 1,2s, CLS 0,002, SEO 100. La leggera oscillazione rispetto al 15 aprile è coerente con il rumore tipico di misurazioni Lighthouse ripetute e con il rilascio continuo di nuovo contenuto.
2. Schema markup dinamico automatico
Un sistema di structured data con 5 builder:
- FAQPage (estrae le FAQ dal body del CMS automaticamente),
- Product (prezzi dinamici),
- HowTo (tutorial step-by-step),
- Breadcrumb,
- entity graph Person + ProfessionalService + WebSite. Se un post ha un H2 “Domande Frequenti” con H3 sotto, lo schema FAQPage viene generato senza intervento. Zero configurazione manuale per singolo post.
3. Recupero architettura di interlink su 21 post
Il 55% dei blog post non aveva link interni strutturati — un segnale negativo per la topical authority che Google valuta per il ranking. Non un errore intenzionale: è il risultato tipico di una pubblicazione accelerata dove il contenuto viene creato più velocemente di quanto si riesca a collegare. Ogni post ha ricevuto 2 link contestuali: uno al pillar article del cluster e uno a una pagina di conversione. Stima del tempo risparmiato: 4-5 ore di lavoro manuale su Sanity Studio completate in circa 90 minuti [misurato su singola sessione, N=1].
4. Meta robots, sitemap e compliance AI crawler
Implementati in batch: tag googleBot con max-image-preview:large (necessario per AI Overview e Featured Snippets), sitemap.xml con priorità ricalibrate, robots.txt con blocco selettivo di 9 AI crawler (GPTBot, PerplexityBot, CCBot), citation meta tag, ed endpoint /llms.txt per la Generative Engine Optimization (GEO).
5. Monitoring GSC settimanale
Un task schedulato che ogni lunedì interroga l’API di Google Search Console: keyword in salita e in discesa, opportunità di CTR (pagine con molte impressioni e pochi click), direttive operative per il content plan.
6. Competitor tracking
Un task settimanale che monitora i competitor per nuovi contenuti, identifica keyword a rischio di cannibalizzazione, e suggerisce risposte editoriali.
Fase 2: il sistema che si auto-corregge
I fix iniziali sono lavoro da consulente. La differenza è quello che succede dal giorno dopo: un ecosistema di 7 task automatizzati che opera su un ciclo settimanale.
Il principio è semplice: ogni task produce un output strutturato che gli altri possono leggere. Il monitor GSC scrive “keyword X ha perso 5 posizioni”. Il content writer legge quel segnale e produce un articolo mirato. L’auditor verifica che il nuovo articolo rispetti gli standard. L’orchestratore della domenica legge tutto e decide le 3 priorità della settimana successiva.
In pratica: il lunedì il sistema sa come è andato Google, tre volte a settimana produce contenuto mirato ai gap identificati, ogni giorno un verificatore controlla la qualità di quello che è andato online (e mette in bozza quello che non supera i criteri), la domenica sera un orchestratore sintetizza tutto e dà le direttive per la settimana entrante. Il ciclo si chiude.
L’esempio che ha testato il sistema: la crisi del crawl budget
A inizio aprile il sistema ha generato un problema che poi ha dovuto risolvere da solo. La pubblicazione aggressiva — un articolo al giorno per 35 giorni — ha saturato il crawl budget di Google: il 62,5% degli URL era in stato “Rilevata ma non indicizzata” su Search Console. In pratica, Googlebot spendeva risorse su contenuti nuovi senza riuscire a indicizzarli, perché il dominio non aveva ancora l’authority necessaria per giustificare quel volume.
Il sistema ha reagito senza intervento manuale. Il monitor GSC ha rilevato l’anomalia nell’indexing rate. L’orchestratore ha emesso una direttiva: ridurre la frequenza a 3 articoli a settimana fino a recovery. Il content writer ha rallentato. L’auditor ha iniziato a segnalare contenuti duplicati da consolidare. L’unica azione umana: la sottomissione manuale di 15 URL prioritari a Google per accelerare il recrawl.
Al 13 maggio 2026 il crawl budget era ancora in fase di lavorazione attiva — l’audit URL Inspection API dell’11 maggio su un campione di 105 URL prioritari mostrava 31 INDEXED (29,5%), sotto il target operativo dell’80%.
In parallelo è andato live il fix codice (sitemap ISR con revalidate 300 secondi, canonical SSR sui post blog, webhook /api/revalidate con signature check) e la queue di richieste manuali di indicizzazione è in esecuzione. Il rientro dal picco di metà aprile è lento e misurabile: il sistema sa di essere in una fase di risanamento e regola autonomamente la cadenza.
L’episodio è significativo: dimostra sia il rischio (un’automazione mal calibrata crea danni SEO reali e misurabili) sia il vantaggio (il monitoring li identifica in giorni anziché settimane, e la risposta è coordinata tra tutti i componenti). In una gestione manuale, questo problema sarebbe emerso al report mensile successivo. Un mese di crawl budget sprecato.
Risultati misurati
Performance tecnica (post-deploy, finestra marzo-maggio 2026)
| Metrica | Prima | Dopo (13 mag 2026) |
| LCP | 5,5s | 3,5s (−36%) |
| Performance score | 67 | 88 |
| FCP | 2,8s | 1,2s |
| TBT | n/d | 40 ms |
| CLS | 0,12 | 0,002 |
| Lighthouse SEO | — | 100 |
Visibilità organica (ultimi 7 giorni al 10 maggio 2026 vs baseline)
| Metrica | Prima | Dopo (7gg, 10 mag) |
| Impressioni settimanali | ~180 (media Q1) | 4.027 (+2.137%) |
| Click settimanali | ~6 (media Q1) | 54 (+800%) |
| CTR | ~2% | 1,34% |
| Posizione media | n/d | 5,49 |
Su 28 giorni (13 aprile – 10 maggio 2026, dati GSC): 8.633 impressioni, 156 click, CTR 1,81%, posizione media 5,86. Due articoli sopra le 1.000 impressioni nella finestra: il comparatore Claude Pro vs Max (4.993 imp, 67 click, posizione 5,2) e la guida Claude AI (1.482 imp, 39 click, posizione 6,4). Insieme generano circa il 70% del traffico organico totale del dominio. Un terzo articolo, la guida Claude Code, è in avvicinamento alle 1.000 impressioni mensili (810 imp, posizione 7,4) — segnale che il cluster sta maturando come hub tematico, non come singolo articolo dominante.
Nota onestà sul CTR: la crescita rapida delle impressioni ha diluito il CTR rispetto alla baseline (da 2,08% del 28 aprile a 1,81% del 10 maggio sulla finestra 28 giorni; sulla settimana il CTR si attesta all’1,34%). Il segnale che leggo è che il sistema sta intercettando query più broader — più visibilità, ma in posizioni dove la rilevanza dell’intento è meno mirata. In parallelo la posizione media è migliorata sia su 7 giorni (5,49 vs 6,06 del 7 maggio) che su 28 giorni (5,86 vs 6,05), e il volume di click in valore assoluto è cresciuto del +42% in sei giorni. Il fine-tuning della relevance per query con intent commerciale è il prossimo step di lavoro.
I fix tecnici (Core Web Vitals, schema markup) hanno effetto misurabile in 2-4 settimane dal recrawl. I fix di contenuto (interlink, espansione articoli) richiedono 4-8 settimane. I dati a 28 e 7 giorni includono l’effetto dei fix tecnici (prima applicazione 27 marzo, correzione regressione 15 aprile) e l’effetto cumulato dei fix di contenuto. I miglioramenti non sono attribuibili a un singolo fattore: automazione, nuovi contenuti, ottimizzazioni tecniche e maturazione organica del dominio contribuiscono tutti.
Quando funziona, quando no, e in che proporzione
Dopo 11 settimane di sistema in produzione, una stima onesta della ripartizione del valore generato:
Stima retrospettiva basata sul tempo investito: circa il 30% dei miglioramenti è attribuibile all’esecuzione automatizzata — i fix tecnici che un agente AI esegue in ore anziché settimane: performance, schema markup, meta tag, sitemap, interlink batch. Lavoro ripetitivo, basato su regole chiare, con criteri di successo oggettivi. [N=1, periodo: 11 settimane, non isolabile dai fattori confondenti]
Il restante ~70% viene da decisioni editoriali e strategiche umane: quali keyword presidiare, quale angolo dare ai contenuti, come posizionarsi rispetto ai competitor, quale tono di voce usare, quando è il momento di rallentare la pubblicazione. L’automazione esegue la strategia; non la crea.
Questo è il punto che la narrativa corrente sull’AI applicata alla SEO spesso ignora. Lo strumento è un moltiplicatore, non un sostituto. Senza una strategia SEO valida a monte, un agente AI produce contenuto irrilevante più velocemente. Con una strategia solida, lo stesso agente comprime i tempi di esecuzione e aggiunge un layer di monitoring continuo che nella gestione manuale semplicemente non esiste.
Non funziona per: keyword research strategica, analisi dell’intento di ricerca, decisioni su quale contenuto creare, valutazione della qualità E-E-A-T, outreach relazionale (che resta un’attività tra persone). Questi ambiti richiedono giudizio, contesto di mercato e comprensione del pubblico.
Le lezioni apprese (errori inclusi)
La prima: un’automazione mal calibrata crea danni misurabili. Pubblicare un articolo al giorno su un dominio con bassa authority ha saturato il crawl budget. Il problema è ancora in fase di lavorazione attiva al 13 maggio — l’audit URL Inspection dell’11 maggio mostra il 29,5% di URL prioritari indicizzati, contro il target dell’80%. Il danno richiede settimane per essere riassorbito. In una gestione manuale, sarebbe emerso al report mensile: un mese di ritardo.
La seconda: i task di verifica contano più di quelli di produzione. L’auditor ha intercettato 14 contenuti sotto standard che sarebbero andati live senza controllo. Il compliance checker ha identificato un bug ricorrente nei link interni (venivano scritti come testo semplice nel CMS, invisibili a Google). Senza questi verificatori, il sistema produrrebbe volume senza migliorare la qualità.
La terza: il valore è nel ciclo, non nei singoli componenti. Sette task isolati producono rumore. Sette task che comunicano attraverso un canale condiviso — dove il monitoring alimenta le decisioni, le decisioni guidano la produzione, la verifica chiude il ciclo — producono un sistema che si autocorregge. La differenza non è tecnologica: è architetturale.
Nota metodologica
tutti i dati in questo articolo provengono da Google Search Console e PageSpeed Insights relativi al dominio giovanniliguori.it, misurati tra marzo 2026 e metà maggio 2026. L’accesso condiviso alla property GSC è disponibile su richiesta per la verifica editoriale. Screenshot delle dashboard sono allegati. I miglioramenti osservati riflettono l’effetto combinato di automazioni, nuovi contenuti, ottimizzazioni tecniche e ranking organico naturale — non è possibile isolare il contributo di un singolo fattore.
