Meta robots noindex, nofollow : guide technique complet

Un déploiement un vendredi soir, un template de pagination qui récupère la mauvaise config, et 12 000 pages produit passent en noindex pendant 72 heures. Le lundi, la Search Console affiche une chute de 40% des pages indexées. Trois semaines plus tard, le trafic organique n'a toujours pas récupéré. Ce scénario n'est pas hypothétique — c'est le type d'incident que les équipes SEO croisent régulièrement sur des sites e-commerce de taille moyenne.

Les directives meta robots sont parmi les leviers les plus puissants du SEO technique. Et comme tout levier puissant, mal utilisé, il casse les choses vite et fort.

Anatomie des directives meta robots

Deux vecteurs permettent de communiquer des directives robots aux moteurs de recherche : la balise HTML <meta> et l'en-tête HTTP X-Robots-Tag. Les deux sont traitées de manière équivalente par Googlebot. Si les deux sont présentes et contradictoires, c'est la directive la plus restrictive qui l'emporte.

La balise HTML meta robots

La forme canonique est simple :

<meta name="robots" content="noindex, nofollow">

Le name="robots" s'applique à tous les crawlers. Vous pouvez cibler un bot spécifique en remplaçant robots par son identifiant — googlebot, bingbot, yandex, etc. :

<!-- Bloque l'indexation par Google uniquement -->
<meta name="googlebot" content="noindex">
<!-- Bing voit toujours cette page comme indexable -->

Quand une page porte à la fois une directive robots et une directive googlebot, Google combine les deux et applique la plus restrictive par directive individuelle. Si robots dit noindex, follow et googlebot dit index, nofollow, le résultat effectif pour Googlebot sera noindex, nofollow. C'est documenté dans la spécification officielle de Google sur les meta robots.

L'en-tête HTTP X-Robots-Tag

Pour les ressources non-HTML (PDF, images, flux JSON, endpoints API) ou quand vous ne maîtrisez pas le template HTML, le header HTTP est votre seul levier :

# Configuration Nginx : bloquer l'indexation de tous les PDF
location ~* \.pdf$ {
    add_header X-Robots-Tag "noindex, nofollow" always;
}

# Bloquer l'indexation d'un répertoire entier de fichiers statiques
location /assets/docs/ {
    add_header X-Robots-Tag "noindex" always;
}

# Directive ciblée pour Googlebot uniquement
location /api/preview/ {
    add_header X-Robots-Tag "googlebot: noindex" always;
}

Le mot-clé always dans Nginx est critique : sans lui, le header n'est ajouté que sur les réponses 2xx et 3xx. Si une page renvoie un 4xx temporaire, le header disparaît — un edge case qui peut passer inaperçu pendant des mois.

Pour Apache, l'équivalent :

<FilesMatch "\.pdf$">
    Header set X-Robots-Tag "noindex, nofollow"
</FilesMatch>

Inventaire complet des directives

Au-delà du couple noindex/nofollow, plusieurs directives existent et sont souvent ignorées :

noindex — empêche l'indexation de la page. La page peut encore être crawlée.
nofollow — demande au moteur de ne pas suivre les liens de la page. Ne bloque pas l'indexation.
noarchive — empêche la mise en cache (plus de lien "En cache" dans les SERP). Utile pour du contenu sensible ou éphémère.
nosnippet — empêche l'affichage de tout snippet textuel dans les résultats. Nucléaire — votre résultat n'affiche que le title et l'URL.
max-snippet:[N] — limite la longueur du snippet à N caractères. Plus granulaire que nosnippet.
max-image-preview:[none|standard|large] — contrôle la taille des images dans les aperçus.
max-video-preview:[N] — limite la durée de l'aperçu vidéo à N secondes.
notranslate — empêche Google de proposer une traduction du résultat.
noimageindex — empêche l'indexation des images de la page. Google a indiqué que cette directive est supportée mais que le moyen le plus fiable reste le fichier robots.txt pour les images.
unavailable_after:[date] — indique qu'après une date donnée, la page ne doit plus apparaître dans les résultats. Format RFC 850. Peu utilisée, mais pertinente pour les offres d'emploi, ventes flash, événements.

Les directives se combinent librement :

<meta name="robots" content="noindex, nofollow, noarchive">
<meta name="robots" content="max-snippet:160, max-image-preview:standard">

noindex : quand désindexer et quand ne pas le faire

La directive noindex retire une page des résultats de recherche. Mais elle ne bloque pas le crawl. Googlebot continue de visiter la page — il a besoin de la parser pour lire la directive. C'est une distinction fondamentale avec le blocage via robots.txt.

Les cas légitimes de noindex

Pages de pagination profonde. Sur un catalogue e-commerce de 15 000 produits avec 20 items par page, les pages /category/shoes?page=47 n'apportent aucune valeur de recherche. En noindex, follow, vous préservez la transmission de PageRank vers les fiches produit tout en retirant des centaines de pages de faible qualité de l'index.

Pages de résultats de recherche interne. Google est explicite là-dessus : les pages de recherche interne qui génèrent une quasi-infinité de combinaisons URL diluent le crawl budget et ne devraient pas être indexées. Le noindex est la solution standard ici.

Pages de staging, prévisualisation, ou environnements de développement. Un classique : l'environnement de staging qui n'est pas protégé par authentification et se retrouve indexé. Le noindex global est un filet de sécurité, mais ne remplacez pas une vraie protection d'accès (auth HTTP, IP whitelisting).

Pages de comptes utilisateur, paniers, tunnels de checkout. Aucune raison que ces pages apparaissent dans l'index.

Pages avec contenu dupliqué technique. Les variantes d'URL avec paramètres de tri (?sort=price-asc), filtres (?color=red&size=L), ou tracking (?utm_source=newsletter). Quand la balise canonical ne suffit pas ou n'est pas respectée, le noindex est le mécanisme de dernier recours.

Quand ne pas utiliser noindex

N'utilisez jamais noindex comme substitut à un canonical. Si deux URLs servent le même contenu, le rel=canonical est l'outil correct. Le noindex détruit le signal — le canonical le consolide. Comme détaillé dans notre guide complet des meta tags SEO, la balise canonical transfère les signaux de ranking vers l'URL préférée, ce que noindex ne fait pas.

N'appliquez pas noindex sur des pages qui reçoivent des backlinks. Si une page /ressources/etude-2024.pdf a acquis 50 domaines référents, la passer en noindex ne détruit pas directement le link equity (les liens existent toujours), mais elle sort de l'index. Un canonical vers une page consolidée, ou un redirect 301, serait préférable.

Attention à la combinaison noindex + nofollow sur des pages structurantes. Si votre page catégorie est le seul chemin de crawl vers 200 fiches produit, la passer en noindex, nofollow orpheline ces 200 pages. Le crawl ne suit plus les liens. Utilisez noindex, follow si vous devez désindexer une page mais conserver le passage du crawler.

Le piège du noindex prolongé

Un point méconnu : si une page reste en noindex suffisamment longtemps, Googlebot réduit sa fréquence de crawl, puis peut cesser de la visiter. Retirer le noindex six mois plus tard ne garantit pas un retour rapide dans l'index — Google ne verra le changement que lors de son prochain passage, qui peut prendre des semaines. C'est documenté par John Mueller dans plusieurs échanges : les pages historiquement en noindex ne récupèrent pas instantanément.

nofollow au niveau de la page vs. au niveau du lien

La confusion entre le nofollow de la meta robots et l'attribut rel="nofollow" sur les liens individuels reste fréquente, même chez des profils seniors.

Meta robots nofollow : portée page entière

<meta name="robots" content="nofollow">

Cette directive indique au moteur de ne suivre aucun lien de la page. Elle est absolue — pas de granularité. Tous les <a href>, toutes les ressources liées. C'est l'équivalent de couper toute la tuyauterie de liens sortants d'un coup.

Cas d'usage valide : les pages de commentaires UGC où vous ne contrôlez pas les destinations, les pages de mentions légales bourrées de liens vers des prestataires tiers que vous ne souhaitez pas endorser.

Attribut rel sur les liens individuels

<a href="https://partner-site.com" rel="nofollow">Partenaire</a>
<a href="https://paid-link.com" rel="sponsored">Lien sponsorisé</a>
<a href="https://forum-post.com/comment" rel="ugc">Commentaire utilisateur</a>

Depuis 2019, Google traite nofollow, sponsored et ugc comme des hints (indices) plutôt que des directives strictes. Google peut choisir de suivre le lien quand même pour des raisons de découverte. En revanche, le nofollow au niveau meta robots reste une directive — Google s'y conforme.

Le mythe du PageRank sculpting

Placer des nofollow sur certains liens internes pour "concentrer" le PageRank vers des pages prioritaires — le PageRank sculpting — ne fonctiplus comme prévu depuis 2009. Le budget de PageRank alloué à un lien nofollow est simplement perdu (évaporé), il n'est pas redistribué aux autres liens de la page. Matt Cutts l'a confirmé à l'époque, et le comportement n'a pas changé depuis.

Si vous devez prioriser le crawl et le link equity vers certaines pages, travaillez votre architecture de liens internes : maillage, breadcrumbs, sections connexes. Le nofollow interne est rarement la bonne réponse.

Implémentation dans les architectures JavaScript modernes

C'est là que les choses se compliquent. Sur une SPA React ou une application Vue en CSR (Client-Side Rendering), la balise meta robots insérée dynamiquement via JavaScript peut ne pas être vue par Googlebot au moment du crawl.

Le problème du CSR pur

Si votre application injecte la balise meta robots via un useEffect React ou un mounted() Vue après le rendu initial, vous dépendez entièrement de la capacité de Googlebot à exécuter votre JavaScript. Googlebot utilise une version de Chrome pour le rendering, mais il y a un délai — la file d'attente de rendering peut prendre des heures, voire des jours. Pendant ce temps, la page est parsée en HTML brut, sans la directive.

Comme nous l'avons détaillé dans l'article sur les différences entre SSR et CSR pour le SEO, le rendering côté client introduit une incertitude fondamentale pour les directives critiques.

// ❌ Dangereux : meta robots injectée côté client uniquement
// Next.js - composant page avec useEffect
import { useEffect } from 'react';

export default function StagingPage() {
  useEffect(() => {
    const meta = document.createElement('meta');
    meta.name = 'robots';
    meta.content = 'noindex, nofollow';
    document.head.appendChild(meta);
  }, []);

  return <div>Contenu de staging</div>;
}

// ✅ Correct : meta robots dans le rendu serveur
// Next.js App Router - avec metadata export
import type { Metadata } from 'next';

export const metadata: Metadata = {
  robots: {
    index: false,
    follow: false,
    noarchive: true,
    googleBot: {
      index: false,
      follow: false,
      'max-image-preview': 'none',
    },
  },
};

export default function StagingPage() {
  return <div>Contenu de staging</div>;
}

Avec Next.js App Router, l'export metadata est résolu côté serveur. La balise meta est présente dans le HTML initial servi au crawler. Aucune dépendance au JS client.

Cas Nuxt.js / Vue SSR

// Nuxt 3 - useHead dans un composant page
// Le rendu SSR garantit la présence dans le HTML initial
export default defineComponent({
  setup() {
    useHead({
      meta: [
        { name: 'robots', content: 'noindex, nofollow' }
      ]
    });
  }
});

La double sécurité : HTML + HTTP header

Pour les pages critiques (staging, preview, environnements de test), combinez la balise HTML et le header HTTP. C'est une défense en profondeur :

# Nginx : ajout du header sur tout l'environnement de staging
server {
    server_name staging.mon-ecommerce.com;

    add_header X-Robots-Tag "noindex, nofollow" always;

    location / {
        proxy_pass http://app_upstream;
    }
}

Même si un bug dans votre framework JavaScript fait sauter la balise meta, le header HTTP reste. Si vous gérez des environnements de prerendering, cette double couche est essentielle.

Scénario concret : migration e-commerce avec incident noindex

Prenons un cas réaliste. LeChausseur.fr, un e-commerce de 18 000 pages (12 000 fiches produit, 400 catégories, 2 000 pages de pagination, 3 600 pages de filtres). L'équipe migre de Magento 2 vers une stack headless Next.js + Shopify.

La migration

Pendant la migration, l'équipe met en place un mécanisme de feature flag pour les pages en cours de refonte. Le flag isLegacyPage est censé afficher un bandeau d'avertissement. Mais un développeur junior ajoute aussi une condition dans le layout global :

// Le bug : condition qui s'applique à TOUTES les pages en production
// au lieu des seules pages legacy
export const metadata: Metadata = {
  robots: process.env.FEATURE_LEGACY_BANNER === 'true'
    ? { index: false, follow: true }
    : { index: true, follow: true },
};

Le problème : la variable d'environnement FEATURE_LEGACY_BANNER est à true en production depuis le sprint précédent. Résultat : 18 000 pages passent en noindex le mercredi soir du déploiement.

La détection

Le jeudi matin, personne ne remarque rien — le trafic organique a un décalage naturel de 24-48h. Le vendredi, l'équipe SEO voit une légère baisse mais l'attribue à la saisonnalité. C'est le lundi suivant, 5 jours après l'incident, qu'un scan Screaming Frog programmé hebdomadaire remonte l'alerte : 100% des pages portent un noindex.

Ici, un outil de monitoring continu comme SEOGard aurait détecté le basculement dans les heures suivant le déploiement — une différence entre 5 jours d'exposition et quelques heures.

L'impact chiffré

Pages désindexées par Google : sur les 18 000 pages, environ 8 500 ont été retirées de l'index en 5 jours (Google avait crawlé environ 47% du site sur cette période, visible dans le rapport de couverture de la Search Console).
Trafic organique : -35% la première semaine après correction, le temps que Google recrawle et réindexe.
Récupération complète : 23 jours. Les pages à forte autorité (catégories principales) sont revenues en 3-5 jours. Les fiches produit de longue traîne ont pris 2-3 semaines.
Coût estimé : sur un CA organique de 180K€/mois, la perte représente environ 45K€ sur la période de récupération.

Les actions correctives

Rollback immédiat de la variable d'environnement.
Soumission des sitemaps dans la Search Console avec le bouton "Demander l'indexation" sur les 50 URLs les plus stratégiques.
Purge du cache CDN (Cloudflare) pour s'assurer que le HTML servi aux crawlers est bien à jour.
Mise en place d'un test automatisé dans la CI/CD :

// test/seo/meta-robots.test.ts
// Test d'intégration vérifiant que les pages critiques ne portent pas de noindex
import { describe, it, expect } from 'vitest';
import { render } from '@testing-library/react';
import ProductPage from '@/app/product/[slug]/page';

describe('Meta robots - Pages produit', () => {
  it('ne doit pas contenir noindex sur les pages produit actives', async () => {
    const html = await fetch('http://localhost:3000/product/running-shoe-x1')
      .then(res => res.text());

    // Vérifie que noindex n'apparaît ni dans une meta tag ni dans un header
    expect(html).not.toMatch(
      /<meta[^>]*name=["']robots["'][^>]*content=["'][^"']*noindex/i
    );
  });

  it('doit contenir noindex sur les pages de recherche interne', async () => {
    const html = await fetch('http://localhost:3000/search?q=chaussures')
      .then(res => res.text());

    expect(html).toMatch(
      /<meta[^>]*name=["']robots["'][^>]*content=["'][^"']*noindex/i
    );
  });
});

Vérification et debugging : la trousse à outils

Screaming Frog

Configurez un crawl avec les filtres sur la colonne "Meta Robots 1" pour isoler toutes les pages portant un noindex ou nofollow. Sur un site de 15K+ pages, exportez le rapport et croisez avec votre sitemap : toute URL présente dans le sitemap ET portant un noindex est une anomalie.

Astuce avancée : dans Configuration > Spider > Advanced, activez "Respect noindex" pour simuler le comportement de Googlebot — les pages noindex seront crawlées mais flaggées. Activez "Respect nofollow" uniquement si vous voulez simuler l'arrêt du crawl sur les liens.

Google Search Console

Le rapport Pages (anciennement "Couverture") affiche explicitement les URLs exclues pour la raison "Exclue par la balise 'noindex'". Si ce chiffre monte brusquement, vous avez un problème. Configurez des alertes par email sur les changements significatifs — mais sachez que les données de la GSC ont un délai de 2-4 jours.

Chrome DevTools + Inspection d'URL

Pour une vérification page par page, l'outil "Inspecter une URL" de la Search Console fait le rendu de la page tel que Googlebot le voit. Vérifiez dans l'onglet "HTML rendu" que la balise meta robots est bien présente dans le <head>.

En complément, dans Chrome DevTools, ouvrez l'onglet Network et filtrez sur le document HTML. Vérifiez les response headers pour un éventuel X-Robots-Tag. C'est la seule façon de voir le header HTTP — il n'apparaît pas dans le DOM.

Vérification CLI rapide

# Vérifier la balise meta robots dans le HTML
curl -s https://lechausseur.fr/product/running-shoe-x1 | grep -i "name=\"robots\""

# Vérifier le header X-Robots-Tag
curl -sI https://lechausseur.fr/assets/docs/guide-tailles.pdf | grep -i "x-robots-tag"

# Vérifier les deux sur un lot d'URLs depuis un fichier
while read url; do
  meta=$(curl -s "$url" | grep -i 'name="robots"' | head -1)
  header=$(curl -sI "$url" | grep -i "x-robots-tag" | head -1)
  echo "$url | META: $meta | HEADER: $header"
done < urls.txt

Pour les sites en JavaScript, curl ne suffit pas — vous ne verrez que le HTML pré-rendering. Si votre site dépend du CSR, vous devez vérifier ce que Google voit réellement. Notre article sur comment tester ce que Google voit réellement sur votre site couvre ce point en détail.

Interactions avec robots.txt et canonical : les conflits silencieux

noindex vs. robots.txt : le piège classique

Si votre robots.txt bloque le crawl d'une URL, Googlebot ne peut pas accéder à la page pour lire la directive noindex. Résultat paradoxal : la page peut rester dans l'index indéfiniment, sans que votre noindex ne soit jamais lu.

# robots.txt - ERREUR : cette combinaison empêche la lecture du noindex
User-agent: *
Disallow: /admin/

Si /admin/dashboard porte une balise noindex dans son HTML, Googlebot ne la verra jamais. La page peut apparaître dans les SERP (sans snippet, sans description — juste l'URL et un titre deviné) si elle est liée depuis d'autres sources.

La règle est simple : si vous voulez désindexer, utilisez noindex et n'utilisez pas Disallow pour cette même URL. Si vous voulez bloquer le crawl sans désindexer (rare, mais ça existe — économie de crawl budget sur des endpoints techniques), utilisez Disallow dans le robots.txt.

noindex + canonical : le signal contradictoire

<!-- Conflit : "ne m'indexe pas" + "je suis la version canonique" -->
<meta name="robots" content="noindex">
<link rel="canonical" href="https://lechausseur.fr/product/running-shoe-x1">

Si la canonical pointe vers la page elle-même (self-referencing) ET que la page est en noindex, Google respecte le noindex. Mais si la canonical pointe vers une AUTRE page, Google peut interpréter le signal comme "cette page est une variante, la version canonique est là-bas" et ignorer le noindex dans certains cas.

La recommandation : ne combinez jamais noindex avec un canonical pointant vers une autre URL. Choisissez l'un ou l'autre. Si le contenu est dupliqué, le canonical suffit. Si la page ne doit vraiment pas exister dans l'index, le noindex suffit — sans canonical cross-page.

noindex et les sitemaps

Inclure une URL noindex dans votre sitemap.xml est un signal contradictoire. Le sitemap dit "cette page est importante, indexe-la". La meta robots dit "ne l'indexe pas". Google gère ce conflit en respectant le noindex, mais il gaspille du crawl budget à revenir vérifier une page qui ne devrait pas être dans le sitemap.

Nettoyez vos sitemaps : toute URL portant un noindex permanent doit être retirée du sitemap. Les outils comme Screaming Frog permettent de croiser les deux datasets en quelques clics.

Directives avancées pour le contrôle des snippets

Les directives max-snippet, max-image-preview et max-video-preview sont sous-utilisées alors qu'elles offrent un contrôle fin sur l'apparence dans les SERP sans sacrifier l'indexation.

Limiter les snippets sans casser l'indexation

Un média en ligne qui monétise son contenu derrière un paywall veut apparaître dans Google mais ne veut pas que le snippet affiche tout l'article. Au lieu d'utiliser nosnippet (qui tue le CTR en n'affichant rien), max-snippet permet un compromis :

<!-- Affiche max 80 caractères de snippet — assez pour teaser, pas assez pour satisfaire -->
<meta name="robots" content="max-snippet:80, max-image-preview:standard">

C'est aussi pertinent dans le contexte des AI Overviews de Google. Comme le montre l'article sur la visibilité des liens dans les AI Overviews, le contenu extrait pour les réponses IA dépend en partie des directives de snippet. Limiter max-snippet peut réduire l'extraction de votre contenu dans ces résumés, ce qui est un levier si vous constatez une cannibalisation du trafic par les AI Overviews.

unavailable_after pour le contenu éphémère

<!-- Cette offre expire le 15 mars 2026 -->
<meta name="robots" content="unavailable_after: 15 Mar 2026 00:00:00 GMT">

Après cette date, Google retire la page de l'index automatiquement. C'est plus propre que de compter sur un développeur pour ajouter un noindex après l'événement, ou pire, supprimer la page et générer des 404.

Pour les sites avec des milliers de pages d'offres temporaires (immobilier, emploi, événementiel), cette directive automatise un processus qui serait autrement manuel et source d'erreurs.

Le monitoring continu comme filet de sécurité

Le scénario du LeChausseur.fr l'illustre : les erreurs de meta robots ne génèrent aucune erreur côté serveur, aucun crash applicatif, aucune alerte dans votre monitoring APM. Un noindex accidentel rend un HTTP 200 parfaitement sain — du point de vue technique, tout va bien. C'est pourquoi le monitoring SEO technique est un domaine à part.

Les trois piliers d'une stratégie de surveillance robuste : un crawl automatisé régulier (Screaming Frog en mode scheduled ou un crawler cloud), les rapports de la Search Console vérifiés hebdomadairement, et un outil de monitoring continu comme SEOGard qui compare les meta tags entre chaque déploiement et alerte en temps réel sur les régressions.

Les directives meta robots sont un mécanisme binaire — elles marchent ou elles cassent votre visibilité, sans état intermédiaire. L'approche défensive (tests en CI, monitoring continu, double vecteur HTML + HTTP) n'est pas de la paranoïa. C'est de l'ingénierie.