Localiser le balisage schema pour l'e-commerce consiste à faire en sorte que vos données structurées parlent la langue de vos clients et des moteurs de recherche. Pour les boutiques en ligne internationales, en particulier celles qui ciblent des régions diverses comme l'UE, l'Asie du Sud-Est ou le Moyen-Orient, la localisation du schema est essentielle pour aider les moteurs de recherche à afficher les bons extraits enrichis en fonction de la langue, de la région et de la devise de l'utilisateur.
En localisant les principaux types de schémas, comme les informations produit, les tarifs et les détails de l'entreprise, vous améliorez la visibilité, la confiance et les taux de conversion sur différents marchés. Cet article explore les éléments de schéma à localiser, les erreurs courantes à éviter et les bonnes pratiques pour aider votre site e-commerce international à performer au mieux.
L'importance de la localisation du schéma pour votre e-commerce
La localisation des schémas garantit que vos données structurées correspondent à la langue, à la devise et au contexte culturel de chaque marché que vous servez. Cela améliore votre visibilité dans les résultats de recherche locaux et optimise l'expérience utilisateur dans différentes régions.
- Améliore les performances de référencement local – Lorsque le balisage schema utilise une langue localisée, une devise et des champs spécifiques à la région, les moteurs de recherche peuvent mieux comprendre et faire correspondre votre contenu à l'intention de recherche locale.
- Permet des extraits enrichis précis – Les extraits enrichis tels que les prix, la disponibilité des produits et les avis refléteront le contexte local de l'utilisateur, renforçant la confiance et améliorant les taux de clics.
- Améliore l'expérience utilisateur multilingue – Le balisage localisé contribue à garantir la cohérence entre le contenu visible de la page et les données structurées qui le sous-tendent, évitant ainsi toute confusion pour les visiteurs internationaux.
- Prend en charge la conformité et les attentes régionales – Différentes régions peuvent avoir des exigences spécifiques en matière de données (comme la TVA dans l'UE ou les zones de livraison en Asie du Sud-Est) qui peuvent être traitées via le balisage schema.
- Augmente les taux de conversion sur les marchés cibles – Les utilisateurs qui voient une langue, une devise et des informations de contact familières dans les aperçus de recherche sont plus susceptibles de faire confiance à votre site et d'interagir avec lui.
Principaux types de schémas e-commerce nécessitant une localisation
Le balisage Schema est un type de données structurées ajouté au HTML de votre site web qui aide les moteurs de recherche à comprendre le contexte de votre contenu. Pour l'e-commerce, il alimente des résultats enrichis comme les notes des produits, les prix, la disponibilité, et bien plus encore, ce qui fait ressortir vos annonces dans les résultats de recherche. Lorsque vous ciblez des marchés internationaux, utiliser simplement le balisage schema ne suffit pas, vous devez également le localiser.
Voici les principaux types de schémas qui nécessitent une localisation minutieuse pour réussir dans le commerce électronique mondial.
Produit
Le schéma Product fournit des informations structurées telles que le nom du produit, la description, le SKU, la marque, l'image et les avis. Lors de la localisation de ce schéma, il est essentiel de traduire avec précision les noms et descriptions de produits, non pas mot à mot, mais d'une manière qui résonne avec les normes culturelles et linguistiques de chaque marché.
Plusieurs éléments clés doivent être adaptés à chaque marché cible pour localiser correctement le schéma Product. Ces éléments vont au-delà de la simple traduction—adaptation culturelle, conformité aux attentes locales et alignement sur le SEO propre à chaque langue. Voici les aspects clés du schéma Product qui devraient être localisés.
- name : Traduisez le nom du produit pour préserver son sens et son attrait dans la langue locale. Évitez les traductions littérales qui pourraient semer la confusion ou induire en erreur le public local.
- description : Localisez les descriptions en tenant compte du ton, des unités de mesure (par exemple, pouces vs centimètres) et de la terminologie familière aux audiences régionales.
- image : Bien qu'il ne s'agisse pas de texte, des visuels localisés peuvent refléter des préférences culturelles. Par exemple, les images de vêtements sur les marchés du Moyen-Orient peuvent nécessiter des visuels plus modestes.
- brand : Si la marque porte des noms différents selon les régions, ou si les sous-marques sont plus reconnaissables localement, assurez-vous que le champ brand le reflète.
- sku : Bien que souvent cohérent au niveau mondial, si vous utilisez des codes ou identifiants produits régionaux, mettez à jour le sku pour qu'il corresponde au catalogue local.
- review et aggregateRating : Ces éléments peuvent également bénéficier d'une localisation. Si les avis clients sont inclus dans le schéma, assurez-vous qu'ils sont rédigés dans la langue locale et reflètent les retours clients spécifiques à la région.
- offers (intégré à Product) : Cela inclut les prix et la disponibilité, qui doivent refléter la devise, les formats et les niveaux de stock locaux. Pensez également à adapter priceValidUntil aux cycles de vente locaux.
Par exemple, un produit « Winter Coat – Arctic Series » en anglais pourrait être localisé en « Chaqueta Invernal – Serie Ártica » en espagnol. Sur les marchés arabes, non seulement le nom et la description doivent être traduits en arabe, mais vous devrez peut-être aussi adapter les visuels et les caractéristiques mises en avant à ce qui est considéré comme attrayant ou pudique.
Ne pas localiser le schéma Product peut créer un décalage entre ce qui est affiché dans l'extrait de recherche et ce qui figure sur la page produit réelle, ce qui nuit à la confiance et fait baisser le taux de clics. En adaptant votre schéma produit à chaque locale, vous garantissez la cohérence, un meilleur alignement SEO et une expérience d'achat plus fluide.
{
"@context": "https://schema.org/",
"@type": "Product",
"name": "Chaqueta Invernal – Serie Ártica",
"description": "Una chaqueta cálida ideal para el invierno, con capucha desmontable y bolsillos amplios.",
"sku": "ARCTIC-ES",
"image": "https://example.com/es/images/arctic-coat.jpg",
"brand": {
"@type": "Brand",
"name": "FrostWear"
}
}
Voici un exemple de balisage de schéma Product qui apparaît en ligne lors de la recherche d'un produit.
Prix et devises
Le prix est l'une des informations les plus sensibles pour les acheteurs en ligne. Le schéma Offer, généralement intégré au schéma Product, comprend des champs clés tels que price, priceCurrency et availability. La localisation de la devise et des prix est cruciale, surtout lorsque votre site cible des régions qui n'utilisent pas l'USD, l'EUR ou d'autres valeurs par défaut standard.
Par exemple, si vous vendez au Moyen-Orient, votre schéma doit refléter les prix en AED ou SAR en utilisant le code de devise ISO 4217 approprié, comme « priceCurrency » : « AED ». De plus, le format des prix doit suivre les conventions régionales—certains pays utilisent des virgules au lieu de points comme séparateurs décimaux, ou placent le symbole monétaire après le montant au lieu d'avant.
Des codes de devise incorrects ou génériques dans le balisage schema peuvent entraîner des extraits enrichis trompeurs, des acheteurs désorientés et même des pénalités des moteurs de recherche pour incohérence des données. Votre schema doit être synchronisé avec ce que les utilisateurs voient sur le front-end et refléter les taux de conversion en temps réel ou les stratégies de tarification localisées. Adapter ce schema par langue ou sous-domaine régional est essentiel pour garantir une représentation précise sur l'ensemble de votre site web multilingue. Éléments clés du schema de tarification qui doivent être localisés.
- price : valeur numérique du prix formatée pour la région locale (par ex., 99,99 au lieu de 99.99).
- priceCurrency : Utilisez le code de devise ISO 4217 correct (par ex., AED, SAR, JPY, etc.).
- Placement du symbole monétaire : Adaptez le symbole aux conventions locales (par ex., « 99 ر.س » au lieu de « SAR 99 »).
- availability : Utilisez un langage ou des libellés localisés le cas échéant (par exemple, « In Stock » → « Disponible » en espagnol).
Voici un exemple de schéma localisé pour les prix adapté à un marché du Moyen-Orient.
{
"@context": "https://schema.org/",
"@type": "Offer",
"price": "89.99",
"priceCurrency": "EUR",
"availability": "https://schema.org/InStock",
"priceValidUntil": "2025-12-31",
"itemCondition": "https://schema.org/NewCondition",
"url": "https://example.com/es/productos/chaqueta-artica"
}
Voici un exemple de balisage de schéma de tarification et de devise qui apparaît en ligne lors de la recherche d'un produit.
Informations commerciales et de contact
Les schémas Organization et ContactPoint définissent l'identité de votre entreprise et la manière dont les clients peuvent vous contacter. La localisation ici implique plus qu'une simple traduction—elle nécessite d'adapter les horaires d'ouverture, les langues de support et les méthodes de contact aux attentes locales.
En localisant le schéma business et contact, vous renforcez la confiance et aidez les moteurs de recherche à afficher des coordonnées précises dans les SERP (surtout sur mobile). Cela aide également la recherche vocale et les assistants intelligents à fournir des réponses commerciales correctes en fonction de la localisation. Un schéma bien localisé garantit que les clients voient les bonnes options de contact au bon moment, en accord avec leur langue, leur région et leurs méthodes de communication préférées.
Les principaux éléments des schémas Organization et ContactPoint à localiser comprennent.
- name : Traduisez ou adaptez le nom de l'entreprise si vous utilisez une identité de marque locale dans différentes régions.
- contactType : Utilisez des termes localisés pour les types de support (par exemple, « servicio al cliente » en espagnol).
- telephone : Incluez les numéros de support locaux avec les formats internationaux appropriés.
- areaServed : Spécifiez la région cible à l'aide des codes ISO pour garantir la pertinence géographique.
- availableLanguage : Indiquez les langues que votre équipe d'assistance peut prendre en charge (par exemple, anglais, arabe, français).
- contactOption : Ajoutez des méthodes de contact spécifiques à la région, telles que WhatsApp, WeChat ou des outils de chat locaux.
- url : Dirigez les utilisateurs vers des pages d'aide ou de contact localisées si elles sont disponibles.
En adaptant chacun de ces champs pour chaque région cible, votre schéma répondra aux attentes locales et augmentera vos chances d'apparaître dans les résultats de recherche pertinents, en particulier ceux qui reposent sur les interactions mobiles ou vocales. Voici un exemple d'application du schéma.
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "YourBusiness",
"url": "https://www.yourbusiness.com",
"contactPoint": {
"@type": "ContactPoint",
"telephone": "+33-1-23-45-67-89",
"contactType": "customer support",
"areaServed": "FR",
"availableLanguage": ["en", "fr"]
}
}
Détails d'expédition et de livraison
Les attentes et les règles en matière de livraison varient considérablement d'un pays à l'autre. En utilisant des types de schéma tels que DeliveryTimeSettings, ShippingDeliveryTime ou OfferShippingDetails qui sont spécifiques à une région, vous pouvez communiquer non seulement la disponibilité et les délais de livraison estimés, mais aussi les régions desservies, les tarifs d'expédition et les délais de traitement, autant d'éléments qui doivent être localisés pour chaque marché. Les éléments de schéma d'expédition qui doivent être localisés incluent :.
- shippingDestination : région ou pays desservi.
- deliveryTime : délai de livraison estimé au format local (par exemple, 2 jours vs 5-7 jours ouvrés).
- shippingRate : tarif d'expédition dans la devise locale.
- transitTimeLabel : libellé utilisé pour décrire le délai de livraison (tel que « Express », « Standard » ou « Livraison en 24 heures »).
- handlingTime : délai de traitement avant le début de la livraison.
Par exemple, un client en Allemagne pourrait s'attendre à une livraison sous 3 jours ouvrés, alors qu'en Indonésie, une estimation typique serait de 5 à 7 jours. Si le schéma de livraison n'est pas localisé, les utilisateurs risquent de ne pas obtenir d'informations pertinentes dans les résultats de recherche, ce qui les rend hésitants à acheter. Voici un exemple d'OfferShippingDetails localisé pour le marché allemand.
{
"@context": "https://schema.org",
"@type": "OfferShippingDetails",
"shippingDestination": {
"@type": "DefinedRegion",
"name": "Germany"
},
"deliveryTime": {
"@type": "ShippingDeliveryTime",
"handlingTime": {
"@type": "QuantitativeValue",
"minValue": 1,
"maxValue": 2,
"unitCode": "d"
},
"shippingRate": {
"@type": "MonetaryAmount",
"value": "5.00",
"currency": "EUR"
}
}
Localisation du magasin et informations sur l'entreprise locale
L'affichage précis des emplacements de magasins dans Google Search ou Google Maps dépend fortement d'un schéma LocalBusiness bien localisé. En particulier lorsque les utilisateurs effectuent des recherches dans leur langue ou leur région, disposer des bonnes informations améliore la visibilité et renforce la confiance. Les éléments clés du schéma LocalBusiness qui nécessitent une localisation incluent :.
- name : le nom de l'entreprise est traduit s'il est pertinent pour le contexte local.
- address: l'adresse formatée selon les conventions locales, y compris addressLocality, addressRegion, postalCode et addressCountry.
- telephone : le numéro de téléphone en utilisant l'indicatif pays correct et le format local.
- openingHoursSpecification : Les horaires d'ouverture sont adaptés aux fuseaux horaires locaux et aux habitudes commerciales.
- géo : coordonnées géographiques (latitude et longitude) de l'emplacement du magasin.
- areaServed : la région ou la zone desservie par l’entreprise.
Par exemple, voici un extrait de schéma pour une boutique opérant à Berlin, en Allemagne.
{
"@context": "https://schema.org",
"@type": "LocalBusiness",
"name": "Modehaus Berlin",
"address": {
"@type": "PostalAddress",
"addressLocality": "Berlin",
"addressCountry": "DE"
},
"telephone": "+49 30 12345678",
"openingHours": "Mo-Fr 10:00-19:00"
}
Voici un exemple de barème de marge pour les entreprises locales.
Fil d'Ariane
Le schéma BreadcrumbList aide à définir la structure de navigation de votre site web, en montrant aux utilisateurs (et aux moteurs de recherche) où ils se trouvent dans la hiérarchie du site. Bien que cela puisse sembler simple, la localisation des fils d’Ariane est essentielle sur un site e-commerce multilingue pour garantir la cohérence, améliorer le référencement et optimiser l’expérience utilisateur.
Par exemple, un fil d'Ariane en anglais, en espagnol et en arabe
- « Accueil > Mode homme > Vestes »
- « Inicio > Moda Masculina > Chaquetas »,
- « الرئيسية > أزياء الرجال > المعاطف ».
Supposons que le schéma de fil d'Ariane reste en anglais alors que le contenu de la page est dans une autre langue. Dans ce cas, les utilisateurs peuvent être désorientés et les moteurs de recherche peuvent avoir du mal à indexer correctement le contenu localisé. Cela peut également nuire à votre stratégie de maillage interne, car le fil d'Ariane influence la façon dont l'équité de lien circule sur votre site.
Éléments clés du schéma BreadcrumbList nécessitant une localisation.
- itemListElement.name : Le nom visible de chaque niveau de fil d’Ariane doit être traduit.
- itemListElement.item: L'URL doit pointer vers la version localisée correcte de chaque page.
- position : Reflète le niveau dans le fil d'Ariane (reste généralement identique mais doit correspondre à la structure localisée).
{
"@context": "https://schema.org",
"@type": "BreadcrumbList",
"itemListElement": [
{
"@type": "ListItem",
"position": 1,
"name": "Inicio",
"item": "https://example.com/es/"
},
{
"@type": "ListItem",
"position": 2,
"name": "Moda Masculina",
"item": "https://example.com/es/moda-masculina"
},
{
"@type": "ListItem",
"position": 3,
"name": "Chaquetas",
"item": "https://example.com/es/moda-masculina/chaquetas"
}
]
}
Voici un exemple de schéma de balisage de fil d'Ariane.
Erreurs courantes dans la localisation des schémas pour le e-commerce
Les entreprises rencontrent souvent des problèmes critiques mais évitables lorsqu'elles localisent le balisage schema pour les sites e-commerce. Beaucoup supposent que la traduction seule suffit, mais les données structurées doivent être entièrement adaptées à la langue, à la devise et aux attentes des utilisateurs de chaque région. Ces négligences peuvent entraîner des extraits enrichis défectueux, une mauvaise visibilité dans les recherches ou une confusion chez les utilisateurs.
Voici quelques-unes des erreurs les plus courantes dans la localisation des schémas—et pourquoi les éviter peut avoir un impact significatif sur les performances de votre site et l'expérience utilisateur.
Utiliser une seule langue ou monnaie
L'une des erreurs les plus fréquentes dans la localisation des schémas e-commerce consiste à conserver une seule langue ou devise dans les données structurées du site, même lorsque le contenu front-end est traduit. Ce décalage perturbe à la fois les utilisateurs et les moteurs de recherche. Un acheteur en France peut lire des descriptions de produits en français mais voir un schéma qui fait toujours référence à l'USD au lieu de l'EUR, ce qui peut nuire à la confiance.
Le schéma localisé doit refléter le contenu traduit et les formats de devise locaux. Par exemple, « priceCurrency » : « EUR » doit remplacer « priceCurrency » : « USD » sur la version française du site, et les champs « name » et « description » du schéma Product doivent apparaître en français. Sans cela, les moteurs de recherche risquent de ne pas afficher correctement vos annonces localisées dans les résultats de recherche.
Ignorer la localisation de la langue et de la devise entraîne des aperçus d'extraits enrichis de mauvaise qualité, réduit les taux de clics et peut même enfreindre les règles d'exactitude des données structurées. Adaptez toujours votre schéma à chaque langue et région, en utilisant hreflang et des sous-domaines ou chemins spécifiques à chaque région.
Mise à jour incorrecte des codes de devise
Beaucoup oublient de mettre à jour le code de devise dans le balisage schema, même lorsque les marchands utilisent le bon symbole de devise localisé sur le front-end. Schema.org utilise les codes ISO 4217 standardisés (comme « USD » pour le dollar américain ou « JPY » pour le yen japonais), et ne pas les refléter correctement dans « priceCurrency » conduit à des résultats enrichis erronés ou trompeurs.
Par exemple, si votre boutique aux Émirats arabes unis affiche les prix en dirhams mais utilise encore « priceCurrency » : « USD » dans le schéma, Google pourrait mal interpréter le prix du produit ou choisir de ne pas l'afficher du tout. Pire encore, un client pourrait supposer qu'un produit est moins cher ou plus cher en raison d'un contexte de devise incorrect, ce qui entraînerait des taux de rebond ou des paniers abandonnés.
Vérifiez toujours les valeurs de devise dans votre schéma, en particulier pour les boutiques multidevises utilisant la géolocalisation ou des sélecteurs de devise. Aligner les informations de devise visuelles et structurées améliore l'apparence dans les résultats de recherche et la confiance des clients.
Ignorer les champs de schéma spécifiques à une région
Une autre erreur consiste à utiliser un schéma générique pour toutes les régions sans intégrer d’éléments spécifiques à chaque région, comme « shippingDestination », « areaServed » ou « availableAtOrFrom ». Ces champs sont essentiels pour communiquer la logistique et la couverture de service, en particulier pour l’expédition internationale ou le support client localisé.
Par exemple, les acheteurs en Australie devraient voir des estimations de délais d'expédition et des options de livraison basées sur les normes locales (par exemple, « shippingDestination » : { « @type » : « DefinedRegion », « name » : « Australia » }). Omettre ces détails peut amener les moteurs de recherche à supposer que vous ne livrez pas dans cette région, ce qui nuit à la visibilité dans les recherches locales.
De plus, des champs comme « areaServed » et « availableAtOrFrom » aident à faire ressortir votre entreprise pour les recherches « près de chez moi » ou basées sur une région. Si vous n'utilisez pas ces champs de schéma dans vos pages régionales, vous passez probablement à côté d'opportunités de recherche localisée.
Prise en charge des langues RTL ignorée
Les langues comme l'arabe et l'hébreu se lisent de droite à gauche (RTL), et ne pas adapter le balisage schema pour en tenir compte peut entraîner des problèmes de lisibilité et de SEO. Bien que le schema ne soit pas rendu visuellement, il doit tout de même refléter le contexte linguistique pour correspondre à l'expérience sur la page et au ciblage linguistique de la recherche.
Par exemple, les champs « name » et « description » du schéma de produit sur une page en arabe doivent être correctement traduits et encodés en utilisant le bon format Unicode. De plus, la page elle-même doit utiliser lang="ar" et dir="rtl" dans le HTML, et le schéma doit correspondre.
Négliger la prise en charge RTL entraîne une incohérence entre le contenu visuel et le contenu structuré, ce qui peut dérouter les utilisateurs et nuire à l'éligibilité aux résultats enrichis. Assurez-vous toujours que la langue et le sens de lecture sont reflétés dans la structure du schema.
Fils d'Ariane traduits manquants
Les fils d'Ariane servent d'aides à la navigation et contribuent de manière significative au maillage interne et au référencement naturel. Une erreur fréquente dans la localisation des données structurées consiste à conserver le balisage du fil d'Ariane dans la langue d'origine, même lorsque le chemin de navigation visible est traduit.
Par exemple, si votre page affiche « Inicio > Moda Femenina > Vestidos » (en espagnol pour « Accueil > Mode féminine > Robes »), votre schéma BreadcrumbList doit refléter cela exactement. Utiliser « name » : « Accueil » au lieu de « Inicio » crée une incohérence et peut nuire à la façon dont Google interprète la structure du site.
Chaque niveau de fil d’Ariane (« name ») doit être localisé, et l’« item » correspondant doit pointer vers l’URL localisée. Maintenir la cohérence de l’ensemble garantit une expérience uniforme pour les utilisateurs et les robots d’exploration, ce qui améliore la visibilité et l’indexation.
Réutiliser le même schéma pour toutes les langues
L'erreur la plus dommageable est d'utiliser une approche de schéma unique pour toutes les langues. Réutiliser les mêmes données structurées sans adapter le contenu, la devise, la langue et le contexte régional va à l'encontre de tout l'objectif de la localisation.
Chaque version localisée de votre site doit avoir un schéma reflétant le contenu et les métadonnées locales. Par exemple, si vous avez des pages produit distinctes pour l’anglais et le français, leur schéma Product doit comporter des champs « name », « description », « priceCurrency » traduits, et même des URL spécifiques à la langue.
Négliger cette pratique peut entraîner des signaux de recherche contradictoires, une mauvaise qualité d'extrait, voire des actions manuelles pour des données structurées trompeuses. Une bonne pratique consiste à maintenir des schémas distincts pour chaque sous-domaine linguistique ou version balisée hreflang, en veillant à ce que les données structurées correspondent à la langue et à la région desservies.
Bonnes pratiques pour la localisation du balisage schema pour l'e-commerce
Le balisage Schema joue un rôle crucial dans la façon dont les moteurs de recherche interprètent et affichent votre contenu. Lorsqu'il est correctement localisé, il améliore votre visibilité dans les SERP locales, augmente les taux de clics et optimise l'expérience d'achat des utilisateurs du monde entier.
Voici les bonnes pratiques que toute entreprise de commerce électronique mondiale devrait suivre pour tirer le meilleur parti de la localisation.
Utiliser un schéma spécifique à la langue pour chaque page
Chaque version linguistique de votre site web doit inclure un balisage schema dans cette langue spécifique. Si vous utilisez des sous-domaines ou des sous-dossiers (par exemple, example.com/en/ pour l'anglais et example.com/de/ pour l'allemand), chacun doit contenir un schema unique et adapté à la langue.
Si votre page allemande utilise encore un schéma en anglais, Google peut avoir du mal à comprendre le contexte local de la page, et les utilisateurs peuvent trouver l’expérience incohérente avec leurs attentes, comme dans l’exemple ci-dessous.
Pays | Champ du schéma | Valeur localisée |
/fr/product-page | « name » | « Veste d'hiver pour homme » |
« description » | « Une veste chaude pour l'hiver français » | |
« inLanguage » | « fr » |
Localisez les noms et descriptions de produits
Les noms et descriptions de produits ne doivent pas se limiter à une traduction et à une adaptation culturelle. Des formulations séduisantes dans un pays peuvent ne pas trouver d’écho dans un autre. Utilisez un langage naturel adapté à votre audience locale, en phase avec ses habitudes d’achat.
Faites appel à des traducteurs natifs ou à des experts locaux pour éviter les formulations maladroites ou les messages peu clairs. Les champs tels que le nom, la description et la marque dans votre schéma doivent refléter la langue et les préférences locales.
Langue | name | description |
Anglais | « Veste élégante pour homme » | « Une veste élégante parfaite pour l'hiver » |
japonais | « メンズウィンタージャケット » | « Une veste élégante parfaite pour l'hiver. » |
Définir un prix et une devise précis
Le prix est un sujet sensible dans le commerce en ligne. Ne vous contentez pas de convertir les devises visuellement sur votre site—assurez-vous que votre schéma reflète précisément la bonne devise à l'aide du code ISO 4217 dans le champ priceCurrency. Les prix doivent également être formatés selon les conventions locales, y compris les décimales et les séparateurs de milliers.
Évitez d'afficher uniquement l'USD dans toutes les versions linguistiques, car cela pourrait semer la confusion chez les utilisateurs ou nuire à la confiance. Si vous utilisez une conversion de devise en temps réel, assurez-vous que votre schéma reste synchronisé. Par exemple.
Pays | prix | priceCurrency | Format local |
Japon | 4500 | JPY | ¥4,500 |
Arabie Saoudite | 180 | SAR | 180 ر.س |
Localiser les informations de l’entreprise
Les coordonnées professionnelles, telles que les adresses, les numéros de téléphone et les horaires d'ouverture, doivent être localisées par région. Utilisez les formats locaux pour des champs comme addressLocality, postalCode et addressCountry. Incluez les indicatifs téléphoniques internationaux dans les numéros de téléphone pour faciliter la prise de contact par les utilisateurs.
Des champs comme openingHoursSpecification doivent refléter les fuseaux horaires et les pratiques commerciales locales. Ces détails aident à établir la confiance et améliorent l'apparence de votre entreprise dans les résultats de recherche locaux. Par exemple.
Pays | addressLocality | postalCode | openingHoursFormat |
Espagne | Barcelone | 08001 | Lun-Ven 09:00–18:00 |
Thaïlande | Chiang Mai | 50000 | Lun-Sam 10:00–19:00 |
Schéma de structure pour les langues RTL
Les langues comme l'arabe et l'hébreu s'écrivent de droite à gauche (RTL). Bien que JSON-LD lui-même ne dépende pas du formatage visuel, tout champ de schéma contenant du texte visible—tel que le nom, la description ou le fil d'Ariane—doit refléter la langue et la direction correctes afin d'éviter toute incohérence entre le contenu et le balisage.
Si votre page est en arabe mais que le schéma contient encore des valeurs en anglais ou du contenu de gauche à droite, cela peut prêter à confusion tant pour les utilisateurs que pour les moteurs de recherche. Assurez-vous toujours que le HTML inclut lang=”ar” et que les champs de données structurées sont localisés en conséquence.
Champ | Non localisé (LTR/anglais) | Localisé (RTL/arabe) |
name | Manteau d'hiver | معطف شتوي |
description | Un manteau chaud pour l'hiver | Un manteau chaud idéal pour l'hiver |
chapelure | Accueil > Vêtements > Vestes | Accueil > Vêtements > Manteaux |
Automatisez la localisation des schémas avec Linguise
Localiser manuellement le balisage de schéma dans plusieurs langues peut s'avérer complexe, surtout lorsqu'il faut gérer des centaines de pages produits dynamiques. Le contenu visible et les données structurées, y compris les schémas Product, Offer, BreadcrumbList et LocalBusiness, doivent être traduits. Sans une localisation appropriée, les extraits enrichis risquent de ne pas refléter la bonne langue, la bonne devise ou la bonne structure pour chaque région.
Linguise propose une solution de traduction automatique qui s'étend aux données structurées, traduisant le balisage schema et votre contenu. Grâce à son Éditeur en direct, vous pouvez ajuster manuellement le contenu du schema, comme les noms de produits, les descriptions ou les valeurs de marque, afin de garantir qu'ils reflètent fidèlement le contexte local. Cela est particulièrement utile lors de la localisation des champs du schema Product qui nécessitent une nuance culturelle et une adaptation des mots-clés pour le référencement régional.
De plus, Linguise prend en charge la traduction des liens et des médias, ce qui permet la localisation des URL de fil d'Ariane, des liens internes et même des références d'images. Cela garantit que tous les éléments, chemins de navigation, ressources et données structurées sont alignés sur la version linguistique correcte, aidant ainsi les moteurs de recherche à fournir des résultats enrichis plus précis et pertinents aux utilisateurs du monde entier.
Conclusion
La localisation du balisage schema est essentielle pour les entreprises de commerce électronique international qui cherchent à améliorer leur visibilité dans les résultats de recherche locaux, à enrichir les extraits enrichis et à offrir aux utilisateurs une expérience multilingue fluide. Des noms de produits et des prix aux détails d'expédition et aux informations commerciales, chaque élément de données structurées doit s'aligner sur la langue, la culture et les attentes de chaque marché cible.
Pour simplifier ce processus, envisagez d'utiliser Linguise—une solution de traduction qui non seulement automatise la traduction de contenu, mais adapte également votre balisage schema, vos liens et vos médias selon la langue. Avec des fonctionnalités comme l'éditeur en direct et la traduction des URL et des images, utiliser Linguise peut aider l'ensemble de votre site—le contenu visible et les données structurées—à être entièrement localisé et prêt pour le SEO.
