Reconnaître une exclusion restée après la préproduction
Les pages publiques fonctionnent, mais la Search Console signale une exclusion par noindex après le lancement. Une consigne préparée pour la copie de travail a peut-être été transférée avec la base, un réglage SEO ou la configuration de l’hébergement. Le résultat recherché est de retirer cette consigne sur les pages destinées au public, tout en conservant les exclusions utiles ailleurs.
Noindex demande aux moteurs qui le prennent en charge de ne pas indexer la ressource. Il peut être transmis dans une balise du document HTML ou dans un en-tête HTTP X-Robots-Tag. Une seule de ces sources peut suffire à maintenir l’exclusion ; corriger la case visible dans WordPress ne garantit donc pas que la réponse finale soit corrigée.
Commencez par observer une page effectivement concernée et sa version actuelle. Un ancien résultat d’inspection peut décrire l’état précédent. Si aucune directive n’est retrouvée dans les réponses actuelles et si le test en ligne n’en détecte plus, ne modifiez pas les réglages au hasard : consignez la correction déjà effective et suivez sa prise en compte.
Définir les pages publiques et celles qui doivent rester exclues
Avant d’agir, choisissez quelques pages publiques touchées et un contenu qui doit conserver son exclusion volontaire, s’il en existe. Séparez aussi le domaine de production et la préproduction. Leurs réglages peuvent se ressembler alors que leur destination reste différente. Vous devez savoir où la correction sera appliquée et où elle ne doit pas être propagée.
Ce parcours demande un compte administrateur pour les réglages généraux, des droits de contenu pour un réglage de page, et un accès autorisé aux fichiers pour une ancienne règle serveur. Conservez les valeurs initiales et une sauvegarde adaptée de la base et des fichiers avant une intervention technique. Sur copie, neutralisez les envois et synchronisations pendant l’essai.
Noindex n’est pas un contrôle d’accès : une personne disposant de l’URL peut encore consulter une page non protégée. La copie de travail et les documents privés demandent une protection adaptée, indépendamment de l’indexation. Si le site entier n’est pas prêt à être public, ne retirez pas son exclusion seulement pour faire disparaître un avertissement. Faites d’abord valider le périmètre de lancement.
Rechercher la directive dans le document réellement reçu
Ouvrez une page publique concernée sans connexion WordPress. Affichez son code source depuis le navigateur et recherchez noindex, puis les balises dont le nom est robots ou googlebot. Lisez le contenu de la balise plutôt que de compter les occurrences du mot : un article peut simplement parler de noindex dans son texte, sans transmettre cette consigne aux moteurs.
Une balise robots applicable à tous les moteurs et une balise googlebot peuvent coexister. La valeur none correspond aussi à une exclusion associée à l’absence de suivi des liens. Ajouter index à une autre balise ne neutralise pas une consigne restrictive qui reste applicable. Il faut retirer ou corriger la source non souhaitée.
Notez l’URL finale, la balise exacte et l’heure du relevé. Comparez l’accueil et une page intérieure. Si une seule page est touchée, privilégiez son réglage individuel ; si toutes les pages d’un même type le sont, examinez le réglage de ce type. L’absence de balise noindex dans le HTML n’écarte pas l’en-tête HTTP, traité à l’étape suivante.
Si le résultat Google contredit ce premier relevé, utilisez aussi Afficher la page testée dans l’inspection active pour examiner le HTML rendu. Un script peut modifier les balises après le téléchargement. En revanche, ne cherchez pas à supprimer par JavaScript un noindex livré dans le document initial : Google peut décider de ne pas exécuter ce JavaScript. Corrigez la source de la directive initiale.
Contrôler X-Robots-Tag dans les en-têtes de réponse
Un en-tête HTTP est transmis avec la réponse du serveur, en dehors du code HTML. Il peut être ajouté par WordPress, le serveur, un proxy ou un CDN. Ce contrôle ne demande aucune extension : utilisez votre navigateur et observez la vraie page publique, pas une prévisualisation de l’éditeur.
Le résultat attendu est de savoir si X-Robots-Tag contient noindex ou none pour cette ressource. Une occurrence dans les en-têtes de requête que vous envoyez n’a pas le même rôle qu’une occurrence dans les en-têtes de réponse. N’utilisez pas les fonctions de remplacement local des réponses : elles changeraient seulement votre observation.
Contrôlez l’URL HTML de la page à publier, pas seulement son sitemap. Yoast ajoute normalement noindex, follow aux réponses de ses sitemaps XML pour éviter leur affichage comme résultats ordinaires. Cela n’empêche pas Google de lire le sitemap ni ne transmet cette exclusion aux pages qu’il énumère. Ne retirez donc pas cet en-tête du sitemap pour réparer une page différente.
- Dans Chrome, ouvrez les outils de développement, puis Réseau.
- Avec le panneau ouvert, rechargez la page et sélectionnez la ligne du document principal, souvent de type Doc.
- Ouvrez En-têtes, puis En-têtes de réponse et recherchez X-Robots-Tag.
- S’il y a plusieurs lignes ou une restriction destinée à un robot précis, relevez-les toutes avec leur valeur.
- Si la navigation redirige, examinez aussi la réponse de la page finale. Gardez les éléments utiles sans partager les cookies ou une exportation complète du trafic.
Effectuer un contrôle GET facultatif avec curl
Avec un terminal autorisé, vous pouvez lire les en-têtes d’une page publique sans recevoir son corps à l’écran. L’exemple vise une adresse fictive à remplacer par la page exacte. Il effectue un GET, comme une lecture ordinaire ; un HEAD peut être traité différemment par certaines configurations. Il ne suit pas automatiquement une redirection, ce qui permet de remarquer une réponse intermédiaire.
Sous Linux, utilisez la commande ci-dessous. Sous Windows, remplacez curl par curl.exe et /dev/null par NUL. Le paramètre -q, placé en premier, évite une configuration personnelle qui modifierait l’essai. Les délais limitent l’attente côté client. Aucun cookie ni identifiant n’est ajouté.
Recherchez X-Robots-Tag dans la réponse, ainsi que le statut. Si l’adresse redirige, vérifiez sa destination avant de refaire une lecture de cette URL finale. Le résultat dépend du contexte réseau et ne reproduit pas nécessairement Googlebot. Ce contrôle ne modifie aucun réglage ; conservez ses résultats dans un emplacement privé, car d’autres en-têtes peuvent contenir des informations sensibles. Sans --fail, une commande terminée avec le code de sortie 0 peut avoir reçu un statut HTTP 403 : lisez la ligne HTTP, pas seulement l’absence d’erreur du terminal.
curl -q --silent --show-error --connect-timeout 5 --max-time 15 --dump-header - --output /dev/null 'https://exemple.invalid/page-publique/'Choisir la source à corriger avant d’écrire
Rassemblez les observations par page : présence d’une balise, présence d’un en-tête, réglage global, réglage individuel et couche de cache connue. Il peut y avoir plusieurs causes simultanées. Une correction utile retire une consigne non voulue à son origine, puis contrôle de nouveau la réponse finale.
Commencez par Réglages, Lecture lorsque toutes les pages publiques sont touchées après copie de la base. Examinez ensuite le gestionnaire SEO déjà utilisé si le défaut suit une page ou un type de contenu. Si un en-tête persiste malgré des réglages WordPress corrects, cherchez la règle de l’hébergement ou du service intermédiaire avec son responsable.
N’installez pas un second plugin SEO pour ajouter une balise index par-dessus une exclusion existante. Ne désactivez pas non plus toutes les sorties robots du site : certaines sont adaptées aux recherches internes ou à des contenus qui ne doivent pas entrer dans l’index. Si l’origine n’est pas certaine, reproduisez sur une copie et modifiez une seule couche. Gardez la réponse avant et après ; elle permet de distinguer un réglage enregistré d’un effet réellement livré.
Corriger le réglage natif de WordPress
Ce parcours convient à un site prêt pour le public dont la case de découragement est encore cochée. Il exige les droits sur Réglages, Lecture. Le cœur utilise l’option blog_public pour ajouter une consigne noindex selon la configuration du site ; retirer la demande globale permet de cesser cette exclusion native, sans imposer l’indexation de tous les contextes.
Le résultat attendu se vérifie dans une nouvelle réponse publique. Il n’est pas nécessaire qu’une balise explicite index apparaisse : l’objectif est de retirer la consigne noindex non voulue. Si elle persiste, poursuivez la recherche de sa source plutôt que de cocher et décocher à répétition.
- Dans le tableau de bord de la production confirmée, ouvrez Réglages, Lecture.
- Notez l’état de Visibilité pour les moteurs de recherche.
- Décochez Demander aux moteurs de recherche de ne pas indexer ce site, puis cliquez sur Enregistrer les modifications.
- Rechargez une page témoin sans connexion et contrôlez sa balise ainsi que ses en-têtes.
- Si l’ouverture doit être annulée, remettez la seule valeur initiale dans ce même écran. Cela ne rend pas le site confidentiel et ne supprime pas immédiatement une page déjà indexée.
Corriger une page dans Yoast SEO déjà installé
Si Yoast SEO gère déjà les métadonnées du site, son réglage individuel peut maintenir l’exclusion malgré la correction native. Cette fonction existe dans la version gratuite ; il n’est pas nécessaire d’acheter Premium pour ce contrôle. Au 3 novembre 2026, le répertoire affiche Yoast SEO 28.8, par Yoast, demandant WordPress 7.0 et PHP 7.4 minimum, avec un test déclaré jusqu’à WordPress 7.1.4. Ces minima ne sont pas une recommandation d’utiliser un ancien PHP.
Utilisez la documentation adaptée si votre version installée est différente, sans mettre à jour le site pendant ce seul diagnostic. Le réglage avancé est accessible par défaut aux éditeurs et administrateurs. Conservez la valeur antérieure pour revenir sur cette page uniquement.
- Ouvrez la page concernée dans l’éditeur WordPress.
- Ouvrez la barre latérale Yoast SEO depuis son icône en haut à droite, ou sa boîte sous l’éditeur, puis Advanced, ou Avancé selon la langue.
- Sous Allow search engines to show this content in search results, sélectionnez Yes pour ce contenu public approuvé.
- Enregistrez la mise à jour de la page, puis vérifiez la réponse publique complète.
- Si le changement ne correspond pas à l’intention éditoriale, rétablissez la valeur initiale et enregistrez de nouveau ; ne modifiez pas toutes les pages.
Corriger un type de contenu seulement si toute cette famille est concernée
Lorsque tous les articles ou toutes les pages publiques d’un type sont exclus, examinez son réglage collectif dans Yoast. Cette opération a une portée plus large qu’un réglage individuel. Faites vérifier les contenus de cette famille avant de l’activer : elle peut comprendre des pages qui n’étaient pas destinées à la recherche.
Dans Yoast SEO, Settings, puis Content types, choisissez le type exact, par exemple Pages. Dans Search appearance, activez le réglage Show [type] in search results, puis cliquez sur Save changes. Conservez l’état initial. Pour annuler ce seul essai, remettez la valeur précédente du même type et enregistrez, sans modifier les autres familles ni les archives.
Contrôlez au moins une page qui suivait le réglage collectif et une page possédant une exclusion individuelle volontaire. La seconde doit conserver son intention. Yoast utilise également ces choix pour le sitemap : un changement de visibilité peut donc faire évoluer sa liste d’URL. Vérifiez-la, sans lancer un autre générateur pour compenser un résultat inattendu. Si l’exclusion persiste dans la réponse publique, examinez encore les réglages individuels, le code et les en-têtes.
Désactiver une ancienne règle Apache précisément identifiée
Cette approche avancée convient uniquement si Apache ajoute encore un en-tête noindex par une règle héritée de la préproduction. Elle demande l’accès autorisé au fichier qui gouverne la réponse et une copie privée permettant son rétablissement. Une règle peut se trouver dans le .htaccess du répertoire public réel, dans un parent ou dans une configuration gérée par l’hébergeur ; ne créez pas un nouveau fichier au hasard.
L’exemple ci-dessous montre une ancienne directive rendue inactive par un commentaire. Il sert à remplacer cette seule directive si vous l’avez réellement retrouvée et attribuée à l’exclusion abandonnée sur la production. Ajouter ce commentaire ailleurs ne neutralise aucune règle existante. Préservez les autres lignes et les conditions qui protègent encore des chemins spécifiques.
Sur copie, commentez uniquement la ligne confirmée, enregistrez et relisez les en-têtes de la même page. Le résultat attendu est la disparition de cet en-tête, sans erreur serveur. Si une panne apparaît, rétablissez immédiatement le fichier conservé. Si la directive relève d’une configuration centrale ou d’un autre serveur, faites intervenir son responsable ; un .htaccess local ne corrige pas une règle Nginx ou CDN. Dans une configuration centrale, faites valider la syntaxe et appliquer le rechargement par l’administrateur du serveur. Une modification de .htaccess est généralement prise en compte à la requête suivante ; ne redémarrez pas tout le serveur pour cet exemple.
# Ancienne directive de préproduction désactivée sur le domaine public :
# Header always set X-Robots-Tag "noindex"Retrouver le propriétaire d’une consigne ajoutée par du code
Si les réglages usuels sont corrects mais que le HTML transmet encore noindex, du code du thème, d’une extension ou d’un module obligatoire peut l’ajouter. Demandez au mainteneur de rechercher la sortie exacte et les filtres robots dans les composants de la copie. WordPress rassemble ses directives par le filtre wp_robots, mais d’autres composants peuvent produire leurs propres balises.
Ne retirez pas globalement la fonction wp_robots et ne videz pas tous ses paramètres pour obtenir une page sans balise. Cette méthode effacerait aussi des directives utiles dans des contextes où l’exclusion reste voulue. Faites corriger la condition ou le réglage du composant propriétaire, avec son fichier initial conservé et un essai sur les pages du périmètre.
Pour un en-tête seulement, étendez la recherche aux réglages de l’hébergement, aux réponses du proxy et au CDN déjà présent. Une règle appliquée après WordPress peut rester active malgré une correction PHP. Évitez une instruction générale de suppression de X-Robots-Tag sur tout le domaine : des fichiers PDF ou des chemins particuliers peuvent avoir une exclusion volontaire. Contrôlez la réponse livrée après toutes les couches.
Contrôler les caches et les prochains déploiements
Un cache de page peut continuer à servir l’ancien HTML contenant noindex. Une couche intermédiaire peut aussi conserver les anciens en-têtes. Corrigez d’abord leur source, puis invalidez les seules copies concernées avec la procédure de votre système existant. Une purge seule ne corrige pas la règle qui recréera l’exclusion à la prochaine réponse.
Après invalidation, vérifiez la page sans connexion, puis une nouvelle lecture une fois le cache reconstitué. Si l’exclusion revient seulement après un déploiement ou une synchronisation, examinez ce qui est recopié : option globale de la base, métadonnées de page, fichier de configuration ou règle de l’hébergement. Notez l’étape qui réintroduit la valeur au lieu de corriger manuellement chaque lendemain de livraison.
Préparez une différence explicite entre les environnements dans la procédure de déploiement. Le domaine de production doit conserver les réglages approuvés pour ses contenus publics, tandis que la copie garde son traitement propre. Ne synchronisez pas toute la base active pour faire passer un seul réglage : des commandes, comptes ou nouveaux contenus pourraient être écrasés. La correction et son contrôle doivent appartenir à la liste de vérification de chaque mise en ligne.
Vérifier le résultat et préserver les exclusions voulues
Reprenez les pages témoins sur la production et notez l’heure de chaque contrôle. La consigne non voulue doit avoir disparu du HTML et des en-têtes applicables. Une balise index ajoutée ne suffit pas si une autre source maintient noindex. Comparez aussi le contenu réellement affiché et l’adresse finale, afin de ne pas valider une autre page par erreur.
Contrôlez ensuite un exemple de contenu volontairement exclu et la préproduction protégée. Leurs protections et intentions doivent rester cohérentes. Sur WordPress.com, les réglages de visibilité du site restent distincts ; un site privé ou non lancé ne doit pas être rendu public par accident pendant une recherche de noindex. En multisite, confirmez que seuls le site et les composants visés ont été modifiés.
Conservez un relevé avant/après avec la cause et le changement exact. Si le résultat n’est pas celui attendu, revenez sur ce seul changement avant de poursuivre une autre piste. Une directive présente uniquement dans une réponse réservée à votre session ne décrit pas forcément la réponse publique : répétez le contrôle dans les conditions correspondant au visiteur et au robot concernés.
Faire constater la nouvelle version par Google
Dans la Search Console, inspectez l’URL finale de la page publique, puis comparez le dernier état connu avec Tester l’URL active. L’ancien motif d’exclusion peut persister dans les données historiques alors que la réponse actuelle est corrigée. Le test en ligne permet de vérifier certains obstacles actuels, sans promettre l’inclusion dans l’index.
Google doit pouvoir explorer la page pour constater ses directives. Ajouter un blocage robots.txt afin de résoudre noindex empêche cette observation et ne constitue pas une correction. Si les deux obstacles existent, traitez-les selon leur portée réelle. Google ne prend pas en charge une instruction noindex écrite dans robots.txt.
Ne remplacez pas ce travail par une modification de canonical. Cette indication sert à proposer une version préférée parmi des contenus proches ; elle n’annule pas une directive noindex encore applicable. De même, ajouter une URL au sitemap ne neutralise pas son exclusion. Confirmez d’abord la réponse de la page elle-même.
Après une modification utile et les contrôles, utilisez Demander une indexation pour quelques pages importantes avec l’accès autorisé, ou laissez le sitemap et les liens ordinaires assurer leur découverte. Les demandes répétées n’accélèrent pas le traitement et aucune date n’est garantie. Transmettez au responsable SEO les URL, la source retirée, les relevés actuels et la date de correction. Gardez distinctes la réparation de la directive et la décision ultérieure d’indexer la page.
