« A standard way for developers to add front-end interactivity to the blocks » — c’est ainsi que la documentation officielle de l’Interactivity API, stabilisée dans WordPress 6.5 en avril 2024, décrit son objectif. Concrètement, elle permet à un bloc de mettre à jour son contenu ou son état côté client, sans recharger la page ni dépendre d’un framework JavaScript externe, via un système de directives déclaratives posées directement dans le balisage HTML du bloc.
Pour un développeur habitué à raisonner en SEO classique, la question qui se pose immédiatement est celle du rendu : si une partie du contenu change après le chargement initial de la page, qu’est-ce que Google voit réellement au moment de l’indexation ? La réponse dépend d’une distinction essentielle entre ce qui est présent dans le HTML servi au premier chargement, et ce qui n’apparaît qu’après une interaction ultérieure de l’utilisateur.
Ce que contient le rendu initial
Contrairement à une application JavaScript classique où le contenu est injecté après exécution du script, un bloc utilisant l’Interactivity API rend son état initial côté serveur, en PHP, exactement comme n’importe quel bloc WordPress traditionnel. Le HTML complet, avec le contenu affiché par défaut, est donc bien présent dans la réponse initiale du serveur et parfaitement visible pour Googlebot sans exécution de JavaScript.
Ce qui change, c’est ce qui se passe après : une directive comme data-wp-on--click ou data-wp-bind permet de modifier dynamiquement une portion du DOM en réponse à une interaction, en s’appuyant sur un état partagé défini via wp_interactivity_state() côté PHP et synchronisé côté client. Cette modification n’a lieu qu’après une action de l’utilisateur — un clic sur un filtre, un changement d’onglet — et n’est donc jamais présente dans le rendu initial servi au robot d’indexation.
Où se situe le vrai risque pour l’indexation
Le risque n’est donc pas que Googlebot rate du contenu qui existait déjà au chargement, mais qu’un développeur place par erreur du contenu important — un prix, une disponibilité, un texte central de la page — exclusivement derrière une interaction nécessaire pour l’afficher, en pensant que « c’est juste de l’interactivité » sans réaliser que ce contenu ne fait alors jamais partie du HTML initial exploitable par un robot qui n’exécute pas systématiquement toutes les interactions possibles.
Un exemple concret : un bloc d’onglets construit avec l’Interactivity API qui n’affiche dans le rendu initial que le contenu du premier onglet, les autres n’étant générés qu’au clic sur leur libellé respectif. Si les onglets suivants contiennent des informations uniques et importantes, elles restent invisibles pour l’indexation classique, exactement comme cela aurait été le cas avec n’importe quelle solution d’onglets en JavaScript avant l’Interactivity API. Le problème n’est pas nouveau, l’API ne fait que le déplacer vers un nouveau mécanisme.
Vérifier ce qui est réellement servi au premier chargement
La vérification la plus fiable consiste à récupérer le HTML brut renvoyé par le serveur, avant toute exécution de JavaScript, et à confirmer que le contenu essentiel y figure déjà :
curl -s https://exemple.fr/produit/ | grep -A 5 'data-wp-interactive'Si le contenu jugé important n’apparaît que dans une structure vide en attente d’hydratation, avec des attributs data-wp-bind pointant vers un état qui ne se peuple qu’après interaction, c’est le signal qu’il faut revoir l’implémentation pour que la valeur par défaut soit déjà présente côté serveur.
Ce que cela ne change pas
- La logique de crawl et d’indexation de Googlebot reste identique à celle appliquée aux autres blocs WordPress
- Le SSR du bloc reste géré en PHP, comme n’importe quel bloc dynamique enregistré via
register_block_type - L’accessibilité de ces blocs pour les technologies d’assistance est un sujet distinct, non traité ici, qui mérite un audit séparé
En résumé
L’Interactivity API ne change pas fondamentalement la manière dont WordPress est indexé : le rendu initial reste du HTML classique généré côté serveur, seule la couche de mise à jour ultérieure passe par un nouveau mécanisme côté client. La vigilance à avoir porte uniquement sur le contenu qu’un développeur pourrait, par erreur d’implémentation, réserver exclusivement à un état atteint après interaction, et qui deviendrait alors invisible pour l’indexation au même titre que n’importe quel contenu chargé dynamiquement avant l’arrivée de cette API.
