Nous avons publié plusieurs guides sur ce blog — le schema.org Hotel, les robots IA, le fichier llms.txt. Chacun traite un sujet en profondeur. Celui-ci fait l'inverse : il rassemble tout ce que nous avons déjà expliqué en une seule liste de contrôle, pour que vous puissiez vérifier votre propre site sans tout relire.
Rien de ce qui suit n'est nouveau ni spéculatif. Ce sont les vingt points que nous vérifions en premier lorsqu'un hôtel nous demande pourquoi il n'apparaît jamais dans les réponses des assistants IA. La plupart des sites échouent sur cinq ou six d'entre eux — rarement tous, rarement aucun.
Accès robots
1. Un robots.txt configuré délibérément, pas laissé par défaut — beaucoup de sites tournent encore avec le fichier généré automatiquement par leur CMS au moment du lancement, jamais revu depuis. Ouvrez votredomaine.com/robots.txt et vérifiez qu'il correspond à une décision, pas à un oubli.
2. GPTBot, ClaudeBot, PerplexityBot et Google-Extended explicitement autorisés — si vous voulez apparaître dans les réponses IA, ces robots doivent avoir une ligne Allow: / qui leur est propre. Une règle générique User-agent: * ne suffit pas toujours à couvrir les cas où un plugin de sécurité ou un pare-feu a ajouté des exceptions spécifiques par la suite.
3. Aucun Disallow: / global qui traîne — le piège classique : un environnement de développement passé en production avec le robots.txt de blocage total resté en place, ou un plugin SEO mal configuré qui bloque tout par précaution. Ce point à lui seul explique une part significative des sites invisibles aux IA que nous auditons.
4. Robots de recherche distingués des robots d'entraînement — OAI-SearchBot, Claude-SearchBot et PerplexityBot construisent des index de recherche qui vous citent. GPTBot, ClaudeBot et Google-Extended collectent du contenu pour l'entraînement des modèles. Vous pouvez autoriser les uns et restreindre les autres : c'est une décision stratégique, pas un choix binaire.
Données structurées
5. Le schema Hotel est complet — adresse au format PostalAddress, classification en étoiles, liste d'équipements en amenityFeature, heures de check-in et check-out, langues parlées à la réception. Un schema qui ne contient que le nom et l'adresse ne dit presque rien d'utile à une IA.
6. Un schema Room ou Offer existe pour chaque type de chambre — sans cela, une IA voit "un hôtel" mais ne peut pas répondre à une question du type "avez-vous une chambre avec vue et baignoire pour deux adultes et un enfant".
7. Un schema FAQPage si votre site a une section FAQ — c'est l'un des types de données structurées les plus directement exploités par les réponses génératives, car il correspond exactement au format question-réponse que ces systèmes produisent.
8. Un schema AggregateRating ou Review si des avis sont affichés — si votre page montre une note moyenne visible pour les visiteurs humains, la même note doit exister dans les données structurées, avec le même chiffre. Un écart entre les deux (4,5/5 affiché, rien dans le schema, ou pire, une valeur différente) génère de la méfiance côté moteurs et pénalités côté Google.
9. Le schema validé avec le Rich Results Test, pas simplement copié d'un tutoriel — un bloc JSON-LD copié depuis un article générique et jamais adapté contient presque toujours des valeurs placeholder oubliées ou des propriétés obligatoires manquantes. Passez systématiquement votre code par search.google.com/test/rich-results avant de le mettre en ligne.
llms.txt
10. Le fichier existe à la racine du domaine — votredomaine.com/llms.txt, en Markdown, accessible publiquement, pas bloqué par le robots.txt.
11. Le contenu est exact, pas générique — un llms.txt qui liste des équipements que vous n'avez plus, ou qui ne mentionne pas votre restaurant ouvert l'an dernier, induit une IA en erreur exactement comme une brochure imprimée périmée trompe un client.
12. Le fichier est tenu à jour — à chaque changement significatif (nouvelle offre, rénovation, nouveau restaurant, changement de politique animaux), le llms.txt doit être révisé au même titre que la page d'accueil. Un fichier créé une fois et jamais retouché perd rapidement sa valeur.
Contenu & métadonnées
13. Des balises de titre uniques sur chaque page — en particulier sur les pages de types de chambres, où la tentation de dupliquer un même titre générique ("Chambres — Nom de l'hôtel") sur dix pages différentes est fréquente.
14. Des méta-descriptions uniques, non dupliquées entre types de chambres — chaque page doit répondre à une question différente. Une méta-description identique sur toutes les fiches chambres signale à un moteur qu'aucune n'est vraiment distincte des autres.
15. Une hiérarchie de titres logique, pas décorative — un seul H1 par page, des H2 qui structurent réellement le contenu, pas des balises choisies pour leur taille visuelle. Une IA qui analyse la structure HTML pour comprendre l'organisation de l'information se fie à cette hiérarchie ; si elle est incohérente, l'extraction l'est aussi.
16. Un texte alternatif descriptif sur les images, pas le nom de fichier — "chambre-deluxe-vue-mer-balcon" apporte de l'information ; "IMG_4021.jpg" ou "chambre-1" n'en apporte aucune, ni pour l'accessibilité, ni pour l'indexation, ni pour un système d'IA qui tente de comprendre le contenu visuel de la page.
17. Une description de l'établissement factuelle, complète et sans ambiguïté — le test le plus simple : un système d'IA pourrait-il reproduire votre description sans inventer un seul détail ? Si votre texte est vague ("un cadre exceptionnel", "une expérience unique") sans jamais préciser le nombre de chambres, la localisation exacte ou les équipements réels, l'IA n'a rien de solide à citer — et cite votre concurrent qui, lui, a été précis.
Performance & multilingue
18. Les balises hreflang correctement appariées entre versions linguistiques — chaque page française doit pointer vers son équivalent anglais exact, et réciproquement. Une paire mal appariée (la page d'accueil française pointant vers une page de chambre anglaise) fait plus de mal que l'absence totale de hreflang.
19. Des URLs canoniques propres, sans chaînes de redirection — chaque redirection supplémentaire ajoute de la latence et de la confusion pour les crawlers, qu'ils soient de recherche classique ou d'IA. Une chaîne de trois redirections pour atteindre une page de chambre est un signal de site mal maintenu.
20. Un sitemap soumis et à jour — dans Google Search Console à minima, reflétant les pages réellement en ligne, sans URLs mortes ni pages supprimées depuis longtemps.
21. Une vitesse de chargement raisonnable sur mobile — Core Web Vitals dans des seuils acceptables. Un site qui met plus de trois ou quatre secondes à s'afficher sur mobile perd des visiteurs humains avant même que la question de la visibilité IA se pose, et signale par ailleurs une infrastructure technique globalement négligée.
Ce que révèle généralement cet audit : la plupart des sites hôteliers que nous examinons échouent sur l'accès bots (point 2 ou 3) et sur le schema incomplet (points 5 à 8) — rarement sur tout, presque jamais sur rien. Deux ou trois corrections ciblées suffisent souvent à débloquer une visibilité qui était simplement empêchée par un détail technique, pas absente par manque de contenu.
Vérifier ces vingt et un points à la main prend facilement une heure ou deux, en sachant exactement où chercher — robots.txt, code source, Rich Results Test, Search Console, PageSpeed Insights. C'est un travail utile, mais répétitif, et il doit être refait à chaque mise à jour significative du site.
C'est exactement ce qu'AIscore automatise en moins d'une minute : robots.txt, schema, llms.txt, hreflang, métadonnées et performance, analysés ensemble, avec un score et les corrections précises à apporter. Ou vous pouvez continuer à faire la liste à la main, page par page. Les deux fonctionnent — l'un prend une minute, l'autre en prend soixante.
Ou passez directement le scan
AIscore vérifie ces vingt et un points — et 70 signaux supplémentaires — en 30 secondes, gratuitement, sans inscription.
Scanner mon hôtel →