A brand.json file on your website provides legally binding brand information as structured, machine-readable brand data. The file can deliver names, services, locations, languages, contact methods, opening hours, and official profiles from a central source. A brand.json file improves technical uniqueness but does not guarantee AI citations or mentions by ChatGPT, Gemini, Perplexity, and other systems.
For an SME, the benefit lies not in the additional file format, but in a binding answer to the question: Which information about the company is correct and where is this information maintained?
A brand.json file does not replace a user-friendly website. The file is an additional, machine-readable output of the same publicly available trademark information.
brand.json for your website: Tasks and limitations
A brand.json file bundles key company and brand data in JSON , a text-based format for data exchange. Humans can read the file; more importantly, it can be processed by websites, applications, interfaces, search systems, and AI-powered services.
The term brand.json does not currently refer to a mandatory web standard published by an established standards body. An open-source brand manager, for example, uses the same name. However, the structure and interpretation of a brand.json file depend on the specific technical integration. Therefore, different systems may use different field names and structures.
Therefore, do not adopt a template without checking it first. Define a clear schema, document the fields, and ensure data consistency. A syntactically valid file containing incorrect opening hours will still be factually flawed.
Which brand facts belong in the file?
In my work with owner-managed businesses, I frequently encounter the same starting point: The company name is spelled differently on the website than in the Google business profile, services aren't consistently named in German and Italian, and an old phone number remains stored in a social media profile. A brand.json file should consolidate those facts where such discrepancies are particularly problematic.
Identity and positioning
- Public brand name: The name under which the company communicates and is searched for.
- Legal name: The full company name for unambiguous identification.
- Short description: an objective description of the company, its target group and its offerings.
- Services: Approved service names with brief explanations and stable identifiers.
- Languages: Languages in which advice, sales, or support are actually offered.
Locations, accessibility and maintenance
- Locations: Full addresses and, where applicable, geographical areas of responsibility.
- Contact methods: general email address, phone number and official website.
- Opening hours: Regular times with clearly defined days of the week and time zone.
- Official profiles: Confirmed company profiles on relevant platforms.
- Version and date of modification: Information on versioning and the last technical review.
Personal data should only be included in the public file if publication is necessary, internally approved, and legally compliant. For many SMEs, a general address like info@company.it is sufficient . You should not publish private mobile numbers, internal extensions, or personal email addresses as a precaution.
Brand data in JSON format: Example from a South Tyrolean SME
The following example describes a fictitious craft business from South Tyrol. The structure is intentionally compact. It is a possible template, but not a universally binding 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"
}
]
}What the individual fields mean
`schemaVersion` refers to the version of the data model used. If a field is later renamed or the structure is extended, a technical application can recognize which schema the file is structured according to.
`version` refers to the current state of the data record. A combination of year and month is often sufficient for small businesses. `lastUpdated` specifies the date of the last content change in the unique format year-month-day.
The publicName and legalName separate the communicated brand name from the legal company name. This separation prevents a short brand name from being accidentally used as the full company name.
The descriptions section contains approved short descriptions categorized by language. Multilingualism encompasses more than just a linguistically correct translation: the statements must be consistent in terms of content across all languages.
The service uses a stable identifier for each service. The value "moebel-nach-mass" remains the same, while the visible names change depending on the language. This allows technical systems to correctly identify the German and Italian names for the same service.
The "locations" field separates the location name from the structured address. A time zone is particularly relevant for opening hours, appointment details, or multiple locations.
The "contacts" section intentionally only includes general contact methods. "openingHours" describes the regular opening hours. Special opening hours, company holidays, and public holidays require an additional, documented field if necessary.
officialProfiles should only contain verified profiles operated by the company itself. Industry directories or editorial mentions are not official profiles.
From distributed information to the Single Source of Truth
The brand.json file should not be manually maintained as a separate file alongside the website. A single source of truth is advisable for your SME : a single, authoritative data source from which the website, structured outputs, and other channels are fed.
The operational process consists of seven steps:
- 1. Gather brand facts: Check websites, company profiles, directories, offers and internal documents for discrepancies.
- 2. Release the facts: Management or brand managers decide which names, descriptions, services and contact methods are binding.
- 3. Determine the central source: A database or a well-maintained content system becomes the authoritative source.
- 4. Generate JSON: The released data is automatically or manually transferred into the agreed structure under controlled conditions.
- 5. Perform data validation: Syntax, mandatory fields, data types, URLs and technical accuracy are checked.
- 6. Deliver publicly: The file receives a stable HTTPS address and is provided with a suitable content type.
- 7. Synchronize changes: New services, changed opening hours or a relocation are first updated in the central source and then transferred to the linked editions.
The economic benefits of machine-readable brand data arise from centralized maintenance and controlled spending across multiple channels.
A before-and-after case study from SME practice
A typical example from my work: The German-language website states "Beratung und Planung" (Consulting and Planning), the Italian site only "Consulenza" (Consulting), the Google business profile lists "Planungsbüro" (Planning Office), and Instagram uses a previous product name. Additionally, the website states opening hours until 18 p.m., while a business directory indicates 17 p.m.
Previously: conflicting information across multiple channels
- Product names are reformulated with each publication.
- Translations cannot be unambiguously assigned to the same service.
- Opening hours are changed manually in several places.
- Old profiles and documents remain online unnoticed.
- Employees do not know which description is binding.
Afterwards: released facts from a central source
- Each service receives a stable identifier and approved names per language.
- The website and brand.json draw their information from the same content database.
- Opening hours are changed at one point and then played out in a controlled manner.
- Official profiles are documented and regularly reviewed.
- Responsibilities and change dates are traceable.
The result is fewer inconsistencies, less maintenance effort, and more reliable statements about the brand . After over 20 years of working in branding, web development, and digitalization, I consider this organizational clarity more important than the individual file format.
Separate brand.json, Schema.org, llms.txt and website content.
Multiple editions can use the same brand facts but serve different purposes. None of the following levels replace the others.
Visible website content informs and guides.
Visible website content is written for people. It explains connections, answers questions, conveys positioning, and leads to an appropriate contact method. Therefore, a brand.json file should not result in services or locations on the website being described only briefly or incomprehensibly.
brand.json bundles approved brand information.
The brand.json file provides a compact dataset about the brand. The format is suitable for controlled further processing, internal applications, and technical integrations. Which systems actually retrieve or interpret the file depends on its implementation.
Schema.org describes entities in the context of a website.
Structured data according to Schema.org is typically embedded directly into websites, often as JSON-LD. Schema.org is a community-maintained initiative and provides types and properties for organizations, addresses, locations, contact points, offers, and services.
Schema.org has a defined vocabulary. A brand.json file, on the other hand, can use its own documented data schema. Both outputs can be generated from the same central source, but they are not automatically interchangeable.
llms.txt curates notes and content links.
Jeremy Howard published llms.txt on September 3, 2024, as a proposal for a Markdown file containing concise background information, notes, and links to further content. The proposed file primarily serves as a guide for language models and is not a comprehensive database of brand facts.
A more detailed explanation of the limitations and possible applications can be found in our article about llms.txt for SMEs.
Maintenance and governance: Who keeps the brand facts up to date?
A brand.json file requires a responsible person. In small businesses, a dedicated data manager is not necessary. Often, the management, a member of the marketing team, or the website administrator handles the technical approval.
A clear division of roles includes four tasks:
- Professional responsibility: Who decides which brand facts are correct and approved?
- Technical responsibility: Who verifies generation, data validation, and publication?
- Linguistic responsibility: Who ensures that multilingual terms convey the same meaning?
- Control responsibility: Who regularly compares the central source with the website and official profiles?
Typical triggers for updates include a relocation, new contact details, changed opening hours, a rebranding, new or discontinued services, an additional location, and new language versions. Such changes should first be made in the single source of truth and then rolled out to the connected channels.
Versioning without unnecessary complexity
For most SMEs, simple versioning is sufficient. Use one field for the structure version, one field for the data status, and a unique modification date. For significant changes, a short internal change log is also advisable.
A new logo with unchanged fields may only require a new data version. However, a modified structure with new mandatory fields requires a new schema version. This distinction helps connected applications process structural changes correctly.
Technical publication of the brand.json
Before publishing, you shouldn't just check if the file appears in the browser. A usable brand.json file requires reliable technical delivery and professional review.
Technical delivery
- Stable HTTPS address: for example https://www.deine-domain.it/brand.json.
- Suitable content type: preferably application / json.
- Valid JSON syntax: No missing commas, unclosed quotation marks, or comments.
- Accessible URLs: Check the website, location pages, and official profiles for errors.
Content review
- Defined mandatory fields: Internally define which details must never be missing.
- Current data: The modification date and content must match.
- Content agreement: Compare names, services, and contact details with the visible information.
- No unnecessary personal data: Only publish what is publicly needed.
- Documented scheme: Record field names, data types, and language logic for later extensions.
A syntax check determines whether the JSON can be technically read. A business check clarifies whether the content is correct and up-to-date. Both are part of data validation. For related JSON-LD checks, our guide to schema validation shows why technical and content checks should be considered separately.
How btlabs Core centrally provides brand data
At Berger+Team, we consider branding, website, and technical outputs as an integrated system. Information such as our address in Bolzano, contact details, and service descriptions for branding, web design, online marketing, AI integration, and consulting should not be listed separately in every document. Such information requires a common content base.
btlabs Core is a central content repository from which website content and machine-readable outputs, such as a brand.json file, can be generated. Multilingual content is managed in a structured manner to ensure that the different language versions are consistent and relevant. This reduces duplicate maintenance and inconsistencies.
Additional channels such as shops, apps, booking functions, or AI agents are possible expansion stages and are not a standard part of every implementation. The decisive factor is the specific needs of the business. On the page about AI-ready websites with btlabs Core, we explain the technical foundation and potential costs in more detail.
Even for centrally maintained AI brand data, the following applies: No system can force a language model to mention a brand or cite a specific source. A clear data foundation improves the conditions for correct processing. It does not replace credible content, brand awareness, external trust signals, or clear positioning.
Questions and answers about brand.json
Where should the brand.json file be stored?
A stable address in the root directory of your domain is easy to communicate, for example /brand.json . Crucially, this requires a persistent HTTPS URL, public accessibility, and correct delivery as JSON.
Are there any mandatory fields for a brand.json file?
No, there is currently no universally binding brand.json web standard with mandatory fields. For your company, define at least the following as internal mandatory fields: public name, legal name, description, services, contact information, location, languages, version, and modification date.
How do I accurately represent multilingualism?
Use unambiguous language codes such as "de" and "it" and assign translations to the same stable performance or location identifier. Check not only the language but also the technical equivalence of the statements.
Can a brand.json file contain personal data?
Technically, this is possible, but you should be cautious from a professional and legal standpoint. Preferably publish general business contact information and clarify beforehand whether personal data is necessary, authorized, and permissible under data protection law.
How often does the file need to be updated?
Update the brand.json file whenever there is a relevant change to the information it contains. Additionally, I recommend checking it against your website, company profiles, and internal master data at least quarterly.
How can I validate a brand.json file?
First, check the JSON syntax with a suitable validator or automated test. Then, perform a functional check of names, URLs, phone numbers, language versions, opening hours, and required fields against the central data source.
Does the brand.json file replace the Schema.org markup?
No. Schema.org markup describes content and entities within a website using a community-maintained vocabulary, while a brand.json file provides a separate brand profile. Both outputs should use the same shared source data.
Is a brand.json the same as an llms.txt?
No. A brand.json file organizes brand information as JSON, while llms.txt is a suggested Markdown file for orientation and linking to important content. The two files can complement each other, but they serve different purposes.
Do AI systems automatically take a brand.json file into account?
No, automatic consideration by all AI systems is neither proven nor can it be assumed. Actual use depends on crawlers, search engines, applications, and specific integrations. Therefore, visible website content and established structured data remain essential.
What is the most important first step for an SME?
Don't start by programming the file, but by releasing your binding brand facts. If the name, services, locations, and contact methods are not internally consistent, a brand.json file simply makes the existing inconsistencies machine-readable.
Conclusion: First clarify brand facts, then output JSON.
A brand.json file is useful when it originates from a well-maintained single source of truth. This file makes binding brand information compact, verifiable, and technically reusable. For SMEs, this means less duplicate maintenance, more consistent multilingual content, and a more reliable foundation for websites, digital services, and AI applications.
The sensible sequence is: establish the facts, clarify responsibilities, determine a central source, validate the JSON, make it publicly available, and monitor it regularly. Without binding source data, even a technically correct brand.json file cannot ensure consistency.
