Por que o Schema precisa ser um gráfico • Yoast

Mais e mais pessoas e mais e mais desenvolvedores estão falando sobre dados estruturados e Schema.org. Nós conversamos e conversamos sobre o Schema há algum tempo no Yoast e construímos muitas coisas com e em cima dele. Recentemente, a proposta protocolo de bloqueio standard começou a falar sobre integração com Schema, e a equipe principal do WordPress também está interessada; Vejo esta discussão no Github.

Os metadados do Schema.org são uma versão legível por máquina e interpretável do que está em uma página. Nós da Yoast estamos muito orgulhosos da marcação de esquema que o Yoast SEO gera. A principal razão pela qual estamos tão orgulhosos disso é que nos esforçamos para garantir que, quando uma máquina o lê, ele o interpreta corretamente. Para isso, determinamos que o Schema deve sempre ser um gráfico interconectado.

Como é um bom gráfico

Digamos que temos uma página com um artigo e esse artigo contém um HowTo. Vamos supor que o HowTo é a “razão de ser” do artigo. Nosso gráfico Yoast SEO, quando analisado, ficaria assim:

o Article e WebPage teria um ou vários autores, datas de publicação, imagens, o site seria de propriedade de uma organização, etc. tonelada de metadados em nosso Schema, que é super útil para os motores de busca. Alguns dos dados estão no nível da página (como o idioma), alguns dos dados geralmente estão no nível do site (como o editor), e tudo isso funciona bem porque nós os relacionamos.

Em muitas implementações de Schema, essas partes são não unidos como um gráfico. Eles são jogados fora como blocos separados. Então, em vez da bela hierarquia acima, você obteria:

  • HowTo
  • Article
  • WebPage
  • WebSite

E no caso acima, isso poderia realmente ficar bem. Eu digo pode por uma razão. E se o HowTo é, na verdade, apenas uma parte tangencial do Article? Há casos em que se torna ainda mais crítico. Deixe-me lhe dar um exemplo.

Quando o Schema se torna destrutivo

Este é, infelizmente, um caso que encontrei na vida real. Um site tinha uma página de produto para um único produto. Abaixo desse produto, ele listava cinco produtos relacionados, coisas comumente compradas em conjunto, etc. O componente usado para mostrar o Esquema de saída desses produtos relacionados para esses cinco produtos. Ele não se vinculou ao resto do esquema da página. Então você tem isso:

  • Product (produto principal)
  • Product (produto relacionado 1)
  • Product (produto relacionado 2)
  • Product (produto relacionado 3)
  • Product (produto relacionado 4)
  • Product (produto relacionado 5)

Product schema é responsável por obter um site com os rich snippets que mostram classificações por estrelas, preço e disponibilidade de produtos nos resultados de pesquisa. Nesse caso, os mecanismos de busca não sabiam qual produto escolher; na verdade, a ferramenta de teste de pesquisa aprimorada do Google nem mesmo fornecerá um resultado. Quando você olha para este esquema fora do contexto de seu design, não há como saber qual produto é o produto principal na página porque o esquema não foi amarrado em um único gráfico. O resultado é uma perda de rich snippets para essas páginas. Uma mudança que foi diretamente atribuível a uma perda de vendas.

Consertá-lo significava conectar os cinco relacionado produtos para o produto principal com isRelatedTo propriedades, removendo Product parte de sua saída e, em seguida, declarando o a Principal produto como o mainEntityOfPage. O ponto aqui é que esses blocos de produtos precisavam se comportar de maneira diferente com base em contexto e seus relacionamentos com outros blocos na (e informações sobre) a página. Esse é o tipo de entendimento que você precisa para poder construir uma saída de esquema funcional.

As partes nerds: como amarramos tudo isso

Em nosso gráfico, ligamos todos os elementos especificando seu relacionamento. Para isso, referenciamos as “peças” do grafo, como as chamamos, por @id. UMA WebPage tem um atributo isPartOfreferenciando o WebSite peça. Um Article tem um isPartOf referenciando o WebPage. Na verdade, um Article por padrão também tem um atributo mainEntityOfPage que faz referência ao WebPagedeclarando-se como a entidade principal.

article webpage website schema

Se você adicionar um HowTo a essa mistura, ele se declararia o mainEntityOfPage do Article. Se o HowTo faz parte de uma página que não produz Article esquema, ele faria o mesmo, mas se anexaria automaticamente como o mainEntityOfPage do WebPage. Dessa forma, um mecanismo de pesquisa pode analisar o gráfico e ver exatamente o que está acontecendo. Isso significa que cada bloco precisa estar ciente de seu contexto quando seu esquema é renderizado.

howto article webpage website schema

Então: Blocos e Schema não são a mesma coisa

Enquanto os blocos no novo editor do WordPress são excelente para uso com Schema, eles requerem um nível extra de análise e uma camada de logíca de negócios para ser vinculado ao resto da página. Infelizmente, não é tão simples como apenas enviar o esquema para cada bloco e deixá-lo assim. A ideia que está sendo discutida atualmente no GitHub do núcleo do WordPress, de vincular Schema a Patterns, é, na minha opinião, um pouco demais… Simplista. Não estou dizendo que não pode ser feito, mas precisa de mais trabalho. O mesmo vale para as discussões em torno do Block Protocol.

Se você deseja implementar o Schema, você precisa estar disposto e ser capaz de determinar todo o contexto de uma página. Essa lógica de negócios é complexa, interconectada e evolui continuamente à medida que o Google e outros consumidores alteram e evoluem seus padrões. Essa lógica não pode viver em cada bloco individual, em peças individuais; ele precisa de um “cérebro” que entenda todas as partes móveis e possa descrever um gráfico coeso de todas essas partes móveis. Como este.

Temos muito orgulho do que Yoast SEO faz nessa área e oferecemos uma API de esquema que permite que outros desenvolvedores se conectem a isso e adicionem suas próprias implementações. Também escrevemos um cheio Especificação do esquema de como nossa saída funciona e por quê. Sem esse “cérebro”, uma abordagem baseada em blocos terá dificuldades para com segurança descrever uma página.

Source link

Amazon Coaching Grátis

Venda 25K Dólares com apenas um Produto no Amazon.

Artigos Relacionados

LEAVE A REPLY

Please enter your comment!
Please enter your name here

9 − 4 =

- Ana Pereira -spot_img

Últimos Artigos

AllEscort