Tipos de Schema.org: la jerarquía de herencia que te hace citar (sin apilar tipos)

Si has abierto el validador de resultados enriquecidos y has visto una advertencia que no sabes cómo leer, o si intuyes que marcar tu negocio con tres tipos a la vez es “más seguro”, este artículo es para ti. La respuesta directa: los tipos de Schema.org forman una jerarquía, y lo correcto es declarar solo el subtipo más específico, no apilar tipos. Apilar ProfessionalService + LocalBusiness + Organization en el mismo nodo no te hace más visible: te ensucia el grafo.

Detrás de esa regla hay un principio que separa al SEO técnico maduro del que solo “pone schema”: el vocabulario de Schema.org está diseñado con herencia de tipos. Cada tipo hereda las propiedades de su tipo padre. Entender esa jerarquía es la diferencia entre un grafo de conocimiento limpio y uno que los validadores y las IAs leen con ruido.

Qué es un “tipo” en Schema.org y qué hace la propiedad @type

En un bloque JSON-LD, la propiedad @type es la que le dice al motor qué clase de cosa estás describiendo: una Organization, una Person, un Article, un Product. Es el punto de entrada a toda la semántica: a partir de ese tipo, el motor sabe qué propiedades son válidas y cómo interpretar el resto del bloque.

El error clásico es tratar @type como una etiqueta acumulativa, como si sumar tipos sumara significado. No es así. El vocabulario de Schema.org no es una lista plana de etiquetas: es un árbol de herencia cuyo tronco es Thing. De ahí cuelgan Organization, Person, Place, CreativeWork y el resto, y cada uno de esos tipos se ramifica a su vez en subtipos más específicos.

La jerarquía de los negocios: Organization → LocalBusiness → ProfessionalService

Para una consultora, clínica o estudio profesional, la cadena de herencia relevante es esta:

• Organization — el tipo base de cualquier entidad organizacional. Define name, logo, address, sameAs, founder.
• LocalBusiness — un subtipo de Organization que añade la dimensión física: openingHours, geo, areaServed, priceRange.
• ProfessionalService — un subtipo de LocalBusiness que añade la dimensión de servicio profesional especializado.

La relación es de subconjunto: todo ProfessionalService es un LocalBusiness, y todo LocalBusiness es una Organization. Cuando declaras "@type": "ProfessionalService", el motor ya sabe que hereda todas las propiedades de LocalBusiness y de Organization. No necesitas repetirlas en el tipo.

Apilar los tres tipos en el mismo nodo es semánticamente redundante: equivale a decirle al motor “esto es un perro, un mamífero y un animal” cuando “perro” ya implica las otras dos. Los validadores no siempre lo marcan como error crítico, pero es exactamente el tipo de ruido semántico que degrada la confianza de un grafo.

Por qué apilar tipos te ensucia el grafo (aunque valide)

Aquí está el matiz que pocos explican: un bloque con tipos apilados puede pasar el validador de Schema.org sin errores y aun así dañar tu presencia en el Knowledge Graph de Google. El validador comprueba la sintaxis; los motores generativos y el grafo de conocimiento evalúan la consistencia semántica.

• Redundancia que confunde la desambiguación: declarar tres tipos simultáneos le deja al motor la tarea de decidir cuál es el “real”. Esa ambigüedad es justo lo que impide que tu entidad se resuelva con claridad.
• Contradicciones latentes: si el nodo hereda propiedades por tres vías distintas, cualquier diferencia entre lo que espera cada tipo (por ejemplo, campos propios de LocalBusiness que no aplican a una consultora 100% remota) genera señales cruzadas.
• Difícil de auditar: un grafo con tipos apilados es más duro de mantener, de comparar entre páginas y de depurar cuando el motor no te cita.

El principio correcto se llama tipado por herencia: declaras solo el subtipo más específico y dejas que la jerarquía del vocabulario implique el resto. Es la diferencia entre un grafo que describe y un grafo que afirma con precisión.

Nota de entidad: cómo un Q-ID transforma texto libre en dato estructurado

El anclaje con Q-ID es el complemento natural del tipado por herencia: un grafo donde el tipo es preciso y la entidad está anclada a fuentes verificables es el que los motores generativos comparan con confianza antes de citar.

La solución tecnológica: SemanticGEO

SemanticGEO es un plugin de GEO para WordPress que extiende el grafo de Yoast SEO aplicando Graph Stitching. En lo que toca a los tipos, implementa exactamente el principio de este artículo:

• Tipado por herencia, sin apilar: declaras ProfessionalService o LocalBusiness y el plugin deja que la jerarquía de Schema.org implique el resto, sin sumar tipos redundantes que los validadores marcan como ruido.
• Validación en tiempo real contra la API de Wikidata: cada Q-ID se verifica en vivo; un dígito equivocado te conectaría a una entidad ajena y el plugin lo impide.
• sameAs doble (Wikipedia + Wikidata): cada entidad queda anclada a dos fuentes verificables.
• 13 packs de nicho importables: SEO, salud, legal, fintech, inmobiliario, educación y más, con sus tipos y Q-IDs correctos preconfigurados. Cero tipeo manual.
• Nodos referenciados por @id: la organización se define una vez y se referencia desde founder, provider, worksFor y publisher, sin duplicar bloques.
• llms.txt automático: generado desde el grafo, nunca desincronizado del schema.

Con la honestidad técnica que nos define: ningún plugin puede garantizar citación en motores generativos, y llms.txt es un estándar emergente aún no confirmado oficialmente. SemanticGEO se vende como lo que es: la implementación técnica más rigurosa de los factores que estos motores declaran consumir.

Preguntas frecuentes

¿Puedo declarar varios tipos en un mismo nodo de Schema.org?

Sí se puede técnicamente, pero en la mayoría de los casos es un error semántico. Como los tipos forman una jerarquía con herencia, declarar ProfessionalService ya implica LocalBusiness y Organization. Apilarlos introduce redundancia que ensucia el grafo.

¿Qué diferencia hay entre LocalBusiness y ProfessionalService?

LocalBusiness es un subtipo de Organization para negocios con presencia física (horarios, geolocalización, área de servicio). ProfessionalService es un subtipo de LocalBusiness para servicios profesionales especializados. Se elige el más específico que describa tu negocio.

¿El validador de Schema.org detecta los tipos apilados?

No siempre. El validador comprueba la sintaxis, no la consistencia semántica, así que un bloque con tipos redundantes puede pasar sin errores. El daño se manifiesta después, en la ambigüedad con la que el Knowledge Graph y los motores generativos intentan resolver tu entidad.

¿Qué es el tipado por herencia en Schema.org?

Es declarar únicamente el subtipo más específico de la jerarquía y dejar que el vocabulario implique los tipos padre y sus propiedades. Produce un grafo más limpio, más fácil de auditar y con menos señales contradictorias para el motor.

Conclusión: menos tipos, más precisión

La tentación de apilar tipos nace de una idea equivocada: que más etiquetas significan más visibilidad. En realidad, la autoridad semántica se construye con precisión: un tipo correcto, una entidad anclada, un grafo coherente. Si quieres profundizar en la arquitectura de grafos, revisa qué es el Graph Stitching, qué son los datos estructurados y JSON-LD, y por qué el Schema Markup tradicional ya no alcanza frente al Knowledge Graph.