Pantalla y fichas de datos. Escena ilustrativa.

GUÍA / PROTOCOLO

Auditar datos estructurados

Un marcado válido no corrige una página ambigua, datos ausentes ni una identidad no verificada.

Respuesta directa

¿Cómo auditar datos estructurados más allá de la sintaxis?

Parta de la página renderizada y su URL canónica. Enumere entidades y propiedades, confronte cada afirmación con el contenido visible y compruebe la sintaxis y los requisitos de la función buscada.

01 / Método de control

Método de control

01

Elegir páginas y tipos

Inventaríe plantillas, tipos de esquema útiles y variantes lingüísticas. Descarte los que no correspondan al contenido.

02

Comparar HTML y marcado

Revise nombres, autores, fechas, imágenes, enlaces y relaciones en el HTML visible y el JSON-LD. Muestre la información importante o elimínela del marcado.

03

Validar en dos niveles

Use un validador de Schema.org para la estructura y la prueba de resultados enriquecidos para las funciones de Google. Separe errores y avisos.

04

Repetir tras cambios

Pruebe plantillas y páginas reales después de publicar. Revise también idiomas y URL canónicas.

EN LA PRÁCTICA

Una corrección termina al revisar sus consecuencias

Una página forma un conjunto con resumen, título, tablas, enlaces, idiomas y datos estructurados. Corregir una frase exige localizar sus reproducciones y comprobar que cada versión conserva el sentido.

¿Qué comprobar primero?

Elija la situación observada. Cada opción indica un primer control, la prueba útil y su límite.

Dos páginas ofrecen información incompatible

Primer control
Aísle la misma afirmación y compare fuente, vigencia y alcance. Defina página de referencia y responsable antes de propagar una corrección.
Prueba que conservar
Ambas URL, formulaciones, referencias, fecha efectiva, decisión y páginas o fragmentos que repiten la información.
Límite que recordar
La página más reciente no es necesariamente correcta. Cambiar la fecha de publicación no resuelve definiciones distintas ni falta de fuente.
Leer la guía relacionada

Para ampliar

Antes de publicar
SituaciónEvitarCorrección útil
Cifra corregidaCambiar solo el párrafo.Revisar tabla, leyenda, síntesis y dato estructurado asociados.
Página trasladadaActualizar solo el enlace visible.Verificar destino, ancla y ruta de regreso.
Versión traducidaCopiar palabras dejando un ejemplo obsoleto.Revisar unidad, fecha, fuente, enlaces y alcance.
  1. Identificar

    ¿Qué afirmaciones dependen del cambio?

  2. Propagar

    ¿Qué páginas e idiomas las reproducen?

  3. Revisar

    ¿Concuerdan cifras, enlaces y límites?

Control final

La fecha de actualización indica una edición real. No redefine fechas de fuente ni observación. Mantenga sus funciones separadas en texto y referencias.

Referencias documentales

Consultado el .

Taller de lectura

JSON legible que atribuye el autor equivocado

La página DEMO es un artículo francés firmado por Lina DEMO. El laboratorio DEMO figura aparte como organización; ninguno existe realmente.

Datos y registros ficticios para aprender: ninguno de estos resultados procede de una consulta en directo.

Cuatro controles después de la sintaxis

El marcado ficticio mezcla identidad, atribución e idioma. No se ejecuta un validador externo: la tabla distingue controles sobre la página renderizada.

Si la tabla supera la pantalla, desplácela horizontalmente; las flechas funcionan cuando la zona tiene el foco.

Cuatro controles después de la sintaxis
ControlEstado DEMOQué estableceCorrección que examinar
Sintaxis JSONLlaves, cadenas y tablas bien formadasEl texto puede analizarse como JSONContinuar el control semántico.
Identidad @idMismo #entity para Lina y laboratorioConfusión de dos objetos distintos en este casoAsignar identificadores coherentes a los objetos descritos.
Autor del artículoLina visible; laboratorio en authorAtribución distinta de la páginaUsar la autoría respaldada sin convertir organización en persona.
Idioma declaradoArtículo francés; inLanguage=enSe declara otro idiomaComprobar la entidad artículo y esta variante.

¿Qué permite una comprobación sintáctica correcta?

Abra cada propuesta para comparar su diagnóstico. Pueden seguir siendo necesarios otros controles.

Certificar autoría e identidad de las entidades

No. Los valores pueden ser válidos gramaticalmente y señalar otro objeto.

Prometer un resultado enriquecido

No. Sintaxis no garantiza elegibilidad ni presentación.

Continuar con identidad, contenido visible y reglas del tipo

Sí. Registrar por separado sintaxis, coherencia editorial y criterios aplicables.

Registro ficticio de auditoría del marcado

Página: artículo DEMO en francés
Autora visible: Lina DEMO
Problema: #entity compartido por persona y organización
Problema: author apunta al laboratorio
Problema: inLanguage=en para este artículo francés
Decisión: corregir marcado, sin certificar resultado enriquecido

Los fragmentos #entity e inLanguage son pistas del ejemplo, no hallazgos sobre este sitio ni un esquema completo que copiar.

Documentación de las reglas, separada de los ejemplos ficticios

02 / Pruebas que conservar

Pruebas que conservar

Inventario de plantillas

URL, tipo de página, esquema previsto, responsable y fecha.

Comparación de campos

Valor marcado, prueba visible, origen del campo y diferencia.

Informe de validación

Herramienta, URL, fecha, errores, avisos y captura.

Decisión correctiva

Campo corregido o retirado, responsable y comprobación posterior.

Comparar otras situaciones y ejercicios

PUNTO DE CONTROL

Antes de concluir

Una interpretación errónea frecuente y la comprobación que ayuda a evitarla.

Conclusión precipitada

Una sintaxis JSON-LD válida no basta si el marcado describe datos ausentes, antiguos o contradichos por la página visible.

Comprobación decisiva

Comparar cada propiedad importante con texto visible, URL canónica y tipo previsto. Validar por separado sintaxis y reglas del buscador; revisar el resultado publicado.

TRAS LA REVISIÓN

Decidir según el hallazgo

01

JSON-LD válido con un hecho ausente de la página

Corrija el marcado o haga visible y verificable el hecho. La sintaxis no garantiza coherencia con el contenido.

02

Dos páginas atribuyen datos contradictorios a una entidad

Fije una referencia editorial, armonice los campos y revise traducciones antes de validar.

Decisión y trazabilidad

Decisión y trazabilidad

Qué debe permitir decidir la comprobación y qué conservar para revisar esa decisión.

Prueba suficiente

Compare el JSON-LD renderizado con texto visible, URL canónica y propiedades del tipo elegido. Revise varios modelos e idiomas.

Siguiente decisión

Quite propiedades no sustentadas, corrija contradicciones y valide el HTML renderizado. Documente los tipos usados y su mantenimiento.

Casos de control detallados

Situaciones tipo para preparar un control. No describen misiones realizadas ni observaciones reales.

El marcado promete más que el texto

Qué examinar

Vincule cada propiedad estructurada con información visible y prueba.

Decisión y acción

Retire valores sin respaldo; sintaxis válida no confirma una valoración, precio o relación.

Prueba que conservar

Propiedad, texto visible, prueba y corrección elegida.

Un identificador nombra dos objetos

Qué examinar

Compare apariciones del mismo @id y atributos de identidad.

Decisión y acción

Reserve el identificador a un objeto coherente; distinga persona, organización y página sin duplicar identidades.

Prueba que conservar

Apariciones, objetos afectados y regla de identificación corregida.

El marcado supera el contenido visible

Qué examinar

Comparar afirmaciones JSON-LD, texto mostrado y fuentes asociadas.

Decisión y acción

Retirar o corregir propiedades no justificadas por la página.

Prueba que conservar

Propiedad, valor visible, fuente y resultado.

REFERENCIAS DOCUMENTADAS

JSON canónico: un contrato más preciso que ordenar claves

JCS, descrito en RFC informativa 8785, define una representación determinista para criptografía. Es más estricto que JSON arbitrario y más completo que quitar espacios.

JSON canónico: un contrato más preciso que ordenar claves
ReferenciaValor o formaQué identifica
INPUTI-JSON · nombres únicosLos nombres deben ser únicos y los datos compatibles con I-JSON. Un parser que sobrescribe duplicados puede ocultar entradas inválidas: compruébelo antes de perder información.
WHITESPACEsin espacios entre tokensNo se emiten espacios entre tokens. Se conservan los espacios dentro de cadenas; quitar todos los blancos del texto cambiaría los datos.
NUMBERSECMAScript · IEEE 754 binary64Los números siguen ECMAScript para valores binary64. Se rechazan NaN e Infinity; mayor precisión requiere un contrato adecuado, a menudo una cadena explícita.
PROPERTY ORDERrecursivo · unidades UTF-16El orden recursivo compara nombres decodificados como unidades UTF-16 sin signo y sin orden lingüístico local. Ordenar bytes UTF-8 o puntos de código puede dar otro resultado.
ARRAY ORDERconservadoEl orden de los elementos de arrays se conserva, aunque se procesan los objetos internos. Ordenar toda lista cambiaría su significado.
UNICODEconservado · salida UTF-8Las cadenas Unicode se conservan: JCS no aplica NFC ni NFKC. La salida final es UTF-8. Canonicalizar JSON no es normalizar lingüísticamente.

Orden publicado para siete nombres JSON

RFC 8785 § 3.2.3. Se conservan los rótulos ingleses. Unidades UTF-16 para comprobar el orden, incluido el carácter fuera del plano multilingüe básico.

Orden publicado para siete nombres JSON
Puntos de códigoUnidades UTF-16Rótulo fuente (inglés)
U+000D000DCarriage Return
U+00310031One
U+00800080Control
U+00F600F6Latin Small Letter O With Diaeresis
U+20AC20ACEuro Sign
U+1F600D83D DE00Emoji: Grinning Face
U+FB33FB33Hebrew Letter Dalet With Dagesh

RFC 8785 § 3.2.3. Copyright © 2020 IETF Trust and the persons identified as document authors. UTF-16 units added for explanation.

Qué conservar en el expediente

Identifique la huella de salida JCS y su perfil. No sustituye la huella de los bytes originales; conserve ambos objetos si necesita trazabilidad.

¿Basta JSON.stringify para JCS?

No por sí solo. No comprueba todas las restricciones ni el orden recursivo. El ejemplo publicado permite detectar un orden Unicode inadecuado.

Documentación primaria

Documentación consultada el .

REFERENCIAS DOCUMENTADAS

JSON Merge Patch: borrar, conservar o sustituir un valor

Una actualización parcial debe identificar su formato. JSON Merge Patch describe valores que se fusionan con el destino; JSON Patch describe operaciones. Sus tipos de medio y el tratamiento de null son distintos. El simulador permite examinar una fusión sin llamar a una API.

JSON Merge Patch: borrar, conservar o sustituir un valor
ReferenciaValor o formaQué identifica
member absentkeepUn miembro omitido queda igual si el destino es un objeto. Un miembro con null solicita borrarlo; si ya está ausente, no añade nada. La cadena vacía, false y cero son valores, no instrucciones de borrado.
member: nulldeleteUn patch objeto se fusiona recursivamente. Si el destino correspondiente es un array, un escalar o null, se convierte primero en objeto vacío. Aplicar {} al número 7 produce {}, no 7.
{}object targetUn patch que no sea objeto sustituye todo el destino en ese nivel. Un array se reemplaza completo: no se concatena ni se empareja por índice o identificador.
null / [] / scalarreplaceUn patch null en la raíz sustituye todo el destino por null. Como miembro de un objeto patch, null borra ese miembro. Una operación JSON Patch puede ser más adecuada para asignar null explícitamente a una propiedad.
JSON values≠ text diffEl cálculo trabaja sobre valores JSON. No conserva espacios, sangría ni orden de presentación de propiedades. Un resultado válido aún puede incumplir el esquema o las reglas de negocio de la API.

Simular JSON Merge Patch

Ejemplos didácticos originales; no se modifica ningún documento real.

Dos valores JSON, máximo 4 000 unidades UTF-16 cada uno, 20 contenedores de profundidad y 500 valores por entrada. Perfil numérico: enteros sin fracción ni exponente, de −9 007 199 254 740 991 a +9 007 199 254 740 991. Nombres de miembros únicos; cadenas Unicode sin sustitutos aislados. Son límites de la herramienta.

Cálculo local; la entrada no se envía ni guarda. El resultado queda en esta página.

Simulación actualizada.

Valor resultante

{
    "title": "B",
    "keep": true
}
El mismo null, dos formatosComparación didáctica: borrar un miembro con Merge Patch y asignarle null con JSON Patch produce objetos distintos.Merge Patch{"note": null}{}JSON Patchreplace /note → null{"note": null}
Comparación didáctica: borrar un miembro con Merge Patch y asignarle null con JSON Patch produce objetos distintos. target = {"note":"old"}
Diez fusiones: destino, patch y resultado
Diez fusiones: destino, patch y resultado
PasoDestino inicialPatch que aplicarValor resultante
1
{
    "title": "A",
    "note": "old",
    "keep": true
}
{
    "note": null,
    "title": "B"
}
{
    "title": "B",
    "keep": true
}
2
{
    "items": [
        "A",
        "B",
        "C"
    ]
}
{
    "items": [
        "B"
    ]
}
{
    "items": [
        "B"
    ]
}
3
[
    1,
    2
]
{
    "x": 1
}
{
    "x": 1
}
4
{
    "x": 1
}
null
null
5
[]
{
    "missing": null
}
[]
6
7
[]
[]
7
{
    "a": {
        "x": 1,
        "y": 2
    },
    "z": 3
}
{
    "a": {
        "x": null
    }
}
{
    "a": {
        "y": 2
    },
    "z": 3
}
8
{
    "a": null,
    "b": 5
}
{
    "b": 0,
    "c": false,
    "d": ""
}
{
    "a": null,
    "b": 0,
    "c": false,
    "d": ""
}
9
{
    "items": [
        "A",
        "B"
    ]
}
{
    "items": [
        "X"
    ]
}
{
    "items": [
        "X"
    ]
}
10
{
    "__proto__": {
        "x": 1
    },
    "constructor": 2
}
{
    "__proto__": {
        "y": 3
    }
}
{
    "__proto__": {
        "x": 1,
        "y": 3
    },
    "constructor": 2
}

Qué conservar en el expediente

La simulación no modifica recursos ni verifica permisos, contrato de API o concurrencia. Los límites numéricos y de entrada protegen la lectura del navegador; no definen todo JSON. Registra por separado identificador y versión del recurso actualizado.

¿Un objeto vacío siempre significa «no cambiar nada»?

No. En Merge Patch, {} conserva un objeto, pero sustituye un destino no objeto por un objeto vacío. El significado depende del tipo en ese nivel. Validar el esquema después es otro control.

Documentación primaria

Documentación consultada el .

Revisión antes de decidir

Estas preguntas completan el método. Ayudan a determinar lo respaldado sin eliminar las reservas del registro.

Hechos visibles

¿Tiene cada fecha, precio, función, reseña o disponibilidad marcada un equivalente visible y justificado? Quite propiedades inferidas u obsoletas en vez de rellenarlas artificialmente.

Ver una decisión comentada

Ejemplo ficticio: el estado se refiere únicamente al criterio y alcance descritos.

Observación ficticia
JSON-LD indica 100; la página muestra 120 para la misma oferta y periodo.
Estado declarado
Discrepancia observada
Decisión y próximo control
Restablezca un valor visible y justificado común. Compruebe variantes y dato que genera el marcado.

Sintaxis y alcance

¿Pasan tipo, propiedades y relaciones el validador adecuado? Distinga validez del marcado, reglas de la función de búsqueda y visualización observada.

Ver una decisión comentada

Ejemplo ficticio: el estado se refiere únicamente al criterio y alcance descritos.

Observación ficticia
El validador no señala errores; no hay observación del resultado de búsqueda.
Estado declarado
No comprobado
Decisión y próximo control
Conserve la validación sintáctica y deje sin verificar la visualización real. No prometa resultados enriquecidos.

Ejemplo u oferta actual

¿El marcado distingue datos ficticios, valores antiguos y oferta visible? Un ejemplo didáctico no debe convertirse en promesa comercial estructurada.

Documentación consultada : Google Search Central · Structured data policies ·

Ver una decisión comentada

Ejemplo ficticio: el estado se refiere únicamente al criterio y alcance descritos.

Observación ficticia
Un ejercicio declara datos ficticios; su marcado describe un recurso educativo sin oferta de venta.
Estado declarado
Verificado en este alcance
Decisión y próximo control
La naturaleza del contenido es coherente en ese alcance. Revise si pasa a ser una oferta real.

HERRAMIENTAS / REGISTROS

Información que registrar

Compare las propiedades declaradas con el contenido visible y las fuentes. Un JSON válido puede ser falso; la validación técnica no sustituye la comprobación editorial.

  • Fecha de consulta y zona horaria
  • URL exacta
  • Tipo de documento
  • Afirmación que verificar
  • Resultado observado
  • Criterio de validación
  • Decisión / próxima acción
  • Responsable del control
  • Próximo control

03 / FAQ

Preguntas frecuentes

¿JSON-LD garantiza un resultado enriquecido?

No. El tipo debe ser pertinente y cumplir las reglas; el buscador decide si lo muestra.

¿Hay que marcar todas las FAQ?

No. Una FAQ útil puede permanecer en HTML sin marcado específico.

¿Qué pasa si los títulos cambian de idioma?

Cada versión debe describir su propio contenido visible y mantener URL y códigos coherentes.

¿Se puede describir un servicio ausente?

No. El marcado debe representar la página sin añadir una promesa no comprobable.

¿Cómo controlar los valores repetidos en varias páginas?

Identificadores y propiedades comunes. Compare sus valores con las referencias del sitio, y luego verifique los modelos que los producen para corregir la causa y los acontecimientos dependientes.

Describir un contexto

REFERENCIAS DOCUMENTADAS

JSON Schema: presente, no nulo y permitido son controles distintos

Se usa dialecto 2020-12 y un validador compatible. Fragmentos educativos. Reglas de objeto suponen type: object; required solo no lo impone.

JSON Schema: presente, no nulo y permitido son controles distintos
ReferenciaValor o formaQué identifica
$schemahttps://json-schema.org/draft/2020-12/schemaURI declara dialecto; registre versión del validador.
propertiesPropiedad presenteproperties valida claves presentes, no exige presencia.
required: ["id"]Presencia ≠ no nulorequired ["id"] exige clave, pero null cuenta como presente.
type: ["string", "null"]Texto o JSON nullstring/null permite ambos; presencia y nulidad siguen separadas.
additionalProperties: falseÁmbito de declaraciones hermanasadditionalProperties considera declaraciones hermanas, no descubre automáticamente otro allOf.
unevaluatedProperties: falsePropiedades evaluadas entre subesquemasunevaluatedProperties considera propiedades evaluadas por subesquemas aplicables exitosos; compruebe soporte.

Qué conservar en el expediente

Conformidad estructural no prueba registro o relación real. Separe sintaxis, esquema y negocio.

¿properties id:string obliga a id?

No: declare objeto, required y política null por separado.

Documentación primaria

Documentación consultada el .

PROFUNDIZACIÓN / PRÁCTICA

Comprobar la coherencia más allá de la sintaxis

Un validador acepta la etiqueta cuando un nombre, fecha o URL ya no corresponde a la página. El control debe aproximar los datos declarados a la información publicada.

Actualizado el .

Comprobaciones prioritarias

Examinar los objetos, sus identificadores y sus relaciones. Verificar las URL finales, las fechas y las propiedades repetidas en varias páginas, y luego detectar las contradicciones.

Errores de interpretación

Un aviso de validación no siempre tiene el mismo efecto que un dato falso. La prioridad depende de la propiedad, su uso y la información que busca representar.

Documento de trabajo que conservar

El registro distingue el error de síntesis, la propiedad ausente y la contradicción de fondo. Cada corrección incluye un control de la etiqueta y la página visible.