Tout ce que vous voudriez savoir avant d'installer.
Un regard détaillé sur le fonctionnement de DataFirefly Indexing API — Soumission automatique Google Indexing API et IndexNow (Bing, Yandex, Naver) pour PrestaShop 8 et 9, pourquoi nous l'avons conçu ainsi, et la réflexion derrière les fonctionnalités ci-dessus.
§ 01
Le problème : Googlebot et Bingbot mettent du temps à passer
C'est l'angle mort SEO de toute boutique en croissance. Vous publiez un nouveau produit le lundi matin, et Google ne l'indexe que le jeudi soir. Vous corrigez une faute de frappe dans une fiche, et Bing affiche encore l'ancienne version pendant deux semaines. Pendant tout ce délai, vous perdez du trafic organique, vous perdez des conversions, et vos utilisateurs voient des informations périmées dans les résultats de recherche. Pour une boutique qui publie ou modifie 20 produits par semaine, ce sont des centaines d'URLs en retard d'indexation à tout instant. Le sitemap XML reste indispensable : c'est le canal de découverte officiel, il doit être propre et à jour. Mais il ne donne aucune priorité, et le ping sitemap classique ne sert plus à rien depuis que Google a supprimé son point de terminaison de ping en juin 2023. Pour signaler une modification en quelques minutes plutôt qu'en quelques jours, il faut passer par la soumission directe.
§ 02
Google Indexing API : ce qu'elle fait, et ce qu'elle ne fait pas
Google expose un point de terminaison REST à l'URL indexing.googleapis.com qui accepte des notifications de mise à jour ou de suppression d'URL. L'authentification se fait par compte de service Google Cloud : vous créez un Service Account, vous téléchargez sa clé au format JSON, vous l'ajoutez comme propriétaire de votre propriété Search Console. Le module signe un JWT RS256 avec la clé privée, échange ce JWT contre un jeton d'accès OAuth2 sur oauth2.googleapis.com, met ce jeton en cache 55 minutes, et l'utilise pour authentifier chaque soumission. Le point à connaître avant d'acheter : la documentation Google restreint officiellement cette API aux pages comportant des données structurées JobPosting, ou BroadcastEvent intégré dans un VideoObject. Une fiche produit ou une page catégorie n'entre dans aucun des deux cas. L'API accepte quand même la soumission et répond 200, mais ce 200 signifie seulement que la notification a été reçue : Google reste seul juge du crawl et de l'indexation. Le quota par défaut est de 200 URLs par jour par compte de service, et l'augmentation de quota est réservée aux sites qui utilisent effectivement JobPosting ou BroadcastEvent, donc une boutique ne doit pas compter dessus. Le module soumet, journalise le code retour, et le dashboard reflète la réponse de l'API, pas la décision d'indexation. Si vous cherchez un gain d'indexation mesurable sur un catalogue produit, c'est IndexNow qui le fournit.
§ 03
IndexNow : Bing, Yandex, Naver, Seznam en un seul appel
IndexNow est un protocole ouvert poussé par Microsoft Bing et Yandex en 2021, rejoint depuis par Naver (le moteur dominant en Corée du Sud) et Seznam (le moteur historique en République tchèque). Contrairement à l'API Google, IndexNow n'impose aucune restriction sur le type de page : fiches produits, catégories et pages CMS sont dans son périmètre normal. Le principe : vous générez une clé alphanumérique, vous la publiez à la racine de votre domaine (fichier clé point txt), et vous appelez le point de terminaison api.indexnow.org avec une liste d'URLs. L'appel est gratuit, illimité, et propagé automatiquement vers tous les moteurs participants. Pas de quota, pas de Service Account, pas d'OAuth : juste une clé et un appel HTTP. Le module génère la clé automatiquement à l'installation, propose deux méthodes pour la servir à la racine (récriture point htaccess avec snippet généré, ou fichier physique), et batche les URLs jusqu'à 100 par appel pour économiser les requêtes.
§ 04
Les hooks PrestaShop écoutés
Le module s'accroche aux hooks officiels du cycle de vie des objets PrestaShop. Pour les produits : actionProductSave est appelé à la création et à chaque modification, et si le produit est actif l'URL est enfilée en URL_UPDATED, sinon en URL_DELETED. actionProductDelete est appelé à la suppression définitive, avec URL_DELETED enfilé. Pour les pages CMS : actionObjectCmsAddAfter (création), actionObjectCmsUpdateAfter (modification), actionObjectCmsDeleteAfter (suppression). Pour les catégories : actionCategoryAdd, actionCategoryUpdate, actionCategoryDelete, la racine catégorie (ID 1 et 2) étant ignorée par sécurité. Chaque hook construit l'URL canonique via l'objet Link officiel de PrestaShop, ce qui garantit le respect des préférences SEO friendly URL, des préfixes de langue, et des règles multilingues.
§ 05
La file d'attente : pourquoi et comment
Soumettre synchroniquement à chaque hook serait une double mauvaise idée : la latence ralentirait l'admin (l'appel à Google peut prendre 2 à 5 secondes), et un échec API rendrait inaccessible la sauvegarde du produit. Le module enfile donc chaque soumission dans une table de file d'attente persistante (table df_indexapi_queue) et un CRON traite le lot toutes les quelques minutes. La déduplication est cruciale : si vous modifiez un produit trois fois en une heure, le module reconnaît qu'un job existe déjà pour ce tuple (boutique, type, ID, provider, action) et met simplement à jour son URL et sa date, il n'en crée pas trois. Le verrouillage logique pending vers processing évite le double traitement si deux CRON parallèles tirent du lot en même temps. Et chaque échec incrémente un compteur de tentatives, déclenchant un re-essai automatique au CRON suivant jusqu'à un maximum configurable (5 par défaut). Au-delà, le job passe en erreur et reste consultable dans l'écran File d'attente avec le message exact retourné par l'API.
§ 06
Le journal et le dashboard
Chaque soumission produit une entrée dans la table df_indexapi_log : provider Google ou IndexNow, type et ID d'objet, URL exacte soumise, action URL_UPDATED ou URL_DELETED, code HTTP retourné, indicateur accepté ou refusé, message complet de réponse, et date. L'écran Journal expose ces données dans un HelperList PrestaShop standard avec filtres natifs (provider, code HTTP, accepté), tri, et export CSV. Le Dashboard agrège tout : cinq cartes pour les compteurs par statut de la file d'attente, deux cartes de diagnostic provider (Google Service Account configuré ou non, IndexNow clé et hôte configurés ou non), un tableau du taux d'acceptation sur 30 jours par provider avec coloration sémantique (vert au-dessus de 90, orange entre 60 et 90, rouge en dessous), et un graphique Chart.js des soumissions quotidiennes superposant total soumis et total accepté. À lire comme un indicateur de bonne santé technique des appels API, pas comme une preuve d'indexation.
§ 07
La sécurité du CRON et du fichier clé
Le contrôleur CRON est exposé en frontend sur une URL standard PrestaShop, mais protégé par un jeton aléatoire de 32 caractères généré à l'installation et régénérable en un clic depuis la configuration. Sans le bon jeton, le contrôleur renvoie 403. Trois actions sont supportées : process traite un lot de la file d'attente (à appeler toutes les 5 à 15 minutes par votre CRON d'hébergement), purge supprime les jobs et logs traités au-delà de la rétention configurée (à appeler une fois par jour), et key sert le contenu du fichier clé IndexNow en text/plain pour la récriture point htaccess (protégée par une connaissance préalable de la clé dans le paramètre k). Le snippet point htaccess exact à coller à la racine PrestaShop est généré automatiquement dans la page Configuration avec la clé courante.
§ 08
Cas d'usage typiques
Boutique en croissance avec 50 nouveaux produits par semaine : le module enfile chaque création, le CRON soumet dans les 10 minutes, et Bing, Yandex, Naver et Seznam prennent généralement en compte les nouvelles URLs dans les heures qui suivent. Côté Google, la soumission accélère la découverte sans garantie de résultat. Boutique multilingue avec catalogue de 5000 produits : à chaque modification de fiche, les URLs canoniques de toutes les langues sont enfilées et soumises, sur tous vos marchés simultanément. Boutique B2B avec catalogue technique fréquemment mis à jour (prix, stocks, fiches techniques) : la déduplication évite de spammer les APIs sur les rafales de modifications, un seul job par produit même si vous le modifiez vingt fois dans la journée. Reprise SEO après migration : un bouton « Relancer tous les jobs » dans l'écran File d'attente permet de re-soumettre en masse après avoir résolu un problème de configuration ou de quota.
§ 09
Limites connues et bonnes pratiques
Google réserve officiellement l'Indexing API aux pages JobPosting et BroadcastEvent, ce qui fait d'IndexNow le canal principal du module pour un catalogue produit. Activez IndexNow en priorité, et traitez Google comme un bonus journalisé. IndexNow ne gère pas l'action URL_DELETED : le protocole considère qu'une 404 ou 410 sur l'URL est la bonne façon de signaler une suppression, donc le module ignore ces jobs (Google, lui, supporte ce type d'action). Le quota Google est plafonné à 200 URLs par jour par Service Account, et comme l'augmentation de quota est conditionnée à la présence de balisage JobPosting ou BroadcastEvent, une boutique doit considérer ce plafond comme définitif : restreignez le filtre Google aux nouveautés, ou créez un second Service Account avec son propre quota. Le module ne soumet pas les variantes ou déclinaisons de produits, l'URL canonique du produit principal suffisant puisque Google consolide naturellement les variantes. Et la racine catégorie (ID 1 et 2) est ignorée pour éviter de soumettre des URLs non pertinentes.
Il n’y a pas encore d’avis.