Validador schema JSON-LD masivo

El tope es 50 URLs, una por línea, y solo se lee JSON-LD

Pegas las direcciones en el cuadro, una por línea. El contador muestra cuántas entran sobre 50. Las líneas vacías se ignoran. Si escribes más de 50, la petición se queda con las 50 primeras. La lista va en ese cuadro: no hay carga de archivo. Si una línea no lleva http o https, se le añade https. Una URL que no se puede leer queda en fetch error, con el mensaje en la fila.

De cada página se descarga el HTML y se extraen solo los script cuyo type es application/ld+json. Se recorren objetos sueltos, arrays y nodos de @graph. Microdata y RDFa no se leen. Si el JSON no parsea, ese bloque queda inválido. Si parsea y no tiene @type, también queda inválido. Si el @context falta o no apunta a schema.org, eso es un aviso, no un error de bloque.

Los avisos de campo recomendado existen para Article (headline, author, datePublished), Product (name, image, offers), LocalBusiness (name, address, telephone), BreadcrumbList (itemListElement, y también si esa lista va vacía), FAQPage (mainEntity), Review (reviewRating, itemReviewed), Event (name, startDate, location), Person (name), Organization (name, url), WebSite (name, url) y VideoObject (name, description, thumbnailUrl). Cualquier otro @type se lista igual. JobPosting, Recipe o BlogPosting aparecen si están en el script, sin esa lista de campos. Las páginas se piden en grupos de 6, con 15 segundos de espera por URL.

Después de un cambio, muestrea una URL por plantilla

El JSON-LD de un sitio suele salir de la plantilla, no de cada URL editada a mano. Después de un deploy, de un cambio de tema o de un plugin, elige una URL por tipo de plantilla: portada, una categoría, un producto o un post, y una página de contacto. Con unas 10 a 20 páginas representativas ves si esa plantilla emite JSON-LD que parsea. El tope de una pasada es 50, así que ese muestreo cabe de una vez.

En una auditoría, recorre las filas y marca las que deberían llevar Article, Product, FAQPage o LocalBusiness y no los tienen, y las que están en Error. Tras una migración, repite el mismo corte en landings, URLs de producto y posts que ya tenían markup. Si el mismo @type desaparece en todas las filas de una plantilla, el fallo está en la plantilla. Corregir una sola URL no arregla el resto del grupo.

Cada fila trae URL, tipos, bloques, estado e issue principal

La tabla tiene una fila por URL. La columna de tipos lista los @type distintos, por ejemplo Organization, WebPage, Article, Product, FAQPage o BreadcrumbList. Si no hay tipos, ves un guion. La columna de bloques muestra válidos sobre el total, como 1/2 cuando un bloque parseó y otro no. En el CSV, Blocks es solo el total.

El estado de la celda es Válido (Valid), Warning, Error, Sin schema (No schema) o Error de fetch (fetch error). El issue principal enseña el primer error del primer bloque roto. Si no hay errores y sí avisos, enseña el primer aviso, por ejemplo Missing recommended field for Product: name, o Missing or invalid @context. Si no hay nada que señalar, la celda marca OK. Encima de la tabla hay recuentos de URLs comprobadas, válidas, con warning, con error y sin schema. El fetch error no tiene pastilla propia: lo lees en la fila. La última columna, Ver, abre esa URL en el Schema Checker.

Valid, Warning, Error, No schema y fetch error no dicen lo mismo

Valid significa que todos los bloques parsearon, tienen @type y no acumulan avisos. En la interfaz en español esa celda dice Válido. Warning significa que los bloques son válidos, pero falta un campo recomendado para su tipo, como Article sin datePublished o Product sin name, o que el @context no es válido. Error significa que algún bloque no parsea o no tiene @type. Ese markup no se puede consumir tal cual. Una página con un bloque roto y otro sano sigue en Error; la columna de bloques te enseña cuántos sí pasaron.

No schema significa que la página respondió y no había ningún application/ld+json. Es ausencia de JSON-LD en el HTML recibido, no un fallo de red. fetch error significa que la URL no se pudo obtener: tiempo de espera, URL vacía o error de red. El mensaje va en la fila.

Esos avisos siguen campos habituales para rich results de Google en los tipos que tienen reglas. Comprueban que el campo exista, no cada restricción de schema.org ni el formato del valor. Un Valid aquí no demuestra que Google vaya a mostrar un rich result.

Una fila en Error, Warning o No schema se abre en el Schema Checker

La tabla sirve para encontrar la plantilla rota. Cuando una fila está en Error, en Warning o en No schema y esa URL debería llevar markup, pulsa Ver. Eso abre el Schema Checker con la misma URL. Ahí ves cada bloque JSON-LD, sus errores y sus avisos, y también Microdata, Open Graph y Twitter Card. El comprobador masivo se queda en los script application/ld+json.

Abre en el detalle las filas que fallan. Si varias comparten plantilla, una URL de cada grupo basta para ver el bloque. Para saber si un tipo concreto puede optar a un rich result, confirma unas pocas páginas representativas, tres a cinco y una por tipo de contenido, en el Rich Results Test de Google. Esa prueba mira una sola URL, valora la elegibilidad y muestra una vista previa. La pasada de 50 URLs no hace esa vista previa.

La exportación es un solo archivo, bulk-schema-check.csv

El botón de exportar descarga un único CSV llamado bulk-schema-check.csv. El formato de salida es ese archivo. No hay exportación JSON, no hay exportación XML y no se generan varios archivos numerados. Las columnas son URL, Status, Schema Types, Blocks, Errors, Warnings y Top Issue. Status usa la etiqueta en inglés de la fila: Valid, Warning, Error, No schema o Fetch error, aunque la tabla en español diga Válido, Sin schema o Error de fetch. Schema Types junta los tipos con punto y coma. Blocks es el total de bloques JSON-LD. Errors y Warnings son recuentos. Top Issue repite el primer problema o, si la página no se pudo leer, el mensaje de la petición.

Ordena el CSV por Status y ataca primero Error y Fetch error. Después Warning. Las filas No schema importan cuando esa plantilla debía incluir JSON-LD. El archivo cubre la pasada actual, como máximo 50 URLs.