Un e-commerce de 45 000 pages perd 38 % de son trafic organique en trois semaines. La cause : un déploiement en staging avait propagé une balise <meta name="robots" content="noindex"> sur l'ensemble des pages catégories via un composant layout partagé. Personne ne l'a vu. Google, si — et il a déindexé 12 000 URLs en 18 jours. Ce type d'incident n'est pas rare. Les directives meta robots sont d'une puissance redoutable, et c'est précisément ce qui les rend dangereuses quand elles sont mal maîtrisées.
Anatomie des directives meta robots
La balise meta robots se place dans le <head> d'un document HTML. Sa syntaxe est simple, mais les interactions entre directives sont subtiles.
<meta name="robots" content="noindex, nofollow">
Les directives principales
Voici les directives que Googlebot (et la plupart des crawlers) reconnaissent :
- index / noindex : contrôle l'inclusion de la page dans l'index de recherche.
- follow / nofollow : contrôle si le crawler doit suivre les liens présents sur la page.
- noarchive : empêche l'affichage d'une version en cache dans les résultats.
- nosnippet : bloque la génération d'extraits textuels et vidéo dans les SERPs.
- max-snippet:[n] : limite la longueur de l'extrait textuel à
ncaractères. - max-image-preview:[setting] : contrôle la taille de la preview d'image (
none,standard,large). - max-video-preview:[n] : limite la durée de la preview vidéo en secondes.
- notranslate : empêche Google de proposer une traduction de la page dans les résultats.
- noimageindex : empêche l'indexation des images de la page (directive spécifique à Google).
- unavailable_after:[date] : demande la déindexation après une date donnée (format RFC 850).
Ce que "index" et "follow" signifient réellement
Un point que beaucoup de SEOs expérimentés oublient : index et follow sont les valeurs par défaut. Écrire <meta name="robots" content="index, follow"> est strictement équivalent à ne pas avoir de balise meta robots du tout. Cette balise ne sert à rien — elle ne "renforce" pas l'indexation. Google l'a confirmé dans sa documentation officielle sur les spécifications meta robots.
Un piège courant : combiner noindex avec follow. C'est une combinaison valide et utile. Elle dit au moteur "ne mets pas cette page dans l'index, mais suis quand même les liens qu'elle contient pour découvrir et transférer du PageRank vers les pages liées". C'est la bonne approche pour les pages de filtres à facettes qui agrègent des liens vers des pages produits.
User-agents spécifiques
Vous pouvez cibler des crawlers précis en remplaçant robots par le nom de l'user-agent :
<!-- Bloque l'indexation uniquement par Google -->
<meta name="googlebot" content="noindex">
<!-- Bloque l'indexation par les crawlers IA tout en restant indexé par Google -->
<meta name="robots" content="index, follow">
<meta name="GPTBot" content="noindex, nofollow">
<meta name="anthropic-ai" content="noindex, nofollow">
Quand plusieurs directives s'appliquent au même user-agent (une directive robots et une directive googlebot par exemple), Google applique la combinaison la plus restrictive des deux. Si robots dit index et googlebot dit noindex, le résultat pour Googlebot sera noindex.
Meta robots vs X-Robots-Tag vs robots.txt : choisir le bon mécanisme
C'est l'une des sources de confusion les plus fréquentes. Ces trois mécanismes n'opèrent pas au même niveau et ne sont pas interchangeables.
robots.txt : contrôle le crawl, pas l'indexation
Le fichier robots.txt bloque le crawl — il empêche le robot d'accéder à la page. Mais si d'autres pages font des liens vers une URL bloquée par robots.txt, Google peut quand même indexer cette URL (sans en connaître le contenu). Vous vous retrouvez avec une entrée d'index affichant "Aucune information n'est disponible pour cette page" dans les SERPs. C'est rarement le résultat souhaité.
Conséquence directe : si une page est bloquée par robots.txt, le crawler ne peut pas lire la balise meta robots qu'elle contient. Un noindex placé sur une page dont le crawl est bloqué par robots.txt est donc invisible pour le moteur. C'est un piège classique — vous pensez avoir déindexé une page, mais le mécanisme s'annule lui-même.
X-Robots-Tag : la directive HTTP header
Le X-Robots-Tag est un header HTTP qui accepte exactement les mêmes directives que la balise meta robots. Son avantage : il fonctionne sur tous les types de ressources, pas uniquement les documents HTML. PDFs, images, fichiers JavaScript — tout ce qui retourne une réponse HTTP peut porter un X-Robots-Tag.
Configuration Nginx pour marquer tous les PDFs en noindex :
location ~* \.pdf$ {
add_header X-Robots-Tag "noindex, nofollow" always;
# Important : le "always" garantit que le header est ajouté
# même sur les réponses 4xx/5xx
}
Configuration Apache équivalente :
<FilesMatch "\.pdf$">
Header set X-Robots-Tag "noindex, nofollow"
</FilesMatch>
Pour un site e-commerce qui génère des milliers de PDFs (fiches techniques, bons de commande, conditions de vente par fournisseur), cette approche est nettement plus maintenable que d'essayer de contrôler l'indexation document par document.
Tableau de décision
| Besoin | Mécanisme recommandé |
|---|---|
| Empêcher l'indexation d'une page HTML | <meta name="robots" content="noindex"> |
| Empêcher l'indexation d'un PDF / image | X-Robots-Tag: noindex (header HTTP) |
| Économiser du crawl budget sur des milliers d'URLs | robots.txt Disallow (mais accepter que les URLs puissent apparaître dans l'index sans contenu) |
| Déindexer ET empêcher le crawl | noindex en meta ou header, attendre la déindexation, PUIS ajouter le Disallow dans robots.txt |
| Bloquer un crawler IA spécifique | <meta name="GPTBot" content="noindex"> ou robots.txt avec User-agent: GPTBot |
L'ordre de cette dernière ligne est critique. Si vous bloquez le crawl avant que Google ait lu le noindex, la directive ne sera jamais prise en compte. Plus de détails sur les limites de crawl dans cet article sur les crawl limits expliqués par Google.
Cas d'usage concrets : quand appliquer noindex
Pages de filtres et facettes en e-commerce
Un site e-commerce mode avec 3 200 produits, 45 catégories et 12 filtres combinables (taille, couleur, prix, marque, matière...) peut facilement générer 150 000+ URLs de combinaisons de filtres. La plupart de ces pages sont du contenu dupliqué ou quasi-dupliqué, et elles diluent massivement le crawl budget.
La stratégie robuste :
<!-- Page catégorie principale : indexée -->
<!-- /chaussures/running -->
<meta name="robots" content="index, follow">
<!-- Un filtre appliqué (pertinent SEO, volume de recherche) : indexée -->
<!-- /chaussures/running?marque=nike -->
<meta name="robots" content="index, follow">
<!-- Combinaison de 2+ filtres : pas d'indexation, mais on suit les liens -->
<!-- /chaussures/running?marque=nike&taille=42&couleur=noir -->
<meta name="robots" content="noindex, follow">
<!-- Tri et pagination de filtres : pas d'indexation -->
<!-- /chaussures/running?marque=nike&taille=42&tri=prix-asc&page=3 -->
<meta name="robots" content="noindex, nofollow">
La nuance entre noindex, follow et noindex, nofollow est délibérée. Sur les combinaisons de deux filtres, les liens pointent souvent vers des pages produits individuelles — vous voulez que le crawler les suive. Sur les pages de tri avec pagination profonde, les liens mènent aux mêmes produits déjà accessibles par d'autres chemins — économisez le crawl.
Un point souvent négligé : Google a confirmé qu'au bout d'un certain temps, si une page est systématiquement marquée noindex, Googlebot réduit la fréquence de crawl de cette URL, voire arrête de la crawler. Le follow sur une page noindex de longue date peut donc devenir inopérant en pratique. Gardez cela en tête pour votre architecture de liens internes — ne comptez pas sur des pages noindex comme seul chemin de découverte vers du contenu important.
Pages techniques et back-office exposées
Pages de résultats de recherche interne, pages de compte utilisateur, pages de panier, pages de remerciement post-commande — toutes ces pages n'ont aucune valeur d'indexation et gaspillent du crawl budget.
<!-- Page de résultats de recherche interne -->
<!-- /search?q=chaussures+running+homme -->
<meta name="robots" content="noindex, nofollow">
Pour la recherche interne spécifiquement, combinez le noindex avec un blocage dans robots.txt si le volume d'URLs est important (certains sites e-commerce ont des millions de combinaisons de recherche interne crawlées) :
# robots.txt
User-agent: *
Disallow: /search
Disallow: /cart
Disallow: /account
Disallow: /checkout
Ici le blocage robots.txt est justifié : vous ne voulez ni l'indexation ni le crawl de ces URLs, et aucun signal SEO ne transite par elles.
Environnements de staging et preview
Le scénario décrit en introduction est réel et courant. La défense en profondeur s'impose :
# Configuration Nginx pour un environnement de staging
server {
listen 443 ssl;
server_name staging.votresite.fr;
# Couche 1 : header X-Robots-Tag sur TOUTES les réponses
add_header X-Robots-Tag "noindex, nofollow" always;
# Couche 2 : authentification basique (empêche le crawl)
auth_basic "Staging";
auth_basic_user_file /etc/nginx/.htpasswd;
# Le reste de la config...
}
La couche d'authentification est la vraie protection — un crawler qui reçoit un 401 ne peut pas indexer le contenu. Le X-Robots-Tag est une sécurité supplémentaire au cas où l'auth serait temporairement désactivée.
Dans un framework comme Next.js, vous pouvez aussi conditionner la balise programmatiquement :
// components/MetaRobots.tsx (Next.js App Router)
import { headers } from 'next/headers';
export function MetaRobots() {
const isProduction = process.env.NEXT_PUBLIC_ENV === 'production';
if (!isProduction) {
return <meta name="robots" content="noindex, nofollow" />;
}
// En production, pas de balise meta robots = index,follow par défaut
return null;
}
Le risque ici : une variable d'environnement mal configurée en production. C'est exactement le type de régression qu'un outil de monitoring comme Seogard détecte en temps réel — un changement de directive meta robots sur un batch de pages déclenche une alerte avant que Google n'ait le temps de déindexer quoi que ce soit.
Implémentation dans les frameworks JavaScript modernes
Le SSR et les SPA introduisent des subtilités spécifiques pour les directives meta robots. Si votre site utilise du CSR pur, Google peut ne pas voir vos balises meta du tout.
Next.js (App Router)
// app/blog/[slug]/page.tsx
import { Metadata } from 'next';
import { getPost } from '@/lib/posts';
export async function generateMetadata({
params
}: {
params: { slug: string }
}): Promise<Metadata> {
const post = await getPost(params.slug);
// Posts en draft : noindex
if (post.status === 'draft' || post.status === 'archived') {
return {
title: post.title,
robots: {
index: false,
follow: true, // On garde le follow pour le maillage interne
googleBot: {
index: false,
follow: true,
'max-image-preview': 'none', // Pas de preview image non plus
},
},
};
}
// Posts publiés : on laisse les défauts (index, follow)
// + on contrôle les previews
return {
title: post.title,
robots: {
googleBot: {
'max-snippet': 160,
'max-image-preview': 'large',
'max-video-preview': 30,
},
},
};
}
Next.js génère automatiquement la balise meta à partir de cet objet. L'avantage de l'API Metadata typée : une erreur de directive sera capturée à la compilation, pas en production.
Nuxt 3
// pages/produit/[id].vue
<script setup lang="ts">
const route = useRoute();
const { data: product } = await useFetch(`/api/products/${route.params.id}`);
// Produit en rupture longue durée : noindex mais follow
// pour maintenir le transfert de PageRank vers les produits liés
useHead({
meta: [
{
name: 'robots',
content: product.value?.outOfStockSince &&
daysSince(product.value.outOfStockSince) > 90
? 'noindex, follow'
: 'index, follow, max-image-preview:large'
}
]
});
</script>
Le piège du hydration mismatch
Un cas vicieux : votre serveur envoie <meta name="robots" content="noindex"> mais le client hydrate avec content="index, follow" (parce que la logique côté client évalue différemment la condition). Google utilise le HTML retourné par le serveur comme source primaire, mais peut aussi exécuter le JavaScript. Le résultat est imprévisible.
Ce type de bug est détaillé dans notre article sur le hydration mismatch et son impact SEO. La règle : la logique de détermination des directives robots doit s'exécuter exclusivement côté serveur. Ne laissez jamais le client modifier une balise meta robots.
Pour vérifier ce que Google voit réellement, l'outil d'inspection d'URL de la Search Console reste la référence. L'onglet "HTML rendu" affiche le DOM après exécution JavaScript — vous y verrez la balise meta robots telle que Googlebot la perçoit. Plus de détails sur la méthodologie dans comment tester ce que Google voit réellement sur votre site.
Audit et monitoring : détecter les erreurs avant Google
Audit initial avec Screaming Frog
Lancez un crawl complet et filtrez sur les directives :
- Onglet Directives > filtrez par "Noindex" pour lister toutes les pages marquées noindex.
- Croisez avec l'onglet Response Codes : une page en 200 avec noindex est volontaire. Une page en 200 avec noindex ET présente dans le sitemap.xml est un problème (signal contradictoire).
- Export CSV, pivot table sur les templates de pages pour identifier les patterns.
Points de contrôle critiques :
- Pages noindex dans le sitemap : le sitemap ne doit contenir que des URLs que vous voulez indexées. Google le dit explicitement dans la documentation du sitemap. Un noindex dans le sitemap ne cause pas de pénalité, mais c'est un signal contradictoire qui gaspille le crawl budget et montre un manque de maîtrise. D'ailleurs, la structuration de votre sitemap mérite une attention particulière — consultez notre article sur pourquoi certains SEOs découpent leur sitemap en plusieurs fichiers.
- Pages canoniques avec noindex : si la page A a un canonical vers la page B, et que la page B est en noindex, vous indiquez à Google que la version canonique d'un contenu ne doit pas être indexée. C'est souvent accidentel.
- Pages à fort trafic en noindex : croisez les données Search Console (pages avec impressions) avec votre liste de pages noindex. Si une page reçoit des impressions et du trafic malgré un noindex, c'est que le noindex est récent et Google ne l'a pas encore traité — ou que le noindex n'est pas correctement implémenté (problème de rendu JavaScript, par exemple).
Monitoring continu en Search Console
Dans Google Search Console, le rapport Indexation des pages signale les pages exclues avec la raison "Exclue par la balise 'noindex'". Surveillez les variations brutales de ce chiffre :
- Augmentation soudaine : quelqu'un a déployé un noindex non intentionnel. Alerte rouge.
- Diminution soudaine : des pages noindex ont perdu leur directive (régression de template). Potentiellement dangereux si ces pages diluent votre index.
Le problème de Search Console : la détection est lente. Google peut mettre plusieurs jours voire semaines à refléter les changements dans ses rapports. Pour un site de 15 000 pages où un déploiement cassé peut impacter des milliers d'URLs en quelques minutes, ce délai est inacceptable. C'est là que le monitoring synthétique en temps réel prend tout son sens — Seogard crawle vos pages critiques à intervalles réguliers et déclenche une alerte dès qu'une directive meta robots change de manière inattendue.
Vérification CLI rapide
Pour un check ponctuel sur une URL spécifique, curl + grep reste le moyen le plus rapide :
# Vérifier la balise meta robots dans le HTML
curl -s https://www.votresite.fr/chaussures/running | \
grep -i 'meta.*name.*robots'
# Vérifier le header X-Robots-Tag
curl -sI https://www.votresite.fr/catalogue.pdf | \
grep -i 'x-robots-tag'
# Check en masse depuis une liste d'URLs
while IFS= read -r url; do
robots=$(curl -s "$url" | grep -oP 'content="\K[^"]*(?=")' | head -1)
xrobots=$(curl -sI "$url" | grep -i 'x-robots-tag' | cut -d: -f2-)
echo "$url | meta: $robots | header: $xrobots"
done < urls.txt
Pour les sites avec rendu JavaScript, ce check ne suffit pas — vous ne voyez que le HTML initial, pas le DOM après hydration. Dans ce cas, utilisez Chrome en mode headless :
# Rendu JavaScript inclus via Chrome headless
google-chrome --headless --dump-dom \
'https://www.votresite.fr/chaussures/running' 2>/dev/null | \
grep -i 'meta.*name.*robots'
Scénario complet : migration avec gestion des directives robots
Prenons un cas concret. Un média en ligne (18 000 articles, 2 500 pages catégorie/tag, trafic organique de 850 000 sessions/mois) migre de WordPress vers un CMS headless avec Next.js en SSR. Voici la stratégie de directives robots pendant et après la migration.
Phase 1 : pré-migration (J-30)
Audit complet de l'état actuel des directives. Export Screaming Frog : 1 200 pages ont un noindex (pages auteur, pages d'archives par date, pages de tags à faible volume). Ce noindex est volontaire — il a été mis en place via Yoast SEO. Il faut reproduire cette logique dans le nouveau stack.
// lib/robotsDirective.ts
type RobotsDirective = {
index: boolean;
follow: boolean;
maxSnippet?: number;
maxImagePreview?: 'none' | 'standard' | 'large';
};
export function computeRobotsDirective(page: {
type: string;
publishStatus: string;
tagArticleCount?: number;
authorArticleCount?: number;
}): RobotsDirective {
// Pages non publiées : jamais indexées
if (page.publishStatus !== 'published') {
return { index: false, follow: true };
}
// Pages auteur : noindex (contenu mince, duplication)
if (page.type === 'author') {
return { index: false, follow: true };
}
// Pages de tags avec moins de 5 articles : noindex
if (page.type === 'tag' && (page.tagArticleCount ?? 0) < 5) {
return { index: false, follow: true };
}
// Archives par date : noindex
if (page.type === 'date-archive') {
return { index: false, follow: false };
}
// Tout le reste : index, follow avec previews optimisées
return {
index: true,
follow: true,
maxSnippet: 300,
maxImagePreview: 'large',
};
}
Cette logique centralisée est testable unitairement — écrivez des tests pour chaque cas avant de déployer. Un test qui vérifie que computeRobotsDirective({ type: 'article', publishStatus: 'published' }) retourne { index: true, follow: true, ... } est trivial mais peut sauver votre trafic.
Phase 2 : migration (J-0 à J+7)
Pendant la bascule, le nouveau site est en production. Les risques :
- Un template qui ne rend pas la balise meta robots correctement en SSR (bug de prerendering ou de mode de rendering).
- Des URLs qui retournent un 200 avec une page vide (cas classique du SPA qui affiche une page blanche).
- Des redirections 301 qui pointent vers des pages noindex (l'ancien article redirige vers une page tag noindex au lieu de la bonne URL).
Check immédiat post-déploiement :
# Échantillon de 100 URLs critiques (top trafic)
head -100 top-urls.txt | while IFS= read -r url; do
status=$(curl -sI -o /dev/null -w '%{http_code}' "$url")
robots=$(google-chrome --headless --dump-dom "$url" 2>/dev/null | \
grep -oP '<meta name="robots" content="\K[^"]*')
echo "$status | $robots | $url"
done | grep -v "200 | index" # Affiche uniquement les anomalies
Phase 3 : post-migration (J+7 à J+90)
Surveillance dans Search Console du rapport d'indexation. Le nombre de pages "Exclues par noindex" doit rester stable (aux alentours de 1 200 dans notre cas). Une dérive significative — disons +500 en une semaine — indique une régression.
Vérifiez aussi que les pages migalées conservent leur position. Le rapport sur les performances de Search Console peut avoir des bugs d'impressions, donc croisez toujours avec vos données analytics.
Les edge cases qui piègent même les experts
noindex + canonical : qui gagne ?
Si une page porte à la fois un noindex et un canonical pointant vers elle-même (ou vers une autre page), Google doit résoudre un conflit. La documentation Google indique que le canonical est un "signal" et non une directive. En pratique, le noindex prend le dessus — une page noindex ne sera pas indexée même avec un canonical auto-référent.
Mais si la page A (noindex) a un canonical vers la page B (index), Google peut choisir d'ignorer le canonical ET le noindex et faire ce qu'il estime le plus pertinent. C'est un territoire flou — évitez cette combinaison.
nofollow sur la meta vs nofollow sur les liens
Le nofollow dans la balise meta robots s'applique à tous les liens de la page. Le rel="nofollow" sur un lien individuel ne s'applique qu'à ce lien spécifique. Ce sont deux mécanismes distincts qui ne se cumulent pas de manière additive — ils opèrent à des niveaux différents.
Depuis 2019, Google traite rel="nofollow" comme un indice (hint) et non plus comme une directive stricte sur les liens individuels. Il peut choisir de le suivre quand même. Le nofollow dans la meta robots, en revanche, reste une directive respectée de manière beaucoup plus stricte par Googlebot.
unavailable_after : le noindex temporisé
Une directive méconnue mais utile pour les contenus à durée de vie limitée (offres promotionnelles, événements, inscriptions à date limite) :
<meta name="robots" content="unavailable_after: 25 Jun 2026 15:00:00 GMT">
Après la date spécifiée, Google déindexera la page. Le format de date doit être RFC 850. L'avantage par rapport à un noindex appliqué manuellement après la date : vous n'avez pas besoin d'un déploiement ou d'un cron job pour changer la directive. L'inconvénient : seul Google supporte cette directive. Bing et les autres moteurs l'ignorent.
L'interaction avec le tag hreflang
Si vous avez des versions internationales d'une page et que l'une d'elles est en noindex, les annotations hreflang deviennent problématiques. Google s'attend à ce que les pages référencées dans un cluster hreflang soient toutes indexables. Une page noindex dans un cluster hreflang crée un signal incohérent qui peut perturber la compréhension du cluster par Google. La solution : retirez les annotations hreflang des pages noindex.
Wrap-up
Les directives meta robots sont le mécanisme le plus direct pour contrôler votre présence dans l'index de Google — et le plus dangereux quand il échappe à votre contrôle. Centralisez la logique dans une fonction testable, auditez régulièrement avec Screaming Frog et Search Console, et surtout monitorez en continu les changements non intentionnels. L'article complémentaire sur les meta tags SEO couvre le contexte global dans lequel ces directives s'inscrivent. Un noindex accidentel qui passe en production un vendredi soir ne devrait jamais survivre au week-end.