Il crawl non è il valore: Cloudflare prova a far pagare l’AI quando usa davvero i contenuti

Per anni abbiamo misurato il valore di un contenuto online con indicatori che stavano quasi tutti prima o dentro la visita: impression, posizione, click, sessioni, conversioni. Con l’AI una parte crescente del valore può nascere altrove: un sistema legge una pagina, la usa per costruire una risposta, una raccomandazione o un report, e l’utente finale potrebbe non visitare mai il sito che ha prodotto l’informazione.

Cloudflare sta provando a mettere un contatore proprio in quel punto. Il 30 settembre ha portato in beta Pay Per Use, un modello in cui l’azienda AI definisce quale utilizzo è disposto a pagare e a quale prezzo, il publisher decide se accettare e il pagamento scatta quando il buyer dichiara che quel contenuto è stato effettivamente usato.

La notizia superficiale è “Cloudflare vuole far pagare l’AI”. Quella interessante è un’altra: il crawl smette di essere trattato come il punto in cui nasce necessariamente il valore economico. Diventa solo una fase della catena. Il vero evento da misurare si sposta più a valle.

Pagare l’accesso e pagare l’uso sono due problemi diversi

Cloudflare aveva già introdotto Pay Per Crawl, che lega il pagamento all’accesso del crawler. È un modello intuitivo: vuoi leggere questa risorsa con il tuo bot, paghi. Ma ha un limite evidente per chi compra contenuti su larga scala: un sistema AI può recuperare moltissime pagine e usarne davvero solo una piccola parte nella risposta finale.

Pay Per Use prova a spostare il prezzo dopo quella selezione. Un motore di ricerca AI potrebbe, per esempio, pagare quando mostra un estratto di una pagina iscritta al programma; un agente di shopping potrebbe pagare quando una recensione influenza una raccomandazione, anche se l’utente non leggerà mai direttamente quella recensione. La definizione dell’evento pagato è proposta dal buyer e il publisher decide se accettare le condizioni.

Se il valore economico nasce dopo il crawl, misurare soltanto il crawl significa osservare il posto sbagliato del sistema.

Questo cambia parecchio il significato del problema. Non stiamo più discutendo soltanto di access control. Stiamo parlando di attribuzione dell’uso: quale contenuto ha contribuito a quale prodotto, in quale momento e secondo quale accordo economico.

Come funziona davvero Pay Per Use

Il meccanismo descritto da Cloudflare è abbastanza lineare. Il buyer identifica il proprio crawler, definisce che cosa considera un uso remunerato, stabilisce un prezzo e collega un account di pagamento. Il publisher vede l’offerta nella dashboard Cloudflare e può accettarla o rifiutarla, mantenendo separati i controlli su crawl, training e altri utilizzi del contenuto.

Quando il buyer usa un contenuto, invia a Cloudflare un record con il momento dell’uso, l’URL sorgente e un identificativo dell’evento. Cloudflare aggrega questi record, verifica che gli eventi siano associati a publisher iscritti, addebita il buyer e paga i publisher mensilmente. Nella dashboard il publisher vede usi riportati e ricavi stimati per buyer e dominio.

È importante non trasformare questa descrizione in qualcosa che non è. Pay Per Use è oggi una beta, non uno standard economico già affermato del web. E soprattutto il dato decisivo — l’uso — è self-reported dal buyer. Le condizioni del programma richiedono reporting completo, ma il sistema dipende comunque dalla capacità di rendere verificabile e credibile quella dichiarazione.

Il punto debole è anche il punto più interessante

Se la parte rivoluzionaria fosse soltanto il micropagamento, ci sarebbe molto meno da raccontare. Internet prova a reinventare i micropagamenti da decenni. Qui la questione seria è un’altra: per pagare l’uso bisogna prima costruire una rappresentazione affidabile dell’uso.

Ed è un problema più difficile di quanto sembri. Un crawler che effettua una richiesta HTTP lascia una traccia relativamente osservabile. Stabilire invece se quella pagina abbia influenzato una risposta, una scelta di un agente o una raccomandazione richiede informazione interna al prodotto AI. Cloudflare non può dedurla semplicemente guardando il traffico in ingresso al sito.

Per questo il modello sposta parte della fiducia sul buyer e prova a incapsularla dentro un contratto, un’identità verificata, una API di reporting, record di utilizzo e settlement. Non elimina il problema della fiducia: lo rende esplicito e gli costruisce attorno un’infrastruttura.

È esattamente il genere di passaggio che vale la pena osservare. Nei sistemi complessi il problema raramente scompare perché gli abbiamo dato un nome nuovo. Diventa gestibile quando identifichiamo chi dichiara un evento, chi lo verifica, quale dato viene conservato e quale conseguenza operativa produce.

Per SEO e AEO cambia la domanda da fare

Se questo modello, o qualcosa di simile, prendesse piede, per chi lavora con contenuti e ricerca diventerebbe insufficiente fermarsi alla domanda “quante visite mi ha mandato l’AI?”. La metrica più interessante sarebbe: in quali esperienze il mio contenuto viene usato e quale valore produce lì dentro?

Cloudflare sta già accostando Pay Per Use ai propri strumenti di Answer Engine Optimization: da una parte osservare come gli assistenti rispondono su un tema, dall’altra vedere quali utilizzi vengono dichiarati e quanto generano. È una saldatura interessante tra discovery, attribution e revenue. Non significa che la AEO diventi automaticamente una macchina per stampare soldi; significa che la visibilità nelle risposte potrebbe finalmente avere una metrica diversa dal traffico referral.

Questo passaggio è coerente con un cambiamento che si vede anche altrove. In una recente intervista a The Verge, il CEO di Cloudflare Matthew Prince ha descritto il problema degli incentivi di un web consumato sempre più da software automatico: i bot non cliccano pubblicità e l’infrastruttura che alimenta le loro richieste continua comunque ad avere un costo.

Il punto non è stabilire oggi quale modello economico vincerà. È riconoscere che il vecchio scambio “ti lascio indicizzare e tu mi mandi traffico” non è più sufficiente a descrivere tutti i casi d’uso.

Essere leggibili dalle macchine non basta più

Nel precedente articolo su Cloudflare cf e gli utenti non umani il tema era l’interfaccia: quando l’utente è anche un agente, output strutturato, contratti prevedibili e ambiguità ridotta diventano requisiti operativi. Pay Per Use aggiunge un secondo livello allo stesso scenario: non basta che una macchina riesca a usare il contenuto, bisogna anche poter governare come lo usa e, eventualmente, attribuire un prezzo a quell’uso.

Lo stesso vale per il passaggio dagli assistenti agli agenti. Quando il software non si limita più a rispondere ma agisce, cresce il numero di eventi che possono avere valore economico: scegliere una fonte, citare una pagina, usare una recensione per decidere, estrarre un dato per completare un task. In questi flussi il semplice conteggio delle visite fotografa una porzione sempre più piccola del sistema.

Il rischio: ottimizzare i contenuti per il contatore sbagliato, di nuovo

C’è però un pericolo abbastanza prevedibile. Appena compare una nuova metrica, qualcuno proverà a ottimizzare tutto per quella metrica. È successo con pageview, keyword density, CTR, engagement e praticamente ogni altro numero disponibile. Potrebbe succedere anche con gli “usi AI”.

Se i publisher iniziassero a produrre materiale soltanto perché ha una maggiore probabilità di essere selezionato da un agente, potremmo semplicemente sostituire una forma di content farm con un’altra. La metrica più sofisticata non rende automaticamente più intelligente il comportamento che incentiva.

La parte sana del modello, semmai, è che può premiare contenuti che hanno un’utilità concreta dentro un processo: dati originali, ricerca, informazioni locali, expertise specialistica, aggiornamenti tempestivi, confronti difficili da ricostruire altrove. Ma questa è una possibilità, non una garanzia. Dipenderà dai prezzi offerti, dalla qualità del reporting e da come buyer e publisher definiranno ciò che vale davvero come “uso”.

Dalla SEO al registro degli effetti

La parte che terrei d’occhio non è quindi il prezzo per singola pagina. Quello cambierà, sarà negoziato, varierà per buyer e per tipo di contenuto. Terrei d’occhio il modello dati che sta emergendo.

Per decenni il web editoriale ha avuto un registro abbastanza semplice: pubblico, il motore indicizza, qualcuno cerca, qualcuno clicca, misuro la visita. Nel web degli agenti la catena potrebbe diventare: pubblico, un sistema scopre, recupera, seleziona, usa, combina, produce un effetto e forse genera un pagamento. Se vogliamo capire quel sistema, dobbiamo osservare più passaggi.

Pay Per Use è interessante perché prova a rendere uno di quei passaggi — l’uso downstream — un evento esplicito, contabilizzabile e collegato a una transazione. Funzionerà? È troppo presto per dirlo. La beta serve esattamente a capire se i buyer sono disposti a pagare abbastanza, se i publisher considerano il ritorno sufficiente e se il reporting viene ritenuto affidabile.

Ma la direzione del problema è molto più importante del prodotto specifico: quando il consumatore del contenuto diventa software, non basta sapere chi è entrato dalla porta. Bisogna capire che cosa ha fatto con ciò che ha trovato dentro.