Claude per l'SEO Tecnico: Audita il Repo, Non la Scansione

Cercate consigli su come usare Claude per l'SEO tecnico e troverete una variante dello stesso approccio: esportate una scansione, incollate le righe peggiori in una finestra di chat e chiedete a Claude cosa fare al riguardo. Quel flusso di lavoro tratta Claude come un luogo più intelligente per leggere un report del crawler — e spreca quasi tutto ciò per cui il modello è effettivamente bravo. L'SEO tecnico su un sito moderno non è un problema di pagina renderizzata che casualmente ha del codice dietro. È codice: regole robots, generazione sitemap, logica canonical, metadati, redirect e structured data sono tutti file sorgente. Il posto giusto per mettere Claude non è dal lato dell'esportazione di un crawler. È dentro il repository, dove può leggere i file che causano i sintomi che il crawler fotografa — e poi correggerli nella stessa sessione, come pull request che un umano esamina.

Questa guida è il capitolo tecnico-SEO del nostro pilastro Claude for SEO. Copre cosa Claude può determinare sulla vostra SEO tecnica staticamente — prima che venga eseguita qualsiasi scansione — la checklist concreta file per file, come gli aggiornamenti si spediscono come PR, e la parte che quasi ogni flusso di lavoro AI-SEO salta: verificare ogni aggiornamento in Search Console circa tre settimane dopo, cosicché “Claude l'ha corretto” diventi un'affermazione misurata invece che una speranzosa. Una divulgazione onesta in anticipo: la query che questo articolo prende di mira registra essenzialmente nessun volume di ricerca per ora. La pratica è in anticipo sulla domanda. Di solito è il momento migliore per scrivere la guida.

Il crawler ha trovato il sintomo. Il repo contiene la causa

Un crawler lavora da fuori verso dentro. Recupera pagine renderizzate, campiona quello che può raggiungere, e riporta sintomi: due canonical in conflitto qui, una catena di redirect lì, un gruppo di pagine mancanti dalla sitemap. Ogni uno di questi sintomi ha una causa, e su un sito costruito con un framework la causa quasi mai si trova sulla pagina — si trova in un template, un file di configurazione, o un ramo di middleware. Il crawler può dirvi che cento pagine portano il canonical sbagliato. Non può dirvi che tutte cento sono renderizzate da un file layout con una linea sbagliata, perché non ha mai visto il file layout.

Claude che corre dentro il repo inizia dalla causa. Legge il template e sa — senza recuperare un singolo URL — che ogni pagina che il template renderizza eredita il bug. Questo capovolgimento cambia gli economici dell'audit due volte. Coverage: un crawler campiona, ma una lettura di file è esaustiva, perché una funzione generateMetadata è i metadati di ogni route che la usa. Velocità: il primo passaggio di un audit tecnico su un sito Next.js è leggere forse dieci file, il che a Claude prende secondi, non le ore che richiede una scansione completa su un sito grande.

Su un sito che abbiamo auditato, la route sitemap mappava una collezione di contenuti che era stata ristrutturata mesi prima. La sitemap compilata, deployata, e ritornata un 200 valido — aveva semplicemente smesso di includere tutte le pagine di un intero template. Un crawler non vide niente di sbagliato, perché ogni pagina che raggiungeva andava bene; le mancanti erano esattamente quelle per cui non aveva un percorso. Leggere app/sitemap.ts rispetto all'albero delle route effettive ha rivelato il divario in un passaggio. È la categoria di bug per cui l'auditing repo-first esiste: invisibile dall'esterno, una lettura di file dall'interno.

Un crawler riporta che cento pagine portano il canonical sbagliato. Il repo vi mostra la linea, in un template, da cui tutti cento lo ereditano — e Claude può leggere quella linea, correggerla, e aprire il PR nella stessa sessione.

Cosa Claude può leggere che un crawler non può

Su un sito Next.js — e ogni framework serio ha equivalenti — la superficie dell'SEO tecnico si concentra in una lista breve di file. Questa è la mappa da cui Claude lavora, e ogni file ha una classe di fallimento caratteristica che è completamente visibile nel sorgente e largamente invisibile in una scansione.

Notate cosa unisce le righe enfatizzate: sono bug che passano ogni build, deployano senza errore, e producono nessun difetto visibile su nessuna pagina individuale. Esistono solo come una relazione tra file — sitemap rispetto all\'albero delle route, canonical rispetto all\'origine — che è precisamente il tipo di ragionamento cross-file per cui un modello linguistico con accesso al repository è costruito, e un crawler pagina-per-pagina non è.

La checklist repo-first, file per file

Ecco il passaggio concreto, nell\'ordine in cui Claude dovrebbe eseguirlo — ogni controllo accoppiato alla condizione di passaggio e alla metrica di Search Console che verifica l\'aggiornamento. La metrica si fissa quando il finding è archiviato, non dopo che l\'aggiornamento è spedito; quella disciplina, e perché la versione più profonda a cinque livelli di questo audit è strutturata nel modo in cui è, sono coperte nella guida sorella su audit dell\'SEO tecnico.

Due abitudini rendono questa checklist funzionare nella pratica. Primo, Claude dovrebbe leggere i file come un sistema, non una lista — il controllo del redirect significa qualcosa solo quando i redirect di next.config e le riscritture di middleware sono composti insieme, e il controllo del canonical significa qualcosa solo rispetto all\'origine live. Secondo, ogni finding dovrebbe essere archiviato prima che qualcosa sia corretto, con il suo impatto atteso e la metrica di verifica allegata, così l\'audit produce una coda responsabile piuttosto che un pomeriggio eroico di edit non registrati.

Gli aggiornamenti si spediscono come pull request, non ticket

Questo è dove il frame repo-first smette di essere un\'ottimizzazione dell\'audit e diventa un modello operativo diverso. Nel flusso di lavoro crawler-e-chat, un finding diventa un ticket, il ticket aspetta uno sviluppatore, lo sviluppatore ri-deriva il contesto che lo strumento aveva già, e l\'aggiornamento arriva settimane dopo — se arriva. Quando Claude è già nel repo, l\'entità che ha trovato il metadataBase mancante è l\'entità che modifica il file. La distanza tra diagnosi e aggiornamento crolla da uno sprint a un diff.

Il punto di controllo non scompare — si sposta a dove i team di software hanno già uno: la pull request. Claude apre una PR con il finding, le evidenze e il cambiamento; un umano esamina e merge. Niente arriva silenziosamente. Questo conta di più nell\'SEO tecnico che quasi ovunque, perché gli stessi file che correggono l\'indicizzazione possono distruggerla — una regola robots sbagliata o un redirect sbagliato è un incidente di sito intero, e una fix canonical di una linea e una catastrofe canonical di una linea si assomigliano quasi identicamente in un diff. La PR è il gate di revisione umana, e produce qualcosa che i ticket non fanno mai: un record con timestamp, revisionabile di esattamente cosa è cambiato, che il passaggio di verifica sta per aver bisogno.

Non fatto finché Search Console non lo dice

Una PR merged è ancora solo un'affermazione. La fix robots dovrebbe ripristinare le impressioni sulla sezione bloccata; il consolidamento canonical dovrebbe aumentare la posizione sull\'URL sopravvissuto. Se l\'ha fatto è un fatto che non esiste finché Google non si ricrawla, non rielabora, e non accumula abbastanza dati di query freschi per confrontare — nella pratica, circa tre settimane. La maggior parte dei flussi di lavoro AI-assistiti di SEO termina al merge e lasciano l\'affermazione stare per sempre. Questo è il lavoro a metà che questo intero metodo esiste per evitare.

La forma di lavoro è una task board che chiude il loop. Ogni finding di checklist arriva come task che porta la sua metrica di verifica e target; la PR merged fa girare il task a fatto con l\'URL di PR allegato; e un monitor settimanale ri-legge Search Console su qualsiasi cosa oltre la sua data di verifica e scrive il verdetto — confermato, regredito, o inconcluso. Claude fa la lettura e la fix; la board fa il ricordare; Search Console fa il giudizio. La meccanica di quel loop — e perché tre settimane è la fisica della fonte di dati piuttosto che una scelta di prodotto — è il soggetto della guida sorella su SEO closed-loop.

Eseguite questo per un trimestre e il sottoprodotto diventa l\'asset: un record per-sito di quali fix tecnici effettivamente verificano. I consolidamenti canonical che confermano affidabilmente, il lavoro di rendering che legge inconcluso due volte di fila — il prossimo passaggio di audit inizia da quel storico misurato invece di una scala di gravità generica, che è come il loop diventa più intelligente su un sito invece di auditarlo da zero per sempre.

Cosa Claude non può vedere dal repo

Repo-first è una grande quota dell\'SEO tecnico. Non è tutto, e fingere altrimenti romperebbe la regola di onestà del metodo stesso. Tre punti ciechi rimangono fuori dall\'albero sorgente non importa quanto bravo sia il modello.

Cosa Google ha effettivamente fatto. Il repo mostra l\'intento; solo Search Console mostra il risultato — cosa è stata indicizzata, cosa viene mostrata, cosa guadagna clic. L\'audit legge GSC durante come il record della realtà, non solo al momento della verifica. Cosa gli utenti reali sperimentano. I Core Web Vitals sono giudicati sui dati di campo al 75° percentile delle visite reali. Claude può individuare l\'immagine non dimensionata e lo script bloccante nel sorgente, ma il verdetto viene da misurazione di campo, e i punteggi di lab fanno più bella ogni sito. Cosa si trova fuori dal repo. Le regole CDN, la configurazione edge, un reverse proxy che qualcuno ha impostato nel 2021 — se non è nell\'albero sorgente, una lettura di sorgente non può trovarlo, e una scansione confermante del sito live rimane il controllo incrociato onesto che cosa il codice intende è cosa il server serve.

Come eseguire questo sul vostro sito

La configurazione è deliberatamente noioso. Claude Code corre nel vostro repository del sito — lo stesso luogo dove i vostri sviluppatori già lavorano — e si connette su MCP ai dati che non può sapere dal sorgente: la performance di Search Console, la task board condivisa, e il fallback di scansione. La guida di connessione copre l\'installazione di un comando. Da lì, il loop sopra è il manuale operativo: leggi i dieci file, archivia i finding con le loro metriche di verifica, spedisci gli aggiornamenti selezionati come PR, e lascia che il monitor settimanale scriva i verdetti.

Se volete vedere la metà di ricerca eseguire prima sulle vostre stesse dati, il report SEO gratuito connette la vostra Search Console e rivela dove lo strato tecnico vi sta già costando — le sezioni mostrate ma mai scelte, gli URL che competono con se stessi. E se preferireste che l\'intero loop correisse come servizio — finding archiviati, PR aperti, verdetti letti — prenotate una call e cammineremo attraverso come si presenta sul vostro repository.