Campos de tipos Schema.org: obrigatorios e recomendados
Saiba que propriedades um tipo de página precisa antes de escrever a marcação: Product pede name e image e recomenda description, sku, brand, offers, aggregateRating e review. Maiúsculas não importam, e um erro como Productt é recusado em vez de adivinhado. Grátis no seu navegador.
- Grátis
- Funciona no seu navegador
- Sem cadastro
- Seus dados não saem do seu aparelho
Executar grátis
Exemplo resolvido
- Tipo
- Product
- URL do esquema
- https://schema.org/Product
- Obrigatório
- name, image
- Recomendado
- description, sku, brand, offers, aggregateRating, review
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. 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.
Interprete os campos como uma lista prática de implementação
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.
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. 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. 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. Um tipo incompatível retorna deliberadamente um erro com o nome enviado e as opções aceitas, facilitando uma correção rápida.
Casos de uso
Auditar propriedades ausentes
Compare as chaves da marcação existente com os campos mínimos e adicionais comuns ao tipo declarado.
Orientar a edição de conteúdo
Mostre primeiro as entradas obrigatórias e depois as melhorias recomendadas ao selecionar um tipo de página.
Perguntas frequentes
O que acontece quando um tipo não é reconhecido?
A solicitação retorna um erro de entrada e lista os nomes canônicos aceitos. Ela nunca tenta adivinhar um substituto.
O resultado inclui estruturas de propriedades aninhadas?
Não. Ele lista propriedades superiores comuns. Objetos aninhados como Offer, Person ou PostalAddress precisam ser criados e validados separadamente.
Quais propriedades um Product precisa ter?
O mínimo comum é name e image, e description, sku, brand, offers, aggregateRating e review são recomendadas. Ligue cada uma a uma informação que realmente aparece na página.
Que tipo escolher para a minha página?
O mais preciso que descreva o assunto principal da página, e não um detalhe dela: Product para algo à venda, Recipe para receita, Article para conteúdo editorial e LocalBusiness para um negócio físico.
Posso preencher uma propriedade sem ter o dado?
Não. Nunca invente nota, preço, autor, imagem, disponibilidade ou data só para completar a lista. Uma marcação mais curta e fiel à página é mais segura do que uma que contradiz o que o visitante vê.
Ferramentas relacionadas
Para desenvolvedores — acesso via API
Tudo nesta página está disponível via API. Esta seção é para equipes que querem integrar a ferramenta aos próprios sistemas; quem não precisa disso pode simplesmente usar a ferramenta acima.
Endpoint
Autenticação por token Bearer. Um único POST coloca a tarefa na fila; o resultado chega por webhook ou link assinado.
Chame do seu código
curl -X POST https://api.kit.forhosting.com/seo/schema-type-lookup \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"type":"Product"}'const res = await fetch("https://api.kit.forhosting.com/seo/schema-type-lookup", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"type": "Product"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/seo/schema-type-lookup",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"type": "Product"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/seo/schema-type-lookup", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"type":"Product"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"type":"Product"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/seo/schema-type-lookup", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Exemplo de requisição
{
"type": "Product"
}Exemplo de resposta
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "seo.schema_type_lookup",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}A API é assíncrona: cada chamada devolve um task_id na hora. Se preferir polling, consulte o status a até 1 requisição por segundo.
Preço
Preço publicado, sem tokens nem créditos escondidos. Tarefa que falha não é cobrada.
Erros
| HTTP | Código | O que significa |
|---|---|---|
401 | unauthorized | Token ausente ou inválido. Confira o header Authorization. |
402 | insufficient_balance | Saldo insuficiente para esta tarefa. Faça uma recarga e tente de novo. |
404 | unknown_type | Esse tipo de tarefa não existe. Confira o campo type no catálogo. |
429 | rate_limited | Muitas requisições em pouco tempo. Espere um instante e tente de novo. |
Notas técnicas
Escolher um tipo Schema.org é apenas o primeiro passo para criar dados estruturados úteis.
Comece pelo tipo exato que representa sua página
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 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. 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
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. Uma ferramenta de auditoria pode comparar chaves JSON-LD existentes com a resposta e relatar lacunas sem considerar toda recomendação um erro. A solicitação da API custa US$ 0,002, e o navegador utiliza a mesma lógica pura.
Casos de integração
Planejar um modelo JSON-LD
Obtenha uma lista estável antes de criar campos do CMS para um novo modelo de dados estruturados.
Perguntas técnicas
Esses campos são exigidos pelo próprio Schema.org?
Não. Schema.org define um vocabulário, mas normalmente não obriga propriedades. A lista obrigatória representa mínimos comuns em implementações de SEO.
Posso enviar uma URL completa do Schema.org?
Sim. Um valor como https://schema.org/Product é normalizado para o tipo canônico Product.
Quanto custa uma consulta pela API?
Cada solicitação da API custa US$ 0,002. O algoritmo é determinístico e não chama serviços externos.