Campos de tipos Schema.org: obrigatorios e recomendados

As propriedades incluídas determinam se mecanismos de busca e outros consumidores conseguem compreender a página. Esta consulta aceita nomes conhecidos, como Article, Product, Recipe ou FAQPage, e retorna imediatamente uma lista prática de campos. Ela separa propriedades geralmente obrigatórias de melhorias recomendadas, usa nomes canônicos e rejeita claramente tipos desconhecidos para que fluxos automatizados nunca prossigam com uma suposição silenciosa.

Comece pelo tipo exato que representa sua página

Os dados estruturados funcionam melhor quando o tipo escolhido descreve o assunto principal da página, e não apenas um pequeno elemento. Informe um tipo Schema.org como Product para um item à venda, Recipe para instruções culinárias, Article para conteúdo editorial ou LocalBusiness para uma empresa com presença física. A consulta não diferencia maiúsculas de minúsculas e também aceita a URL completa de um tipo em schema.org, o que é conveniente quando o valor vem de um documento JSON-LD existente. A resposta devolve o nome e a URL canônicos, além de duas listas ordenadas de propriedades. Se o nome não estiver no catálogo compatível, a capacidade retorna um erro de entrada em vez de inventar uma correspondência aproximada. Esse comportamento é valioso em fluxos de publicação porque um erro como Productt interrompe a compilação, em vez de gerar uma marcação aparentemente plausível, mas sem significado definido. Escolha o tipo compatível mais específico e correto. A consulta se concentra em tipos populares usados em SEO, não em todas as classes do vocabulário completo do Schema.org.

Interprete os campos como uma lista prática de implementação

Schema.org é um vocabulário e não exige propriedades universalmente como um esquema de banco de dados. Recursos de busca, validadores e consumidores posteriores estabelecem suas próprias regras de qualificação, que podem mudar conforme a plataforma e a apresentação. Portanto, a lista obrigatória representa as propriedades normalmente tratadas como o conjunto mínimo útil para SEO, enquanto os campos recomendados tendem a melhorar a integridade, a qualificação ou a qualidade do resultado exibido. Primeiro, associe cada propriedade obrigatória a informações reais e visíveis na página. Depois, acrescente as recomendadas quando houver dados confiáveis. Nunca invente avaliação, preço, autor, imagem, disponibilidade ou data somente para preencher a lista. Um objeto mais curto e fiel ao conteúdo é mais seguro do que uma marcação rica que contradiz o que visitantes veem. Algumas propriedades contêm objetos aninhados, como offers em Product, author em Article, location em Event e mainEntity em FAQPage. A consulta indica essas propriedades superiores, mas não gera valores aninhados nem valida um grafo JSON-LD completo.

Use resultados determinísticos em auditorias e publicações

Como a consulta usa um catálogo fixo em memória, sem rede, modelos, aleatoriedade ou dependência do relógio, o mesmo tipo compatível sempre produz o mesmo resultado ordenado. Isso a torna adequada para auditorias reproduzíveis, criadores de formulários, modelos de schema, scripts de migração e verificações de integração contínua. Um CMS pode solicitar a lista quando uma pessoa editora seleciona um tipo de conteúdo, destacar entradas obrigatórias ausentes e apresentar melhorias recomendadas separadamente. Uma ferramenta de auditoria pode comparar chaves JSON-LD existentes com a resposta e relatar lacunas sem considerar toda recomendação um erro. Um gerador pode usar a URL canônica e preservar a ordem dos campos em uma interface previsível. Trate o resultado como ponto de partida prático e consulte a documentação atual de qualquer mecanismo de busca cujo resultado avançado seja essencial ao negócio, pois políticas específicas ficam fora deste catálogo offline. A solicitação da API custa US$ 0,002, e o navegador utiliza a mesma lógica pura. Um tipo incompatível retorna deliberadamente um erro com o nome enviado e as opções aceitas, facilitando uma correção rápida.