Professione: Specialista in Employer Branding – Presentazione delle aziende come datori di lavoro attraenti
Un file brand.json fornisce informazioni sul marchio legalmente vincolanti in formato leggibile da una macchina. Questa guida illustra la sua struttura, un esempio in formato JSON, la convalida, la manutenzione e la differenza rispetto a Schema.org e llms.txt.

Un file brand.json sul tuo sito web fornisce informazioni sul marchio legalmente vincolanti sotto forma di dati strutturati e leggibili automaticamente. Il file può contenere nomi, servizi, sedi, lingue, metodi di contatto, orari di apertura e profili ufficiali da un'unica fonte. Un file brand.json migliora l'unicità tecnica, ma non garantisce citazioni o menzioni da parte di sistemi di intelligenza artificiale come ChatGPT, Gemini, Perplexity e altri.

Per una PMI, il vantaggio non risiede nel formato di file aggiuntivo, bensì in una risposta vincolante alla domanda: quali informazioni sull'azienda sono corrette e dove sono conservate?

Un file brand.json non sostituisce un sito web di facile utilizzo. Il file è un output aggiuntivo, leggibile da una macchina, delle stesse informazioni sul marchio disponibili pubblicamente.

brand.json per il tuo sito web: compiti e limitazioni

Un file brand.json raccoglie i dati chiave dell'azienda e del marchio in formato JSON , un formato testuale per lo scambio di dati. Gli esseri umani possono leggere il file; cosa ancora più importante, può essere elaborato da siti web, applicazioni, interfacce, sistemi di ricerca e servizi basati sull'intelligenza artificiale.

Attualmente, il termine brand.json non si riferisce a uno standard web obbligatorio pubblicato da un ente di standardizzazione riconosciuto. Un gestore di brand open source, ad esempio, utilizza lo stesso nome. Tuttavia, la struttura e l'interpretazione di un file brand.json dipendono dalla specifica integrazione tecnica. Pertanto, sistemi diversi possono utilizzare nomi e strutture di campo differenti.

Pertanto, non adottate un modello senza prima averlo verificato. Definite uno schema chiaro, documentate i campi e assicuratevi della coerenza dei dati. Un file sintatticamente valido, ma contenente orari di apertura errati, sarà comunque inesatto dal punto di vista fattuale.

Quali informazioni sul marchio devono essere incluse nel file?

Nel mio lavoro con le aziende a conduzione familiare, mi imbatto spesso nello stesso problema iniziale: il nome dell'azienda è scritto in modo diverso sul sito web rispetto al profilo Google My Business, i servizi non sono denominati in modo coerente in tedesco e italiano e un vecchio numero di telefono è ancora memorizzato in un profilo sui social media. Un file brand.json dovrebbe consolidare queste informazioni laddove tali discrepanze risultano particolarmente problematiche.

Identità e posizionamento

  • Nome del marchio pubblico: Il nome con cui l'azienda comunica e viene ricercata.
  • Nome legale: Il nome completo dell'azienda per un'identificazione inequivocabile.
  • Breve descrizione: Una descrizione oggettiva dell'azienda, del suo target di riferimento e della sua offerta.
  • Servizi: Nomi di servizio approvati con brevi spiegazioni e identificatori stabili.
  • lingue: Lingue in cui vengono effettivamente offerti consulenza, vendite o assistenza.

Ubicazione, accessibilità e manutenzione

  • Posizioni: Indirizzi completi e, ove applicabile, aree geografiche di competenza.
  • Modalità di contatto: Indirizzo email generico, numero di telefono e sito web ufficiale.
  • Orari di apertura: Orari regolari con giorni della settimana e fuso orario chiaramente definiti.
  • Profili ufficiali: Profili aziendali confermati sulle piattaforme pertinenti.
  • Versione e data di modifica: Informazioni sulla gestione delle versioni e sull'ultima revisione tecnica.

I dati personali devono essere inclusi nel file pubblico solo se la pubblicazione è necessaria, approvata internamente e conforme alla legge. Per molte PMI, un indirizzo generico come info@company.it è sufficiente . Per precauzione, è consigliabile non pubblicare numeri di cellulare privati, interni o indirizzi email personali.

Dati del marchio in formato JSON: esempio da una PMI altoatesina

L'esempio seguente descrive un'attività artigianale fittizia dell'Alto Adige. La struttura è volutamente compatta. Si tratta di un possibile modello, ma non di uno schema brand.json universalmente vincolante.

{
  "schemaVersion": "1.0",
  "version": "2026.03",
  "lastUpdated": "2026-03-20",
  "publicName": "Alpenwerk",
  "legalName": "Alpenwerk Holzmanufaktur GmbH",
  "descriptions": {
    "de": "Planung und Fertigung maßgefertigter Möbel für private und gewerbliche Räume in Südtirol.",
    "it": "Progettazione e produzione di mobili su misura per spazi privati e commerciali in Alto Adige."
  },
  "website": "https://www.alpenwerk.example",
  "languages": [
    {
      "code": "de",
      "name": "Deutsch"
    },
    {
      "code": "it",
      "name": "Italiano"
    }
  ],
  "services": [
    {
      "id": "moebel-nach-mass",
      "names": {
        "de": "Möbel nach Maß",
        "it": "Mobili su misura"
      }
    },
    {
      "id": "innenausbau",
      "names": {
        "de": "Innenausbau",
        "it": "Arredamento d'interni"
      }
    }
  ],
  "locations": [
    {
      "id": "hauptsitz-bozen",
      "names": {
        "de": "Hauptsitz Bozen",
        "it": "Sede di Bolzano"
      },
      "address": {
        "street": "Musterweg 12",
        "postalCode": "39100",
        "city": "Bozen",
        "region": "Südtirol",
        "countryCode": "IT"
      },
      "timeZone": "Europe/Rome"
    }
  ],
  "contacts": {
    "email": "info@alpenwerk.example",
    "phone": "+39 0471 000000"
  },
  "openingHours": [
    {
      "days": ["monday", "tuesday", "wednesday", "thursday"],
      "opens": "08:00",
      "closes": "17:00"
    },
    {
      "days": ["friday"],
      "opens": "08:00",
      "closes": "12:00"
    }
  ],
  "officialProfiles": [
    {
      "platform": "linkedin",
      "url": "https://www.linkedin.com/company/alpenwerk-example"
    },
    {
      "platform": "instagram",
      "url": "https://www.instagram.com/alpenwerk.example"
    }
  ]
}

Significato dei singoli campi

`schemaVersion` si riferisce alla versione del modello dati utilizzato. Se un campo viene successivamente rinominato o la struttura viene estesa, un'applicazione tecnica può riconoscere a quale schema si basa la struttura del file.

`version` si riferisce allo stato attuale del record di dati. Per le piccole imprese, spesso è sufficiente una combinazione di anno e mese. `lastUpdated` specifica la data dell'ultima modifica del contenuto nel formato univoco anno-mese-giorno.

I campi publicName e legalName separano il nome commerciale comunicato dalla ragione sociale. Questa separazione impedisce che un nome commerciale abbreviato venga accidentalmente utilizzato come nome completo dell'azienda.

La sezione delle descrizioni contiene brevi descrizioni approvate, categorizzate per lingua. Il multilinguismo va oltre la semplice correttezza linguistica della traduzione: le affermazioni devono essere coerenti in termini di contenuto in tutte le lingue.

Il servizio utilizza un identificatore stabile per ciascun servizio. Il valore "moebel-nach-mass" rimane invariato, mentre i nomi visualizzati cambiano a seconda della lingua. Ciò consente ai sistemi tecnici di identificare correttamente i nomi in tedesco e in italiano per lo stesso servizio.

Il campo "posizioni" separa il nome della posizione dall'indirizzo strutturato. Il fuso orario è particolarmente rilevante per gli orari di apertura, i dettagli degli appuntamenti o le sedi multiple.

La sezione "Contatti" include intenzionalmente solo i metodi di contatto generali. "Orari di apertura" descrive gli orari di apertura regolari. Orari di apertura speciali, festività aziendali e festività pubbliche richiedono, se necessario, un campo aggiuntivo da documentare.

La sezione officialProfiles dovrebbe contenere esclusivamente profili verificati e gestiti direttamente dall'azienda. Le directory di settore o le menzioni editoriali non sono da considerarsi profili ufficiali.

Dall'informazione distribuita alla Fonte Unica di Verità

Il file brand.json non deve essere gestito manualmente come file separato accanto al sito web. Per la tua PMI è consigliabile un'unica fonte di dati affidabile: un'unica fonte autorevole da cui attingere per alimentare il sito web, gli output strutturati e gli altri canali.

Il processo operativo si compone di sette fasi:

  • 1. Raccogli informazioni sul marchio: Verificate la presenza di discrepanze nei siti web, nei profili aziendali, negli elenchi, nelle offerte e nei documenti interni.
  • 2. Rivelate i fatti: La direzione o i responsabili del marchio decidono quali nomi, descrizioni, servizi e metodi di contatto sono vincolanti.
  • 3. Individuare la fonte centrale: Un database o un sistema di gestione dei contenuti ben curato diventa la fonte autorevole.
  • 4. Genera JSON: I dati rilasciati vengono trasferiti automaticamente o manualmente nella struttura concordata in condizioni controllate.
  • 5. Eseguire la convalida dei dati: Vengono controllati la sintassi, i campi obbligatori, i tipi di dati, gli URL e la correttezza tecnica.
  • 6. Consegnare in pubblico: Il file riceve un indirizzo HTTPS stabile e gli viene fornito un tipo di contenuto appropriato.
  • 7. Sincronizza le modifiche: I nuovi servizi, le modifiche agli orari di apertura o i trasferimenti di sede vengono aggiornati prima nella fonte centrale e poi trasferiti alle edizioni collegate.

I vantaggi economici derivanti dai dati di marca leggibili dalle macchine si basano sulla gestione centralizzata e sul controllo della spesa su più canali.

Uno studio di caso prima e dopo tratto dalla pratica delle PMI

Un esempio tipico tratto dal mio lavoro: il sito web in lingua tedesca riporta "Beratung und Planung" (Consulenza e pianificazione), il sito italiano solo "Consulenza" (Consulenza), il profilo aziendale di Google elenca "Planungsbüro" (Ufficio di pianificazione) e Instagram utilizza un nome di prodotto precedente. Inoltre, il sito web indica orari di apertura fino alle 18:00, mentre una directory aziendale indica le 17:00.

In precedenza: informazioni contrastanti provenienti da più canali

  • I nomi dei prodotti vengono riformulati a ogni pubblicazione.
  • Le traduzioni non possono essere assegnate in modo univoco allo stesso servizio.
  • Gli orari di apertura vengono modificati manualmente in diversi punti vendita.
  • Vecchi profili e documenti rimangono online inosservati.
  • I dipendenti non sanno quale descrizione sia vincolante.

In seguito: fatti resi pubblici da una fonte centrale

  • Ogni servizio riceve un identificatore stabile e nomi approvati per ciascuna lingua.
  • Il sito web e il file brand.json attingono le informazioni dallo stesso database di contenuti.
  • Gli orari di apertura vengono modificati a un certo punto e poi la modifica viene attuata in modo controllato.
  • I profili ufficiali sono documentati e regolarmente rivisti.
  • Le responsabilità e le date di modifica sono tracciabili.

Il risultato è una minore incoerenza, un minore impegno in termini di manutenzione e dichiarazioni più affidabili sul marchio . Dopo oltre 20 anni di esperienza nel branding, nello sviluppo web e nella digitalizzazione, ritengo questa chiarezza organizzativa più importante del formato dei singoli file.

Separare i file brand.json, Schema.org, llms.txt e il contenuto del sito web.

Diverse edizioni possono utilizzare le stesse informazioni sul marchio, ma servire a scopi diversi. Nessuno dei seguenti livelli sostituisce gli altri.

I contenuti visibili del sito web informano e guidano.

I contenuti visibili di un sito web sono scritti per le persone. Spiegano le connessioni, rispondono alle domande, comunicano il posizionamento e indirizzano verso un metodo di contatto appropriato. Pertanto, un file brand.json non dovrebbe comportare una descrizione superficiale o incomprensibile dei servizi o delle sedi del sito web.

Il file brand.json raccoglie le informazioni approvate relative al marchio.

Il file brand.json fornisce un set di dati compatto sul marchio. Il formato è adatto per ulteriori elaborazioni controllate, applicazioni interne e integrazioni tecniche. I sistemi che effettivamente recuperano o interpretano il file dipendono dalla loro implementazione.

Schema.org descrive le entità nel contesto di un sito web.

I dati strutturati secondo Schema.org vengono in genere incorporati direttamente nei siti web, spesso in formato JSON-LD. Schema.org è un'iniziativa gestita dalla comunità e fornisce tipi e proprietà per organizzazioni, indirizzi, posizioni, punti di contatto, offerte e servizi.

Schema.org ha un vocabolario definito. Un file brand.json, d'altra parte, può utilizzare il proprio schema di dati documentato. Entrambi gli output possono essere generati dalla stessa fonte centrale, ma non sono automaticamente intercambiabili.

Il file llms.txt raccoglie note e collegamenti ai contenuti.

Il 3 settembre 2024 Jeremy Howard ha pubblicato il file llms.txt , una proposta per un file Markdown contenente informazioni di base concise, note e link a contenuti aggiuntivi. Il file proposto funge principalmente da guida per i modelli linguistici e non è un database completo di informazioni sui marchi.

Una spiegazione più dettagliata dei limiti e delle possibili applicazioni è disponibile nel nostro articolo su llms.txt per le PMI.

Manutenzione e governance: chi si occupa di mantenere aggiornate le informazioni sul marchio?

Un file brand.json richiede una persona responsabile. Nelle piccole imprese, non è necessario un responsabile dati dedicato. Spesso, l'approvazione tecnica viene gestita dalla direzione, da un membro del team marketing o dall'amministratore del sito web.

Una chiara suddivisione dei ruoli prevede quattro compiti:

  • Responsabilità professionale: Chi decide quali informazioni relative a un marchio sono corrette e approvate?
  • Responsabilità tecnica: Chi verifica la generazione, la convalida dei dati e la pubblicazione?
  • Responsabilità linguistica: Chi garantisce che i termini multilingue abbiano lo stesso significato?
  • Responsabilità di controllo: Chi confronta regolarmente la fonte centrale con il sito web e i profili ufficiali?

I motivi tipici per cui è necessario un aggiornamento includono un trasferimento di sede, nuovi recapiti, orari di apertura modificati, un rebranding, servizi nuovi o interrotti, l'apertura di una nuova sede e nuove versioni linguistiche. Tali modifiche dovrebbero essere apportate prima nella fonte principale e poi implementate sui canali collegati.

Versioning senza inutili complicazioni

Per la maggior parte delle PMI, un semplice sistema di versioning è sufficiente. È sufficiente utilizzare un campo per la versione della struttura, un campo per lo stato dei dati e una data di modifica univoca. Per le modifiche significative, è consigliabile anche un breve registro interno delle modifiche.

Un nuovo logo con campi invariati potrebbe richiedere solo una nuova versione dei dati. Tuttavia, una struttura modificata con nuovi campi obbligatori richiede una nuova versione dello schema. Questa distinzione aiuta le applicazioni connesse a elaborare correttamente le modifiche strutturali.

Pubblicazione tecnica del file brand.json

Prima della pubblicazione, non basta verificare che il file venga visualizzato correttamente nel browser. Un file brand.json utilizzabile richiede una consegna tecnica affidabile e una revisione professionale.

Consegna tecnica

  • Indirizzo HTTPS stabile: per esempio https://www.deine-domain.it/brand.json.
  • Tipologia di contenuto adatta: preferibilmente application / json.
  • Sintassi JSON valida: Nessuna virgola mancante, virgolette non chiuse o commenti.
  • URL accessibili: Verificate la presenza di errori sul sito web, sulle pagine relative alle sedi e sui profili ufficiali.

Revisione dei contenuti

  • Campi obbligatori definiti: Definisci internamente quali dettagli non devono mai mancare.
  • Dati attuali: La data di modifica e il contenuto devono corrispondere.
  • Accordo sui contenuti: Confronta nomi, servizi e recapiti con le informazioni visibili.
  • Nessun dato personale non necessario: Pubblica solo ciò che è di pubblico interesse.
  • Schema documentato: Annotare i nomi dei campi, i tipi di dati e la logica del linguaggio per future estensioni.

Un controllo di sintassi determina se il JSON può essere letto tecnicamente. Un controllo di conformità aziendale chiarisce se il contenuto è corretto e aggiornato. Entrambi fanno parte della convalida dei dati. Per i controlli JSON-LD correlati, la nostra guida alla convalida dello schema spiega perché i controlli tecnici e di contenuto dovrebbero essere considerati separatamente.

Come btlabs Core fornisce centralmente i dati del marchio

Noi di Berger+Team consideriamo il branding, il sito web e i risultati tecnici come un sistema integrato. Informazioni quali il nostro indirizzo a Bolzano, i recapiti e le descrizioni dei servizi di branding, web design, marketing online, integrazione AI e consulenza non devono essere elencate separatamente in ogni documento. Tali informazioni richiedono una base di contenuti comune.

btlabs Core è un repository di contenuti centralizzato da cui è possibile generare contenuti per siti web e output leggibili automaticamente, come ad esempio un file brand.json. I contenuti multilingue vengono gestiti in modo strutturato per garantire la coerenza e la pertinenza delle diverse versioni linguistiche. Ciò riduce la duplicazione degli interventi di manutenzione e le incongruenze.

Canali aggiuntivi come negozi online, app, funzioni di prenotazione o agenti basati sull'intelligenza artificiale rappresentano possibili fasi di espansione e non sono inclusi di serie in ogni implementazione. Il fattore determinante è rappresentato dalle esigenze specifiche dell'azienda. Nella pagina dedicata ai siti web predisposti per l'IA con btlabs Core, spieghiamo in dettaglio le basi tecniche e i potenziali costi.

Anche per i dati di marca dell'IA gestiti centralmente, vale quanto segue: nessun sistema può obbligare un modello linguistico a menzionare un marchio o a citare una fonte specifica. Una solida base di dati migliora le condizioni per una corretta elaborazione, ma non sostituisce contenuti credibili, notorietà del marchio, segnali di fiducia esterni o un posizionamento chiaro.

Domande e risposte su brand.json

Dove deve essere memorizzato il file brand.json?

Comunicare un indirizzo stabile nella directory principale del proprio dominio è semplice, ad esempio /brand.json . Fondamentalmente, ciò richiede un URL HTTPS persistente, accessibilità pubblica e una corretta trasmissione in formato JSON.

Ci sono campi obbligatori nel file brand.json?

No, al momento non esiste uno standard web brand.json universalmente vincolante con campi obbligatori. Per la tua azienda, definisci almeno i seguenti campi come obbligatori interni: nome pubblico, ragione sociale, descrizione, servizi, informazioni di contatto, sede, lingue, versione e data di modifica.

Come posso rappresentare accuratamente il multilinguismo?

Utilizza codici linguistici inequivocabili come "de" e "it" e assegna le traduzioni allo stesso identificatore stabile di prestazioni o posizione. Verifica non solo la lingua, ma anche l'equivalenza tecnica delle affermazioni.

Un file brand.json può contenere dati personali?

Tecnicamente è possibile, ma è necessario agire con cautela da un punto di vista professionale e legale. È preferibile pubblicare informazioni di contatto aziendali generali e chiarire preventivamente se i dati personali siano necessari, autorizzati e consentiti dalla normativa sulla protezione dei dati.

Con quale frequenza è necessario aggiornare il file?

Aggiorna il file brand.json ogni volta che si verificano modifiche rilevanti alle informazioni in esso contenute. Inoltre, consiglio di confrontarlo con il tuo sito web, i profili aziendali e i dati anagrafici interni almeno trimestralmente.

Come posso convalidare un file brand.json?

Innanzitutto, verifica la sintassi JSON con un validatore appropriato o un test automatizzato. Successivamente, esegui un controllo funzionale di nomi, URL, numeri di telefono, versioni linguistiche, orari di apertura e campi obbligatori confrontandoli con la fonte dati centrale.

Il file brand.json sostituisce il markup Schema.org?

No. Il markup Schema.org descrive i contenuti e le entità all'interno di un sito web utilizzando un vocabolario gestito dalla community, mentre un file brand.json fornisce un profilo del marchio separato. Entrambi i file di output dovrebbero utilizzare gli stessi dati di origine condivisi.

Un file brand.json è equivalente a un file llms.txt?

No. Un file brand.json organizza le informazioni sul marchio in formato JSON, mentre llms.txt è un file Markdown consigliato per l'orientamento e il collegamento a contenuti importanti. I due file possono integrarsi a vicenda, ma servono a scopi diversi.

I sistemi di intelligenza artificiale tengono automaticamente conto del file brand.json?

No, non è dimostrato né si può presumere che tutti i sistemi di intelligenza artificiale prendano automaticamente in considerazione i dati. L'utilizzo effettivo dipende da crawler, motori di ricerca, applicazioni e integrazioni specifiche. Pertanto, i contenuti visibili del sito web e i dati strutturati consolidati rimangono essenziali.

Qual è il primo passo più importante per una PMI?

Non iniziate programmando il file, ma rendendo pubbliche le informazioni vincolanti del vostro marchio. Se il nome, i servizi, le sedi e i metodi di contatto non sono internamente coerenti, un file brand.json rende semplicemente leggibili automaticamente le incongruenze esistenti.

Conclusione: prima chiarire i dati relativi al marchio, poi generare il file JSON.

Un file brand.json è utile quando proviene da un'unica fonte affidabile e ben gestita. Questo file rende le informazioni sul marchio compatte, verificabili e tecnicamente riutilizzabili. Per le PMI, ciò si traduce in una minore duplicazione degli aggiornamenti, contenuti multilingue più coerenti e una base più affidabile per siti web, servizi digitali e applicazioni di intelligenza artificiale.

La sequenza logica è: accertare i fatti, chiarire le responsabilità, individuare una fonte centrale, convalidare il JSON, renderlo pubblico e monitorarlo regolarmente. Senza dati di origine vincolanti, anche un file brand.json tecnicamente corretto non può garantire la coerenza.

Swell

  1. brand.json – gestore di brand e documentazione di progetto open-source
  2. Schema.org: Organizzazione
  3. Jeremy Howard: Il file /llms.txt (2024)
Florian Berger
Bloggerei.de