Cómo funcionan los Datos Estructurados, de donde vienen, cual es su origen y cómo afectan al SEO y a los Resultados Enriquecidos
Los motores de búsqueda tienen que hacer un gran esfuerzo para comprender el contenido de una página web, a pesar de las actualizaciones tanto de Inteligencia Artificial, como de algoritmos para comprender el lenguaje de una mejor forma.
Por este motivo Google, Bing y Yandex entre otros motores de búsqueda se sumaron al proyecto Schema.org entre otros, para que las webs tuvieran un formato estándar y común para estructurar los datos más importantes de una página.
Los datos estructurados, por lo tanto, sirven para ofrecer una información de datos relevantes a los motores de búsqueda.
Estos datos Google los suele tener en cuenta a la hora de la generación de Resultados Enriquecidos. No obstante el poner unos datos estructurados, aunque estos estén correctamente implementados, no garantizan una aparición en los resultados enriquecidos, ni si quiera que estos correspondan al 100% con lo presentado en los mismos datos estructurados.
Los Datos Estructurados nos ayudan a aparecer en los resultados enriquecidos porque ayuda a los motores de búsqueda a entender nuestro contenido, pero no nos garantiza nada.
Esto puede llevarnos a la pregunta de "para qué sirven entonces". Los Datos Estructurados, son una herramienta más para hacerle entender nuestro contenido a los motores de búsqueda, que esto, sí nos ayudará a aparecer en los Resultados Enriquecidos, aunque no nos lo garantice.
En cualquier caso, antes de pensar en la implementación de datos estructurados, tenemos que tener en cuenta aspectos mucho más básicos y de hecho más importantes para el entendimiento de nuestra web. Como es el uso correcto de HTML con etiquetas como nav, ul, li o los famosísimos Headings que tanto nos apasionan en el SEO (H1,H2,H3).
El HTML es la base de la estructura de una Web y es lo que hará que Google diferencie lo que es una barra de navegación, un encabezado y un listado. Google utiliza el HTML para proporcionar resultados enriquecidos. Ya que lo que hace Google con los Datos Enriquecidos es mostrar al usuario una información (que considera que ha entendido de la página de donde lo ha extraído) que considera que puede satisfacerle la intención de búsqueda lo más rápido posible.
Cuando los datos estructurados aparecieron hubo un momento de caos y lucha para la implementación. A día de hoy hay mayor consenso y lo recomendable es utilizar JSON siempre que sea posible. Sin embargo siempre puede ser útil conocer otro tipo de implementaciones para ver alternativas, o para entender que datos estructurados no tienen sentido en la actualidad.
Es un formato de intercambio de datos que ha venido para ser una gran alternativa de otros formatos de marcado como XML. Pero alejándonos de tecnicismos que se escapan de lo que compete realmente al SEO, JSON se ha convertido en el formato de dato Estructurado más recomendado por los motores de búsqueda, sobre todo desde que Bing y Google lo leen. Ya que JSON no era leído por Bing y había 3 alternativas de datos estructurados que se insertaban en el HTML, y había que cambiar la estructura del HTML para hacer dicha implementación. Cuestión que a día de hoy gracias a este formato no es necesario en absoluto.
La principal ventaja es esa, que no es necesario intercalado con el texto. De esta forma, también es mucho más sencillo expresar elementos "hijos" o que se aniden al elemento principal.
Ambas son especificaciones de HTML, que se deben exponer dentro del código para marcar dichos datos estructurados. Ambos son bastante similares, sin embargo aunque los Microdatos sean de comunidad abierta, el RDFa es más completo. No obstante, no sería de sorprender que fuesen formatos destinados a desaparecer ya que simplemente hacen lo mismo que JSON pero menos completo y más problemático a la hora de implementarlo.
Data Vocabulary fue un formato de datos estructurados auspiciado por Google que se descontinuó en 2020 (no sin avisos previos) y que CMS tan conocidos como Prestashop han seguido empleando hasta no hace tanto. La propia web avisa de su descontinuación. Por lo tanto a día de hoy no funciona ni tiene sentido emplearlo.
Esta suele ser la mayor duda de cara al sector SEO. Además de cuestiones como comprobar que hace la competencia (por cierto, la competencia no siempre tiene por qué hacerlo bien), lo ideal y más fácil es comprobar si el elemento principal de nuestra web aparece en el Search Gallery de Google.
Es una guía muy completa donde indican las principales características que tiene en cuenta y cómo realizarlas de una forma correcta.
Otra recomendación es ir a Schema.org y comprobar si hay algo concretamente específico para nuestro negocio, como por ejemplo si es la web de una clínica veterinaria es mejor especificar eso que la versión genérica de MedicalOrganization.
Por otro lado lo recomendable es poner los datos estructurados que sean relevantes para cada página en si misma (aunque hay algunos que se pueden extender en toda la web).
Se pueden anidar e incluir distintos elementos individuales siempre y cuando tengan relevancia y se muestren en la propia página.
A menudo se suele utilizar prácticas como:
Todas estas prácticas, no solo pueden provocar que no aparezcan los Datos Estructurados en las SERPs, sino que pueden conllevar a penalizaciones de acciones manuales ya que son unas prácticas consideradas como Blackhat.
Otras prácticas, que aunque no estén consideradas como black hat, no se deben realizar, es establecer en los datos estructurados elementos que no sean tan relevantes dentro de la propia página u ofrecer datos desactualizados.
Aunque existe el Codelab que es como una "web" de aprendizaje que presta Google para que se experimente con datos estructurados, el que no esté acostumbrado al código se puede asustar más que si se pusiera directamente paso a paso.
Lo que recomiendo para el que no haya hecho datos estructurados nunca, es que coja un ejemplo de alguno de la Search Gallery, y vaya experimentando con el validador de Marcado de Schema para comprobar que le va funcionando. Es importante para esto saber como funciona realmente un JSON, y yo recomiendo aprender un poco de la sintaxis acerca de como funcionan las llaves, las comas y las comillas e ir probando los errores posibles con un validador de JSON.
Es normal sentirse perdido con este tipo de implementaciones y es algo demasiado extenso como para poder exponer o asimilar todos los conceptos en un simple post. Es por ello que en el Master de SEO explicamos todas estas prácticas paso a paso y hacemos tutorías continuas para que cualquiera pueda hacer este tipo de implementaciones, y cualquier implementación relacionada con SEO con la mayor seguridad y profesionalidad.
También existen herramientas, plugins y extensiones para que alguien sin conocimientos pueda implementarlos, pero suelen ser datos estructurados muy genéricos y no siempre se adaptan bien a todos los proyectos.
Para comprobar los datos estructurados de una web, realmente lo conveniente es emplear ambas herramientas validadoras de marcado. La que provee Schema y la que provee Google.
Lo maravilloso de los datos estructurados, para grandes blogs o para e-commerce, es que con el uso de la programación se pueden automatizar y ser muy efectivos.
De forma que se mantiene toda la estructura de los datos estructurados que se desean, y se adaptan por fields o condicionales.
En mi propia web, se puede comprobar que todos los artículos tienen datos estructurados. Utilizando varibles y unos fields personalizados con una estructura ya diseñada, realmente tengo este simple código (lógicamente las variables están declaradas en otro lado y los fields se cogen de la ddbb):<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "NewsArticle",
"mainEntityOfPage": {
"@type": "WebPage",
"@id": "<?php echo $url_sin_string;?>"
},
"headline": "<?php the_title(); ?>",
"image": [
"<?php the_field('open_graph'); ?>"
],
"datePublished": "<?php echo get_the_date('c'); ?>",
"dateModified": "<?php echo get_the_modified_date('c'); ?>",
"author": {
"@type": "Person",
"name": "<?php if ( get_field( 'author_json' ) ){the_field( 'author_json' );} else{echo "Carlos Sánchez";}?>",
"url": "<?php if ( get_field( 'url_author_json' ) ){the_field( 'url_author_json' );} else{echo "https://sanchezdonate.com/sobre-mi/";}?>"
},
"publisher": {
"@type": "Person",
"name": "Carlos Sanchez"
},
"description": "<?php the_field("metadescription"); ?>"
}
</script>
Mucha gente desconoce que en el JSON de producto, es obligatorio poner la propiedad Review, aggregateRating u offers. Pero una vez se ha implementado una, el resto no son obligatorias y aparecen como propiedades recomendadas (y no obligatorias) en la prueba de resultados enriquecidos.
Este dato que lo desconocen muchos profesionales, viene claramente en la documentación de Google.
Aunque haya una feroz lucha por conseguir aparecer en los Datos Estructurados y ocupar el mayor espacio posible en las SERPs puede que no siempre nos resulte positivo aparecer en las mismas. Google al exponer esa información tal cual y a veces sin citar la fuente, puede provocar que lejos de lo esperado, acabe viniendo menos gente a nuestra web.
Esto ha pasado con webs que ofrecían la hora, cálculos, loterías e incluso letras de canciones, donde tenemos el ejemplo de GENIUS que decidió emplear distintos tipos de comillas para comprobar si Google copiaba tal cual su contenido (y así era). Este tipo de prácticas puede provocar que hacer este tipo de páginas webs no sean rentables.
Si bien los Resultados Enriquecidos pueden provocar una mejora en el tráfico de la web, también puede conseguir lo contrario y hacer que no necesiten salir de Google para ver la información que el usuario necesita de la web en donde está dicho contenido.
PD: GENIUS fue a juicio contra Google, pero perdió porque GENIUS no tiene la propiedad intelectual de las canciones que transcribe y traduce.
Te falta mi máster. Accede a una formación avanzada que te permitirá aplicar e implementar SEO en cualquier tipo de WEB
¡Accede al Máster de SEO Técnico!