Générateur de dégradés CSS
Dégradés linéaires, radiaux et coniques.
Design
Données structurées Schema.org en JSON-LD.
Schema.org compte des centaines de types, mais seuls quelques-uns produisent un affichage visible.
| Type | Pour quoi | Affichage |
|---|---|---|
| Article | articles et actualités | date, auteur |
| FAQPage | foire aux questions | blocs dépliants |
| Product | fiches produit | prix, disponibilité |
| LocalBusiness | établissement physique | horaires, adresse |
| BreadcrumbList | fil d'Ariane | chemin dans le résultat |
| HowTo | instructions pas à pas | étapes numérotées |
LocalBusiness mérite une attention particulière si vous avez un établissement physique en France : associé à une fiche d'établissement bien tenue, c'est ce qui produit le plus d'effet en recherche locale.
Indiquez les horaires au format structuré, le téléphone avec l'indicatif international, et l'adresse avec le code postal. Et veillez à ce que ces données correspondent exactement à votre fiche d'établissement : les divergences font perdre en confiance.
Les résultats enrichis ne sont jamais garantis. Le balisage vous rend éligible, le moteur décide.
JSON-LD est un bloc autonome, ce qui le rend bien plus maniable que les alternatives.
Il se place dans une balise script dont le type vaut application/ld+json, dans le head ou dans le body — les deux conviennent.
Son avantage sur les microdonnées et RDFa est qu'il ne s'entremêle pas au HTML : vous pouvez le générer, le modifier ou le supprimer sans toucher à la mise en page.
Tout bloc commence par @context valant « https://schema.org » et un @type qui précise de quoi il s'agit.
Vous pouvez avoir plusieurs blocs sur la même page, ou un seul avec un @graph contenant plusieurs entités liées. La seconde option est plus propre quand les entités se référencent entre elles.
Et une règle sans exception : le balisage doit décrire ce que l'utilisateur voit sur la page. Baliser des avis inexistants, ou une foire aux questions absente du contenu visible, expose à une action manuelle et à la perte de tous les résultats enrichis du site.
Presque tous les problèmes tiennent en quelques catégories.
Champs obligatoires manquants : chaque type a les siens, et sans eux le balisage n'est pas éligible même s'il constitue un JSON valide.
Dates mal formées : elles doivent suivre la norme ISO 8601, avec fuseau horaire. Une date au format français dans le JSON-LD est une erreur.
Prix écrits en texte avec le symbole : la valeur doit être numérique et la devise figure dans son propre champ, avec le code EUR.
Balisage copié d'une page à l'autre sans mise à jour, de sorte que vingt produits partagent le même identifiant. C'est plus courant qu'on ne l'imagine dans les boutiques à gabarits.
Validez systématiquement avec l'outil de test des résultats enrichis avant de considérer que c'est bon, puis surveillez le rapport d'améliorations dans la console de recherche : c'est là qu'apparaissent les erreurs en production.
Et si vous utilisez un système de gestion de contenu, vérifiez qu'il ne génère pas déjà son propre balisage. Deux blocs contradictoires sur la même page valent moins que rien.
JSON-LD, recommandé et le plus simple à maintenir puisqu'il ne se mêle pas au HTML.
Non. Vous devenez éligible, mais le moteur décide de les afficher ou non.
Non. Cela expose à une action manuelle et à la perte de tous vos résultats enrichis.
Au format ISO 8601 avec fuseau horaire, jamais au format français.
LocalBusiness, avec horaires structurés et des données identiques à votre fiche d'établissement.
Non.