Errores a evitar al aplicar marcado de datos estructurados

Escrito por Ramón Saquete

Los datos estructurados permiten especificar al robot de Google el tipo de información que contiene una web para que pueda interpretarla mejor y, con determinados tipos de datos, enriquecer cómo aparecen los resultados de búsqueda y generar impresiones en asistentes de voz. No obstante, si se aplican incorrectamente, podrían penalizar la página en una revisión manual de Google.

En la documentación sobre las acciones manuales que ejecuta Google para penalizar un sitio, encontramos múltiples ejemplos de mal uso o abuso de datos estructurados. Estos fallos se realizan siempre intencionadamente como estrategia de Black Hat SEO, con el fin de aparecer en los SERPS con fragmentos enriquecidos. Es muy raro cometer uno de estos fallos de forma no intencionada, por lo que aunque reclamemos que lo hemos hecho sin querer, nos van a penalizar igualmente ante una revisión manual.

No debemos tener miedo a que nos penalicen por los datos estructurados, ya que, como ya hemos comentado en otras ocasiones, bien utilizados mejoran el posicionamiento y la visibilidad en las búsquedas, además de las apariciones en búsquedas por voz. Para aprovechar las ventajas de los datos estructurados sin ser penalizados, siempre debemos aplicarlos de forma correcta y sin engaños.

A continuación, vamos a ver cuáles son los tipos de errores que debemos evitar, tanto si queremos que Google interprete correctamente los datos, como si no queremos que nos penalicen. Básicamente, tenemos estos tipos de errores:

1. Los errores sintánticos. Pueden ser de dos tipos:
   1. Los cometidos sobre el formato del lenguaje.
   2. Los cometidos sobre la gramática especificada por los vocabularios de schema.org y Google.
2. Los errores semánticos.

Estos son los mismos errores que se pueden cometer con cualquier lenguaje de marcado.

Errores sintácticos

Los errores sintácticos se producen cuando se escribe un lenguaje y no se siguen las reglas de la gramática del mismo. En el caso de los datos estructurados tenemos que seguir dos tipos de reglas gramaticales: las del formato en el que vamos a escribirlos, por ejemplo JSON-LD, y las reglas gramaticales del lenguaje definido por el vocabulario de schema.org.

Errores sintácticos sobre el formato

Como ya hemos comentado, son los errores cometidos a la hora de escribir el formato de los datos estructurados, ya sea  JSON-LD o microdatos, de forma que el tipo de dato no podrá ser interpretado.

Veamos un ejemplo donde generamos un JSON-LD con varios errores de sintaxis típicos. Uno de ellos, provocado porque no se ha tenido en cuenta que el atributo «license» puede estar vacío a la hora de generar este código:

{
   "@context":"https://schema.org/",
   "@type":"BlogPosting",
   license: 
   headline:"ejemplo",
}

Si no tenemos un valor para «license», deberíamos quitar este atributo o añadir una cadena vacía, de la forma siguiente, para evitar el error de sintaxis y que sea un JSON correcto:

{
   "@context":"https://schema.org/",
   "@type":"BlogPosting",
   "license": "",
   "headline":"ejemplo"
}

Los otros errores de sintaxis corregidos en el ejemplo, por si no los habéis visto, son el entrecomillado de los atributos y la eliminación de la última coma antes del cierre de las llaves. También faltan atributos requeridos, pero eso no son errores por no seguir la sintaxis del formato, sino debidos a no seguir la sintaxis del vocabulario.

Para no cometer errores en la formación de datos estructurados, debemos seguir la gramática de JSON, definida en el RFC 7159, la especificación de JSON-LD en el W3C y la especificación de los microdatos en el WhatWG.

Cuando un lenguaje de marcado sigue las reglas gramaticales de su formato corrrectamente, se dice que está bien formado, (en las herramientas de validación de XMLs, como por ejemplo un sitemap, es común encontrar esta expresión).

Errores sintácticos sobre schema.org y Google

Son los cometidos por no seguir las reglas gramaticales de la especificación de schema.org o Google.

Ejemplos de errores sintácticos de este tipo son:

• Asignar como valor de un atributo, un tipo de dato incorrecto o que no existe. Por ejemplo, si el atributo author sólo puede ser del tipo Organization o Person, no podemos romper las reglas de la gramática asignándole datos del tipo Event.
• Añadir un atributo a un tipo de dato que no lo tiene, por errores a la hora de seguir la especificación. Por ejemplo, añadir el atributo addressLocality directamente al tipo LocalBusiness:

  {
    "@context": "http://schema.org",
    "@type": "LocalBusiness",
    "addressLocality": "Madrid"
  }
  

  Esto es un error porque la especificación indica que LocalBusiness está compuesto por un atributo address del tipo PostalAddress, al que corresponde el atributo addressLocality, y no a LocalBusiness:

  {
    "@context": "http://schema.org",
    "@type": "LocalBusiness",
    "address": {
      "@type": "PostalAddress",
      "addressLocality": "Madrid"
    }
  }
  

Los errores sintácticos por no seguir la especificación del vocabulario se pueden subdividir en dos tipos: los cometidos por no seguir la especificación general de schema.org y los cometidos por no seguir la especificación de Google. Ya explicamos cómo se debe interpretar shcema.org para crear datos estructurados y que en la especificación de Google, nos vamos a encontrar restricciones adicionales a la especificación de schema.org, como qué atributos son los requeridos.

Cuando un lenguaje de marcado sigue las reglas sintácticas de su formato y las del vocabulario, se dice que es válido, lo que además implica que está bien formado.

Diferenciar el tipo de error sintáctico con las herramientas de validación

Los interpretes de las herramientas de validación de datos estructurados no nos dicen directamente si han encontrado errores sintácticos del formato o del vocabulario, pero sí que tienen su propia manera de expresar que han encontrado un error sintáctico del formato, si la herramienta da otro tipo de error, es un error cometido sobre la gramática del vocabulario:

Esto es importante, porque para que el vocabulario de un tipo de dato estructurado sea correcto, primero su formato debe ser sintácticamente correcto. Por lo que si tenemos un sólo error sintáctico en el formato, Google no leerá nada del tipo de dato estructurado y, si no los tenemos, pero tenemos varios errores en el vocabulario, puede que interprete alguna cosa aunque nos señale los errores en rojo.

Errores semánticos

Son aquellos cometidos por darle a los datos un significado distinto al que tienen. Un ejemplo claro y exagerado sería usar para una receta el tipo de dato libro (Book). Sintácticamente podemos hacerlo y, además, el tipo Book y el tipo Recipe heredan los mismos atributos de CreativeWork que podríamos rellenar, pero el significado que le estaríamos dando no sería el correcto.

Es común encontrar casos en los que, aunque no hay error, se puede mejorar el significado. Por ejemplo, asignar el tipo de datos Article a una entrada de un Blog en lugar del tipo derivado BlogPosting. Pero esto no es motivo de penalización.

Ninguna herramienta automática nos dirá si el documento es semánticamente correcto. Esta es la razón por la que Google realiza revisiones manuales y la razón por la que existen los datos estructurados, ya que si la máquina fuera capaz de deducir el significado de los datos y las relaciones entre estos sin equivocarse no sería necesario marcarlos.

Los errores semánticos son los que nos podrían generar una penalización ante una revisión manual, mientras que los errores sintácticos sólo nos generarán avisos de Google Search Console, sin ningún tipo de penalización, más allá de no tener los datos estructurados correctamente.

En la especificación de datos estructurados de Google, nos vamos a encontrar el significado semántico de cada tipo de dato mejor detallado que en schema.org. La documentación del buscador incluye, además, ejemplos para evitar confusiones que puedan conducir a una penalización.

Este es el tipo de error que suelen cometer adrede los SEOs Black Hat. Por ejemplo, últimamente ocurre mucho con los tipos de datos FAQPage y How to. Al comenzar a generar fragmentos enriquecidos en las SERPS y búsquedas de voz, se ha empezado a abusar de ellos. Se introducen en páginas que no son de preguntas y respuestas ni de instrucciones, añadiendo artificialmente trozos de contenido de estos tipos a páginas donde no constituyen su contenido principal, sólo para ocupar más espacio en los resultados, sin tener en cuenta que eso va a restar relevancia a lo que realmente se tiene que posicionar en la página, bajando posiciones y aumentando la tasa de rebote.

Otros errores

Añadir datos de estructurados sobre información que no está en la página o que está oculta al usuario, es un tipo de error habitual de los SEOs Black Hat más atrevidos, que también podríamos considerar error semántico y que es motivo de penalización. Esto suele ocurrir, por ejemplo, con el rich snippet de las opiniones con estrellas para puntuar, con el que se suelen inventar las puntuaciones y ni siquiera aparecen en la página o están ocultas, con el único propósito de aparecer con las estrellas en los resultados.

Recientemente Google ha limitado el número de tipos de datos estructurados a los que se puede aplicar y no permite su uso sobre comentarios gestionados de forma propia en los tipos LocalBusiness y Organization, por el abuso que se hace de este tipo de dato estructurado.

Entre las directrices de Google, podemos encontrar otros requisitos lógicos, como que no se deben aplicar datos estructurados sobre contenidos ilegales como: plagios de contenido, timos, engaños o cualquier tipo de contenido éticamente deplorable.

Conclusión

En las situaciones en las que los datos estructurados no tienen un efecto visual en los resultados, son muy útiles para el posicionamiento, ya que ayudan a especificar el significado de los contenidos al robot, posicionándolos mejor para aquello en lo que sí somos relevantes, disminuyendo la tasa de rebote, lo que a su vez mejora el posicionamiento.

Los cambios visuales de los fragmentos enriquecidos, también son útiles para aumentar el CTR en los SERPS, pero la mayoría de SEOs sólo ven este efecto y, en ocasiones, los SEOs Black Hat abusan de ellos, hasta el punto de distorsionar el significado del contenido de las páginas, lo que es contraproducente y penalizable.

La mejor estrategia con los datos estructurados, como en cualquier aspecto del SEO, es no quitarnos el sombrero blanco e intentar implementarlos de la mejor forma posible.