Le JavaScript SEO désigne l’ensemble des réglages qui rendent visible pour Google un contenu affiché par du code. Ton module de réservation en fait partie. Le moteur explore d’abord le HTML brut, puis rend la page dans un navigateur sans interface, en différé. Entre les deux, ton calendrier peut rester invisible.
Le contenu que Google ne voit pas sur ta page de réservation
Ouvre ta page de réservation, clic droit, « afficher le code source de la page ». Ce que tu lis là, c’est le HTML initial : le document que ton serveur envoie avant la moindre exécution de code. Si ton calendrier, tes prestations et tes tarifs n’y figurent nulle part, c’est qu’ils sont injectés ensuite par du JavaScript.
Rien d’anormal en soi. La quasi-totalité des modules du marché fonctionnent ainsi : un script récupère les créneaux depuis le serveur de l’éditeur, puis les dessine dans ta page. Ton visiteur ne voit aucune différence. Google, si.
La documentation Search Central de Google est explicite : le moteur indexe le HTML rendu, celui qui existe après exécution du JavaScript, pas le document de départ. Encore faut-il que ce rendu ait lieu, qu’il aboutisse et qu’il produise le contenu attendu. Trois conditions, trois occasions de perdre ta page en route.
Le symptôme classique ? Ta page de réservation est bien indexée, mais elle ressort sur son titre et rien d’autre. Aucune prestation, aucune ville, aucun tarif ne remonte. Google connaît l’adresse, pas le contenu. Résultat : elle ne se positionne sur aucune requête métier, alors que c’est précisément la page qui transforme un visiteur en client.
Trois configurations concentrent le problème : le widget d’un éditeur tiers posé sur ton site, l’iframe qui affiche une page hébergée ailleurs, et l’application monopage où toute la navigation se fait sans recharger le document. Chacune casse quelque chose de différent et se répare autrement. Le choix d’architecture compte donc autant que l’outil lui-même, un point détaillé dans le guide pour choisir un système de réservation en ligne.
Exploration, rendu, indexation : trois étapes, pas une
Google ne traite pas une page en JavaScript comme une page en HTML statique. Sa documentation décrit trois phases distinctes, et chacune peut échouer sans que tu en sois averti.
Le rendu arrive après coup
Googlebot récupère d’abord ton fichier HTML, lit les liens présents dans les attributs href et note les adresses à visiter. Si la page répond en code 200, elle rejoint une file d’attente de rendu. Un Chromium sans interface graphique exécute alors le JavaScript, reconstitue la page complète, et c’est ce résultat qui alimente l’index.
Cette file d’attente a longtemps été le cauchemar des sites en JavaScript. Le délai s’est effondré depuis : Martin Splitt, l’ingénieur de Google qui porte ces sujets, annonçait au Chrome Dev Summit 2019 un temps médian de cinq secondes entre l’exploration et le rendu, avec un neuvième décile qui se compte en minutes. Le rendu différé n’est plus une excuse recevable pour une page qui ne ressort jamais.
Ces affirmations ne relèvent pas de la rumeur SEO. Une base indépendante recense, classe et traduit en français les propos des porte-parole de Google, Martin Splitt inclus, qui reste la voix officielle du moteur sur tout ce qui touche au JavaScript. Utile le jour où ton prestataire t’assure qu’un widget « ça passe très bien », sans autre argument.
Ce que Googlebot ne fait jamais
Le robot visite ta page comme un navigateur, avec une réserve de taille : il n’agit pas. Aucun clic, aucun défilement, aucun formulaire rempli, aucune connexion à un compte. Tout contenu qui exige un geste pour apparaître reste hors de portée.
Concrètement, ces éléments passent à la trappe :
- un calendrier qui ne charge ses créneaux qu’après un clic sur « voir les disponibilités » ;
- une liste de prestations dépliée par un accordéon dont le contenu n’existe pas avant l’ouverture ;
- un bouton « charger la suite » en bas de page ;
- tout ce qui se déclenche au défilement sans passer par l’IntersectionObserver, la méthode que Google recommande justement pour le chargement différé.
Le service de rendu travaille aussi sans mémoire : Google précise dans sa documentation qu’il vide les données stockées par le navigateur entre deux chargements. Un tunnel de réservation qui garde son étape en réserve côté client repart donc de zéro à chaque page vue par le robot.
JavaScript SEO : trois façons de vérifier ce que Google voit
Trois vérifications suffisent pour savoir si ton contenu de réservation existe aux yeux du moteur. Aucune ne demande de compétence technique.
Le test d’URL en direct dans la Search Console
L’outil d’inspection d’URL de la Google Search Console teste ta page en direct et renvoie le HTML rendu ainsi qu’une capture de ce que le robot a obtenu. Si ton calendrier apparaît vide sur la capture, ou si tes prestations sont absentes du code rendu, le diagnostic est posé. L’outil liste en prime les ressources qu’il n’a pas réussi à charger, ce qui pointe souvent le coupable en une minute.
La recherche d’un extrait exact
Plus rapide encore : prends une phrase précise affichée par ton module, le nom d’une prestation par exemple, et cherche-la sur Google entre guillemets, suivie de ton nom de domaine. Aucun résultat ? Ce texte n’est pas dans l’index. La méthode ne prouve pas l’inverse à tous les coups, mais un silence complet reste un signal fiable.
Le test sans JavaScript
Désactive le JavaScript dans les paramètres de site de ton navigateur, puis recharge ta page de réservation. Ce que tu vois alors correspond au document initial, celui que Googlebot lit avant le rendu. Un écran entièrement blanc te dit tout : ton contenu dépend à cent pour cent d’un rendu qui peut échouer.
Un dernier réflexe : vérifie que ton fichier robots.txt ne bloque ni les scripts ni les feuilles de style. Google le martèle depuis l’abandon de son ancien schéma d’exploration AJAX, annoncé en octobre 2015 sur le blog Search Central. Bloquer ces ressources revient à empêcher le rendu, donc à condamner la page.
Le contenu essentiel doit exister dans le document de départ
Le principe tient en une ligne : ce qui doit se positionner ne doit pas dépendre d’un script. Le calendrier reste dynamique, personne n’indexe des créneaux qui changent toutes les heures. Le reste, non.
Fais vivre ces éléments dans le HTML servi par ton serveur :
- le titre de la page et sa méta-description ;
- le nom de ton établissement, ta ville, ton adresse ;
- la liste de tes prestations avec leur description et leur durée ;
- tes tarifs, tes conditions d’annulation, ta politique d’acompte ;
- les liens vers tes autres pages.
Le vocabulaire de ton prestataire tournera autour de trois options. Le rendu côté serveur construit la page complète avant de l’envoyer. La prégénération fabrique des fichiers HTML statiques à l’avance. Le rendu dynamique sert une version pré-rendue aux robots, une solution que Google présente désormais comme un contournement temporaire, jamais comme une cible.
Une quatrième voie, souvent la plus simple pour un établissement : garder une page de présentation classique en HTML, avec tout le contenu commercial, et n’appeler le module que pour la sélection du créneau. Ta page se positionne sur son propre contenu, le widget fait son travail de prise de rendez-vous. Cette séparation t’évite de tout miser sur un composant que tu ne maîtrises pas.
Le raisonnement vaut aussi quand tu vends des produits en même temps que des prestations, un cas traité dans le guide pour créer une boutique en ligne avec un système de réservation intégré.
Widget, iframe, application monopage : trois pièges distincts
Le widget d’éditeur injecte son contenu dans ta page après chargement. Bien construit, il finit rendu puis indexé. Mal construit, il attend une interaction, charge depuis un domaine bloqué, ou s’appuie sur un script si lourd que le rendu tourne court. Demande à ton éditeur si son widget affiche ses données sans clic préalable.
L’iframe de réservation pose un problème plus radical. Le contenu affiché dans un cadre appartient à l’URL de ce cadre, pas à ta page. Google peut l’explorer, mais il l’associe au domaine de l’éditeur. Ta page, elle, reste vide de tout signal métier. Le procédé n’a rien de disqualifiant, à condition que ta page porte son propre contenu autour du cadre.
L’application monopage concentre les difficultés. Toute la navigation passe par JavaScript, sans nouveau chargement de document. Sans réglage précis, tes différentes vues partagent la même URL, le même titre, la même description. Google ne voit qu’une seule page là où tu en comptes vingt.
La balise meta robots mérite une alerte à part. La documentation Google le dit noir sur blanc : quand le moteur rencontre une directive noindex, il peut sauter l’étape de rendu et n’exécutera pas ton JavaScript. Un script qui retire cette directive après coup n’y changera rien, la décision est déjà prise. Même logique pour la balise canonique : injectée tardivement par script, elle risque d’arriver après la bataille.
Des liens en vraies balises, des URL propres
Un lien, c’est une balise a avec un href
Google découvre tes pages en lisant les attributs href des balises a. Une publication du blog Search Central de mai 2020 consacrée aux liens et au JavaScript est sans ambiguïté : un div cliquable, un bouton doté d’un gestionnaire d’événement ou un href en javascript:void(0) ne constituent pas des liens pour le moteur. Ton menu, tes pages de prestation, tes fiches par ville doivent être atteignables par de vraies balises pointant vers de vraies adresses.
Des adresses, pas des fragments
Le dièse dans l’URL pose le second problème. Une adresse du type tonsite.fr/reservation#coiffure ne constitue pas une page distincte : le fragment sert à cibler un endroit dans un document, pas à charger un autre contenu. Le vieux système à base de dièse et point d’exclamation a été abandonné par Google en octobre 2015, et rien ne l’a remplacé.
La bonne pratique tient en un terme que ton prestataire connaît : l’History API. Elle donne à chaque vue d’une application monopage une adresse réelle, sans recharger la page, avec son titre et sa description propres. Google la recommande explicitement dans sa documentation consacrée au JavaScript.
Vérifie enfin les codes de réponse. Une page de prestation supprimée doit renvoyer un 404, pas un 200 accompagné d’un message d’erreur affiché par script. Google nomme ce cas une soft 404 et finit par désindexer l’ensemble. Ces réglages relèvent du paramétrage de ton outil, un terrain voisin de celui du logiciel de gestion des réservations adapté à ta PME.
Les six questions à poser à ton prestataire
Tenir cette conversation ne réclame aucune compétence en développement. Six questions suffisent, et les réponses te diront vite à qui tu as affaire.
- Le contenu de ma page de réservation figure-t-il dans le HTML envoyé par le serveur, ou seulement après exécution du JavaScript ?
- Chaque prestation et chaque lieu disposent-ils d’une adresse propre, sans dièse, avec leur titre et leur description ?
- La navigation du module passe-t-elle par des balises a avec un href réel ?
- Le contenu s’affiche-t-il sans clic ni défilement préalable ?
- Les scripts et les feuilles de style du module sont-ils accessibles aux robots, sans blocage dans le robots.txt ?
- Une page supprimée renvoie-t-elle bien un code 404 ?
Une réponse évasive sur la première question suffit à changer de sujet, voire de prestataire. Un éditeur sérieux connaît ces contraintes et documente sa configuration sans se faire prier.
Garde un ordre de priorité en tête. Le contenu présent dans le document initial pèse plus lourd que tout le reste. Viennent ensuite les adresses propres, puis les liens en vraies balises. Le chargement différé et la mise en cache arrivent loin derrière, même si Google conseille d’inscrire une empreinte du contenu dans le nom des fichiers de script, du type main.2bb85551.js, pour éviter qu’une version périmée reste servie au robot.
Ces vérifications se branchent naturellement sur le reste de ta chaîne d’outils, une logique développée dans le guide pour automatiser ton processus de réservation avec des outils SaaS.
Prochaine étape : ouvre ta page de réservation, coupe le JavaScript, recharge. Si l’écran reste blanc, envoie les six questions ci-dessus à ton prestataire dans la journée. Une page correctement rendue remonte dans l’index sous deux à quatre semaines, le temps que Google la réexplore.