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

GUÍA / PROTOCOLO
Un marcado válido no corrige una página ambigua, datos ausentes ni una identidad no verificada.
Respuesta directa
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
Inventaríe plantillas, tipos de esquema útiles y variantes lingüísticas. Descarte los que no correspondan al contenido.
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.
Use un validador de Schema.org para la estructura y la prueba de resultados enriquecidos para las funciones de Google. Separe errores y avisos.
Pruebe plantillas y páginas reales después de publicar. Revise también idiomas y URL canónicas.
EN LA PRÁCTICA
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.
Elija la situación observada. Cada opción indica un primer control, la prueba útil y su límite.
Para ampliar
| Situación | Evitar | Corrección útil |
|---|---|---|
| Cifra corregida | Cambiar solo el párrafo. | Revisar tabla, leyenda, síntesis y dato estructurado asociados. |
| Página trasladada | Actualizar solo el enlace visible. | Verificar destino, ancla y ruta de regreso. |
| Versión traducida | Copiar palabras dejando un ejemplo obsoleto. | Revisar unidad, fecha, fuente, enlaces y alcance. |
¿Qué afirmaciones dependen del cambio?
¿Qué páginas e idiomas las reproducen?
¿Concuerdan cifras, enlaces y límites?
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.
Consultado el .
Taller de lectura
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.
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.
| Control | Estado DEMO | Qué establece | Corrección que examinar |
|---|---|---|---|
| Sintaxis JSON | Llaves, cadenas y tablas bien formadas | El texto puede analizarse como JSON | Continuar el control semántico. |
| Identidad @id | Mismo #entity para Lina y laboratorio | Confusión de dos objetos distintos en este caso | Asignar identificadores coherentes a los objetos descritos. |
| Autor del artículo | Lina visible; laboratorio en author | Atribución distinta de la página | Usar la autoría respaldada sin convertir organización en persona. |
| Idioma declarado | Artículo francés; inLanguage=en | Se declara otro idioma | Comprobar la entidad artículo y esta variante. |
Abra cada propuesta para comparar su diagnóstico. Pueden seguir siendo necesarios otros controles.
No. Los valores pueden ser válidos gramaticalmente y señalar otro objeto.
No. Sintaxis no garantiza elegibilidad ni presentación.
Sí. Registrar por separado sintaxis, coherencia editorial y criterios aplicables.
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.
02 / Pruebas que conservar
URL, tipo de página, esquema previsto, responsable y fecha.
Valor marcado, prueba visible, origen del campo y diferencia.
Herramienta, URL, fecha, errores, avisos y captura.
Campo corregido o retirado, responsable y comprobación posterior.
PUNTO DE CONTROL
Una interpretación errónea frecuente y la comprobación que ayuda a evitarla.
Una sintaxis JSON-LD válida no basta si el marcado describe datos ausentes, antiguos o contradichos por la página visible.
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
Corrija el marcado o haga visible y verificable el hecho. La sintaxis no garantiza coherencia con el contenido.
Fije una referencia editorial, armonice los campos y revise traducciones antes de validar.
Decisión y trazabilidad
Qué debe permitir decidir la comprobación y qué conservar para revisar esa decisión.
Compare el JSON-LD renderizado con texto visible, URL canónica y propiedades del tipo elegido. Revise varios modelos e idiomas.
Quite propiedades no sustentadas, corrija contradicciones y valide el HTML renderizado. Documente los tipos usados y su mantenimiento.
Situaciones tipo para preparar un control. No describen misiones realizadas ni observaciones reales.
Vincule cada propiedad estructurada con información visible y prueba.
Retire valores sin respaldo; sintaxis válida no confirma una valoración, precio o relación.
Propiedad, texto visible, prueba y corrección elegida.
Compare apariciones del mismo @id y atributos de identidad.
Reserve el identificador a un objeto coherente; distinga persona, organización y página sin duplicar identidades.
Apariciones, objetos afectados y regla de identificación corregida.
Comparar afirmaciones JSON-LD, texto mostrado y fuentes asociadas.
Retirar o corregir propiedades no justificadas por la página.
Propiedad, valor visible, fuente y resultado.
REFERENCIAS DOCUMENTADAS
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.
| Referencia | Valor o forma | Qué identifica |
|---|---|---|
| INPUT | I-JSON · nombres únicos | Los 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. |
| WHITESPACE | sin espacios entre tokens | No se emiten espacios entre tokens. Se conservan los espacios dentro de cadenas; quitar todos los blancos del texto cambiaría los datos. |
| NUMBERS | ECMAScript · IEEE 754 binary64 | Los 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 ORDER | recursivo · unidades UTF-16 | El 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 ORDER | conservado | El orden de los elementos de arrays se conserva, aunque se procesan los objetos internos. Ordenar toda lista cambiaría su significado. |
| UNICODE | conservado · salida UTF-8 | Las cadenas Unicode se conservan: JCS no aplica NFC ni NFKC. La salida final es UTF-8. Canonicalizar JSON no es normalizar lingüísticamente. |
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.
| Puntos de código | Unidades UTF-16 | Rótulo fuente (inglés) |
|---|---|---|
| U+000D | 000D | Carriage Return |
| U+0031 | 0031 | One |
| U+0080 | 0080 | Control |
| U+00F6 | 00F6 | Latin Small Letter O With Diaeresis |
| U+20AC | 20AC | Euro Sign |
| U+1F600 | D83D DE00 | Emoji: Grinning Face |
| U+FB33 | FB33 | Hebrew 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.
Identifique la huella de salida JCS y su perfil. No sustituye la huella de los bytes originales; conserve ambos objetos si necesita trazabilidad.
No por sí solo. No comprueba todas las restricciones ni el orden recursivo. El ejemplo publicado permite detectar un orden Unicode inadecuado.
Documentación consultada el .
REFERENCIAS DOCUMENTADAS
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.
| Referencia | Valor o forma | Qué identifica |
|---|---|---|
| member absent | keep | Un 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: null | delete | Un 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 target | Un 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 / [] / scalar | replace | Un 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 diff | El 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. |
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.
{
"title": "B",
"keep": true
}| Paso | Destino inicial | Patch que aplicar | Valor 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
} |
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.
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 consultada el .
Estas preguntas completan el método. Ayudan a determinar lo respaldado sin eliminar las reservas del registro.
¿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.
Ejemplo ficticio: el estado se refiere únicamente al criterio y alcance descritos.
¿Pasan tipo, propiedades y relaciones el validador adecuado? Distinga validez del marcado, reglas de la función de búsqueda y visualización observada.
Ejemplo ficticio: el estado se refiere únicamente al criterio y alcance descritos.
¿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 ·
Ejemplo ficticio: el estado se refiere únicamente al criterio y alcance descritos.
HERRAMIENTAS / REGISTROS
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.
03 / FAQ
No. El tipo debe ser pertinente y cumplir las reglas; el buscador decide si lo muestra.
No. Una FAQ útil puede permanecer en HTML sin marcado específico.
Cada versión debe describir su propio contenido visible y mantener URL y códigos coherentes.
No. El marcado debe representar la página sin añadir una promesa no comprobable.
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.
04 / Referencias oficiales
REFERENCIAS DOCUMENTADAS
Se usa dialecto 2020-12 y un validador compatible. Fragmentos educativos. Reglas de objeto suponen type: object; required solo no lo impone.
| Referencia | Valor o forma | Qué identifica |
|---|---|---|
| $schema | https://json-schema.org/draft/2020-12/schema | URI declara dialecto; registre versión del validador. |
| properties | Propiedad presente | properties valida claves presentes, no exige presencia. |
| required: ["id"] | Presencia ≠ no nulo | required ["id"] exige clave, pero null cuenta como presente. |
| type: ["string", "null"] | Texto o JSON null | string/null permite ambos; presencia y nulidad siguen separadas. |
| additionalProperties: false | Ámbito de declaraciones hermanas | additionalProperties considera declaraciones hermanas, no descubre automáticamente otro allOf. |
| unevaluatedProperties: false | Propiedades evaluadas entre subesquemas | unevaluatedProperties considera propiedades evaluadas por subesquemas aplicables exitosos; compruebe soporte. |
Conformidad estructural no prueba registro o relación real. Separe sintaxis, esquema y negocio.
No: declare objeto, required y política null por separado.
Documentación consultada el .
PROFUNDIZACIÓN / PRÁCTICA
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 .
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.
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.
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.