Cómo probar los rich snippets (y corregir errores de schema)

TL;DR: Prueba la elegibilidad para rich snippets con la Rich Results Test de Google. Usa el modo URL para la página publicada, corrige cada error y trata las advertencias como mejoras opcionales. Después, supervisa el informe correspondiente en Google Search Console. Una prueba aprobada significa que la página es elegible para un resultado enriquecido, no que vaya a recibir uno.

La elección de la herramienta importa. En su documentación de Search Central sobre datos estructurados, Google describe la Rich Results Test como “la herramienta oficial de Google para probar tus datos estructurados y ver qué rich results de Google se pueden generar a partir de los datos estructurados de tu página”.

Ahí es donde empiezo cuando alguien me pide que pruebe la elegibilidad para rich snippets. No con una extensión de navegador, un tic verde de un plugin, o la antigua Structured Data Testing Tool que se mencionaba en algún tutorial viejo.

Una corrección de terminología: Google ahora los llama rich results. “Rich snippet” es el término más antiguo que la gente sigue usando. Ambos describen listados de búsqueda mejorados que pueden incluir valoraciones, precios, imágenes, breadcrumbs, fechas de eventos, detalles de recetas y otra información además del título y la descripción estándar.

Los datos estructurados no son el resultado de búsqueda en sí. Son una descripción legible por máquina de la página, normalmente escrita como JSON-LD. Google también puede analizar microdatos y RDFa, pero JSON-LD suele ser más fácil de generar, inspeccionar y mantener sin enredar el marcado dentro de HTML visible.

Los datos estructurados válidos crean elegibilidad. Google sigue decidiendo si una mejora aparece para una página y una consulta concretas. Esa diferencia explica buena parte de los informes de “la prueba pasa, pero no veo el rich snippet”.

Cómo probar un rich snippet correctamente

La Rich Results Test tiene modos URL y Code. Se solapan, pero no demuestran lo mismo.

1. Abre la Rich Results Test de Google.
2. Selecciona URL para una página publicada o Code para HTML o JSON-LD que aún no se haya desplegado.
3. Ejecuta la prueba y deja que Google obtenga, renderice o procese la entrada.
4. Abre cada tipo de rich result detectado en lugar de detenerte en el resumen.
5. Revisa los errores, las advertencias y las propiedades analizadas de cada elemento.
6. Corrige cada error y vuelve a ejecutar la prueba.
7. Despliega el cambio, limpia los caches relevantes y prueba de nuevo el URL en vivo.
8. Cuando Google vuelva a rastrear las páginas afectadas, revisa el informe correspondiente en Search Console y valida allí la corrección.

Empieza con el modo URL para páginas de producción

El modo URL responde a la pregunta útil en producción: ¿Qué puede recuperar Google de este URL ahora mismo?

Tu JSON-LD puede ser perfecta dentro de un campo del CMS y estar ausente de la página publicada. Una condición de la plantilla puede suprimirla, el caché puede servir la versión anterior, un error de JavaScript puede bloquear la inyección, o el despliegue en producción puede omitir completamente el componente. El editor es una prueba de intención. El URL en vivo es una prueba de salida.

El modo URL también renderiza páginas, así que puede detectar datos estructurados insertados mediante JavaScript. Aun así, suelo preferir JSON-LD renderizado en servidor cuando es práctico, porque elimina otro punto de fallo (no todas las implementaciones necesitan otra pieza móvil).

Durante nuestra migración de enero de 2026 de seojuice.io a seojuice.com, las pruebas representativas con URLs en vivo formaron parte de la checklist de lanzamiento. Una migración puede conservar la plantilla del schema mientras cambia canonicals, rutas de producción, caches y la salida de la página alrededor de ella. Probar solo el fragmento de JSON-LD habría ignorado la mayor parte del riesgo de la migración.

Usa el modo Code antes de publicar

El modo Code es útil mientras construyes o editas el marcado. Pega el HTML o JSON-LD relevante, ejecuta la prueba y repara la estructura antes de tocar producción.

Pega un fragmento “crudo” como este marcado de Article y pruébalo antes de que la página salga:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "How to Test Rich Snippets",
  "author": { "@type": "Person", "name": "Vadim Kravcenko" },
  "datePublished": "2026-07-19"
}
</script>

Para problemas persistentes, prueba ambos modos. El modo Code te dice si el marcado propuesto es aceptable. El modo URL te dice si esa versión llegó a la página. Esos resultados a menudo divergen, y esa divergencia es la pista, no una molestia.

Si necesitas construir primero el JSON-LD, usa nuestro generador de schema markup y luego pasa su salida por la prueba de Google. Un generador puede reducir errores de corchetes, anidación y propiedades. Pero no puede verificar que el CMS haya suministrado los datos correctos ni que producción haya renderizado el bloque final.

Errores que bloquean elegibilidad; advertencias que suelen no

Esta distinción conviene conservarla al leer la salida de la prueba.

Un elemento significa un objeto concreto de datos estructurados detectado en la página. Un solo URL puede contener varios elementos y varios tipos de schema, y cada uno puede tener un estado distinto.

He visto equipos eliminar una docena de advertencias mientras dejaban sin resolver un error de propiedad obligatoria. Eso invierte la prioridad. Primero arregla los bloqueos, vuelve a ejecutar la prueba y pasa las advertencias realmente útiles a un backlog de optimización.

Una advertencia también puede revelar datos de origen débiles. Por ejemplo, una imagen o un identificador opcional pueden ayudar a Google a entender y presentar un Product de forma más completa. Pero “recommended” no significa “secretamente obligatorio” (y añadir valores inventados para silenciar una advertencia es peor que dejarla tal cual).

Cómo corregir errores de schema recurrentes

Propiedades obligatorias que faltan

La Rich Results Test normalmente indica qué propiedad falta. Empieza por ahí, en lugar de cambiar plugins o copiar el JSON-LD de otro sitio.

Un Product puede estar faltando su nombre o la información necesaria de offers, review o aggregate-rating. Una Recipe puede estar faltando una imagen. Los requisitos difieren según el tipo de rich-result, así que abre la documentación de Google para la función detectada y compara la estructura esperada con el elemento analizado.

Luego rastrea la propiedad que falta hacia arriba. Si una plantilla espera un campo de precio, autor, imagen o fecha y el registro del CMS está vacío, editar el JSON-LD generado trata el síntoma. En su lugar, corrige el modelo de contenido, la regla de validación o el fallback de plantilla.

Por lo que vemos en SEOJuice a través de varios sitios, los fallos “incómodos” tienden a ocurrir en esa entrega entre la lógica de schema válida y los datos incompletos de la página. El generador sabe dónde va cada valor; no puede inventar un precio real ni una reseña visible que la página no contiene. Y tampoco debería hacerlo.

Tipos incorrectos y formatos de valor

No todas las propiedades de schema aceptan texto plano. Una propiedad puede requerir un número, una URL, una Offer, un PostalAddress u otro objeto anidado. Un valor puede parecer razonable para un lector y aun así tener el tipo legible por máquina equivocado.

Abre el elemento afectado en la prueba, localiza la propiedad exacta y compara su valor con el tipo esperado. Si la plantilla genera el mismo error en un URL, prueba varias otras páginas usando esa misma plantilla. Un fallo suele ser una muestra de un problema más grande, no una página aislada.

Corregir la plantilla una vez es lo eficiente. Corregir 80 páginas generadas a mano son 80 oportunidades para cometer el mismo error de nuevo (o 79, si la suerte acompaña con la primera edición).

Fechas no válidas

Propiedades como datePublished, dateModified y startDate necesitan valores ISO 8601 legibles por máquina. Un CMS puede mostrar “July 19, 2026” correctamente a los usuarios mientras envía al schema una cadena localizada o ambigua.

Corrige el formateador de fechas a nivel de plantilla. Además, revisa las zonas horarias de eventos y offers; una marca temporal sintácticamente válida puede aun así comunicar la hora de inicio o expiración incorrecta.

Schema presente en el editor pero ausente en la página

Pasa el URL de producción por la Rich Results Test. Si no se detecta el tipo esperado, inspecciona la salida real en lugar de editar repetidamente el objeto de schema.

• Confirma que el JSON-LD aparece en la página entregada o renderizada.
• Revisa las condiciones del CMS y del tema que controlan dónde se inserta.
• Revisa la configuración de plugins y las exclusiones.
• Limpia caches de página, CDN y de la aplicación cuando aplique.
• Comprueba si falla la ejecución de JavaScript antes de la inyección del schema.
• Confirma que la lógica de consentimiento o personalización no lo oculte a los crawlers.

SEOJuice genera automáticamente schema en las páginas que gestionamos, pero Lida y yo aún probamos salidas representativas. Somos un equipo de dos personas, así que la automatización es esencial. Tratar la automatización como infalible solo automatizaría nuestro punto ciego.

Marcado duplicado o en conflicto

Una página puede recibir schema desde su tema, plugin SEO, plugin de comercio, un plugin especializado de schema y JSON-LD personalizado al mismo tiempo. La Rich Results Test separa los elementos detectados, lo que facilita encontrar copias incompletas o inesperadas.

No celebres un Product válido mientras ignoras un segundo bloque de Product roto. Identifica qué sistema genera cada objeto y elige un propietario para ese tipo de schema. Desactivar la salida redundante suele ser más seguro que intentar mantener sincronizados varios generadores.

Ojo antes de borrar aparentemente duplicado Organization o WebSite, eso sí. Objetos de aspecto similar pueden describir entidades distintas o cumplir propósitos diferentes a nivel de página. Primero compara sus identificadores, tipos y relaciones (esta es una de las áreas donde “eliminar duplicados” es demasiado burdo).

Tu marcado debe coincidir con el contenido visible de la página

En términos técnicos, el marcado puede ser válido y aun así vulnerar las políticas de datos estructurados de Google. Un validador comprueba si los datos se pueden analizar; no certifica que las afirmaciones sean veraces.

“No marques contenido que no sea visible para los lectores de la página.”

Las directrices generales sobre datos estructurados de Google añaden: “Tus datos estructurados deben ser una representación fiel del contenido de la página”. La consecuencia también es explícita: “Una acción manual sobre datos estructurados significa que una página pierde la elegibilidad para aparecer como rich result”.

No agregues estrellas agregadas de reseñas si los usuarios no pueden encontrar esas reseñas en la página. No marques una fecha de evento que la página no muestra. No conviertas un artículo ordinario en un objeto Recipe solo porque el resultado de receta se vería más destacado.

Esto también aplica a valores desactualizados. Si el precio visible del producto cambia pero el JSON-LD en caché conserva el precio antiguo, el marcado ya no representa la página. Puede tener una sintaxis perfecta y aun así estar mal.

La antigua Structured Data Testing Tool ya no existe

Google dejó obsoleta su antigua Structured Data Testing Tool en 2020. La validación genérica de schema.org ahora continúa a través del Schema Markup Validator, mientras que Google indica que la verificación de elegibilidad para rich results se haga con la Rich Results Test.

• Rich Results Test: comprueba si Google puede generar una de sus funciones de búsqueda soportadas a partir de la página o del código.
• Schema Markup Validator: comprueba el marcado frente al vocabulario más amplio de schema.org, incluyendo tipos que Google no muestra como rich results.

Por lo tanto, un tipo de schema.org puede ser válido sin producir una mejora de Google. No hay contradicción: schema.org describe muchas más entidades y relaciones que las que admite la galería de búsqueda de Google.

Usa el validador para responder “¿Es este marcado válido de schema.org?”. Usa la herramienta de Google para responder “¿Es elegible para un rich result de Google?”. Si necesitas la distinción más profunda, nuestra guía de Schema.org 2026 explica qué lee y usa Google actualmente.

No persigas rich results de FAQ ni de HowTo

Muchos tutoriales de schema que antes eran competentes ahora están desactualizados.

La structured-data search gallery en vivo de Google sigue siendo la fuente para comprobar qué tipo implementar para ganar visibilidad en búsqueda. Las funciones soportadas incluyen Article, Breadcrumb, Dataset, Discussion forum, Event, Job posting, Local business, Organization, Product, Profile page, Q&A, Recipe, Review snippet, Software app, Vacation rental y Video, entre otras.

FAQ y HowTo no aparecen.

Google eliminó HowTo como función de búsqueda en 2023. En su registro de cambios de documentación, dice: “Se eliminó la documentación de datos estructurados de How-to, ya que este rich result ya no se muestra en resultados de búsqueda, en escritorio y en dispositivos móviles”.

FAQ sobrevivió más tiempo, pero en una forma restringida, y eso también terminó. Barry Schwartz informó en Search Engine Land que Google dejó de dar soporte a rich results de FAQ a partir del 7 de mayo de 2026. El aviso de documentación de Google decía:

“Los rich results de FAQ ya no aparecen en Google Search. Dejaremos de mostrar la aparición de FAQ en búsqueda, el informe de rich results y el soporte en la Rich results test en junio de 2026.”

FAQPage sigue formando parte de schema.org, y otros sistemas pueden procesarlo. No generará un rich result de FAQ de Google. El marcado de HowTo aún puede describir contenido instructivo en un sentido semántico general, pero ya no gana una mejora HowTo en Google Search.

Mantén las FAQs útiles y las instrucciones paso a paso para los lectores. Solo no presupuestes tiempo de implementación con la suposición de que estos dos tipos de schema crearán rich snippets de Google. Esa táctica ya caducó.

Pasa de probar una sola página a supervisar a nivel de sitio

La Rich Results Test es un diagnóstico a nivel de página. Search Console informa qué encontró Google en las páginas rastreadas.

Abre el informe relevante, como Breadcrumbs, Product snippets o Merchant listings. Inspecciona las URL afectadas, identifica la plantilla o fuente de datos compartida, despliega la corrección y, si está disponible, selecciona Validate fix. Google debe volver a rastrear y procesar las URL antes de que el informe se actualice.

Search Console es más lenta que probar solo el código pegado, porque refleja el ciclo de rastreo de Google, no tu edición local más reciente. Ese retraso puede ser molesto (yo he refrescado esos informes sabiendo perfectamente que no iba a cambiar nada), pero también es lo que vuelve valiosos esos datos: representan páginas de producción a escala.

Nuestra auditoría SEO gratuita puede ayudar a identificar problemas más amplios del sitio antes de limitar la investigación a URL individuales. Confirma la elegibilidad para rich results con la prueba de Google después; una auditoría de terceros no debería ser la autoridad final sobre una función de Google.

Por qué una prueba aprobada puede no producir un rich result

Un resultado válido significa elegibilidad, no visualización garantizada.

Google decide si muestra una mejora para cada consulta y resultado. La aparición en búsqueda también puede verse afectada por la calidad de la página, un marcado engañoso o que no coincide, tipos de funciones no compatibles y acciones manuales sobre datos estructurados.

Si la prueba pasa pero no aparece ninguna mejora:

1. Confirma que probaste el URL canónico final.
2. Revisa que la información marcada sea visible y esté actualizada.
3. Vuelve a mirar el informe correspondiente en Search Console.
4. Revisa Search Console por acciones manuales.
5. Verifica que el tipo de schema sigue apareciendo en la galería de búsqueda de Google.
6. Supervisa varias consultas relevantes en vez de tratar una única búsqueda manual como concluyente.

Estoy seguro de esta secuencia de diagnóstico. Predecir exactamente cuándo Google decorará un resultado elegible es menos seguro, porque Google no ofrece garantías de visualización. Reescribir JSON-LD ya válido cada vez que desaparece un rich result puede introducir errores nuevos sin cambiar la decisión subyacente.

La elegibilidad y la presentación se separan en más frentes además del schema. Nuestra guía sobre SERP snippets y visibilidad de IA explica por qué indexar y controlar los snippets sigue importando incluso cuando las plataformas de búsqueda eligen la presentación final.

Preguntas frecuentes

¿Cómo puedo probar si mi página califica para rich results?

Pega el URL publicado en la Rich Results Test de Google. Usa el modo Code para HTML o JSON-LD que aún no se haya publicado. La herramienta identifica los tipos de rich result soportados y lista errores, advertencias y propiedades analizadas. Usa Search Console para información agregada sobre páginas rastreadas.

¿Qué pasó con la Structured Data Testing Tool?

Google retiró la antigua Structured Data Testing Tool. Usa la Rich Results Test para la elegibilidad de rich results de Google y el Schema Markup Validator en validator.schema.org para la validación general de schema.org.

¿Cuál es la diferencia entre la Rich Results Test y Schema Markup Validator?

La Rich Results Test comprueba si el marcado puede generar un rich result compatible con Google. El Schema Markup Validator comprueba la validez general de schema.org, incluyendo vocabulario que Google no usa para mejoras de búsqueda. Aprobar este último no prueba la elegibilidad en Google.

¿Cuál es la diferencia entre un error de schema y una advertencia?

Un error significa que falta una propiedad obligatoria o que es inválida, lo que hace que el elemento afectado no sea elegible. Una advertencia normalmente significa que falta una propiedad recomendada, pero el elemento sigue siendo elegible. Corrige todos los errores primero y luego evalúa las advertencias según su utilidad y los datos que realmente se muestran en la página.

¿El schema de FAQ sigue generando rich results en 2026?

No. Google eliminó por completo los rich results de FAQ el 7 de mayo de 2026 y, posteriormente, también dejó caer el soporte relacionado de pruebas y reportes. FAQPage sigue siendo un vocabulario válido de schema.org, pero ya no genera un rich result de FAQ de Google.

¿Por qué no se detecta ningún schema en mi página en vivo?

El marcado quizá no llegó a producción, podría estar suprimido por una condición de plantilla, podría estar detrás de un caché desactualizado, o podría depender de JavaScript que falló durante el renderizado. Compara el modo Code con el modo URL y, luego, inspecciona la salida de producción renderizada y cada sistema capaz de inyectar schema.

¿Por qué mi rich result no se muestra aunque la prueba pase?

Aprobar significa que la página es elegible, no que se vaya a recibir una visualización mejorada. Confirma que el marcado coincide con el contenido visible, revisa el informe correspondiente de Search Console, verifica que la función siga siendo soportada y asegúrate de que el sitio no tenga ninguna acción manual sobre datos estructurados.

Si estás generando o reparando JSON-LD, empieza por una página representativa, pruébala en modo Code, despliega y prueba el URL en vivo. Una vez que esa página esté limpia, aplica la corrección a nivel de plantilla en todo el sitio y deja que Search Console confirme el resultado a escala.