Votre page affiche une adresse, un téléphone, des horaires, un prix. Le visiteur les lit. Google doit les déduire du texte et des liens, et il se trompe parfois. Les données structurées retirent ce doute : un bloc de code, invisible à l'écran, qui nomme ce qu'est la page et ce qu'elle décrit.
La décision qui compte n'est pas technique. Elle consiste à savoir quoi déclarer, sur quelle page, et quand s'abstenir. Six types suffisent pour un commerce local.
Ce que « données structurées » veut dire
Un bloc de données structurées est un texte au format JSON, posé dans la page entre deux balises de script. Vous y écrivez des paires nom-valeur : le type de la page, le nom de l'entreprise, le téléphone, la ville, les horaires. Ce format s'appelle JSON-LD, et c'est celui que Google lit aujourd'hui.
Le bloc ne s'affiche pas : il est lu par les robots qui parcourent la page. Deux effets en découlent.
Le premier est une compréhension plus sûre : au lieu de déduire votre activité d'un paragraphe, Google lit une déclaration explicite. Cette clarté sert aussi aux moteurs de réponse, qui citent plus volontiers une entreprise déclarée noir sur blanc.
Le second touche l'affichage dans les résultats : un fil d'Ariane à la place d'une adresse illisible, un prix, des questions dépliables. Rien n'est automatique : le balisage rend la page éligible, Google décide ensuite.
Ce que le balisage ne fait pas
Ce n'est pas un levier de classement. Le balisage décrit une page, il ne la pousse pas. Une page mal placée reste mal placée : celle qui gagne des places est celle qui répond mieux à la recherche.
Ce n'est pas un rattrapage. Un bloc propre ne crée pas l'information absente. Si votre page ne dit ni vos prix, ni votre zone, ni vos délais, le code n'a rien à décrire. Un bloc qui déclare ce que la page n'affiche pas est une faute, pas une optimisation.
Ce n'est pas un remplacement de la fiche. Pour un commerce local, la fiche Google reste la source que les clients consultent. Le balisage du site la confirme : même nom, même adresse, même numéro. Deux sources qui se contredisent valent moins qu'une seule source juste.
Le repère. Le balisage ne dit pas ce que vous aimeriez être. Il dit ce que la page affiche.
Six types, six questions
Chaque type répond à une question précise, dans l'ordre où on les rencontre sur un site.
Organization : qui est cette entreprise ? LocalBusiness : où se trouve cet établissement, et comment le joindre ? Product : qu'est-ce que cet article vendu ? Article : qu'est-ce que ce texte ? BreadcrumbList : où suis-je dans ce site ? FAQPage : quelles questions reviennent sur ce sujet ?
D'autres types existent, mais ils concernent d'autres métiers.
Organization : à déclarer une fois
Organization décrit l'entreprise elle-même : son nom, l'adresse de son site, son logo, ses pages officielles. Il se pose une seule fois, sur la page d'accueil, et les autres pages s'y rattachent par un identifiant commun. Google relie alors votre nom, votre logo et vos pages à une seule entité, au lieu de traiter chaque page comme un site distinct.
Quand il ne sert à rien. Sur un site d'une seule page, il fait doublon avec LocalBusiness : un bloc complet vaut mieux que deux partiels. Et un nom différent de celui de votre fiche Google crée une contradiction que Google devra trancher.
LocalBusiness : la page de contact, et pas ailleurs
C'est le bloc le plus utile pour un commerce local, et celui qui se pose le plus mal. Il décrit un établissement : son nom, son adresse, son téléphone, ses horaires. Ces informations figurent déjà dans votre fiche Google Business Profile ; le balisage les confirme là où la page les affiche.
Où il sert
Sur la page qui présente l'établissement : la page de contact, la page « où nous trouver », ou l'accueil quand le commerce n'a que cette page. Les coordonnées sont visibles sur cette page, et le bloc reprend exactement les mêmes valeurs. Le détail des champs est traité dans la configuration de la fiche Google Business Profile.
Où il ne sert à rien
Sur un article de blog, une page de service, une page de mentions légales, une page produit. Ces pages ne sont pas la page de votre établissement : y déclarer une adresse et des horaires n'aide personne, et multiplie les déclarations à réconcilier.
Le cas le plus courant est le bloc identique recopié partout : le jour où vous changez de numéro, il faut penser à chaque page, et un seul oubli crée la contradiction.
Un exemple de LocalBusiness, court et correct
Voici un bloc réel, pour une menuiserie installée à Cocody. Il tient en huit lignes et couvre l'essentiel : identité, contact, adresse, horaires, zone.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "LocalBusiness",
"name": "Menuiserie Kouassi",
"url": "https://menuiserie-kouassi.ci/contact/",
"telephone": "+225 07 07 00 00 00",
"address": "Rue des Jardins, Cocody, Abidjan, Côte d'Ivoire",
"openingHours": "Mo-Sa 08:00-18:00",
"areaServed": "Abidjan",
"sameAs": "https://www.facebook.com/menuiseriekouassi"
}
</script>Chaque ligne se relit avant publication. Le name est celui de l'enseigne, écrit comme sur la devanture. L'url pointe la page qui porte le bloc, pas l'accueil si le bloc est sur la page de contact. Le telephone s'écrit en entier, indicatif pays compris. L'address tient en une seule ligne de texte, ce qui suffit à décrire l'établissement.
Deux remarques. Ce bloc ne se recopie pas d'un site à l'autre : reprendre l'exemple d'un prestataire en laissant son nom ou son numéro décrit votre page avec l'identité de quelqu'un d'autre. Ensuite, le téléphone doit être identique dans le bloc, dans le pied de page, sur la page de contact et dans la fiche Google.
Product : seulement là où un article est vendu
Product décrit un article précis : son nom, son prix, sa disponibilité. Bien posé, il permet d'afficher le prix dans le résultat de recherche, et amène des visiteurs déjà informés.
Où il sert : sur la page du produit, celle où le client peut l'acheter ou le commander, avec un prix affiché et une disponibilité réelle. Le prix du bloc est celui de la page, dans la même monnaie.
Où il ne sert à rien : sur une page de catégorie, une page de tarifs, une page de service, ou un article qui parle d'un produit sans le vendre. Autre cas fréquent : beaucoup de modèles de boutique déclarent un Product sur toutes les pages, accueil et panier compris. Mieux vaut le désactiver. Le travail sur les fiches elles-mêmes est traité dans la rédaction des fiches produits.
Article : pour le contenu éditorial
Article décrit un texte : son titre, sa date de publication, son auteur. Il ne produit pas d'affichage spectaculaire, mais il lève une ambiguïté réelle : cette page est-elle un article d'information ou une page de vente ?
Ce blog s'en sert sur chacun de ses articles. La page que vous lisez porte trois blocs — Article, BreadcrumbList et FAQPage — visibles dans son code source, avec les trois niveaux de son fil d'Ariane. L'exemple est sous vos yeux.
Quand il ne sert à rien : sur une page de service, une page de contact, une page de tarifs. Une négligence revient aussi souvent : la date du bloc et la date affichée sur la page finissent par diverger.
BreadcrumbList : le fil visible d'abord
BreadcrumbList décrit le chemin parcouru dans le site : accueil, rubrique, page. Dans les résultats, ce chemin remplace parfois l'adresse de la page, souvent illisible.
La règle est simple : le fil déclaré doit être celui qui est affiché en haut de la page. Sans fil visible, le bloc n'a rien à décrire.
Il devient donc inutile sur un site d'une seule page, ou sur un site sans hiérarchie. Sur un blog ou une boutique à rubriques, il aide à la fois le visiteur et la lecture de vos adresses de page. Ce blog en pose un sur chaque article, à trois niveaux : Blog, SEO, puis le titre. La méthode d'ensemble est dans le guide du SEO local à Abidjan.
FAQPage : seulement s'il y a une FAQ visible
FAQPage décrit une liste de questions et de réponses. Utilisé correctement, il peut afficher des questions dépliables dans le résultat de recherche : une place gagnée à côté du lien, et une réponse donnée avant le clic.
La condition est stricte : les questions et les réponses doivent être visibles sur la page, avec le même texte. Un bloc FAQPage posé sur une page qui n'affiche aucune FAQ est une faute, et c'est le cas le plus fréquent. Une extension ajoute le bloc, les questions sont retirées à la refonte suivante, et le code décrit un contenu disparu. Google l'ignore, et l'affichage enrichi s'éteint.
Trois règles pratiques. Un seul bloc FAQPage par page. Des réponses de deux ou trois phrases, formulées comme sur la page. Et une mise à jour des deux côtés : réponse visible modifiée, bloc modifié. Sur ce blog, chaque article porte une FAQ visible et un bloc qui reprend les mêmes questions.
Où poser quoi, page par page
La répartition qui tient sur la plupart des sites de commerce local se résume en cinq lignes, et c'est aussi l'ordre de travail.
Page d'accueil : Organization, une seule fois. Si le commerce n'a qu'une page, c'est LocalBusiness qui vient à sa place, avec les coordonnées complètes.
Page de contact : LocalBusiness, avec les mêmes coordonnées que la fiche Google et que le pied de page.
Pages de service : rien de spécifique. Du texte clair, des liens, un fil d'Ariane.
Pages produit : Product, sur chaque article réellement vendu.
Articles et guides : Article, plus BreadcrumbList, plus FAQPage si une FAQ est affichée.
Un principe traverse cette liste : un type par page, déclaré une seule fois. Deux blocs qui décrivent la même chose avec des valeurs différentes se neutralisent. Et pour un commerce sans site, la fiche reste le levier principal, comme le montre le SEO local sans site web.
Vérifier ce qui est posé
Les fautes qui reviennent
Le code recopié tel quel, avec le nom ou le numéro du prestataire. Une déclaration sans contenu visible : une FAQ absente, un prix qui n'est plus affiché, des horaires de l'an dernier. Des coordonnées contradictoires entre le bloc, le pied de page et la fiche. Des blocs en double : une extension en pose un, quelqu'un en ajoute un second à la main. Un bloc invalide : une virgule en trop, un guillemet oublié, et le bloc entier est ignoré sans que personne ne s'en aperçoive.
Quatre vérifications
Un : compter les blocs. Ouvrez le code source de la page et cherchez « application/ld+json » : notez combien de blocs apparaissent et ce qu'ils déclarent. Sur dix pages, le tour se fait en une demi-heure.
Deux : tester une page. L'outil de test des résultats enrichis de Google affiche les types détectés, les erreurs et les avertissements.
Trois : relire les valeurs. L'outil dit que le code est valide ; il ne dit pas que l'adresse est la bonne. Comparez le bloc avec la page affichée et avec la fiche Google.
Quatre : refaire le tour après chaque changement. Une refonte, une extension ajoutée, un modèle mis à jour : les blocs changent sans prévenir. Un contrôle par trimestre suffit, en regardant aussi le rapport de Search Console. Comptez plusieurs semaines entre la pose et un effet visible.
Et une page à la fois : mieux vaut trois blocs exacts que dix blocs approximatifs, et une déclaration qui reste vraie après le prochain changement de numéro.
Votre site dit-il à Google ce qu'il est ?
La page site web présente ce qui est remis avec un site : structure claire, balisage des pages essentielles, coordonnées identiques à celles de votre fiche.
Voir la page site web Écrire sur WhatsAppFAQ — Les données structurées
Les données structurées font-elles monter une page dans les résultats ?
Non, ce n'est pas un levier de classement : le balisage décrit la page, il ne la fait pas remonter. Il peut en revanche changer l'affichage du résultat quand Google choisit de s'en servir.
Quelle différence entre Organization et LocalBusiness ?
Organization décrit l'entreprise : son nom, son site, son logo, ses pages officielles. Il se pose une fois, sur l'accueil. LocalBusiness décrit un établissement et ses coordonnées : adresse, téléphone, horaires, zone desservie. Il se pose sur la page qui présente cet établissement, le plus souvent la page de contact. Sur un site d'une seule page, gardez un seul bloc, complet.
Peut-on baliser une FAQ qui n'est pas visible sur la page ?
Non, c'est une faute. Les questions et les réponses déclarées dans le bloc doivent être affichées sur la page, avec le même texte. Un bloc FAQPage posé sur une page sans FAQ, ou dont les questions ont été retirées à une refonte, décrit un contenu qui n'existe pas : Google l'ignore, et l'affichage enrichi disparaît.
Où placer le code dans la page ?
Dans une balise de script de type application/ld+json, placée dans l'en-tête ou dans le corps de la page. L'emplacement n'a pas d'importance pour la lecture : ce qui compte, c'est que le bloc soit présent sur la page qu'il décrit, et qu'il soit unique.
Le balisage suffit-il pour obtenir un affichage enrichi ?
Non. Le balisage rend la page éligible, il ne déclenche rien : c'est Google qui décide, requête par requête, d'afficher ou non un prix ou un fil d'Ariane. Le travail utile consiste à décrire correctement ce qui existe sur la page, puis à vérifier avec l'outil de test que tout est détecté sans erreur.
Que se passe-t-il si le bloc contient une erreur ?
Le bloc est ignoré en entier. Une virgule en trop, un guillemet oublié ou une accolade mal fermée suffisent, et rien ne s'affiche dans le navigateur pour vous prévenir. C'est pourquoi chaque bloc se vérifie avec l'outil de test des résultats enrichis avant publication, et à nouveau après chaque refonte.