Pourquoi mon site n'apparaît pas sur Google : le diagnostic

Quand un site n’apparaît pas sur Google, deux causes sans rapport se disputent l’explication : la page n’est pas indexée, ou elle l’est et se classe trop bas pour être vue. Une recherche site: tranche en quelques secondes. La Search Console donne ensuite le motif exact, URL par URL.

Pourquoi mon site n’apparaît pas sur Google : indexation ou classement

Un site invisible n’est pas forcément absent de l’index. Confondre les deux situations coûte des semaines de travail mal orienté, parce qu’elles ne se réparent pas au même endroit.

L’indexation décide si une page existe dans la base du moteur. Le classement décide de sa position une fois qu’elle y figure. Une page hors index ne sortira sur aucune requête, pas même sur la dénomination sociale exacte. Une page indexée mais faible ressort au contraire sur des formulations très précises, souvent au-delà de la troisième page de résultats.

La vérification qui prend trente secondes

L’aide de la Search Console décrit la manipulation : lancer une recherche site:mondomaine.fr pour le site entier, ou site:mondomaine.fr/chemin/page pour une page isolée. Google ajoute un détail que presque personne n’applique : désactiver SafeSearch avant le test, ce filtre pouvant écarter des résultats.

Trois lectures se présentent.

• aucun résultat : rien de ce domaine ne figure dans l’index, le blocage est en amont
• la page d’accueil seule ressort : la découverte des pages profondes échoue
• tout ressort : le sujet est un problème de classement, pas d’indexation

L’opérateur donne une indication, jamais un verdict. La même documentation rappelle qu’une page peut figurer très bas dans les résultats, ou être omise en raison des spécificités de la recherche.

Ce que la Search Console montre et que la SERP cache

Le rapport sur l’indexation des pages liste les URL connues de Google avec leur motif d’exclusion. C’est la seule source qui distingue une page jamais découverte d’une page explorée puis écartée, ce qu’aucune recherche publique ne montre.

Les états à repérer en premier : exclusion par la règle noindex, blocage par le fichier robots.txt, page en double sans URL canonique sélectionnée par l’utilisateur, page comportant une redirection, soft 404. Chacun renvoie à une cause technique précise, traitée plus bas.

L’outil d’inspection d’URL, le seul verdict page par page

La Search Console propose une inspection unitaire qui répond à la question réelle. Google y affiche « Cette URL est sur Google » ou « Cette URL n’a pas été indexée par Google », en précisant que la première mention ne garantit pas l’apparition dans les résultats.

Trois informations valent le détour dans ce panneau. L’URL canonique retenue par Google, qui révèle les regroupements involontaires. La date de la dernière exploration, qui date le problème. Le bouton de test en direct, qui interroge la page telle qu’elle répond maintenant et fournit une capture de son rendu par Google-InspectionTool. L’accès suppose d’être propriétaire ou utilisateur complet de la propriété.

Sans propriété vérifiée, le diagnostic reste aveugle. Déclarer le site et valider la propriété, par enregistrement DNS ou par fichier déposé à la racine, précède donc toute correction.

Le site est récent : le délai que Google annonce lui-même

Sur un domaine mis en ligne depuis moins d’un mois, l’absence de résultats est le comportement attendu, pas une anomalie.

Les ordres de grandeur documentés

L’aide de la Search Console est directe : si votre page ou votre site sont nouveaux, attendez quelques jours que Google les détecte et les explore. Elle ajoute qu’une fois l’URL connue, quelques semaines au maximum peuvent s’écouler avant l’exploration du site en totalité ou en partie. La documentation Search Central reprend la même échelle pour la réexploration : plusieurs jours, voire plusieurs semaines.

Détectée, explorée, indexée : trois états distincts

Le rapport d’indexation sépare des situations que le langage courant confond.

• détectée, actuellement non indexée : la page est connue de Google mais pas encore explorée, souvent pour ne pas surcharger le serveur
• explorée, actuellement non indexée : la page a été explorée puis écartée, Google conseillant de ne pas la renvoyer pour exploration
• indexée : la page figure dans la base et peut apparaître selon les requêtes

Le premier état appelle de la patience et un serveur qui répond vite. Le second est un signal éditorial, pas technique.

Accélérer la découverte sans s’épuiser

Trois leviers existent, dans cet ordre d’efficacité.

• publier un fichier sitemap déclaré dans la Search Console, la voie recommandée par Google dès qu’il y a un grand nombre d’URL, notamment après un lancement ou une migration
• soigner la navigation interne : Google écrit que si la page d’accueil est sur Google et si le site propose une navigation de qualité, il devrait pouvoir trouver toutes les pages
• demander l’exploration d’une poignée d’URL avec l’outil d’inspection, réservé à quelques adresses

Le quatrième levier n’existe pas. Google précise qu’un quota limite l’envoi d’URL individuelles et que les demandes répétées de réexploration d’une même URL n’accélèrent rien. Les fondations décrites dans notre guide pour créer un premier site internet évitent d’ailleurs la moitié des blocages qui suivent.

Quand la découverte n’est pas en cause et que l’invisibilité tient à l’architecture du site, à son autorité ou à sa présence dans les moteurs de réponse génératifs, le diagnostic sort du périmètre d’une checklist technique et demande un accompagnement spécialisé en référencement. L’agence parisienne Triaina traite le SEO et le référencement dans les moteurs IA sur un même périmètre, de l’audit au suivi des citations : en savoir plus.

Les blocages techniques, du plus fréquent au plus rare

Passé le délai normal, la cause est presque toujours une consigne posée volontairement, puis oubliée.

La balise noindex restée en place après la mise en ligne

C’est le premier suspect sur un site refondu. La balise noindex protège une préproduction, survit à la bascule, et neutralise le site entier sans le moindre message d’erreur. Elle vit dans le code source de la page ou dans un en-tête de réponse HTTP, et la plupart des gestionnaires de contenu l’exposent derrière une case à cocher relative à la visibilité par les moteurs.

Un piège se referme souvent à ce stade. Google écrit que pour que la règle noindex soit efficace, la page ne doit pas être bloquée par un fichier robots.txt : si le robot n’accède pas à la page, il ne détecte pas la règle. L’inverse est vrai aussi, ce qui donne des sites verrouillés deux fois et impossibles à débloquer d’un seul geste.

Une règle Disallow trop large

Une ligne Disallow: mal calibrée à la racine coupe l’exploration du site entier. L’erreur classique consiste à croire que ce fichier retire une page des résultats : il empêche l’exploration, pas l’indexation.

La documentation officielle est nette sur ce point : une page non autorisée dans le fichier robots.txt peut toujours être indexée si d’autres sites la référencent, l’adresse et parfois le texte d’ancrage des liens continuant de figurer dans les résultats. Pour empêcher réellement l’affichage, Google renvoie vers trois méthodes : protection par mot de passe, règle noindex, ou suppression de la page.

Canoniques et redirections mal posées

Une URL canonique unique déclarée sur tout le site, souvent héritée d’un thème mal configuré, concentre l’index sur une seule adresse et efface les autres. Google traite l’annotation comme un signal fort, pas comme une directive : il choisit lui-même la version qu’il juge la plus pertinente, et ignore parfois la déclaration.

Trois erreurs reviennent en audit. Une canonique pointant vers une page redirigée ou bloquée. Une canonique combinée à une règle noindex, qui empêche la sélection. Un usage du robots.txt pour canonicaliser, que la documentation déconseille explicitement.

HTTP, certificat expiré, contenu mixte

Le chiffrement ne fait pas sortir un site des résultats à lui seul. Le billet publié par Google Search Central le 6 août 2014 qualifie le HTTPS de signal léger, affectant moins de 1 % des requêtes mondiales et pesant moins que la qualité du contenu. Un certificat expiré produit en revanche un avertissement plein écran qui vide la page de ses visiteurs. La Search Console dispose depuis septembre 2022 d’un rapport listant les URL servies en HTTP. Les cas concrets, du contenu mixte au renouvellement automatisé, sont détaillés dans notre guide sur le certificat SSL et le passage en HTTPS.

Quand Googlebot ne voit pas la même page que vous

Un site parfaitement lisible dans un navigateur peut arriver vide chez le robot. Le symptôme est trompeur, parce que rien ne se voit à l’œil nu.

Le rendu JavaScript et sa file d’attente

Google décrit son traitement en trois phases : exploration, affichage, indexation. Les pages qui répondent en code 200 sont mises en file d’attente pour l’affichage, exécuté dans un environnement Chromium sans interface. La documentation précise qu’une page peut rester dans cette file quelques secondes ou davantage, le temps que les ressources nécessaires se libèrent.

Sur une application monopage dont le contenu s’injecte après le chargement, ce rendu JavaScript décale l’indexation et la rend dépendante de l’exécution du script. Un rendu côté serveur, ou une prégénération, supprime la dépendance.

Les ressources bloquées à l’insu du site

Interdire les répertoires de scripts et de feuilles de style dans le robots.txt reste une habitude héritée des années 2010. Google le formule simplement : si l’URL est marquée comme non autorisée, le robot n’envoie pas la requête HTTP pour cette URL. La page s’affiche alors sans mise en forme ni contenu dynamique.

Le test en direct de l’outil d’inspection tranche en une minute, capture de rendu à l’appui. Ce contrôle rejoint la logique décrite dans notre méthode pour diagnostiquer un site web lent : mesurer ce que la machine reçoit, pas ce que l’écran affiche.

Soft 404 et pages coquilles

Une page qui renvoie un code 200 tout en affichant un message d’absence est classée en soft 404. Google conseille alors deux corrections : renvoyer un véritable code HTTP 404, ou ajouter du contenu significatif à la page. Les catégories vides et les pages de recherche interne alimentent l’essentiel de cette famille.

Le site est indexé mais reste introuvable

Si l’inspection confirme l’indexation, le chantier change de nature : aucune correction technique ne fera remonter une page jugée sans intérêt sur la requête visée.

Contenu trop mince ou dupliqué

Les règles anti-spam de Google Search Central visent l’abus de contenu à grande échelle, défini comme la production massive de pages sans valeur ajoutée pour l’utilisateur, y compris lorsqu’elle passe par des outils génératifs. Le billet de mars 2024 accompagnant la mise à jour principale a élargi ce périmètre.

Le contenu dupliqué interne produit un effet voisin sans pénalité : Google regroupe les pages proches et n’en retient qu’une. Les fiches déclinées par ville sur le même texte en sont l’exemple type. Nos repères sur les limites du contenu généré et sa détection précisent où se situe la ligne.

Aucun maillage, aucun lien entrant

Une page orpheline, accessible seulement par son adresse directe, met longtemps à se faire découvrir et n’hérite d’aucune autorité interne. Les liens entrants externes jouent le même rôle à l’échelle du domaine, comme l’explique notre article sur le rôle des backlinks dans le référencement.

Deux gestes suffisent au démarrage : lier chaque nouvelle page depuis au moins deux pages existantes, et vérifier que le fil de navigation y mène en trois clics depuis l’accueil.

La requête est simplement trop concurrentielle

Le dernier cas n’est pas un défaut. Une page indexée qui sort en cinquantième position sur une requête disputée fonctionne normalement, elle vise trop haut. Le rapport de performances de la Search Console le montre en une minute : des impressions existent, sur des requêtes plus longues que celle espérée.

Redescendre d’un cran dans l’intention règle souvent le problème : viser la requête sur laquelle des impressions existent déjà, plutôt que celle inscrite au cahier des charges.

Le cas rare : une action manuelle

L’aide de la Search Console définit le mécanisme sans détour : lorsqu’un examinateur manuel de l’équipe Google détermine que des pages d’un site ne respectent pas les règles concernant le spam, Google initie une action manuelle contre ce site, qui ne s’affichera plus en totalité ou en partie dans les résultats.

Une action manuelle se lit dans un rapport dédié de la Search Console, jamais ailleurs. Aucun outil tiers ne la détecte, et son absence dans ce rapport élimine définitivement l’hypothèse. Après correction, la demande de réexamen doit décrire précisément les mesures prises. Google annonce un traitement de plusieurs jours à plusieurs semaines, plus long pour les demandes liées aux liens.

Prochaine étape

Reprenez le diagnostic dans cet ordre, en vous arrêtant à la première anomalie trouvée.

1. lancer une recherche site:mondomaine.fr, SafeSearch désactivé
2. inspecter l’URL d’accueil et une URL profonde dans la Search Console
3. ouvrir le fichier robots.txt et chercher les lignes Disallow: actives
4. lire la source d’une page publiée et vérifier l’absence de noindex
5. contrôler l’URL canonique retenue par Google sur trois pages
6. lancer un test en direct et regarder la capture de rendu
7. ouvrir le rapport des actions manuelles
8. vérifier les impressions dans le rapport de performances

Comptez une heure pour ces huit points sur un site de quelques dizaines de pages. Si tout est propre et que le site est bien indexé, le chantier n’est plus technique : il porte sur le contenu et sur les liens, avec des effets lisibles en trois à six mois.