Un comprobador de schema lee los datos estructurados de una página y te dice si una máquina puede parsearlos y si están los campos que buscan los buscadores. Pega una URL en el Schema Checker de Scrawl, corrige lo marcado como error y luego las advertencias. El markup válido no garantiza un rich result, pero el markup roto lo descarta.
Qué es el schema markup
El schema markup es un conjunto de etiquetas del vocabulario schema.org que añades a una página para que el software sepa de qué trata. Una persona ve una receta. Un rastreador ve texto e imágenes hasta que algo dice «esto es una Recipe, este es su tiempo de cocción, esta es su valoración».
Google, Bing y otros consumidores leen ese markup para entender entidades en la página y, para algunos tipos, construir rich results: precios y stock de producto, migas de pan, estrellas de reseña, fechas de evento y extras similares en el listado.
Hay tres formas de escribirlo. JSON-LD va en un bloque <script type="application/ld+json">. Microdata pone atributos itemscope, itemtype e itemprop en tu HTML. RDFa hace el mismo trabajo con otro conjunto de atributos. Google acepta los tres y recomienda JSON-LD.
Cómo comprobar schema con el Schema Checker
La herramienta tiene dos modos y responden preguntas distintas.
Modo URL responde «¿qué sirve esta página en vivo?». Introduces la dirección y ejecutas la comprobación. La herramienta pide la página, lee el HTML que devuelve el servidor y extrae cada bloque script JSON-LD y cada itemscope de microdata. El JSON-LD con @graph se divide en nodos separados, así un grafo con Organization, WebSite y Article aparece como tres ítems, no un bloque único. Junto al schema, el modo URL también lista Open Graph, Twitter card, title, meta description, robots meta y canonical, más una puntuación global.
Modo pegar responde «¿este fragmento está bien antes de publicarlo?». Cambia a Pegar JSON-LD y suelta un objeto, un array o un bloque <script type="application/ld+json"> completo. No se obtiene nada por red. Es el ciclo más rápido al editar una plantilla o un campo del CMS.
Una rutina práctica:
- Comprueba primero la URL en vivo para ver lo que Google vería hoy.
- Copia el bloque con problemas al modo pegar.
- Edita hasta que no haya errores y las advertencias restantes las entiendas.
- Publica el arreglo y vuelve a ejecutar el modo URL en la página en vivo.
Un límite a tener en cuenta: el modo URL lee la respuesta HTML. No ejecuta JavaScript. Si tu schema lo inyecta un gestor de tags o un script tras la carga, el comprobador no lo verá. Google puede renderizar JavaScript, pero JSON-LD en servidor es más fácil de recoger para cualquier rastreador; si «no encuentra nada» en una página muy JS, revisa cómo se añade el markup.
Leer resultados: errores, advertencias y qué corregir primero
Cada ítem JSON-LD lleva etiqueta de tipo, estado válido o no, y listas de errores y advertencias. Los ítems de microdata muestran el tipo de itemtype y las propiedades dentro del scope.
Errores significan que el ítem está roto:
- Error de parseo. El bloque no es JSON válido; nada dentro cuenta. Causas habituales: coma faltante, comillas tipográficas, comilla doble sin escapar dentro de una cadena o un comentario suelto.
- Falta @type. El ítem parsea pero no dice qué es. Sin tipo, ningún consumidor puede mapearlo.
Advertencias significan que parsea pero está escaso o poco claro:
- Falta o @context inválido. El bloque debería apuntar a
https://schema.org. Sin eso, los nombres de propiedad no tienen vocabulario detrás. - Campo recomendado faltante. Para tipos habituales la herramienta comprueba una lista corta: Article necesita
headline,authorydatePublished; Product necesitaname,imageyoffers; LocalBusiness necesitaname,addressytelephone; Event necesitaname,startDateylocation. BreadcrumbList, FAQPage, Review, Organization, WebSite, Person y VideoObject tienen sus propias comprobaciones. - Lista de migas vacía. Un BreadcrumbList sin ítems.
- Scope de microdata sin propiedades. Un
itemscopeque declara tipo pero no lleva valoresitemprop.
Corrige errores primero, porque un bloque roto oculta todo lo demás. Luego añade campos faltantes. La lista del comprobador es un suelo, no la spec completa: la documentación de Google para cada rich result lista propiedades requeridas y recomendadas, y algunas van más allá de lo que prueba un comprobador general. Cuando un tipo te importe, lee la página de Google y compara campo a campo.
Errores habituales de schema y cómo corregirlos
JSON inválido. JSON no admite comas finales, comillas simples ni comentarios. El comprobador intenta leer tras una coma final o comillas codificadas en HTML, pero otros parsers pueden no hacerlo; límpialo igualmente. Si generas JSON-LD en plantilla, usa el codificador JSON de tu lenguaje en lugar de concatenar cadenas.
Fechas en formato incorrecto. Usa ISO 8601: 2026-10-29 o 2026-10-29T09:00:00+05:00. Una fecha como 29/10/2026 es ambigua y puede ignorarse.
Markup que no coincide con la página. Precios, valoraciones, respuestas FAQ y autores en el schema deben coincidir con lo que ve el visitante. Marcar reseñas que no están en la página, o un precio distinto del visible, entra en lo que las políticas de datos estructurados de Google tratan como spam.
Dos plugins, dos grafos. Temas y plugins SEO suelen emitir Organization o Article a la vez. Terminas con ítems duplicados o en conflicto. El modo URL lista cada bloque; mantén una fuente y apaga la otra.
URLs de imagen relativas o rotas. Usa URLs absolutas en image, logo y url, y comprueba que carguen.
Si prefieres empezar limpio, el Generador de datos estructurados construye JSON-LD para Article, Product, FAQ, LocalBusiness, Breadcrumb y otros tipos. Genera, pega la salida en el Schema Checker y añádela a tu plantilla.
JSON-LD frente a microdata
Ambos describen lo mismo. La diferencia es dónde vive el markup.
JSON-LD es un bloque autocontenido. Puedes añadirlo o cambiarlo sin tocar el HTML visible, generarlo desde tu capa de datos y revisarlo en un solo sitio. Por eso la mayoría de sitios modernos lo usan y Google lo recomienda.
Microdata está tejida en el HTML. Cada valor va en el elemento que lo muestra, así markup y contenido visible van al unísono por diseño. El coste es que un rediseño puede romperla sin que nadie lo note, y los tipos anidados cuestan de leer.
Si empiezas de cero, usa JSON-LD. Si un tema antiguo ya emite microdata válida, no hace falta arrancarla, pero evita describir la misma entidad en ambos formatos en una página. El Schema Checker lee ambos, así ves si ocurre.
Qué tipos de schema importan para rich results
No todo tipo de schema.org cambia lo visible en búsqueda. Tipos ligados a rich results de Google incluyen Product (con offers y reviews), BreadcrumbList, Article, Event, Recipe, VideoObject, LocalBusiness, fragmentos Review, JobPosting y Organization (logo y datos del sitio).
Dos cambios recientes conviene conocer. Desde 2023, Google muestra rich results FAQ solo en un conjunto pequeño de sitios gubernamentales y de salud conocidos, y dejó de mostrar rich results HowTo. El markup FAQPage sigue siendo schema válido y sigue describiendo tu Q&A a las máquinas; no lo añadas esperando los desplegables antiguos en búsqueda. Y ningún rich result está garantizado: Google decide por consulta, aunque el markup sea perfecto.
Comprobar más de una página
El schema suele venir de plantillas; una plantilla rota implica cientos de páginas rotas. Tras actualizar tema o plugin, muestrea una URL por tipo de plantilla: inicio, categoría, producto o post, contacto. Cuando necesites un barrido más amplio, el Bulk Schema Checker audita hasta 50 URLs y muestra tipos, errores y advertencias en una tabla. Úsalo para encontrar la plantilla que falla y abre esa URL en el comprobador de una página para el detalle.
Tras publicar un arreglo, pide indexación de una URL representativa en Search Console y vigila el informe de mejoras de ese tipo. El Rich Results Test de Google tiene la última palabra sobre elegibilidad para un rich result concreto; el Schema Checker es el sitio más rápido para encontrar y corregir el markup antes de llegar allí.