Un archivo brand.json en su sitio web proporciona información de marca legalmente vinculante como datos estructurados y legibles por máquina. Este archivo puede ofrecer nombres, servicios, ubicaciones, idiomas, métodos de contacto, horarios de apertura y perfiles oficiales desde una fuente centralizada. Si bien un archivo brand.json mejora la singularidad técnica, no garantiza menciones ni citas por parte de sistemas como ChatGPT, Gemini, Perplexity u otros.
Para una PYME, la ventaja no reside en el formato de archivo adicional, sino en una respuesta vinculante a la pregunta: ¿Qué información sobre la empresa es correcta y dónde se almacena esta información?
Un archivo brand.json no reemplaza un sitio web fácil de usar. Este archivo es una salida adicional, legible por máquina, de la misma información de marca registrada que está disponible públicamente.
brand.json para tu sitio web: Tareas y limitaciones
Un archivo brand.json agrupa datos clave de la empresa y la marca en formato JSON , un formato de texto para el intercambio de datos. Los usuarios pueden leer el archivo; y, lo que es más importante, puede ser procesado por sitios web, aplicaciones, interfaces, sistemas de búsqueda y servicios con inteligencia artificial.
El término brand.json no se refiere actualmente a un estándar web obligatorio publicado por un organismo de normalización reconocido. Un gestor de marcas de código abierto, por ejemplo, utiliza el mismo nombre. Sin embargo, la estructura e interpretación de un archivo brand.json dependen de la integración técnica específica. Por lo tanto, distintos sistemas pueden utilizar nombres y estructuras de campos diferentes.
Por lo tanto, no adopte una plantilla sin antes revisarla. Defina un esquema claro, documente los campos y garantice la coherencia de los datos. Un archivo sintácticamente válido que contenga horarios de apertura incorrectos seguirá teniendo errores de información.
¿Qué información sobre la marca debe incluirse en el archivo?
En mi trabajo con empresas gestionadas por sus propietarios, me encuentro frecuentemente con el mismo problema: el nombre de la empresa aparece escrito de forma diferente en la página web que en el perfil de Google My Business, los servicios no se nombran de forma consistente en alemán e italiano, y un número de teléfono antiguo sigue registrado en un perfil de redes sociales. Un archivo brand.json debería consolidar esta información cuando dichas discrepancias resulten especialmente problemáticas.
Identidad y posicionamiento
- Nombre de marca pública: El nombre con el que la empresa se comunica y es buscada.
- Nombre legal: El nombre completo de la empresa para una identificación inequívoca.
- Breve descripción: una descripción objetiva de la empresa, su público objetivo y su oferta de productos y servicios.
- Servicios: Nombres de servicios aprobados con breves explicaciones e identificadores estables.
- idiomas: Idiomas en los que se ofrecen asesoramiento, ventas o soporte.
Ubicación, accesibilidad y mantenimiento
- ubicaciones: Direcciones completas y, en su caso, áreas geográficas de responsabilidad.
- Métodos de contacto: Dirección de correo electrónico general, número de teléfono y sitio web oficial.
- Horario de apertura: Horarios regulares con días de la semana y zona horaria claramente definidos.
- Perfiles oficiales: Perfiles de empresa confirmados en las plataformas pertinentes.
- Versión y fecha de modificación: Información sobre el control de versiones y la última revisión técnica.
Los datos personales solo deben incluirse en el archivo público si su publicación es necesaria, cuenta con aprobación interna y cumple con la normativa legal. Para muchas pymes, una dirección genérica como info@company.it es suficiente . Por precaución, no se deben publicar números de teléfono móvil privados, extensiones internas ni direcciones de correo electrónico personales.
Datos de marca en formato JSON: Ejemplo de una PYME del Tirol del Sur
El siguiente ejemplo describe un negocio artesanal ficticio del Tirol del Sur. La estructura es intencionadamente compacta. Se trata de una plantilla posible, pero no de un esquema brand.json universalmente vinculante.
{
"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"
}
]
}Qué significan los campos individuales
`schemaVersion` hace referencia a la versión del modelo de datos utilizado. Si posteriormente se cambia el nombre de un campo o se amplía la estructura, una aplicación técnica puede reconocer según qué esquema está estructurado el archivo.
`version` se refiere al estado actual del registro de datos. Para las pequeñas empresas, suele ser suficiente con la combinación de año y mes. `lastUpdated` especifica la fecha de la última modificación del contenido en el formato único año-mes-día.
Los campos publicName y legalName separan el nombre de marca comunicado del nombre legal de la empresa. Esta separación evita que un nombre de marca abreviado se utilice accidentalmente como nombre completo de la empresa.
La sección de descripciones contiene descripciones breves aprobadas, clasificadas por idioma. El multilingüismo abarca más que una simple traducción correcta: las declaraciones deben ser coherentes en cuanto a su contenido en todos los idiomas.
El servicio utiliza un identificador fijo para cada servicio. El valor "moebel-nach-mass" permanece invariable, mientras que los nombres visibles cambian según el idioma. Esto permite que los sistemas técnicos identifiquen correctamente los nombres en alemán e italiano para el mismo servicio.
El campo "ubicaciones" separa el nombre de la ubicación de la dirección estructurada. La zona horaria es especialmente relevante para los horarios de apertura, los detalles de las citas o las múltiples ubicaciones.
La sección "Contactos" incluye únicamente métodos de contacto generales. "Horario de apertura" describe el horario habitual. Si es necesario, se requiere un campo adicional que contenga información sobre horarios especiales, días festivos de la empresa o días festivos oficiales.
Los perfiles oficiales solo deben contener perfiles verificados gestionados por la propia empresa. Los directorios del sector o las menciones editoriales no se consideran perfiles oficiales.
De la información distribuida a la Fuente Única de Verdad
El archivo brand.json no debe mantenerse manualmente como un archivo independiente junto con el sitio web. Se recomienda que su PYME cuente con una única fuente de información fidedigna : una fuente de datos única y autorizada de la que se nutran el sitio web, los resultados estructurados y otros canales.
El proceso operativo consta de siete pasos:
- 1. Recopilar información sobre la marca: Verifique los sitios web, los perfiles de la empresa, los directorios, las ofertas y los documentos internos para detectar discrepancias.
- 2. Revelar los hechos: La dirección o los responsables de marca deciden qué nombres, descripciones, servicios y métodos de contacto son vinculantes.
- 3. Determinar la fuente central: Una base de datos o un sistema de contenido bien mantenido se convierte en la fuente autorizada.
- 4. Generar JSON: Los datos publicados se transfieren de forma automática o manual a la estructura acordada bajo condiciones controladas.
- 5. Realizar la validación de datos: Se comprueban la sintaxis, los campos obligatorios, los tipos de datos, las URL y la precisión técnica.
- 6. Entregar públicamente: El archivo recibe una dirección HTTPS estable y se le proporciona un tipo de contenido adecuado.
- 7. Sincronizar cambios: Los nuevos servicios, los cambios en el horario de apertura o una reubicación se actualizan primero en la fuente central y luego se transfieren a las ediciones vinculadas.
Los beneficios económicos de los datos de marca legibles por máquina se derivan del mantenimiento centralizado y del gasto controlado en múltiples canales.
Un estudio de caso de antes y después de una práctica de PYME
Un ejemplo típico de mi trabajo: el sitio web en alemán indica "Beratung und Planung" (Consultoría y Planificación), el sitio en italiano solo "Consulenza" (Consultoría), el perfil de Google Business muestra "Planungsbüro" (Oficina de Planificación) e Instagram utiliza un nombre de producto anterior. Además, el sitio web indica un horario de atención hasta las 18:00, mientras que un directorio comercial indica que cierra a las 17:00.
Anteriormente: información contradictoria en múltiples canales
- Los nombres de los productos se reformulan con cada publicación.
- Las traducciones no pueden asignarse inequívocamente al mismo servicio.
- En varios lugares, el horario de apertura se modifica manualmente.
- Los perfiles y documentos antiguos permanecen en línea sin que nadie se dé cuenta.
- Los empleados desconocen qué descripción es la vinculante.
Posteriormente: hechos publicados por una fuente central.
- Cada servicio recibe un identificador estable y nombres aprobados por idioma.
- El sitio web y el archivo brand.json obtienen su información de la misma base de datos de contenido.
- Los horarios de apertura se modifican en un momento dado y luego se implementan de forma controlada.
- Los perfiles oficiales están documentados y se revisan periódicamente.
- Las responsabilidades y las fechas de los cambios son rastreables.
El resultado son menos inconsistencias, menor esfuerzo de mantenimiento y declaraciones más fiables sobre la marca . Tras más de 20 años trabajando en branding, desarrollo web y digitalización, considero que esta claridad organizativa es más importante que el formato de archivo individual.
Separe los archivos brand.json, Schema.org, llms.txt y el contenido del sitio web.
Varias ediciones pueden usar la misma información de marca, pero con propósitos diferentes. Ninguno de los siguientes niveles reemplaza a los demás.
El contenido visible del sitio web informa y orienta.
El contenido visible de un sitio web está escrito para los usuarios. Explica las conexiones, responde preguntas, comunica el posicionamiento y proporciona un método de contacto adecuado. Por lo tanto, un archivo brand.json no debería dar como resultado que los servicios o ubicaciones del sitio web se describan de forma breve o incomprensible.
El archivo brand.json contiene información de marca aprobada.
El archivo brand.json proporciona un conjunto de datos compacto sobre la marca. Su formato es adecuado para un procesamiento posterior controlado, aplicaciones internas e integraciones técnicas. Los sistemas que recuperan o interpretan el archivo dependen de su implementación.
Schema.org describe las entidades en el contexto de un sitio web.
Los datos estructurados según Schema.org suelen integrarse directamente en los sitios web, a menudo en formato JSON-LD. Schema.org es una iniciativa mantenida por la comunidad que proporciona tipos y propiedades para organizaciones, direcciones, ubicaciones, puntos de contacto, ofertas y servicios.
Schema.org tiene un vocabulario definido. Un archivo brand.json, por otro lado, puede usar su propio esquema de datos documentado. Ambos formatos pueden generarse a partir de la misma fuente central, pero no son automáticamente intercambiables.
llms.txt organiza notas y enlaces de contenido.
Jeremy Howard publicó llms.txt el 3 de septiembre de 2024, como propuesta para un archivo Markdown que contiene información de contexto concisa, notas y enlaces a contenido adicional. El archivo propuesto sirve principalmente como guía para modelos de lenguaje y no es una base de datos exhaustiva de información sobre marcas.
En nuestro artículo sobre llms.txt para PYMES encontrará una explicación más detallada de las limitaciones y posibles aplicaciones.
Mantenimiento y gobernanza: ¿Quién se encarga de mantener actualizada la información de la marca?
El archivo brand.json requiere una persona responsable. En las pequeñas empresas, no es necesario un gestor de datos dedicado. A menudo, la dirección, un miembro del equipo de marketing o el administrador del sitio web se encargan de la aprobación técnica.
Una clara división de roles incluye cuatro tareas:
- Responsabilidad profesional: ¿Quién decide qué información sobre las marcas es correcta y está aprobada?
- Responsabilidad técnica: ¿Quién verifica la generación, la validación de datos y la publicación?
- Responsabilidad lingüística: ¿Quién garantiza que los términos multilingües transmitan el mismo significado?
- Responsabilidad del control: ¿Quién compara periódicamente la fuente principal con el sitio web y los perfiles oficiales?
Los factores que suelen desencadenar actualizaciones incluyen un cambio de ubicación, nuevos datos de contacto, cambios en el horario de atención, un cambio de marca, servicios nuevos o discontinuados, una nueva ubicación y nuevas versiones de idioma. Estos cambios deben realizarse primero en la fuente única de información y luego implementarse en los canales conectados.
Control de versiones sin complejidad innecesaria
Para la mayoría de las pymes, un control de versiones sencillo es suficiente. Utilice un campo para la versión de la estructura, otro para el estado de los datos y una fecha de modificación única. Para cambios significativos, también es recomendable un breve registro interno de cambios.
Un nuevo logotipo con campos sin cambios puede requerir únicamente una nueva versión de datos. Sin embargo, una estructura modificada con nuevos campos obligatorios requiere una nueva versión del esquema. Esta distinción ayuda a las aplicaciones conectadas a procesar correctamente los cambios estructurales.
Publicación técnica del archivo brand.json
Antes de publicar, no basta con comprobar si el archivo aparece en el navegador. Un archivo brand.json funcional requiere una entrega técnica fiable y una revisión profesional.
Entrega técnica
- Dirección HTTPS estable: por ejemplo https://www.deine-domain.it/brand.json.
- Tipo de contenido adecuado: preferiblemente aplicación / json.
- Sintaxis JSON válida: No faltan comas, no hay comillas sin cerrar ni comentarios.
- URLs accesibles: Comprueba si hay errores en la página web, las páginas de ubicación y los perfiles oficiales.
Revisión de contenido
- Campos obligatorios definidos: Defina internamente qué detalles nunca deben faltar.
- Datos actuales: La fecha de modificación y el contenido deben coincidir.
- Acuerdo de contenido: Compare los nombres, los servicios y los datos de contacto con la información visible.
- No se permiten datos personales innecesarios: Publica únicamente lo que sea de interés público.
- Esquema documentado: Registre los nombres de los campos, los tipos de datos y la lógica del lenguaje para futuras extensiones.
Una comprobación de sintaxis determina si el JSON se puede leer técnicamente. Una comprobación de negocio aclara si el contenido es correcto y está actualizado. Ambas forman parte de la validación de datos. Para obtener información sobre comprobaciones JSON-LD relacionadas, nuestra guía de validación de esquemas explica por qué las comprobaciones técnicas y de contenido deben considerarse por separado.
Cómo btlabs Core proporciona datos de marca de forma centralizada
En Berger+Team, consideramos la imagen de marca, el sitio web y los resultados técnicos como un sistema integrado. Información como nuestra dirección en Bolzano, datos de contacto y descripciones de servicios de imagen de marca, diseño web, marketing online, integración de IA y consultoría no deben aparecer por separado en cada documento. Dicha información requiere una base de contenido común.
btlabs Core es un repositorio central de contenido desde el cual se pueden generar contenido web y archivos legibles por máquina, como el archivo brand.json. El contenido multilingüe se gestiona de forma estructurada para garantizar la coherencia y relevancia de las diferentes versiones lingüísticas. Esto reduce la duplicación de tareas de mantenimiento y las inconsistencias.
Canales adicionales como tiendas online, aplicaciones, funciones de reserva o agentes de IA son posibles etapas de expansión y no forman parte de todas las implementaciones. El factor decisivo son las necesidades específicas del negocio. En la página sobre sitios web preparados para IA con btlabs Core, explicamos con más detalle la base técnica y los costes potenciales.
Incluso para los datos de marca gestionados centralmente mediante IA, se aplica lo siguiente: ningún sistema puede obligar a un modelo de lenguaje a mencionar una marca o citar una fuente específica. Una base de datos sólida mejora las condiciones para un procesamiento correcto. No sustituye el contenido creíble, el reconocimiento de marca, las señales de confianza externas ni un posicionamiento claro.
Preguntas y respuestas sobre brand.json
¿Dónde se debe almacenar el archivo brand.json?
Una dirección estable en el directorio raíz de tu dominio facilita la comunicación, por ejemplo, /brand.json . Fundamentalmente, esto requiere una URL HTTPS persistente, acceso público y una entrega correcta en formato JSON.
¿Hay algún campo obligatorio en un archivo brand.json?
No, actualmente no existe un estándar web universalmente vinculante para brand.json con campos obligatorios. Para su empresa, defina al menos los siguientes campos internos obligatorios: nombre público, nombre legal, descripción, servicios, información de contacto, ubicación, idiomas, versión y fecha de modificación.
¿Cómo puedo representar con precisión el multilingüismo?
Utilice códigos de idioma inequívocos como "de" e "it" y asigne traducciones al mismo identificador de rendimiento o ubicación estable. Verifique no solo el idioma, sino también la equivalencia técnica de las declaraciones.
¿Puede un archivo brand.json contener datos personales?
Técnicamente, esto es posible, pero conviene ser precavido desde un punto de vista profesional y legal. Preferiblemente, publique información general de contacto de la empresa y aclare de antemano si el uso de datos personales es necesario, está autorizado y permitido según la legislación de protección de datos.
¿Con qué frecuencia hay que actualizar el archivo?
Actualiza el archivo brand.json siempre que haya algún cambio relevante en la información que contiene. Además, recomiendo compararlo con tu sitio web, los perfiles de la empresa y los datos maestros internos al menos trimestralmente.
¿Cómo puedo validar un archivo brand.json?
Primero, verifique la sintaxis JSON con un validador adecuado o una prueba automatizada. Luego, realice una verificación funcional de los nombres, URL, números de teléfono, versiones de idioma, horarios de apertura y campos obligatorios con respecto a la fuente de datos central.
¿El archivo brand.json reemplaza el marcado de Schema.org?
No. El marcado Schema.org describe el contenido y las entidades de un sitio web mediante un vocabulario mantenido por la comunidad, mientras que un archivo brand.json proporciona un perfil de marca independiente. Ambos formatos deben utilizar los mismos datos de origen compartidos.
¿Un archivo brand.json es lo mismo que un archivo llms.txt?
No. El archivo brand.json organiza la información de la marca en formato JSON, mientras que llms.txt es un archivo Markdown sugerido para la orientación y la vinculación con contenido importante. Ambos archivos pueden complementarse, pero cumplen funciones diferentes.
¿Los sistemas de IA tienen en cuenta automáticamente un archivo brand.json?
No, la consideración automática por parte de todos los sistemas de IA no está demostrada ni puede darse por sentada. Su uso real depende de los rastreadores, los motores de búsqueda, las aplicaciones y las integraciones específicas. Por lo tanto, el contenido visible del sitio web y los datos estructurados establecidos siguen siendo esenciales.
¿Cuál es el primer paso más importante para una PYME?
No empieces programando el archivo, sino publicando la información clave de tu marca. Si el nombre, los servicios, las ubicaciones y los métodos de contacto no son coherentes internamente, un archivo brand.json simplemente hace que las inconsistencias existentes sean legibles por máquina.
Conclusión: Primero, aclare los datos de la marca y luego genere el archivo JSON.
Un archivo brand.json resulta útil cuando proviene de una fuente única y fiable de información. Este archivo hace que la información de marca sea compacta, verificable y técnicamente reutilizable. Para las pymes, esto se traduce en menos mantenimiento duplicado, contenido multilingüe más coherente y una base más sólida para sitios web, servicios digitales y aplicaciones de IA.
La secuencia lógica es: establecer los hechos, aclarar las responsabilidades, determinar una fuente central, validar el JSON, hacerlo público y supervisarlo periódicamente. Sin datos de origen vinculantes, incluso un archivo brand.json técnicamente correcto no puede garantizar la coherencia.
