Do schema básico ao grafo: o que muda
Dados estruturados avançados são marcações em que as entidades do site (empresa, pessoa, serviços, páginas e artigos) são descritas uma vez e ligadas entre si por identificadores, formando um grafo coerente em vez de blocos soltos que se repetem e se contradizem.
O schema básico costuma ser um bloco de Organization colado no rodapé por um plugin e um Article gerado automaticamente em cada post. Cada bloco fala sozinho. A empresa aparece com um nome no rodapé, com outro no Article, e o autor é só um texto sem ligação com ninguém. O schema avançado resolve isso com uma ideia simples: cada entidade ganha um identificador fixo, o @id, e as outras entidades apontam para ele.
As regras gerais continuam valendo. As >diretrizes gerais de dados estruturados do Google recomendam JSON-LD como formato, pedem que a marcação seja uma representação verdadeira do conteúdo da página, proíbem marcar conteúdo que o leitor não vê e avisam que o Google não garante que a marcação apareça nos resultados. Também dizem que problemas de dados estruturados podem gerar ação manual, que remove a elegibilidade para resultados enriquecidos.
Este guia é sobre o código. Por que as ligações entre entidades importam para Google e IAs está em SEO de entidades; como construir a página e a biografia do especialista que o código descreve está em página de autor e página Sobre; e o que as diretrizes de qualidade pedem como prova está em E-E-A-T na prática. Para a base técnica do site, como rastreamento, canonical e velocidade, veja SEO técnico avançado.
@id: o identificador que liga as entidades
O @id não é invenção do Schema.org nem do Google. Ele vem da especificação >JSON-LD 1.1 do W3C, que o define como a palavra-chave usada para identificar de forma única os objetos descritos no documento, com IRIs. A mesma especificação explica que um objeto que contém só o @id pode ser uma referência a um objeto descrito em outro lugar, e que, idealmente, acessar o identificador deveria levar a uma representação daquele objeto.
Essa última parte orienta uma boa convenção: usar como @id a URL da página que melhor descreve a entidade, seguida de um fragmento. A organização, descrita na página inicial, fica com https://www.exemplo.com.br/#organization. A pessoa, descrita na página Sobre, fica com https://www.exemplo.com.br/sobre/#person. Um serviço, com https://www.exemplo.com.br/servicos/auditoria-seo/#service. O fragmento depois do # evita confundir a entidade com a página em si.
Regras práticas para o @id
- Use URLs absolutas, com o domínio canônico (com ou sem www, mas sempre o mesmo).
- Defina o identificador uma vez e nunca mude, mesmo que o nome da empresa mude.
- Reaproveite exatamente o mesmo
@idem todas as páginas que citam a entidade. - Descreva a entidade por completo em uma página e, nas demais, apenas aponte para ela com
{"@id": "..."}. - Não crie dois identificadores para a mesma coisa (um plugin com
#organizatione outro com#org, por exemplo). - Não use o
@idde uma entidade para outra diferente, como a pessoa e a empresa.
Um ponto de honestidade: o Google não detalha o uso de @id nas páginas de Organization nem de LocalBusiness, e nenhuma empresa de IA documenta se lê esses vínculos. O que se sabe é que o grafo é JSON-LD válido, elimina contradições entre blocos e deixa explícitas relações que, sem ele, a máquina teria de adivinhar.
Exemplo de grafo: empresa, pessoa, site, serviço e artigo
O exemplo abaixo descreve uma consultoria fictícia de Ribeirão Preto com uma especialista fictícia. Em produção, os blocos ficam dentro de um único <script type="application/ld+json"> com uma lista em "@graph". Separei cada nó para comentar.
Organização, descrita na página inicial:
{"@type": "Organization", "@id": "https://www.exemplo.com.br/#organization", "name": "Exemplo Consultoria", "url": "https://www.exemplo.com.br/", "logo": "https://www.exemplo.com.br/logo.png", "description": "Consultoria de SEO para clínicas, com base em Ribeirão Preto (SP).", "address": {"@type": "PostalAddress", "addressLocality": "Ribeirão Preto", "addressRegion": "SP", "addressCountry": "BR"}, "areaServed": {"@type": "State", "name": "São Paulo"}, "founder": {"@id": "https://www.exemplo.com.br/sobre/#person"}, "sameAs": ["https://www.linkedin.com/company/exemplo-consultoria"]}
Pessoa, descrita na página Sobre:
{"@type": "Person", "@id": "https://www.exemplo.com.br/sobre/#person", "name": "Ana Souza", "jobTitle": "Consultora de SEO", "url": "https://www.exemplo.com.br/sobre/", "image": "https://www.exemplo.com.br/ana-souza.jpg", "worksFor": {"@id": "https://www.exemplo.com.br/#organization"}, "sameAs": ["https://www.linkedin.com/in/ana-souza-exemplo"]}
Site, na página inicial:
{"@type": "WebSite", "@id": "https://www.exemplo.com.br/#website", "url": "https://www.exemplo.com.br/", "name": "Exemplo Consultoria", "publisher": {"@id": "https://www.exemplo.com.br/#organization"}}
Serviço, na página do serviço:
{"@type": "Service", "@id": "https://www.exemplo.com.br/servicos/auditoria-seo/#service", "name": "Auditoria de SEO para clínicas", "provider": {"@id": "https://www.exemplo.com.br/#organization"}, "areaServed": {"@type": "State", "name": "São Paulo"}}
Artigo, em cada post:
{"@type": "Article", "@id": "https://www.exemplo.com.br/blog/guia/#article", "headline": "Título do artigo", "author": {"@id": "https://www.exemplo.com.br/sobre/#person"}, "publisher": {"@id": "https://www.exemplo.com.br/#organization"}, "datePublished": "AAAA-MM-DD", "dateModified": "AAAA-MM-DD", "isPartOf": {"@id": "https://www.exemplo.com.br/#website"}}
Repare no que o grafo diz sem ambiguidade: a Ana trabalha na Exemplo Consultoria e é sua fundadora; a empresa publica o site; o serviço é prestado pela empresa; o artigo foi escrito pela Ana e publicado pela empresa. Nos posts, não é preciso repetir a descrição completa da pessoa e da empresa: basta o objeto com o @id. Se você repetir, os dados precisam ser idênticos.
Dois cuidados. Primeiro, tudo o que está no código precisa estar visível na página: se a página Sobre não mostra a foto e o cargo da Ana, eles não deveriam estar no Person. Segundo, o sameAs só aponta para perfis oficiais e atualizados. Para vídeos, a mesma lógica de ligação vale para o VideoObject, tema de vídeo e YouTube para SEO e IA.
Qual tipo usar: Organization, LocalBusiness, ProfessionalService ou subtipo
A escolha do tipo é onde mais vejo confusão. O critério é a natureza do negócio e o que a página mostra, não o tipo que "parece mais forte".
| Tipo | Quando usar | Cuidado |
|---|---|---|
| Organization | Empresa sem atendimento presencial ao público, consultorias remotas, marcas com várias unidades (como entidade-mãe) | Endereço é opcional; descreva o que for verdadeiro |
| Subtipo de LocalBusiness (Dentist, AccountingService, LegalService etc.) | Negócio com local físico que recebe clientes e cujo setor tem subtipo próprio | O Google exige name e address para resultado enriquecido local |
| LocalBusiness genérico | Negócio com local físico sem subtipo adequado | Prefira sempre o subtipo mais específico que existir |
| ProfessionalService | Ainda aceito pelo vocabulário | O próprio Schema.org registra que o uso genérico foi descontinuado |
| Service | Cada serviço que a empresa presta, numa página própria | Não é a empresa: liga-se a ela por provider |
| Person | Fundador, especialista, autor | Liga-se à empresa por worksFor ou founder |
Sobre ProfessionalService, vale ler a página do >Schema.org para ProfessionalService: ela informa que o tipo genérico para negócios locais foi descontinuado por causa da confusão com Service, e que os antigos subtipos ganharam tipos próprios, como Dentist, AccountingService, Attorney e Electrician, além de LegalService como supertipo mais abrangente para serviços jurídicos. Por isso, em projetos novos, eu prefiro o subtipo específico ou Organization.
A >documentação de LocalBusiness do Google confirma a preferência pelo subtipo mais específico possível, aceita uma lista de tipos quando o negócio se encaixa em mais de um e avisa que additionalType não é suportado. Ela também restringe aggregateRating e review: só são recomendados para sites que reúnem avaliações sobre outros negócios locais. Marcar a própria nota com estrelas no próprio site, portanto, não é o caminho.
FAQPage, Article e o que mudou na Busca
Quem trabalha com schema precisa acompanhar o histórico de mudanças do Google, porque recursos aparecem e desaparecem. A página de >atualizações da documentação do Google Search registra, por exemplo, que em setembro de 2025 foi removida a documentação de vários tipos que deixaram de aparecer nos resultados, como informações de curso, salário estimado, vídeo educativo, anúncio especial e anúncio de veículos. E registra a mudança que mais afetou sites de serviço: em maio de 2026 o Google anunciou o fim do resultado enriquecido de FAQ, que deixou de aparecer na Busca a partir de 7 de maio de 2026, e em junho removeu a documentação do recurso.
Ainda vale marcar FAQPage?
FAQPage continua sendo vocabulário válido do Schema.org, e uma lista de perguntas e respostas visível na página segue útil para o leitor e para qualquer sistema que leia o texto. O que acabou foi o resultado enriquecido no Google. Minha posição é prática: se a página tem perguntas frequentes reais e visíveis, manter a marcação igual ao texto tem custo baixo e descreve o conteúdo com precisão. Se a FAQ só existia para ganhar o destaque na busca, não há motivo para criá-la agora. O que não é aceitável é marcar perguntas que não aparecem na página. Não existe documentação pública dizendo que assistentes de IA dão peso especial ao FAQPage; trate isso como incerto.
Article e datas
No Article, os pontos de atenção são autoria e datas. As boas práticas de autor estão detalhadas em página de autor e página Sobre. Sobre datas, dateModified deve mudar quando o conteúdo muda de verdade, não a cada vez que o site é publicado. Atualizar a data sem revisar o texto é o tipo de marcação que não representa a página.
Erros comuns que encontro
Na prática, quase todo site que reviso tem pelo menos um destes problemas. A maioria nasce de plugins e temas que geram marcação automática sem ninguém olhar o resultado.
- Duas organizações diferentes no mesmo site. O tema gera uma, o plugin de SEO gera outra, com nomes ou logos distintos. Escolha uma fonte de marcação e desligue a outra.
- Identificadores diferentes para a mesma entidade. A empresa é
#organizationna página inicial e#companynos posts. O grafo se parte em dois. - Autor como texto solto. O Article tem
"author": "Equipe"em vez de apontar para um Person real. - Marcação de coisas invisíveis. Endereço, telefone, perguntas ou avaliações que estão no código e não na página.
- Estrelas da própria empresa.
aggregateRatingcom a nota do próprio negócio, contra a orientação do Google. - LocalBusiness sem local. Consultoria remota marcada com endereço de coworking onde ninguém atende.
- sameAs para perfis errados. Perfis abandonados, de outra pessoa ou de diretórios irrelevantes.
- Mesmo bloco em todas as páginas. O Service da página inicial repetido em todos os posts, dizendo que cada post é um serviço.
- dateModified automático. Data atualizada a cada publicação do site, sem mudança no conteúdo.
- Unidades misturadas. Telefone e horário de uma unidade aparecendo na página da outra.
O último erro é tão comum em empresas com mais de um endereço que há um guia próprio sobre ele: duas unidades com informação misturada. E quando o problema é maior do que o schema, uma auditoria de SEO completa costuma ser o primeiro passo.
Como eu aplico isso
Quando eu reviso um site, começo pela marcação que já existe, não pela que eu gostaria de colocar. Abro o código-fonte de quatro páginas (inicial, Sobre, um serviço e um artigo) e listo todas as entidades declaradas, quem as gera e se os dados batem entre si. Quase sempre aparecem duplicações.
Depois, sigo esta sequência:
- Mapa de entidades. Desenho no papel quais entidades existem (organização, pessoas, unidades, serviços, site) e como se relacionam.
- Definição dos identificadores. Fixo um
@idpara cada entidade, com a URL da página que a descreve. - Uma fonte de marcação. Escolho onde o schema será gerado e desligo o resto.
- Descrição completa em um lugar. Organização na página inicial, pessoa na Sobre, cada serviço na sua página.
- Referências no resto. Nas demais páginas, só os objetos com
@id. - Conferência com o texto visível. Tudo o que está no código precisa estar na página.
- Validação. Uso o Rich Results Test do Google para checar elegibilidade e o Schema Markup Validator para checar o vocabulário.
- Monitoramento. Acompanho os relatórios de dados estruturados no Search Console após a publicação.
No meu próprio site eu uso exatamente isso: Person e Organization ligados por @id, perguntas frequentes visíveis iguais à marcação e um arquivo llms.txt como complemento, sem tratá-lo como substituto do schema. Um case que mostra por que as relações importam tanto quanto as informações é a informação estava no site, mas as relações não estavam claras. Para uma visão de como schema, autoridade e conteúdo trabalham juntos, veja schema, autoridade e conteúdo para respostas inteligentes.
Empresas com unidades no estado de São Paulo
Empresas paulistas com mais de um endereço são o caso em que o grafo mais ajuda. Pense numa rede de clínicas odontológicas com unidades em Campinas, Jundiaí e na capital, ou num escritório de contabilidade com sede em Santos e filial em São Vicente. Cada unidade tem endereço, telefone e horário próprios, mas todas pertencem à mesma marca.
A estrutura que uso é esta: a marca é uma Organization com @id na página inicial; cada unidade é um subtipo de LocalBusiness (Dentist, AccountingService) com @id na sua própria página de unidade, por exemplo https://www.exemplo.com.br/unidades/campinas/#local, e se liga à marca pela propriedade parentOrganization, que o Schema.org define como a organização maior da qual esta faz parte. Cada página de unidade traz só os dados daquela unidade, em texto visível e no código. Para departamentos com dados distintos dentro de um mesmo endereço, a documentação do Google para LocalBusiness prevê o uso de department.
Negócios que atendem várias cidades sem ter endereço em todas, como uma empresa de manutenção de Ribeirão Preto que atende Sertãozinho e Jardinópolis, não devem inventar unidades. O correto é declarar a área atendida em texto e no areaServed da organização ou do serviço. Como fazer isso sem criar páginas-porta está em SEO local para várias unidades e cidades.
Na capital, onde muitas empresas têm nomes parecidos, a marcação limpa ajuda a separar a sua unidade da Vila Mariana da empresa homônima do Tatuapé. No interior e no litoral, ajuda a deixar clara a cidade-base. A forma como trabalho esses projetos no estado está em especialista em SEO, AEO e GEO em São Paulo, e os outros guias técnicos estão na biblioteca de SEO, AEO e GEO.