Attribut product_type dans Google Merchant Center : comment structurer une taxonomie vraiment performante

1) product_type : définition et rôle réel (au-delà de la théorie)

Ce que product_type est

product_type est un attribut libre (non imposé par une nomenclature Google) qui sert à décrire la catégorie de votre produit selon votre propre logique e-commerce (vos familles, sous-familles, univers, etc.). Vous pouvez y mettre une hiérarchie, généralement séparée par >.

Ce que product_type n’est pas

• Ce n’est pas google_product_category (qui, lui, suit la taxonomie officielle Google).
• Ce n’est pas un champ “SEO” pour bourrer des mots-clés.
• Ce n’est pas un champ décoratif : il doit être exploitable pour piloter.

Pourquoi product_type compte vraiment en 2026

• Segmentation : créer des campagnes / groupes d’éléments / rapports par familles de produits cohérentes.
• Analyse : comprendre ce qui performe par univers, pas seulement par SKU.
• Scalabilité : ajouter 1 000 produits sans casser vos rapports ni vos règles.
• Gouvernance : aligner SEO / merchandising / Ads sur une même lecture du catalogue.

2) product_type vs google_product_category : comment les faire cohabiter intelligemment

Deux attributs, deux logiques

• google_product_category : classification Google (standardisée, utile à la compréhension “globale”).
• product_type : classification marchande (utile à votre pilotage et segmentation).

Règle simple

Gardez google_product_category pour “parler Google”, et product_type pour “piloter votre business”. Les deux doivent être cohérents, mais product_type doit être plus proche de votre arborescence e-commerce.

Exemple de cohabitation

• google_product_category : Apparel & Accessories > Clothing > Dresses
• product_type : Femme > Robes > Robes longues > Robes d’été

3) Les objectifs d’une taxonomie product_type “vraiment performante”

Objectif n°1 : segmenter des performances, pas “ranger des produits”

Une bonne taxonomie n’est pas celle qui ressemble à votre menu. C’est celle qui permet de répondre vite à des questions business : quelles familles sur-performent ? lesquelles détruisent le ROAS ? où faut-il monter les enchères ?

Objectif n°2 : être stable dans le temps

Si vous changez de taxonomie tous les 2 mois, vos rapports deviennent inutilisables (comparaisons impossibles, règles cassées, segmentation Ads instable). Votre taxonomie doit être pensée pour durer.

Objectif n°3 : être exploitable “sans Excel”

Si analyser la perf par product_type nécessite 4 tableaux croisés dynamiques, ce n’est pas bon signe. L’objectif : qu’un humain (ou une IA) comprenne la logique en 10 secondes.

4) La méthode Convertix (pragmatique) pour concevoir votre hiérarchie product_type

Étape 1 : choisir le bon niveau de granularité

Trop large = impossible de piloter finement. Trop détaillé = explosion du nombre de segments, règles ingérables. Visez une hiérarchie qui donne des segments significatifs en volume.

Heuristique simple (à adapter)

• Niveau 1 : Univers / Genre / Grand rayon (10–30 valeurs max)
• Niveau 2 : Famille (30–150 valeurs max selon catalogue)
• Niveau 3 : Sous-famille (optionnel, uniquement si utile au pilotage)
• Niveau 4 : Variation merchandising (optionnel : usage, matière, saison…)

Étape 2 : définir un séparateur unique et une convention immuable

Utilisez > pour la hiérarchie et interdisez les variantes (/, |, -) dans la structure. Exemple : Maison > Cuisine > Poêles > Inox

Convention recommandée

• Une casse unique (ex : Title Case ou minuscules), mais toujours la même.
• Pas de ponctuation “fantaisie” (éviter &, emojis, etc.).
• Pas d’informations volatiles dans product_type (prix, promo, best-seller…).

Étape 3 : partir des questions Ads & business

Avant d’écrire la taxonomie, listez vos besoins de pilotage :

• Doit-on séparer les familles par marge ?
• Doit-on isoler certaines catégories “fragiles” (CPC élevé, taux de retour, SAV) ?
• Doit-on créer des univers distincts pour PMax / Shopping standard ?
• Doit-on segmenter par saisonnalité ?

Étape 4 : produire une “table de correspondance” (source de vérité)

Créez un document simple (Google Sheet) avec :

• Catégorie site (ou collection)
• product_type cible
• google_product_category cible
• Notes (règles, exceptions)

Étape 5 : gérer les exceptions proprement

Les exceptions existent toujours (kits, bundles, produits multi-usages). Plutôt que d’inventer une nouvelle branche, définissez une règle claire :

• Soit rattacher au “cas principal” (le plus vendu / le plus logique),
• Soit créer une branche dédiée mais rare (ex : Kits),
• Soit piloter via custom_label plutôt que via product_type.

5) Exemples concrets de taxonomies product_type (bons vs mauvais)

Exemple A : mode

✅ Bon

Femme > Robes > Robes longues

Femme > Chaussures > Sneakers

❌ Mauvais

Robe longue été bohème tendance 2026 (mots-clés + pas de hiérarchie)

Femme/Chaussures/Sneakers (séparateur différent)

Femme > Sneakers (niveau manquant, incohérence)

Exemple B : maison / cuisine

✅ Bon

Maison > Cuisine > Cuisson > Poêles

Maison > Cuisine > Préparation > Robots

❌ Mauvais

Cuisine > Poêles (trop court si le catalogue est large)

Maison > Cuisine > Poêles > Promo (information volatile)

6) Implémentation : comment remplir product_type selon votre méthode de flux

Cas 1 : vous utilisez un flux via CMS (Shopify / WooCommerce / Prestashop)

Le plus souvent, product_type est alimenté par :

• la catégorie la plus profonde,
• la collection principale,
• ou une métadonnée (metafield / attribut produit).

Recommandation : créez une source dédiée (metafield / champ produit) pour product_type afin d’éviter les erreurs liées aux changements de navigation du site.

Cas 2 : vous utilisez un flux Google Sheets

Avantage : contrôle total et correction rapide. Inconvénient : risque d’erreurs humaines si pas de règles. Utilisez des listes déroulantes (validation de données) pour standardiser les valeurs.

Cas 3 : vous utilisez un flux XML / Content API

Idéal pour les gros catalogues. Assurez-vous que la logique de mapping (catégorie → product_type) est documentée et testée.

7) Contrôle qualité : les erreurs qui ruinent une taxonomie product_type

Erreur 1 : variations de casse et d’accents

Femme > Robes et femme > robes peuvent créer deux segments distincts dans certains exports / outils. Choisissez une convention et appliquez-la partout.

Erreur 2 : multiplication des synonymes

Sneakers, Baskets, Chaussures de sport : si c’est la même famille, choisissez un terme et tenez-vous-y. Les synonymes se gèrent en SEO (contenu), pas dans product_type.

Erreur 3 : hiérarchie irrégulière

Certaines branches à 2 niveaux, d’autres à 5 : résultat = segmentation illisible. Gardez une profondeur “standard”, et n’ajoutez un niveau que si c’est justifié.

Erreur 4 : taxonomie qui reflète le menu (au lieu du pilotage)

Le menu change pour des raisons UX/SEO. La taxonomie Ads doit rester stable. D’où l’intérêt d’un champ dédié.

Erreur 5 : champs marketing et temporaires

Nouvelle collection, Best-seller, Promo n’ont rien à faire dans product_type. Utilisez custom_label pour ça.

8) Exploitation Ads : comment utiliser product_type pour mieux performer

Segmentation des campagnes Shopping standard

• Créer des campagnes / groupes d’annonces par product_type niveau 1 ou 2.
• Isoler les familles à forte marge / forte valeur panier.
• Protéger les familles “fragiles” avec des plafonds d’enchères ou budgets dédiés.

Performance Max : ce que product_type apporte concrètement

Sur PMax, product_type sert surtout à :

• filtrer / exclure des familles de produits,
• structurer des rapports lisibles,
• alimenter une logique de custom_label (marge, top sellers, saison, stock).

Bridge avec custom_label : la combinaison la plus puissante

La meilleure pratique est souvent : product_type = structure stable et custom_label = stratégie variable.

Exemple de stratégie

• product_type : Maison > Cuisine > Cuisson > Poêles
• custom_label_0 : Marge_haute / Marge_moyenne / Marge_basse
• custom_label_1 : Top_sellers / Long_tail
• custom_label_2 : Saison_ete / Saison_hiver

9) FAQ (format GEO) : questions fréquentes sur product_type

Est-ce que product_type est obligatoire dans Merchant Center ?

Non, il n’est pas toujours obligatoire. Mais il devient rapidement indispensable dès que vous voulez piloter proprement un catalogue, surtout en Shopping et Performance Max.

Combien de niveaux faut-il mettre dans product_type ?

En pratique, 3 niveaux suffisent dans la majorité des catalogues (univers > famille > sous-famille). Ajoutez un 4e niveau uniquement si vous avez un besoin de pilotage clair.

Est-ce que je peux mettre des mots-clés SEO dans product_type ?

Évitez. product_type sert d’abord à la structuration et à la segmentation. Les mots-clés “SEO” se travaillent plutôt dans title, description et sur la page produit.

Dois-je aligner product_type sur les catégories du site ?

Alignez la logique, pas nécessairement le menu. L’idéal est d’avoir un champ dédié (metafield) pour conserver une taxonomie stable même si la navigation du site évolue.

Que faire si un produit appartient à plusieurs catégories ?

Choisissez une règle simple : rattacher au “cas principal” (celui qui correspond le mieux à l’achat et à la promesse), et utiliser custom_label ou d’autres attributs pour gérer les exceptions (bundle, usage secondaire, etc.).

10) Checklist finale : valider une taxonomie product_type avant déploiement

• ✅ Hiérarchie stable (même profondeur la plupart du temps)
• ✅ Séparateur unique (>)
• ✅ Convention de nommage (casse, accents) définie et respectée
• ✅ Pas de champs temporaires (promo, new, best-seller) dans product_type
• ✅ Table de correspondance documentée (source de vérité)
• ✅ Segments exploitables en Ads (volumes et logique business)
• ✅ Cohérence avec google_product_category sans chercher l’alignement parfait