Générer un flux Google Shopping sur mesure avec Magento 1.9 : retour d’expérience

Flux Google Shopping custom sur Magento 1.9 : ce qu’on a appris

Les extensions du marché couvrent 80 % des cas. Le problème, c’est quand votre catalogue a des produits livrés par transporteur spécialisé sur devis, des EAN stockés dans des attributs custom, des images assignées au scope global plutôt qu’au store view, et des url_key qui ne correspondent plus aux URLs réelles depuis 3 ans. Là, vous codez.

Architecture : fichier statique, pas d’endpoint dynamique

Le module génère un XML dans var/export/googlefeed/feed.xml, via cron quotidien ou URL manuelle. Google crawle à ses propres horaires de toute façon. Un endpoint dynamique sur 2 500 produits, c’est un timeout garanti.

Techniquement : lots de 200 produits, écriture dans un fichier .tmp, puis rename() atomique vers le fichier final. Le flux en prod n’est jamais dans un état partiel, même si la génération plante en cours de route.

Piège n°1 : setStoreId() ne ramène pas tout

Appeler setStoreId() sur la collection Magento pour cibler le bon store view ne garantit pas que tous les attributs remontent. Les attributs de scope Global stockés uniquement sur store_id = 0 reviennent vides s’il n’existe pas de valeur spécifique au store view.

Sur ce projet : le code EAN (gtin13reel) et l’image principale concernés. Fix : un fallback SQL direct sur catalog_product_entity_varchar en store_id = 0 quand la collection retourne vide. Pas glamour, mais fiable.

Piège n°2 : les url_key qui mentent

Magento régénère core_url_rewrite quand un produit est modifié. Il ne met pas à jour url_key si le champ n’est pas explicitement retouché dans le formulaire. Sur un catalogue de plusieurs années, l’écart s’accumule.

Construire les URLs du flux depuis le url_key brut produit des 404 que GMC détecte au crawl de vérification. La solution : lire core_url_rewrite en priorité, url_key en fallback.

Piège n°3 : les machines de 1 200 kg

Trois broyeurs sur remorque, entre 1 000 et 1 400 kg. Envoyer ce poids dans shipping_weight déclenche un refus GMC. Ces machines partent par transporteur spécialisé sur devis, pas en Colissimo.

Fix : seuil à 1 000 kg. Au-dessus, le bloc shipping et le shipping_weight disparaissent du flux. Sans liste de SKUs codée en dur.

transit_time_label n’existe pas

transit_time_label n’est pas un sous-attribut valide de shipping dans le spec Google Shopping, malgré ce que suggèrent certaines docs tierces. GMC le signale comme attribut non reconnu et refuse les produits concernés. Les bons sous-attributs : min_transit_time / max_transit_time pour la livraison, min_handling_time / max_handling_time pour la préparation, en jours ouvrés entiers.

Le mapping de catégories, c’est une question d’ordre

Le module fait correspondre les noms de catégories Magento aux identifiants Google Product Category via un tableau de mots-clés partiels testés dans l’ordre de déclaration. L’ordre est tout : robot avant tondeuse, autoportée avant tracteur, broyeur avant scie. Un seul mauvais placement et vous vous retrouvez avec des tronçonneuses classées en « Caméras de recul ».

Une catégorie par défaut couvre les non-matchs. Google préfère une catégorie approximative à une catégorie absente.

Ce qu’un module standard n’aurait pas géré

• Fallback SQL sur store_id = 0 pour les EAN et les images
• Exclusion du bloc livraison sur critère de poids
• Produits discontinués avec remplaçant : exportés en availability: discontinued avec description enrichie et lien vers le successeur
• Filtrage des SKUs internes (lignes de frais, options de paiement) absents du flux
• Validation EAN : 13 chiffres exacts, nettoyage des valeurs parasites (N/A, 0, tirets)

En chiffres

2 465 produits exportés. 1 487 avec un GTIN valide. Génération en moins de 4 secondes. Les 978 sans EAN ne sont pas un problème de code : ce sont des références sans code fournisseur identifié, à renseigner en back-office.

Vous avez un projet e-commerce qui dépasse les capacités des solutions standard ? Parlons-en.