Contenuti generati dagli utenti: la guida SEO

Quando si parla di contenuti generati dagli utenti in ottica SEO, quasi tutto quello che si trova online riguarda il fuori sito: forum esterni dove citare il tuo brand, community dove promuovere un articolo, segnali di autorevolezza che arrivano da discussioni altrui. È un argomento legittimo, ma lascia scoperto un problema diverso e più urgente per chi gestisce un sito che ospita UGC in prima persona: commenti sotto gli articoli, thread di forum, sezioni domande e risposte, profili utente, recensioni. Quel contenuto vive sul tuo dominio, viene scansionato dal tuo crawl budget e finisce, bene o male, dentro l'indice di Google insieme al resto del sito.

La domanda che conta qui non è se l'UGC fa bene o male alla SEO in astratto, ma come si comporta ogni singola pagina che gli utenti generano: è una pagina che risponde a un'intenzione di ricerca reale e approfondita, oppure è un guscio vuoto — un profilo senza post, un thread con una sola risposta, una pagina di ordinamento duplicata dieci volte con parametri diversi? La differenza tra un sito dove l'UGC costruisce autorità e uno dove l'UGC diluisce la qualità media dell'indice si gioca tutta su decisioni tecniche: quale attributo mettere sui link, quali pagine indicizzare, quali bloccare, quando intervenire prima che diventi un problema di manual action.

Il confine con la promozione: qui l'UGC è già tuo

Vale la pena essere espliciti sul perimetro. Usare forum e community per promuovere un contenuto, scegliere dove intervenire per costruire visibilità fuori dal proprio sito, è un tema di distribuzione e non viene trattato qui. Allo stesso modo, capire cosa rende un contenuto linkabile, cioè perché altri dovrebbero volerlo citare, è una domanda editoriale a monte. Questo articolo parte da un punto diverso: l'utente ha già scritto qualcosa, quel qualcosa ha già generato una URL sul tuo dominio, ed è già stato scansionato o lo sarà a breve. Da qui in poi il problema è tuo, tecnico e quotidiano.

rel="ugc" e nofollow: quale attributo sui link degli utenti

Ogni volta che un utente lascia un link in un commento, in una firma di forum o in una biografia di profilo, quel link va marcato in modo esplicito. Nel 2019 Google ha introdotto rel="ugc" proprio per questo scenario, accanto a rel="sponsored" per i link a pagamento, entrambi pensati come varianti più specifiche del vecchio rel="nofollow". Il messaggio a Google è: questo link non è stato scelto dall'editore del sito, non è un voto di fiducia editoriale, è stato inserito da un terzo. Da quando questi attributi sono trattati come segnali e non come blocchi assoluti, Google può comunque decidere di scansionare o considerare il link, ma la marcatura resta il modo corretto di dichiarare la natura del link.

In pratica, questo si configura una volta sola a livello di piattaforma: il motore di commenti, il software del forum o il CMS che gestisce i profili deve applicare rel="ugc" automaticamente a ogni link inserito dagli utenti, senza affidarsi alla marcatura manuale caso per caso, che su un sito con migliaia di commenti al mese è semplicemente impraticabile. Il disavow file è uno strumento diverso e più pesante, da riservare a link tossici già indicizzati altrove, non un sostituto della marcatura preventiva.

Spam nei commenti e nei profili come vettore di manual action

Nella Search Console, "spam generato dagli utenti" è una categoria di azione manuale a sé, distinta dallo spam puro e semplice del sito. Si applica quando un sito permette, anche solo per assenza di controlli, che vengano pubblicati contenuti spam attraverso aree aperte agli utenti: sezioni commenti senza moderazione, forum dove le firme diventano elenchi di link, pagine profilo che esistono solo per ospitare un link in uscita, libri degli ospiti mai controllati. Il punto chiave è che Google tende a ritenere responsabile il sito che ospita, non solo chi ha scritto lo spam: la piattaforma aperta è un tuo asset e la sua igiene è compito tuo.

I punti da presidiare in modo continuativo sono pochi ma vanno controllati con regolarità:

• Coda di moderazione per commenti e post prima della pubblicazione pubblica, non dopo
• rel="ugc" o rel="nofollow" applicato di default su ogni link inserito da utenti, senza eccezioni manuali
• Limiti di frequenza e controlli anti-bot sulla creazione di account e post, come misura di volume più che di SEO in senso stretto
• Audit periodico dei vettori più sfruttati: bio profilo, firme forum, corpo dei commenti, campo "sito web" nei form

Pagine sottili e quasi-duplicate che l'UGC crea da solo

Anche senza alcuno spam, l'UGC produce da solo un numero enorme di pagine povere di contenuto. Un thread con una sola risposta che si limita a citare per intero il messaggio originale è, agli occhi di un crawler, quasi indistinguibile dal post di partenza: due URL, un contenuto. Un profilo utente con avatar di default, nessuna biografia e zero post pubblici è comunque una URL indicizzabile per default in molte piattaforme, moltiplicata per ogni account mai creato, anche quello aperto una volta e mai più usato. Su un forum attivo da anni questo significa decine di migliaia di pagine che non rispondono a nessuna query reale.

Il rischio non è la singola pagina povera, è l'effetto aggregato: i segnali di qualità che Google valuta a livello di sito tengono conto anche di quanto dell'indice è utile rispetto a quanto è rumore. Un sito dove gran parte delle pagine indicizzate sono profili vuoti o thread da una riga trasmette un segnale diverso da uno dove la stessa proporzione di UGC è fatta di risposte sostanziali. La soluzione non è vietare l'indicizzazione dell'UGC in blocco, ma introdurre una soglia: solo le pagine che superano un livello minimo di sostanza, come numero di risposte, lunghezza, presenza di contenuto originale, restano indicizzabili.

Paginazione dei thread e crawl budget

I forum multi-pagina generano URL a raffica: pagina 2, pagina 3, spesso moltiplicati per varianti di ordinamento come più recenti, più popolari, meno recenti, e per viste di stampa o modalità compatta. Ogni combinazione è tecnicamente una URL diversa che un crawler può trovare e visitare, ma il contenuto sottostante è quasi sempre lo stesso set di messaggi presentato in un ordine diverso. Google documenta esplicitamente il concetto di crawl budget per i siti di grandi dimensioni, e un forum attivo è il caso da manuale: migliaia di thread, ciascuno moltiplicato per pagine e parametri di ordinamento, possono facilmente superare quello che Googlebot è disposto a scansionare in un ciclo, a scapito delle pagine che contano davvero.

La gestione corretta separa due problemi che vengono spesso confusi. Bloccare la scansione via robots.txt impedisce a Googlebot di visitare quelle URL, ma se sono comunque linkate altrove possono finire indicizzate senza che il crawler ne abbia mai letto il contenuto, un risultato peggiore, non migliore. Il noindex, al contrario, richiede che la pagina venga scansionata almeno una volta perché il crawler legga il tag e la rimuova dall'indice: per questo va applicato lasciando la scansione aperta, non insieme a un blocco robots.txt sulla stessa URL. In pratica: canonical verso la vista di default sulle varianti di ordinamento, noindex e follow sulle pagine di paginazione oltre la prima quando il contenuto è sostanzialmente ripetuto, canonical autoreferenziale sulla pagina uno di ogni thread.

Quando noindexare una categoria UGC (e quando no)

Il noindex indiscriminato di intere sezioni UGC è tanto sbagliato quanto lasciarle tutte aperte: elimina insieme lo scarto e le pagine che stavano già portando traffico. La decisione va presa per categoria, con criteri verificabili prima di agire. Un thread risponde a un'intenzione di ricerca che nessun'altra pagina del sito copre già? Ha una profondità minima, più risposte sostanziali e non solo un "grazie", oppure è ancora un guscio vuoto? Sta già ricevendo ingressi organici, verificabili nei log del server o nei dati di ricerca già disponibili, prima di decidere di rimuoverlo dall'indice? Un thread già posizionato che viene noindexato per automatismo è traffico buttato via.

Un criterio pratico che funziona su volumi alti è invertire il default: le nuove pagine UGC nascono noindex, e vengono promosse a indicizzabili solo quando superano una soglia di attività, un numero minimo di risposte sostanziali, una risposta accettata o segnalata come utile, un tempo minimo di permanenza senza essere segnalate come spam. È lo stesso principio che i siti di domande e risposte più maturi applicano da anni: non si indicizza il contenitore appena creato, si indicizza la discussione quando ha effettivamente raggiunto una profondità che vale la pena mostrare in SERP.

Quando l'UGC guadagna davvero il posizionamento

L'errore opposto, altrettanto comune, è trattare tutto l'UGC come rumore da nascondere e noindexare per prudenza intere sezioni che in realtà stanno facendo il lavoro che nessun redattore potrebbe fare da solo. Un redattore scrive per il visitatore medio, con un linguaggio che generalizza; un utente in un thread di supporto scrive con l'esatto codice di errore che sta vedendo, il nome esatto del modello di prodotto, la frase esatta con cui poi altri utenti con lo stesso problema cercheranno su Google. Quella corrispondenza letterale tra la domanda digitata e la formulazione della risposta è qualcosa che un contenuto editoriale, per quanto ben scritto, raramente replica.

Il caso tipico è un thread di forum di supporto il cui titolo riporta un errore specifico che finisce per posizionarsi meglio della pagina di documentazione ufficiale sullo stesso argomento, non perché il thread sia scritto meglio, ma perché la documentazione descrive la funzionalità mentre il thread descrive il fallimento con le stesse parole usate da chi lo sta cercando. Recensioni molto specifiche, con dettagli che solo un utente reale scriverebbe, coprono lo stesso spazio: nessun copy editoriale genera quel livello di specificità senza inventarla, il che è un problema per motivi diversi da quelli SEO.

Governance continua, non una pulizia occasionale

L'UGC si genera ogni giorno, quindi il controllo non può essere un intervento una tantum fatto una volta e dimenticato. Funziona meglio quando le regole sono incorporate nella configurazione della piattaforma piuttosto che applicate a mano pagina per pagina: rel="ugc" automatico su ogni link inserito da un utente, noindex di default sulle nuove pagine finché non superano la soglia di attività definita, canonical automatico sulle varianti di ordinamento e paginazione. Le regole codificate nel sistema non dipendono dalla memoria di chi gestisce il sito e restano valide anche quando cambia la persona che se ne occupa.

Accanto all'automazione serve un ciclo di controllo periodico, non giornaliero ma nemmeno annuale: un'analisi trimestrale che segmenta le pagine indicizzate per sezione UGC, confronta il numero di pagine indicizzate con quelle che stanno effettivamente generando ingressi, e individua i thread rimasti sotto la soglia di attività per mesi, candidati naturali a restare fuori indice o a essere accorpati. Questo controllo periodico è concettualmente vicino alla potatura dei contenuti editoriali, ma applicato a un tipo di contenuto che nasce e si accumula in modo continuo, non a un catalogo statico di articoli.