WordPress « ne pas indexer ce site » : ce que change ce réglage

Dans WordPress, la case « Demander aux moteurs de recherche de ne pas indexer ce site » (en anglais « Discourage search engines from indexing this site ») ajoute une balise meta robots noindex, nofollow sur chaque page publique du site. Google respecte cette balise : chaque page qu'il réexplore avec la balise sort de ses résultats de recherche, et les nouvelles pages n'y entrent pas. Sur une copie de préproduction privée, c'est l'effet recherché. Sur un site en ligne que vous voulez voir dans Google, décochez-la tout de suite : elle retire le site entier de Google, une réexploration après l'autre, sans que rien ne change pour les visiteurs.

Ce que le réglage produit dans la version actuelle de WordPress

La case se trouve dans Réglages → Lecture, sur la ligne « Visibilité pour les moteurs de recherche », et l'installateur de WordPress propose la même case sur son écran de configuration. Elle enregistre une seule valeur dans la base de données : l'option blog_public, à 0 quand la case est cochée et à 1 quand elle ne l'est pas. Nous avons vérifié ce que change cette valeur dans le code source du cœur de WordPress en octobre 2026, alors que la version en cours était la 7.1.3 :

• Chaque page publique reçoit une balise meta robots. La sortie standard du head du thème contient cette ligne :

<meta name='robots' content='noindex, nofollow' />

• Le sitemap XML intégré se désactive. Le sitemap natif à l'adresse /wp-sitemap.xml renvoie une erreur 404, et la ligne Sitemap: disparaît du robots.txt généré par WordPress.
• Le robots.txt ne bloque rien de plus. Le fichier généré conserve son Disallow habituel pour l'espace d'administration et son Allow pour admin-ajax.php.
• Aucun en-tête HTTP n'est ajouté. Le cœur n'envoie aucun en-tête X-Robots-Tag pour ce réglage : le signal n'existe que dans le HTML.
• Le site reste public. Le texte sous la case indique « Certains moteurs de recherche peuvent décider de l'indexer malgré tout. » (en anglais : « It is up to search engines to honor this request. »). Les visiteurs, et tout robot qui ignore les balises meta robots, peuvent toujours lire chaque page.
• Les administrateurs ont un seul rappel. Le widget « D'un coup d'œil » du tableau de bord affiche la ligne « Moteurs de recherche refusés » tant que la case est cochée.

Si votre tableau de bord est en espagnol, le libellé dépend de la variante linguistique. Le projet de traduction de WordPress, consulté en octobre 2026, traduit l'option par « Disuade a los motores de búsqueda de indexar este sitio » pour le Mexique, l'Argentine, la Colombie et plusieurs autres variantes latino-américaines, et par « Pedir a los motores de búsqueda que no indexen este sitio » pour l'espagnol d'Espagne. Dans la plupart des variantes espagnoles, la ligne s'appelle « Visibilidad en los motores de búsqueda » sur l'écran « Ajustes de lectura », et dans toutes, la ligne du tableau de bord indique « Motores de búsqueda disuadidos ».

Comment le comportement du réglage a évolué selon les versions de WordPress

Des conseils rédigés pour d'anciennes versions circulent encore et décrivent un autre mécanisme. Le code source du cœur montre 3 étapes :

Le changement de la 5.3 est le plus important. Auparavant, le robots.txt généré interdisait le site entier à tous les robots : Google ne récupérait donc pas les pages et ne voyait jamais leur balise noindex. Les URL qui recevaient des liens d'autres sites pouvaient rester dans l'index de Google sans être explorées, ce que la Search Console signale par le statut « Indexée malgré le blocage par le fichier robots.txt » ; la page consacrée à ce statut explique ce conflit. Depuis la 5.3, la case ne touche plus au robots.txt et repose uniquement sur la balise meta. Sur un site actuel, un Disallow: / provient d'un fichier robots.txt physique, d'une extension ou de l'hébergeur, jamais de cette case.

Pourquoi le réglage se retrouve sur un site en production

Le scénario habituel : un site de préproduction correctement masqué, puis une mise en ligne qui copie sa base de données. Les extensions de migration, les outils de « mise en production » des hébergeurs comme un export-import manuel déplacent tous la table des options, et blog_public voyage avec elle. Le seul changement visible est une ligne dans le head de la page, qu'aucun visiteur ne lit.

sequenceDiagram
    participant S as Site de préproduction
    participant P as Site de production
    participant G as Googlebot
    S->>S: Case cochée, blog_public vaut 0
    S->>P: Base de données copiée à la mise en ligne
    P->>P: blog_public vaut toujours 0
    G->>P: Réexplore la page d'accueil et les articles
    P-->>G: HTML avec noindex, nofollow
    G->>G: Retire des résultats chaque page réexplorée

Sur 45 sites externes audités par SEOReport entre mai et octobre 2026, aucun ne servait de page d'accueil portant une directive noindex, que ce soit dans le HTML ou dans un en-tête X-Robots-Tag. Un échantillon de cette taille ne permet pas de dire à quelle fréquence l'erreur se produit, seulement qu'elle n'est pas courante. Quand elle survient, elle touche toutes les pages publiques à la fois : c'est pourquoi elle a sa place dans chaque checklist de mise en ligne.

Comment vérifier le réglage hors du tableau de bord

Ce qui compte, c'est le HTML que reçoit un visiteur non connecté, après tout cache de page ou CDN, car c'est ce que Google récupère. Remplacez example.com par votre domaine, et répétez les 2 premières commandes sur 2 ou 3 articles en plus de la page d'accueil. L'option -L suit les redirections : un passage du domaine nu vers www ou vers HTTPS ne masque donc pas la page finale.

# 1. The robots meta tag in the served HTML
curl -sL https://example.com/ | grep -io "<meta[^>]*name=.robots[^>]*>"

# 2. Any noindex sent as an HTTP header instead
curl -sL -o /dev/null -D - https://example.com/ | grep -i "x-robots-tag"

# 3. What robots.txt actually serves
curl -sL https://example.com/robots.txt

# 4. Whether the core sitemap is switched off
curl -sL -o /dev/null -w "%{http_code}\n" https://example.com/wp-sitemap.xml

Un noindex dans le premier résultat, associé à une erreur 404 pour le quatrième, correspond à ce réglage. Une extension SEO peut remplacer le sitemap natif par le sien : une 404 seule ne prouve donc rien. Un noindex dans le deuxième résultat est une règle d'en-tête posée par le serveur, l'hébergeur, le CDN ou une extension, et la case ne peut pas la supprimer.

Depuis WordPress, la confirmation la plus rapide est la ligne « Moteurs de recherche refusés » du tableau de bord. Avec un accès en ligne de commande, wp option get blog_public affiche 0 quand la case est cochée et 1 quand elle ne l'est pas.

flowchart TD
    A["Le HTML en ligne contient-il un meta robots noindex ?"] -->|oui| B["blog_public vaut-il 0 ?"]
    A -->|non| C["L'en-tête X-Robots-Tag contient-il noindex ?"]
    C -->|oui| D["Supprimer la règle du serveur, de l'hébergeur ou du CDN"]
    C -->|non| E["La page en ligne est indexable : demander une réexploration"]
    B -->|oui| F["Décocher la case et purger les caches"]
    B -->|non| G["Une extension ou le thème ajoute noindex : vérifier ses réglages"]
    F --> H["HTML en ligne propre sur l'accueil et les articles ?"]
    G --> H
    H -->|non| I["Un cache sert encore l'ancien HTML : le purger"]
    I --> H
    H -->|oui| J["Test en direct dans l'inspection d'URL, puis Valider la correction"]

Comment le réglage apparaît dans la Search Console

À mesure que Google réexplore les pages et trouve la balise, elles passent du côté « Non indexées » du rapport sur l'indexation des pages, avec le motif « URL marquée "noindex" ». La documentation de Google sur ce rapport, consultée en octobre 2026, indique que la page n'a pas été indexée parce que Google a trouvé une directive noindex en tentant de l'indexer. Le basculement est progressif, car Google réexplore les pages à des moments différents. Notre guide du statut « URL marquée "noindex" » présente les autres causes de ce statut et les cas où il est voulu.

L'outil d'inspection d'URL montre les deux versions. La vue par défaut décrit la version que Google a indexée en dernier, et son champ « Indexation autorisée ? » indique si cette version interdisait l'indexation. « Tester l'URL en direct » récupère la page telle qu'elle est maintenant. Après une correction, fiez-vous au test en direct : la vue indexée ne change qu'après la réexploration de Google.

Un site mis en ligne avec la case cochée dès le jour 1 peut n'afficher que très peu d'URL dans le rapport. Le sitemap natif est désactivé, et nofollow demande à Google de ne pas suivre les liens de chaque page : Google n'a donc presque rien à partir de quoi découvrir des URL.

Extensions et règles serveur qui changent la donne

Les extensions SEO gèrent elles-mêmes la balise robots. Nous avons lu en octobre 2026 le code source de 2 extensions très utilisées, Yoast SEO et Rank Math : toutes deux forcent toujours noindex tant que la case est cochée, et toutes deux affichent un avertissement dans l'administration. Avec l'une ou l'autre active, décocher la case reste la solution.

Ces mêmes extensions peuvent maintenir un noindex après que la case a été décochée, via leurs propres réglages pour certains articles, types de contenu ou archives. N'importe quelle autre extension ou thème peut ajouter des directives via le même filtre robots de WordPress, par exemple une extension « bientôt disponible » ou « mode maintenance » restée active après la mise en ligne. Si le HTML en ligne affiche encore noindex alors que blog_public vaut 1, c'est dans ces réglages qu'il faut chercher.

La préproduction laisse 2 autres traces. Un fichier robots.txt physique contenant Disallow: / prend le pas sur le fichier généré : relisez donc le fichier en ligne après la mise en ligne, surtout si vous avez enregistré des règles robots.txt via une extension pendant que le site était masqué. Une règle d'en-tête qui ajoute X-Robots-Tag: noindex agit comme la balise meta, mais n'apparaît jamais dans le code source de la page : c'est pourquoi la vérification externe contrôle les deux. Notre guide du robots.txt et de l'accès à l'exploration explique comment lire le fichier ligne par ligne.

Comment rétablir l'indexation, et en combien de temps

1. Décochez la case et enregistrez, ou exécutez wp option update blog_public 1.
2. Purgez toutes les couches de cache : l'extension de cache de page, le cache de l'hébergeur et le CDN. Une page en cache continue de servir l'ancien head jusqu'à son expiration.
3. Relancez la vérification externe sur la page d'accueil et quelques articles, et vérifiez que /wp-sitemap.xml ou le sitemap de votre extension répond désormais 200.
4. Envoyez le sitemap dans le rapport Sitemaps de la Search Console, pour que Google dispose de la liste complète des URL à réexplorer. Notre guide des sitemaps XML détaille ce que doit contenir un sitemap propre.
5. Lancez un test en direct dans l'outil d'inspection d'URL sur la page d'accueil et vos pages les plus importantes, puis utilisez « Demander l'indexation » pour ces quelques pages. L'outil applique un quota aux URL individuelles, et la documentation de Google précise que des demandes répétées pour la même URL n'accélèrent pas l'exploration.
6. Ouvrez « URL marquée "noindex" » dans le rapport sur l'indexation des pages et sélectionnez « Valider la correction ».

Ensuite, patientez. La documentation de Google sur la réexploration, consultée en octobre 2026, indique que l'exploration peut prendre de quelques jours à quelques semaines, et sa documentation sur noindex précise qu'une nouvelle visite peut prendre des mois pour certaines pages. La documentation du rapport sur l'indexation des pages indique que la validation prend généralement jusqu'à 2 semaines environ, et parfois beaucoup plus. L'indexation elle-même reste une décision de Google : la documentation de l'outil d'inspection d'URL précise qu'une demande ne garantit pas l'apparition d'une page dans l'index.

Comment éviter que cela se reproduise à la prochaine mise en ligne

Protégez la préproduction par un mot de passe, via une authentification HTTP au niveau du serveur ou de l'hébergeur, au lieu de compter sur la case. Un identifiant arrête tous les visiteurs et tous les robots. Laissez la case décochée sur la copie protégée par mot de passe : Google ne peut pas lire une page derrière une connexion, la case n'y apporte donc rien, et une base de données copiée en production n'emporte alors aucun noindex. Ajoutez ensuite une ligne à la checklist de mise en ligne : lancer la vérification externe sur le domaine de production après la mise en ligne, puis après chaque migration ou restauration de base de données.

Un diagnostic complet SEOReport lit la balise meta robots et l'en-tête X-Robots-Tag de votre page d'accueil, ainsi que la balise meta robots des pages listées dans votre sitemap, et désigne chaque page qui demande aux moteurs de recherche de ne pas l'indexer. Un noindex sur la page d'accueil, que ce réglage produit toujours, est signalé comme un constat critique : le réglage est donc détecté même lorsqu'il a aussi désactivé le sitemap. Pour un site qui change souvent de mains ou d'hébergeur, la surveillance hebdomadaire, mise en place via l'API REST, réaudite le site et vous envoie un e-mail lorsqu'un nouveau constat critique apparaît. Le phénomène plus large des sites qui masquent leurs propres pages est traité dans nos données sur les conflits d'indexabilité et dans le guide de l'indexabilité des pages.

Questions fréquentes

Ce réglage bloque-t-il les robots d'IA ?

Non. Il n'ajoute aucune règle au robots.txt, et c'est généralement dans le robots.txt que se contrôle l'accès des robots d'IA. Il touche en revanche les fonctionnalités d'IA de Google : la documentation de Google sur ses fonctionnalités d'IA, consultée en octobre 2026, indique qu'une page doit être indexée pour apparaître comme lien de référence dans les Aperçus IA ou le Mode IA ; une page en noindex en disparaît donc aussi. Voyez la case comme une demande liée à l'indexation dans la recherche, pas comme une politique vis-à-vis de l'IA. Notre tableau de décision pour les robots d'IA dans le robots.txt explique comment en définir une en connaissance de cause.

J'ai décoché la case il y a des semaines et des pages affichent toujours « URL marquée "noindex" ». Pourquoi ?

La Search Console rapporte ce que Google a vu lors de sa dernière exploration de chaque page. Lancez d'abord « Tester l'URL en direct » : si le test en direct trouve encore un noindex, un cache, une extension ou une règle d'en-tête le sert. Si le test en direct est propre, la page attend d'être réexplorée, et « Valider la correction » accompagné d'un sitemap envoyé est la bonne étape suivante.

Puis-je cocher la case sans risque pendant la refonte d'un site en ligne ?

Non. Le réglage s'applique au site en ligne, et chaque page que Google réexplore pendant la refonte disparaît de ses résultats. Construisez plutôt la refonte sur une copie de préproduction protégée par mot de passe.