Conflictos de Schema en WordPress: cómo detectar JSON-LD duplicado antes de que la IA malinterprete tu sitio

Conflictos de Schema en WordPress: cómo detectar JSON-LD duplicado antes de que la IA malinterprete tu sitio

Los conflictos de Schema en WordPress aparecen cuando varios plugins, el tema o código personalizado emiten datos estructurados sobre la misma página sin compartir una identidad común. El resultado puede ser JSON-LD técnicamente válido, pero con organizaciones, autores, productos o FAQ duplicados que un motor generativo no puede relacionar con certeza.

La corrección no consiste en añadir más marcado. Consiste en identificar qué emisor crea cada nodo, definir un identificador canónico con @id y conectar las referencias al mismo grafo. Esa diferencia separa una colección de scripts de un Knowledge Graph que ayuda a los sistemas de búsqueda a resolver quién publica, qué ofrece y qué entidad respalda el contenido.

Para una agencia SEO o un desarrollador WordPress, esta auditoría importa especialmente ahora: el Schema Markup tradicional no equivale a un Knowledge Graph. Un validador puede aprobar las propiedades individuales y, aun así, dejar sin resolver las relaciones entre ellas.

Qué es un conflicto de Schema y por qué afecta a la comprensión de tu sitio

Un conflicto de Schema ocurre cuando dos o más fuentes describen la misma entidad con datos incompatibles, repetidos o aislados. Es frecuente encontrar a Yoast SEO emitiendo Organization, un plugin de snippets emitiendo otro Organization, WooCommerce creando Product y un bloque manual añadiendo un producto paralelo. Cada fragmento puede parecer correcto por separado; juntos elevan la ambigüedad.

El problema no es que existan muchos nodos. Un sitio sólido puede tener WebSite, WebPage, Article, Person, Organization y Service. El problema surge cuando el mismo negocio se declara tres veces, con URLs distintas, logotipos diferentes o sin relaciones explícitas. Los motores no deberían tener que adivinar si esos nodos representan la misma empresa.

Duplicación no es redundancia útil

La redundancia útil repite una referencia al mismo @id: un artículo puede nombrar a su editor y su publisher mediante el nodo canónico de la organización. La duplicación dañina vuelve a imprimir todo el objeto Organization con variaciones. En el primer caso hay una identidad consolidada; en el segundo, hay candidatos que compiten por serla.

Las cinco fuentes más habituales de JSON-LD duplicado en WordPress

  • Plugin SEO y plugin de Schema a la vez: ambos pueden publicar Organization, WebPage, breadcrumbs y Article.
  • Tema o constructor visual: algunas plantillas incorporan LocalBusiness, FAQ o producto sin que el editor lo haga visible.
  • WooCommerce más un generador genérico: el catálogo ya publica Product, Offer y reseñas; un segundo plugin puede replicar esas ofertas.
  • Bloques JSON-LD pegados manualmente: suelen sobrevivir a cambios de plugin y vuelven a declarar entidades antiguas.
  • Versiones HTTP y HTTPS: un @id con http:// y otro con https:// pueden partir la identidad de la misma organización.

Esta revisión también evita un error de gobierno de datos: resolver una falla visual agregando un tercer plugin. Antes de cambiar el stack, hay que establecer cuál será el emisor principal y qué nodos debe extender cada componente.

Cómo auditar conflictos de Schema paso a paso

1. Extrae el marcado que realmente llega al navegador

Abre el código fuente de una página representativa, no solo el editor, y localiza todos los scripts con application/ld+json. Anota su origen si el código lo revela, los tipos emitidos y cada valor de @id. Repite el proceso en una entrada, una página de servicio y un producto: los conflictos cambian según la plantilla.

2. Construye un inventario de entidades, no solo de tipos

Un inventario útil responde cuatro preguntas: ¿cuántos nodos Organization hay?, ¿cuántos Person describen al mismo autor?, ¿qué URL identifica al publisher?, ¿qué relaciones apuntan a cada @id? Esta mirada de Entity SEO detecta incoherencias que quedan ocultas al contar únicamente etiquetas.

Señal encontradaRiesgo semánticoAcción recomendada
Dos Organization con URL distintaEntidad corporativa fragmentadaConservar un @id canónico y referenciarlo
Dos Product para la misma fichaOfertas, stock o reseñas contradictoriasDejar a WooCommerce como emisor y enriquecerlo
FAQPage manual y FAQ de pluginPreguntas repetidas o mainEntity en conflictoElegir una fuente visible de verdad
HTTP y HTTPS en identificadoresGrafo dividido por URLNormalizar la URL canónica a HTTPS

3. Revisa relaciones, no solo objetos

Una auditoría completa verifica que publisher, provider, worksFor, founder y mainEntity apunten a nodos existentes mediante @id. Si una página publica un Service pero no lo vincula con el proveedor corporativo, la información existe pero queda aislada. Este es el motivo por el que Graph Stitching es una decisión de arquitectura y no un detalle decorativo.

4. Valida la sintaxis y luego interpreta el grafo

Un validador de Schema.org ayuda a detectar propiedades inválidas y tipos incompatibles. Sin embargo, no reemplaza la revisión editorial y técnica del grafo: puede confirmar que dos objetos Organization son válidos sin determinar cuál describe al negocio real. La pregunta final debe ser: ¿un tercero puede seguir las relaciones y llegar siempre a la misma identidad?

{
  "@type": "Service",
  "@id": "https://ejemplo.cl/servicio/#service",
  "provider": {
    "@id": "https://ejemplo.cl/#organization"
  }
}

El ejemplo no repite el nombre, la URL ni el logo de la organización dentro del servicio. Los referencia al nodo canónico. Esa práctica disminuye la superficie de inconsistencia cuando la empresa actualiza sus datos.

Nota de Entidad: un Q-ID convierte un nombre en una referencia verificable

Escribir «Wikidata» en texto libre puede aludir al proyecto, a una página o a una idea relacionada. Al enlazar la entidad con Q2013, validada en la API de Wikidata, se establece una referencia única. En un grafo, ese anclaje puede convivir con sameAs hacia su página de Wikipedia, reduciendo ambigüedad para personas y sistemas.

Schema válido no siempre significa entidad resoluble

Schema.org ofrece un vocabulario para describir cosas y sus relaciones. Su valor depende de cómo se use: declarar Organization es un comienzo, pero no basta si la organización no conecta con sus perfiles, fundadores, cobertura, servicios y contenidos. El objetivo no es acumular propiedades para pasar una prueba, sino mantener una representación consistente y verificable.

Esto es relevante para la Topical Authority. Un sitio que publica guías, casos y servicios sobre una especialidad debe poder expresar el vínculo entre esos contenidos y las entidades que conoce. El contenido visible sostiene la experiencia; el grafo reduce la distancia entre esa experiencia y la interpretación de las máquinas.

La solución tecnológica: SemanticGEO

SemanticGEO extiende el grafo que Yoast SEO ya genera mediante Graph Stitching. En lugar de competir con Yoast o emitir scripts aislados, conecta los nodos nuevos al grafo existente con referencias estrictas por @id. Así, Organization, Person, Service, SoftwareApplication y las entidades de una página pueden formar una estructura coherente.

Su biblioteca central permite definir una entidad una sola vez y reutilizarla, con Q-ID y enlaces sameAs a Wikipedia y Wikidata. La validación se realiza en tiempo real contra la API de Wikidata. Los 13 packs de nicho importables aceleran la configuración para agencias y equipos B2B, sin tipeo manual repetitivo ni identificadores inventados.

También normaliza relaciones, refuerza nodos Person para E-E-A-T, ancla areaServed y genera llms.txt automáticamente desde el grafo. Es importante ser precisos: ningún plugin puede garantizar una cita en un motor generativo y llms.txt es un estándar emergente sin adopción oficialmente confirmada por los proveedores de LLM. La propuesta de SemanticGEO es una implementación técnica más rigurosa para que el sitio entregue información consistente y fácil de interpretar.

Preguntas frecuentes sobre conflictos de Schema en WordPress

¿Tener dos plugins de Schema siempre genera un conflicto?

No necesariamente. Pueden coexistir si sus responsabilidades no se solapan y referencian los mismos nodos canónicos. En la práctica, conviene revisar con especial cuidado Organization, Article, Product, FAQPage y breadcrumbs, porque son los tipos que más se duplican.

¿Un validador puede detectar un Knowledge Graph fragmentado?

Detecta muchos problemas de sintaxis y propiedades, pero no sustituye una auditoría de identidad. Dos nodos válidos pueden describir a la misma entidad con datos diferentes. La auditoría debe comparar @id, URLs, relaciones y fuentes emisoras.

¿Debo borrar el Schema de Yoast para usar SemanticGEO?

No. SemanticGEO requiere Yoast SEO activo y trabaja sobre su grafo. La lógica es extender una base ya establecida mediante Graph Stitching, no reemplazarla con un conjunto paralelo de scripts.

¿Qué relación hay entre sameAs y los conflictos de entidad?

La propiedad sameAs conecta una entidad con fuentes externas que la identifican. Cuando se usa con URLs verificadas y un Q-ID correcto, ayuda a desambiguar la entidad. No corrige por sí sola los duplicados internos, pero fortalece la identidad del nodo canónico.

Menos scripts, más continuidad semántica

La salida de una auditoría de Schema no debería ser una lista de plugins nuevos. Debe ser un mapa claro de emisores, nodos canónicos y relaciones. Cuando cada página remite a la misma organización, al mismo autor y a entidades ancladas, el sitio es más mantenible y su información resulta menos ambigua.

Si administras varios WordPress y necesitas pasar de JSON-LD aislado a una arquitectura de entidades conectadas, explora cómo SemanticGEO puede integrarse sobre Yoast SEO.

Convierte tu Schema en un grafo coherente

Conecta entidades, autores, servicios y cobertura territorial sobre el grafo de Yoast mediante una implementación técnica rigurosa para WordPress.

Ver planes y precios

Comments are closed.