Claude Code SEO: L'Agente che Modifica il Vostro Sito, Non le Vostre Bozze

Cercate “claude code seo” e la maggior parte di ciò che trovate sono raccolte di prompt: incollate la vostra bozza in Claude e chiedete meta descrizioni, generate dieci varianti di titolo, fate brainstorming di parole chiave. Tutto questo tratta Claude Code come una macchina da scrivere con opinioni — il che perde completamente ciò che la cosa effettivamente è. Claude Code è l’agente terminale di Anthropic. Le sue capacità native sono leggere file, modificare file ed eseguire git. E su un sito web moderno, questo elenco descrive praticamente l’intera superficie dell’SEO — perché i vostri tag title, canonical, sitemap, regole robots, redirect e dati strutturati non sono impostazioni in un dashboard. Sono righe di codice in un repository.

Questo è il reframe a cui questa guida si impegna: Claude Code non assiste l’SEO, trasforma l’SEO in lavoro su repository — trovate il problema in Search Console, modificate i file sorgente reali, aprite una pull request, e verificate il movimento in Search Console settimane dopo. Questo è il lato operativo della nostra guida su Claude per SEO: non ciò che il modello può scrivere, ma ciò che l’agente può fare.

I vostri problemi di SEO sono file

Esaminate ciò che un audit SEO rileva e dove effettivamente risiede ogni elemento su un sito framework. Il titolo debole sulla vostra money page è un export generateMetadata. Gli URL duplicati che dividono i vostri segnali sono una regola canonical in un file di layout. Le pagine che Google non ha mai trovato sono una voce mancante da app/sitemap.ts. Il blocco staging che è finito in produzione è una riga in app/robots.ts. Il rich result che non state ottenendo è un componente JSON-LD che si è allontanato dalla sincronizzazione con la pagina. Nessuno di questi è un artefatto di marketing. È codice, versionato in git, modificabile in secondi.

Il flusso di lavoro tradizionale ignora questo. Uno strumento trova il problema in un browser, un marketer lo scrive in un ticket, uno sviluppatore lo prende due sprint dopo, e nessuno verifica di nuovo il numero in seguito. Il finding era istantaneo; la spedizione ha richiesto un mese; la verifica non è mai accaduta. Quel divario non è un problema di talento — è ciò che ottenete quando le persone che trovano problemi di SEO e le persone che possono modificare i file vivono in strumenti diversi. Un agente di codifica che può interrogare Search Console e modificare il sorgente collassa il divario in una sessione.

Ciò di cui Claude Code ha bisogno: prove che può interrogare, file che può modificare

Di fabbrica, Claude Code che esegue nel vostro repository del sito ha le mani ma non le prove. Può leggere ogni template, ma non può sapere quale query si trova sulla prima pagina guadagnando nulla, quali pagine Google mostra ma nessuno clicca, o come si presentano i risultati concorrenti. Quella conoscenza vive in Google Search Console e nei SERP — fuori dal repository, dietro le API.

Il ponte è MCP, il Model Context Protocol — lo standard aperto, introdotto da Anthropic, che permette a Claude Code di chiamare strumenti remoti naturalmente come legge file locali. Connettete un server MCP che espone i vostri dati di Search Console e una bacheca di task condivisa, e l’agente all’improvviso ha entrambi i lati del lavoro: può eseguire una query GSC per trovare la pagina con underperforming, cercare nel repository il template che la renderizza, modificare il file, e registrare l’intera transazione su una bacheca che sopravvive alla sessione. Come è costruito quel server — scopes, strumenti, la bacheca come sistema di record — è l’argomento della guida gemella su server MCP per SEO; il cablaggio pratico è un singolo comando claude mcp add, coperto nella guida di connessione.

Il loop, da capo a fondo: find, edit, PR, verify

Ecco l’intero meccanismo, eseguito come un unico movimento continuo invece di quattro lavori disconnessi. È l’implementazione concreta del ciclo find → fix → verify che la nostra guida all’SEO a ciclo chiuso descrive in astratto — con Claude Code come le mani ad ogni passo.

1. Find — le prove vengono da Search Console

L’agente interroga GSC tramite MCP per i pattern che vale la pena affrontare: query che si posizionano sulla prima pagina con un click-through rate ben al di sotto di ciò che la posizione dovrebbe guadagnare, pagine con impressioni e nessun click, query a distanza di tiro che si aggirano alla posizione undici, URL che la sitemap dichiara ma l’indice ignora. Su un sito che abbiamo sottoposto ad audit, una query commerciale se ne stava comodamente sulla prima pagina e guadagnava quasi nulla — il titolo che Google mostrava era un default di template che non diceva nulla che un compratore cliccherebbe. Nessuno crawler lo segnala; le prove esistono solo nei dati a livello di query di Search Console. Ogni finding diventa un task con la metrica che giudicherà il fix impegnato in anticipo: questo è un problema di CTR, quindi CTR sarà il giudice.

2. Edit — il fix è un diff, non un suggerimento

Ora la parte che nessun dashboard può fare. L’agente cerca nel repository la rotta, legge l’export generateMetadata o il layout che produce il titolo debole, e lo modifica — nel file reale, nello stile del codice circostante. I bug a livello di template ottengono fix a livello di template: una modifica a un file di layout corregge ogni pagina che quel layout renderizza, qualcosa che un flusso di lavoro CMS pagina per pagina non può esprimere. Lo stesso movimento copre componenti schema, logica canonical, link interni, redirect — tutta la superficie di audit repository-first.

3. Ship — la pull request è il gate di revisione

L’agente crea un branch, fa un commit e apre una PR la cui descrizione porta le prove: la query, i numeri che l’hanno segnalata, l’impatto atteso, la metrica che la verificherà. Un umano esamina il diff e fa il merge — oppure controbatte. Nulla atterra silenziosamente. La PR merged fa il doppio dovere: spedisce il fix e lo timestamp, e quel timestamp è da dove il clock di verifica inizia. Il task si capovolge a done con l’URL della PR allegato.

4. Verify — Search Console rende il verdetto

Circa tre settimane dopo — tempo sufficiente per una ricrawl e per l’accumulo di dati di query freschi su entrambi i lati del cambiamento — la metrica impegnata viene riletta sulla query esatta che il task ha nominato. Si è mossa e ha tenuto: confermato, e il sito ora ha un fatto provato che non aveva prima. Si è mossa nel modo sbagliato: regressione, e il task si riaprì con informazioni migliori. Non riesce ancora a dire: inconcludente, un null onesto. Un monitor settimanale fa la ri-lettura, quindi nessun umano deve ricordare trenta date di verifica.

Perché la PR rende questo più sicuro, non più lento

L’obiezione istintiva a un agente che modifica il vostro sito web è il rischio — e ha esattamente il rischio al contrario. Confrontate i modi di fallimento. Una modifica bulk CMS o un toggle “auto-ottimizza” di plugin modifica le pagine senza diff, senza revisore, e senza un modo pulito di tornare indietro. Una pull request è l’opposto di tutti e tre: ogni cambiamento è un diff leggibile, un umano lo approva prima che esista in produzione, e git revert lo annulla in un movimento. Il flusso di lavoro PR che i team di software hanno adottato precisamente perché i cambiamenti non esaminati vi bruciano è lo stesso gate che rende l’SEO agenticа fidata.

Un agente che suggerisce è sicuro e inutile. Un agente che spedisce silenziosamente è utile e pericoloso. Un agente che spedisce attraverso una pull request è sia utile che esaminabile — questo è l’intero design.

Il gate risolve anche qualcosa di più sottile: l’attribuzione. Perché ogni fix è un commit merged con un timestamp, la domanda “cosa è cambiato e quando?” — la domanda che rende la maggior parte dei retrospettivi SEO dissolti in sospiri — ha una risposta esatta. La verifica è buona solo quanto il record di ciò che è stato spedito, e git è il miglior change record mai costruito.

Claude Code vs. Claude in una finestra di chat

Lo stesso modello si trova dietro entrambi, il che è esattamente perché il confronto è chiarificante: la differenza non è intelligenza, è agency. Una finestra di chat può ragionare sull’SEO brillantemente e lasciare comunque ogni finding bloccato dal vostro lato del vetro — voi portate l’insight al CMS, ricordate di ri-controllare, siete il loop. Claude Code con accesso MCP è il loop.

Ciò che questo onestamente non può fare

Quattro limiti, affermati chiaramente. Primo, il loop ha bisogno dei suoi dati: senza Search Console connesso tramite MCP, Claude Code sta facendo audit al buio — può leggere ogni file e comunque non sapere quale conta, perché l’importanza è una proprietà di query, non di codice. Secondo, la verifica obbedisce alla fisica della fonte di dati, non al vostro ciclo sprint: il proprio reporting di Search Console è in ritardo di circa due giorni, le ricrawl richiedono giorni in più, e un fair before-and-after ha bisogno di impressioni su entrambi i lati — leggete il numero al giorno cinque e state valutando rumore. Terzo, eseguito onestamente, una quota reale di fix verificherà inconcludente, specialmente piccoli cambiamenti di igiene; un sistema che confermava tutto vi starebbe mentendo.

Quarto — e questo è quello che le raccolte di prompt sbagliano nell’altra direzione — l’accesso al repository non rende la strategia di contenuto gratuita. Un agente che scrive articoli senza prove SERP produce ipotesi fiduciose e ben formattate. Il loop di scrittura ha la sua disciplina — una smantellamento di ciò che già si posiziona, un outline che lo batte, gate di scoring prima che qualcosa sia spedito — che il pilastro Claude per SEO mappa attraverso il cluster. La stessa avvertenza vale per i siti che non sono repository a tutti: un CMS ospitato senza accesso al sorgente ricade su strumenti basati su crawl e integrazioni API, che funzionano, ma rinunciate alla leva a livello di template che rende il percorso del repository così efficiente.

Come configurarlo

La configurazione di lavoro è quattro step, e nessuno di loro è esotico. Installate Claude Code. Aprite un terminale nel repository del vostro sito web — lo stesso in cui lavorano i vostri sviluppatori. Connettete un server MCP che espone i vostri dati di Search Console e una bacheca di task (un comando, poi autenticate). Poi chiedetegli di lavorare sulla bacheca: find, edit, PR, e lasciate che il monitor legga i verdetti. Da quel momento il vincolo non è più quanto velocemente i finding possono essere spediti — è quanto bene sono i finding, dove l’accesso dell’agente ai dati di query reali si compone di ciclo su ciclo.

Se volete vedere il lato find eseguito prima contro la vostra proprietà, il report SEO gratuito connette il vostro Search Console e presenta le query dove spedire una modifica di file muoverebbe effettivamente un numero — ranking della prima pagina che non guadagnano nulla, pagine mostrate e mai scelte. E se preferite che l’intero loop girasse per voi — agente, bacheca, PR e i verdetti di tre settimane — prenotate una chiamata e lo esamineremo sui vostri dati.