Il prezzo SEO dei dati pubblici (e chi lo paga davvero)

Apri il sorgente di una qualunque pagina del tuo prodotto e contane i dati. Non quelli che si vedono: quelli che ci sono. Quasi sempre sono molti di più, e quasi sempre nessuno ha deciso che ci fossero. Per farti trovare devi esporre alle macchine esattamente il patrimonio informativo su cui è costruita la tua azienda — catalogo, prezzi, disponibilità, recensioni. È un trade-off legittimo e in buona parte inevitabile. Il problema non è che esista. È che quasi nessuno lo tratta come una scelta, con un perimetro e dei limiti.

TL;DR

Ogni pagina ottimizzata per la ricerca espone dati strutturati leggibili da chiunque, non solo dai motori.
Una pagina moderna contiene due strati di dati per le macchine: quelli per i motori di ricerca e lo stato con cui si costruisce l'interfaccia. Il secondo è quasi sempre più ricco di quanto la pagina mostri.
Il problema non è il singolo dato: è la scala. Migliaia di schede raggiungibili con la stessa richiesta che fa un utente che clicca "pagina successiva".
In UE questi dati restano protetti anche se pubblici, dal diritto sui generis sulle banche dati. "Pubblico" non vuol dire "libero".
La risposta non è nascondere tutto. È decidere cosa esporre, a chi, con quali limiti — e sono poche righe di codice, non solo di policy.

Il trade-off che nessuno mette per iscritto

Per essere trovato — da Google o da un assistente conversazionale — devi rendere leggibile a una macchina proprio ciò che ti distingue: quanto è ampio il catalogo, quanto copri il territorio, quanto sei valutato bene. Non esiste una versione di "buona SEO" che non passi di lì. Se vendi visibilità, la visibilità si paga in dati.

Fin qui è sano. Il punto dove si rompe è un altro: fra "questi dati servono per essere indicizzati" e "questi dati sono finiti in pagina perché era più comodo così" non c'è quasi mai nessuno che traccia la riga. Non è una decisione sbagliata — è l'assenza di una decisione.

Cosa c'è davvero in una pagina

Quello che il browser mostra e quello che la pagina contiene sono due cose diverse. Una pagina moderna porta con sé almeno due strati destinati alle macchine, entrambi in chiaro nel sorgente:

I dati strutturati per i motori di ricerca (schema.org). Servono a generare i risultati arricchiti: nome, indirizzo, valutazione, immagini, URL. Li legge chiunque scriva un parser in dieci righe, non solo Googlebot.
Lo stato applicativo con cui l'interfaccia si costruisce. È il meccanismo con cui le app moderne "idratano" la pagina al primo caricamento. Ed è qui che si accumula il grasso: categoria precisa, valutazioni su più dimensioni, orari, personale, coordinate geografiche — e spesso campi che l'interfaccia non mostra affatto.

Per capire la differenza (dati inventati, solo per mostrarne la forma):

<!-- 1. Pensato per i motori di ricerca — schema.org, formato standard -->
<script type="application/ld+json">
  {
    "@context": "https://schema.org",
    "@type": "HairSalon",
    "name": "Salone Esempio",
    "address": { "streetAddress": "Via Roma 1", "addressLocality": "Milano" },
    "aggregateRating": { "ratingValue": "4.7", "reviewCount": 128 }
  }
</script>

// 2. Stato di hydration — molto più ricco, e include roba che la pagina non mostra
{
  "venue": {
    "id": "8231",
    "name": "Salone Esempio",
    "category": "Parrucchiere",
    "rating": { "overall": 4.7, "cleanliness": 4.8, "value": 4.5 },
    "openingHours": { "mon": "09:00-19:00" },
    "staff": [{ "name": "..." }],
    "address": { "lat": 45.4642, "lon": 9.19, "street": "Via Roma 1" },
    "contact": { "phone": "+39 02 XXXXXXX" }
  }
}

Nessuno dei due chiede login, chiave API o altro. Sono la pagina che riceve qualunque visitatore.

Un caso che ho verificato

Perché non resti teoria: ho fatto questo esame su un marketplace beauty e wellness europeo, reale, che non nomino. Trovati entrambi gli strati, nessuno dei due protetto. Sulla scheda di dettaglio, lo stato applicativo esponeva anche un dato assente dalla lista di ricerca: il numero di telefono diretto.

Ma il dato singolo non è il problema. È la scala. Una grande città italiana restituiva fra le mille e le millecinquecento attività su una settantina di pagine, e ogni pagina successiva era raggiungibile con un link normale presente nell'HTML — lo stesso che segue un utente che clicca avanti. Ricostruire il catalogo completo di una categoria in una città è questione di minuti, non di ore, con richieste anonime e rispettando i tempi dichiarati dal sito stesso.

Due dettagli che valgono più del resto:

Il robots.txt era scritto bene. Bloccava con precisione decine di combinazioni di filtri, e apriva esplicitamente ai crawler AI con un elenco dichiarato. Non è un file dimenticato: è un file curato da qualcuno che sapeva cosa voleva escludere. Le pagine di listing e di dettaglio, però, restavano aperte — coerente con la scelta di visibilità, e proprio per questo mai compensata altrove.
Zero link esterni nel payload. Nessun dominio proprio, nessun social, nessun URL fuori dal marketplace. Coerente con un modello che non vuole disintermediare. Il corollario è interessante: un'attività visibile solo lì è un'attività che non ha un sito suo — e questo dice qualcosa sul mercato più che sulla piattaforma.

Onestà: non c'è niente di eccezionale in questo caso. L'ho scelto perché è ordinario. La stessa identica analisi la puoi fare, adesso, sul tuo prodotto.

Cosa dice la legge

Un punto spesso sottovalutato: in UE, le raccolte di dati godono di una protezione specifica — il diritto sui generis sulle banche dati (Direttiva 96/9/CE) — che si applica anche quando i singoli dati sono pubblici. La protezione non riguarda l'originalità dei contenuti, ma l'investimento fatto per raccoglierli, verificarli e organizzarli. Estrarre e riutilizzare sistematicamente una parte sostanziale di una banca dati protetta, senza autorizzazione, può violare questo diritto indipendentemente dal fatto che i singoli dati fossero visibili gratuitamente.

Se tra i dati compaiono elementi riferibili a persone fisiche — nomi di professionisti, recensioni con contenuto identificabile — entra in gioco anche il GDPR, con obblighi specifici su base giuridica e finalità del trattamento che vanno ben oltre la semplice pubblicità del dato originale.

Cosa può fare un'azienda, in pratica

Non è necessario scegliere tra "SEO forte" e "dati protetti": è necessario smettere di trattarli come se non fossero collegati. Alcune di queste contromisure sono a costo quasi zero, altre richiedono un vero intervento architetturale — vale la pena separarle, e qualche riga di codice aiuta a capire cosa cambia davvero.

Le contromisure a basso sforzo (giorni, non sprint)

Ridurre lo stato al minimo, non al comodo. Lo stato di hydration lato client dovrebbe contenere solo ciò che serve a disegnare quella schermata in quel momento — non l'intero oggetto restituito dal backend. In pratica, spesso basta un passaggio esplicito di selezione dei campi prima di serializzare:

// Cattivo: passa l'intero oggetto dominio così com'è al client
return res.json({ props: { venue } })

// Meglio: whitelist esplicita dei campi che l'interfaccia usa davvero
const { id, name, category, rating, openingHours, address } = venue
return res.json({ props: { venue: { id, name, category, rating, openingHours, address } } })
// niente "contact.phone", niente campi interni di ranking, ecc. — se non servono a QUELLA pagina

Separare i dati strutturati per i motori di ricerca dallo stato applicativo. Il blocco schema.org dovrebbe nascere da una funzione dedicata, con la lista esplicita dei campi da indicizzare — non da un dump dello stesso oggetto usato dal frontend:

function toSearchEngineJsonLd(venue: Venue) {
  // Solo i campi che vogliamo davvero indicizzare, elencati a mano
  return {
    '@type': 'HairSalon',
    name: venue.name,
    address: venue.address,
    aggregateRating: venue.rating,
    url: venue.publicUrl,
  }
}

Mettere un rate limit reale, non solo dichiarato. Un Crawl-delay nel robots.txt è una richiesta educata, non un'enforcement: i bot che si comportano bene lo rispettano, chi vuole aggirarlo lo ignora e basta. Un limite lato server, anche semplice, taglia fuori la maggior parte dei tentativi non sofisticati:

// Esempio minimale, in memoria — in produzione userei Redis o un edge rate limiter
const richiesteRecenti = new Map<string, number[]>()

function isOltreLimite(ip: string, maxRichieste = 60, finestraMs = 60_000) {
  const ora = Date.now()
  const storico = (richiesteRecenti.get(ip) ?? []).filter((t) => ora - t < finestraMs)
  storico.push(ora)
  richiesteRecenti.set(ip, storico)
  return storico.length > maxRichieste
}

Alert su pattern anomali, non solo su errori. Migliaia di richieste sequenziali a pagine di listing consecutive, da uno stesso IP o blocco di IP, in un intervallo di tempo che nessun utente umano userebbe per sfogliare un catalogo, è un pattern rilevabile con una query di log — se qualcuno la scrive e qualcuno la guarda.

Le contromisure architetturali (richiedono un progetto)

Passare da "stato serializzato nel client" a un pattern BFF (Backend-For-Frontend) o Server Components. Se il rendering avviene lato server e il client riceve solo HTML già pronto più le interazioni minime via richieste mirate, non esiste più un blocco JSON monolitico da "aspirare" in un colpo solo — ogni dato richiede una richiesta a sé, tracciabile e limitabile singolarmente.
Firmare o legare temporalmente le risposte (token con scadenza breve, watermarking sottile dei dati per identificare la fonte di un eventuale leak aggregato) per rendere costoso — non impossibile, costoso — il riuso sistematico su larga scala.
Un livello anti-bot dedicato (fingerprinting comportamentale, challenge invisibili, non necessariamente CAPTCHA visibili che degradano l'esperienza umana) davanti alle rotte di listing e dettaglio più preziose, con un'eccezione esplicita e verificata per i crawler che si vuole autorizzare (motori di ricerca, i crawler AI scelti consapevolmente) — la differenza rispetto a oggi è che l'eccezione va dichiarata e verificata (verificare lo User-Agent non basta, si falsifica in una riga), non lasciata come comportamento di default per chiunque.

Il pezzo che quasi nessuno fa

Un canale dati ufficiale per chi ha un bisogno legittimo di accesso massivo — partner, aggregatori, researcher — con un'API dedicata, termini d'uso chiari, e un referente. Chi ha davvero bisogno di tanti dati preferisce quasi sempre un canale stabile e documentato a uno grezzo e non garantito; offrirlo toglie la scusa "non c'era altro modo" a chiunque voglia comunque passare dalla porta sul retro.
Citare esplicitamente la protezione sui generis e i termini d'uso nella pagina stessa, non solo nei Termini di Servizio generali che nessuno legge. Rende la posizione legale difendibile in modo esplicito invece che implicito, e alza — psicologicamente, prima ancora che legalmente — il costo percepito di ignorarla.

Nessuna di queste misure, da sola, è una soluzione definitiva — ed è proprio questo il punto: la sicurezza di un'esposizione dati non è un interruttore, è una somma di attriti. L'obiettivo non è rendere impossibile l'estrazione sistematica: è renderla abbastanza costosa, tracciabile e deliberata da scoraggiare chiunque non abbia un motivo legittimo e dichiarato per farla.

Cosa farei domani mattina

Se dovessi guardare un prodotto che non conosco, farei tre cose in quest'ordine. La prima costa venti minuti.

Apri il sorgente di una pagina di listing e di una di dettaglio, e leggi lo stato applicativo riga per riga. Non cercare vulnerabilità: fai l'inventario. Per ogni campo una domanda sola — questa pagina lo usa? Quello che avanza è già la risposta.

Poi guarda quanto è facile arrivare alla pagina mille. Se il link "avanti" è un URL normale e non c'è un limite lato server, il tuo catalogo non è protetto da niente. Il robots.txt è una richiesta educata, non un cancello.

Poi decidi, e scrivilo da qualche parte che qualcuno rileggerà quando il modello dati cambia. Perché cambierà, e il campo nuovo entrerà nel payload per lo stesso motivo per cui ci è entrato il telefono: perché serializzare tutto è più veloce che scegliere.

Non è un lavoro da sprint, è mezza giornata. E quasi nessuno la spende — che è poi il motivo per cui, quando la spendi, trovi sempre qualcosa.

FAQ

Uno scraping massivo di dati pubblici è legale?

Dipende dalla giurisdizione e dai dettagli. In UE, il diritto sui generis sulle banche dati protegge le raccolte anche quando i singoli dati sono pubblici, e il GDPR si applica se sono coinvolti dati personali. "Pubblico" non equivale a "libero da ogni protezione legale".

Perché un'azienda dovrebbe autorizzare i crawler AI se questo espone anche i suoi dati?

Perché la visibilità nelle risposte generative (AEO/GEO) sta diventando un canale di scoperta paragonabile alla ricerca classica. La scelta corretta non è bloccare tutto, ma decidere consapevolmente cosa autorizzare a leggere e in quale forma — distinguendo i dati minimi necessari dal resto.

Come si trova un equilibrio tra SEO e protezione del patrimonio dati?

Separando esplicitamente ciò che serve all'indicizzazione da ciò che serve solo al funzionamento dell'interfaccia, monitorando pattern di accesso anomali, e offrendo un canale dedicato — con termini chiari — a chi ha un bisogno legittimo di accesso più ampio di un singolo utente umano.

Se stai valutando come bilanciare visibilità SEO/GEO e protezione del tuo patrimonio dati — o vuoi capire cosa espone davvero il tuo prodotto oggi — è un audit che faccio regolarmente: parliamone. Approfondimenti collegati: GEO, cos'è davvero e SEO per le AI e Google AI Overview.

Fonti: Direttiva 96/9/CE sulla tutela giuridica delle banche di dati, Regolamento (UE) 2016/679 — GDPR, schema.org — ItemList.