Significado e escopo
O tipo WebSite do Schema.org pode expressar o nome de um site, a URL e informações relacionadas em dados estruturados. Ele é um vocabulário, não uma promessa de que um mecanismo de busca vai exibir determinado recurso. O Google decide como, quando e se usa dados estruturados na apresentação da busca, e pode mudar o suporte a recursos com o tempo.
Fluxo prático
Modele apenas fatos estáveis e visíveis ou verificáveis de outra forma. Use a URL canônica da página inicial, o nome que os usuários veem e a relação com uma Organization somente quando ela descrever a mesma entidade com exatidão. JSON-LD é um formato de transporte comum, mas um grafo sintaticamente válido ainda pode induzir ao erro se combinar fatos de sites diferentes ou configurações desatualizadas.
O que inspecionar
Inspecione o código-fonte da página renderizada e faça o parse do grafo depois da publicação. Confirme que os identificadores resolvem como esperado, que os valores batem com a identidade visível do site e que não há nó duplicado ou conflitante no grafo de nível de site. Valide o vocabulário e a sintaxe e, para verificar o suporte atual a recursos, consulte a documentação relevante do Google, em vez de confiar em tutoriais antigos.
Limites e erros comuns
Não adicione SearchAction para tentar obter um recurso de exibição aposentado ou sem suporte, e não invente nomes alternativos, relações com publicadores nem um endpoint de busca. Dados estruturados devem esclarecer fatos existentes; eles não corrigem conteúdo fraco, páginas inacessíveis ou uma configuração confusa de canonical.
Modele a entidade WebSite com cuidado
Comece pela página inicial que os usuários e os rastreadores realmente acessam depois dos redirecionamentos. Registre a URL canônica final dela, o nome visível do site, qualquer nome alternativo visível e a relação com a Organization somente se os dois descreverem a mesma entidade pública. Um grafo WebSite não deve repetir um host diferente, um nome de staging ou uma antiga identidade jurídica só porque esses valores continuam em uma configuração do CMS. Identificadores estáveis são mais úteis do que um grafo grande com nós contraditórios.
{ "@context": "https://schema.org", "@type": "WebSite", "name": "Example", "url": "https://example.test/" }Inspecione o HTML renderizado, não a prévia de um editor. Faça o parse de cada script JSON-LD e liste @id, @type, name, url, alternateName e as conexões com nós de Organization ou WebPage; depois compare esses campos com os fatos visíveis da página. Ferramentas de validação identificam problemas de sintaxe ou de vocabulário, mas não sabem se um nome antigo, uma URL desatualizada ou uma promessa sem suporte reflete o negócio.
Teste o grafo na página inicial, nas versões de idioma e nos principais templates. A marcação de nível de site costuma ser injetada globalmente, então uma mudança pode duplicar um nó ou dar a cada versão de idioma uma URL conflitante. Se sites regionais ou de idiomas forem entidades distintas, documente a relação de forma deliberada, em vez de copiar sem alterações uma declaração WebSite única. Confirme que as URLs canônicas no grafo abrem diretamente e de forma consistente.
Não adicione uma propriedade só porque um tutorial antigo diz que ela ativa um recurso de busca. O Schema.org define o vocabulário, enquanto o Google documenta separadamente quais recursos de dados estruturados suporta no momento e pode mudar isso. Uma entidade WebSite válida pode melhorar a consistência para máquinas, mas não garante a exibição do nome do site, de sitelinks ou de qualquer outro recurso de aprimoramento da busca.