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.
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 d'indexation, 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. La soumission via sitemap.xml et le ping classique n'aident pas — Google et Bing ne s'y précipitent plus depuis longtemps. La seule façon de demander une indexation prioritaire en temps réel, c'est de passer par les APIs officielles de soumission directe.
Google Indexing API — comment ça marche
Google expose un point de terminaison REST officiel à 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, et c'est tout. Le module signe un JWT RS256 avec la clé privée du Service Account, é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 quota par défaut est de 200 URLs par jour par compte de service, ce qui couvre la grande majorité des boutiques. Google peut accorder un quota plus élevé sur demande motivée. À noter : Google a officiellement limité l'usage de cette API aux pages comportant des données structurées JobPosting ou BroadcastEvent. L'API accepte toutefois les autres types et répond 200, mais Google peut ignorer l'indexation finale — le module soumet quand même, à toutes fins utiles, et le dashboard reflète la réponse de l'API, pas la décision finale d'indexation.
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). 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 à indexer. 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.
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 — si le produit est actif, l'URL est enfilée en URL_UPDATED, sinon en URL_DELETED. actionProductDelete est appelé à la suppression définitive — 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) est 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.
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.
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é. Vous voyez d'un coup d'œil si l'indexation tourne et où ça coince le cas échéant.
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.
Cas d'usage typiques
Boutique en croissance avec 50 nouveaux produits par semaine : le module enfile chaque création, le CRON soumet à Google et IndexNow dans les 10 minutes — vos nouveaux produits sont en SERP en quelques heures au lieu de quelques jours. Boutique multilingue avec catalogue de 5000 produits : à chaque modification de fiche, les URLs canoniques de toutes les langues sont enfilées et soumises — vous bénéficiez du gain SEO 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.
Limites connues et bonnes pratiques
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. Le module ignore donc les jobs IndexNow en URL_DELETED (Google les soumet bien, lui, qui supporte ce type d'action). Le quota Google est plafonné à 200 URLs par jour par Service Account par défaut — pour une boutique qui modifie plus que ça, il faut soit demander une augmentation à Google, soit créer un deuxième Service Account avec son propre quota. Le module ne soumet pas les variantes ou déclinaisons de produits — l'URL canonique du produit principal suffit pour Google qui 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.