Losayudan a los motores de búsqueda a comprender mejor la información contenida en las páginas web. La llamada anotación semánticade datos estructurados deja a los robots establecer vínculos de significado y también interpretar los datos de forma automática para traducirlos en otros formatos visuales. Google, hasta el instante el buscador más utilizado con diferencia, se apoya en los datos estructurados para entregar a los usuarios resultados enriquecidos en las páginas de resultados de búsqueda (SERP). ¿Cuál es la ventaja para los administradores de estas páginas? Estos resultados resaltan entre el resto y aumentan la visibilidad de la oferta.
Para que esto resulte posible se debe marcar la información relevante semánticamente con las consecuentes etiquetas. Con este fin, durante los años la comunidad de Internet ha ido desarrollando diversos estándares de estructuración de datos. A continuación te contamos por qué deberías priorizar a JSON-LD ante formatos alternativos como microformatos,o.
Back to top1) ¿Qué es JSON-LD?
, acrónimo de JavaScript Object Notation for Linked Data, es un método basado en JSON para añadir datos estructurados a páginas web aunque,a diferencia de otros formatos para articular datos como microformatos, RDFa o bien microdatos, aquí el etiquetado no se realiza como anotación intercalada en el código fuente. En vez de ello, los metadatos se incorporan en una etiqueta <script> separada del contenido,bien en el encabezado (<head>) o en el cuerpo (<body>) del documento HTML. Para poder hacerlo, JSON-LD se fundamenta en la notación JSON y la amplía con una sintaxis con la cual los datos se marcan en función de esquemas de validez universal.
Lafue elaborada por el creador de Digital Bazaar Manu Sporny y figura como recomendación oficial del W3C desde el dieciseis de enero de 2014.
JSON-LD es una sintaxis recomendada por el W3C con la cual es posible integrar en el compacto formato JSON tanto datos estructurados como los esquemas para la estructuración de datos.
Este término hace referencia a la notación de objetos con JavaScript (JavaScript Oject Notation) y designa a un formato compacto y basado en texto para el intercambio de datosfácilmente interpretable tanto por personas como por máquinas. Este formato de datos es una derivación de JavaScript, aunque se puede emplear en cualquier plataforma con independencia del lenguaje de programación usado. Como formato de texto para la serialización de datos estructurados (la representación de objetos programables en una secuencia), JSON acostumbra a emplearse para transferir y almacenar datos estructurados, en aplicaciones web y en aplicaciones móviles.
La sintaxis de un objeto JSON se compone esencialmente de pares nombre:valor entrecomillados (a excepción de los valores numéricos), separados por 2 puntos y escritos entre llaves. Cada par nombre:valor suele comenzar en una nueva línea y termina con una coma, excluyendo al último par que antecede a la llave de cierre y se anota sin coma:
El siguiente ejemplo ilustra el esquema básico de la sintaxis de JSON:
En el primer fragmento de texto se incluyen los palabras “Manu Sporny”. Una persona que los lea entiende que esta secuencia de letras, por el contexto, corresponde a un nombre propio, y que el enlace conduce a la página web del desarrollador de JSON-LD. En cambio, los navegadores y los robots de los buscadores necesitan metadatos que les ayuden a procesarestas relaciones semánticas. Esto es lo que ofrece JSON con los pares nombre:valor.
El ejemplo mostrado arriba muestra los 2 elementos “name” y “homepage” con sus respectivos valores. Un programa que interpreta a una página con este objeto JSON es capaz de identificar fácilmente a “Manu Sporny” como el nombre de una persona y a “/about/” como su página web.
1.1) Linked Data (LD)
Si en una página la asignación de significado con JSON se realiza sin inconvenientes, no ocurre lo mismo con el análisis de datos JSON de diferentes páginas, que deriva fácilmente en un problema de ambigüedad. En general, las máquinas examinan semánticamente una enorme pluralidad de páginas web y ordenan la información que extraen de ellas en bases de datos. Mas el código usado arriba, por ejemplo, no garantiza de forma absoluta que los elementos “name” y “homepage” se usen en diferentes páginas web siempre y en toda circunstancia en exactamente el mismo contexto. En consecuencia y para excluir ambivalencias, JSON-LD completa la clásica anotación JSON con elementos de contextosobre la base de los datos enlazadoso linked data (LD), datos estructurados conectados entre sí e identificados por URI (identificador de recursos uniforme) de manera que los rastreadores puedan “entender” las relaciones semánticas que les dan sentido.
En este vídeo, el desarrollador de JSON-LD Manu Sporny aclara en qué consisten los datos enlazados:
Para proteger tu privacidad, el vídeo se cargará tras hacer click.
Para que JSON pueda enlazar datos, JSON-LD completa los clásicos pares nombre:valor propios del marcado JSON con palabras clave(palabras clave). En la sintaxis de JSON-LD las palabras clave siempre van antecedidas de una @ y, entre ellas, @contexty @typetienen singular importancia: mientras que la primera define el vocabulario en que se fundamenta el script, la segunda hace referencia al tipo de datos (esquema) del que se trata.
El proyecto Schema.orgofrece una base de datos de esquemas estandarizados para articular datos. En sulos webmasters tienen acceso a un diccionario que comprende todos y cada uno de los géneros de datos (types) que pueden usarse así como las propiedades (properties) subordinadas a cada tipo y que facilitan un etiquetado semántico aún más detallado del contenido.
JSON-LD no se asocia en principio a ningún vocabulario de manera especial, si bien el proyecto Schema.org, desarrollado en colaboración por los principales buscadores Bing, Google y Yahoo!, está considerado de factocomo el estándar para la anotación semántica.
Si añadimos al ejemplo anterior las etiquetas semánticas correspondientes, resulta el siguiente script:
La palabra clave @context en la línea dos define el diccionario que se utiliza para marcar los datos, en un caso así Schema.org. En la línea tres se introduce el género de dato “Person” con ayuda de la palabra clave @type, que se detalla un poco más en las líneas cuatro y 5 con las propiedades “name” y “url”. Un programa que indexe este código puede identificar el factor de texto “Manu Sporny” marcado como “name” como el nombre de una persona según le indica el tipo “Person” de Schema.org. Los pares nombre:valor encabezados por “name” y “url” se procesan como propiedades (properties) del esquema “Person”. El esquema de Schema.org establece qué características corresponden a cada tipo.
Para proteger tu privacidad, el vídeo se cargará tras hacer click.
Back to top2) Ventajas de JSON-LD en frente de otros formatos de datos
La asignación de esquemasy propiedades en JSON-LD marcha de forma análoga a otros formatospara el marcado semántico de contenidos web. Transformado a código fuente, el script del ejemplo también se puede marcar con microdatos o bien RDFa siguiendo a Schema.org sin que resulte en una pérdida de información:
Sintaxis de microdatos según Schema.org:
Sintaxis RDFa según Schema.org:
Con todo, la gran ventaja que ofrece JSON-LD frente al resto de formatos contrincantes es que los metadatos no se integran en el código HTML, sino se pueden implementar como un bloque de código autónomo en el sitio que interese. Esto se efectúa mediante una etiqueta <script> siguiendo el siguiente esquema:
Si empleamos nuestro ejemplo obtenemos la siguiente anotación:
Aun cuando JSON se anota en etiquetas script, no forma código ejecutable.
Esta rigurosa separación entre código HTML, por un lado, y anotación semántica, por el otro, no solamente contribuye a que el código sea más fácil de leer, sino que además posibilita la generación dinámica de estructuras de datos con independencia del contenido visible: con JSON-LD, introducir, extraer de una base de datos o bien generar metadatos a partir de una plantillason acciones que pueden hacerse en el backend. Esto permite también el marcado semántico de los contenidos dinámicos, cuya demanda de espacio en Internet es cada vez mayor.
Back to top3) JSON-LD y SEO
Si el proyecto Schema.org no oculta su predilección por JSON-LD como uno de los formatos de datos más relevantes ya desde junio de dos mil trece, Google recomienda la integración de metadatos con JSON-LD siempre que sea posible por formar el fundamento de distintos elementos de las SERP(Search Engine Results Pages) que el buscador usa para presentar resultados ampliados a sus búsquedas.
A la hora de mostrar sus resultados, Google usa diferentes formatos: además de los basic resultso resultados simples, desde hace unos años los usuarios del buscador también obtienen, en función de su consulta, los llamados featured results(resultados señalados) y los knowledge graph results(resultados con gráfico de conocimiento). Al paso que los resultados simples solo se ven ampliados con breadcrumbs como único complemento, los resultados señalados y los gráficos de conocimiento son capaces de aceptar más datos extra, lo que Google llama también Enhancements o bien Search Results Features.
En la terminología de Google, el término Featured Result se emplea para llamar a los resultados ampliados que presentan contenido procedente de una sola fuente (la página web enlazada). A los elementos de este tipo también se les conoce como Rich Search Result y Rich Card (tarjeta enriquecida). Si un resultado señalado permite la interacción pasa a conocerse como Enriched Search Result (resultado enriquecido). Para realizar los gráficos de conocimiento, por el contrario, Google no se apoya en una única web, sino en el Knowledge Graph, un algoritmo que sintetiza contenido desde diferentes fuentes dando forma a resultados que también se conocen como tarjetas, cajas o bien cuadros de gráfico de conocimiento (Knowledge Graph Cards, Knowledge Graph Boxes, Knowledge Graph Displays). Cuando el buscador halla diferentes tarjetas enriquecidas o bien gráficos de conocimiento para una misma consulta, las muestra en forma de carrusel, un tipo de lista en forma de carrete que sirve para enseñar géneros de datos diferentes.
En la actualidad Google+ soporta marcas JSON-LD para las extensiones que prosiguen a continuación. En la galería de búsqueda deel proveedor presenta un caso para cada formato destacado.
-
Breadcrumbs: la llamada navegación con migas de pan muestra la posición de la página actual en la jerarquía de la página web. Si su administrador web marca las migas de pan semánticamente facilita que Google+ la pueda mostrar en la página de resultados. Las breadcrumbs se cuentan entre los pocos elementos propios (Search result features) que Google plus también incluye en los resultados simples.
-
Datos de contacto corporativos: si las compañías marcan semánticamente su información de contacto, Google+ puede mostrarla en las SERP como Knowledge Graph Display, uno de los formatos visuales que torna posible el algoritmo de gráfico de conocimiento.
-
Logotipos: cuando se marcan los logotipos, se deja claro al buscador qué gráfico tiene que emplear como logotipo corporativo oficial. Es lo que deja a Google+ ampliar los resultados de búsqueda de una empresa con su pertinente logo.
-
Cuadro de búsquedas para vínculos de sitios (sitelinks searchbox):hay páginas que tienen un buscador propio. Si está etiquetado semánticamente, Google plus lo incluye en el resultado de búsqueda de la página para consultar su contenido directamente desde aquí.
- Vínculos a perfiles sociales:si se han marcado los enlaces a los perfiles sociales como datos estructurados, Google+ amplía el Knowledge Graph Display de personas y organizaciones con los botones correspondientes. Por el momento Google plus soporta el marcado JSON-LD para Fb, Twitter, Google+, Instagram, YouTube, LinkedIn, Myspace, Pinterest, SoundCloud y Tumblr.
Los propietarios de páginas web que aspiran a colocar su contenido en las SERP de forma sobresaliente cuentan con la opción de identificar semánticamente diferentes géneros de datos, si bien se ha de tener en cuenta que es Google+ quien decide en última instancia si un resultado de búsqueda se muestra como resultado simple o enriquecido. Google plus aguanta hasta ahora la anotación JSON-LD para los siguientes tipos de datos y la usa para procesarlos como Rich Search Results, Enriched Search Results o Knowledge Graph Results:
-
Artículos: identificando semánticamente los artículos periodísticos o bien las entradas de weblog los administradores web dejan que Google+ los incorpore en el carrusel de historias primordiales (Top stories carousel) o los complemente en las SERP con Search Result Features como titulares o imágenes de vista previa.
-
Libros: en el momento en que una web ofrece un marcado JSON-LD para la información que hace referencia a libros Google plus crea una tarjeta gráfica de conocimiento para las consultas relevantes que no solo contiene datos interesantes sobre el libro, sino que también permite adquirirlo de forma directa desde el buscador.
-
Música(músicos y álbumes): la oferta musical también se puede marcar de forma similar, lo que deja a Google+ crear tarjetas gráficas de conocimiento para contenido musical que ofrecen al usuario datos sobre álbumes y músicos a la par que permiten interaccionar con el contenido reproduciéndolo o bien aun adquiriéndolo.
-
Cursos: cuando se ofrece oferta educativa en la web y se marca con JSON-LD de forma que el rastreador pueda leer automáticamente el título, una breve descripción y el ofertante, se obtiene el beneficio de que Google plus muestre esta información como resultado enriquecido.
-
Eventos: los organizadores de conciertos y festivales tienen la posibilidad de etiquetar con JSON-LD todos los datos relevantes relativos al sitio, la fecha y la hora del evento de tal forma que Google plus pueda extraerlos y enumerarlos automáticamente en las SERP o bien en los mapas.
-
Ofertas de trabajo: las vacantes que las empresas y las organizaciones publican en su web también se pueden marcar de esta forma para mostrarlos como resultados enriquecidos.
-
Negocios locales: los mercaderes de ámbito local que ofrecen datos estructurados en su página dejan que Google plus pueda crear tarjetas enriquecidas que se muestren en las SERP o bien en los mapas para las búsquedas relevantes. Si un usuario busca un restaurant asiático en Google plus, el buscador reproduce un carrusel con las ofertas pertinentes de la zona.
-
Conjuntos de datos: las bases de datos como las tablas en CSV o los ficheros en formatos propietarios también pueden hacerse accesibles al motor de búsqueda con JSON-LD.
-
Podcasts: Google+ soporta JSON-LD también para marcar los datos sobre podcasts. Si se hace, el motor de búsqueda lo muestra como contenido enriquecido.
-
Vídeos: los distribuidores de contenido que ofrecen datos estructurados, como la descripción, un link a una imagen de vista previa, la fecha de su subida o bien su duración, para los vídeos que publican en sus páginas web, posibilitan que Google plus extraiga esta información y la presente como tarjeta enriquecida o bien como un carrusel.
-
Películas y espectáculos: si una web entrega datos estructurados sobre oferta cinematográfica o bien espectáculos, Google+ los incorpora como tarjeta gráfica enriquecida cuando son relevantes para la búsqueda. Estas tarjetas pueden ampliarse con elementos interactivos que permiten consumir o adquirir la oferta.
- Recetas de cocina: desde hace algunos años, Google+ también ofrece recetas gastronómicas como resultado señalado. El único requisito consiste en ofrecer toda la información relevante que compone una receta como datos estructurados. Un posible formato resultante podría ser un carrusel compuesto por las tarjetas enriquecidas pertinentes para la búsqueda.
-
Críticas: Google+ aguanta valoraciones para diferentes tipos de datos Schema.org como negocios locales, restaurantes, productos, libros, películas u obras creativas y su representación visual tiene sitio como snippet (recorte). Google plus diferencia entre las críticas de autores apartados y los comentarios en portales de valoraciones. Si han sido anotados semánticamente, ambos tipos de crítica se muestran como resultado destacado en las SERP.
- Productos: los mercaderes en línea que proveen los datos sobre sus artículos como el costo, la disponibilidad o bien las valoraciones como datos estructurados permiten que Google+ muestre esta información como resultados enriquecidos en búsquedas coincidentes.
Los resultados enriquecidos, ya se trate de featured results o Knowledge Graph Displays, presentan sobre todo una ventaja para los administradores web, y es que destacan de entre todos y cada uno de los demás resultados. Google+ dispone los cuadros gráficos y los carruseles en un lugar preeminenteencima de los resultados simples, esto es, al comienzo de la página. Los Knowledge Graph Displays pueden aparecer también como carrusel en el borde superior o bien a la derecha de los resultados orgánicos enmarcados en un cuadro. Es así como los resultados enriquecidos ofrecen la ocasión de lograr la mejor posición de la página de resultados sin invertir bastante tiempo y dinero en la mejora del ranking orgánico.
Aun así, no solo el mejor posicionamiento, sino también algunos elementos como las imágenes de vista previa, las puntuaciones, los fragmentos de texto y los elementos interactivos captan la atención del internauta y fomentan las ganas de pinchar en los enlaces. Se puede asumir indudablemente que la tasa de clicsen los resultados enriquecidos es más elevada que en los resultados simples.
También en cuanto a la tasa de rebote puede deducirse un efecto positivo de los resultados ampliados. A diferencia de los basic results, que por norma general solo incluyen un metatítulo, un URL y una breve descripción, los resultados enriquecidos permiten hacerse una idea más detallada del contenido que puede esperarse de la página web enlazada, de tal modo que ya antes de abrirla puede probarse su relevancia para con la consulta efectuada y solo pulsar en el enlace si es realmente necesario.
Con todo, Google+ no considera la presencia o bien la ausencia de marcado semántico con JSON-LD como un factor de ranking, como puso de relieve ya en dos mil doce Matt Cutts, exjefe del equipo de spam de Google plus Web, en el próximo vídeo incluido en la serie Google plus Webmasters:
Para proteger tu privacidad, el vídeo se cargará tras hacer clic.
Tal y como la concentración del marcado en bloques de script separados propia de JSON-LD le supera ante otros formatos, también lo hace en el indexado de páginas. En comparación con métodos alternativos de anotación como microdatos o RDFa, JSON-LD facilita que el código fuente sea liviano y que los bots de Google plus y otros rastreadores los puedan explorar y también indexar fácilmente. No obstante, esto también tiene sus desventajas. En Google+ y otros buscadores se acostumbra a estimar como regla fundamental marcar como contenido inteligible para las máquinas solo aquel que también se pone a disposición del usuario, pero con JSON-LD, en cambio, se puede implementar teóricamente cualquier marcado, incluso cuando en el contenido mismo de la página web no existe ningún equivalente para los metadatos que se han seleccionado. En este caso se está prometiendo, tanto al motor de búsqueda como al usuario, un hipotético valor añadido que una página así configurada en realidad no ofrece. Usando este método se corre el riesgo de ser sancionado como medida contra el spam web.
Con el fin de evitar que los webmasters sobrepasen involuntariamente los límites de la anotación semántica conforme con los motores de búsqueda, Google plus provee con las un conjunto de reglas que, reduciéndolo a lo esencial, podemos sintetizar en los próximos puntos:
-
Formato: los datos han de estar estructurados en función de uno de los 3 formatos consolidados, estos son, microdatos, RDFa o JSON-LD. Google plus aconseja el último.
-
Accesibilidad: las páginas con datos estructurados han de ser accesibles para el Googlebot. Los métodos que controlan su acceso (robots.txt o bien noindex) impiden la lectura de los metadatos.
-
Equivalencia de contenido: la anotación JSON-LD solo puede describir entidades que también se describen en el código HTML.
-
Relevancia: una anotación JSON-LD solo debería tomar como referencia las correspondencias relevantes de los modelos de datos usados. Si se marca un manual técnico como receta se infringe la directiva de relevancia.
-
Integridad: todos las clases de datos representados en la anotación JSON-LD se han de marcar de forma íntegra y con las propiedades precisas. Los modelos de datos que carecen de propiedades esenciales no se ajustan a los resultados enriquecidos.
- Especificidad: los proyectos de datos enlazados como Schema.org ofrecen una enorme diversidad de géneros de datos. Con la intención de clasificar el contenido para una representación ampliada en los resultados de búsqueda hay que elegir los esquemas tan específicamente como sea posible.
Básicamente, se cree que cuantas más propiedades se faciliten en forma de datos estructurados más elevado es el valor añadido para el usuario. En consecuencia, a la hora de posicionar las tarjetas enriquecidas Google tiene presente la amplitud de los datos proveídos, aunque también los webmasters se favorecen de una anotación lo más completa posible. Tomando el ejemplo de las ofertas de empleo, los usuarios prefieren encontrar aquellas vacantes que incluyan datos como el salario o valoraciones.
Back to top4) JSON-LD según Schema.org: manual «paso a paso»
A continuación mostramos cómo puedes enriquecer tu página web con metadatos relevantes. Este tutorial de JSON-LD se fundamenta en el léxico provisto por el proyecto Schema.org.
4.1) 1.Reflexiones previas
El mayor o menor trabajo derivado de la implementación de datos estructurados depende de la amplitud de la oferta web, por tanto, es recomendable meditar con antelación qué objetivosse desean lograr con la anotación semántica y cuánto tiempose está presto a invertir para esto.
La anotación tiene que estructurar los datos de la página web y ofrecerlos en una forma que puedan leer los motores de búsqueda, puesto que lo que se quiere probar es que esta página, optimizada de esta manera, provee los mejores recursos para búsquedas relevantes sobre la especialidad temática del proyecto. Por lo tanto, procura responder a estas preguntas:
- ¿Cuál es el contenido principal de tu página web?
- ¿Qué valor añadido ofrece este contenido a las visitas potenciales?
- ¿Qué textos son tan relevantes temáticamente en relación con el foco de la página web que deberían anotarse de una manera afable para los buscadores?
4.2) 2.Determina los textos más relevantes
Elabora una lista de todo aquel contenido que ofrece un valor añadido y decide sobre qué artículos sería conveniente llamar la atención del lector en potencia ya en las páginas de resultados.
Google propone, por poner un ejemplo, anotar con JSON-LD los datos que hacen referencia a eventos. En HTML las noticias sobre conciertos, obras teatrales musical o representaciones teatrales se representan así:
La información más típica que comprende el objeto “Evento” hace referencia a la data y la hora, el precio, la disponibilidad de entradas, la dirección o los enlaces a información complementaria sobre el acontecimiento o bien el lugar donde tiene lugar. Los usuarios humanos son capaces de extraer esta información de un texto, de una tabla o de cualquier formato informativo y ponerlo en su contexto, pero los programas, tales como los rastreadores de los buscadores web, necesitan metadatos que les señalen cómo deben procesar toda esta información. JSON-LD se los facilita como un formato de datos que se incluye en el código fuente en HTML de forma independiente del contenido.
Las reglas para crear anotaciones JSON-LD y también integrarlas en una página web las facilita Schema.org.
4.3) 3.Seleccionar los esquemas
En efecto, Schema.org ofrece a los gestores de páginas web un extenso lenguaje para estructurar datos que abarca un total de en torno a 600 tiposque a su vez pueden especificarse con más de 860 propiedades.
A la hora de elegir los tipos más adecuados, un administrador web podría proseguir dos estrategias:
- En principio podría cotejar los contenidos definidos al principio con las clases de datos libres en el diccionario de Schema.org y a partir de aquí escoger el tipo más ceñido a cada elemento de contenido, pero este método es lento y en general superfluo.
- En la práctica, los webmasters suelen limitarse a un conjunto determinado de tipos. Si tu objetivo en el momento de incorporar una anotación JSON-LD es simplemente proveer datos estructurados a los motores de búsqueda, sería suficiente con que te limitaras a los modelos que Google soporta hoy día y que describe a fondo en la sección para desarrolladores.
Como intuyes, la segunda opción es la más aconsejable precisamente porque para todos los tipos que soporta su buscador, Google ofrece una detallada documentación con una anotación de ejemplopara cada tipo.
Utiliza los ejemplos que Google facilita en su página para desarrolladores como plantilla para tus anotaciones.
Para poder optimizar tu página web con datos estructurados no hay que descubrir América. Singularmente si aún no cuentas con mucha experiencia con la sintaxis de JSON-LD, recurrir a modelos predefinidos en lugar de escribirlos desde cero puede suponer un ahorro esencial de tiempo y energía. En lase halla la siguiente anotación para acontecimientos como ejemplo:
Las etiquetas script de apertura y cierre definen el elemento desde la línea uno hasta la tres como un script del tipo “application/ld+json”,lo que quiere decir que los datos que encierra se dirigen a programas con capacidad para interpretar datos enlazados en formato JSON.
En un primer nivel se encuentran las palabras clave “@context” y “@type” con los valores “” y “event” respectivamente (líneas tres y cuatro). El programa consigue con ellas la instrucción de que los datos que siguen pertenecen al esquema “Event” según Schema.org, es decir, se trata de propiedades específicas del acontecimiento que se describe, que se muestran como pares nombre:valor.
En este mismo nivel también aparecen las propiedades “name”, “startDate”, “location”, “image”, “description”, “enddate”, “offers” y “performer”, a las que se asignan los datos sobre el acontecimiento como valor. Es así como un rastreador del buscador puede identificar sin atisbo de duda la información “Lieberman Concert Series: Journey in Jazz” como título del espectáculo (“name”) y “ T19:30-08:00” como el instante preciso en que tiene lugar (“startDate”).
Al igual que RDFa y microdatos, la sintaxis de JSON-LD también aguanta la anidación(nesting), por la cual a una propiedad también puede asignarse un esquema secundario que por su parte puede concretarse aún más detalladamente con otras propiedades. Así lo hallamos en el segundo nivel del código en las líneas ocho, dos y 3..
En la octava línea, por servirnos de un ejemplo, la propiedad “location” se define como un subesquema del tipo “Place” y detallado con las propiedades “name” y “address”. Además, la propiedad “address” se define en la línea 1. como subesquema del tipo “PostalAddress” y con las propiedades “streetAddress”, “addressLocality”, “postalCode”, “addressRegion” y “addressCountry”.
Cada nuevo nivel se delimita con claves para separarlo del nivel superior al que se subordina.
Fragmento (líneas 07—18):
Como vemos, Schema.org pone a disposición de los webmasters las clases de datos en una estructura de árbol que partiendo del tipo más general “Thing” (cosa) va descendiendo hacia el nivel más concreto.
En el siguiente paso mostramos cómo puedes adaptar el ejemplo de Google para “Event” a tu propio evento.
4.4) 4.Modificar una anotación JSON-LD
En la documentación de Google se incluyen únicamente ejemplos que ilustran cómo marcar los tipos explicados con JSON-LD, pero si se emplean como plantilla el código se debe ajustar a cada caso. Frecuentemente puede resultar de mucha ayuda echar un vistazo a la propiaa propósito de los modelos de datos para conocer mejor un determinado esquema así como las propiedades que se le pueden asignar. En el próximo ejemplo puedes entender cómo se personaliza un código de Google para el tipo Event:
En un primer paso se han sustituido todos los valores de la plantilla por los valores del acontecimiento y eliminado o bien modificado aquellos esquemas y propiedades que no se ajustaban a él. Por servirnos de un ejemplo, en el subesquema “performer”, en lugar de “PerformingGroup” se ha empleado “Person”, en tanto que el evento no está protagonizado por una banda, sino más bien por un solo artista. Asimismo hemos ampliado la anotación con datos que el modelo de Google no incluye: en las líneas siete y uno se incluyen los URL del acontecimiento y del lugar donde se celebra. En la documentación de Schema.org encuentras todas y cada una de las propiedades que puedes utilizar.
Incluso si escribes tu anotación desde cero es recomendable echar una ojeada a la página de la documentación de Google sobre cada tipo por el hecho de que la compañía indica las propiedades que son obligatoriasy las que se recomiendanpara cada uno de las clases que soporta.
Cuida que tu anotación entienda todas y cada una de las propiedades obligatorias porque solo en ese caso la página puede aspirar a clasificarse como resultado enriquecido. Procura, además, proveer de valor a las propiedades recomendadas para incrementar tus opciones de entrar en el ranking.
Los ejemplos que incluye Google en su documentación contienen siempre y en toda circunstancia todas y cada una de las propiedades tanto obligatorias como opcionales. Y si quieres comprobar si falta alguna propiedad en tu anotación usa su propia herramienta de validación.
4.5) 5.Probar la anotación JSON-LD
La anidación de esquemas, esquemas secundarios y propiedades repercute en anotaciones por norma general complejas, aunque la separación de HTML y anotación semántica repercute en una legibilidad mucho mayorque en otros formatos apoyados en código fuente. Con objeto de eludir posibles errores de programación, con la Google ofrece la opción de validar gratuitamente el código JSON-LD que has escrito.
Sigue estos pasos:
- Copia y queja el código en el campo previsto para ello
Puedes copiar la anotación en el campo previsto para esto o bien introducir el URL de la página web cuyos metadatos quieras comprobar.
- Valida el código pulsando en “Ejecutar prueba”
Durante la comprobación, la herramienta lee los datos estructurados de la anotación JSON-LD y verifica su integridad. Seguidamente el usuario consigue una vista de tabla en la que se muestran los datos extraídos y que contiene avisos e indicaciones si la herramienta encuentra errores de sintaxiso si detecta que faltan datos.
Tal como vemos en la imagen, nuestro código no contiene errores e incluye todas y cada una de las propiedades precisas. Si elimináramos la propiedad obligatoria “startDate” recibiríamos la próxima respuesta:
También se pueden encontrar así errores de sintaxis como olvidar la coma al final de un par nombre:valor.
Además de la función de prueba, la herramienta de comprobación de Google también contiene un modo de vista anterior que anticipa el aspecto que podría tener un resultado enriquecido basado en las anotaciones validadas. Para ello solo tienes que pulsar en el botón “Obtener una vista previa”.
Back to top5) Posibles fallos en la implementación de la anotación JSON-LD
Si Google no muestra ningún resultado enriquecido pese a emplear JSON-LD para marcar los datos acostumbra a deberse a un error en la estructuración de los datos, así que lo mejor sería regresar a comprobar el código prestando atención especialmente a estas fuentes frecuentes de error:
-
Error de sintaxis: el vocabulario de JSON-LD es sencillo y claro, mas como ocurre con cualquier lenguaje de marcado, también pueden colarse errores algunas veces. Un motivo frecuente de error radica en la diferencia entre los 2 géneros de comilla inglesa que se usan para la programación ("…") y para la palabra impresa (“…”). Puesto que los programas de procesamiento de textos a menudo transforman las primeras en comillas literarias, puedes evitarte cefaleas si utilizas un editor como Notepad para redactar tu anotación JSON-LD. La comilla simple (' '), tan popular en programación, tampoco se acepta en JSON.
- Vocabulario incompleto, erróneo o poco específico: en la estructura jerárquica de Schema.org se define con exactitud qué propiedades se pueden utilizar para qué género de datos. Si utilizas una propiedad para un tipo no compatible Google no puede interpretar el valor pertinente y clasifica el código como erróneo. La herramienta también descubre este género de fallos.
Todos las clases y propiedades del vocabulario Schema.org son case-sensitive, lo que significa que utilizar mayúscula o minúscula puede provocar diferencias semánticas significativas.
En terminante, ten siempre y en toda circunstancia a mano las páginas de documentación de Schema.org y valida el código que escribes con ayuda de la herramienta de pruebas de Google. Además, resulta conveniente tener en cuenta las Pautas Generales para Datos Estructuradosy lasde Google con tal de eludir una infracción de la normativa que podría conducir a la exclusión del ranking para resultados enriquecidos.
Back to top
