Site invisible sur Google : les 5 points que je vérifie en premier

« Mon site est en ligne mais personne ne le trouve »

C'est la phrase que j'entends le plus souvent. Le site est beau, rapide, bien construit. Et pourtant : zéro trafic organique, zéro position dans Google, comme si la page n'existait pas.

Avant de chercher des solutions complexes, je commence toujours par vérifier les mêmes cinq choses, dans le même ordre.

Parce que dans 80 % des cas, le problème est simple. Juste invisible depuis l'intérieur.

1. Google connaît-il seulement l'URL ?

Première question, pas évidente : est-ce que Google a déjà vu cette page ?

Dans la Search Console, l'outil « Inspection d'URL » répond en cinq secondes. Si la réponse est « Google ne reconnaît pas cette URL », tout le reste est secondaire. Il faut d'abord se faire connaître.

Les causes courantes : un sitemap absent ou en erreur, une directive noindex oubliée dans le code, un robots.txt trop restrictif, ou simplement un site trop récent auquel Google n'a pas encore eu le temps de passer.

2. Y a-t-il un `noindex` quelque part ?

Un noindex dans la balise robots d'une page, et Google s'arrête là. Il crawle, lit la directive, repart sans indexer. Aucun contenu, aucun titre, aucun backlink ne compense ça.

C'est l'erreur que je retrouve le plus souvent sur des sites développés rapidement : la directive était là pour les tests, personne ne l'a retirée avant la mise en production.

Endroit où vérifier : la balise <meta name="robots"> dans le <head>, les headers HTTP de la réponse serveur, et parfois les paramètres du CMS.

3. Le sitemap est-il propre ?

Un sitemap sert à dire à Google : « voilà les pages que je veux que tu trouves ». Mais un sitemap avec des erreurs, des URLs en 404, des pages noindex listées dedans — c'est pire qu'un sitemap absent.

Google le télécharge, trouve des incohérences, et fait moins confiance au reste.

Dans la Search Console, le rapport Sitemaps indique le nombre d'erreurs et l'écart entre les URLs soumises et les URLs réellement indexées. Un gros écart est un signal d'alerte direct.

4. Le contenu est-il réellement dans le HTML ?

Avec les frameworks JavaScript modernes (Next.js, Nuxt, SvelteKit…), il arrive que le contenu ne soit visible que côté client — il s'affiche dans le navigateur, mais le HTML brut envoyé par le serveur est vide.

Google rend le JavaScript, mais avec un délai. Les pages dont le contenu dépend d'un fetch client-side sont indexées plus lentement, moins bien, ou pas du tout.

Vérification rapide : clic droit > Afficher la source de la page (pas Inspecter, la source brute). Si le texte n'est pas là, il n'est pas rendu côté serveur.

5. La page mérite-t-elle de remonter ?

Dernière question, parfois difficile à entendre : est-ce que cette page apporte quelque chose que Google n'a pas déjà en dizaines d'exemplaires ?

Un site peut être techniquement parfait et ne pas remonter parce que son contenu est trop générique, trop court, ou ne répond à aucune question précise qu'un vrai utilisateur poserait.

L'index de Google, c'est une bibliothèque. Il n'y a pas de place pour dix exemplaires identiques du même livre.

Ce n'est pas un problème technique. C'est un problème de fond — et c'est souvent là que le vrai travail commence.

Par où commencer si les cinq cases sont cochées ?

Si le site est indexable, sans noindex, avec un sitemap propre, en SSR, et avec un contenu original — et qu'il ne remonte toujours pas — alors on parle d'autorité, d'ancienneté du domaine, de signaux de confiance.

Ces problèmes se règlent sur la durée, pas en une nuit. Mais au moins, on travaille sur le bon problème.