Comparador de JSON-LD: qué cambió entre dos versiones

Un cambio de tema, una app nueva o una migración pueden reescribir el JSON-LD de tus fichas sin que nada se vea distinto en la página. El comparador pone dos versiones de ese marcado una frente a otra y lista lo que cambió, ruta por ruta. Es para quien tiene una tienda, o la lleva desde una agencia, y necesita saber después de tocar algo si los datos estructurados de una ficha de producto siguen diciendo lo mismo. Funciona en tu navegador: no descarga ninguna página y lo que pegas no sale de ella.

Cuándo lo necesitas

Cuando algo que no controlas del todo escribe el marcado de tus fichas. Los casos típicos:

• Cambias de tema o lo actualizas. Si el marcado sale de la plantilla del tema, una versión nueva puede traer otro marcado, con propiedades de menos o con otra forma.
• Instalas o quitas una app que escribe JSON-LD, como una app de SEO o de reseñas. Dos sistemas que escriben el mismo dato es el terreno de la sobrescritura de campos: gana el último que escribe y el valor anterior se pierde sin aviso.
• Migras de plataforma y conservas las URLs: la página es la misma, pero el marcado lo genera otro sistema.
• Cambias cómo se alimenta el catálogo, por ejemplo con un PIM o una sincronización nueva, y quieres comprobar que la ficha publicada no ha perdido nada.

Lo que buscas en todos los casos es la deriva de datos: la diferencia que aparece entre lo que se publicó bien y lo que la página dice después, porque algo lo cambió.

Cómo conseguir las dos versiones

1. Guarda el antes, antes del cambio. Abre la ficha publicada, mira su código fuente («Ver código fuente de la página», o view-source: delante de la URL), copia todo y guárdalo en un archivo de texto con la fecha. Elige pocas fichas y distintas: un producto sencillo y uno con variantes.
2. Haz el cambio y repite con las mismas URLs.
3. Pega el antes en la primera caja y el después en la segunda. Vale el código fuente entero o solo el JSON-LD, en cualquiera de los dos lados: si el texto empieza por <, el comparador lee todos los bloques application/ld+json del HTML; si no, lo lee como un JSON.
4. Pulsa «Comprobar». «Cargar un ejemplo» rellena las dos cajas con una ficha ficticia antes y después de un cambio de tema.

Compara siempre lo mismo con lo mismo. Si el marcado lo añade JavaScript al cargar la página, no está en el código fuente: copia entonces la página renderizada en los dos lados (herramientas para desarrolladores, Elementos, clic derecho en el elemento <html>, Copiar outerHTML). Comparar el código fuente de antes con la página renderizada de después te dará diferencias que no son del cambio.

Cómo leer el resultado

La línea de recuento dice cuántas rutas se han añadido, quitado y cambiado. Con el ejemplo, «2 añadidos, 2 quitados, 1 cambiados.». Si no hay ninguna diferencia, el comparador lo dice: son iguales, sin contar el orden de las claves ni los espacios.

La tabla tiene cuatro columnas: el resultado (Quitado, Añadido o Cambiado), la ruta, el valor de antes y el de después. Primero van las rutas quitadas, después las añadidas y al final las cambiadas, hasta 400 filas. Las quitadas son las que más conviene leer: una propiedad que ya no está es lo que un cambio de tema rompe sin que se note en la página.

La ruta dice dónde está cada valor. offers.price es el precio dentro de la oferta; image[0] es el primer elemento de una lista; @graph[#product].offers.price es el precio del nodo de @graph cuyo identificador @id es #product.

Los valores se enseñan como JSON: el texto va entre comillas y los números sin ellas. Por eso un precio que pasa de 29.9 a "29.90" sale como cambiado aunque la cifra sea la misma: lo que cambió es el tipo. Decide tú si importa.

En el ejemplo del botón, la ficha ficticia pierde gtin13 y offers.availability, gana brand.@type y brand.name, y su offers.price pasa de "29.90" a "24.90". Tres cosas que no se ven en la página y que cambian lo que una máquina sabe del producto.

Lo que no es una diferencia

• El orden de las claves y los espacios. En JSON, un objeto es una colección no ordenada de pares nombre-valor, y los espacios alrededor de la sintaxis no significan nada.⁠^{[1]IETF. RFC 8259: The JavaScript Object Notation (JSON) Data Interchange Format} El comparador ordena las claves antes de comparar.
• Un nodo que cambia de sitio dentro de @graph con el mismo @id. En JSON-LD, @id identifica el nodo.⁠^{[2]W3C. JSON-LD 1.1} El comparador nombra cada nodo de una lista por su @id cuando lo tiene, así que moverlo no cambia su ruta.

Lo que sale aunque el significado sea el mismo

• Una lista sin @id que cambia de orden. JSON-LD trata las listas como no ordenadas salvo que se diga lo contrario,⁠^{[2]W3C. JSON-LD 1.1} pero el comparador compara por posición: dos imágenes que se intercambian salen como dos cambios.
• Una propiedad que cambia de forma. Si brand pasa de {"@type": "Brand", "name": "Calella"} a "Calella", verás quitadas brand.@type y brand.name y añadida brand.
• Un bloque de más o de menos. Si una versión tiene un bloque JSON-LD y la otra dos, todas las rutas cambian de forma y casi todo sale como quitado y añadido. En ese caso compara bloque a bloque, pegando solo el JSON-LD de cada uno.

Qué mirar primero

No todas las rutas pesan lo mismo. Para una ficha que quiere aparecer en las fichas de comerciante de Google, estas van primero:

• offers.price y offers.priceCurrency. Son obligatorias, el precio tiene que ser mayor que cero y la moneda va en código ISO 4217.⁠^{[3]Google Search Central. Merchant listing (Product, Offer) structured data} Un precio quitado, o uno que cambia sin que haya cambiado el de la página, es lo primero que se arregla.
• offers.availability. Es recomendada y lleva un solo valor.⁠^{[3]Google Search Central. Merchant listing (Product, Offer) structured data} Si desaparece, la ficha deja de decir a una máquina si hay existencias.
• Los GTIN (gtin, gtin8, gtin12, gtin13, gtin14). Google los quiere en forma numérica, no como URL.⁠^{[3]Google Search Central. Merchant listing (Product, Offer) structured data} Si un tema los cambia de propiedad o de formato, pásalos por el validador de GTIN.
• @id. Un nodo que se refiere a otro con solo su @id es una referencia a un nodo definido en otra parte.⁠^{[2]W3C. JSON-LD 1.1} Si el @id de un nodo cambia, las referencias que apuntaban al antiguo dejan de llevar a ninguna parte. En el comparador se ve así: dentro de @graph, el nodo entero sale quitado con el @id viejo y añadido con el nuevo.
• Un Product de más. Si el después tiene dos nodos Product para la misma ficha, uno del tema y otro de una app, los dos describen el mismo producto, y Google pide que el marcado sea un reflejo fiel de la página.⁠^{[4]Google Search Central. General structured data guidelines} Si dicen cosas distintas, al menos uno no lo es.

Lo que el comparador no te dice

• Qué vio Google. Compara lo que pegas. Lo que Google encontró la última vez que indexó la página está en la inspección de URLs de Search Console, que también enseña el código de la página rastreada.⁠^{[5]Ayuda de Search Console. URL Inspection tool}
• Si alguna de las dos versiones es correcta. Un después idéntico al antes puede estar igual de mal. Para lo que falta frente a lo que pide Google está la herramienta de cobertura de datos estructurados; para lo que el marcado dice frente a lo que ve el comprador, la guía para auditar una ficha de producto; y la diferencia entre comprobar un marcado y comprobar lo publicado está en validar frente a verificar.
• Lo que hay al otro lado de una referencia. El comparador compara la estructura de cada versión tal como está escrita; no sigue un @id hasta el nodo al que apunta.
• El marcado que no es JSON-LD. No lee microdatos ni RDFa.

Lo que hemos probado

Probado en: navegador y versión, fecha.