Checklist visibilité IA pour sites B2B SaaS : ce que les guides génériques ratent

La plupart des guides « visibilité IA » sont écrits pour un site vitrine : une page d'accueil, une adresse, des horaires. Un site B2B SaaS n'a presque aucun de ces problèmes — et en a trois autres, plus profonds, que ces guides ne couvrent pas : le rendu JavaScript, la structure des pages pricing/features, et le volume de contenu docs/changelog que personne ne relit ligne par ligne.

Cette checklist est écrite pour cette différence-là. Chaque point se vérifie seul, en quelques minutes, sans outil propriétaire — que vous suiviez déjà votre citation IA avec une plateforme dédiée ou pas encore. Les endroits où Livada Edge SEO ou AgentRadar accélèrent une étape sont signalés au passage, mais la checklist fonctionne très bien sans eux.

Le rendu JavaScript — ce que le crawler lit n'est pas ce que vous voyez

React, Next.js, Vue, Svelte : la quasi-totalité des sites marketing SaaS modernes tournent sur un framework JS, souvent avec une partie du contenu injectée côté client après chargement. C'est l'angle mort le plus commun de ce type de site — et le plus mal compris.

Fin 2026, GPTBot (OpenAI), ClaudeBot (Anthropic) et PerplexityBot n'exécutent pas le JavaScript : ils lisent le HTML brut renvoyé par le serveur, sans attendre de rendu ni retenter une deuxième passe. Si votre bloc de fonctionnalités ou votre grille de prix n'existe qu'après hydratation côté client, ces trois crawlers ne le voient jamais. Googlebot, lui, exécute le JavaScript depuis des années — c'est pour ça qu'un site peut très bien se positionner sur Google Search tout en étant fonctionnellement vide pour les IA qui répondent à vos prospects.

Comment vérifier : chargez votre page pricing avec le JavaScript désactivé, ou interrogez-la avec curl -A "GPTBot" https://votresite.com/pricing, et comparez au rendu dans le navigateur. Si le contenu qui compte — prix, fonctionnalités, argumentaire — n'apparaît que dans la version avec JS, ce n'est pas une hypothèse, c'est un fait mesurable.

La vraie correction est côté application : rendu serveur (SSR) ou génération statique (SSG) pour les pages marketing, au moins pour le contenu qui doit être cité. C'est un chantier d'ingénierie, pas un correctif d'une heure. Ce que Livada Edge SEO peut faire en attendant — ou en complément — c'est injecter au niveau de l'edge, avant que la page n'atteigne le visiteur, les signaux qui ne dépendent pas du rendu JS : schema JSON-LD, balises title/meta, /llms.txt, sitemap, sans toucher au build ni au code de l'app. Ça ne remplace pas un vrai SSR si votre contenu texte lui-même n'existe que côté client — mais ça ferme immédiatement l'écart sur tout ce qui est signal structuré, ce qui est souvent la moitié du problème.

La page pricing — l'endroit où le schema compte le plus

Quand un agent IA répond à « combien coûte [votre produit] », il ne devine pas au hasard : il cite ce qu'il a trouvé, si c'est trouvable. Une page pricing SaaS a trois manques récurrents :

• Pas de schema Product/SoftwareApplication avec un objet Offer (prix, devise, période de facturation) — l'agent doit deviner le prix depuis du texte libre, avec un vrai risque d'erreur ou de valeur périmée
• Pas de FAQPage sur les objections courantes (essai gratuit ? annulation ? sièges illimités ? mensuel vs annuel ?) — ce sont pourtant exactement les questions qu'un prospect pose à un agent avant de vous les poser à vous
• Un prix qui n'existe que derrière un bouton « Nous contacter », sans aucune fourchette publique — invisible par définition, schema ou pas

Le correctif est le même, que le site soit sous WordPress ou en Next.js maison : balisage complet sur la page pricing, une FAQ écrite pour répondre à une vraie question plutôt que pour remplir une section, et une fourchette publiée en clair si elle existe déjà en interne. Sur un site non-WordPress, c'est exactement le type de balisage que Livada Edge SEO injecte côté serveur sans toucher au CMS ni au code de l'application.

Docs et changelog — le contenu le plus interrogé, le moins audité

Une bonne partie des questions posées à ChatGPT ou Claude au sujet d'un outil SaaS ne portent pas sur le prix, mais sur l'usage : « est-ce que [produit] supporte SSO ? », « comment faire un webhook avec [produit] ? », « qu'est-ce qui a changé dans la dernière version ? ». Ces réponses vivent dans la doc et le changelog — deux zones presque jamais auditées avec le même sérieux que la page d'accueil.

Deux problèmes reviennent souvent :

• La plateforme de doc elle-même est parfois construite avec le même type de rendu côté client que le site principal — le point de vérification de la section précédente s'applique là aussi, spécifiquement
• Le changelog est souvent une liste de titres sans contexte (« v2.4.1 — correctifs ») — techniquement indexable, mais inutilisable pour un agent qui cherche « ce qui a changé pour l'authentification »

/llms.txt est particulièrement pertinent ici : c'est une convention née dans l'écosystème dev-tool/API avant de se répandre ailleurs, et une doc technique est exactement le type de contenu qu'elle est faite pour structurer — un sommaire en clair, avec les pages qui comptent en priorité, plutôt que de laisser un agent deviner l'arborescence. Guide complet : /llms.txt — le fichier que votre site doit avoir en 2026.

robots.txt dit oui, votre pare-feu applicatif dit non

Un réflexe que les sites vitrine n'ont pas : la plupart des entreprises B2B logent leur site marketing derrière la même infrastructure de sécurité que leur produit — WAF, protection anti-bot (Cloudflare Bot Management, Akamai, PerimeterX/HUMAN, Datadome…). Ces outils filtrent ou défient le trafic « suspect » par défaut, souvent au niveau infrastructure, avant même que la requête n'atteigne l'application qui sert robots.txt.

Résultat : robots.txt peut autoriser GPTBot noir sur blanc, et le crawler recevoir quand même un 403 ou un défi à la porte, parce que la règle de sécurité applicative n'a jamais été mise à jour pour distinguer un crawler IA légitime d'un bot malveillant. Personne ne le voit, parce que personne ne teste avec le vrai user-agent — seulement le contenu du fichier.

Comment vérifier : interrogez votre site avec le user-agent exact du bot et regardez le code de statut réellement renvoyé, pas seulement ce qu'autorise robots.txt sur le papier. Liste exhaustive des user-agents à tester : robots.txt et IA — la liste des bots à autoriser en 2026.

Pages comparatives et « alternative à » — le contenu qu'on gate sans s'en rendre compte

Le B2B SaaS a une habitude que les sites vitrine n'ont pas : publier des pages « [Produit] vs [Concurrent] » et « meilleure alternative à [Concurrent] ». C'est exactement le format qu'un agent IA cite quand un prospect demande une comparaison — mais deux erreurs reviennent souvent :

• Le contenu comparatif est enfermé derrière une démo ou un compte à créer — invisible pour un crawler qui ne remplit pas de formulaire
• La page reste vague par prudence juridique (« une expérience plus flexible », « plus moderne ») sans un seul fait vérifiable — un agent n'a rien de concret à citer, donc il ne cite rien

La correction n'est pas technique : elle est éditoriale. Un comparatif utile pour un agent IA nomme des faits — une fonctionnalité présente ou absente, une fourchette de prix si elle est publique, une différence d'architecture — plutôt que des adjectifs. C'est la même règle qu'on applique aux comparatifs publiés sur ce site : jamais de tableau générique, seulement des lignes qu'on peut vérifier.

La vérification statique ne suffit pas — testez avec un vrai agent

Tous les points ci-dessus se vérifient avec un audit statique : schema présent, robots.txt ouvert, llms.txt à jour. Aucun ne garantit qu'un agent atteint réellement l'information. Un agent peut avoir accès à votre doc, comprendre votre balisage, et échouer quand même à trouver « comment configurer SSO » — parce que c'est sur la mauvaise page, ou enterré sous un menu qu'il n'ouvre pas.

C'est le niveau que teste spécifiquement Livada AgentRadar : un vrai agent reçoit une vraie tâche (« trouve le prix du plan Enterprise », « trouve si SSO est supporté »), rejouée dix fois, jugée par un modèle d'un fournisseur différent de celui testé, avant puis après une correction — avec un journal signé plutôt qu'un score à croire sur parole. Le principe ne dépend pas du secteur : la question change, la méthode non.

La checklist condensée

• Rendu — le contenu qui compte (pricing, features) existe dans le HTML brut, pas seulement après hydratation JS
• Schema pricing — Product/SoftwareApplication + Offer + FAQPage sur la page pricing
• Docs et changelog — servis en HTML brut, changelog avec du contexte réel, pas que des titres de version
• /llms.txt — présent, à jour, pointe vers les pages qui comptent
• robots.txt ET pare-feu — testés avec le vrai user-agent du bot, pas juste le fichier texte
• Pages comparatives — non gatées, avec des faits nommés plutôt que des adjectifs
• Un agent réel testé — sur une vraie tâche (pricing, feature, doc), pas juste un score théorique

Les six premiers points se corrigent une fois. Le dernier se surveille : un déploiement change le rendu, une refonte de doc déplace une page, et ce qui répondait hier peut échouer demain sans qu'aucune alerte classique ne le signale.