Votre site n'apparaît pas sur Google

Search Console : la raison de chaque page absente

Le rapport d'indexation des pages, réservé au propriétaire du site et aux personnes qu'il autorise, donne une raison pour chaque adresse laissée hors de l'index. Une partie de ces raisons désigne un réglage du site : adresse marquée noindex, bloquée par robots.txt, en erreur, redirigée, soft 404, ou page en double pour laquelle Google a retenu une autre adresse canonique. Celles-là se corrigent chez vous.

D'autres sont des décisions de Google : « Détectée, actuellement non indexée », quand il connaît l'adresse sans l'avoir encore explorée ; « Explorée, actuellement non indexée », quand il l'a lue et ne l'a pas retenue. Aucun réglage ne les force. Une action manuelle, décidée par un examinateur de Google, a son propre rapport dans la Search Console.

Pour une adresse précise, l'inspection d'URL dit si Google la connaît, et quelle adresse il a retenue. C'est elle qui a montré que les deux accueils de notre propre site étaient inconnus de Google.

Google prévient aussi qu'il ne faut pas s'attendre à voir toutes les adresses d'un site indexées : les doublons et les pages sans information utile ne le sont pas, et c'est normal. Ce qui compte, ce sont les pages que vous voulez voir apparaître.

Une consigne qui tient Google à l'écart

Pendant la construction d'un site, il est courant de demander aux moteurs de ne pas l'indexer. Si la consigne survit à la mise en ligne, Google lit les pages et les écarte, exactement comme on le lui a demandé. Elle prend l'une de ces formes.

• La consigne noindex, dans la page (balise meta robots) ou dans les en-têtes de la réponse du serveur (X-Robots-Tag). Google lit la page et la laisse hors de l'index.
• Le fichier robots.txt, qui interdit la lecture mais pas l'indexation : une adresse interdite peut rester dans les résultats sans description, et une page interdite ne montre jamais à Google sa consigne noindex. Le guide sur ce que robots.txt bloque vraiment décrit ce piège.
• Un mot de passe ou un refus d'accès : une page qui répond 401 ou 403 à Google n'est pas indexée. C'est voulu sur un espace client, pas sur une page qu'on veut voir apparaître.
• Une consigne posée ou retirée par un script. Google précise, dans sa documentation sur le JavaScript, que s'il trouve noindex dans la page servie, il peut ne pas exécuter le JavaScript : un script qui retire la consigne ensuite peut donc rester sans effet. Le guide sur le référencement des sites rendus en JavaScript compare ce que le serveur envoie et ce que le navigateur affiche.

Une consigne noindex n'est pas toujours une erreur, et c'est page par page qu'on le sait. Dans l'exemple de rapport d'une boutique en ligne, sept pages la portent : cinq pages de randonnée et de trail, une sélection de vélos, et une fiche produit. Le rapport juge les listes comme un choix éditorial défendable. La fiche, elle, est un produit en vente que les moteurs n'affichent pas.

Une autre adresse retenue à la place de la vôtre

Une même page servie sous plusieurs adresses, Google ne la garde qu'une fois. Il regroupe les pages en double et choisit celle qu'il juge la plus représentative. La balise canonique, qui désigne l'adresse à retenir, est pour lui un signal fort, pas un ordre ; une redirection aussi ; la présence dans le sitemap, un signal faible. Quand ces signaux se contredisent, c'est Google qui tranche.

Vos pages peuvent alors s'effacer au profit d'une autre adresse : la version en http, l'adresse sans www, un ancien domaine, une copie de travail. La balise canonique elle-même peut les écarter : si toutes les pages d'un site désignent l'accueil comme adresse à retenir, ou une adresse qui redirige ou n'existe plus, Google reçoit, page après page, un signal fort qui l'éloigne des pages que vous voulez voir dans les résultats.

Reste la 404 molle : une adresse qui n'existe pas et répond « page trouvée » (code 200). Google juge sur le contenu : d'après sa documentation sur les erreurs HTTP, une page vide ou un message d'erreur servis comme un succès apparaissent dans la Search Console en « soft 404 », et ne sont pas indexés. Une vraie page qui paraît vide à Google peut être classée de la même façon. Le guide sur la 404 molle explique ce qu'un serveur doit répondre.

Un site neuf que Google n'a pas encore trouvé

Google l'écrit dans sa présentation du fonctionnement de la recherche : il ne garantit pas d'explorer, d'indexer ou d'afficher une page, même quand elle respecte ses consignes. Il découvre les adresses surtout par les liens des pages qu'il connaît déjà, et par les sitemaps.

Pour un site neuf, cela prend du temps. Google indique que l'exploration peut prendre de quelques jours à quelques semaines, et qu'une demande d'exploration ne garantit pas l'entrée dans les résultats. Un site neuf qu'aucune autre page ne cite est donc découvert lentement, sans qu'aucun réglage soit en faute.

Nos deux accueils, « inconnus de Google »

Notre site en a fait l'expérience. Il a deux accueils, /fr/ et /en/. Sa racine, l'adresse sans dossier de langue, servait une copie de l'accueil anglais avec un code 200, et un script envoyait les navigateurs francophones vers /fr/. Aucun lien interne ne menait à cette racine, et elle ne figurait pas dans le sitemap.

La version actuelle du site a été mise en ligne le 29 septembre 2026. Trois jours plus tard, l'inspection des adresses dans la Search Console montrait la plupart des pages indexées, mais les deux accueils « inconnus de Google ». La racine était indexée à leur place. Les clics et les impressions ne pouvaient pas le montrer : une page absente de l'index n'y laisse aucune ligne. Seule l'inspection adresse par adresse l'a fait voir.

Le 2 octobre 2026, nous avons changé la réponse du serveur : la racine renvoie désormais, par une redirection temporaire (302), vers l'accueil de la langue du navigateur. Elle ne sert plus de copie, et chaque accueil n'a plus qu'une adresse. Tout le reste désignait déjà /fr/ et /en/, donc supprimer la copie a suffi. Retenir les deux accueils reste une décision de Google : la correction retire le doublon, elle ne commande pas l'index.

De l'extérieur, on voit qu'une même page répond sous deux adresses. On ne voit pas laquelle Google a gardée : cela, seule la Search Console le dit. C'est pour cela que les deux lectures vont ensemble.

Accès, consignes, adresse unique : par où commencer

Ce sont des accès à obtenir, des questions à poser et des décisions à prendre. Les corrections elles-mêmes reviennent à la personne qui tient votre site.

1. Obtenez l'accès à la Search Console de votre site, à votre nom, puis lisez la raison que Google donne pour chaque page absente. C'est le seul endroit où il dit ce qu'il a fait de vos pages. Si votre agence l'a ouverte pour vous, demandez à y être ajouté comme propriétaire : le site est à vous, ses données aussi.
2. Demandez à votre prestataire de confirmer, pour chacune de vos pages importantes, qu'aucune consigne de non-indexation posée pendant la construction n'est restée en place : une case cochée dans le gestionnaire de contenu, une balise noindex, une interdiction dans robots.txt, un mot de passe. C'est la correction la plus simple, et Google en tient compte à sa prochaine lecture des pages.
3. Faites choisir une seule version du site, en https, avec ou sans www, et une seule adresse par page. Les autres adresses (ancien domaine, version en http, copie de l'accueil) doivent renvoyer vers elle, et la balise canonique, le sitemap et les liens internes doivent tous la désigner.
4. Faites vérifier qu'aucune copie de travail du site n'est publique. Une préproduction restée publique et indexée concurrence le vrai site avec son propre contenu.
5. Si le site est neuf, donnez à Google des chemins vers lui : un sitemap déclaré dans la Search Console, et des liens depuis des pages qu'il connaît déjà, comme les sites de vos partenaires ou vos profils professionnels. Puis laissez-lui du temps.
6. Si la cause reste introuvable, ou si vous voulez contrôler la réponse qu'on vous a faite, faites relire le site par quelqu'un qui ne l'a pas construit. Le guide pour vérifier qu'une agence SEO fait son travail dit ce que vous pouvez lui demander.

Une consigne oubliée, une ligne de robots.txt trop large ou un sitemap absent se corrigent à un seul endroit, et Google en tient compte à sa prochaine lecture des pages, pas instantanément. Le chantier est plus large quand le même contenu vit sous plusieurs adresses : ancien domaine, version en http, préproduction, racine qui recopie une page, versions de langue. Il faut décider quelle adresse porte chaque page, puis aligner sur elle les redirections, les balises canoniques, le sitemap et les liens internes. Demandez-le comme un travail à part entière, avec en livrable la liste des adresses traitées et ce que devient chacune.

Une indexation garantie n'existe pas : Google lui-même ne la promet pour aucune page. Et si vos pages sont indexées mais classées trop loin pour être vues, ce n'est plus une question de réglage, c'est une question de contenu, face aux pages qui se classent devant les vôtres.

De l'extérieur, page par page, sans la Search Console

Ces pourcentages portent sur une trentaine de sites audités entre le 14 août 2026 et le 24 septembre 2026. Chacun ne compte que les sites où le point a pu être vérifié. Beaucoup ont été audités parce qu'un défaut s'y voyait vite : ces chiffres décrivent nos audits, pas l'ensemble des sites.

Aucun de ces deux défauts n'empêche à lui seul un site d'apparaître. Sans robots.txt, Google considère que tout est autorisé ; sans sitemap, il n'a que les liens pour trouver les pages. La 404 molle lui laisse trier lui-même des pages qui n'existent pas.

L'audit lit votre site de l'extérieur, dans un navigateur, comme un visiteur, sans accès à votre hébergement ni à votre Search Console. Il ne s'arrête pas à l'accueil : sur chaque page analysée, il cherche ce qui empêche Google de la lire, de l'indexer ou de retenir la bonne adresse. Quand la Search Console donne une raison qui désigne un réglage du site, le rapport montre où se trouve ce réglage.

• Les consignes de non-indexation de chaque page analysée, dans la balise meta robots et dans les en-têtes de la réponse. Sur une page importante, la consigne est relevée ; sur une page qu'on écarte volontairement, elle est normale, et le rapport ne la compte pas comme un défaut.
• Sur la page de référence du site, en général l'accueil, la version que le serveur envoie et celle que le navigateur affiche après les scripts. Une balise canonique ou une consigne noindex qui n'existe que dans l'une des deux est relevée.
• Le fichier robots.txt : les interdictions qui ferment tout le site, à tous les robots ou à celui de Google, et les lignes qu'un robot ignore.
• La balise canonique de chaque page : présente, et menant directement à une page qui répond, sans redirection ni consigne noindex. Une page profonde qui désigne l'accueil comme adresse à retenir est relevée.
• Le sitemap : présent, lisible, et listant réellement des pages.
• La réponse à une adresse inventée : le serveur doit répondre 404. Une réponse 200 est une 404 molle.
• Les adresses d'entrée, en http et en https, avec et sans www : une seule doit servir le site, les autres doivent y renvoyer.
• Les sous-domaines que les équipes donnent le plus souvent à une copie de travail : une copie publique et indexable du site est relevée.

Une lecture de l'extérieur a ses bornes, et le rapport les écrit au lieu de les combler. Dans le rapport de la boutique, toute requête qui s'annonce comme un robot de moteur, Googlebot compris, reçoit un refus (403), quand le même serveur répond normalement à un navigateur au même instant. Le rapport n'en conclut pas que Google est bloqué : la mesure ne part pas des adresses de Google, et la présence du site dans les résultats indique que le vrai robot est servi. Ce que Googlebot reçoit lui-même, seule la Search Console le dit.

Le rapport nomme les pages concernées par chaque constat, et ce qui y a été observé : la personne qui corrige sait où intervenir, et vous pouvez vérifier ensuite que c'est fait. Chaque limite de l'examen est indiquée dans le rapport. Un point non vérifiable n'est jamais présenté comme conforme.