Navigation à facettes : canonical, noindex, URL pour le SEO

Une catégorie produit, cinq filtres, trois valeurs par filtre. Vous croyez gérer une page, Googlebot en voit 243. Multipliez par 50 catégories : 12 150 URLs servies pour 50 pages utiles. Le crawl budget part dans le décor, et la cannibalisation des signaux SEO commence.

Sous le capot : la navigation à facettes est le premier facteur de gaspillage de crawl identifié par Google. Le sujet a sa doc dédiée chez Google Search Central, une seconde page dans la Crawling Infrastructure, et un blog post dédié de décembre 2024. Trois sources officielles, et pourtant la moitié des e-commerces se vautrent encore sur le même piège technique.

Une facette, c'est un filtre dans une page de listing : couleur, taille, marque, prix, matière. Chaque combinaison génère une URL distincte. Le moteur de boutique fait son boulot, sauf que côté Google chaque URL est une page candidate à l'indexation.

Trois conséquences mesurables.

Crawl budget gaspillé. Googlebot crawle des combinaisons inutiles au lieu de découvrir vos nouvelles fiches produit. Les URLs avec query strings sont rendues plus lentement : médiane 13s contre 10s pour les URLs propres, et au 75e percentile on passe de 22 secondes à 31 minutes selon l'étude Vercel sur le rendering Googlebot. Trois ordres de magnitude.

Duplicate content massif. Cinq URLs qui retournent quasi le même listing. John Mueller l'a redit cent fois : pas de pénalité automatique. Mais il y a cannibalisation : Google doit choisir laquelle indexer, vos signaux de ranking se diluent, vos positions chutent.

Soft 404 et thin content. Une combinaison de filtres sans résultat retourne une page vide en HTTP 200. Google la classe en thin content. Multipliée à grande échelle, elle dégrade la qualité globale perçue du domaine.

La vraie question technique ici : quelle facette mérite une URL indexable, laquelle doit disparaître côté crawl, laquelle doit rester crawlable mais hors index ?

Trois cas, trois traitements distincts. Pas de stratégie globale qui marche partout.

Cas 1 : la facette n'a aucune valeur SEO. Tri par prix croissant, tri par popularité, pagination après la page 3, filtre couleur sans volume de recherche. Verdict : on bloque le crawl en amont. Robots.txt ciblé sur le paramètre. Exemple officiel Google extrait de la doc Crawling Infrastructure :

User-agent: *
Disallow: /*?*color=
Disallow: /*?*size=
Disallow: /*?*sort=
Allow: /*?products=all$

Le $ ancre la fin de l'URL. L'Allow explicite est nécessaire si vous voulez préserver une combinaison particulière. Citation directe de Google : "oftentimes there's no good reason to allow crawling of filtered items, as it consumes server resources".

Cas 2 : la facette a une valeur SEO mais elle dilue les signaux. Filtre marque sur une catégorie générique, filtre matière sur une page chaussures. La page filtrée pourrait ranker, mais la page mère doit gagner. Verdict : rel="canonical" vers la page mère sur les URLs filtrées. Effet documenté par Google : "using rel='canonical' may, over time, decrease the crawl volume of non-canonical versions of those URLs". Progressif, pas immédiat. Comptez plusieurs semaines avant de voir l'impact dans les logs.

Cas 3 : volume de recherche prouvé sur la combinaison filtre + catégorie. "Chaussures running rouges", "veste imperméable femme taille 38". Verdict : on indexe pleinement. URL propre (chemin statique de préférence), title et meta description uniques, ajout au sitemap XML, contenu éditorial minimal pour sortir du thin content. C'est de la longue traîne pure.

Cas 4 (filtres de présentation) : noindex, follow. Les filtres qui changent l'affichage sans changer le contenu (pagination, vues grille/liste) restent crawlables et passent le link equity, mais sortent de l'index. Réflexe historique, toujours valide.

Pour les devs dans la salle, cinq règles que Google répète depuis 2014 et qu'on retrouve cassées en audit régulièrement.

Séparateur d'URL : & standard, point. Citation Google : "Characters like comma, semicolon, and brackets are hard for crawlers to detect as parameter separators". Si votre framework génère ?color=red,size=42 au lieu de ?color=red&size=42, vous perdez la lisibilité côté crawler. Refactorer.

Ordre cohérent des paramètres dans les URLs. Une page filtrée par couleur puis taille doit toujours produire ?color=red&size=42 et jamais ?size=42&color=red. Sans cette règle, deux URLs distinctes pour la même page. Duplicate content artificiel généré par votre code.

HTTP 404 sur les combinaisons sans résultat, jamais soft 404. Google : "Return an HTTP 404 status code when a filter combination doesn't return results". Pas de redirect 302 vers la home, pas de page vide en 200. Status code 404 propre.

Fragments #hash non crawlés. Citation Google : "Google Search generally doesn't support URL fragments in crawling and indexing". Si vous voulez vraiment qu'une facette n'existe pas pour le SEO, l'implémenter en hash-based ou full AJAX côté client. Aucune URL générée, aucun problème de crawl. C'est l'option zéro-coût pour les filtres purement UX.

rel="prev/next" est mort depuis mars 2019. Annonce officielle Google le 21 mars 2019 : ils ne l'utilisaient plus en indexation depuis des années. Si votre code legacy le génère encore, vous pouvez le retirer sans risque. Pour gérer la pagination correctement aujourd'hui, soit noindex, follow à partir de la page 2, soit canonical vers page 1, soit (mieux) "view all" avec pagination en complément.

Question qui revient à chaque audit : pourquoi pas tout en canonical ? La réponse est simple : robots.txt empêche le crawl, canonical n'empêche que l'indexation. Sur un site qui souffre de crawl budget, le canonical ne suffit pas. Googlebot continue de venir taper toutes les URLs filtrées, juste pour vous faire plaisir avant de les écarter de l'index.

Robots.txt = on coupe en amont. Économie maximum de crawl budget. Mais on perd le link equity qui passerait par les liens internes vers ces pages.

Canonical = on laisse crawler, on consolide les signaux vers la canonical, le link equity remonte. Mais le crawl continue de coûter.

Règle pragmatique : robots.txt par défaut sur les facettes sans aucune valeur SEO ni link equity à préserver. Canonical sur les facettes intermédiaires (link equity à consolider, mais aucune valeur de ranking propre). Indexation pleine sur les combinaisons à volume prouvé.

Et noindex ? Il s'utilise quand on veut garder le crawl actif (pour le link equity) mais sortir de l'index. C'est le bon choix pour les pages de tri et de présentation, pas pour les vraies facettes produits.

Détail souvent oublié dans la discussion. L'étude Vercel sur le rendering Googlebot a chiffré l'écart entre Next.js en SSR et React en CSR pur : les pages SSR sont indexées dès le premier crawl pass parce que le HTML est complet dans la réponse initiale. Côté CSR, 38 % des pages JavaScript rendues restaient en statut "Discovered, Currently Not Indexed" en 2024.

Pour une boutique e-commerce avec navigation à facettes, le verdict est tranché. SSR (Next.js, Nuxt, Remix) ou Static Site Generation pour les listings catégorie. Les filtres dynamiques côté client peuvent rester en CSR si on les veut hash-based. Mais une URL filtrée censée être indexée doit servir du HTML complet au premier hit, sinon Googlebot la jette dans la file de rendering et vous attendez.

À noter pour maîtriser indexation et crawlabilité : un sitemap XML à jour réduit significativement les délais de découverte, indépendamment du mode de rendu. Sur un site e-commerce, le sitemap doit lister uniquement les URLs canoniques indexables. Pas les URLs filtrées qu'on canonicalise. Pas les pages bloquées en robots.txt. Cohérence totale entre sitemap, canonical et robots.

Avant de toucher au code, vous mesurez. Logs serveur via Screaming Frog Log Analyzer, GSC couverture, échantillon d'URLs filtrées analysées à la main.

Quatre questions par facette :

1. Cette combinaison génère-t-elle du trafic organique mesurable sur les douze derniers mois ?
2. A-t-elle un volume de recherche externe prouvé (Search Console, Ahrefs, Semrush) ?
3. Reçoit-elle des liens entrants à consolider ?
4. Le contenu est-il suffisamment unique pour ne pas tomber en thin content ?

Quatre oui = indexation pleine + sitemap + title/meta uniques. Trois oui = canonical vers page mère. Un ou zéro oui = robots.txt Disallow.

Avant de déployer, deux passes de vérif : crawl Screaming Frog en mode JS rendering pour voir ce que Googlebot voit, et test du robots.txt dans GSC pour confirmer qu'aucune URL canonique ne se retrouve bloquée par erreur. Le combo classique qui casse en prod : un Disallow trop large qui shoote les URLs propres.

Pour aller plus loin sur les patterns adjacents : la gestion du duplicate content à l'échelle d'un domaine, et le robots.txt et sitemap.xml à coupler à la stratégie facettes.

La navigation à facettes ne se traite pas avec une règle unique. C'est un arbre de décision facette par facette, basé sur la valeur SEO mesurée et le link equity à préserver. Robots.txt en première intention quand le filtre n'a aucune utilité de ranking, canonical pour consolider sans renoncer au crawl, indexation pleine sur les combinaisons à volume prouvé, noindex sur les filtres de présentation.

Le coût d'opportunité d'un mauvais traitement se chiffre vite : crawl budget brûlé sur des URLs poubelles pendant que vos nouvelles fiches produit attendent leur tour. Sur un site avec 50 000 SKUs, c'est plusieurs semaines de retard sur l'indexation des nouveautés. À ce niveau-là, ce n'est plus un détail technique, c'est du chiffre d'affaires.

• Google Search Central, "Crawling and indexing : managing faceted navigation", developers.google.com/search/docs/crawling-indexing/crawling-managing-faceted-navigation
• Google Crawling Infrastructure, "Faceted navigation", developers.google.com/crawling/docs/faceted-navigation
• Google Search Central Blog, "Crawling December : Faceted navigation", décembre 2024
• Vercel, "How Google handles JavaScript throughout the indexing process", 2024
• Search Engine Land, "Google no longer supports rel=next/prev", 21 mars 2019
• Search Engine Land, guide complet faceted navigation, 2024-2025