Sens et périmètre
Le type Schema.org WebSite peut exprimer le nom, l'URL et les informations associées d'un site dans des données structurées. C'est un vocabulaire, pas une promesse qu'un moteur de recherche affichera une fonctionnalité donnée. Google décide comment, quand et s'il utilise les données structurées dans la présentation des résultats, et peut modifier la prise en charge de ces fonctionnalités avec le temps.
Méthode pratique
Ne modélisez que des faits stables et visibles, ou vérifiables autrement. Utilisez l'URL canonique de la page d'accueil, le nom que voient les internautes, et les relations avec une Organization uniquement lorsqu'elles décrivent exactement la même entité. Le JSON-LD est un format de transport courant, mais un graphe syntaxiquement valide peut rester trompeur s'il mélange des faits de sites différents ou des réglages obsolètes.
Ce qu'il faut inspecter
Inspectez le code source de la page rendue et analysez le graphe après déploiement. Vérifiez que les identifiants se résolvent comme prévu, que les valeurs correspondent à l'identité visible du site, et qu'il n'existe aucun graphe au niveau du site en double ou contradictoire. Validez le vocabulaire et la syntaxe, puis consultez la documentation Google pertinente pour contrôler la prise en charge actuelle des fonctionnalités, plutôt que de vous fier à de vieux tutoriels.
Limites et erreurs courantes
N'ajoutez pas SearchAction pour tenter de retrouver une fonctionnalité d'affichage retirée ou non prise en charge, et n'inventez ni noms alternatifs, ni relations d'éditeur, ni point d'accès de recherche. Les données structurées doivent clarifier des faits existants ; elles ne peuvent pas compenser un contenu faible, des pages inaccessibles ou une configuration canonique confuse.
Modéliser l'entité WebSite avec soin
Partez de la page d'accueil que les internautes et les robots atteignent réellement après les redirections. Relevez son URL canonique finale, le nom du site visible, tout nom alternatif visible, et la relation avec une Organization seulement si les deux décrivent la même entité publique. Un graphe WebSite ne doit pas répéter un autre hôte, un nom de préproduction ou une ancienne identité juridique simplement parce que ces valeurs subsistent dans un réglage du CMS. Des identifiants stables valent mieux qu'un graphe volumineux aux nœuds contradictoires.
{ "@context": "https://schema.org", "@type": "WebSite", "name": "Example", "url": "https://example.test/" }Inspectez le HTML rendu plutôt qu'un aperçu de l'éditeur. Analysez chaque script JSON-LD, listez les @id, @type, name, url, alternateName et les liaisons vers les nœuds Organization ou WebPage, puis comparez ces champs aux faits visibles de la page. Les outils de validation détectent les problèmes de syntaxe ou de vocabulaire, mais ils ne peuvent pas savoir si un ancien nom de site, une URL périmée ou une promesse non prise en charge reflète l'activité réelle de l'entreprise.
Testez le graphe sur la page d'accueil, sur les variantes linguistiques et sur les principaux gabarits. Les données au niveau du site sont souvent injectées globalement : une modification peut dupliquer un nœud ou attribuer à chaque langue une URL contradictoire. Si les sites régionaux ou linguistiques sont des entités distinctes, documentez volontairement cette relation au lieu de recopier sans changement une seule déclaration WebSite. Vérifiez que les URL canoniques du graphe se résolvent directement et de façon cohérente.
N'ajoutez pas une propriété simplement parce qu'un vieux tutoriel prétend qu'elle déclenche une fonctionnalité de recherche. Schema.org définit le vocabulaire, tandis que Google documente séparément les fonctionnalités de données structurées qu'il prend en charge actuellement, et peut les modifier. Une entité WebSite valide peut améliorer la cohérence lisible par les machines, mais elle ne garantit ni l'affichage du nom du site, ni les liens annexes (sitelinks), ni aucune autre amélioration de la recherche.