Désindexer une page WordPress - La méthode propre et efficace

Comprendre ce qu’on veut vraiment bloquer

Je distingue toujours trois questions avant de toucher au SEO d’une page: doit-elle rester visible pour les humains, doit-elle rester accessible seulement à certains, ou doit-elle simplement sortir de l’index? Si elle peut être visitée mais ne doit pas remonter dans Google, on parle de noindex. Si elle contient des données sensibles, je préfère une barrière d’accès en plus. Et si l’objectif est surtout d’économiser du crawl sur des URLs techniques, robots.txt peut aider, mais ce n’est pas une vraie stratégie d’indexation.

Le point que beaucoup ratent, c’est la différence entre crawl et indexation. Google Search Central rappelle qu’un fichier robots.txt n’est pas un moyen de cacher une page des résultats; il sert d’abord à gérer l’accès des robots au crawl. Autrement dit, si tu bloques la page avant d’avoir posé la directive adéquate, le robot ne voit pas toujours ce que tu veux lui faire comprendre. C’est pour ça que je commence toujours par qualifier le besoin réel avant de choisir l’outil.

Une page publique à garder accessible, une page privée et une page technique ne se traitent pas de la même manière. Une fois ce cadre posé, on peut passer à la mise en place concrète sur WordPress.

Appliquer un noindex propre sur une page WordPress

Dans WordPress, la voie propre consiste à ajouter la directive au niveau de la page, pas à tout le site. La documentation WordPress expose le filtre wp_robots pour ce genre de réglage au cas par cas, et c’est celui que je privilégie quand je veux garder la main sur une URL précise.

add_filter( 'wp_robots', function( array $robots ) {
    if ( is_page( 'page-privee' ) ) {
        return wp_robots_no_robots( $robots );
    }

    return $robots;
} );

Dans ce type de règle, is_page() peut cibler un identifiant, un slug ou un titre. C’est pratique, parce qu’on peut viser une page précise sans bricoler tout le thème. Si la page est sensible, je préfère souvent wp_robots_sensitive_page(), qui ajoute aussi noarchive et limite les traces laissées dans les résultats. Pour ma part, je place ce genre de logique dans un mini-plugin ou un mu-plugin plutôt que dans un thème amené à changer.

Après ça, je purge systématiquement le cache WordPress et, si un plugin SEO a généré un sitemap XML, je vérifie que l’URL n’y figure plus. Sinon, tu envoies des signaux contradictoires aux moteurs. La question suivante devient alors: faut-il vraiment passer par noindex, ou une autre méthode est plus adaptée au contexte?

Choisir entre noindex, robots.txt, X-Robots-Tag et mot de passe

Quand j’hésite entre plusieurs techniques, je regarde surtout la nature du contenu et le niveau de contrôle dont je dispose sur l’hébergement. Ce tableau résume la logique que j’applique le plus souvent.

Pour une page WordPress classique, je choisis presque toujours noindex d’abord. Pour un fichier non HTML, X-Robots-Tag est souvent plus propre, parce qu’il agit au niveau de la réponse HTTP. Et pour du contenu réellement privé, aucun réglage SEO ne remplace une protection d’accès. Je ne compte pas non plus le canonical comme un verrou: il signale une version préférée d’un doublon, mais il ne retire pas une URL des résultats.

La logique est simple: on choisit l’outil en fonction du contenu, pas en fonction de l’habitude du plugin. C’est justement là que se glissent les erreurs les plus coûteuses.

Éviter les erreurs qui empêchent la page de disparaître

La plupart des problèmes viennent d’un empilement de réglages qui se contredisent. Quand une page reste visible malgré la demande de désindexation, je vérifie toujours les points suivants.

• Bloquer la page dans robots.txt avant d’avoir posé noindex empêche souvent le robot de lire l’instruction utile.
• Laisser l’URL dans le sitemap XML envoie un signal contraire au moteur, surtout si le plugin SEO la considère encore comme publiable.
• Oublier les liens internes, les menus et les blocs de pages liées garde la page dans le maillage du site, donc dans le circuit de découverte.
• Confondre nofollow et noindex fait perdre du temps: le premier agit sur le suivi des liens, pas sur la présence de la page dans l’index.
• Utiliser un canonical en pensant qu’il supprime l’URL est une erreur classique; il indique une préférence, il ne bloque pas l’indexation.
• Laisser un cache ou un CDN servir l’ancienne version peut retarder l’application réelle de la règle pendant plusieurs jours.

Quand j’audite une page qui ne sort pas de l’index, je commence par le code source et le sitemap, pas par des suppositions. C’est là que se voient les contradictions les plus fréquentes, surtout sur les sites WordPress qui ont beaucoup de couches techniques.

Vérifier que Google a bien compris la consigne

Une fois la règle posée, la vérification compte autant que le réglage lui-même. Je fais toujours le contrôle en plusieurs étapes, parce qu’une page déjà indexée ne disparaît pas instantanément.

1. J’ouvre la page et je vérifie dans le code source la présence d’une directive du type meta name="robots" content="noindex" ou de l’en-tête X-Robots-Tag.
2. Je confirme que la page reste accessible au robot si je compte sur noindex, au lieu de la bloquer trop tôt.
3. Je passe par l’inspection d’URL dans Search Console pour voir le signal réellement lu par Google.
4. Je purge le cache WordPress, le cache serveur et, si besoin, le CDN.
5. J’attends la prochaine exploration, parce qu’une URL déjà indexée peut rester visible quelques jours à quelques semaines selon sa fréquence de crawl.

Si la page a déjà été diffusée par erreur, une demande de suppression temporaire peut accélérer la disparition dans Google, mais elle ne remplace jamais la correction de fond. Une fois la situation stabilisée, il reste une dernière chose utile: formaliser la règle pour ne pas la perdre lors d’une future mise à jour.

La séquence que j’utilise avant de laisser une page hors de l’index

• Page publique mais non stratégique: j’applique noindex.
• Contenu privé ou sensible: j’ajoute une protection d’accès et, si nécessaire, noarchive.
• Fichier non HTML ou besoin de contrôle serveur: je passe par X-Robots-Tag.
• URL temporaire, doublon ou contenu de test: je nettoie aussi les liens internes, le sitemap et le cache.

Sur un site WordPress bien tenu, le meilleur réflexe est simple: décider d’abord si la page doit rester accessible, choisir ensuite l’instruction adaptée, puis vérifier la source, le sitemap et le cache. C’est cette séquence, plus que n’importe quel plugin, qui permet de garder le contrôle sans perturber le SEO du reste du site.