Utilidades gratuitas

Guía completa de Schema.org, JSON-LD y resultados enriquecidos

El generador de Schema.org ayuda a crear marcado JSON-LD para artículos, productos, organizaciones, eventos, FAQ y otros tipos de páginas. Puedes copiar el código final y añadirlo al sitio para que los motores de búsqueda entiendan mejor el contenido.

Gratis Funciona en el navegador Sin registro

Selecciona el objeto que realmente se describe en la página, completa sus propiedades y obtén el código JSON-LD para insertarlo en el HTML. El generador ayuda a construir la sintaxis, pero antes de publicar debes verificar la correspondencia con el contenido visible, los requisitos del consumidor de datos elegido y la vigencia de los valores.

Schema.org, JSON-LD y resultado enriquecido — son cosas diferentes

Schema.org

Es un vocabulario común de tipos y propiedades: Article, Product, Organization, Event, name, image, offers y muchos otros. Describe qué entidades y relaciones se pueden representar de forma estructurada.

JSON-LD

Es uno de los formatos para escribir datos estructurados. El código se coloca dentro de:

<script type="application/ld+json">
    {
    "@context": "https://schema.org",
    "@type": "Article",
    "headline": "Título del artículo"
    }
    </script>

Google recomienda JSON-LD cuando es adecuado para la implementación, pero Schema.org también puede expresarse con Microdata o RDFa.

Resultado enriquecido de Google

Es una presentación especial en los resultados de búsqueda que solo admite un conjunto limitado de tipos y requiere cumplir con reglas específicas de Google. Un marcado Schema.org válido no garantiza un resultado enriquecido, una posición alta ni siquiera el uso de todas las propiedades enviadas. Por lo tanto, no se debe evaluar el marcado solo con la pregunta "¿mostrará un snippet bonito?". Debe ante todo describir correctamente la entidad real de la página.

Cómo elegir el tipo de marcado

Elige el tipo según el objeto principal de la página, no según el aspecto deseado en la búsqueda.

Tipo	Cuándo aplicarlo	Qué verificar especialmente
`Article`	artículo, noticia, reseña, publicación	título, autor o editor, fechas, imagen, relación con la página actual
`BreadcrumbList`	cadena de navegación visible o lógica	orden correcto de las posiciones y URL de cada paso
`Event`	evento concreto con fecha y formato de celebración	fecha y zona horaria, lugar o URL en línea, estado y vigencia
`FAQPage`	página con una respuesta oficial del sitio para cada pregunta	todas las preguntas y respuestas son visibles para el usuario; no marcar foros ni respuestas de usuarios
`HowTo`	instrucción paso a paso real	los pasos coinciden con el material visible; no contar con el resultado enriquecido HowTo de Google
`JobPosting`	oferta de empleo individual disponible	empleador, ubicación o formato remoto, fecha de publicación, fecha de caducidad, descripción
`LocalBusiness`	punto físico concreto u organización local	subtipo más preciso, dirección, teléfono, horario de atención y URL específica de ese punto
`Organization`	empresa, institución, marca o asociación	nombre oficial, URL, logotipo, contactos y un `@id` estable
`Person`	perfil de una persona concreta	nombre, rol, afiliación a una organización, perfiles oficiales; no presentar suposiciones como hechos
`Product`	producto concreto o variante del mismo	el producto existe en la página; precio, moneda, disponibilidad, oferta y reseñas son actuales
`Recipe`	receta culinaria	ingredientes, pasos, tiempo, porciones e imagen disponibles para el usuario
`VideoObject`	video individual en la página	título, descripción, vista previa, fecha de carga y URL accesible del video o reproductor
`WebSite`	sitio web como objeto único	URL canónica principal, nombre y relación con la organización; este tipo normalmente no se necesita en cada página como entidad independiente

En una misma página se permiten varios objetos relacionados. Por ejemplo, un artículo puede tener un autor Person, un editor Organization, migas de pan BreadcrumbList y un video incrustado VideoObject. Es mejor vincularlos mediante @id, en lugar de crear copias contradictorias.

Restricciones actuales importantes de Google

FAQPage

Google ha limitado significativamente la visualización de resultados enriquecidos de FAQ: normalmente solo están disponibles para sitios gubernamentales y médicos de autoridad reconocida. Para un sitio comercial o informativo común, un marcado FAQPage correcto puede no generar una expansión notable en los resultados. Esto no invalida el tipo FAQPage en Schema.org, pero no se puede prometer al usuario que "las preguntas aparecerán en Google".

HowTo

Google ha dejado de mostrar resultados enriquecidos de HowTo. El tipo HowTo sigue en el vocabulario de Schema.org y puede ser utilizado por otros consumidores, pero añadirlo únicamente por el antiguo resultado enriquecido de Google ya no tiene sentido.

Otros tipos

Organization, Person y WebSite ayudan a describir entidades, pero no todos crean un resultado enriquecido visual individual. El soporte y la apariencia de las funciones de búsqueda cambian, por lo que antes de implementar debes consultar la galería actual de Google Search Central.

Regla principal: el marcado debe coincidir con el contenido visible

No agregues en JSON-LD información que no esté presente en la página o que la contradiga. Esto aplica especialmente a:

precio y disponibilidad del producto;
calificación y número de reseñas;
preguntas y respuestas;
fecha y lugar del evento;
autor del contenido;
dirección y horario de la empresa;
condiciones de la oferta de empleo;
ingredientes y pasos de la receta.

El marcado no es un lugar para texto publicitario oculto ni para palabras clave adicionales. El usuario y el motor de búsqueda deben recibir información coherente.

Los campos obligatorios dependen de quién lea el marcado

Schema.org define un vocabulario, pero no una lista universal única de "campos obligatorios" para todos los sistemas. El consumidor concreto —por ejemplo, Google Search— establece sus propias propiedades obligatorias y recomendadas para una función de búsqueda determinada. Por lo tanto, son posibles tres resultados de verificación diferentes:

El JSON es sintácticamente correcto.
Los tipos y propiedades existen en Schema.org.
El marcado cumple con los requisitos del resultado enriquecido específico de Google.

Superar la primera o segunda etapa no garantiza la tercera.

Cómo completar URL, fechas e identificadores

Usa URL absolutas

Preferiblemente:

https://ejemplo.com/catalogo/producto-1

En lugar de:

/catalogo/producto-1

Los enlaces deben ser accesibles para el robot de búsqueda, no requerir autorización y apuntar a un recurso estable.

Indica las fechas en ISO 8601

Fecha:

2026-08-04

Fecha y hora con zona horaria:

2026-08-04T18:30:00+02:00

Para eventos es especialmente importante no perder la zona horaria. De lo contrario, la hora podría interpretarse incorrectamente.

Crea un `@id` estable

@id es el identificador de la entidad, a menudo en forma de URL con fragmento:

https://ejemplo.com/#organizacion
    https://ejemplo.com/articulo/#paginaweb
    https://ejemplo.com/articulo/#autor

La misma organización en diferentes páginas debe referenciar un identificador estable único, no parecer múltiples empresas independientes.

Cómo describir múltiples entidades con `@graph`

Para objetos relacionados es conveniente usar un solo bloque:

{
    "@context": "https://schema.org",
    "@graph": [
        {
        "@type": "Organization",
        "@id": "https://ejemplo.com/#organizacion",
        "name": "Empresa Ejemplo",
        "url": "https://ejemplo.com/"
        },
        {
        "@type": "Article",
        "@id": "https://ejemplo.com/blog/articulo/#articulo",
        "headline": "Título del artículo",
        "publisher": {
            "@id": "https://ejemplo.com/#organizacion"
        }
        }
    ]
    }

Así los objetos están explícitamente relacionados y no es necesario repetir todos los datos de la organización dentro de cada artículo.

Dónde insertar JSON-LD

El bloque <script type="application/ld+json"> se puede colocar en <head> o en <body> de la página HTML. Es más importante que:

el código esté presente en el HTML final o sea accesible después de un renderizado correcto;
se refiera específicamente a la página actual;
el CMS lo escape sin dañar comillas ni caracteres;
una misma plantilla no inserte los mismos datos en páginas diferentes;
el precio, disponibilidad y fechas dinámicos se actualicen junto con el contenido visible.

Después de la implementación, verifica no solo el código del generador, sino también la URL publicada: la plantilla, el plugin o JavaScript pueden modificar el marcado final.

Dos niveles diferentes de validación

Schema Markup Validator

Verifica la sintaxis y el uso del vocabulario Schema.org. Es adecuado para ver los tipos, propiedades y problemas generales del marcado encontrados.

Google Rich Results Test

Muestra si Google reconoce en la página un tipo compatible de resultado enriquecido y si se cumplen sus requisitos especiales. La herramienta no confirma que la expansión aparecerá necesariamente en la búsqueda. Después de la publicación, también es útil verificar la URL mediante URL Inspection en Google Search Console para ver la versión procesada por Google y los elementos detectados.

Error y advertencia no son categorías universales

El validador puede considerar la ausencia de una propiedad como una advertencia, mientras que para un consumidor concreto podría ser obligatoria. Y viceversa, Schema.org permite una propiedad que Google no utiliza para la función deseada. Evalúa el mensaje según cuatro preguntas:

¿Está rota la sintaxis JSON?
¿Existen el tipo y la propiedad en Schema.org?
¿Está la propiedad correctamente anidada y tiene un valor válido?
¿La requiere la función de búsqueda elegida u otra integración?

Errores frecuentes

Tipo inadecuado: una página de categoría de productos se marca como un solo Product, aunque no hay un producto individual ni una oferta única. O un artículo normal recibe FAQPage solo porque al final hay un pequeño bloque de preguntas.
Marcado que no coincide con la página: en el código se indica precio antiguo, calificación inexistente, preguntas ocultas u otro autor.
Entidades en conflicto: varios plugins crean bloques Organization diferentes con nombres, logotipos y URL distintos. Los objetos no están vinculados mediante un @id común.
Anidado incorrecto: por ejemplo, price se escribe directamente en Product, aunque la oferta normalmente se describe mediante un objeto Offer en la propiedad offers.
Tipo de valor incorrecto: la fecha se escribe como texto arbitrario, el precio contiene la moneda en la misma cadena, el valor booleano se pasa como una frase y el campo que espera una URL contiene una ruta relativa.
Imágenes y páginas inaccesibles: la URL devuelve error, está bloqueada por autorización o robots.txt, redirige mediante un enlace temporal inestable o apunta a una imagen que el buscador no puede obtener.
Datos dinámicos desactualizados: el evento ya terminó, la oferta de empleo está cerrada, el producto no está disponible, pero el marcado sigue enviando el estado antiguo.
Errores de JSON: comillas simples o tipográficas; coma sobrante después de la última propiedad; corchete sin cerrar; comentarios dentro del JSON; salto de línea sin escapar dentro de un valor de cadena; clave duplicada en un mismo objeto.

Flujo de trabajo de implementación

Define el objeto principal y el propósito del marcado.
Consulta los requisitos actuales de Schema.org y del consumidor de datos necesario.
Elige el tipo más preciso.
Completa solo las propiedades verídicas presentes en la página.
Genera el JSON-LD.
Verifica el código en Schema Markup Validator.
Si necesitas un resultado enriquecido compatible con Google, prueba con Rich Results Test.
Inserta el código en la versión de prueba de la página.
Vuelve a verificar la URL publicada, no solo el fragmento aislado.
Configura la actualización de valores dinámicos y nuevas verificaciones después de cambios en la plantilla.

Lista de verificación rápida antes de publicar

se ha elegido el tipo del objeto real de la página;
los datos coinciden con el contenido visible;
no hay calificaciones, reseñas o propiedades inventadas;
las URL son absolutas, accesibles y canónicamente consistentes;
las fechas están en un formato comprensible y con zona horaria cuando sea necesario;
el precio y la moneda están en campos separados;
las mismas entidades están vinculadas mediante un @id estable;
no hay marcado conflictivo de otro módulo;
el código ha pasado las verificaciones adecuadas;
la URL publicada contiene el mismo JSON-LD correcto;
los datos dinámicos se actualizarán.

Preguntas frecuentes

¿Schema.org garantiza un snippet enriquecido?

No. Un marcado correcto hace que la página sea apta para el procesamiento, pero el motor de búsqueda decide de forma autónoma si usarlo y cómo mostrar el resultado.

¿Es necesario añadir Schema.org en cada página?

Solo donde haya una entidad y propiedades útiles y verídicas para describirla. La inserción masiva del mismo bloque sin relación con el contenido crea errores y contradicciones.

¿Se pueden dejar propiedades que el usuario no ve?

Los identificadores y relaciones técnicas pueden no mostrarse como texto independiente, pero los datos factuales sobre el producto, calificación, preguntas, evento y otros objetos deben coincidir con el contenido disponible para el usuario y con las reglas del consumidor.

¿Dónde colocar el código — en `head` o `body`?

JSON-LD puede estar en ambos lugares. Lo importante es el HTML final correcto, la accesibilidad del marcado para el procesador y la correspondencia con la página actual.

¿Por qué Schema Markup Validator no muestra error y Google sí?

La primera herramienta verifica el vocabulario Schema.org y la estructura del marcado, mientras que Google aplica además los requisitos de la función de búsqueda específica.

¿Vale la pena marcar FAQPage ahora?

Se puede, cuando la página es realmente un FAQ y el tipo es útil para otros consumidores de datos. Pero para la mayoría de los sitios no se debe esperar un resultado enriquecido FAQ de Google.

¿Es necesario HowTo para Google?

Google ya no muestra resultados enriquecidos HowTo. El tipo puede seguir siendo útil como descripción semántica para otros sistemas, pero no se debe esperar el antiguo efecto en la búsqueda de Google.

Herramientas relacionadas

Diffchecker; Procesador de textos; Base64.

Materiales oficiales

Recomendaciones editoriales generales para la sección

1. No duplicar el mismo bloque comercial dentro de cada texto útil

El bloque sobre "auditoría SEO completa, herramientas para aumentar la visibilidad en IA y automatización" se puede dejar como un CTA visual separado después del material principal. No debe insertarse en la estructura del artículo entre secciones útiles: rompe el flujo de lectura y se ve igual en las nueve páginas. Es mejor usar un breve enlace contextual que corresponda a la herramienta. Por ejemplo:

después del generador UTM — a informes por canales y conversiones;
después del combinador — a verificación de frecuencia, clustering y asignación de consultas a páginas;
después de Schema — a auditoría de datos estructurados;
después de Diffchecker — a monitoreo de cambios en páginas;
después de eliminar duplicados — a importación de semántica o URL al proyecto.

2. No hacer secciones idénticas de "Ventajas" y "Para quién es" por obligación de plantilla

Su contenido casi siempre se convierte en repeticiones: "rápido", "cómodo", "gratuito", "para especialistas y profesionales". Es más útil dejar escenarios concretos, limitaciones, ejemplos y FAQ. Los breves indicadores "gratuito", "en el navegador", "sin registro" ya se muestran junto a la herramienta.

3. Alinear las promesas con la implementación real

Antes de publicar, los desarrolladores deben confirmar:

si el procesamiento se realiza completamente en el navegador o si los datos se envían al servidor;
qué límites existen en cuanto a volumen de texto y número de líneas;
si los datos originales o los resultados se conservan;
qué algoritmo y biblioteca se utilizan para la detección de idioma;
cómo exactamente Diffchecker compara palabras y líneas;
si la eliminación de duplicados distingue entre mayúsculas y minúsculas y espacios, y en qué orden se aplican las acciones;
si el generador de contraseñas utiliza una fuente de aleatoriedad criptográficamente fuerte;
qué codificación aplica el convertidor Base64;
si admite Base64url o solo Base64 estándar.

Después de confirmarlo, estos detalles se pueden incluir en un bloque breve "Procesamiento y privacidad" en cada página. No se puede prometer procesamiento local y ausencia de almacenamiento solo porque la herramienta funciona visualmente en el navegador.

4. Mostrar las limitaciones junto a la función, no esconderlas al final

Advertencias especialmente importantes:

las etiquetas UTM no se colocan en enlaces internos;
Diffchecker no verifica el significado ni la corrección factual;
el combinador no confirma la demanda ni crea la estructura del sitio automáticamente;
Base64 no cifra los datos;
no se debe convertir toda la URL a minúsculas sin verificación;
la contraseña no se puede considerar criptográficamente fuerte sin verificar el generador;
un Schema.org válido no garantiza un resultado enriquecido.

5. Agregar enlaces internos según la siguiente acción del usuario

En lugar de una lista general de todas las utilidades, coloca dos o tres enlaces realmente relacionados al final de la página. El texto del enlace debe explicar la continuación del escenario: "Limpiar la lista obtenida", "Comparar dos versiones", "Eliminar combinaciones repetidas", "Verificar el idioma del texto".

6. No marcar FAQ solo para prometer un snippet enriquecido

Las FAQ en estos textos son útiles para el usuario y pueden permanecer en la página. Pero la decisión de añadir FAQPage debe tomarse por separado, considerando las reglas de Schema.org y las restricciones actuales de los motores de búsqueda. Para sitios comunes, Google actualmente no suele mostrar resultados enriquecidos de FAQ.

7. Orden recomendado de implementación

Diffchecker, detección de idioma y UTM — actualmente tienen menos material útil.
Eliminación de duplicados — corregir urgentemente el consejo de convertir todas las URL a minúsculas.
Base64 — reemplazar "descifrar" por "decodificar" y añadir Base64url.
Generador de contraseñas — actualizar las recomendaciones de longitud y verificar la implementación de la generación aleatoria.
Schema.org — reemplazar el texto actual excesivamente largo y repetitivo por una guía más compacta pero técnicamente precisa.
Combinador y procesador de textos — mantener las partes fuertes, añadir limitaciones y un orden práctico de acciones.

¿Necesitas una auditoría SEO completa, herramientas para aumentar la visibilidad en IA y automatización?

La búsqueda está cambiando: ya no bastan las posiciones clásicas; también importan la visibilidad de tu sitio en respuestas de IA, la calidad del contenido, las brechas frente a la competencia y el rendimiento de la publicidad. Labrika analiza tu sitio según más de 400 factores y te ofrece decenas de herramientas de crecimiento: auditoría SEO, análisis con IA, redactor con IA, posiciones en buscadores y en IA, análisis de campañas PPC, competidores y cambios en el sitio. Prueba Labrika y descubre si tu sitio está listo para competir no solo en Google, sino también en los nuevos asistentes de IA y motores de búsqueda.

Registrarse