O rótulo da página deve corresponder à página que o visitante pode ver
O markup do Schema.org fornece ao software uma descrição estruturada de uma página e seu assunto. Ele deve explicar o que a página já diz, não adicionar afirmações que um visitante não possa confirmar.
Comece anotando o propósito da página e sua entidade principal. Depois escolha o tipo mais simples que se encaixa. A página "Sobre" de um projeto e uma página de produto não são intercambiáveis, mesmo que ambas estejam no mesmo site. Isso dá a você uma primeira verificação útil para schema.org para visibilidade em IA. Uma pessoa consegue apontar para o conteúdo visível por trás de cada fato marcado?
| Página ou assunto | Tipo possível | Uma verificação prática |
|---|---|---|
| Projeto ou empresa | Organization | O nome público e os detalhes estão corretos? |
| Site inteiro | WebSite | O registro descreve o próprio site? |
| Uma URL | WebPage | Ele identifica a página que está sendo descrita? |
| Recurso editorial | Article | O autor e os detalhes de publicação estão visíveis? |
| Produto ou software | Product ou SoftwareApplication | A página realmente descreve essa oferta? |
Preferimos ver um conjunto pequeno que sua equipe possa manter do que um registro cheio de propriedades sem suporte. Para uma visão mais ampla do trabalho técnico, veja orientação técnica sobre AEO.
Comece pelos detalhes do projeto que as pessoas já perguntam
Imagine um fundador cujo primeiro lançamento foi discreto. A única pessoa que responde entra em férias, e novos visitantes ainda precisam de detalhes claros sobre o projeto.
Começaríamos pelas páginas que esses visitantes precisam, não por um grande template de markup. Verificaríamos se o nome do projeto, a descrição do produto e os detalhes de contato aparecem claramente no site. Depois mapearíamos apenas esses fatos visíveis para propriedades adequadas do schema.org. A página continua sendo a fonte da verdade; o markup a segue.
Imagine que o projeto tem uma página de produto e um artigo explicativo curto. A página de produto pode suportar Product se realmente descrever o produto. O explicativo pode se adequar a Article quando seu autor e detalhes editoriais são mostrados. Se a página não suportar um campo, deixe-o de fora e peça ao responsável pelo projeto para esclarecer a fonte primeiro.
Isso também facilita a transferência do trabalho. Um colega de equipe pode seguir a conexão entre cada campo e a página em vez de adivinhar por que foi adicionado. Para mais informações sobre como criar páginas de origem úteis, visite conteúdo citável para assistentes de IA.
Quais tipos de schema se encaixam em diferentes partes de um site de projeto?
O tipo de schema certo depende do que uma página específica representa. Um site de projeto pode usar vários tipos em URLs diferentes, desde que cada um reflita o conteúdo visível.
Comece pelo site e suas páginas
Organization pode descrever o projeto ou a empresa por trás do site. WebSite descreve o site como um todo, enquanto WebPage descreve uma URL individual. Esses tipos podem ser conectados onde a relação é real e clara. Mantenha nomes e detalhes públicos consistentes entre a página e seu markup.
Adicione tipos específicos de conteúdo apenas onde eles se encaixam
Article pode ser adequado para um recurso editorial com autor ou detalhes de publicação visíveis. Product pode se encaixar em uma página que realmente apresenta um produto. SoftwareApplication pode se encaixar em uma página que descreve software, se os detalhes representados no markup forem suportados ali.
Por exemplo, uma página que explica um recurso de software pode ser revisada quanto à adequação ao SoftwareApplication. Se ela discute apenas o projeto em geral, adicionar esse tipo pode descrevê-la incorretamente. Uma revisão página por página evita que um template seja copiado para páginas diferentes.
Um objeto JSON-LD pode ser pequeno e legível. Aqui, o nome e o endereço são ilustrativos, não fatos sobre seu projeto:
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "Exemplo de Projeto",
"url": "https://exemplo.org/"
}
Use os detalhes públicos reais do seu site e verifique se a página renderizada os suporta. Para páginas de perguntas, a otimização de FAQ pode ajudar você a planejar as respostas visíveis antes de considerar o markup.
Uma sequência calma de cinco etapas, da lista de páginas ao JSON-LD verificado
Uma lista de páginas e uma verificação curta de evidências tornam o trabalho com schema mais fácil de revisar. Usamos esta sequência para manter cada registro conectado à página que descreve.
- Escolha URLs prioritárias. Liste as páginas que importam primeiro. Anote o propósito de cada página, sua entidade principal e o endereço canônico.
- Escolha um tipo adequado. Decida se a página descreve a organização, o site, um artigo, um produto, um software ou outro assunto apropriado.
- Rastreie cada propriedade. Anote onde um visitante pode ver o fato ou qual fonte confiável do projeto o confirma. Remova campos sem suporte claro.
- Adicione o JSON-LD à página correspondente. Verifique se as URLs apontam para a página pretendida e se a sintaxe é válida. Compare o registro com o conteúdo renderizado.
- Revise após edições. Verifique o markup relacionado quando uma página, detalhe do produto, autor ou fato da organização mudar.
Pediríamos a um editor ou responsável pelo produto para confirmar a identidade e as alegações do produto antes de publicar. Essa revisão captura nomes incorretos e descrições desatualizadas enquanto ainda são fáceis de corrigir. Mantenha a lista de verificação com as anotações da página, para que um editor futuro possa repetir as mesmas verificações sem reconstruir o raciocínio do zero. Se você também está considerando como implementar llms.txt, mantenha essa tarefa separada: o arquivo e o markup da página fazem trabalhos diferentes.
A transição entre dados estruturados e plataformas de IA
Dados estruturados podem tornar os detalhes sobre uma página mais explícitos. Mas eles não podem direcionar como ChatGPT, Perplexity, Google ou outra plataforma seleciona ou apresenta informações. A documentação do Google descreve dados estruturados como uma forma de ajudar a entender o conteúdo e avaliar a elegibilidade para aparências de pesquisa suportadas. Se uma aparência é exibida continua sendo uma decisão do Google. Nenhum tipo de schema pode prometer uma citação ou uma resposta específica.
Esse limite dá à sua equipe um teste de qualidade útil. Verifique se a página responde a uma necessidade real do leitor, se suas afirmações são suportadas e se o markup reflete o texto visível. Se os dados são válidos, mas a página é vaga, melhore a página antes de adicionar mais propriedades. Se uma descrição do projeto mudar, atualize a página e depois revise o registro relacionado.
Mantenha anotações sobre o que você mudou e por quê. Dessa forma, a próxima pessoa pode dizer se um campo representa um detalhe real da página ou uma suposição antiga. Ao comparar o que ChatGPT e Perplexity mostram, registre o que cada plataforma realmente exibe. Não trate o markup como a causa de uma menção ou omissão. Nosso guia sobre visibilidade em IA search cobre o panorama mais amplo de publicação.
Mantenha um pequeno registro que sua equipe possa revisitar
Um registro de revisão compacto ajuda a equipe a manter separados os fatos da página, as verificações de markup e as observações de visibilidade. Também torna a próxima atualização de conteúdo menos propensa a deixar detalhes antigos para trás.
Para cada URL prioritária, anote seu tipo pretendido, endereço canônico, última revisão e status de validação. Adicione uma nota curta quando a página mudar de uma forma que possa afetar seus dados estruturados. Depois, mantenha as observações da plataforma em um lugar separado: registre a pergunta verificada, a plataforma, a data da verificação e o que ela mostrou. Essas notas descrevem o que sua equipe viu; elas não estabelecem por que uma plataforma escolheu uma fonte específica.
Use um conjunto pequeno de perguntas que visitantes reais possam fazer sobre o projeto. Repita-as ao revisar a página e compare a resposta com o que a página publicada diz. Se uma resposta perder um detalhe importante, inspecione o texto e a informação da fonte antes de alterar o schema. Isso mantém o trabalho fundamentado em conteúdo que as pessoas podem verificar.
Se você quiser uma revisão técnica mais ampla, llms.txt e configuração de IA crawler explica uma parte separada desse trabalho. Para iniciar sua própria revisão, reúna algumas URLs prioritárias, as perguntas que seu público faz e qualquer exportação de schema existente. Podemos ajudar a verificar a correspondência página-markup e retornar correções claras para sua equipe.
Como funciona
- Liste páginas prioritáriasRegistre o propósito de cada URL, sua entidade principal e o endereço canônico.
- Selecione tipos de páginaEscolha tipos que descrevam o propósito visível de cada página.
- Rastreie os fatosConecte cada propriedade a um conteúdo visível ou a uma fonte confiável do projeto.
- Adicione e verifique o JSON-LDColoque-o na página que descreve, teste sua sintaxe e compare seus fatos com a página renderizada.
- Revise após ediçõesReveja o markup quando o conteúdo da página relacionada ou os detalhes do projeto mudarem.
Perguntas frequentes
O markup de schema pode ajudar ChatGPT ou Perplexity a mencionar um projeto?
O schema pode descrever detalhes da página de forma estruturada, mas ChatGPT e Perplexity decidem o que mostram e citam. Verifique se a página responde a uma pergunta clara do leitor e se os fatos marcados correspondem ao texto visível. Ao revisar um resultado, salve a pergunta e a plataforma para que sua equipe possa repetir a observação.
Com quais tipos de schema um site de projeto deve começar?
Comece pelas páginas que você tem e pelo que cada uma realmente diz. Organization pode descrever o projeto, enquanto WebSite e WebPage descrevem o site e uma URL individual. Article, Product ou SoftwareApplication podem se encaixar em páginas específicas quando seus detalhes visíveis suportam esses tipos.
Preciso de llms.txt e markup schema.org?
Não necessariamente. Schema.org descreve o conteúdo e as entidades da página em dados estruturados; llms.txt é uma convenção de arquivo de texto proposta para apontar para recursos selecionados do site. Decida se cada um ajuda com uma necessidade separada e mantenha as informações atualizadas apenas se sua equipe puder mantê-las.
Como posso verificar um exemplo de JSON-LD em relação à minha página?
Verifique se a sintaxe é válida, se o tipo se encaixa na página e se cada propriedade tem suporte visível ou confiável. Compare nomes, URLs e descrições com a página renderizada antes de publicar. Um segundo revisor pode confirmar detalhes como autoria ou informações do produto quando esses fatos não são óbvios.
Toda página com perguntas deve usar o markup FAQPage?
Não. Use um tipo apenas quando ele descrever a página com precisão e seguir os requisitos documentados da plataforma relevante. Uma página ainda pode responder perguntas comuns claramente sem o markup FAQPage. A verificação principal é se os visitantes conseguem encontrar as respostas representadas nos dados.
Com que frequência nossa equipe deve revisar o markup de schema?
Revise-o quando a página ou os detalhes que ela descreve mudarem. Por exemplo, uma descrição de produto revisada ou um nome de organização alterado deve provocar uma verificação do registro relacionado. Manter a URL, o tipo pretendido e a última revisão em uma nota curta torna essa verificação mais fácil de repetir.
Conte sobre seu projeto
Responda quatro perguntas rápidas e um gerente enviará um plano, prazos e uma faixa de preço em até uma hora. Tudo fica confidencial.
Carregando formulário…