# WooCommerce 8.0 : ce que change la nouvelle passerelle pour le suivi SEO

> Pour un développeur SEO e-commerce qui doit suivre les conversions après un changement de structure de commande. Les changements classés par impact réel sur le tracking existant.

- Auteur : WordPress Développement
- Publié le : 2023-01-22
- Mis à jour le : 2023-01-22
- Catégorie : SEO & GEO
- URL : https://www.wpmoderne.fr/seo/woocommerce-8-0-passerelle-suivi-seo/

## L’essentiel

- Le tunnel de commande change de structure d'URL
- Les événements de conversion ne se déclenchent plus au même moment
- Trois vérifications avant mise en production

Face à une montée de version majeure de WooCommerce, la tentation est de ne regarder que le changelog du cœur du plugin et de considérer que le suivi SEO n'est pas concerné. C'est une erreur récurrente : chaque refonte du tunnel de commande touche potentiellement au moment et à la manière dont les événements de conversion se déclenchent, avec des conséquences directes sur l'attribution du trafic organique.

Voici, classés par impact réel sur le tracking existant, les points à revalider systématiquement lors d'une telle montée de version — indépendamment du numéro exact — sur un site e-commerce dont le référencement dépend d'une mesure fiable des conversions par canal.

## Impact fort : la structure d'URL du tunnel de commande

Le premier point à vérifier est la structure d'URL des étapes du tunnel : panier, commande, paiement, confirmation. Une modification de gabarit peut faire apparaître un nouveau paramètre d'URL ou changer le fragment d'ancrage utilisé pour distinguer les étapes d'un formulaire en une seule page. Si l'extension SEO du site applique une balise `noindex` conditionnelle sur ces pages via une règle basée sur le chemin d'URL, un changement de structure peut la rendre inopérante du jour au lendemain — et exposer des pages de paiement à l'indexation.

La vérification se fait simplement en repassant Screaming Frog sur les URL de test du tunnel après la montée de version, filtré sur la directive `robots` :

```
wp option get woocommerce_checkout_page_id
curl -s -I https://exemple.test/commande/ | grep -i "x-robots-tag"
```

## Impact fort : le moment de déclenchement de l'événement de conversion

> L'essentiel à retenir : Le tunnel de commande change de structure d'URL ; Les événements de conversion ne se déclenchent plus au même moment ; Trois vérifications avant mise en production

Le second point concerne le moment exact où l'événement de conversion (achat validé) se déclenche côté navigateur. Certaines versions de WooCommerce déplacent la logique de confirmation de commande d'un rendu classique côté serveur vers un appel asynchrone en AJAX, pour accélérer l'affichage de la page de remerciement. Si le script de mesure (balise Analytics, pixel publicitaire) est injecté dans le gabarit de la page de confirmation en dur, et que cette page se charge désormais avant que le statut de la commande ne soit confirmé côté serveur, l'événement peut se déclencher sur des commandes annulées ou en attente de paiement.

Le test consiste à passer une commande de test avec un moyen de paiement qui échoue volontairement, et à vérifier dans la console réseau du navigateur qu'aucun événement de conversion n'est envoyé tant que le statut de la commande n'est pas passé à « terminée » ou « en cours » :

- Commande payée avec succès : l'événement doit se déclencher une seule fois.
- Paiement refusé : aucun événement de conversion ne doit partir.
- Rechargement manuel de la page de confirmation : l'événement ne doit pas se dupliquer.

## Impact modéré : les hooks utilisés par les extensions tierces

Un changement de version peut aussi déplacer ou renommer certains hooks internes utilisés par des extensions tierces de tracking, comme les intégrations directes avec des plateformes publicitaires. Le hook `woocommerce_thankyou` reste stable historiquement et sert de point d'ancrage fiable pour la plupart des intégrations maison, contrairement aux hooks plus récents liés à l'API de blocs de paiement, encore sujets à évolution.

```
add_action( 'woocommerce_thankyou', function( $id_commande ) {
    $commande = wc_get_order( $id_commande );
    if ( $commande->has_status( 'processing' ) || $commande->has_status( 'completed' ) ) {
        // envoi de l'événement de conversion
    }
});
```

## Impact faible : les libellés d'état de commande affichés

Enfin, un changement de libellé d'état de commande (le passage de « En cours » à un intitulé différent dans l'interface) n'a en général aucun effet sur le tracking lui-même, à condition que le code sous-jacent (`has_status()`) continue de reposer sur les slugs internes des statuts plutôt que sur leurs libellés traduits. C'est un point de vigilance à vérifier une seule fois, rarement une source réelle de régression.

> Sur nos projets e-commerce, chaque montée de version majeure de WooCommerce déclenche automatiquement une commande de recette avec un moyen de paiement en échec — c'est le test le plus révélateur pour repérer une régression de tracking silencieuse.

## Notre verdict

Le tracking des conversions sur WooCommerce est plus fragile qu'il n'y paraît face aux montées de version : la structure d'URL du tunnel, le moment de déclenchement de l'événement et les hooks utilisés par les intégrations tierces sont les trois points qui méritent une revalidation systématique, avant même de regarder le reste du changelog. Un scénario de commande en échec, rejoué à chaque montée de version majeure, reste le test le plus fiable pour détecter une régression avant qu'elle ne fausse des semaines de données d'attribution.