Los datos estructurados sirven para describir de forma explícita qué representa el contenido de una página. En WordPress suelen implementarse mediante vocabulario de Schema.org y, en la mayoría de los casos, con formato JSON-LD.
La parte importante no es añadir el mayor número posible de tipos de Schema, sino utilizar el marcado que corresponde al contenido real. Un marcado técnicamente válido puede seguir siendo incorrecto si describe algo que la página no muestra o exagera información que no existe.
Qué son los datos estructurados
Google define los datos estructurados como un formato estandarizado para proporcionar información sobre una página y clasificar su contenido. Esa información puede ayudar al buscador a entender mejor qué está viendo y, cuando se cumplen los requisitos de una función concreta, puede hacer que una URL sea apta para determinados resultados enriquecidos.
Eso no significa que implementar Schema garantice una apariencia especial en Google. La propia documentación de Search Central deja claro que cumplir los requisitos hace que una función sea elegible, pero no obliga a Google a mostrarla.
JSON-LD, Microdata o RDFa
Google admite los tres formatos. Para la mayoría de proyectos WordPress, JSON-LD suele ser la opción más mantenible porque el marcado se mantiene separado del HTML visible. Google lo recomienda de forma general cuando la configuración del sitio lo permite.
Un ejemplo mínimo de JSON-LD tiene esta forma:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "BlogPosting",
"headline": "Título del artículo"
}
</script>Ese ejemplo solo ilustra la estructura. Un marcado real debe incluir las propiedades adecuadas, valores verdaderos y URLs que correspondan con la página publicada.
Qué Schema tiene sentido en una web WordPress corporativa
No existe una lista universal. El tipo correcto depende de la función de cada URL. En una web corporativa como Gonzalo CN, los casos más habituales pueden ser los siguientes.
WebSite
Describe el sitio web como entidad. Normalmente se utiliza a nivel global y no es necesario duplicarlo manualmente en cada entrada si el plugin SEO o el tema ya lo genera.
Organization o Person
Debe elegirse según la identidad real que representa la web. Google recomienda utilizar el subtipo más específico que describa correctamente la organización cuando se emplea Organization. Si la presencia digital corresponde principalmente a una persona profesional, Person puede ser más coherente.
Lo importante es no inventar propiedades: logos, perfiles sociales, datos de contacto o identificadores deben corresponder a información verificable.
BlogPosting o Article
Para entradas del blog, BlogPosting es un subtipo de Article definido por Schema.org. Google admite Article, NewsArticle y BlogPosting para contenido editorial y puede utilizar propiedades como el titular, la imagen, las fechas de publicación y modificación o la autoría para comprender mejor la página.
En un blog técnico convencional no tiene sentido marcar una entrada como NewsArticle solo porque se haya publicado recientemente. El tipo debe reflejar la naturaleza del contenido.
BreadcrumbList
Es útil cuando la web utiliza migas de pan visibles y coherentes con la jerarquía real. El marcado debe representar la navegación que existe, no inventar una arquitectura distinta para los buscadores.
Service
Puede ser apropiado en páginas que describen servicios reales, como desarrollo WordPress o posicionamiento SEO. No debe utilizarse para convertir cualquier página informativa en una página comercial.
FAQPage: cuidado con usarlo por rutina
Que una página incluya preguntas frecuentes no significa que debamos añadir marcado indiscriminadamente. El Schema debe corresponder al contenido visible y, además, conviene revisar qué funciones de resultados enriquecidos admite actualmente Google y bajo qué condiciones. Añadir marcado solo para intentar obtener más espacio visual en los resultados es una mala práctica si no representa correctamente la página.
El error más habitual: duplicar Schema
En WordPress es frecuente que el marcado venga de varias capas al mismo tiempo:
- el plugin SEO;
- el tema;
- un plugin específico de Schema;
- bloques o plugins de contenido;
- código personalizado.
El resultado puede ser un grafo con entidades repetidas, autores diferentes, organizaciones duplicadas o propiedades contradictorias. Antes de instalar otro plugin, conviene inspeccionar el marcado que ya se está generando.
Más Schema no significa mejor SEO
Los datos estructurados no sustituyen a una buena arquitectura, a un contenido útil ni a una correcta indexación. Son una capa semántica adicional. Si una entrada está aislada, tiene contenido pobre o presenta señales contradictorias, añadir JSON-LD no resuelve esos problemas.
Por eso conviene abordar primero la base: arquitectura, rastreo, indexación, contenido y enlazado interno. La guía de arquitectura SEO y canibalización explica cómo separar intenciones antes de añadir capas técnicas.
Qué propiedades deben ser reales
Un principio sencillo ayuda a evitar la mayoría de errores: el marcado debe describir lo que el usuario puede comprobar en la página. Por ejemplo:
- el
headlinedebe corresponder al artículo; - la imagen debe representar el contenido marcado;
- el autor debe ser el autor real;
- las fechas deben coincidir con la publicación y actualización reales;
- la entidad de empresa o persona debe ser la que realmente está detrás del sitio;
- una valoración, precio o FAQ no debe inventarse para completar campos.
Google advierte expresamente contra el marcado engañoso o que no representa el contenido principal de la página.
Cómo validar los datos estructurados
Una implementación correcta debería pasar por varias comprobaciones:
- Revisar el HTML renderizado: confirmar qué JSON-LD llega realmente al navegador.
- Usar Rich Results Test: comprobar si Google detecta errores críticos para las funciones que admite.
- Revisar Schema.org Validator: útil para validar vocabulario y estructura más allá de las funciones específicas de Google.
- Usar inspección de URL: comprobar cómo Google accede a la página publicada.
- Vigilar cambios: una actualización del tema o del plugin SEO puede modificar el grafo sin que el contenido visible cambie.
Checklist práctica para WordPress
- Identifica qué plugin o componente genera actualmente el Schema.
- No instales un segundo sistema sin revisar el primero.
- Utiliza tipos que describan la función real de cada URL.
- Evita propiedades vacías, inventadas o inconsistentes.
- Comprueba autor, fechas, imagen y entidad principal.
- Valida el resultado renderizado, no solo la configuración del panel.
- Repite la comprobación después de cambios importantes de tema, SEO o plantillas.
Fuentes oficiales
- Google Search Central: introducción a los datos estructurados.
- Google: directrices generales de datos estructurados.
- Google: datos estructurados Article, NewsArticle y BlogPosting.
- Schema.org: BlogPosting.
Conclusión
El mejor Schema no es el más complejo, sino el que describe correctamente la página, se mantiene sin contradicciones y puede validarse después de cada cambio. En WordPress, el primer paso debería ser siempre descubrir qué marcado ya existe antes de añadir otra capa.
Si necesitas revisar el SEO técnico de una instalación WordPress, puedo ayudarte a detectar duplicidades, problemas de indexación y marcado inconsistente desde el servicio de SEO para WordPress.
