Een brand.json-bestand op uw website biedt juridisch bindende merkinformatie in de vorm van gestructureerde, machineleesbare merkgegevens. Het bestand kan namen, diensten, locaties, talen, contactmethoden, openingstijden en officiële profielen vanuit een centrale bron leveren. Een brand.json-bestand verbetert de technische uniciteit, maar garandeert geen vermeldingen of citaties door AI-systemen zoals ChatGPT, Gemini, Perplexity en andere systemen.
Voor een mkb-onderneming ligt het voordeel niet in het extra bestandsformaat, maar in een bindend antwoord op de vraag: welke informatie over het bedrijf is correct en waar wordt deze informatie bewaard?
Een brand.json-bestand vervangt geen gebruiksvriendelijke website. Het bestand is een aanvullende, machinaal leesbare uitvoer van dezelfde openbaar beschikbare merkinformatie.
brand.json voor uw website: taken en beperkingen
Een brand.json-bestand bundelt belangrijke bedrijfs- en merkgegevens in JSON , een tekstgebaseerd formaat voor gegevensuitwisseling. Mensen kunnen het bestand lezen; belangrijker nog, het kan worden verwerkt door websites, applicaties, interfaces, zoekmachines en AI-gestuurde diensten.
De term brand.json verwijst momenteel niet naar een verplichte webstandaard die is gepubliceerd door een erkende standaardisatie-instantie. Een open-source merkbeheersysteem gebruikt bijvoorbeeld dezelfde naam. De structuur en interpretatie van een brand.json-bestand hangen echter af van de specifieke technische integratie. Daarom kunnen verschillende systemen verschillende veldnamen en structuren gebruiken.
Gebruik daarom geen sjabloon zonder het eerst te controleren. Definieer een duidelijk schema, documenteer de velden en zorg voor consistentie van de gegevens. Een syntactisch correct bestand met onjuiste openingstijden is feitelijk nog steeds onjuist.
Welke merkfeiten horen in het dossier thuis?
In mijn werk met door de eigenaar geleide bedrijven kom ik vaak hetzelfde probleem tegen: de bedrijfsnaam wordt anders gespeld op de website dan in het Google Bedrijfsprofiel, de aangeboden diensten worden niet consistent benoemd in het Duits en Italiaans, en er staat nog steeds een oud telefoonnummer in een socialmediaprofiel. Een brand.json-bestand zou deze feiten moeten samenvoegen, vooral waar dergelijke discrepanties problematisch zijn.
Identiteit en positionering
- Publieke merknaam: De naam waaronder het bedrijf communiceert en waarop gezocht wordt.
- Wettelijke naam: De volledige bedrijfsnaam voor ondubbelzinnige identificatie.
- Korte omschrijving: Een objectieve beschrijving van het bedrijf, de doelgroep en het aanbod.
- diensten: Goedgekeurde servicenamen met korte toelichtingen en stabiele identificatiecodes.
- Talen: Talen waarin daadwerkelijk advies, verkoop of ondersteuning wordt geboden.
Locaties, bereikbaarheid en onderhoud
- Locaties: Volledige adressen en, indien van toepassing, geografische verantwoordelijkheidsgebieden.
- Contactmethoden: Algemeen e-mailadres, telefoonnummer en officiële website.
- Openingstijden: Vaste tijden met duidelijk omschreven dagen van de week en tijdzone.
- Officiële profielen: Geverifieerde bedrijfsprofielen op relevante platformen.
- Versie en datum van wijziging: Informatie over versiebeheer en de laatste technische beoordeling.
Persoonsgegevens mogen alleen in het openbare bestand worden opgenomen als publicatie noodzakelijk is, intern is goedgekeurd en wettelijk is toegestaan. Voor veel mkb-bedrijven is een algemeen e-mailadres zoals info@company.it voldoende . Publiceer uit voorzorg geen privé mobiele nummers, interne doorkiesnummers of persoonlijke e-mailadressen.
Merkgegevens in JSON-formaat: voorbeeld van een Zuid-Tiroolse mkb-onderneming.
Het volgende voorbeeld beschrijft een fictief ambachtelijk bedrijf uit Zuid-Tirol. De structuur is opzettelijk compact. Het is een mogelijke sjabloon, maar geen universeel toepasbaar brand.json-schema.
{
"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"
}
]
}Wat de afzonderlijke velden betekenen
`schemaVersion` verwijst naar de versie van het gebruikte datamodel. Als een veld later wordt hernoemd of de structuur wordt uitgebreid, kan een technische applicatie herkennen volgens welk schema het bestand is gestructureerd.
`version` verwijst naar de huidige status van het gegevensrecord. Een combinatie van jaar en maand is vaak voldoende voor kleine bedrijven. `lastUpdated` specificeert de datum van de laatste inhoudswijziging in het unieke formaat jaar-maand-dag.
De publieke naam en de wettelijke naam scheiden de gecommuniceerde merknaam van de officiële bedrijfsnaam. Deze scheiding voorkomt dat een korte merknaam per ongeluk als volledige bedrijfsnaam wordt gebruikt.
De beschrijvingensectie bevat goedgekeurde korte beschrijvingen, gecategoriseerd per taal. Meertaligheid omvat meer dan alleen een taalkundig correcte vertaling: de teksten moeten inhoudelijk consistent zijn in alle talen.
De dienst maakt gebruik van een stabiele identificatiecode voor elke dienst. De waarde "moebel-nach-mass" blijft hetzelfde, terwijl de zichtbare namen veranderen afhankelijk van de taal. Hierdoor kunnen technische systemen de Duitse en Italiaanse namen voor dezelfde dienst correct herkennen.
Het veld "locaties" scheidt de locatienaam van het gestructureerde adres. Een tijdzone is met name relevant voor openingstijden, afspraakgegevens of meerdere locaties.
Het gedeelte 'contactgegevens' bevat bewust alleen algemene contactmethoden. 'Openingstijden' beschrijft de reguliere openingstijden. Voor afwijkende openingstijden, bedrijfsfeestdagen en nationale feestdagen is, indien nodig, een apart veld vereist.
OfficialProfiles mag alleen geverifieerde profielen bevatten die door het bedrijf zelf worden beheerd. Branchegidsen of vermeldingen in tijdschriften gelden niet als officiële profielen.
Van verspreide informatie naar de enige bron van waarheid.
Het brand.json-bestand mag niet handmatig als apart bestand naast de website worden beheerd. Voor uw mkb-onderneming is één betrouwbare bron van informatie aan te raden : één gezaghebbende gegevensbron van waaruit de website, gestructureerde output en andere kanalen worden gevoed.
Het operationele proces bestaat uit zeven stappen:
- 1. Verzamel merkinformatie: Controleer websites, bedrijfsprofielen, gidsen, aanbiedingen en interne documenten op onregelmatigheden.
- 2. Maak de feiten openbaar: Het management of de merkmanagers bepalen welke namen, beschrijvingen, diensten en contactmethoden bindend zijn.
- 3. Bepaal de centrale bron: Een database of een goed onderhouden contentmanagementsysteem wordt de gezaghebbende bron.
- 4. JSON genereren: De vrijgegeven gegevens worden automatisch of handmatig onder gecontroleerde omstandigheden overgebracht naar de overeengekomen structuur.
- 5. Voer gegevensvalidatie uit: De syntaxis, verplichte velden, gegevenstypen, URL's en technische nauwkeurigheid worden gecontroleerd.
- 6. Openbaar overhandigen: Het bestand krijgt een stabiel HTTPS-adres en een geschikt inhoudstype.
- 7. Wijzigingen synchroniseren: Nieuwe diensten, gewijzigde openingstijden of een verhuizing worden eerst in de centrale bron bijgewerkt en vervolgens doorgevoerd naar de gekoppelde edities.
De economische voordelen van machinaal leesbare merkgegevens vloeien voort uit gecentraliseerd onderhoud en gecontroleerde uitgaven via meerdere kanalen.
Een casestudy met voor- en na-vergelijkingen uit de praktijk van het MKB.
Een typisch voorbeeld uit mijn werk: de Duitstalige website vermeldt "Beratung und Planung" (Advies en Planning), de Italiaanse site alleen "Consulenza" (Advies), het Google-bedrijfsprofiel vermeldt "Planungsbüro" (Planbureau) en Instagram gebruikt een eerdere productnaam. Bovendien vermeldt de website openingstijden tot 18 uur, terwijl een bedrijvengids 17 uur aangeeft.
Eerder: tegenstrijdige informatie via meerdere kanalen.
- Productnamen worden bij elke publicatie aangepast.
- Vertalingen kunnen niet eenduidig aan dezelfde dienst worden toegewezen.
- De openingstijden worden op verschillende locaties handmatig aangepast.
- Oude profielen en documenten blijven online onopgemerkt.
- Werknemers weten niet welke beschrijving bindend is.
Vervolgens: vrijgegeven feiten afkomstig van een centrale bron.
- Elke dienst ontvangt een stabiele identificatiecode en goedgekeurde namen per taal.
- De website en het brand.json-bestand halen hun informatie uit dezelfde contentdatabase.
- De openingstijden worden op een bepaald moment gewijzigd en vervolgens op een gecontroleerde manier toegepast.
- Officiële profielen worden gedocumenteerd en regelmatig gecontroleerd.
- Verantwoordelijkheden en wijzigingsdata zijn traceerbaar.
Het resultaat is minder inconsistenties, minder onderhoud en betrouwbaardere uitspraken over het merk . Na meer dan 20 jaar ervaring in branding, webdevelopment en digitalisering, beschouw ik deze organisatorische duidelijkheid als belangrijker dan het individuele bestandsformaat.
Scheid de bestanden brand.json, Schema.org, llms.txt en de websitecontent.
Meerdere edities kunnen dezelfde merkinformatie gebruiken, maar dienen verschillende doelen. Geen van de volgende niveaus vervangt de andere.
Zichtbare websitecontent informeert en begeleidt.
Zichtbare websitecontent is geschreven voor mensen. Het legt verbanden uit, beantwoordt vragen, brengt de positionering over en leidt naar een geschikte contactmethode. Daarom mag een brand.json-bestand er niet toe leiden dat diensten of locaties op de website slechts beknopt of onbegrijpelijk worden beschreven.
brand.json bundelt goedgekeurde merkinformatie.
Het bestand brand.json biedt een compacte dataset over het merk. Het formaat is geschikt voor gecontroleerde verdere verwerking, interne applicaties en technische integraties. Welke systemen het bestand daadwerkelijk ophalen of interpreteren, hangt af van de implementatie.
Schema.org beschrijft entiteiten in de context van een website.
Gestructureerde data volgens Schema.org wordt doorgaans direct in websites ingebed, vaak als JSON-LD. Schema.org is een initiatief dat door de community wordt onderhouden en biedt typen en eigenschappen voor organisaties, adressen, locaties, contactpunten, aanbiedingen en diensten.
Schema.org heeft een gedefinieerde terminologie. Een brand.json-bestand daarentegen kan een eigen, gedocumenteerd dataschema gebruiken. Beide outputs kunnen vanuit dezelfde centrale bron worden gegenereerd, maar ze zijn niet automatisch uitwisselbaar.
llms.txt beheert notities en links naar relevante content.
Jeremy Howard publiceerde llms.txt op 3 september 2024 als een voorstel voor een Markdown-bestand met beknopte achtergrondinformatie, aantekeningen en links naar verdere inhoud. Het voorgestelde bestand dient voornamelijk als leidraad voor taalmodellen en is geen uitgebreide database met merkfeiten.
Een meer gedetailleerde uitleg van de beperkingen en mogelijke toepassingen vindt u in ons artikel over llms.txt voor het mkb.
Onderhoud en beheer: Wie zorgt ervoor dat de merkgegevens actueel blijven?
Een brand.json-bestand vereist een verantwoordelijke persoon. In kleine bedrijven is een speciale datamanager niet nodig. Vaak wordt de technische goedkeuring verleend door het management, een lid van het marketingteam of de websitebeheerder.
Een duidelijke taakverdeling omvat vier taken:
- Professionele verantwoordelijkheid: Wie bepaalt welke merkfeiten juist en goedgekeurd zijn?
- Technische verantwoordelijkheid: Wie controleert de generatie, gegevensvalidatie en publicatie?
- Taalkundige verantwoordelijkheid: Wie zorgt ervoor dat meertalige termen dezelfde betekenis overbrengen?
- Verantwoordelijkheid voor de controle: Wie vergelijkt de centrale bron regelmatig met de website en officiële profielen?
Typische aanleidingen voor updates zijn onder andere een verhuizing, nieuwe contactgegevens, gewijzigde openingstijden, een rebranding, nieuwe of stopgezette diensten, een extra vestiging en nieuwe taalversies. Dergelijke wijzigingen moeten eerst in de centrale bron van informatie worden doorgevoerd en vervolgens worden uitgerold naar de gekoppelde kanalen.
Versiebeheer zonder onnodige complexiteit
Voor de meeste mkb-bedrijven volstaat eenvoudige versiebeheer. Gebruik één veld voor de structuurversie, één veld voor de gegevensstatus en een unieke wijzigingsdatum. Bij belangrijke wijzigingen is een kort intern wijzigingslogboek ook aan te raden.
Een nieuw logo met ongewijzigde velden vereist mogelijk alleen een nieuwe dataversie. Een aangepaste structuur met nieuwe verplichte velden vereist echter een nieuwe schemaversie. Dit onderscheid helpt gekoppelde applicaties om structurele wijzigingen correct te verwerken.
Technische publicatie van het brand.json-bestand
Voordat je publiceert, moet je niet alleen controleren of het bestand in de browser verschijnt. Een bruikbaar brand.json-bestand vereist een betrouwbare technische uitvoering en een professionele beoordeling.
Technische levering
- Stabiel HTTPS-adres: bij voorbeeld https://www.deine-domain.it/brand.json.
- Geschikt contenttype: bij voorkeur application / json.
- Geldige JSON-syntaxis: Geen ontbrekende komma's, openstaande aanhalingstekens of opmerkingen.
- Toegankelijke URL's: Controleer de website, locatiepagina's en officiële profielen op fouten.
Inhoudelijke beoordeling
- Gedefinieerde verplichte velden: Bepaal intern welke details absoluut niet mogen ontbreken.
- Actuele gegevens: De wijzigingsdatum en de inhoud moeten overeenkomen.
- Inhoudelijke overeenkomst: Vergelijk namen, diensten en contactgegevens met de zichtbare informatie.
- Geen onnodige persoonlijke gegevens: Publiceer alleen wat publiekelijk nodig is.
- Gedocumenteerd schema: Noteer veldnamen, gegevenstypen en taallogica voor latere uitbreidingen.
Een syntaxcontrole bepaalt of de JSON technisch leesbaar is. Een zakelijke controle verduidelijkt of de inhoud correct en actueel is. Beide maken deel uit van gegevensvalidatie. Voor gerelateerde JSON-LD-controles laat onze handleiding voor schemavalidatie zien waarom technische en inhoudelijke controles afzonderlijk moeten worden beschouwd.
Hoe btlabs Core centraal merkgegevens levert
Bij Berger+Team beschouwen we branding, website en technische output als een geïntegreerd systeem. Informatie zoals ons adres in Bolzano, contactgegevens en beschrijvingen van diensten voor branding, webdesign, online marketing, AI-integratie en consultancy hoeven niet in elk document afzonderlijk te worden vermeld. Dergelijke informatie vereist een gemeenschappelijke basis.
btlabs Core is een centrale contentrepository van waaruit websitecontent en machineleesbare output, zoals een brand.json-bestand, kunnen worden gegenereerd. Meertalige content wordt op een gestructureerde manier beheerd om ervoor te zorgen dat de verschillende taalversies consistent en relevant zijn. Dit vermindert dubbel onderhoud en inconsistenties.
Extra kanalen zoals webshops, apps, boekingsfuncties of AI-agenten zijn mogelijke uitbreidingsmogelijkheden en maken niet standaard deel uit van elke implementatie. De specifieke behoeften van het bedrijf zijn doorslaggevend. Op de pagina over AI-ready websites met btlabs Core leggen we de technische basis en de mogelijke kosten in detail uit.
Zelfs voor centraal beheerde AI-merkdata geldt het volgende: geen enkel systeem kan een taalmodel dwingen om een merk te noemen of een specifieke bron te citeren. Een duidelijke datafundament verbetert de voorwaarden voor een correcte verwerking. Het vervangt echter geen geloofwaardige content, merkbekendheid, externe vertrouwenssignalen of een heldere positionering.
Vragen en antwoorden over brand.json
Waar moet het brand.json-bestand worden opgeslagen?
Een stabiel adres in de hoofdmap van uw domein is gemakkelijk te communiceren, bijvoorbeeld /brand.json . Cruciaal is dat dit een permanente HTTPS-URL vereist, publieke toegankelijkheid en correcte levering als JSON.
Zijn er verplichte velden voor een brand.json-bestand?
Nee, er bestaat momenteel geen universeel bindende brand.json-webstandaard met verplichte velden. Definieer voor uw bedrijf ten minste de volgende velden als interne verplichte velden: publieke naam, wettelijke naam, omschrijving, diensten, contactgegevens, locatie, talen, versie en wijzigingsdatum.
Hoe kan ik meertaligheid op een accurate manier weergeven?
Gebruik eenduidige taalcodes zoals "de" en "it" en wijs vertalingen toe aan dezelfde stabiele prestatie- of locatie-identificatiecode. Controleer niet alleen de taal, maar ook de technische equivalentie van de verklaringen.
Is het toegestaan dat een brand.json-bestand persoonsgegevens bevat?
Technisch gezien is dit mogelijk, maar vanuit professioneel en juridisch oogpunt moet u voorzichtig zijn. Publiceer bij voorkeur algemene zakelijke contactgegevens en maak vooraf duidelijk of persoonsgegevens noodzakelijk, geautoriseerd en toegestaan zijn volgens de wetgeving inzake gegevensbescherming.
Hoe vaak moet het bestand worden bijgewerkt?
Werk het brand.json-bestand bij zodra er een relevante wijziging is in de informatie die het bevat. Daarnaast raad ik aan om het minstens elk kwartaal te vergelijken met uw website, bedrijfsprofielen en interne stamgegevens.
Hoe kan ik een brand.json-bestand valideren?
Controleer eerst de JSON-syntaxis met een geschikte validator of geautomatiseerde test. Voer vervolgens een functionele controle uit van namen, URL's, telefoonnummers, taalversies, openingstijden en verplichte velden aan de hand van de centrale gegevensbron.
Vervangt het brand.json-bestand de Schema.org-markup?
Nee. Schema.org-markup beschrijft de inhoud en entiteiten binnen een website met behulp van een door de community beheerde vocabulaire, terwijl een brand.json-bestand een apart merkprofiel biedt. Beide outputs moeten dezelfde gedeelde brongegevens gebruiken.
Is een brand.json hetzelfde als een llms.txt?
Nee. Een brand.json-bestand organiseert merkinformatie als JSON, terwijl llms.txt een aanbevolen Markdown-bestand is voor oriëntatie en het linken naar belangrijke content. De twee bestanden kunnen elkaar aanvullen, maar ze dienen verschillende doelen.
Houden AI-systemen automatisch rekening met een brand.json-bestand?
Nee, automatische verwerking door alle AI-systemen is noch bewezen, noch kan dit worden aangenomen. Het daadwerkelijke gebruik is afhankelijk van crawlers, zoekmachines, applicaties en specifieke integraties. Daarom blijven zichtbare websitecontent en vastgestelde gestructureerde data essentieel.
Wat is de belangrijkste eerste stap voor een mkb-bedrijf?
Begin niet met het programmeren van het bestand, maar met het vrijgeven van uw bindende merkgegevens. Als de naam, diensten, locaties en contactmethoden intern niet consistent zijn, maakt een brand.json-bestand de bestaande inconsistenties eenvoudigweg machineleesbaar.
Conclusie: Verduidelijk eerst de merkfeiten en genereer vervolgens de JSON-output.
Een brand.json-bestand is nuttig wanneer het afkomstig is van een goed onderhouden, betrouwbare bron. Dit bestand maakt bindende merkinformatie compact, verifieerbaar en technisch herbruikbaar. Voor mkb-bedrijven betekent dit minder dubbel onderhoud, consistentere meertalige content en een betrouwbaardere basis voor websites, digitale diensten en AI-toepassingen.
De logische volgorde is: feiten vaststellen, verantwoordelijkheden verduidelijken, een centrale bron bepalen, de JSON valideren, openbaar maken en regelmatig controleren. Zonder bindende brongegevens kan zelfs een technisch correct brand.json-bestand geen consistentie garanderen.
