Instalas un plugin, aparece un bloque JSON-LD y el panel muestra una señal verde. Parece que el trabajo terminó. Sin embargo, el precio publicado no coincide con la ficha, dos herramientas describen empresas distintas y el resultado enriquecido que esperabas nunca aparece.
El Schema markup SEO requiere más que generar código sin errores de sintaxis. Debes elegir qué información describir, conectar entidades reales y comprobar que el marcado representa lo que ve la persona en cada página.
Los datos estructurados pueden ayudar a interpretar contenido y, para tipos compatibles y elegibles, permitir apariencias enriquecidas. No garantizan posiciones ni una mejora automática del CTR. Esta guía explica cómo empezar con JSON-LD y cómo evaluar el resultado con evidencia.
Schema.org y resultados enriquecidos no son lo mismo
Schema.org es un vocabulario para describir entidades y relaciones. Google admite determinadas funciones de búsqueda con requisitos propios. Que un tipo exista en Schema.org no significa que Google ofrezca un resultado enriquecido específico para él.
Por ejemplo, Service permite describir un servicio y su proveedor, pero no concede por sí mismo una tarjeta enriquecida genérica de servicios. Organization y BreadcrumbList tienen usos y documentación propios en Google.
Consulta la galería de funciones compatibles antes de definir objetivos. Así puedes distinguir una mejora de claridad semántica de una implementación orientada a una función concreta.
Qué cambió con FAQPage en 2026
Google retiró la aparición de resultados enriquecidos de FAQ a partir del 7 de mayo de 2026, según su registro oficial de actualizaciones. Por eso, una guía actual no debe prometer desplegables de preguntas frecuentes en la búsqueda mediante FAQPage.
El tipo sigue teniendo sentido dentro del vocabulario cuando describe correctamente una página de preguntas y respuestas. También puedes mantener una sección útil de dudas para tus lectores aunque no la marques.
Si ya tenías ese código, revisa qué lo genera y si aporta valor a tu arquitectura. Evita invertir en una implementación nueva bajo la expectativa de recuperar una función retirada de Google.
JSON-LD frente a microdatos
JSON-LD expresa información en un bloque de datos, normalmente dentro de una etiqueta script. Los microdatos son otra forma de marcar contenido, integrada en atributos HTML. No conviene utilizar ambos nombres como si fueran exactamente la misma técnica.
Para muchos proyectos, JSON-LD facilita mantener la representación estructurada separada de la maquetación. Su comodidad no elimina la obligación de actualizarlo cuando cambian precios, autores o servicios.
Antes de añadir código, identifica qué genera el tema, el CMS y cada plugin. Una segunda implementación puede duplicar entidades o introducir contradicciones. Decide qué sistema será responsable de cada tipo y documenta esa propiedad.
1. Define entidades e identificadores estables
Una organización, un servicio y una página no son la misma entidad. Utiliza identificadores @id estables para relacionarlos y evitar descripciones independientes difíciles de mantener.
El siguiente ejemplo usa example.com y una empresa ficticia. No está listo para copiar en producción: sustituye datos, rutas y entidades con información real visible en las páginas correspondientes. @id identifica una entidad; los fragmentos del identificador no necesitan ser nuevas páginas publicables.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "Organization",
"@id": "https://example.com/#organization",
"name": "Agencia Ejemplo",
"url": "https://example.com/"
},
{
"@type": "Service",
"@id": "https://example.com/servicios/seo/#service",
"name": "Consultoría SEO",
"serviceType": "Consultoría SEO técnica",
"url": "https://example.com/servicios/seo/",
"provider": {
"@id": "https://example.com/#organization"
},
"areaServed": {
"@type": "Country",
"name": "México"
}
}
]
}
</script>Este bloque ilustra una relación entre servicio y proveedor; no establece elegibilidad para una función enriquecida de Google. En una implementación real, describe la organización de forma completa donde corresponda y conserva referencias consistentes desde las páginas de servicio.
2. Completa Organization con datos verificables
Revisa nombre, URL, logotipo y perfiles oficiales aplicables. Si añades sameAs, utiliza páginas que identifiquen a la misma entidad, no artículos donde simplemente aparece mencionada.
No inventes un domicilio para completar campos. Tampoco publiques teléfonos personales o identificadores internos que no correspondan con la información comercial que deseas exponer.
La documentación de Organization permite revisar propiedades admitidas y condiciones. Define un registro central para actualizar estos datos cuando cambie la marca o su información pública.
3. Implementa breadcrumbs coherentes con la navegación
BreadcrumbList describe una ruta de navegación. Debe representar una jerarquía razonable para el usuario, con nombres claros y URLs pertinentes. No necesitas reproducir cada segmento técnico de una dirección si no corresponde con la estructura útil del sitio.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "BreadcrumbList",
"itemListElement": [
{
"@type": "ListItem",
"position": 1,
"name": "Inicio",
"item": "https://example.com/"
},
{
"@type": "ListItem",
"position": 2,
"name": "Servicios",
"item": "https://example.com/servicios/"
},
{
"@type": "ListItem",
"position": 3,
"name": "Consultoría SEO"
}
]
}
</script>El ejemplo supone que existe una página real de servicios. No generes enlaces a categorías inexistentes solo para llenar la cadena. Consulta los requisitos de breadcrumbs y verifica su representación en los dispositivos y resultados donde la función esté disponible.
4. Usa FAQPage únicamente con expectativas correctas
Si decides mantener ese vocabulario por una necesidad semántica propia, representa preguntas y respuestas que la página realmente ofrece. Este ejemplo es didáctico y no habilita resultados FAQ en Google:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "¿Qué incluye el diagnóstico técnico?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Incluye revisión de rastreo e indexación y un plan de prioridades."
}
}
]
}
</script>No dupliques el bloque en todas las páginas ni añadas respuestas que solo existen dentro del código. La utilidad de las preguntas debe sostenerse en la experiencia del lector, independientemente del marcado.
5. En tiendas, revisa Product y Offer por plantilla
Las fichas pueden requerir datos de producto, oferta, disponibilidad y políticas comerciales según su caso. Mantén sincronía entre contenido visible, compra y marcado.
Los cambios de moneda, descuentos y stock requieren controles. Una caché desactualizada puede describir una oferta que ya no existe. Si las variantes tienen precios distintos, verifica cómo se representa la selección y qué página se está describiendo.
La guía de SEO para eCommerce desarrolla estas dependencias. El marcado debe formar parte del sistema de catálogo, no vivir como una copia manual que nadie revisa después.
6. Valida con dos preguntas diferentes
Primero pregunta si el vocabulario y su estructura son válidos. El validador de Schema.org ayuda a revisar esa dimensión. Después pregunta si cumple los requisitos de una función concreta de Google mediante la Prueba de resultados enriquecidos.
Un tipo válido puede no ser compatible con una función enriquecida. Del mismo modo, pasar una prueba no garantiza que Google muestre esa apariencia. Sus directrices generales de datos estructurados explican estas condiciones.
Prueba URLs reales además de fragmentos. Verifica que los robots puedan acceder y que el HTML entregado contenga lo esperado. Añade muestras con casos difíciles: campos vacíos, caracteres especiales, ofertas y varias plantillas.
7. Mide CTR con capturas y comparaciones reales
Para comprobar qué ocurrió, guarda una captura del marcado validado, una del resultado observado y una exportación de rendimiento. Anota fecha, consulta, país, dispositivo y URL. Una captura demuestra una aparición puntual, no un aumento general de CTR.
Compara impresiones, clics, CTR y posición para consultas y condiciones equivalentes. Considera campañas, estacionalidad y cambios de ranking. Si la posición subió al mismo tiempo, no atribuyas todo el cambio de CTR al marcado.
No existe una imagen universal que demuestre cuánto mejorará tu negocio. El caso debe documentarse en una propiedad con datos disponibles. Evita publicar recreaciones de SERP como si fueran capturas reales o presentar porcentajes hipotéticos como resultados medidos.
Evita los errores que deterioran la implementación
Los problemas habituales incluyen entidades duplicadas, URLs de staging, precios antiguos, reseñas falsas y marcado que no corresponde al contenido. Revisa también cómo se serializa JSON: nombres con comillas o campos vacíos pueden romper una plantilla mal construida.
Asigna mantenimiento. Si el contenido cambia y el marcado queda congelado, la implementación pierde coherencia. Programa revisiones de muestras después de actualizar tema, plugins o modelos de datos.
En visibilidad generativa, conserva la misma disciplina. El marcado puede describir información, pero no garantiza citas. Nuestra guía de GEO SEO explica cómo evaluar ese objetivo por separado.
Solicita una implementación a medida
En el servicio de SEO técnico y datos estructurados revisamos contenido, plantillas y fuentes de datos antes de definir el marcado. Cuando hace falta intervenir el CMS, coordinamos el trabajo con desarrollo web.
Solicita una revisión de Schema y comparte plataforma, tipos de página y problemas detectados. El alcance debe incluir validación, responsabilidad de actualización y criterios para comprobar el resultado después de publicar.
—
Recursos y activación editorial
La plantilla CSV y el diagrama SVG incluidos en el paquete son recursos originales para adaptar al sitio. No están publicados en glitchcreativo.com: súbelos al CMS y añade sus URLs reales si quieres ofrecerlos como descargas en las entradas 1 y 6. Mientras tanto, los artículos ya contienen el formato de diagnóstico y una explicación del diagrama, sin enlaces de descarga ficticios.
Para el artículo 10, captura resultados únicamente cuando exista una implementación real y datos suficientes. No se incluyen capturas de aumentos de CTR porque no se proporcionó acceso a una propiedad ni un estudio medido. Puedes publicar la guía sin esas imágenes y añadir un caso documentado posteriormente.
Orden de publicación sugerido: 1, 6, 2, 10, 4, 7, 8, 3, 9 y 5. Publica enlaces cruzados solo hacia destinos activos y revisa si existe contenido anterior que deba actualizarse en vez de duplicarse. Si cambias un slug, actualiza todo el mapa de enlaces.
Antes de publicar: revisar autoría; confirmar alcance comercial y disponibilidad de CTA; sustituir imágenes sugeridas por material propio; comprobar URLs y canonicals; validar código adaptado; excluir las fichas SEO del cuerpo; revisar navegación móvil; registrar conversiones; y documentar fecha real de revisión.