Un lecteur, Dorian, m'a écrit un jour une question très simple, et elle revient encore régulièrement dans mes échanges avec des dirigeants : « Est-il possible de récupérer les données d'un espace professionnel protégé par mot de passe avec SEMrush ou un autre outil ? » Le cas était classique : un fabricant avec, d'un côté, un site vitrine public, et de l'autre un extranet réservé aux revendeurs, hébergé sur un sous-domaine.
Ma réponse n'a pas bougé depuis : non, et c'est logique. Les outils SEO ne font que reconstituer ce que les moteurs voient, et un espace fermé ne cherche pas de visibilité publique. Mais la vraie question de Dorian n'était pas celle-là. Derrière « peut-on l'auditer ? » se cache « comment sait-on si cet espace fonctionne bien ? ». Là, il y a beaucoup à dire, et rien ne s'appelle référencement.
Un outil SEO ne voit que ce que voit un robot
SEMrush, Ahrefs ou n'importe quel crawler tiers travaillent à partir de deux matières premières : l'index public des moteurs et leur propre exploration du web ouvert. Sur le sous-domaine de l'extranet, le robots.txt interdisait l'accès à tous les agents, Googlebot compris, et une recherche site: ne renvoyait aucun résultat. Ni mots-clés positionnés, ni backlinks, ni trafic organique : ces métriques n'existaient pas.
Rappelons que chaque domaine et chaque sous-domaine possède son propre robots.txt. Un site public parfaitement ouvert peut très bien cohabiter avec un extranet totalement fermé sur espacepro.exemple.com : deux hôtes distincts, deux politiques distinctes. C'est la configuration la plus saine pour séparer nettement le public du privé.
J'avais donné à Dorian une analogie qui parle à tout le monde : un site e-commerce ressemble à un supermarché. Le responsable décide de ce qui est en tête de gondole et oriente le parcours du client, mais le client n'entre ni dans les bureaux ni dans la réserve. Optimiser la réserve pour attirer des passants n'a aucun sens ; l'optimiser pour que les employés trouvent une palette en trente secondes, si.
Ce que le référencement n'apporte pas sur un site fermé
Sur un intranet, un extranet ou un espace client, trois piliers du SEO tombent d'un coup. La concurrence sur les requêtes disparaît : vos utilisateurs n'arbitrent pas entre vous et dix autres résultats, ils se connectent parce qu'ils y sont obligés. Les liens entrants ne servent à rien, puisque personne d'extérieur ne peut pointer vers une page qu'il ne peut pas ouvrir. Et la page de résultats n'entre jamais dans l'équation : balises title, rich snippets et maillage sémantique n'ont plus d'objet.
Ce qui reste, ce sont les briques d'ergonomie que le SEO emprunte à l'UX sans les avoir inventées : un intitulé clair, une page rapide, une arborescence logique. La différence, c'est le juge : ce n'est plus un algorithme, mais un collaborateur pressé ou un revendeur qui cherche une fiche technique entre deux rendez-vous.
Les six chantiers qui remplacent le SEO
Le moteur de recherche interne
C'est le premier poste à traiter, et le plus souvent négligé. Nielsen Norman Group, à l'issue de tests d'utilisabilité et d'études de terrain menés dans quinze organisations (article publié le 22 mai 2022), décrit un mécanisme d'abandon très net : les salariés attendent du moteur interne qu'il se comporte comme Google, ils sont déçus, cessent de l'utiliser et repassent par la navigation, ce qui allonge le temps de réalisation des tâches. Le remède n'est pas que technique : il tient autant à la gouvernance des contenus qu'au moteur lui-même.
L'architecture de l'information
Un intranet vieillit par sédimentation : chaque service ajoute sa rubrique, personne n'en retire, et au bout de cinq ans il existe trois endroits où déposer une note de frais. Le travail utile consiste à cartographier les tâches réelles, pas l'organigramme, puis à regrouper les contenus par intention. C'est la méthode d'un audit UX, appliquée à un périmètre fermé.
Le nommage et les métadonnées
Sur un espace privé, le nom du fichier et le titre du document remplacent la balise title. « Procedure_V3_final_OK.docx » est autant un problème de recherche qu'un problème de rangement. Une convention de nommage simple — type, objet, service, date — et quelques champs obligatoires à l'import font plus pour la trouvabilité que n'importe quel réglage de moteur.
L'accessibilité
Contrairement à une idée répandue, le caractère privé d'un site ne l'exonère pas. Le champ d'application du RGAA, publié par la Direction interministérielle du numérique, vise explicitement « les sites internet, intranet, extranet » et les progiciels utilisés via un navigateur. Il concerne les personnes morales de droit public, certains organismes privés d'intérêt général, et les entreprises privées dont le chiffre d'affaires annuel réalisé en France dépasse 250 millions d'euros, moyenne calculée sur les trois derniers exercices, en application de l'article 47 de la loi n° 2005-102 du 11 février 2005. Une exemption existe pour les contenus d'intranets et d'extranets publiés avant le 23 septembre 2019, jusqu'à leur refonte en profondeur : le jour où vous refondez, elle tombe. Au-delà de l'obligation, c'est la condition pour qu'un salarié malvoyant ou dyslexique fasse son travail.
La performance perçue
Un extranet lent coûte du temps salarié tous les jours, sans jamais apparaître dans un rapport. Les seuils des Core Web Vitals restent une référence utile même hors moteur de recherche : selon la documentation de Google sur web.dev, un LCP inférieur à 2,5 secondes, un INP inférieur à 200 millisecondes et un CLS inférieur à 0,1 correspondent à une bonne expérience. Ces seuils mesurent une perception humaine, pas un classement : ils gardent tout leur sens derrière un mot de passe. Sur des applications métier chargées de tableaux et de scripts, c'est souvent là que se cache le gain le plus rentable, et le travail d'optimisation de la vitesse y est identique.
La recherche fédérée
Dans la plupart des PME que j'accompagne, l'information n'est pas dans l'intranet : elle est éclatée entre la GED, l'ERP, un wiki, un Drive partagé et les boîtes mail. Une recherche fédérée — un seul champ qui interroge plusieurs sources — évite de demander au salarié de deviner où chercher. C'est un projet d'intégration, pas un projet éditorial : budgétez-le comme tel.
| Critère | Site public | Intranet, extranet, espace client |
|---|---|---|
| Objectif | Être trouvé par un inconnu | Faire gagner du temps à un utilisateur connu |
| Levier principal | Contenu, popularité, technique | Recherche interne, architecture, nommage |
| Indicateur | Positions, trafic organique, conversions | Taux de recherches sans résultat, temps de tâche, tickets support |
| Outil de mesure | Search Console, crawler SEO | Logs du moteur interne, tests utilisateurs |
| Risque principal | Invisibilité | Fuite d'URL et de documents |
Le cas des contenus partiellement protégés
Entre le tout public et le tout fermé existe une zone grise : articles derrière abonnement, fiches techniques accessibles après inscription, tarifs réservés aux clients. L'objectif y est double : rester indexé pour attirer, tout en gardant le contenu sous clé.
Google prévoit ce cas. Sa documentation sur le contenu payant (page mise à jour le 8 septembre 2026) demande de baliser explicitement la partie protégée en JSON-LD ou microdonnées : la propriété isAccessibleForFree passée à false, et un hasPart de type WebPageElement qui désigne la zone via un cssSelector — uniquement un sélecteur de classe. Sans ce balisage, montrer à Googlebot un texte que l'internaute ne verra pas relève du cloaking, et expose à une sanction. Avec, la pratique est explicitement admise.
Deux erreurs fréquentes à ce stade : croire qu'un formulaire d'inscription « léger » ne compte pas — s'il masque du contenu, il doit être déclaré ; et oublier que ce balisage informe le moteur mais ne verrouille rien. Le verrou, c'est le contrôle d'accès côté serveur.
noindex, robots.txt et le risque de fuite d'URL
C'est le point où je vois le plus d'erreurs, y compris chez des prestataires expérimentés. Google l'écrit noir sur blanc : une page interdite dans robots.txt peut tout de même être indexée si d'autres sites pointent vers elle. L'URL et le texte du lien peuvent alors apparaître dans les résultats. Le robots.txt gère l'exploration, il ne cache rien — et comme il est public, il liste les répertoires que vous cherchez à dissimuler.
Le piège suivant est mécanique. Pour qu'une directive noindex soit prise en compte, il faut que le robot puisse lire la page. La documentation de Google est explicite : si la page est bloquée par robots.txt, le crawler ne verra jamais la règle noindex, et la page peut continuer d'apparaître. Cumuler Disallow et noindex sur la même URL, c'est neutraliser le second. Il faut choisir : laisser crawler pour désindexer, ou fermer par authentification. C'est ce que je vérifie lors d'un contrôle de l'indexation.
Reste la fuite par les côtés, la plus sournoise. Un devis PDF déposé dans un répertoire non listé mais accessible sans mot de passe finira par être trouvé : un lien partagé par mail, un en-tête Referer ou un sitemap oublié suffisent. La seule barrière fiable reste une authentification serveur sur chaque ressource, fichiers joints compris. Le « secret de l'URL » n'est pas un mécanisme de sécurité.
Comment trancher, concrètement
Posez-vous trois questions dans l'ordre. Le contenu doit-il attirer des inconnus ? Il est alors public et relève du SEO classique. Doit-il être lisible par un moteur mais réservé à des abonnés ? On applique le balisage de contenu payant et on verrouille côté serveur. N'a-t-il aucune vocation externe ? On l'authentifie, et on investit le budget dans la recherche interne et l'ergonomie.
Le suivi change aussi de nature : taux de recherches internes sans résultat, requêtes internes les plus fréquentes, temps de réalisation d'une tâche type, volume de tickets « je ne trouve pas ». Ces données sortent des logs applicatifs et se consolident dans un tableau de bord Data Studio (ex-Looker Studio). Si l'espace est encore à construire, ces contraintes se décident au moment du cahier des charges, pas après : c'est une réflexion que je mène lors d'une création de site professionnel.
La conclusion tient en une phrase : on n'optimise pas un intranet pour Google, on l'optimise pour les gens qui n'ont pas le choix de l'utiliser. Une exigence plus forte, pas plus faible.
Questions fréquentes
Peut-on analyser un site protégé par mot de passe avec un outil SEO ?
Non. Les plateformes comme SEMrush ou Ahrefs s'appuient sur l'index public des moteurs et sur leur propre exploration du web ouvert. Une zone fermée par authentification ou interdite dans le robots.txt ne leur renvoie rien : il n'existe ni positions, ni backlinks, ni trafic organique à mesurer. Pour auditer un espace privé, il faut passer par un crawler configuré avec des identifiants, les logs serveur et des tests utilisateurs.
Un intranet doit-il respecter le RGAA ?
Oui pour les organismes concernés. Le champ d'application du référentiel vise explicitement les sites internet, intranet et extranet ainsi que les progiciels utilisés via un navigateur. Il s'applique aux personnes morales de droit public, à certains organismes privés d'intérêt général et aux entreprises dont le chiffre d'affaires annuel en France dépasse 250 millions d'euros. Les contenus d'intranet publiés avant le 23 septembre 2019 bénéficient d'une exemption jusqu'à leur refonte en profondeur.
robots.txt suffit-il à empêcher l'indexation d'une page ?
Non. Google indique qu'une URL interdite dans le robots.txt peut tout de même apparaître dans les résultats si d'autres pages pointent vers elle, avec son adresse et le texte du lien. Le fichier robots.txt est en outre public, donc il révèle les répertoires que vous cherchez à masquer. Pour empêcher réellement l'accès, il faut une authentification côté serveur.
Peut-on combiner Disallow dans robots.txt et balise noindex ?
C'est contre-productif. Pour appliquer une directive noindex, le robot doit pouvoir charger la page et lire la balise ou l'en-tête HTTP. Si l'URL est bloquée par le robots.txt, la règle noindex n'est jamais vue et la page peut rester affichée dans les résultats. Il faut donc autoriser l'exploration le temps de la désindexation, puis fermer l'accès si nécessaire.
Comment garder un contenu payant indexé sans faire de cloaking ?
Google admet cette pratique à condition de la déclarer en données structurées. On indique la propriété isAccessibleForFree à false et on désigne la partie protégée avec un hasPart de type WebPageElement et un cssSelector qui pointe vers une classe CSS. Sans ce balisage, servir au robot un texte que l'internaute ne voit pas est assimilé à du cloaking et peut être sanctionné.
Quels indicateurs suivre sur un espace à accès protégé ?
Les métriques SEO n'ont plus d'objet, il faut les remplacer par des indicateurs d'usage. Les plus parlants sont le taux de recherches internes sans résultat, les requêtes internes les plus fréquentes, le temps nécessaire pour accomplir une tâche courante et le nombre de sollicitations du support liées à une information introuvable. Ces données viennent des logs applicatifs et de tests utilisateurs, pas d'un outil de référencement.