shaul1991/structured-data

Données structurées (JSON-LD)

Sources : Documentation des données structurées de Google Search Central et guide des données structurées de Naver Search Advisor (vérifié le 4 novembre 2026). Pour les décisions importantes, rouvrir les documents originaux.

Principes communs

• N'insérez que des valeurs correspondant au texte visible sur la page. Si vous ne connaissez pas un prix, un horaire, un stock ou une évaluation, laissez le champ vide et ne le créez pas (la documentation de Google sur les fonctionnalités IA recommande également que "les données structurées correspondent au texte visible").
• Le marquage ne garantit pas l'obtention de résultats enrichis ou d'une exposition (Google et Naver le précisent tous deux).
• Le format par défaut est JSON-LD (pris en charge par Google, Naver recommande Microdata ou JSON-LD). À placer dans <script type="application/ld+json"> dans <head> ou <body>.
• Validation : Test des résultats enrichis de Google, Schema Markup Validator (le guide de Naver recommande l'outil de schema.org), et scripts/seo-check.mjs du Skill seo-orchestrator (vérifie l'analyse JSON et les propriétés obligatoires uniquement).

Différences de prise en charge (4 novembre 2026)

Type	Google	Naver
Event	Documentation sur l'environnement de recherche d'événements disponible. ⚠️ La Corée ne figure pas dans la liste des régions couvertes (Australie, Brésil, Canada, Allemagne, Inde, Amérique latine, Espagne, Royaume-Uni, États-Unis)	Pas de guide
Organization/Person + sameAs	Informations sur l'organisation	Canaux associés du site (page racine, name·url·sameAs obligatoires)
WebSite	Nom du site (page d'accueil)	—
BreadcrumbList	Pris en charge	Pris en charge (name obligatoire, position facultatif)
ItemList (carrousel)	Uniquement certains types	Guide pour le carrousel (ListItem) disponible

Pour un site d'événements ciblant la Corée : le balisage Event peut être conservé pour une structuration précise des données et une future expansion vers d'autres régions, mais ne partez pas du principe que les résultats enrichis d'événements apparaissent actuellement dans la recherche Google en Corée. Évaluez les performances via les résultats de recherche classiques (titres et extraits) et la Search Console.

Event (selon Google)

Règles (données structurées d'événements Google) :

• Marquez chaque événement sur une URL unique (page de détail). Pas sur une page de liste ou de calendrier répertoriant plusieurs événements.
• Obligatoire : name (titre de l'événement. Interdiction des noms de lieu, prix, ou expressions promotionnelles comme "réservez maintenant"), startDate (ISO-8601), location (Place + name + address).
• Recommandé : endDate, eventStatus, description (contenu de l'événement, sans répéter la date et le lieu), image (largeur recommandée 1 920 px, minimum 720 px, plusieurs formats 16:9·4:3·1:1), offers, organizer, performer, previousStartDate.
• Date : si l'heure est inconnue, indiquez uniquement la date ("2026-12-04"). Ne complétez pas avec T00:00:00. Si l'heure est connue, incluez le décalage UTC (2026-12-04T10:00:00+09:00).
• Pour un événement de plusieurs jours, incluez startDate et endDate. Si des billets séparés sont nécessaires pour chaque jour, créez un Event par date.
• Pour un événement se déroulant simultanément dans plusieurs lieux, créez un Event par lieu.
• Utilisez offers.price: 0 uniquement si l'entrée gratuite est officiellement confirmée. Avant la mise en vente, vous pouvez omettre availability. validFrom correspond à l'heure de début de la vente.
• En cas de changement de statut, ne modifiez que eventStatus et conservez les autres valeurs inchangées :
  • Annulation EventCancelled (ne supprimez pas startDate·location)
  • Report sans nouvelle date EventPostponed (conservez la startDate d'origine)
  • Nouvelle date confirmée EventRescheduled + nouveau startDate/endDate + previousStartDate facultatif
• Ne marquez pas comme Event ce qui n'en est pas un (coupons, horaires d'ouverture, soldes). Les événements réservés aux membres ou sur invitation ne sont pas éligibles à l'environnement événementiel.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Event",
  "name": "<Nom officiel de l'événement et édition>",
  "startDate": "<YYYY-MM-DD ou YYYY-MM-DDThh:mm:ss+09:00>",
  "endDate": "<YYYY-MM-DD>",
  "eventStatus": "https://schema.org/EventScheduled",
  "location": {
    "@type": "Place",
    "name": "<Nom du lieu>",
    "address": {
      "@type": "PostalAddress",
      "streetAddress": "<Adresse postale>",
      "addressLocality": "<Ville·Arrondissement>",
      "addressRegion": "<Province·Département>",
      "postalCode": "<Code postal>",
      "addressCountry": "KR"
    }
  },
  "image": ["<https://.../16x9.jpg>", "<https://.../4x3.jpg>", "<https://.../1x1.jpg>"],
  "description": "<Résumé du contenu de l'événement. Ne répétez pas la date ou le lieu>",
  "organizer": { "@type": "Organization", "name": "<Organisateur>", "url": "<URL officielle de l'organisateur>" }
}
</script>

N'ajoutez offers que si le prix et les informations de vente sont officiellement confirmés.

Pages de liste

• N'insérez pas plusieurs Event dans une page de liste (par région, par mois) : Google ne prend en charge que les pages d'événements uniques. Utilisez plutôt BreadcrumbList et, si nécessaire, ItemList contenant les URL de détail.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "ItemList",
  "itemListElement": [
    { "@type": "ListItem", "position": 1, "url": "https://example.com/events/<id-1>" },
    { "@type": "ListItem", "position": 2, "url": "https://example.com/events/<id-2>" }
  ]
}
</script>

WebSite (Nom du site Google, page d'accueil uniquement)

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "WebSite",
  "name": "<Nom du site>",
  "alternateName": ["<Abréviation>"],
  "url": "https://example.com/"
}
</script>

Utilisez le même nom que og:site_name et le <title> de la page d'accueil. Source : Noms de sites

Organization + sameAs (Canaux associés Naver, page racine)

Domaines des canaux associés utilisés par Naver pour l'analyse (4 novembre 2026) : Naver Blog, SmartStore, KnowledgeiN, Chzzk, Clip, Daangn, Threads, Instagram, YouTube, KakaoStory, KakaoTalk Channel, Tistory, TikTok, Facebook, X (Twitter). L'exposition n'est pas garantie.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "<Nom du site>",
  "url": "https://example.com/",
  "sameAs": [
    "https://cafe.naver.com/<Café>",
    "https://pf.kakao.com/<Chaîne>",
    "https://x.com/<Compte>"
  ]
}
</script>

• N'incluez que les canaux réellement actifs. N'ajoutez pas d'URL de canaux non encore ouverts.
• Daum utilise également le même format (Person/Organization + sameAs) avec des domaines de support différents : YouTube, Facebook, X, Instagram, Google Play, Apple Store, KakaoStory, Daum Cafe, KakaoTV, Tistory, Brunch (daum-search). Vous pouvez regrouper les canaux réels des deux moteurs de recherche dans un seul bloc.
• Le café Naver n'est pas explicitement mentionné dans la liste des canaux associés ci-dessus (4 novembre 2026). Vous pouvez l'inclure, mais ne partez pas du principe que Naver l'utilisera comme canal associé.
• Source : Canaux associés du site

BreadcrumbList (Commun Google·Naver)

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    { "@type": "ListItem", "position": 1, "name": "<Nom de la catégorie supérieure>", "item": "https://example.com/<supérieure>" },
    { "@type": "ListItem", "position": 2, "name": "<Nom de la catégorie inférieure>", "item": "https://example.com/<supérieure>/<inférieure>" }
  ]
}
</script>

• Naver : utilisez des noms décrivant la page plutôt que des termes génériques comme "Accueil" ou "top", ordre large → spécifique, évitez les noms trop longs, composés uniquement de chiffres ou de caractères spéciaux.
• Sources : Naver BreadcrumbList, Google Breadcrumb