Quand utiliser le schema WebSite pour décrire un site web ?

Par l’équipe Limpi. Les faits externes sont distingués des méthodes Limpi et aucune visibilité, position ou citation automatique n’est garantie.

Comprendre Schema.org WebSite

Schema.org WebSite représente le site web comme entité, c’est-à-dire un ensemble de pages liées. Il ne faut pas le confondre avec WebPage, qui décrit une page particulière. Cette distinction aide à modéliser correctement ce dont parle chaque nœud structuré.

Inspecter le comportement réellement servi

Examinez le JSON-LD et identifiez les nœuds WebSite, leur @id, url, name et les relations vers l’organisation ou les pages lorsqu’elles existent. Vérifiez que l’URL correspond réellement au site et qu’un même site n’est pas déclaré sous plusieurs identifiants incompatibles.

Distinguer les notions qui se ressemblent

WebSite décrit le site ; WebPage décrit le document courant ; Organization décrit une organisation. Une page d’accueil peut contenir plusieurs entités reliées sans devenir elle-même de type WebSite uniquement parce qu’elle présente le site.

Identifier les causes les plus probables

Les erreurs viennent d’un plugin qui duplique WebSite, d’un @id changeant selon la page, d’une URL avec ou sans slash utilisée de façon incohérente, ou d’un mélange entre nom du site, nom de l’entreprise et titre de la page.

Décider ce qui mérite d’être corrigé en premier

Ajoutez WebSite lorsque vous avez une entité site réelle à représenter et des propriétés fiables. N’ajoutez pas ce type à chaque article comme un décor isolé ; privilégiez un graphe cohérent où les identifiants restent stables.

Corriger à la bonne couche

Choisissez un @id durable, une URL canonique du site et les propriétés effectivement connues. Reliez les autres entités lorsque la relation est vraie. Ne remplissez pas des champs uniquement parce qu’ils existent dans le vocabulaire Schema.org.

Traiter les cas limites sans automatisme

Un domaine peut héberger plusieurs sous-sites ou produits avec des périmètres distincts. Décidez alors quelle entité WebSite chaque page référence. Les versions linguistiques peuvent partager ou séparer certaines propriétés selon l’architecture, sans inventer d’entités artificielles.

Valider la correction sur des cas réels

Validez la syntaxe JSON-LD, inspectez le graphe rendu et vérifiez que WebSite ne remplace pas le WebPage de la page éditoriale. Contrôlez plusieurs gabarits pour détecter des @id différents qui devraient représenter le même site.

Prévenir la régression dans le temps

Centralisez l’entité WebSite dans la couche de données structurées commune et documentez ses identifiants. Les pages spécialisées ne devraient modifier que les relations nécessaires, pas recréer une définition concurrente du site.

Clôturer le contrôle sur Schema.org WebSite

Pour clôturer le contrôle « Quand utiliser le schema WebSite pour décrire un site web ? », conservez une preuve avant/après : URL ou composant testé, constat initial, origine technique, correction appliquée et résultat de la vérification. Contrôlez aussi les pages liées /seo/donnees-structurees, /seo/schema-webpage, /seo/schema-organization-page-accueil afin de vérifier que la correction reste cohérente avec le reste du corpus. Le périmètre documentaire reste volontairement borné : Décrire WebSite comme l’entité représentant un ensemble de pages liées sur un domaine. Ne pas confondre le type du site avec le type WebPage de la page éditoriale Limpi. Si le comportement dépend d’un gabarit, d’un CDN, d’un navigateur ou d’un outil tiers, testez au moins un second cas représentatif. Une anomalie ambiguë doit rester en revue plutôt que d’être fermée sur une hypothèse. Attribuez enfin la règle à une source précise — composant, template, serveur, CMS ou configuration — pour pouvoir la retester après une refonte.

Conserver une preuve exploitable dans l’audit

Un contrôle sur Schema.org WebSite est utile seulement si une autre personne peut reproduire le constat. Enregistrez la réponse ou l’état observé, l’outil utilisé, le contexte de test et l’élément exact qui justifie la conclusion. Évitez les captures isolées sans URL, statut ou propriété mesurée. Pour les anomalies répétées, comptez les occurrences par gabarit avant et après correction. Cette trace permet de distinguer une résolution globale d’un exemple corrigé manuellement et évite de rouvrir le même diagnostic sans information nouvelle. Lorsque la documentation officielle est la borne du contrôle, notez également la source utilisée afin de pouvoir réévaluer la règle si elle évolue.

Tester un scénario représentatif

Imaginez un site éditorial exploité par une société. Le graphe peut contenir un nœud WebSite avec l’URL du domaine et son nom, un nœud Organization pour l’entreprise et un WebPage propre à chaque document. Vérifiez que l’@id du WebSite reste identique sur l’accueil, un article et une page d’aide. Si un plugin génère #website tandis qu’un autre crée /#site avec des noms différents, vous avez deux représentations concurrentes de la même entité. Contrôlez également que le titre de l’article n’est pas recopié comme name du WebSite. Ce scénario clarifie la séparation entre l’ensemble de pages, l’organisation responsable et le document courant, et fournit une convention d’identifiants stable pour le reste du graphe structuré. Le contrôle est terminé lorsque le même site conserve un identifiant WebSite cohérent sur plusieurs gabarits, que son nom n’est pas remplacé par le titre de chaque document et que les relations avec Organization et WebPage restent lisibles dans le graphe rendu. Dans le JSON-LD, inventorie @context, @type WebSite, @id, url, name, alternateName éventuel et relations vers publisher ou potentialAction uniquement si elles sont réellement utilisées. Comparez #website, /#website et autres identifiants générés par plugins. La même entité doit rester reconnaissable sur accueil, article et page institutionnelle. WebPage conserve un @id distinct lié à l’URL du document courant. Vérifiez un sous-domaine documentation.example.com : selon l’architecture, il peut appartenir au même écosystème tout en ayant un WebSite distinct. La décision doit être stable et reflétée dans les @id, plutôt que varier selon le plugin qui génère le JSON-LD sur chaque sous-domaine. Ajoutez url, name, alternateName, inLanguage, publisher, copyrightHolder ou potentialAction uniquement lorsqu’ils ont un sens dans le graphe du site. Vérifiez surtout les identifiants croisés : WebPage isPartOf WebSite, WebSite publisher Organization et Organization url. Des relations stables facilitent la lecture du graphe sans surcharger chaque nœud de propriétés redondantes. Pour approfondir, cartographiez aussi le graphe à l’échelle du domaine : page d’accueil, section blog, centre d’aide, espace documentation et éventuel sous-domaine produit. Notez pour chacun url, @id WebSite, @id WebPage, publisher et breadcrumb. Vérifiez si un moteur de templates ajoute un SearchAction, un potentialAction ou un alternateName uniquement sur certaines routes. Une variation de nom commercial, de protocole, de slash ou de sous-domaine peut créer plusieurs identités difficiles à rapprocher. Conservez une convention d’identifiants indépendante du titre de la page et des paramètres de campagne. Si un site possède plusieurs marques ou environnements, documentez explicitement où commence et où s’arrête chaque WebSite. Cette cartographie de domaine, d’entités parentes, de documents enfants et de relations isPartOf fournit une base beaucoup plus solide qu’un nœud WebSite répété mécaniquement.

Sources officielles

Les règles des moteurs et des fournisseurs de crawlers peuvent évoluer. Les affirmations techniques de cette page sont bornées par les documentations officielles ci-dessous.

• schema website