L’arrivée du Speculative Loading en cœur avec WordPress 6.8, en avril 2025, a surtout été commentée sous l’angle de la vitesse. C’est un angle mort qu’on veut combler ici : au-delà du gain perçu par l’utilisateur, cette fonctionnalité a des implications directes sur le SEO technique d’un site, qui méritent d’être comprises avant de l’activer sans y réfléchir.
Comment WordPress génère les règles de spéculation
Le module cœur ajoute, en fin de page, un bloc <script type="speculationrules"> contenant un JSON qui définit quelles URL peuvent être préchargées ou pré-rendues, et sous quelle condition de déclenchement (survol, ou zone visible du viewport). Ces règles sont générées dynamiquement et peuvent être filtrées par du code personnalisé, via le filtre wp_speculation_rules_configuration, ce qui permet par exemple d’exclure certaines URL sensibles (page de connexion, panier, zone de paiement) du périmètre de spéculation.
add_filter( 'wp_speculation_rules_configuration', function ( $configuration ) {
$configuration['mode'] = 'prerender';
$configuration['eagerness'] = 'moderate';
return $configuration;
} );
Premier impact SEO technique : la mesure du trafic
Un point souvent négligé : une page pré-rendue en arrière-plan exécute ses scripts, y compris ceux de mesure d’audience, avant même que l’utilisateur ne clique réellement dessus. Sans précaution, un outil d’analytics peut comptabiliser une page vue qui ne correspond à aucune visite réelle, si le pré-rendu se déclenche puis que l’utilisateur change finalement d’avis. Les navigateurs Chromium exposent l’API document.prerendering ainsi que l’événement prerenderingchange pour permettre aux scripts de différer leur exécution jusqu’à l’activation effective de la page, une précaution que tout script de mesure devrait intégrer.
Deuxième impact : le comportement des robots d’indexation
Les règles de spéculation n’ont aucun effet sur le comportement des robots d’indexation classiques (Googlebot inclus) ni sur celui des robots associés aux moteurs de réponse générative : ces agents ne sont pas des navigateurs pilotés par un utilisateur qui survole des liens, et ils ignorent purement et simplement le bloc speculationrules. Il n’y a donc aucun risque de gaspillage de budget de crawl provoqué par cette fonctionnalité, contrairement à une crainte parfois évoquée par des clients.
Troisième impact : la cohérence avec le cache de page
Un site qui sert des pages différentes selon des règles côté serveur (contenu personnalisé, prix variable, disponibilité en temps réel) doit vérifier que le pré-rendu ne fige pas une version obsolète avant l’affichage réel. Le mode prerender exécute la page en arrière-plan à un instant T ; si son contenu change entre le pré-rendu et l’affichage effectif, l’utilisateur peut voir une information périmée de quelques secondes. Sur les sites avec des prix dynamiques, il est recommandé de rester en mode prefetch, plus prudent, plutôt qu’en prerender.
Tableau de synthèse des deux modes
| Mode | Ce qu’il fait | Risque principal |
|---|---|---|
prefetch | Télécharge la ressource sans l’exécuter | Faible, aucun script exécuté par anticipation |
prerender | Construit la page complète en arrière-plan | Scripts exécutés avant affichage réel, contenu potentiellement figé |
Comment vérifier ce qui est réellement généré sur son site
- Ouvrir le code source d’une page publique et chercher
speculationrules. - Vérifier la liste des URL couvertes et le mode utilisé.
- Confirmer qu’aucune URL sensible (panier, compte, paiement) n’apparaît dans le périmètre.
- Si un outil d’analytics tiers est utilisé, vérifier sa documentation pour la prise en charge de l’événement
prerenderingchange.
Un réflexe simple qu’on recommande : traiter cette fonctionnalité comme n’importe quelle nouveauté cœur qui touche au JavaScript exécuté sur le site, avec la même vigilance qu’on aurait pour un nouveau plugin.
En résumé
Le rendu spéculatif de WordPress 6.8 n’a pas d’effet direct sur l’indexation ou le crawl par les robots, humains ou IA, mais il modifie la façon dont les scripts s’exécutent sur le navigateur d’un visiteur humain. Les équipes SEO gagnent à vérifier la configuration de cette fonctionnalité au même titre qu’elles vérifieraient un changement de balisage, plutôt que de la laisser tourner sans regard sur ses réglages par défaut.
