TL;DR Googlebot traite le JavaScript en 3 phases et peut voir un accordéon Elementor si le contenu est dans le HTML servi ou rendu. Les crawlers IA (GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, PerplexityBot) n'exécutent pas le JavaScript : ils ne lisent que le HTML initial. Sans clic, seul l'état par défaut est lisible : premier item d'accordéon ouvert, onglet actif uniquement. Téléchargé ne veut pas dire exécuté. La réponse dépend du moteur : Gemini hérite du rendu Googlebot, ChatGPT non. Ce guide vous donne une méthode de vérification en 5 étapes, à faire vous-même.
On croit souvent que si c'est sur la page, c'est lu. C'est faux. Ce qui se cache derrière un clic, un onglet ou un accordéon fermé n'est pas toujours vu par les robots. Et selon qu'on parle de Google ou d'un modèle d'IA, la réponse change complètement.
Pas de panique : ce n'est pas une question de chance. C'est une question de méthode. Voyons ça ensemble, étape par étape, avec des tests que vous pouvez lancer vous-même.
1. Contenus Elementor et IA : ce qui se passe vraiment quand un robot visite votre page
Il faut d'abord distinguer deux mondes qui ne fonctionnent pas pareil.
D'un côté, Googlebot. Il travaille en 3 phases : le crawl, le rendu, puis l'indexation. Concrètement, il récupère la page, l'exécute dans un navigateur Chromium, puis décide quoi indexer. Bonne nouvelle : toutes les pages qui répondent en HTTP 200 passent en file de rendu, même celles qui dépendent fortement du JavaScript.
De l'autre côté, les crawlers IA. Eux ne font pas ce travail. Ils lisent le HTML initial, celui que le serveur envoie au départ. Point. Ils ne cliquent pas, ils n'exécutent pas le JavaScript.
C'est là que beaucoup se trompent. Un fichier JavaScript peut très bien être téléchargé par un crawler IA, mais rester du texte brut, jamais exécuté. Téléchargé ne veut pas dire exécuté.
Et il y a une nuance importante : tous les moteurs ne se comportent pas pareil. Gemini s'appuie sur l'infrastructure de Googlebot, donc il profite du rendu complet. ChatGPT, Claude ou Perplexity, non.
À retenir Google peut voir un contenu injecté en JavaScript après rendu. Les crawlers IA, eux, ne voient que le HTML initial. Un contenu absent du HTML initial est donc invisible pour ChatGPT, même s'il est parfaitement visible pour un humain.
Les principaux user-agents IA à connaître :
- GPTBot : utilisé par OpenAI pour l'entraînement des modèles.
- OAI-SearchBot : lié à l'apparition dans la recherche ChatGPT.
- ChatGPT-User : déclenché quand un utilisateur demande à ChatGPT de visiter une page.
- ClaudeBot : le crawler d'Anthropic.
- PerplexityBot : le crawler de Perplexity.
2. Onglets, accordéons, toggles : ce qu'un robot voit sans cliquer
Voici le cœur du problème. Un robot ne clique pas. Il ne survole pas. Il ne déplie rien.
Donc il ne voit que l'état par défaut de vos widgets. Et cet état dépend du widget Elementor que vous utilisez.
| Widget | État par défaut | Ce que voit un robot sans clic |
|---|---|---|
| Accordéon | Premier item ouvert, les autres fermés | Le contenu du premier item uniquement |
| Toggle | Tout fermé | Rien du contenu dépliable |
| Onglets | Onglet actif affiché | Le contenu de l'onglet actif seulement |
La conséquence est simple : sans interaction, seul l'état par défaut est lisible. Le reste attend un clic qui ne viendra jamais d'un crawler.
Attention à ne pas confondre deux choses. Un contenu peut être « visible dans le HTML rendu » (donc accessible à Google) tout en étant « absent du HTML initial » (donc invisible pour les IA). C'est exactement le cas d'un accordéon dont le texte est injecté en JavaScript.
Alors, faut-il tout ouvrir par défaut ? Pas forcément. L'idée n'est pas de sacrifier l'expérience utilisateur, mais de garder le contenu critique accessible sans clic. Elementor propose d'ailleurs une option FAQ Schema native sur son widget Accordéon. C'est un levier utile, mais ce n'est pas une garantie : le schema aide à comprendre la structure, il ne remplace pas la présence du texte dans le HTML.
3. Les sections dynamiques et le lazy-loading : le piège documenté
C'est le point le plus concret, et Elementor le reconnaît lui-même : le lazy-loading peut nuire à l'indexation du contenu qui n'est pas chargé.
En clair, si votre texte ou votre image de fond n'arrive qu'après coup, il peut ne jamais être vu. Pour les images de fond, Elementor applique un chargement différé, sauf pour la première.
Et pour les sections chargées en AJAX ? La documentation de l'éditeur ne le précise pas. C'est donc à vous de le vérifier par test, widget par widget.
Restons factuels : ce n'est pas un défaut, c'est un point de vigilance. Voici les signes d'alerte à surveiller :
- Le contenu est absent du code source de la page.
- Une image de fond n'apparaît nulle part dans le code.
- Une section semble vide dans le DOM rendu.
Si vous cochez l'un de ces signes, creusez. C'est souvent là que se cache le contenu que vous croyez publié.
4. La méthode de vérification en 5 étapes (à faire soi-même)
Voici la partie pratique. Faites-la dans l'ordre, et notez vos résultats.
Étape 1 : le code source (Ctrl+U) Objectif : savoir si le texte est dans le HTML initial. Outil : votre navigateur. Action : ouvrez le code source et cherchez le texte d'un onglet ou d'un accordéon fermé. Résultat attendu : si le texte est là, c'est bon signe pour les IA. Erreur typique : chercher dans la page affichée au lieu du code source.
Étape 2 : comparer avec le DOM rendu (DevTools) Objectif : voir ce que Google peut voir. Outil : les outils de développement. Action : inspectez la page et vérifiez si le texte apparaît après rendu. Résultat attendu : s'il apparaît seulement ici, Google peut le voir, mais pas les IA. Erreur typique : conclure trop vite sans comparer les deux.
Étape 3 : tester avec JavaScript désactivé Objectif : simuler un crawler IA. Outil : les réglages de votre navigateur. Action : désactivez le JavaScript et rechargez la page. Résultat attendu : notez ce qui disparaît. Erreur typique : oublier de réactiver le JavaScript après le test.
Étape 4 : les outils Google Objectif : confirmer ce que Google a réellement rendu. Outils : l'URL Inspection Tool (pour voir le HTML rendu) et le Rich Results Test (pour valider votre FAQ Schema). Résultat attendu : vous savez si le contenu est bien pris en compte. Erreur typique : tester une URL qui n'est pas celle que vous croyez.
Étape 5 : logs serveur et test de citation Objectif : vérifier l'impact réel. Action : repérez dans vos logs le passage de GPTBot, OAI-SearchBot ou PerplexityBot. Puis posez une question ciblée dans ChatGPT et Gemini pour voir si votre contenu est cité. Résultat attendu : vous savez si vous êtes lu, pas seulement crawlé.
Checklist récapitulative
- Texte recherché dans le code source (Ctrl+U)
- Comparaison code source / DOM rendu
- Test avec JavaScript désactivé
- URL Inspection Tool consulté
- Rich Results Test passé sur le FAQ Schema
- Logs serveur vérifiés
- Test de citation lancé dans ChatGPT et Gemini
Un dernier rappel : faites un test par widget, pas une fois pour tout le site. Un accordéon peut très bien se comporter différemment d'un onglet.
5. Corriger ce qui doit l'être : les bons réflexes
Une fois le diagnostic posé, place aux actions simples.
Gardez le contenu critique dans le HTML visible. Évitez de tout cacher derrière un clic. Activez le FAQ Schema quand c'est pertinent. Limitez le lazy-loading sur les contenus clés. Structurez en H2 et H3 avec des listes, pour rester lisible dès le premier rendu. Validez votre JSON-LD. Et surveillez votre robots.txt ainsi que votre llms.txt.
Chaque action a un but : être cité, pas seulement indexé. C'est là que le suivi de citations prend tout son sens. Chez Semly, l'approche consiste justement à relier chaque test technique à un indicateur de citation dans les modèles d'IA. Vous ne mesurez pas une impression, vous mesurez une présence réelle dans les réponses.
À ne pas rater Ne bloquez pas Googlebot par erreur : une URL bloquée peut malgré tout rester indexée si d'autres pages la lient. Et rappelez-vous que Google-Extended ne contrôle pas les AI Overviews. Le vrai levier passe par Googlebot et le robots.txt.
6. Les erreurs fréquentes et comment les corriger
- Croire que « téléchargé = lu » → corrigez en vérifiant le HTML initial, pas seulement le rendu.
- Tester une seule fois pour tout le site → refaites le test widget par widget.
- Confondre Gemini et ChatGPT → gardez en tête que Gemini hérite du rendu Googlebot, pas ChatGPT.
- Oublier le lazy-loading → vérifiez vos images de fond et vos sections différées.
- Bloquer un crawler par robots.txt sans le vouloir → relisez votre fichier avant de publier.
- Se fier au rendu visuel au lieu du code source → ouvrez toujours le code source en premier.
7. Et ensuite ?
Le test n'est pas une case à cocher une fois pour toutes. C'est un réflexe à garder.
- Refaire le test après chaque refonte ou changement de thème.
- Tester d'autres widgets, pas seulement les accordéons et les onglets.
- Suivre vos citations dans le temps, pour voir si la tendance bouge.
Si le contenu critique reste invisible malgré tout, il existe des variantes comme le pré-rendu ou le SSR. Et si votre site est très dynamique, avec un contenu majoritairement généré côté client, une autre approche sera parfois plus adaptée.
Dans tous les cas, gardez un œil sur le suivi : Semly vous aide à voir comment votre marque apparaît réellement dans les réponses de ChatGPT, Gemini et Google AI, et à comparer avec la concurrence. Tester, c'est bien. Mesurer, c'est mieux.
