Il consulente SEO chiede una modifica al sito. Lo sviluppatore risponde che, per realizzarla, deve intervenire sul modello usato da decine di pagine. Il responsabile marketing pensava che fosse una correzione semplice. Il titolare scopre il costo quando il lavoro è già entrato nel calendario.
In una situazione del genere le persone possono essere tutte competenti e il progetto può comunque fermarsi. Ognuno sta rispondendo a una domanda diversa. Il consulente guarda il problema di visibilità. Lo sviluppatore guarda il codice, le dipendenze e il rischio di creare effetti indesiderati. L’azienda guarda priorità, budget e conseguenze commerciali.
Prima di un intervento congiunto serve quindi un accordo operativo: chi formula la richiesta, chi ne verifica la fattibilità, chi autorizza costi e rilascio, chi esegue il lavoro e con quale prova l’azienda lo considererà concluso. Questo accordo può stare in una scheda o in un ticket ben scritto. Il formato conta meno delle decisioni che rende visibili.
La responsabilità utile segue le fasi del lavoro. La stessa persona può coprirne più di una, se l’incarico e le competenze lo permettono. Ciò che deve sparire è il passaggio implicito in cui tutti pensano che deciderà qualcun altro.
“Consulente SEO” e “sviluppatore” descrivono competenze, non l’intero incarico
La SEO comprende decisioni sui contenuti, sulla struttura e su aspetti tecnici del sito. Lo sviluppo comprende la realizzazione e la manutenzione della tecnologia con cui quel sito funziona. Le due aree si incontrano spesso, però il confine concreto dipende da ciò che è stato concordato.
Google, nella sua guida alla scelta di un professionista SEO, elenca tra i servizi possibili la revisione dei contenuti o della struttura e i consigli tecnici sullo sviluppo. Nella stessa guida invita a chiedere come verranno comunicate le modifiche e spiegate le raccomandazioni. È un’indicazione utile per il cliente: la parola “SEO” può comprendere attività diverse e il titolo professionale, da solo, non assegna ogni passaggio.
Un consulente può preparare le specifiche e affidare la realizzazione allo sviluppatore. Può anche intervenire direttamente su alcune attività, se possiede accessi e competenze e se l’incarico lo prevede. Lo sviluppatore può proporre una soluzione tecnica migliore di quella immaginata inizialmente. L’azienda deve comunque conservare le decisioni che riguardano priorità, costi, vincoli e pubblicazione.
Nel mio lavoro posso eseguire l’attività SEO oppure strutturarla per chi sviluppa il sito. La ripartizione va confermata in ogni incarico, perché cambia con la tecnologia, con le persone disponibili e con il rischio dell’intervento.
Un intervento attraversa quattro decisioni diverse
Per capire chi decide che cosa conviene seguire il lavoro nel suo ordine reale. Un’attività condivisa attraversa almeno quattro decisioni.
1. L’azienda decide se il problema merita risorse
Il consulente può mostrare che alcune pagine importanti sono difficili da trovare, che un modello ripete informazioni sbagliate o che una funzione ostacola il percorso delle persone. Queste evidenze aiutano a valutare il problema. La scelta di investire resta collegata agli obiettivi e ai vincoli aziendali.
Il titolare o il responsabile incaricato deve poter rispondere a domande semplici: quale risultato stiamo proteggendo o cercando? Quali pagine o servizi hanno priorità? Quanto possiamo investire? Quale altro lavoro verrà rimandato? Senza questa scelta, il team tecnico riceve una richiesta con urgenza apparente e una priorità ancora incerta.
2. Il consulente SEO definisce il comportamento da ottenere
Una richiesta come “sistemare la SEO tecnica” lascia troppo spazio all’interpretazione. Serve indicare il problema osservato, le pagine coinvolte, la conseguenza possibile e il comportamento atteso dopo la modifica.
Il comportamento atteso descrive ciò che il sito deve permettere. Per esempio: da ogni pagina di un servizio deve essere possibile raggiungere la guida pertinente attraverso un collegamento visibile e comprensibile, anche da telefono. Questa frase chiarisce il risultato. Evita di imporre in anticipo il codice con cui realizzarlo, perché quella scelta richiede la conoscenza della piattaforma.
Il consulente deve anche spiegare su quali prove si basa la richiesta e quali limiti restano. Può mostrare pagine interessate, dati, controlli tecnici o indicazioni ufficiali. Se il beneficio è ancora un’ipotesi, va dichiarato. Una raccomandazione SEO non autorizza una promessa di crescita.
3. Lo sviluppatore valuta fattibilità, soluzione e conseguenze tecniche
Lo sviluppatore traduce il comportamento atteso nella tecnologia reale del sito. Verifica dove intervenire, quali componenti condivisi sono coinvolti, quali accessi servono, quanto lavoro è necessario e quali altre funzioni potrebbero essere toccate.
Questa valutazione può cambiare il piano. Una modifica che sembra riferita a una pagina potrebbe dipendere da un modello comune. Un’aggiunta manuale potrebbe diventare difficile da mantenere su centinaia di pagine. Una soluzione automatica potrebbe richiedere regole che l’azienda non ha ancora definito.
Quando emerge un’alternativa, lo sviluppatore deve descriverne costi, tempi e rischi con parole che permettano al cliente di scegliere. Il consulente verifica se l’alternativa conserva l’obiettivo SEO. L’azienda autorizza il compromesso e la spesa. In questo passaggio la decisione è condivisa, con contributi diversi.
4. Prima del rilascio si decide come accettare il lavoro
I criteri di accettazione sono condizioni osservabili che permettono di dire che l’intervento è stato eseguito correttamente. Vanno scritti prima dello sviluppo, quando è ancora possibile scoprire una differenza nelle aspettative senza rifare il lavoro.
Un criterio utile precisa che cosa provare, su quali pagine, in quali condizioni e quale risultato deve comparire. Può includere un controllo tecnico e uno aziendale. Il primo verifica che la modifica funzioni. Il secondo conferma che testo, destinazione o regola siano coerenti con l’offerta.
“È online” descrive l’avvenuta pubblicazione. L’accettazione richiede anche l’esito delle prove concordate. Dopo il rilascio, il controllo va ripetuto sul sito pubblico e registrato.
Un esempio: aggiungere un collegamento alle guide nelle pagine dei servizi
Immagina un’azienda con diverse pagine di servizio e un archivio di guide. Il consulente osserva che una persona può leggere la descrizione dell’offerta senza trovare l’approfondimento che risponde ai dubbi più frequenti. Propone quindi un blocco di collegamenti alle guide pertinenti.
La richiesta iniziale potrebbe sembrare semplice: “Aggiungiamo gli articoli correlati”. Restano però diverse decisioni aperte. Chi stabilisce quale guida appartiene a ciascun servizio? Il collegamento verrà scelto manualmente o tramite una regola automatica? Che cosa accade quando una guida viene aggiornata o rimossa? Dove apparirà il blocco da telefono? Chi controllerà che il testo del collegamento descriva davvero la destinazione?
Il consulente specifica la funzione del blocco, indica le pagine iniziali e prepara una prima corrispondenza fra servizi e guide. Lo sviluppatore controlla come sono costruiti i modelli, propone la soluzione e segnala le dipendenze. Il responsabile marketing conferma le associazioni e i testi. L’azienda approva il costo e il momento del rilascio.
Prima di estendere la modifica a tutto il sito, il gruppo può provarla su poche pagine rappresentative. I criteri di accettazione potrebbero essere questi:
- il blocco compare soltanto sulle pagine incluse nella prima fase;
- ogni collegamento usa il testo approvato e porta alla guida corretta;
- il blocco resta leggibile da computer e da telefono;
- chi gestisce i contenuti può aggiornare l’associazione nel modo concordato;
- le altre parti del modello continuano a funzionare come prima;
- dopo la pubblicazione vengono controllate le pagine campione e registrato l’esito.
Queste prove dimostrano che il blocco è stato realizzato secondo l’accordo. Per capire se aiuta le persone a orientarsi e se contribuisce alla visibilità o alle richieste occorrono osservazioni successive. Nell’articolo sui tempi della SEO distinguo proprio l’implementazione, la visibilità, il traffico utile e il risultato commerciale.
La scheda che evita riunioni senza una decisione
Dopo aver compreso la sequenza, puoi raccoglierla in una scheda essenziale. Non serve trasformare ogni intervento in un documento lungo. Serve lasciare una traccia che possa essere letta allo stesso modo da azienda, consulente e sviluppatore.
| Campo | Che cosa scrivere | Chi deve confermare |
|---|---|---|
| Problema e priorità | Situazione osservata, conseguenza possibile e motivo per cui l’intervento viene affrontato ora. | Consulente e referente aziendale. |
| Perimetro | Pagine, modelli, funzioni e casi inclusi; ciò che resta fuori dalla prima fase. | Consulente e sviluppatore, con approvazione dell’azienda. |
| Comportamento atteso | Che cosa deve poter fare una persona o che cosa deve produrre il sito dopo la modifica. | Consulente e referente che conosce l’esigenza aziendale. |
| Soluzione e dipendenze | Modalità tecnica, accessi, materiali, rischi, tempi e altri lavori necessari. | Sviluppatore; consulente per la coerenza con l’obiettivo. |
| Autorizzazione | Costo, ordine di esecuzione, compromessi accettati e momento previsto per il rilascio. | Persona dell’azienda con autorità su budget e priorità. |
| Prove di accettazione | Casi da provare, risultato atteso, pagine campione, responsabile del controllo e traccia da conservare. | Chi esegue il controllo tecnico e chi approva il risultato per l’azienda. |
| Dopo il rilascio | Controllo sul sito pubblico, problemi da sorvegliare e momento in cui valutare gli effetti successivi. | Sviluppatore, consulente e referente secondo le verifiche assegnate. |
La scheda deve avere anche un responsabile che ne tiene aggiornata la versione. Può essere il referente marketing, un project manager, il consulente o un’altra persona scelta dall’azienda. Senza questo presidio, le decisioni finiscono in messaggi separati e lo sviluppatore rischia di lavorare su indicazioni superate.
Tre segnali che mostrano una responsabilità ancora aperta
Il primo segnale è una richiesta che passa direttamente dal report al calendario dello sviluppatore. Manca la decisione aziendale su priorità e risorse. Il tecnico può stimare il lavoro, però non dovrebbe essere costretto a dedurre da solo quanto quel problema conti per il business.
Il secondo segnale è la frase “poi la controlliamo insieme”. Insieme può significare che tutti parteciperanno. Resta da assegnare chi esegue la prova, chi registra l’esito e chi possiede l’autorità per accettare il lavoro.
Il terzo segnale è una soluzione tecnica già scelta prima della verifica di fattibilità. Il consulente può proporre una strada, ma lo sviluppatore deve poter spiegare se la piattaforma richiede un’altra soluzione. Se l’alternativa modifica il risultato atteso, la scelta torna al tavolo con l’azienda.
La mia opinione: il cliente deve conservare la decisione, anche quando delega il lavoro
La mia opinione è che una buona collaborazione riduca le decisioni nascoste. Il consulente rende comprensibili problema, priorità e risultato atteso. Lo sviluppatore rende comprensibili fattibilità, soluzione e rischi. L’azienda sceglie quali compromessi accettare e conserva una prova di ciò che è stato autorizzato.
Delegare l’esecuzione resta utile. Delegare senza una traccia delle decisioni rende invece difficile capire perché un intervento sia stato scelto, che cosa comprendesse e chi debba valutarlo. Il problema emerge mesi dopo, quando cambia una persona o quando una nuova modifica tocca la stessa parte del sito.
Nella pagina sulla consulenza SEO spiego come collego analisi, priorità, indicazioni operative e verifica dei rilasci. In base al progetto posso svolgere direttamente alcune attività oppure preparare e seguire il lavoro con lo sviluppatore dell’azienda.
Raccontami chi lavora sul progetto e quali passaggi devono essere coordinati. Indicami anche quale intervento è fermo o poco chiaro: possiamo partire da quello per assegnare decisioni, responsabilità e prova finale.