Por qué Schema necesita ser un gráfico • Yoast


Cada vez más personas y más y más desarrolladores hablan de datos estructurados y de Schema.org. Hablamos y hemos hablado sobre Schema durante bastante tiempo en Yoast y hemos construido muchas cosas con y encima de él. Recientemente, la propuesta protocolo de bloque standard comenzó a hablar sobre la integración con Schema, y ​​el equipo central de WordPress también se está interesando; ver esta discusión en Github.

Los metadatos de Schema.org son una versión legible por máquina e interpretable de lo que hay en una página. En Yoast estamos muy orgullosos del marcado de esquema que genera Yoast SEO. La razón principal por la que estamos tan orgullosos es que hacemos todo lo posible para garantizar que cuando una máquina lo lea, lo interprete correctamente. Para hacerlo, hemos determinado que Schema debe siempre ser un gráfico interconectado.

Cómo se ve un buen gráfico

Digamos que tenemos una página con un artículo, y ese artículo contiene un HowTo. Supondremos que el HowTo es la “razón de ser” del artículo. Nuestro gráfico Yoast SEO, cuando se analiza, se vería así:

los Article y WebPage tendría uno o varios autores, fechas de publicación, imágenes, el sitio web sería propiedad de una organización, etc. Hay un tonelada de metadatos en nuestro esquema, que es muy útil para los motores de búsqueda. Algunos de los datos están a nivel de página (como el idioma), algunos de los datos suelen estar a nivel de sitio (como el editor), y todo esto funciona bien porque lo unimos todo.

En muchas implementaciones de Schema, estas partes son no unidos como un gráfico. Se tiran como bloques separados. Entonces, en lugar de la buena jerarquía anterior, obtendrías:

  • HowTo
  • Article
  • WebPage
  • WebSite

Y en el caso anterior, que puede que en realidad estar bien. Digo podría por una razón. ¿Qué pasa si el HowTo en realidad es sólo una parte tangencial de la Article? Hay casos en los que se vuelve aún más crítico. Dejame darte un ejemplo.

Cuando Schema se vuelve destructivo

Este es, desafortunadamente, un caso que encontré en la vida real. Un sitio web tenía una página de producto para un solo producto. Debajo de ese producto, enumeró cinco productos relacionados, cosas comúnmente compradas juntas, etc. El componente utilizado para mostrar el esquema de salida de esos productos relacionados para esos cinco productos. No se vinculaba con el resto del esquema de la página. Así que tienes esto:

  • Product (Producto principal)
  • Product (producto relacionado 1)
  • Product (producto relacionado 2)
  • Product (producto relacionado 3)
  • Product (producto relacionado 4)
  • Product (producto relacionado 5)

Product schema es responsable de obtener un sitio con fragmentos enriquecidos agradables que muestran calificaciones de estrellas, precio y disponibilidad de productos en los resultados de búsqueda. En este caso, los motores de búsqueda no sabían qué producto elegir; de hecho, la herramienta de prueba de resultados enriquecidos de Google ni siquiera le dará un resultado. Cuando observa este esquema fuera del contexto de su diseño, no hay forma de saber qué producto es el producto principal en la página. porque el esquema no estaba unido en un solo gráfico. El resultado es una pérdida de fragmentos enriquecidos para estas páginas. Un cambio que era directamente atribuible a una pérdida de ventas.

Arreglarlo significaba conectar los cinco relacionado productos al producto principal con isRelatedTo propiedades, eliminando Product parte de su producción, y luego declarando el principal producto como el mainEntityOfPage. El punto aquí es que esos bloques de productos debían comportarse de manera diferente según contexto y sus relaciones con otros bloques en (e información sobre) la página. Este es el tipo de comprensión que necesita para poder crear una salida de esquema que funcione.

Los bits geek: cómo lo unimos todo

En nuestro gráfico, unimos todos los elementos especificando su relación. Para hacerlo, hacemos referencia a las “piezas” del gráfico como las llamamos, por @id. A WebPage tiene un atributo isPartOfhaciendo referencia a la WebSite pieza. Un Article tiene un isPartOf haciendo referencia a la WebPage. De hecho, un Article por defecto también tiene un atributo mainEntityOfPage que hace referencia a la WebPagedeclarándose como entidad principal.

Si agregas un HowTo a esa mezcla, se declararía el mainEntityOfPage del Article. Si el HowTo es parte de una página que no genera Article esquema, haría lo mismo pero se adjuntaría automáticamente como el mainEntityOfPage del WebPage. De esta manera, un motor de búsqueda puede analizar el gráfico y ver exactamente Que esta pasando. Eso significa que cada bloque debe conocer su contexto cuando se representa su esquema.

Entonces: los bloques y el esquema no son lo mismo

Mientras que los bloques en el nuevo editor de WordPress son estupendo para usar con Schema, requieren un nivel adicional de análisis y una capa de lógica de negocios para ser atado al resto de la página. Desafortunadamente, no es tan simple como generar un esquema para cada bloque y dejarlo así. La idea que se está discutiendo actualmente en el núcleo de WordPress GitHub, vincular Schema a Patterns, es, en mi opinión, demasiado… Simplista. No digo que no se pueda hacer, pero necesita más trabajo. Lo mismo es cierto para las discusiones sobre el Protocolo de bloques.

Si desea implementar Schema, debe estar dispuesto y ser capaz de determinar todo el contexto de una página. Esa lógica empresarial es compleja, está interconectada y evoluciona continuamente a medida que Google y otros consumidores modifican y evolucionan sus estándares. Esta lógica no puede vivir en cada bloque individual, en piezas individuales; necesita un «cerebro» que comprenda todas las partes móviles y pueda describir un gráfico cohesivo de todas esas partes móviles. Como éste.

Estamos muy orgullosos de lo que hace Yoast SEO en esa área, y ofrecemos una API de esquema eso permite que otros desarrolladores se relacionen con eso y agreguen sus propias implementaciones. También hemos escrito un completo especificación del esquema de cómo funciona nuestra salida y por qué. Sin este «cerebro», un enfoque basado en bloques tendrá dificultades para sin peligro describir una página.



Source link

0 comentarios

Dejar un comentario

¿Quieres unirte a la conversación?
Siéntete libre de contribuir!

Deja una respuesta

Tu dirección de correo electrónico no será publicada.