Un sito WordPress può dire a un crawler AI di non usare i suoi articoli per l’addestramento. Non significa che il crawler sia tecnicamente escluso. Questa differenza, piccola sulla carta, decide se un editore sta esprimendo una preferenza oppure sta davvero controllando l’accesso ai contenuti.

Il 17 settembre 2026 nuovi atti desecretati nella causa del New York Times contro OpenAI e Microsoft hanno riportato al centro il tema. Secondo la ricostruzione di TechCrunch, le accuse includono scraping massivo, aggiramento di paywall e rimozione di avvisi di copyright. Gran parte del materiale citato proviene però dalla memoria dei ricorrenti e gli allegati originali restano sigillati: è un contenzioso aperto, non una sentenza. Per chi gestisce un sito, la domanda utile è più concreta: conviene bloccare i crawler o costruire un accesso sotto licenza?

Il criterio: quanto controllo si può far rispettare

Le due opzioni non si distinguono per posizione ideologica sull’AI. Si distinguono per potere contrattuale e capacità tecnica. Il blocco serve a ridurre un uso non desiderato; la licenza serve a trasformare un corpus in un prodotto controllato. La prima strada è disponibile quasi a tutti. La seconda funziona solo quando contenuti, aggiornamento e pubblico hanno abbastanza valore da giustificare una trattativa o un’integrazione.

Il criterio corretto è quindi verificabile: chi accede, a quali materiali, per quale uso e con quale prova nei log o nel contratto. Se una di queste quattro risposte manca, non c’è controllo. C’è solo una dichiarazione di intenti.

Approccio A: segnalare il divieto e applicare il blocco

Il primo livello è robots.txt. Lo standard IETF RFC 9309 specifica che le sue regole non sono una forma di autorizzazione all’accesso e consiglia misure applicative reali, come l’autenticazione, quando una risorsa deve essere protetta. Il file resta utile: dichiara la policy ai crawler che rispettano il protocollo e separa il traffico ammesso da quello contrario alle regole.

I Content Signals aggiungono una distinzione che il vecchio Disallow non aveva: ricerca, uso come input in tempo reale e addestramento. Su WordPress si può quindi lasciare search=yes, negare ai-train e consentire solo un uso di riferimento. Ma anche Cloudflare scrive chiaramente che la conformità a robots.txt è volontaria. Per applicare il blocco servono controlli sul traffico: bot management, regole WAF, rate limit e analisi dei log.

I pro sono velocità e costo contenuto. Una PMI può definire la policy senza costruire un prodotto dati. I contro sono l’identificazione imperfetta dei crawler e il rischio di bloccare strumenti utili insieme a quelli indesiderati. Il punto di rottura arriva quando il bot cambia user-agent, usa indirizzi distribuiti o si presenta come traffico normale. La regola nel file resta corretta, ma l’enforcement perde presa.

Approccio B: licenziare un accesso controllato

La licenza parte dal presupposto opposto: l’accesso è consentito, ma solo entro confini negoziati. Le partnership annunciate da OpenAI con editori come Financial Times, Folha de S.Paulo e UOL prevedono contenuti mostrati con attribuzione e link alle fonti. I dettagli economici non sono pubblici, quindi non ha senso stimare ricavi o usare quegli accordi come listino.

Per un’impresa più piccola, “licenza” non deve per forza significare un accordo con una piattaforma globale. Può essere un feed autenticato, un endpoint REST separato o un archivio con permessi espliciti per un cliente, un’associazione di categoria o un motore verticale. Il contratto definisce l’uso; l’autenticazione identifica il soggetto; i log misurano prelievi e aggiornamenti. È molto più solido di una clausola affidata a un crawler anonimo.

I vantaggi sono tracciabilità, possibilità di compenso e attribuzione concordata. I costi sono legali, commerciali e tecnici. Bisogna mantenere il feed, gestire revoche, correggere i contenuti e verificare che la piattaforma rispetti citazioni e limiti. Il punto di rottura è il potere negoziale: un archivio generico e poco aggiornato difficilmente giustifica un’integrazione dedicata.

Costo, messa in opera e cosa si rompe

Criterio Blocco tecnico Accesso con licenza
Costo Basso all’avvio; cresce con monitoraggio e falsi positivi. Alto all’avvio; include contratto, integrazione e manutenzione.
Messa in opera robots.txt, Content Signals, WAF e log. Feed o API autenticata, termini d’uso, metriche e revoca.
Cosa si rompe crescendo Il crawler non identificato aggira le regole. L’integrazione costa più del valore prodotto.
Prova del controllo Richieste bloccate e traffico osservato nei log. Accessi autenticati, obblighi contrattuali e report.

Cosa cambia per WordPress e per una PMI

Su un blog pubblico eviterei il blocco totale. Togliere accesso a tutti i bot può ridurre indicizzazione e scoperta senza impedire le copie fatte da client non dichiarati. La configurazione sensata separa gli usi: ricerca consentita, addestramento negato, crawling AI noto limitato o bloccato dove serve. Ho già descritto come impostare i Content Signals in WordPress; il passaggio successivo è leggere i log e verificare se la policy produce effetti.

Se invece l’azienda possiede manuali tecnici, listini strutturati, documentazione specialistica o un archivio aggiornato che altri vogliono interrogare, costruirei un canale separato. Il sito pubblico resta pensato per persone e motori di ricerca. Il corpus licenziato passa da un endpoint autenticato, con versioni, identificativi stabili, canonical della fonte e limiti di riuso. In questo modo una modifica al tema WordPress non rompe il flusso dati e una revoca non richiede di oscurare il sito.

In entrambi i casi serve una misura. Per il blocco: richieste per user-agent, risposte negate e volume trasferito. Per la licenza: accessi, citazioni, referral e conversioni. Senza questi numeri non si sa se si sta proteggendo un asset o rinunciando a distribuzione. Il punto di partenza è misurare citazioni e crawler AI sul sito, non aggiungere direttive alla cieca.

La mia scelta: blocco di base, licenza solo per un corpus vero

Per la maggior parte delle PMI sceglierei una policy leggibile dalle macchine, enforcement sui crawler noti e monitoraggio. È il minimo sensato: costa poco, conserva la visibilità in ricerca e rende esplicita la riserva sull’addestramento.

Passerei alla licenza solo davanti a un corpus che ha tre caratteristiche: è originale, viene aggiornato con continuità e risolve un problema che qualcuno è disposto a pagare. Se mancano, costruire un’API commerciale è teatro tecnico. Se ci sono, affidarsi soltanto a robots.txt significa lasciare sul tavolo controllo, attribuzione e ricavi. La scelta netta è questa: bloccare è la difesa predefinita; licenziare è un prodotto, non un’impostazione.

Fonti