Eine brand.json auf Deiner Website stellt verbindliche Markenfakten als strukturierte, maschinenlesbare Markendaten bereit. Die Datei kann Namen, Leistungen, Standorte, Sprachen, Kontaktwege, Öffnungszeiten und offizielle Profile aus einer zentralen Quelle ausliefern. Eine brand.json verbessert die technische Eindeutigkeit, bietet aber keine Garantie auf KI-Zitate oder Erwähnungen durch ChatGPT, Gemini, Perplexity und andere Systeme.
Für ein KMU liegt der Nutzen nicht im zusätzlichen Dateiformat, sondern in einer verbindlichen Antwort auf die Frage: Welche Angaben über das Unternehmen sind korrekt und wo werden diese Angaben gepflegt?
Eine brand.json ersetzt keine verständliche Website. Die Datei ist eine zusätzliche, maschinenlesbare Ausgabe derselben freigegebenen Markenfakten.
brand.json für Deine Website: Aufgaben und Grenzen
Eine brand.json bündelt zentrale Unternehmens- und Markendaten in JSON, einem textbasierten Format für den Datenaustausch. Menschen können die Datei lesen; vor allem lässt sie sich von Websites, Anwendungen, Schnittstellen, Suchsystemen und KI-gestützten Diensten verarbeiten.
Der Begriff brand.json bezeichnet derzeit keinen verpflichtenden, von einem etablierten Standardisierungsgremium veröffentlichten Webstandard. Ein quelloffener Markenmanager verwendet beispielsweise denselben Namen. Aufbau und Interpretation einer brand.json hängen jedoch von der jeweiligen technischen Integration ab. Unterschiedliche Systeme können deshalb verschiedene Feldnamen und Strukturen verwenden.
Übernimm eine Vorlage daher nicht ungeprüft. Definiere ein verständliches Schema, dokumentiere die Felder und halte die Daten konsistent. Eine syntaktisch valide Datei mit falschen Öffnungszeiten bleibt inhaltlich fehlerhaft.
Welche Markenfakten in die Datei gehören
In meiner Arbeit mit inhabergeführten Betrieben sehe ich häufig denselben Ausgangspunkt: Der Firmenname wird auf der Website anders geschrieben als im Google-Unternehmensprofil, Leistungen heißen auf Deutsch und Italienisch nicht einheitlich und eine alte Telefonnummer bleibt in einem Social-Media-Profil gespeichert. Eine brand.json sollte jene Fakten bündeln, bei denen solche Widersprüche besonders problematisch sind.
Identität und Positionierung
- Öffentlicher Markenname: der Name, unter dem das Unternehmen kommuniziert und gesucht wird.
- Rechtlicher Name: die vollständige Firmenbezeichnung für die eindeutige Zuordnung.
- Kurzbeschreibung: eine sachliche Beschreibung des Betriebs, seiner Zielgruppe und seines Angebots.
- Leistungen: freigegebene Leistungsnamen mit kurzen Erklärungen und stabilen Kennungen.
- Sprachen: Sprachen, in denen Beratung, Verkauf oder Betreuung tatsächlich angeboten werden.
Standorte, Erreichbarkeit und Pflege
- Standorte: vollständige Anschriften sowie gegebenenfalls geografische Zuständigkeiten.
- Kontaktwege: allgemeine E-Mail-Adresse, Telefonnummer und offizielle Website.
- Öffnungszeiten: reguläre Zeiten mit eindeutigen Wochentagen und Zeitzone.
- Offizielle Profile: bestätigte Unternehmensprofile auf relevanten Plattformen.
- Version und Änderungsdatum: Angaben zur Versionierung und zur letzten fachlichen Prüfung.
Personenbezogene Daten gehören nur dann in die öffentliche Datei, wenn die Veröffentlichung notwendig, intern freigegeben und rechtlich geklärt ist. Für viele KMU reicht eine allgemeine Adresse wie info@unternehmen.it. Private Mobilnummern, interne Durchwahlen oder persönliche E-Mail-Adressen solltest Du nicht vorsorglich veröffentlichen.
Markendaten im JSON-Format: Beispiel für ein Südtiroler KMU
Das folgende Beispiel beschreibt einen fiktiven Handwerksbetrieb aus Südtirol. Die Struktur ist bewusst kompakt. Sie ist eine mögliche Vorlage, aber kein allgemein verbindliches 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"
}
]
}Was die einzelnen Felder bedeuten
schemaVersion bezeichnet die Version des verwendeten Datenmodells. Wenn später ein Feld umbenannt oder die Struktur erweitert wird, kann eine technische Anwendung erkennen, nach welchem Schema die Datei aufgebaut ist.
version bezeichnet den fachlichen Stand des Datensatzes. Eine Kombination aus Jahr und Monat ist für kleine Unternehmen häufig ausreichend. lastUpdated nennt das Datum der letzten inhaltlichen Änderung im eindeutigen Format Jahr-Monat-Tag.
publicName und legalName trennen den kommunizierten Markennamen von der rechtlichen Firmenbezeichnung. Diese Trennung verhindert, dass ein kurzer Markenname versehentlich als vollständige Firmenbezeichnung ausgegeben wird.
descriptions enthält freigegebene Kurzbeschreibungen nach Sprachcode. Mehrsprachigkeit umfasst dabei mehr als eine sprachlich korrekte Übersetzung: Die Aussagen müssen in allen Sprachen fachlich übereinstimmen.
services verwendet für jede Leistung eine stabile Kennung. Der Wert moebel-nach-mass bleibt gleich, während die sichtbaren Namen je nach Sprache wechseln. Technische Systeme können dadurch die deutsch- und italienischsprachige Bezeichnung derselben Leistung zuordnen.
locations trennt die Standortbezeichnung von der strukturierten Anschrift. Eine Zeitzone ist besonders bei Öffnungszeiten, Terminangaben oder mehreren Standorten relevant.
contacts enthält bewusst nur allgemeine Kontaktwege. openingHours beschreibt die regulären Zeiten. Sonderöffnungszeiten, Betriebsferien und Feiertage benötigen bei Bedarf ein zusätzliches, dokumentiertes Feld.
officialProfiles sollte ausschließlich bestätigte Profile enthalten, die vom Unternehmen selbst betrieben werden. Branchenverzeichnisse oder redaktionelle Erwähnungen sind keine offiziellen Profile.
Von verteilten Angaben zur Single Source of Truth
Die brand.json sollte nicht als weitere Datei manuell neben der Website gepflegt werden. Sinnvoll ist eine Single Source of Truth für Dein KMU: eine verbindliche Datenquelle, aus der Website, strukturierte Ausgaben und weitere Kanäle gespeist werden.
Der operative Ablauf besteht aus sieben Schritten:
- 1. Markenfakten sammeln: Website, Unternehmensprofile, Verzeichnisse, Angebote und interne Dokumente auf abweichende Angaben prüfen.
- 2. Fakten freigeben: Geschäftsführung oder Markenverantwortliche entscheiden, welche Namen, Beschreibungen, Leistungen und Kontaktwege verbindlich sind.
- 3. Zentrale Quelle bestimmen: Eine Datenbank oder ein gepflegtes Inhaltssystem wird zur maßgeblichen Quelle.
- 4. JSON erzeugen: Die freigegebenen Daten werden automatisiert oder kontrolliert manuell in die vereinbarte Struktur überführt.
- 5. Datenvalidierung durchführen: Syntax, Pflichtfelder, Datentypen, URLs und fachliche Richtigkeit werden geprüft.
- 6. Öffentlich ausliefern: Die Datei erhält eine stabile HTTPS-Adresse und wird mit einem passenden Content-Type bereitgestellt.
- 7. Änderungen synchronisieren: Neue Leistungen, geänderte Öffnungszeiten oder ein Umzug werden zuerst in der zentralen Quelle aktualisiert und danach in die angebundenen Ausgaben übernommen.
Der wirtschaftliche Nutzen maschinenlesbarer Markendaten entsteht durch eine zentrale Pflege und kontrollierte Ausgaben in mehreren Kanälen.
Ein Vorher-Nachher-Fall aus der KMU-Praxis
Ein typischer Fall aus meiner Arbeit: Auf der deutschsprachigen Website steht „Beratung und Planung“, auf der italienischen Seite nur „Consulenza“, im Google-Unternehmensprofil „Planungsbüro“ und auf Instagram ein früherer Produktname. Zusätzlich nennt die Website Öffnungszeiten bis 18 Uhr, während ein Branchenverzeichnis 17 Uhr angibt.
Vorher: widersprüchliche Angaben in mehreren Kanälen
- Leistungsnamen werden bei jeder Veröffentlichung neu formuliert.
- Übersetzungen können nicht eindeutig derselben Leistung zugeordnet werden.
- Öffnungszeiten werden an mehreren Stellen manuell geändert.
- Alte Profile und Dokumente bleiben unbemerkt online.
- Mitarbeitende wissen nicht, welche Beschreibung verbindlich ist.
Nachher: freigegebene Fakten aus einer zentralen Quelle
- Jede Leistung erhält eine stabile Kennung und freigegebene Namen pro Sprache.
- Website und brand.json beziehen ihre Angaben aus derselben Inhaltsbasis.
- Öffnungszeiten werden an einer Stelle geändert und anschließend kontrolliert ausgespielt.
- Offizielle Profile werden dokumentiert und regelmäßig geprüft.
- Verantwortlichkeiten und Änderungsdatum sind nachvollziehbar.
Das Ergebnis sind weniger Widersprüche, weniger Pflegeaufwand und verlässlichere Aussagen über die Marke. Nach über 20 Jahren Arbeit an Branding, Webentwicklung und Digitalisierung halte ich diese organisatorische Klarheit für wichtiger als das einzelne Dateiformat.
brand.json, Schema.org, llms.txt und Website-Inhalte trennen
Mehrere Ausgaben können dieselben Markenfakten verwenden, erfüllen aber unterschiedliche Aufgaben. Keine der folgenden Ebenen ersetzt die anderen.
Sichtbare Website-Inhalte informieren und führen
Sichtbare Website-Inhalte sind für Menschen geschrieben. Sie erklären Zusammenhänge, beantworten Fragen, vermitteln die Positionierung und führen zu einem passenden Kontaktweg. Eine brand.json darf deshalb nicht dazu führen, Leistungen oder Standorte auf der Website nur noch knapp oder unverständlich zu beschreiben.
brand.json bündelt freigegebene Markenfakten
Die brand.json stellt einen kompakten Datensatz über die Marke bereit. Das Format eignet sich für kontrollierte Weiterverarbeitung, interne Anwendungen und technische Integrationen. Welche Systeme die Datei tatsächlich abrufen oder interpretieren, hängt von deren Implementierung ab.
Schema.org beschreibt Entitäten im Kontext einer Website
Strukturierte Daten nach Schema.org werden üblicherweise direkt in Websites eingebunden, häufig als JSON-LD. Schema.org ist eine gemeinschaftlich gepflegte Initiative und bietet Typen sowie Eigenschaften für Organisationen, Adressen, Standorte, Kontaktpunkte, Angebote und Dienstleistungen.
Schema.org besitzt ein definiertes Vokabular. Eine brand.json kann dagegen ein eigenes, dokumentiertes Datenschema verwenden. Beide Ausgaben können aus derselben zentralen Quelle erzeugt werden, sind aber nicht automatisch austauschbar.
llms.txt kuratiert Hinweise und Inhaltslinks
Jeremy Howard veröffentlichte llms.txt am 3. September 2024 als Vorschlag für eine Markdown-Datei mit kompakten Hintergrundinformationen, Hinweisen und Links zu weiterführenden Inhalten. Die vorgeschlagene Datei dient vor allem der Orientierung für Sprachmodelle und ist keine vollständige Datenbank der Markenfakten.
Eine ausführlichere Einordnung der Grenzen und Einsatzmöglichkeiten findest Du in unserem Beitrag über llms.txt für KMU.
Pflege und Governance: Wer hält die Markenfakten aktuell?
Eine brand.json braucht eine verantwortliche Person. In kleinen Betrieben ist dafür keine eigene Datenstelle erforderlich. Häufig übernimmt die Geschäftsführung, eine Person aus dem Marketing oder die für die Website verantwortliche Fachkraft die fachliche Freigabe.
Eine klare Rollenverteilung umfasst vier Aufgaben:
- Fachliche Verantwortung: Wer entscheidet, welche Markenfakten korrekt und freigegeben sind?
- Technische Verantwortung: Wer prüft Erzeugung, Datenvalidierung und Veröffentlichung?
- Sprachliche Verantwortung: Wer stellt sicher, dass mehrsprachige Bezeichnungen dieselbe Bedeutung transportieren?
- Kontrollverantwortung: Wer vergleicht die zentrale Quelle regelmäßig mit Website und offiziellen Profilen?
Typische Aktualisierungsauslöser sind ein Umzug, neue Kontaktdaten, geänderte Öffnungszeiten, ein Rebranding, neue oder eingestellte Leistungen, ein zusätzlicher Standort und neue Sprachversionen. Solche Änderungen sollten zuerst in der Single Source of Truth vorgenommen und anschließend in die angebundenen Kanäle übertragen werden.
Versionierung ohne unnötige Komplexität
Für die meisten KMU reicht eine einfache Versionierung. Verwende ein Feld für die Strukturversion, ein Feld für den Datenstand und ein eindeutiges Änderungsdatum. Bei relevanten Änderungen ist zusätzlich ein kurzes internes Änderungsprotokoll sinnvoll.
Ein neues Logo bei unveränderten Feldern erfordert möglicherweise nur eine neue Datenversion. Eine geänderte Struktur mit neuen Pflichtfeldern erfordert dagegen eine neue Schema-Version. Die Unterscheidung hilft angebundenen Anwendungen, strukturelle Änderungen korrekt zu verarbeiten.
Technische Veröffentlichung der brand.json
Vor der Veröffentlichung solltest Du nicht nur prüfen, ob die Datei im Browser erscheint. Eine brauchbare brand.json benötigt eine verlässliche technische Auslieferung und eine fachliche Kontrolle.
Technische Auslieferung
- Stabile HTTPS-Adresse: beispielsweise https://www.deine-domain.it/brand.json.
- Passender Content-Type: vorzugsweise application/json.
- Valide JSON-Syntax: keine fehlenden Kommas, ungeschlossenen Anführungszeichen oder Kommentare.
- Erreichbare URLs: Website, Standortseiten und offizielle Profile auf Fehler prüfen.
Inhaltliche Prüfung
- Definierte Pflichtfelder: intern festlegen, welche Angaben nie fehlen dürfen.
- Aktuelle Daten: Änderungsdatum und Inhalt müssen zusammenpassen.
- Inhaltliche Übereinstimmung: Namen, Leistungen und Kontaktdaten mit den sichtbaren Angaben vergleichen.
- Keine unnötigen Personendaten: nur veröffentlichen, was öffentlich benötigt wird.
- Dokumentiertes Schema: Feldnamen, Datentypen und Sprachlogik für spätere Erweiterungen festhalten.
Eine Syntaxprüfung erkennt, ob das JSON technisch gelesen werden kann. Eine fachliche Prüfung klärt, ob der Inhalt korrekt und aktuell ist. Beides gehört zur Datenvalidierung. Für verwandte JSON-LD-Prüfungen zeigt unser Leitfaden zur Schema-Validierung, warum technische und inhaltliche Kontrolle getrennt betrachtet werden sollten.
Wie btlabs Core Markendaten zentral bereitstellt
Bei Berger+Team denken wir Branding, Website und technische Ausgaben als zusammenhängendes System. Angaben wie unsere Anschrift in Bozen, Kontaktwege sowie Leistungsbezeichnungen aus Branding, Webdesign, Online-Marketing, KI-Integration und Beratung sollten nicht in jeder Ausgabe separat eingetragen werden. Solche Fakten benötigen eine gemeinsame Inhaltsbasis.
btlabs Core ist eine zentrale Inhaltsbasis, aus der Website-Inhalte und maschinenlesbare Ausgaben wie eine brand.json gespeist werden können. Mehrsprachige Inhalte werden strukturiert verwaltet, damit die verschiedenen Sprachfassungen fachlich zusammengehören. Das reduziert doppelte Pflege und abweichende Angaben.
Weitere Kanäle wie Shops, Apps, Buchungsfunktionen oder handelnde KI-Agenten sind mögliche Ausbaustufen und nicht pauschal Bestandteil jeder Umsetzung. Entscheidend ist der konkrete Bedarf des Betriebs. Auf der Seite zur KI-ready Website mit btlabs Core erklären wir das technische Fundament und mögliche Ausgaben genauer.
Auch für zentral gepflegte KI-Markendaten gilt: Kein System kann erzwingen, dass ein Sprachmodell eine Marke nennt oder eine bestimmte Quelle zitiert. Eine eindeutige Datenbasis verbessert die Voraussetzungen für eine korrekte Verarbeitung. Sie ersetzt weder glaubwürdige Inhalte noch Bekanntheit, externe Vertrauenssignale oder eine klare Positionierung.
Fragen und Antworten zur brand.json
Wo sollte die brand.json gespeichert werden?
Eine stabile Adresse im Stammverzeichnis Deiner Domain ist leicht kommunizierbar, zum Beispiel /brand.json. Entscheidend sind eine dauerhafte HTTPS-URL, öffentliche Erreichbarkeit und die korrekte Auslieferung als JSON.
Gibt es verpflichtende Felder für eine brand.json?
Nein, derzeit existiert kein allgemein verbindlicher brand.json-Webstandard mit universellen Pflichtfeldern. Definiere für Dein Unternehmen mindestens öffentlichen Namen, rechtlichen Namen, Beschreibung, Leistungen, Kontakt, Standort, Sprachen, Version und Änderungsdatum als interne Pflichtangaben.
Wie bilde ich Mehrsprachigkeit sauber ab?
Verwende eindeutige Sprachcodes wie de und it und ordne Übersetzungen derselben stabilen Leistungs- oder Standortkennung zu. Prüfe nicht nur die Sprache, sondern auch die fachliche Gleichwertigkeit der Aussagen.
Darf eine brand.json personenbezogene Daten enthalten?
Technisch ist das möglich, fachlich und rechtlich solltest Du zurückhaltend sein. Veröffentliche bevorzugt allgemeine geschäftliche Kontaktwege und kläre vorab, ob personenbezogene Angaben notwendig, freigegeben und datenschutzrechtlich zulässig sind.
Wie oft muss die Datei aktualisiert werden?
Aktualisiere die brand.json bei jeder relevanten Änderung an den enthaltenen Fakten. Zusätzlich empfehle ich mindestens eine vierteljährliche Kontrolle gegen Website, Unternehmensprofile und interne Stammdaten.
Wie kann ich eine brand.json validieren?
Prüfe zuerst die JSON-Syntax mit einem geeigneten Validator oder automatisierten Test. Danach folgt die fachliche Kontrolle von Namen, URLs, Telefonnummern, Sprachversionen, Öffnungszeiten und Pflichtfeldern gegen die zentrale Datenquelle.
Ersetzt die brand.json Schema.org-Markup?
Nein. Schema.org-Markup beschreibt Inhalte und Entitäten innerhalb einer Website mit einem gemeinschaftlich gepflegten Vokabular, während eine brand.json ein separates Markenprofil bereitstellt. Beide Ausgaben sollten dieselben freigegebenen Ausgangsdaten verwenden.
Ist eine brand.json dasselbe wie eine llms.txt?
Nein. Eine brand.json organisiert Markenfakten als JSON, während llms.txt eine vorgeschlagene Markdown-Datei zur Orientierung und zur Verlinkung wichtiger Inhalte ist. Die beiden Dateien können sich ergänzen, erfüllen aber unterschiedliche Aufgaben.
Berücksichtigen KI-Systeme eine brand.json automatisch?
Nein, eine automatische Berücksichtigung durch alle KI-Systeme ist nicht belegt und kann nicht vorausgesetzt werden. Die tatsächliche Nutzung hängt von Crawlern, Suchsystemen, Anwendungen und konkreten Integrationen ab. Deshalb bleiben sichtbare Website-Inhalte und etablierte strukturierte Daten unverzichtbar.
Was ist der wichtigste erste Schritt für ein KMU?
Beginne nicht mit dem Programmieren der Datei, sondern mit der Freigabe Deiner verbindlichen Markenfakten. Wenn Name, Leistungen, Standorte und Kontaktwege intern nicht eindeutig sind, macht eine brand.json die bestehenden Widersprüche lediglich maschinenlesbar.
Fazit: Erst Markenfakten klären, dann JSON ausgeben
Eine brand.json ist sinnvoll, wenn sie aus einer gepflegten Single Source of Truth entsteht. Die Datei macht verbindliche Markenfakten kompakt, überprüfbar und technisch weiterverwendbar. Für KMU bedeutet das weniger doppelte Pflege, konsistentere Mehrsprachigkeit und eine verlässlichere Grundlage für Websites, digitale Dienste und KI-Anwendungen.
Die sinnvolle Reihenfolge lautet: Fakten festlegen, Verantwortung klären, zentrale Quelle bestimmen, JSON validieren, öffentlich ausliefern und regelmäßig kontrollieren. Ohne verbindliche Ausgangsdaten kann auch eine technisch korrekte brand.json keine Konsistenz herstellen.
