Champs Schema.org obligatoires et recommandes
Sachez quelles propriétés un type de page demande avant d'écrire le balisage : Product exige name et image, et recommande description, sku, brand, offers, aggregateRating et review. La casse importe peu, et une faute comme Productt est refusée au lieu d'être devinée. Gratuit dans votre navigateur.
- Gratuit
- Fonctionne dans votre navigateur
- Sans inscription
- Vos données restent sur votre appareil
Lancer gratuitement
Exemple résolu
- Type
- Product
- URL du schéma
- https://schema.org/Product
- Obligatoire
- name, image
- Recommandé
- description, sku, brand, offers, aggregateRating, review
Les propriétés incluses déterminent si les moteurs de recherche et les autres consommateurs comprennent la page. Cette consultation accepte un nom courant tel que Article, Product, Recipe ou FAQPage, puis renvoie immédiatement une liste pratique de champs. Elle distingue les propriétés généralement obligatoires des améliorations recommandées, emploie les noms canoniques et rejette clairement tout type inconnu afin qu'un processus automatisé ne poursuive jamais son exécution sur une supposition silencieuse.
Commencez par le type exact représenté par votre page
Les données structurées fonctionnent mieux lorsque le type choisi décrit le sujet principal de la page, et non un simple élément secondaire. La réponse fournit le nom et l'URL canoniques avec deux listes ordonnées de propriétés. Si le nom ne figure pas dans le catalogue pris en charge, la capacité renvoie une erreur de saisie au lieu d'inventer une correspondance approchante.
Dans une chaîne de publication, une faute comme Productt arrête donc la compilation au lieu de produire un balisage apparemment plausible, mais dépourvu de sens défini. Choisissez le type compatible le plus précis.
Interprétez les champs comme une liste de mise en œuvre
Les fonctionnalités de recherche, validateurs et autres consommateurs appliquent leurs propres critères d'admissibilité, susceptibles de varier selon la plateforme et la présentation. La liste obligatoire désigne donc les propriétés couramment considérées comme le minimum utile en SEO, tandis que les champs recommandés améliorent généralement l'exhaustivité, l'admissibilité ou la qualité du résultat affiché. Associez d'abord chaque propriété obligatoire à une information réelle et visible sur la page.
Ajoutez ensuite les propriétés recommandées lorsque vous disposez de données fiables. N'inventez jamais une note, un prix, un auteur, une image, une disponibilité ou une date dans le seul but de remplir la liste. Un objet plus court et fidèle au contenu vaut mieux qu'un balisage riche contredisant ce que voient les visiteurs.
Certaines propriétés contiennent des objets imbriqués, notamment offers pour Product, author pour Article, location pour Event et mainEntity pour FAQPage.
Intégrez des résultats déterministes à vos contrôles
La consultation utilise un catalogue fixe en mémoire, sans réseau, modèle, hasard ni dépendance à l'heure. Un même type pris en charge produit donc toujours le même résultat ordonné. Elle convient aux audits reproductibles, générateurs de formulaires, modèles de schéma, scripts de migration et contrôles d'intégration continue.
Un CMS peut demander la liste lorsqu'une personne chargée de l'édition choisit un type de contenu, signaler les entrées obligatoires manquantes et présenter séparément les améliorations recommandées. Un générateur peut utiliser l'URL canonique tout en conservant l'ordre des champs dans une interface prévisible. Considérez le résultat comme un point de départ pratique et vérifiez la documentation actuelle de tout moteur de recherche dont les résultats enrichis sont essentiels, car ses règles particulières ne font pas partie de ce catalogue hors ligne.
Tout type non pris en charge produit volontairement une erreur avec le nom soumis et les choix admis.
Cas d’usage
Contrôler les propriétés absentes
Comparez les clés du balisage existant aux champs minimaux et complémentaires courants de son type déclaré.
Guider la rédaction du contenu
Présentez d'abord les saisies obligatoires, puis les améliorations recommandées lors du choix d'un type de page.
Questions fréquentes
Que se passe-t-il si un type est inconnu ?
La requête renvoie une erreur de saisie et énumère les noms canoniques acceptés. Aucun remplacement n'est deviné.
Le résultat inclut-il les structures imbriquées ?
Non. Il énumère les propriétés supérieures courantes. Les objets imbriqués comme Offer, Person ou PostalAddress doivent être créés et validés séparément.
Quelles propriétés faut-il pour un Product ?
Le minimum courant est name et image, tandis que description, sku, brand, offers, aggregateRating et review sont recommandées. Reliez chacune à une information réellement visible sur la page.
Quel type choisir pour ma page ?
Le plus précis qui décrit le sujet principal de la page, pas un simple détail : Product pour un article à acheter, Recipe pour une recette, Article pour un contenu éditorial et LocalBusiness pour un commerce physique.
Puis-je remplir une propriété sans en avoir la donnée ?
Non. N'inventez jamais une note, un prix, un auteur, une image, une disponibilité ou une date pour compléter la liste. Un balisage plus court et fidèle à la page est plus sûr qu'un balisage qui la contredit.
Outils associés
Pour les développeurs — accès API
Tout sur cette page est disponible par programmation. Cette section s'adresse aux équipes qui veulent l'intégrer à leurs systèmes ; les autres peuvent simplement utiliser l'outil ci-dessus.
Endpoint
Authentification par jeton Bearer : un seul POST met la tâche en file d’attente, et le résultat vous parvient par webhook ou lien signé.
Appeler depuis votre stack
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)Exemple de requête
{
"type": "Product"
}Exemple de réponse
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "seo.schema_type_lookup",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}L’API est asynchrone : chaque appel renvoie un task_id immédiatement, puis vous interrogez l’état à raison d’une requête par seconde.
Tarifs
Le prix est publié, sans tokens ni crédits. Une tâche qui échoue n’est pas facturée.
Erreurs
| HTTP | Code | Signification |
|---|---|---|
401 | unauthorized | Clé API absente ou invalide : vérifiez l’en-tête Authorization. |
402 | insufficient_balance | Solde insuffisant : rechargez votre compte pour lancer cette tâche. |
404 | unknown_type | Type de tâche inconnu : vérifiez le champ type de votre requête. |
429 | rate_limited | Trop de requêtes : ralentissez la cadence, puis réessayez. |
Notes techniques
Choisir un type Schema.org n'est que la première étape de la création de données structurées utiles.
Commencez par le type exact représenté par votre page
Indiquez un type Schema.org comme Product pour un article vendu, Recipe pour des instructions culinaires, Article pour un contenu éditorial ou LocalBusiness pour une entreprise disposant d'une présence physique. La consultation ignore la casse et accepte également l'URL complète d'un type schema.org, ce qui est pratique lorsque la valeur provient d'un document JSON-LD existant. Cette consultation couvre les types populaires des mises en œuvre SEO, et non toutes les classes du vocabulaire Schema.org complet.
Interprétez les champs comme une liste de mise en œuvre
Schema.org est un vocabulaire et n'impose pas universellement des propriétés comme le ferait un schéma de base de données. La consultation nomme ces propriétés supérieures, mais ne génère pas leurs valeurs et ne valide pas un graphe JSON-LD complet.
Intégrez des résultats déterministes à vos contrôles
Un outil d'audit peut comparer les clés JSON-LD existantes à la réponse et relever les lacunes sans transformer chaque recommandation en erreur. Une requête API coûte $0.002 et le navigateur utilise la même logique pure.
Cas d'intégration
Préparer un modèle JSON-LD
Obtenez une liste stable avant de concevoir les champs du CMS destinés à un nouveau modèle de données structurées.
Questions techniques
Ces champs sont-ils imposés par Schema.org ?
Non. Schema.org définit un vocabulaire, mais n'impose généralement pas de propriétés. La liste obligatoire représente les minimums courants en SEO.
Puis-je envoyer une URL Schema.org complète ?
Oui. Une valeur telle que https://schema.org/Product est normalisée vers le type canonique Product.
Quel est le coût d'une consultation par API ?
Chaque requête API coûte $0.002. L'algorithme est déterministe et n'appelle aucun service externe.