Lo structured data diventa davvero utile quando smette di essere una collezione di blocchi JSON-LD indipendenti e inizia a descrivere entità che restano riconoscibili nel tempo. Una Organization, una Person, un Article o un prodotto non dovrebbero cambiare identità perché cambia il template che li renderizza.
In SuperRankSEO questa distinzione è importante perché Schema & Knowledge Graph non vive isolato: alimenta una rappresentazione coerente del sito e, nel caso ecommerce, si collega anche al modello prodotto. Il punto non è “avere più tipi Schema”, ma sapere quali entità esistono, chi le possiede e come si collegano.
Dal markup isolato alle entità persistenti
Il problema del markup isolato appare quando ogni pagina genera il proprio oggetto senza una strategia di identità. L’organizzazione viene descritta in modi diversi, l’autore cambia @id tra template, il prodotto non è collegato correttamente alle sue varianti oppure più plugin emettono grafi concorrenti. Google può comunque leggere il JSON-LD, ma per il team diventa difficile capire quale componente è autorevole.
Un modello a entità parte dalla domanda opposta: quali oggetti del dominio devono esistere indipendentemente dalla pagina corrente? Per un sito editoriale possono essere Organization, Person e Article. Per un ecommerce entrano Product, ProductGroup o ProductModel, Brand e identificatori. Una volta definito l’owner, i template dovrebbero limitarsi a referenziare quell’identità invece di reinventarla.
Tre regole di ownership che evitano la maggior parte dei conflitti
- Un solo writer autorevole per ogni entità. Se tema, plugin SEO e plugin ecommerce scrivono tutti lo stesso oggetto, prima o poi emergerà una divergenza.
- ID stabili. L’identità di Organization, Person o ProductModel non dovrebbe dipendere dal percorso della pagina che la mostra.
- Relazioni esplicite. Article → author, Product → brand, ProductModel → variant sono più utili quando il grafo rende leggibile la relazione e non solo la presenza dei nodi.
WooCommerce: prodotto reale, listing e varianti non sono la stessa cosa
Il catalogo WooCommerce rende evidente il problema. Una scheda prodotto può rappresentare un singolo bene, un modello con più varianti oppure un listing commerciale. Colori, taglie e SKU non trasformano automaticamente ogni variante in una nuova identità concettuale. Per questo la baseline SuperRankSEO include relazioni Product / ProductGroup / ProductModel e controlli sugli identificatori.
La pagina WooCommerce tratta questo aspetto come parte del modello ecommerce, non come decorazione del markup. Prima di pubblicare dati strutturati bisogna sapere quale oggetto viene venduto, quali identificatori sono realmente disponibili e quali varianti condividono la stessa identità di modello.
Gli identificatori non vanno inventati per riempire una proprietà
GTIN, EAN, UPC e altri identificatori hanno valore proprio perché collegano un prodotto a un sistema esterno di identità commerciale. Se non esistono, non vanno creati “per far contento Schema”. Lo stesso principio vale per un Brand o per un autore: meglio uno stato incompleto ma vero che un grafo formalmente ricco e semanticamente falso.
Principio operativo: Schema descrive lo stato del sito; non deve inventare uno stato migliore di quello che il catalogo o il contenuto possiedono davvero.
Come verificare che il graph resti coerente
La validazione non dovrebbe fermarsi al “nessun errore sintattico”. È utile controllare un campione di URL rappresentative e chiedersi: l’@id dell’organizzazione è lo stesso? l’autore punta alla stessa Person? il prodotto e le varianti mantengono relazioni coerenti? un secondo plugin sta emettendo lo stesso tipo con proprietà incompatibili?
- controlla il source HTML reale, non solo la configurazione del backend;
- confronta pagine diverse che dovrebbero condividere la stessa entità;
- verifica cosa succede quando un contenuto cambia autore o un prodotto cambia disponibilità;
- controlla che noindex, canonical e template alternativi non generino un graph completamente diverso per errore.
Dove entra il Knowledge Graph operativo
Quando le entità sono persistenti, possono diventare contesto per altri workflow: internal linking, contenuti correlati, organizzazione editoriale o modelli ecommerce. Questo non significa che il grafo “decida” automaticamente cosa ottimizzare; significa che altri moduli possono leggere una rappresentazione più coerente invece di dedurre ogni volta chi o che cosa stanno osservando.
Per la procedura tecnica, continua con la guida KB Schema & Entity Registry: ownership e verifica del graph. Per la parte ecommerce, vedi anche ProductModel, GTIN e identificatori WooCommerce.