Nos cinq parcours produit étaient totalement invisibles pour le premier passage
des robots. Pas mal classés : absents. Chaque nom de produit, chaque titre de
bénéfice et chaque description était récupéré depuis un point d'accès interne
après le chargement de la page, puis écrit dans le DOM avec innerHTML. Le HTML
que recevait un robot ne contenait donc qu'une seule chaîne pertinente :
Loading Platform Architecture....
Nous avons reconstruit le site pour que le contenu soit rendu côté serveur. Voici ce que nous avons constaté.
L'échec était mesurable, et il valait zéro
La vérification tient en une commande :
curl -s https://archmir.com/platform/expertarch | grep -c "Expert Level Reasoning Layer"
Avant la refonte, elle renvoyait 0. La page avait un titre, une description et
des balises Open Graph, toutes injectées côté serveur par substitution de texte
dans un gabarit, mais aucun corps de page. Les métadonnées décrivaient une page
dont le contenu n'existait pas tant que JavaScript n'avait pas été exécuté.
Cela pèse plus lourd qu'avant. Googlebot indexe en deux passes : la première lit le HTML brut, et tout ce qui exige JavaScript est mis en file d'attente pour le Web Rendering Service, où l'attente peut durer des heures ou des semaines. Les robots qui n'exécutent jamais JavaScript, dont ceux qui génèrent les aperçus sur les réseaux sociaux et un nombre croissant d'agents de recherche IA, ne voient jamais le contenu.
Ce que nous avons changé
Le contenu est passé d'une requête côté client à des Server Components. Le comportement interactif est resté, mais il s'attache désormais à un balisage déjà présent dans le HTML au lieu de le créer.
| Avant | Après |
|---|---|
Catalogue récupéré depuis /api/content/platform, injecté avec innerHTML | Rendu par le serveur ; présent dans le HTML initial |
Pages produit construites à l'exécution par une fonction _renderIsolationMode() | Générées statiquement à la compilation, un fichier par produit et par langue |
Langue changée par un paramètre de requête ?lang= | Des chemins distincts et indexables, reliés par hreflang |
| Une seule image Open Graph pour toutes les URL | Une carte générée par route |
La hiérarchie des titres commençait en h3, sans h2 au-dessus | Un seul h1, puis une véritable hiérarchie h2/h3 |
Les parties interactives — changement d'onglet, révélations au défilement, lecture vidéo et formulaire de contact — sont des composants client montés par-dessus un balisage rendu côté serveur. L'utilisateur n'y perd rien.
Trois choses qui n'allaient pas de soi
Cacher du contenu derrière opacity: 0 est un vrai risque. Nos animations au
défilement rendent chaque section invisible au départ et la révèlent en
JavaScript. Googlebot exécute JavaScript et finirait par la voir, mais un client
sans JavaScript verrait une page blanche. Un bloc <noscript> qui neutralise
l'animation ne coûte rien et supprime entièrement ce mode de défaillance.
Bloquer une URL dans robots.txt ne la retire pas de l'index. Nous avions
prévu d'interdire les anciennes URL en ?lang=. C'eût été l'inverse de ce qu'il
fallait faire : une URL qu'un robot ne peut pas demander est une URL dont il ne
découvrira jamais la redirection, et l'ancienne adresse serait donc restée
indexée indéfiniment. Pour qu'une redirection fonctionne, elle doit être
explorable.
Les robots d'IA attendent une invitation explicite. Google-Extended et
Applebot-Extended sont des jetons de retrait pour l'ancrage des systèmes d'IA.
Ne rien dire, c'est laisser la décision à une valeur par défaut. Si vous voulez
que votre documentation soit accessible aux moteurs génératifs, listez-les sous
Allow.
La part qui ne s'automatise pas
La stratégie de rendu, les données structurées et les Core Web Vitals sont des problèmes d'ingénierie, et les problèmes d'ingénierie ont des solutions déterminables. Ce qu'aucun d'eux ne remplace, c'est le fait d'avoir quelque chose de précis et de vérifiable à dire. C'est pourquoi les chiffres de cet article sont ceux que nous avons mesurés sur notre propre site, et non des références citées de quelqu'un d'autre.