Google discover e l’opacità algoritmica: analisi dei publisher profiles

Publisher profiles: un tentativo di Google di ristrutturare il grafo delle entità in un ecosistema sempre più opaco

Se c’è un termine che chi scrive codice impara a temere più di ogni altro, non è “bug” o “refactoring”, ma “opacità”.

E l’inizio del 2026 ci sta offrendo una lezione magistrale su quanto possa essere tecnicamente opaco l’ecosistema da cui dipende gran parte dell’informazione online. Nelle ultime settimane, gli analisti SEO e gli sviluppatori che monitorano i log dei server hanno notato un comportamento erratico in Google Discover, il feed queryless (senza ricerca attiva) che negli ultimi anni è diventato il polmone artificiale per il traffico di molti editori.

Dopo il Core Update di dicembre 2025, che ha riscritto le logiche di visibilità con la delicatezza di una query DROP TABLE in un database di produzione, è emersa — o meglio, riemersa — una funzionalità tecnica apparentemente minore ma strategicamente rilevante: i Publisher Profiles. Si tratta di schede dedicate che permettono agli utenti di “seguire” un editore specifico, aggregando i suoi contenuti.

Dietro questa interfaccia utente pulita, però, si nasconde un tentativo di ristrutturare il grafo delle entità di Google, in un momento in cui Chartbeat documenta un calo del traffico di ricerca globale di un terzo nel corso del 2025.

Non siamo di fronte a una semplice modifica estetica, ma a un cambio di paradigma nell’architettura dell’informazione che merita di essere disassemblato.

Il paradosso della visibilità senza query

Per comprendere la mossa tecnica, bisogna prima guardare sotto il cofano di Discover. A differenza della Ricerca tradizionale (Search), dove l’intento dell’utente è esplicito (“Miglior laptop 2026”), Discover opera su un modello predittivo basato sul Knowledge Graph. L’algoritmo deve indovinare l’interesse dell’utente incrociando la cronologia di navigazione, le interazioni con l’ecosistema Android e i segnali di qualità del contenuto.

È un sistema intrinsecamente instabile, privo di quel determinismo che uno sviluppatore si aspetterebbe da un sistema di input-output.

L’aggiornamento di dicembre ha esacerbato questa instabilità. Molti editori hanno visto crollare le impressioni del 90% quasi da un giorno all’altro, un comportamento che suggerisce una ricalibrazione dei pesi assegnati all’autorità del dominio (E-E-A-T) rispetto alla pura viralità del singolo articolo. In questo scenario di volatilità algoritmica, l’introduzione diffusa dei Publisher Profiles, segnalata dall’esperto Glenn Gabe, appare come un tentativo di reintrodurre un segnale deterministico (il “follow” dell’utente) in un sistema probabilistico.

Tuttavia, l’implementazione tecnica rivela una contraddizione di fondo. Mentre Google chiede agli editori di strutturare meglio i dati per alimentare questi profili, l’algoritmo di raccomandazione sembra andare in tutt’altra direzione. I dati di Marfeel mostrano che il feed ora favorisce massicciamente i riassunti generati dall’AI e i contenuti video di YouTube, riducendo drasticamente il CTR (Click-Through Rate) verso i siti proprietari.

È come se si chiedesse a uno sviluppatore di ottimizzare il codice per una piattaforma che sta attivamente dismettendo le API pubbliche.

Un’identità strutturata nel caos

Dal punto di vista dell’ingegneria del software, i Publisher Profiles sono una soluzione elegante a un problema di “disambiguazione delle entità”. Google ha bisogno di sapere con certezza che un contenuto appartiene a una fonte specifica e verificata per poterlo servire in sicurezza all’interno dei suoi nuovi moduli AI. Creando un contenitore esplicito (il Profilo), Google spinge gli editori a fornire metadati puliti, loghi vettoriali corretti e descrizioni semantiche precise.

L’ironia tecnica risiede nel fatto che questa “pulizia del codice” da parte degli editori non garantisce più il risultato atteso. In passato, un markup Schema.org ben implementato era quasi una garanzia di interpretazione corretta da parte del crawler.

Oggi, è solo il biglietto d’ingresso per competere in un’arena dove le regole fisiche sono cambiate.

Già a settembre 2025, Google aveva annunciato l’espansione dei Profili Editore con l’obiettivo dichiarato di personalizzare i contenuti proposti, ma l’esecuzione attuale suggerisce che questi profili servano più a trattenere l’utente dentro Discover che a inviarlo fuori.

La tensione è evidente anche nelle dichiarazioni ufficiali. Mentre il reparto tecnico di Mountain View spinge per l’adozione di questi formati, le figure di riferimento per le relazioni con la ricerca cercano di abbassare le aspettative sugli outcome effettivi.

Non fate affidamento sull’ottenere il 90% del traffico da una singola fonte come Discover. È rischioso.

— John Mueller, Search Relations Lead presso Google

Questa ammissione, proveniente da una delle voci più tecniche e pragmatiche dell’azienda, suona come un warning in fase di compilazione che non andrebbe ignorato.

Il costo tecnico della dipendenza

Analizzando la situazione come un sistema distribuito, stiamo assistendo alla centralizzazione di nodi che dovrebbero essere decentralizzati. L’espansione dei Publisher Profiles e la contemporanea erosione del traffico in uscita configurano un Walled Garden (giardino recintato) sempre più alto. Per un tecnico, è affascinante osservare come l’infrastruttura di Google stia riuscendo a ingerire contenuti esterni, processarli tramite LLM (Large Language Models) e restituirli all’utente senza mai generare una richiesta HTTP verso il server di origine.

Gli editori si trovano in una posizione di vendor lock-in forzato. Per tentare di recuperare il traffico perso col Core Update, devono adottare le nuove specifiche dei Profili, fornendo a Google dati ancora più strutturati e granulari.

Facendo ciò, però, addestrano il sistema stesso che rende i loro siti meno necessari. È un loop ricorsivo in cui l’efficienza tecnica della piattaforma ospitante cannibalizza le risorse dei nodi periferici.

La ricomparsa dei Profili Editore non va letta come un ramoscello d’ulivo, ma come una patch applicata a un sistema che ha perso equilibrio. L’interfaccia utente suggerisce controllo (“Segui questo editore”), ma il backend esegue una logica di soppressione del traffico organico in favore di asset proprietari o sintetici.

Se nel 2010 l’obiettivo di un buon sviluppatore web era ottimizzare il Time to First Byte per servire l’utente il più velocemente possibile, nel 2026 la sfida è diventata convincere l’algoritmo intermedio che il proprio contenuto merita ancora un link diretto e non una rielaborazione sintetica.

La domanda che ogni CTO editoriale dovrebbe porsi oggi non è “come implementiamo i Publisher Profiles?”, ma se stiamo costruendo infrastrutture per i nostri utenti o stiamo semplicemente fornendo API gratuite per il training set di qualcun altro.