El Comprobador de Datos Estructurados de Screpy examina JSON-LD de una página pública o de código pegado. Identifica errores de análisis, enumera las entidades declaradas y señala problemas en propiedades seleccionadas de cinco tipos de esquema compatibles. Utiliza el informe para decidir qué corregir y qué requiere una comprobación más amplia. La sintaxis válida, las comprobaciones compatibles y la elegibilidad para un resultado enriquecido de Google son cuestiones distintas; un estado verde no responde a las tres.
Elige una URL de página o JSON-LD pegado
Selecciona URL de la página para examinar una página publicada, como la ficha de un producto o la página de contacto de una empresa. Introduce su dirección pública HTTP o HTTPS en lugar de elegir siempre la página de inicio: distintas plantillas pueden contener marcado diferente. El modo URL lee el HTML que devuelve la página. Una página privada o protegida por contraseña no proporciona la misma evidencia pública, y un fallo al obtenerla no demuestra que sus datos estructurados estén dañados.
Selecciona Pegar código para revisar un borrador, un script extraído o HTML que ya tengas. Elige JSON-LD para el JSON en sí, sin un elemento <script> alrededor. Elige HTML si la entrada contiene bloques <script type="application/ld+json">. La dirección de un archivo JSON independiente no es una página HTML; pega su contenido en modo JSON-LD. La entrada pegada tiene un límite de 256 KiB medido en bytes UTF-8, por lo que el número de caracteres permitido depende del texto.
Las comprobaciones por URL no ejecutan JavaScript. El marcado añadido después de cargar la página puede faltar en el código fuente obtenido. Google puede procesar JSON-LD insertado dinámicamente, así que la ausencia de un bloque en este informe no demuestra que Google tampoco lo vea. Examina el marcado renderizado pertinente o usa la prueba de funciones de Google cuando esta distinción importe. Pegar código comprueba lo que has proporcionado; no confirma lo que sirve la página publicada.
Lee el informe de datos estructurados
Empieza por la cobertura y continúa con los hallazgos y la tabla de entidades. Bloques JSON-LD cuenta los scripts detectados en HTML; el JSON-LD pegado se considera un bloque. Entidades cuenta los objetos con un tipo declarado que se conservaron y cuyo JSON se analizó correctamente; un script puede contener varias entidades. Errores de sintaxis cuenta los bloques procesados que no se pudieron analizar. Son cantidades distintas: una página con tres bloques no tiene necesariamente tres entidades. En un informe parcial, el número de bloques detectados no demuestra que se hayan examinado todos.
Cada fila separa Sintaxis y Alcance. La sintaxis válida en verde significa que el analizador JSON aceptó el bloque. Las comprobaciones compatibles en verde indican que la entidad cumplía las condiciones de las comprobaciones de propiedades seleccionadas de esta herramienta. Lee también sus hallazgos: ninguna etiqueta confirma que todas las propiedades sean correctas. El rojo identifica errores de análisis o hallazgos de error; el amarillo destaca advertencias y cobertura parcial; el gris señala evidencia no compatible o no disponible. Interpreta el estado escrito junto con el color.
La columna Ruta ayuda a localizar objetos anidados. Por ejemplo, $.author apunta al objeto del autor dentro de la raíz y $.@graph[1] al segundo objeto de una matriz @graph. Las rutas son relativas a su bloque JSON-LD, por lo que una misma ruta puede aparecer en varios scripts; el JSON descargado incluye números de bloque para distinguirlas.
La columna Nombre lee name, no la propiedad de presentación de todos los tipos. Por eso, un Article con un headline válido puede tener la celda Nombre vacía. Examina la propiedad y el hallazgo correspondientes antes de considerar ese vacío un defecto del contenido.
Corrige la sintaxis JSON antes de las advertencias de propiedades
Un bloque inválido no proporciona hallazgos fiables sobre entidades. Repara primero el JSON y repite la comprobación antes de interpretar advertencias de propiedades ausentes. Entre las causas habituales están las comillas simples en nombres o cadenas, una coma adicional después de la última propiedad, un corchete o llave de cierre ausente y una comilla sin escapar dentro del texto. JSON utiliza cadenas entre comillas dobles y comas entre miembros; RFC 8259 define la gramática.
Esta Organization ficticia es un ejemplo mínimo de sintaxis para Pegar código → JSON-LD:
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "Example Studio",
"url": "https://example.com/"
}
El ejemplo incluye las dos propiedades que este comprobador busca en Organization. No es una plantilla completa para ninguna función de búsqueda de Google. Sustituye los valores ficticios por datos reales de la página y consulta los requisitos de la función correspondiente antes de publicar.
Un JSON válido no basta para confirmar que los datos estructurados sean utilizables. Una cadena o un número independiente puede ser JSON válido, pero no describe la entidad esperada; la herramienta indica que la raíz necesita un objeto o una matriz. Del mismo modo, un objeto analizado sin @type declarado puede no generar filas de entidades. Revisa la estructura real antes de añadir propiedades solo para dejar el informe sin avisos.
¿Qué propiedades del esquema se comprueban?
El Comprobador de Datos Estructurados aplica comprobaciones seleccionadas a cinco tipos exactos cuando reconoce su contexto. Usa la tabla para entender un hallazgo, no como una lista completa de propiedades de Schema.org ni de campos obligatorios de Google.
| Tipo declarado | Qué examina este comprobador | Cómo utilizar el hallazgo |
|---|---|---|
Organization |
Presencia de name y url |
Comprueba que describan la organización real y su sitio web correcto. |
LocalBusiness |
Presencia de name y address |
Revisa la identidad y la dirección reales del negocio; los componentes de la dirección no se validan por completo. |
Article |
Presencia de headline, author, datePublished e image |
Compara los valores con el artículo y revisa los formatos por separado. |
Product |
Presencia de name; si se proporciona alguno de offers, review o aggregateRating |
Utiliza solo datos veraces y pertinentes del producto. No inventes ofertas o reseñas para eliminar una advertencia. |
BreadcrumbList |
Matriz itemListElement no vacía; position entero positivo y name de texto no vacío en cada elemento examinado |
Corrige el elemento indicado y comprueba después la ruta de navegación completa y las URL de destino por separado. |
La mayoría son comprobaciones de presencia. Un valor puede existir aunque su URL, fecha, imagen, estructura de objeto o contenido factual sea incorrecto. Un objeto vacío puede superar una comprobación de presencia, y no todas las comprobaciones rechazan valores compuestos solo por espacios. Por tanto, un estado compatible no confirma que una dirección, un autor o una oferta estén completos.
Las comprobaciones de rutas de navegación examinan además los valores seleccionados de los elementos, pero no confirman posiciones consecutivas o únicas, URL item correctas ni la semántica completa de ListItem. El informe conserva como máximo 100 hallazgos de propiedades por entidad. Una ruta larga o una entidad con numerosos defectos repetidos puede necesitar una revisión adicional después de esos hallazgos.
Corrige el hallazgo dentro del contexto de la página. Si el autor de un artículo es una persona, conserva la estructura correcta del autor aunque la Person anidada quede fuera del alcance del comprobador. Cambiar marcado veraz únicamente para obtener etiquetas verdes puede ocultar el problema original en lugar de resolverlo.
¿Por qué un marcado válido aparece como no compatible o parcial?
No compatible significa que la herramienta no aplicó sus comprobaciones seleccionadas de propiedades a esa entidad. No significa que Schema.org prohíba el tipo. Por ejemplo, un Article compatible puede contener un autor Person anidado. Article recibe sus comprobaciones seleccionadas, pero Person aparece como no compatible y la cobertura pasa a ser parcial. Restaurant también queda fuera de los cinco tipos exactos compatibles, aunque sea un tipo de negocio más específico. Conserva el tipo que describa correctamente el tema y utiliza un validador más amplio para las comprobaciones restantes.
El contexto puede producir la misma distinción. Este comprobador reconoce un contexto simple http://schema.org o https://schema.org, con o sin barra final, incluido uno heredado de un objeto padre. No resuelve contextos de objeto o matriz. Esas formas pueden ser legítimas según la especificación de contextos JSON-LD del W3C. Cuando una entidad declara varios tipos, todos deben pertenecer al conjunto compatible para que se ejecuten sus comprobaciones de propiedades.
La cobertura también tiene límites. El comprobador considera los primeros 50 bloques JSON-LD y conserva hasta 500 filas de resultados, incluidas las de bloques inválidos. Detiene el recorrido por encima de 32 niveles de anidación o 10.000 valores visitados por bloque. Estos límites pueden dejar entidades posteriores sin comprobar. La detección de Microdata o RDFa en HTML también hace parcial el informe, porque esos formatos no se validan aquí.
En entradas pegadas grandes, divide bloques JSON-LD completos en comprobaciones separadas; no cortes un objeto por la mitad y crees un nuevo error de sintaxis. Conserva la fuente original e identifica qué partes cubre cada informe. Estas comprobaciones no se combinan automáticamente en una auditoría completa de la página.
Verifica la página después de corregir el marcado
Compara primero el marcado con lo que un visitante puede leer en la página. Contrasta identidades, fechas, direcciones, detalles de productos y posibles reseñas con el contenido real. Las directrices de Google para datos estructurados exigen información pertinente y precisa y el cumplimiento de los requisitos aplicables de cada función; un analizador no confirma esos hechos. No añadas detalles inventados para satisfacer una advertencia de propiedades.
Elige la siguiente comprobación según la pregunta pendiente. Usa el Validador de Marcado de Schema.org para un examen más amplio del marcado Schema.org, incluidos Microdata y RDFa. También tiene límites: no obtiene ni interpreta otras URL de contexto. Utiliza la Prueba de resultados enriquecidos de Google para examinar funciones de búsqueda de Google compatibles y los errores o advertencias que se indiquen. Superar una prueba no garantiza que Google muestre un resultado enriquecido.
Si preparas marcado empresarial, el Generador de Schema para Negocios Locales puede producir JSON-LD con tus datos reales. Revisa la salida antes de publicarla. Los tipos de negocio específicos y los objetos PostalAddress anidados pueden seguir sin ser compatibles con este comprobador; generar y realizar una validación seleccionada son tareas distintas.
Después de aplicar una corrección, repite la comprobación pertinente en la página publicada, no solo en el borrador. Confirma que el marcado servido contiene el cambio previsto y compara los hallazgos restantes. Utiliza Descargar JSON para conservar números de bloque, rutas de entidades, hallazgos y cobertura de esa ejecución. Guarda la entrada y el alcance junto con la exportación para que otro revisor pueda entender la evidencia. Un informe guardado registra una comprobación; no supervisa continuamente futuros cambios de plantillas o contenido.