Faut-il utiliser les données structurées Product ou LocalBusiness pour un site de services ?

Quelle est la recommandation officielle de Google pour les sites de services ?

Google recommande explicitement d'utiliser les données structurées LocalBusiness pour les sites proposant des services, et non les données structurées Product. Cette position peut sembler surprenante car Schema.org, l'organisme de référence pour les données structurées, suggère pourtant que Product peut être utilisé pour décrire des services.

La recommandation de John Mueller concerne particulièrement les services à tarification variable, c'est-à-dire ceux nécessitant un devis personnalisé. Pour ces cas, Google préconise d'indiquer une fourchette de prix dans le markup LocalBusiness plutôt que d'utiliser les propriétés de Product.

Pourquoi cette distinction entre Product et LocalBusiness est-elle importante ?

Google a développé des affichages enrichis spécifiques pour chaque type de données structurées. Les résultats enrichis pour les produits affichent des informations de e-commerce (stock, prix fixe, avis), tandis que LocalBusiness met en avant la dimension locale et relationnelle des services.

Cette distinction permet à Google de mieux comprendre la nature de votre activité et d'afficher vos pages dans les contextes les plus pertinents, notamment dans les résultats de recherche locale et Google Maps.

Quels sont les points essentiels à retenir de cette déclaration ?

• Privilégier LocalBusiness pour les sites de services, même si Schema.org suggère Product
• Utiliser la propriété priceRange pour indiquer une fourchette tarifaire approximative
• Éviter les données structurées Product qui sont conçues pour le e-commerce de biens physiques
• Suivre les recommandations de Google plutôt que l'interprétation large de Schema.org
• Cette approche est particulièrement pertinente pour les services nécessitant un devis personnalisé

Cette recommandation est-elle cohérente avec les pratiques observées sur le terrain ?

Sur le terrain, de nombreux sites de services utilisent effectivement les données structurées Product sans observer de pénalités visibles. Google ne sanctionne généralement pas cette pratique, mais l'absence de résultats enrichis peut être un signal que le moteur ne valorise pas ce markup.

Les sites qui ont migré vers LocalBusiness constatent souvent une meilleure visibilité dans les recherches locales et une présence renforcée dans le Knowledge Panel. Cette cohérence sémantique aide Google à mieux contextualiser l'activité.

Quelles nuances faut-il apporter à cette règle ?

Il existe une zone grise pour les services standardisés vendus en ligne de manière transactionnelle. Par exemple, un service de création de logo à prix fixe avec paiement immédiat peut légitimement être considéré comme un produit dématérialisé.

De même, les plateformes de réservation en ligne proposant des prestations à prix fixe (cours, consultations) peuvent bénéficier d'un markup hybride, combinant Service avec des éléments d'Offer pour la dimension transactionnelle.

Dans quels cas cette règle pourrait-elle évoluer ?

Google pourrait à terme assouplir sa position si Schema.org renforce sa définition du type Product pour inclure explicitement les services dématérialisés. L'évolution des usages en ligne, avec la croissance du commerce de services digitaux, pourrait influencer cette position.

Il est également possible que Google développe un nouveau type de données structurées spécifiquement dédié aux services en ligne, permettant de mieux capturer leurs spécificités (tarification variable, personnalisation, dimension conseil).

Que faut-il faire concrètement pour mettre son site en conformité ?

Commencez par un audit de vos données structurées actuelles pour identifier tous les usages du type Product appliqués à des services. Utilisez l'outil de test des résultats enrichis de Google pour vérifier comment vos markups sont interprétés.

Remplacez ensuite vos implémentations Product par LocalBusiness ou Service selon votre contexte. Pour une entreprise locale proposant des services, LocalBusiness est le choix prioritaire. Ajoutez la propriété priceRange avec une indication comme "€€" ou "50-200€" pour donner une idée tarifaire.

N'oubliez pas d'enrichir votre markup avec les propriétés complémentaires : areaServed pour votre zone géographique, openingHours pour vos horaires, et review pour les avis clients.

Quelles erreurs éviter lors de cette migration ?

Ne supprimez pas brutalement toutes vos données structurées Product sans les remplacer. Une absence totale de markup est pire qu'un markup imparfait. Procédez progressivement, en testant vos modifications sur quelques pages pilotes.

Évitez également de mélanger Product et LocalBusiness pour décrire la même entité sur une même page. Cette redondance crée de la confusion sémantique et dilue la clarté de votre signal.

• Ne pas indiquer de prix fixes si vos tarifs varient selon les besoins clients
• Ne pas utiliser les propriétés spécifiques au e-commerce (availability, sku, gtin)
• Ne pas oublier de mettre à jour le sitemap et de redemander une indexation
• Ne pas négliger les données structurées sur les pages de services individuels

Comment vérifier que la mise en œuvre est correcte et efficace ?

Utilisez systématiquement le validateur de données structurées de Google et le test des résultats enrichis. Ces outils détectent les erreurs de syntaxe et vous indiquent si vos markups sont éligibles aux affichages enrichis.

Surveillez ensuite vos performances dans Google Search Console, notamment la section "Améliorations" qui indique les problèmes détectés sur vos données structurées. Suivez également l'évolution de votre visibilité dans les recherches locales et le Knowledge Panel.

• Valider le markup avec les outils officiels de Google
• Vérifier l'absence d'erreurs dans Search Console
• Contrôler l'affichage dans les SERP après quelques semaines
• Monitorer les impressions et clics sur les pages modifiées
• Tester sur mobile où les résultats enrichis sont particulièrement visibles