Il tuo workflow SEO è troppo furbo per il proprio bene: una Q&A per agenzie

Riepilogo

La maggior parte delle agenzie non perde le vittorie SEO per mancanza di competenza; le perde perché ogni cliente diventa un progetto scientifico su misura. La soluzione è un workflow deliberatamente noioso e ripetibile: lo stesso scheletro di audit, lo stesso ordine di operazioni e la stessa struttura di reporting per ogni cliente. Questa guida in stile Q&A affronta le decisioni pratiche — da dove iniziare, come stabilire le priorità, cosa riportare, cosa automatizzare e come resistere alle tattiche appariscenti. Copre le fondamenta come robots.txt, sitemap XML e tag canonici, poi passa all'intento dell'utente, ai Core Web Vitals e ai dati strutturati. Imparerai perché più schema non è sempre meglio e perché un processo fisso in realtà fa emergere le esigenze uniche di ogni cliente. L'obiettivo è rendere il tuo lavoro SEO abbastanza ripetibile da sopravvivere al decimo cliente.

Il tuo asset SEO più prezioso non è una nuova tecnica intelligente. È un processo deliberatamente noioso e ripetibile che ti obbliga a fare le stesse fondamenta nello stesso ordine per ogni cliente. Ho visto team di agenzie affrontare ogni nuovo incarico come un progetto scientifico unico. Il cliente chiede: “Cosa dovremmo fare per primo?” e tu improvvisi una lista di priorità su misura. Discuti se sistemare prima la homepage o le pagine di categoria. Passi un'ora a spiegare perché la situazione di questo cliente è diversa. E sei mesi dopo, quando qualcuno chiede perché hai scelto quelle priorità, nessuno se lo ricorda. La soluzione non è una conoscenza SEO più sofisticata. È un workflow così coerente da sembrare noioso — e proprio quella noiosità è ciò che gli permette di sopravvivere al contatto con un decimo cliente.

Questo articolo è una Q&A su quel workflow, scritto per chi deve rendere il lavoro SEO e le performance ripetibili per un'agenzia, non solo per un singolo progetto. Le domande sono quelle che i team fanno davvero quando si rendono conto di stare annegando nella complessità specifica del cliente. Le risposte sono deliberatamente noiose. È proprio questo il punto.

Perché il mio processo SEO continua a crollare tra un cliente e l'altro?

Perché tratti ogni incarico come un problema da zero. Il cliente A ha un blog di dieci anni con contenuti duplicati e una sitemap che non viene aggiornata dall'anno scorso. Il cliente B ha un sito nuovo con una scansione pulita ma nessun link interno tra pagine correlate. Il cliente C ha un sito veloce che non si posiziona perché nessuno ha scritto per ciò che le persone cercano realmente. Ognuno sembra richiedere una strategia unica — e ognuno riceve una strategia unica e improvvisata.

Funziona finché non hai più di due o tre clienti. Poi il tuo stesso processo diventa il collo di bottiglia. Non ricordi perché hai dato priorità a una cosa per il Cliente A e perdi una settimana a ri-insegnarti il contesto. L'azione pratica è definire un ordine fisso di operazioni prima ancora di guardare il sito di un cliente: scansione, confronto con una baseline, correzione di crawlability e indicizzazione, correzione della velocità, correzione dei contenuti, misurazione, reporting. Usa lo stesso scheletro ogni volta e discostati solo quando qualcosa di specifico blocca un passaggio.

La ricerca su questo è quasi noiosa nella sua coerenza. Le stesse linee guida di Google indirizzano ancora i team attraverso le fondamenta come crawlability e indicizzazione prima di qualsiasi altra cosa. Le definizioni di SEO tecnico in tutto il settore elencano gli stessi compiti fondamentali — robots.txt, sitemap XML, tag canonici — come punto di partenza. Quando la lista di tutti è uguale, ciò che ti distingue non è la lista. È se esegui nello stesso ordine senza drammi.

Quindi smetti di improvvisare. Metti per iscritto lo scheletro. Trasformalo in un modello. Quando un cliente chiede: “Dovremmo fare qualcosa di diverso perché siamo un sito e-commerce?” la risposta di solito è: “No. Devi comunque essere scansionabile, indicizzabile, veloce e pertinente. Cominciamo da lì.” Le preoccupazioni specifiche dell'e-commerce — navigazione a faccette, varianti di prodotto, paginazione — vengono dopo, una volta che le fondamenta sono solide. Un modello non ti impedisce di affrontarle; ti impedisce solo di saltare le cose noiose per arrivarci.

Da dove comincio quando ogni cliente ha un disastro diverso?

Inizia con i tre file e tag che determinano se qualsiasi altra cosa fai ha importanza: robots.txt, sitemap XML e tag canonici. Non perché siano glamour — sono la parte meno glamour della SEO — ma perché i motori di ricerca hanno bisogno di una via di accesso affidabile. Se il robots.txt di un cliente blocca accidentalmente l'intero sito, o un tag canonico punta ogni pagina alla homepage, nessuna quantità di lavoro sui contenuti o ottimizzazione della velocità si vedrà nei ranking.

Un modello comune: un cliente passa settimane a riscrivere il testo della homepage, poi scopre che una direttiva noindex rimasta da un server di staging era ancora attiva in produzione. Sistemare quel singolo tag può fare di più per la visibilità di ogni parola riscritta nello stesso periodo. Un altro modello: la sitemap elenca 4.000 URL quando il sito ha in realtà 200 pagine di contenuto. I motori di ricerca vedono ora un sito tentacolare, per lo più vuoto, e il budget di scansione viene speso per pagine che non c'entrano. Pulire quella sitemap ti insegna più sul sito del cliente di qualsiasi sessione di ricerca di parole chiave.

Un terzo modello appare quando il CMS di un cliente ha subito alcuni restyling: i vecchi tag canonici puntano a pagine di categoria rinominati, quindi il motore di ricerca riceve segnali contrastanti su quale URL rappresenti la pagina “vera”. Non è un problema sottile. È l'equivalente di inviare un pacco importante a due indirizzi diversi sperando che uno arrivi. Devi risolvere il conflitto canonico prima di poterti fidare di qualsiasi altra cosa misuri.

L'azione pratica: esegui un audit rapido di questi tre elementi prima di guardare qualsiasi altra cosa. Non hai bisogno di una metodologia su misura per ogni cliente; hai bisogno di un audit SEO tecnico che inizi sempre con gli stessi controlli di salute a livello di scansione. Se il tuo audit è ripetibile, allora “da dove comincio” diventa una non-domanda. Inizi lì, per ogni cliente, senza discuterne.

Questo ti aiuta anche a definire l'ambito dell'incarico. Quando un cliente ti chiede un preventivo per la “SEO”, la prima cosa che puoi dire è “inizieremo con un controllo di salute tecnico che copre robots.txt, sitemap e tag canonici, poi passeremo a contenuti e performance.” Questa frase funziona per un dentista, un'azienda di software e un fornitore di logistica. Non importa cosa vende il cliente; la via di accesso al sito è la stessa.

Come decido quale correzione conta di più in questo trimestre?

Questa è la domanda che mette in difficoltà la maggior parte dei team di agenzia, perché la risposta sembra dover essere su misura. Ma se hai eseguito correttamente il primo passo — garantire crawlability e indicizzazione — la decisione successiva non riguarda il settore del cliente. Riguarda in quale fase del funnel il loro sito sta fallendo.

La tabella qui sotto è la regola pratica che ho trovato più utile:

Quando il sito del cliente è...	La priorità ripetibile è...	Perché funziona
Non appare affatto nei risultati di ricerca	Salute della scansione e indicizzazione	Nient'altro conta se le pagine non sono nell'indice
Appare ma non si posiziona	Rilevanza on-page e intento dell'utente	I motori di ricerca premiano le pagine che rispondono alla query
Si posiziona ma le posizioni stanno scivolando	Core Web Vitals e velocità della pagina	Google ha confermato la velocità come fattore di ranking; LCP, INP e CLS sono i segnali di esperienza misurabili
Si posiziona ma non genera click	Dati strutturati e meta description	Etichette accurate nei risultati di ricerca, inclusi i rich result, possono aumentare la visibilità prima che un utente faccia clic

L'avvertenza è che i clienti attraversano queste fasi in cicli. Un sito può essere non indicizzato, lento e irrilevante tutto in una volta. Ma il punto di un processo ripetibile è che non rimetti in discussione l'ordine ogni volta. Hai un default: prima la scansione, poi l'indicizzazione, poi l'intento dei contenuti, poi la velocità, poi lo schema. Se hai un motivo particolare per saltare avanti, va bene — ma ci devono essere prove.

Considera un cliente che si posiziona quarto per la sua parola chiave principale ma sta scivolando da due mesi. La pagina è scansionabile, indicizzata e in linea con il messaggio. La leva più probabile è l'esperienza — velocità della pagina e Core Web Vitals. Se la homepage è pesante di immagini non ottimizzate, la pagina potrebbe perdere posizione perché il sistema di ranking di Google pesa l'esperienza utente più di quanto facesse in passato. L'azione ripetibile è eseguire una valutazione dei Core Web Vitals prima che il cliente inizi a riscrivere contenuti già pertinenti.

Ora pensa a un cliente le cui pagine sono indicizzate ma la percentuale di click-through è terribile. Si posizionano in prima pagina ma nessuno clicca. In quel caso, i dati strutturati — in particolare quelli che generano rich result come prezzo del prodotto, valutazione o FAQ — possono fare un uso fondamentalmente migliore dei pixel che Google ti dà. È un compito diverso dal migliorare i tempi di caricamento e merita un proprio passaggio nel workflow.

Questo framework risolve anche il dibattito tra lavoro “tecnico” e “contenuti”. Non sono in competizione. Sono fasi sequenziali dello stesso workflow. E poiché le fasi sono fisse, puoi dedicare la tua energia alla prioritizzazione del lavoro SEO e delle performance nelle poche decisioni che variano davvero — come se sistemare il pasticcio di hreflang o prima le pagine di categoria duplicate — invece di ridecidere l'intera roadmap.

Cosa dovrei effettivamente inserire in un report per il cliente?

Il report per il cliente è dove i processi noiosi si rompono. Passi ore a fare lavoro vero — sistemare robots.txt, pulire la sitemap, risolvere conflitti canonici — e poi lo riversi in un PDF di 40 pagine con ogni errore di scansione trovato. Il cliente lo sfoglia, si innervosisce, e la riunione successiva si spende a spiegare perché il tuo report non è una lista di cose da fare.

L'azione pratica: riporta le prove, non lo sforzo. Usa una pagina con quattro quadranti: salute della scansione, indicizzazione, segnali di velocità e gap di contenuti. Per ciascuno, mostra cosa è cambiato, cosa no e cosa farai dopo. Se una metrica si è mossa nella giusta direzione, dillo in linguaggio semplice. Se non lo ha fatto, di' che ci stai ancora lavorando. Includi poi una breve lista separata delle prime tre correzioni per il mese successivo.

Micro-esempio: invece di elencare 400 errori di scansione nel corpo del report, etichettali come “ignorabili — vecchi PDF” o “richiede azione — link interni rotti verso pagine live.” Il cliente non ha bisogno del foglio di calcolo completo; deve sapere quali errori contano e quali sono rumore di fondo. La stessa logica vale per i Core Web Vitals. Dire “LCP ora è nel range raccomandato” è più utile che presentare un grafico di ogni metrica. Ancora meglio, collega il risultato di business: “il tempo di caricamento della homepage è migliorato, in linea con il fattore di ranking confermato da Google per la velocità.”

Un secondo micro-esempio viene da un errore comune delle agenzie: inserire “crescita delle pagine indicizzate” nel report mentre la pagina prodotto principale del cliente non è ancora indicizzabile. Il report dovrebbe essere sempre organizzato attorno agli obiettivi di business del cliente, non attorno alle metriche che ti capita di aver raccolto. Se l'obiettivo del cliente è vendere più widget, allora “la pagina /widgets ora è indicizzabile” è una riga significativa. “Abbiamo visto 12 nuove pagine nella sitemap” non lo è.

Evita di riportare metriche che non puoi modificare. Se la tua agenzia non controlla il server, riportare i tempi di risposta del server ogni mese crea una discussione senza una decisione. Il tuo report dovrebbe sempre terminare con una chiara “prossima azione” sia per te che per il cliente — non un punteggio.

Quanto di questo dovrei automatizzare?

Automatizza la raccolta, non il giudizio. I report di scansione, i controlli di uptime e il monitoraggio dei Core Web Vitals possono essere eseguiti su un programma. È un enorme risparmio di tempo, soprattutto quando gestisci più siti clienti. L'automazione dovrebbe alimentare il tuo processo fisso, non sostituirlo.

Ma un report automatizzato che riversa 400 errori di scansione in un foglio di calcolo non aiuta nessuno. Il giudizio — quali errori richiedono un umano, quali sono rumore e quali devono essere escalation — è dove vive la tua competenza. Se automatizzi la raccolta e applichi le stesse regole di triage settimana dopo settimana, puoi gestire qualsiasi cliente in un'ora.

Per il contesto specifico dell'agenzia, l'automazione è più preziosa quando produce un report di eccezioni. Configura una scansione programmata che ti invii email solo quando qualcosa si rompe: un nuovo noindex su una pagina di denaro, una sitemap che ha smesso di risolversi, un picco di 404. In questo modo non stai riesaminando un'istantanea statica ogni settimana; stai aspettando che qualcuno faccia scattare un allarme. La parte noiosa e ripetibile è l'allarme. La parte che richiede ancora un umano è decidere se coinvolgere il cliente nella conversazione o sistemare in silenzio.

Uno strumento di scrittura AI generico o un generatore di pagine all-in-one potrebbero essere allettanti per produrre contenuti su larga scala, ma la stessa regola vale: usali dove eliminano il lavoro ripetitivo e mantieni umana la priorità. L'obiettivo non è eliminare le parti noiose. È rendere le parti noiose più veloci in modo da avere più tempo per le parti che richiedono davvero ragionamento — come decidere se affrontare prima la revisione della tassonomia o le pagine orfane.

Un processo fisso non mi farà perdere ciò che è unico in ogni cliente?

È una preoccupazione legittima. Se usi lo stesso scheletro per un idraulico locale e un'azienda SaaS globale, non stai ignorando le differenze evidenti? La risposta è no, perché lo scheletro non è la strategia. È la rete di sicurezza.

Un processo fisso significa che non perdi il tag noindex sulla pagina contatti dell'idraulico perché eri troppo occupato a pensare alle parole chiave locali. Significa che non dimentichi di controllare se i post del blog dell'azienda SaaS sono collegati internamente alle loro pagine prodotto perché eri concentrato sullo schema. Le parti uniche di ogni cliente — il loro mercato, i loro concorrenti, i loro gap di contenuti — vengono a fuoco solo dopo aver eliminato il rumore di base.

Le cose speciali di solito appaiono nella fase dei contenuti, non in quella della scansione. Quando mappi l'intento dell'utente sulle pagine esistenti del cliente, trovi i gap che contano per quel specifico business. Il gap di un idraulico potrebbe essere “nessuna pagina sulle aree di servizio locali.” Il gap di un'azienda SaaS potrebbe essere “nessun contenuto relativo ai prezzi per le query di confronto.” Il processo fa emergere questi gap perché ti obbliga a guardare ogni pagina come risposta a una domanda, piuttosto che come una proprietà da ottimizzare.

Quindi il processo non ti acceca di fronte all'unicità. In realtà la amplifica. Passi meno tempo in indagini tecniche improvvisate e più nel giudizio strategico per cui i clienti pagano.

Non è sempre meglio avere più dati strutturati?

No. Questo è un buon punto per fermarsi in modo controcorrente. I dati strutturati sono diventati una parola d'ordine per le agenzie perché promettono rich result e migliore visibilità. Ma applicare schema a ogni pagina non è una best practice ripetibile — è un modo per creare un insieme rumoroso di dichiarazioni che i motori di ricerca potrebbero ignorare.

La domanda corretta non è “possiamo aggiungere dati strutturati?” ma “questa pagina rappresenta qualcosa che i motori di ricerca possono riassumere come rich result?” Una pagina prodotto può legittimamente marcare prezzo e disponibilità. Una pagina contatti con un indirizzo fisico può usare LocalBusiness. Un post di blog su un argomento di solito non ha bisogno di più di un markup Article — e spesso nemmeno quello. Aggiungere FAQ schema a una pagina che non contiene una vera FAQ è più probabile che venga ignorato o contato come abuso di markup piuttosto che ottenere un rich result.

La ricerca è coerente qui: i dati strutturati sono codice che aiuta i motori di ricerca a comprendere i contenuti in modo più efficace e può portare a risultati più ricchi, soprattutto con la crescita della ricerca guidata dall'IA. Ma funziona solo quando descrive accuratamente ciò che è sulla pagina. Il tuo workflow ripetibile dovrebbe includere un passaggio che dice: “Per ogni tipo di pagina, chiediti se esiste un rich result e se la pagina ne soddisfa veramente i requisiti.” Questa è una regola molto più utile di “aggiungi schema a tutto.”

Considera un cliente con un negozio online. La tentazione ovvia è aggiungere Organizational schema a ogni pagina perché “riguarda l'azienda.” Ma le pagine che ne beneficeranno davvero sono le pagine prodotto, dove Product schema può mostrare prezzo e disponibilità. Aggiungere lo stesso markup alla homepage, alla pagina contatti e a ogni post del blog non aiuta; rende solo il markup più difficile da controllare. L'azione ripetibile è mappare i tipi di schema ai modelli di pagina, non alle singole pagine.

Per una checklist di implementazione più approfondita, vedi questa guida all'implementazione dei dati strutturati. Ti dà un modo ripetibile per decidere pagina per pagina piuttosto che modello per modello.

Qual è il vero collo di bottiglia nella SEO moderna?

Il vero collo di bottiglia non è tecnico. È pertinenza e fiducia. Le tendenze moderne della SEO enfatizzano l'intento dell'utente rispetto al keyword stuffing, e i motori di ricerca premiano sempre di più i contenuti pertinenti, autorevoli e affidabili (E-E-A-T). Puoi risolvere ogni problema tecnico su un sito e perdere comunque perché i contenuti non corrispondono a ciò che gli utenti cercano.

Un micro-esempio comune: un cliente vuole posizionarsi per “miglior CRM per piccole imprese,” ma i risultati di ricerca sono dominati da guide di confronto, non da pagine prodotto. Se ottimizzi la pagina prodotto con title tag perfetti e schema, non si posizionerà comunque, perché l'intento dietro quella query è di ricerca, non di acquisto. L'azione ripetibile è mappare ogni parola chiave target al suo effettivo intento di ricerca prima di scrivere un brief. Se l'intento è informativo, ti serve una guida. Se è transazionale, ti serve una pagina prodotto.

Questo è anche dove entra in gioco l'E-E-A-T, ed è la cosa più difficile da sistematizzare. Non puoi fingere l'autorità con un server più veloce o un blocco di schema. Viene dalla qualità dei contenuti, dall'esperienza dell'autore e da segnali esterni come backlink e menzioni. Il tuo workflow dovrebbe includere un passaggio per valutare se i contenuti del cliente hanno la sostanza per meritarsi un ranking — non solo la prontezza tecnica per essere scansionati.

In pratica, questo significa che il tuo processo ripetibile dovrebbe includere un audit dei contenuti che guardi ogni pagina come risposta a una domanda: Questa pagina esiste? Risponde alla query meglio dei primi dieci risultati attuali? Il cliente ha l'autorità (firme, citazioni, dati originali) per sostenere le affermazioni? Se no, il lavoro tecnico è sprecato. L'analisi dei gap di contenuti è dove troverai le vincite più grandi per la maggior parte dei clienti, ed è spesso il passaggio che le agenzie saltano quando sono bloccate nell'inferno degli errori di scansione.

Cosa dico quando un cliente chiede qualcosa di trendy?

Un cliente legge di contenuti generati dall'IA o dell'ultima funzionalità di schema e li vuole subito. Il tuo processo è la tua difesa. La risposta non è “no, è male.” La risposta è “ecco dove si inserisce nella nostra sequenza.”

Se un cliente chiede di generare 200 post di blog con l'IA, la risposta misurata è chiedere quale intento dell'utente servirebbero quei post, chi li scriverebbe con abbastanza competenza per stabilire l'E-E-A-T, e se il sito è attualmente abbastanza veloce da erogarli bene. Di solito il vero collo di bottiglia è qualcos'altro.

Se un cliente chiede un restyling del sito perché “il sito sembra vecchio,” il processo dice: il sito attuale è scansionabile e indicizzabile? Un restyling che rompe robots.txt o rimuove i tag canonici annullerà mesi di lavoro. Meglio sistemare prima le fondamenta tecniche, poi restyling con una checklist di migrazione.

L'azione ripetibile è tenere una lista “parcheggio.” Quando un cliente propone qualcosa di trendy, aggiungilo alla lista e di' che verrà considerato nella prossima revisione trimestrale, dopo che le priorità attuali saranno completate. Questo non respinge l'idea; le dà un posto formale nel workflow. E impedisce che la tendenza dirotti il tempo del tuo team prima che il lavoro noioso sia fatto.

Questo può sembrare una soft skill piuttosto che una competenza SEO, ma è la colla che tiene intatto il processo. Senza, ogni cliente ti tirerà in una direzione diversa, e il tuo processo ripetibile crollerà sotto il peso delle eccezioni.

Allora come appare in pratica il processo noioso?

Ecco tutto, condensato:

1. Lo stesso scheletro di audit, per ogni cliente. Inizia con robots.txt, sitemap XML e tag canonici. Poi la salute della scansione. Poi l'indicizzazione.
2. Un ordine di operazioni ripetuto. Scansione, indicizzazione, intento dei contenuti, velocità, dati strutturati, report.
3. Una regola di triage per gli errori. No, non sistemo ogni 404. Sistemo quelli che bloccano la navigazione principale o puntano a pagine di alto valore.
4. Un report cliente di una pagina. Prove, non sforzo. Tre correzioni principali per il mese prossimo.
5. Un ritmo di revisione mensile. Non quotidiano. Non trimestrale. Il mensile dà abbastanza tempo perché i cambiamenti si riflettano nel comportamento dei motori di ricerca.

L'ultimo passo è dove molte agenzie deviano. Implementano le correzioni, poi controllano i ranking ogni settimana e vanno nel panico. Ma i motori di ricerca hanno bisogno di tempo per riscansionare, reindicizzare e rivalutare le pagine. Una revisione mensile dà al tuo processo un naturale spazio di respiro. Fai cambiamenti, li lasci maturare, poi misuri e aggiusti.

Un mese è anche un tempo sufficiente per accumulare dati significativi. Se controlli settimanalmente, vedrai rumore. Se controlli trimestralmente, ti perderai problemi. Il mensile è il punto dolce per un processo che deve funzionare su più clienti senza consumare il tuo team.

Se fai sul serio, il prossimo passo è costruire un modello di baseline per velocità e performance che riusi su ogni cliente. La guida ai Core Web Vitals è un buon punto di partenza. Esamina le stesse tre metriche — LCP, INP, CLS — come un set fisso di controlli, piuttosto che un'indagine nuova ogni volta.

Conclusione

Il valore che aggiungi come agenzia non è inventare una nuova religione SEO per ogni cliente. È portare un processo prevedibile e ripetibile che cattura le stesse mine nello stesso ordine, ogni volta. Il cliente con il tag noindex rimasto e il cliente con la sitemap gonfia ricevono entrambi lo stesso primo passaggio. Il cliente con un gap di contenuti riceve lo stesso esercizio di mappatura dell'intento. Il cliente con un sito lento riceve gli stessi controlli sui Core Web Vitals.

È quella ripetibilità che ti permette di scalare. È ciò che permette a un membro del team junior di prendere in mano un cliente e sapere esattamente cosa fare. Ed è ciò che ti permette di dire “no” a una nuova tattica appariscente che non si adatta al processo, senza sentirti come se ti stessi perdendo qualcosa. La cosa più sofisticata che puoi fare per i tuoi clienti è essere noioso di proposito — e fare le fondamenta nello stesso ordine, ogni singola volta.

Quando un cliente chiede se dovresti passare direttamente a un restyling o a un aggiornamento dei contenuti, puoi rispondere con sicurezza perché sai esattamente dove si inserisce nella sequenza. Il processo ti dà un modo basato su principi per rimandare il lavoro che non è ancora giustificato. E quando il cliente spinge per qualcosa di trendy, puoi indicare le prove: il sito non è ancora completamente indicizzabile, quindi un nuovo page builder non risolverà nulla. La risposta noiosa è spesso quella giusta.