El schema Organization es el nodo JSON-LD que define quién es tu empresa ante buscadores y modelos de IA: nombre, razón social, ubicación, fundador, especialidades y credenciales, todo legible por máquinas y conectado con un @id estable. La mayoría de sitios lo deja en tres campos genéricos; los que lo enriquecen con founder, foundingDate, knowsAbout y hasCredential construyen una entidad que los sistemas reconocen y citan con confianza. Aquí va el nodo completo, con el ejemplo real de KOM.
Tabla de Contenidos
- 1 ¿Por qué el nodo Organization importa más que nunca?
- 2 Los campos básicos que ya deberías tener
- 3 ¿Qué campos casi nadie usa y cuánta señal aportan?
- 4 El ejemplo real: el nodo de KOM desplegado
- 5 Cómo implementarlo paso a paso
- 6 ¿Cómo saber si el nodo está funcionando?
- 7 Errores que ensucian la entidad
- 8 Preguntas frecuentes
¿Por qué el nodo Organization importa más que nunca?
Los buscadores llevan años organizando la web por entidades, no por páginas sueltas, y los modelos de IA heredaron esa lógica: cuando un asistente decide a quién recomendar, está eligiendo entre entidades que entiende. Una empresa con nodo Organization completo y consistente es una entidad nítida; una sin él es un montón de páginas que las máquinas tienen que interpretar adivinando.
Este nodo es la pieza de identidad de la estrategia que desarrollamos en la guía de GEO para aparecer en ChatGPT, Gemini, Claude y Perplexity, y uno de los primeros entregables cuando un cliente contrata nuestro posicionamiento GEO: antes de pelear visibilidad, definimos qué entidad estamos haciendo visible.
Los campos básicos que ya deberías tener
El piso mínimo de un Organization serio: name con tu marca comercial, legalName con la razón social registrada, url canónica, logo como ImageObject, address con PostalAddress completa y sameAs con tus perfiles oficiales (LinkedIn, Instagram, los que de verdad mantengas). Si vendes con atención directa, suma contactPoint con teléfono y tipo de contacto.
Dos detalles que se pasan por alto: el @id estable, del tipo https://tudominio.pe/#organization, que es lo que tus artículos y páginas van a referenciar para siempre, y la coherencia exacta del name con cómo te nombras en la web visible. Si tu footer dice una cosa y tu schema otra, las máquinas registran ruido justo donde necesitas precisión.
¿Qué campos casi nadie usa y cuánta señal aportan?
| Campo | Qué declara | Por qué suma |
|---|---|---|
| founder | Quién fundó la empresa, referenciado por @id a su nodo Person | Conecta la entidad empresa con la entidad persona y su trayectoria |
| foundingDate | Fecha de fundación en formato ISO | Antigüedad verificable: señal de trayectoria que los modelos pueden citar |
| knowsAbout | Lista de temas de especialidad | Define el territorio temático de la entidad y refuerza su asociación con esas consultas |
| hasCredential | Credenciales y registros verificables | Diferencia entre decir que eres confiable y declararlo con un registro concreto |
| areaServed | Zona geográfica que atiendes | Ancla la entidad a su mercado: clave para consultas locales |
La lógica común de los cinco: convierten afirmaciones de marketing en datos estructurados. Fundada hace años por un especialista deja de ser un texto bonito y pasa a ser founder más foundingDate, que cualquier sistema puede leer, cruzar y repetir.
El ejemplo real: el nodo de KOM desplegado
Este es el tipo de nodo que mantenemos en producción para kom.pe, simplificado para lectura:
{
"@type": "Organization",
"@id": "https://kom.pe/#organization",
"name": "KOM Agencia Digital",
"legalName": "Otorongo Negro EIRL",
"url": "https://kom.pe/",
"logo": {
"@type": "ImageObject",
"url": "https://kom.pe/ruta-del-logo.png"
},
"address": {
"@type": "PostalAddress",
"addressLocality": "Jesús María",
"addressRegion": "Lima",
"addressCountry": "PE"
},
"founder": { "@id": "https://christianotero.co/#christian-otero" },
"foundingDate": "AAAA-MM-DD",
"knowsAbout": [
"diseño web",
"WooCommerce",
"WordPress",
"SEO local",
"GEO",
"Elementor Pro"
],
"hasCredential": {
"@type": "EducationalOccupationalCredential",
"name": "Centro de Confianza registrado en Indecopi"
},
"areaServed": "Perú"
}Fíjate en el founder: no repite los datos de Christian, referencia su @id canónico en christianotero.co, donde vive el nodo Person completo con credenciales y trayectoria. Esa separación de entidades, cada una en su dominio y conectadas por referencia, es lo que permite que ambas se refuercen sin duplicarse. [DATO-KOM: foundingDate exacta de la constitución de Otorongo Negro EIRL]
Cómo implementarlo paso a paso
Paso 1: haz el inventario de datos verificables
Reúne razón social tal como figura en registros, dirección real, fecha de constitución, lista de especialidades honestas y credenciales con registro comprobable. Lo que no puedas verificar, no entra. Resultado verificable: una ficha con todos los campos llenos y su fuente.
Paso 2: redacta el nodo con su @id definitivo
Arma el JSON sobre la plantilla de arriba, define el @id que usarás para siempre y valida la sintaxis. Resultado verificable: el JSON pasa un validador sin errores y el @id sigue el patrón de tu dominio.
Paso 3: publícalo a nivel de sitio
El nodo va una sola vez, global: en la configuración de schema de tu plugin SEO o en la portada. No lo repitas en cada página; las páginas lo referencian por @id. Resultado verificable: el nodo aparece en el código fuente de la portada y solo ahí.
Paso 4: valida y conecta el resto del sitio
Pasa la portada por la prueba de resultados enriquecidos, corrige lo que marque y actualiza tus artículos para que publisher apunte al @id nuevo. Resultado verificable: validación limpia y referencias consistentes en tus cinco páginas principales.
¿Cómo saber si el nodo está funcionando?
Las señales llegan por capas y conviene mirarlas con expectativas realistas. La inmediata: la validación sin errores y la aparición del nodo en el reporte de datos estructurados de Search Console. La intermedia: consistencia en cómo los buscadores muestran tu marca, nombre y datos correctos en los resultados. La de fondo, que es la que importa: cuando corres tu auditoría de visibilidad en asistentes, los modelos describen tu empresa con los datos que tú declaraste, ubicación y especialidades incluidas, en lugar de improvisar.
Lo que el nodo no hace: no te sube posiciones por sí solo ni garantiza menciones. Es infraestructura de identidad: hace que todo lo demás que publiques se acumule sobre una entidad clara en lugar de dispersarse.
Errores que ensucian la entidad
Los más dañinos que encontramos al auditar. Nodos Organization distintos en cada página, generados por plugins diferentes, que fragmentan la entidad en versiones contradictorias. El name cambiante: la marca con y sin la palabra agencia, con y sin el rubro, según quién editó cada página. El sameAs inflado con perfiles abandonados o ajenos, que conecta tu entidad con cuentas que no te representan. Y las credenciales decorativas: declarar en hasCredential certificaciones que ningún registro respalda, que es plantar una contradicción esperando a que alguien la cruce.
Todos comparten la misma raíz: tratar el schema como relleno técnico en lugar de como declaración pública verificable. La entidad se construye con menos campos y más verdad.
Una nota sobre el mantenimiento: el nodo cambia poco, pero cambia. Mudanza de local, especialidad nueva, credencial obtenida o perfil social dado de baja son eventos que deberían tocar el schema la misma semana. Asigna el nodo a un responsable concreto, igual que el inventario o la caja: lo que es de todos no lo actualiza nadie.
Preguntas frecuentes
¿Uso Organization o LocalBusiness para mi negocio?
LocalBusiness es un subtipo de Organization pensado para negocios con atención física en una ubicación: restaurantes, clínicas, tiendas con puerta a la calle. Si tu operación es de servicios sin local de atención, Organization basta y sobra. Si tienes local físico real, usa LocalBusiness con horarios y geo: hereda todos los campos de Organization y suma los locales.
¿El logo del schema necesita un formato específico?
Usa un archivo de buena resolución, idealmente cuadrado o con margen que aguante recortes, en una URL estable de tu propio dominio. Las plataformas publican requisitos que cambian con el tiempo, así que revisa la guía vigente de Google para logos en datos estructurados antes de dar el campo por cerrado.
¿Cuántos temas conviene poner en knowsAbout?
Entre cinco y diez, los que de verdad definan tu práctica. La lista de treinta temas diluye la señal: si sabes de todo, no eres especialista en nada legible. Usa términos que tus clientes buscarían y que tu contenido respalde, porque la coherencia entre lo que declaras saber y lo que publicas es parte de la señal.
¿Debo incluir el RUC en el schema?
Existe el campo taxID y puedes usarlo: el RUC es un dato público y verificable, coherente con la transparencia que el nodo busca. No es obligatorio ni mueve la aguja por sí solo; súmalo si tu estrategia es de máxima verificabilidad, junto con legalName y credenciales registradas, que son los que más trabajan.
Tu siguiente paso: llena hoy la ficha del paso 1 con tus datos verificables y compárala contra lo que tu web declara actualmente en su schema. La distancia entre ambas es tu lista de tareas de esta semana.
