Pages d’atterrissage SEO : maîtriser facettes, indexation Google et maillage interne

Table des matières :

1. Pages d’atterrissage SEO : définition opérationnelle et critères de sélection
2. Facettes PrestaShop (ps_facetedsearch) : génération d’URL et pièges à crawl
3. Indexation Google : décider quoi indexer, puis l’imposer (canonical, noindex, robots, sitemaps)
4. Implémentation côté PrestaShop : hooks, contrôleurs, en‑têtes HTTP et réécriture
5. Maillage interne : transformer les facettes en chemins de crawl maîtrisés
6. Contrôle qualité et monitoring : logs, GSC, IndexNow et détection des pages inutiles

Les pages d’atterrissage SEO en e‑commerce ne sont pas des pages « éditoriales » au sens marketing : ce sont des vues catalogue stables, indexables, et suffisamment différenciées pour capter une intention de recherche (souvent « catégorie + attribut ») sans ouvrir un spider trap via les facettes. Sur PrestaShop (8.1.x à 9.2, PHP 8.2/8.3 en prod), le point dur n’est pas de « créer une page », mais de choisir un sous‑ensemble d’URL facettées que Google doit indexer, puis de forcer cette décision techniquement (canonical, noindex, maillage interne, sitemap).

Un bon repère : si une URL facettée n’a pas vocation à être une « page de destination » stable (au même titre qu’une catégorie), elle doit rester un outil de navigation UX — pas une unité SEO.

Pages d’atterrissage SEO : définition opérationnelle et critères de sélection

Une page d’atterrissage SEO (landing page SEO) est une URL qui correspond à une intention récurrente, qui reste valide dans le temps (stock, assortiment, prix), et qui a une profondeur de clic acceptable pour les robots. En e‑commerce, les pages candidates sont typiquement : catégorie + genre, catégorie + marque, catégorie + gamme de prix, catégorie + usage (« chaussures running homme », « robe invitée mariage grande taille », etc.). Le signal clé à viser n’est pas « beau contenu », mais une cohérence indexation ↔ requêtes ↔ conversion.

D’un point de vue indexation, une page d’atterrissage SEO doit répondre à 3 contraintes minimales : (1) avoir un contenu principal suffisamment distinct (liste produits différente, éventuellement texte court contextualisé), (2) ne pas être un duplicat pur d’une catégorie canonique, (3) ne pas fluctuer au point de devenir un soft‑404 (zéro produit, ou inventaire quasi nul). Dans la pratique, fixez des seuils : par exemple ≥ 8–12 produits disponibles et un volume de recherche non négligeable avant d’autoriser l’indexation.

Pour rendre ces critères actionnables (et éviter les décisions « à l’instinct »), utilisez une grille simple. Exemple de matrice de sélection :

Critère	Pourquoi ça compte	Comment le vérifier (rapide)	Seuil indicatif
Stabilité de l’assortiment	Évite soft‑404 / pages vides	Historique stock, saisonnalité	≥ 8–12 produits la majorité du temps
Intention claire	Améliore CTR & pertinence	Requêtes GSC / auto‑suggest	Requête « catégorie + attribut » récurrente
Différenciation	Réduit duplication/cannibalisation	Chevauchement produits avec page mère	Liste produits significativement différente
Valeur business	Priorise l’effort technique	Taux de conv., marge, panier moyen	Attribut lié à l’achat (marque/usage/taille)
Discoverability	Permet crawl & indexation	Profondeur de clic, liens HTML	Atteignable en ≤ 3 clics depuis catégorie

Mini‑scénario (typique en France/Belgique/Suisse francophone) : une boutique de chaussures a une catégorie « Running ». Les filtres « Homme », « Femme », « Trail », « Route », « Pointure 42 », « Marque » existent pour l’UX. Côté SEO, la boutique « valide » seulement quelques combinaisons à forte intention et stables : running homme, trail homme, running femme, running nike, et évite d’indexer des combinaisons volatiles du type « running + pointure 39 + promo -30% » (trop instable, et souvent sans volume).

Le risque structurel, surtout avec ps_facetedsearch, est de confondre « filtres utiles à l’utilisateur » et « pages indexables ». Vous pouvez garder 100% des facettes pour l’UX, tout en ne rendant indexables que 1–5% des combinaisons. L’objectif est de réduire la surface d’URL crawlables : une boutique avec 200 catégories, 8 facettes, 10 valeurs par facette peut théoriquement générer des millions de combinaisons. Google le rappelle dans sa doc sur le crawl : « Crawl budget is the number of URLs Googlebot can and wants to crawl. » (Google Search Central, Managing crawl budget, https://developers.google.com/search/docs/crawling-indexing/large-site-managing-crawl-budget). Si vous laissez le budget se dissoudre dans des variantes, vos pages stratégiques (catégories, produits) perdent en fréquence de crawl.

• La page a une requête cible (GSC, outil mots‑clés, ou au minimum autosuggest + logique marché).
• Elle a un inventaire suffisant et un plan si le stock descend (fallback, redirection, ou désindexation).
• Elle est liée en HTML depuis une page forte (catégorie mère, menu, bloc « populaire »).
• Elle a une canonical cohérente (auto‑référente si indexable).
• Elle n’entraîne pas une explosion combinatoire (pas de multi‑facettes instables du type promo/stock/prix dynamique).

Facettes PrestaShop (ps_facetedsearch) : génération d’URL et pièges à crawl

Dans le core, la navigation à facettes (module ps_facetedsearch) génère le plus souvent des URL avec query string (ex. ?q=Marque-Nike/Couleur-Noir/Taille-42) ou des paramètres proches selon thème/override. Le module est avant tout orienté UX : il optimise le filtrage côté SQL, mais il ne fournit pas nativement une stratégie SEO robuste pour : canonicaliser, dédupliquer, créer des landing pages stables, ni gérer finement l’indexabilité par combinaison.

Techniquement, le piège est double. D’abord, la facette peut créer des variations à l’infini (ordre des filtres, pagination, tri order=price, plages de prix, etc.). Ensuite, ces variations sont souvent liées entre elles (les blocs facettes pointent vers d’autres combinaisons), ce qui construit un graphe d’URL qui « aspire » Googlebot. Le résultat classique en logs : des hits Googlebot majoritairement sur des URL ?q= et quasi pas sur des produits récents.

Trois sources de « variantes invisibles » (souvent sous‑estimées) :

• Permutation des filtres : Marque-Nike/Couleur-Noir vs Couleur-Noir/Marque-Nike (même résultat, URL différente).
• Paramètres de tri : order=price / order=quantity ; ces pages n’ajoutent généralement aucune valeur SEO.
• Pagination + facettes : page=7 d’une combinaison filtrée est rarement une landing SEO (et peut générer des centaines d’URL supplémentaires).

Sur des catalogues conséquents, le bruit n’est pas seulement SEO : il devient opérationnel (charge DB, cache inefficace, pages lentes au pire moment). Une règle pragmatique : plus les facettes s’appuient sur des calculs (prix, remise, disponibilité, « nouveautés »), moins elles doivent produire d’URL indexables.

Ajoutez à cela les aspects non‑SEO : sécurité et charge. Les endpoints de filtrage peuvent devenir un vecteur de bruit applicatif (trop de requêtes, combinaisons pathologiques) et un point d’exposition. Une mitigation classique côté trafic consiste à limiter les comportements abusifs (rate‑limit, règles WAF, bannissement) et à surveiller les patterns de requêtes sur ?q=. Exemple côté durcissement : PrestaShop sécurité : bloquer la navigation à facettes via fail2ban https://www.expertise-prestashop.fr/2026/07/08/prestashop-securite-bloquer-la-navigation-a-facettes-via-fail2ban/.

Astuce « anti spider trap » sans toucher au module : normaliser ce que vous pouvez contrôler (au moins) :

• Forcer une canonical stable même si l’ordre des filtres change.
• Empêcher l’indexation des pages de tri (order=), des pages au‑delà d’une profondeur de pagination (ex. page>3), et des filtres instables (promo, stock, « nouveau »).

Indexation Google : décider quoi indexer, puis l’imposer (canonical, noindex, robots, sitemaps)

La règle pratique : indexer uniquement les pages qui apportent une valeur de recherche. Tout le reste doit être soit (a) non indexé mais crawlable pour que Google comprenne la canonicalisation, soit (b) bloqué au crawl si c’est du pur bruit (paramètres de tri, combinaisons explosives) et si vous acceptez que Google n’en voie pas le contenu. Le point non négociable : éviter de mettre une canonical vers une URL que vous bloquez dans robots.txt (Google ne peut pas confirmer la canonical si la page source est inaccessible au crawl).

Pour la déduplication, basez‑vous sur la définition Google : « A canonical page is the preferred version of a set of duplicate pages. » (Google Search Central, Consolidate duplicate URLs, https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls). Concrètement :

• Si la combinaison facettée n’est pas une landing SEO : mettez rel="canonical" vers la catégorie « mère » (ou vers une landing SEO parent) et ajoutez noindex, follow.
• Si la combinaison est une landing SEO : canonical vers elle‑même, index, et contenu minimal différenciant.

Le noindex doit être compris comme un contrôle d’indexation, pas de crawl. La doc Google définit explicitement la directive : « noindex: Do not show this page, media, or resource in search results. » (Google Search Central, Robots meta tag, https://developers.google.com/search/docs/crawling-indexing/robots-meta-tag). C’est exactement ce que vous voulez pour les variantes d’URL UX : laisser Google passer (follow), mais empêcher l’index. Pour les paramètres purement techniques (tri, pagination extrême), un blocage robots.txt peut rester pertinent, mais seulement si vous ne comptez pas sur la canonical et que vous acceptez de ne pas « nettoyer » l’index via noindex.

Un tableau de décision (simple) aide à garder une stratégie cohérente :

Type d’URL	But	Indexation	Canonical	Présence sitemap
Catégorie « mère »	Capter intention générique	Index	Self	Oui
Produit	Capter requêtes transactionnelles	Index	Self	Oui
Landing SEO (catégorie+attribut)	Capter intention spécifique stable	Index	Self	Oui (si validée)
Facette pure UX (?q=)	Naviguer, pousser vers produits	Noindex, follow	Vers catégorie/landing parent	Non
Tri (order=), vues techniques	Fonctionnel, sans valeur SEO	Bloquer crawl ou noindex	Vers page propre	Non
Pagination profonde	Explorer produits, mais faible valeur	Souvent noindex	Vers page 1 ou self selon stratégie	Non

Enfin, votre sitemap doit refléter votre stratégie d’indexation (et non votre UX). Ne mettez que les URL que vous voulez indexer : catégories, produits, CMS, et éventuellement les landing pages SEO « validées ». Un sitemap qui liste 200k URLs facettées est un signal de bruit. Sur ce point, référez‑vous à Plan de site : optimiser l’indexation Google avec un sitemap clair https://www.expertise-prestashop.fr/2026/07/24/plan-de-site-optimiser-lindexation-google-avec-un-sitemap-clair/ et, si vous pilotez l’indexation multi‑moteurs, à IndexNow : intégration PrestaShop et stratégie d’indexation pour e-commerce https://www.expertise-prestashop.fr/2026/07/28/indexnow-integration-prestashop-et-strategie-dindexation-pour-e-commerce/.

Point « GEO » (au sens géolocalisation / marché) souvent utile en e‑commerce francophone : si vous avez des déclinaisons par pays (FR/BE/CH), ne confondez pas pages « filtrées » et pages « localisées ». Une page « chaussures running homme » peut exister en /fr/ et /be/ pour des raisons légitimes (devise, livraison, disponibilité). Dans ce cas, la canonicalisation doit rester dans la même version locale, et la logique d’indexation doit s’aligner avec hreflang (si vous en avez) — sinon vous risquez d’ajouter de la duplication entre pays en plus de la duplication par facettes.

Implémentation côté PrestaShop : hooks, contrôleurs, en‑têtes HTTP et réécriture

Sur PrestaShop 8.1/9.x, vous avez trois niveaux d’action : (1) la vue (Twig/Smarty selon thème), (2) le contrôleur front (Symfony ou legacy selon page), (3) le serveur (Nginx/Apache) via en‑têtes et règles. Le core n’offre pas un « switch » simple par combinaison de filtres ; si vous voulez une vraie gouvernance, vous finirez presque toujours par : une table de mapping des combinaisons indexables, plus un plugin/hook qui applique canonical + robots selon règles.

Une approche qui tient dans le temps consiste à stocker une whitelist sous forme de « règles » :

• catégorie ID (ou route),
• attribut (marque, genre, usage),
• slug SEO attendu,
• statut (actif/inactif),
• seuil stock minimal (optionnel).

Ainsi, quand le merchandising change (marques ajoutées/retirées), vous ne « cassez » pas la couche SEO : vous l’administrez.

1) Canonical et robots au bon endroit

Le plus fiable est d’injecter les directives côté HTML et éventuellement en en‑tête HTTP. Exemple de stratégie :

• Pour toutes les URL contenant ?q= (ps_facetedsearch) : envoyer X-Robots-Tag: noindex, follow.
• Pour les landing pages SEO validées : ne rien envoyer (index par défaut) et rendre la canonical auto‑référente.

En Nginx, une version simple (à adapter, testez sur staging) :

# Attention : pattern indicatif, à adapter au routing réel.
if ($arg_q != "") {
  add_header X-Robots-Tag "noindex, follow" always;
}

C’est brutal mais efficace pour « purger » l’index des variantes, tout en laissant vos landing SEO propres (qui devraient idéalement ne pas dépendre de ?q=). Si vous gardez des landing sur paramètres, vous devrez les whitelister (regex + condition) : c’est faisable, mais ça devient vite fragile.

• Cohérence HTML vs HTTP : évitez de dire « index » dans le HTML et « noindex » en HTTP sur la même URL.
• Tests sur échantillon : validez 10–20 URL facettées (avec et sans produits, avec pagination, avec tri) via « Inspection d’URL » dans GSC et via curl -I pour vérifier l’en‑tête X‑Robots-Tag.

2) Sortir des paramètres : URLs réécrites et landing pages dédiées

La solution robuste est de créer des URLs stables hors query string, par exemple : /chaussures-running/homme/ ou /chaussures-running/nike/. Deux approches : (a) module « SEO filter pages » qui génère des routes et des pages dédiées, (b) contrôleur custom qui rejoue le filtrage en interne (en utilisant les mêmes contraintes que ps_facetedsearch) mais expose une URL canonique réécrite. L’intérêt est triple : vous maîtrisez le canonical, vous pouvez ajouter un contenu statique minimal, et vous évitez le chaos des permutations de paramètres.

• 1 intention = 1 URL : une landing « running homme » ne doit pas exister en 5 variantes (slash final, majuscules, ordre des segments, etc.). Mettez des 301 vers la forme canonique.
• Évitez les attributs instables dans l’URL : prix, remise, disponibilité. Gardez ces filtres en UX.
• Pensez internationalisation : si vous avez fr/en, la route doit rester cohérente (et les slugs traduits) pour éviter la duplication entre langues.

Côté perf, attention : le filtrage facetté peut coûter cher en SQL sur gros catalogues (joins + agrégations). Si vous exposez des landing pages stables, mettez un cache (Redis, full page cache, ou au minimum cache applicatif des résultats de filtres) et surveillez TTFB/INP. Les impacts sont très concrets sur Core Web Vitals et sur le crawl. Référence utile : PrestaShop performance : optimiser gros catalogues et Core Web Vitals https://www.expertise-prestashop.fr/2026/07/27/prestashop-performance-optimiser-gros-catalogues-et-core-web-vitals/.

Maillage interne : transformer les facettes en chemins de crawl maîtrisés

Le maillage interne est le levier qui « rend vrai » votre sélection de landing pages. Si une landing SEO existe mais n’est accessible que via 5 clics et une combinaison de filtres JS, Google la découvrira tard (ou jamais). À l’inverse, si vos facettes lient tout vers tout, vous amplifiez le spider trap. Votre objectif : lier fortement les landing pages indexables, et affaiblir (ou encapsuler) les liens vers les variantes non indexables.

Concrètement, partez d’une taxonomie de liens en 3 couches :

1. Liens structurels (header, menu catégories, breadcrumbs) vers les pages mères.
2. Liens SEO (blocs « Affiner par … » statiques, blocs « Marques populaires », « Tailles les plus demandées ») vers les landing pages whitelistées.
3. Liens UX (facettes complètes) qui peuvent rester, mais dont les URL doivent être non indexables (noindex, follow) et idéalement non présentes dans le sitemap.

Ce découplage est souvent impossible « proprement » avec un thème standard : il faut modifier le template facettes pour n’exposer en dur (HTML simple) qu’un sous‑ensemble de valeurs (top N), et garder le reste en interaction (dépliage, pagination de facettes, etc.).

Deux exemples concrets (sobres, mais efficaces) de « liens SEO » :

• Sur une catégorie « Robes », afficher en haut de liste 6 liens HTML : « Robe longue », « Robe courte », « Robe grande taille », « Robe invitée mariage », « Robe noire », « Robe cérémonie ». Ce sont des intentions stables et compréhensibles.
• Sur « Chaussures running », afficher un bloc « Marques les plus recherchées » (Nike, Asics, Adidas, Salomon) uniquement si vous avez assez de produits par marque ; sinon, vous créez des pages faibles.

Pour garder les bonnes pratiques SEO e‑commerce (breadcrumbs, données structurées, cohérence des ancres), relisez SEO e-commerce : implémenter schema Product Review Breadcrumb et maillage interne https://www.expertise-prestashop.fr/2026/07/16/seo-e-commerce-implementer-schema-product-review-breadcrumb-et-maillage-interne/ et, côté fiches produit (qui doivent rester prioritaires en crawl), SEO PrestaShop : optimiser fiches produits, schema.org et images WebP https://www.expertise-prestashop.fr/2026/07/20/seo-prestashop-optimiser-fiches-produits-schema-org-et-images-webp/.

Un point souvent sous-estimé : les pages facettées non indexables doivent quand même pousser du PageRank interne vers les produits (d’où follow). Le compromis standard (testé sur des catalogues > 200k produits) est : noindex, follow + canonical vers la catégorie.

Dans un cas concret (boutique multi‑catégories mode), le passage d’un index « pollué » (~650k URL indexées dont 80% facettes) à un index « piloté » (~55k URL) a amélioré le crawl des nouveautés et la couverture produit en 6–8 semaines, avec une hausse organique mesurée à +10–20% selon familles. Ce n’est pas magique : c’est juste la conséquence directe d’un graphe de liens et d’un budget crawl redevenus utiles.

Contrôle qualité et monitoring : logs, GSC, IndexNow et détection des pages inutiles

Sans validation, vous ne saurez pas si Google suit vos directives ou si votre site génère encore des variantes à la volée. Le premier niveau est Google Search Console : rapports d’indexation (pages « Exclues par noindex », « Dupliquées, Google a choisi une autre canonical »), exploration (stats de crawl), et inspection d’URL sur des exemples d’URL facettées. Le deuxième niveau (beaucoup plus fiable) est l’analyse de logs serveur : proportion de hits Googlebot sur /category/, /product/, versus ?q=/order=/page=.

Sur Nginx/Apache, vous pouvez extraire rapidement un indicateur par grep/awk (exemple indicatif) :

# Exemple : compter les hits Googlebot sur URLs contenant ?q=
grep -i "googlebot" /var/log/nginx/access.log | grep "?q=" | wc -l

Pour aller un cran plus loin (sans outillage lourd), suivez 3 KPI hebdomadaires :

• Part des hits Googlebot sur URLs facettées (?q=) vs catégories/produits.
• Nombre d’URL « Discovered – currently not indexed » (GSC) sur les variantes (si ça monte, vous nourrissez encore du bruit).
• Couverture des pages clés : catégories mères + nouveautés produits (si elles ne sont pas recrawlées, c’est mauvais signe).

Ce que vous voulez voir : une baisse nette des hits sur les variantes facettées non stratégiques, et une hausse relative sur catégories/produits. Si vous observez l’inverse, c’est que votre maillage interne (ou vos redirections/canonical) envoie toujours les robots dans le labyrinthe.

Enfin, surveillez les effets secondaires : pages vides (zéro produit après filtres), timeouts/503 lors de pics, ou pages qui deviennent « soft 404 » parce que l’assortiment change. Les pages vides sont un signal SEO négatif et un symptôme de facettes mal gouvernées ; voir Page vide : causes fréquentes et impact sur l’indexation Google https://www.expertise-prestashop.fr/2026/07/27/page-vide-causes-frequentes-et-impact-sur-lindexation-google/ et, pour formaliser vos contrôles avant mise en prod, Audit SEO technique : contrôle qualité avant publication des pages web https://www.expertise-prestashop.fr/2026/07/08/audit-seo-technique-controle-qualite-avant-publication-des-pages-web/.

Si vous devez industrialiser la découverte/indexation (multi‑moteurs, feed, push), couplez votre stratégie de landing pages avec un ping contrôlé (IndexNow) uniquement sur les URL indexables et stables. Le but n’est pas d’accélérer l’indexation du bruit, mais de prioriser les pages qui ont un ROI crawl : produits qui tournent, catégories fortes, et landing pages SEO validées. Pour le protocole et ses contraintes (format, limites, endpoints), la documentation officielle est ici : https://www.indexnow.org/documentation.

Le reste doit rester du filtrage UX — utile pour l’utilisateur, invisible dans l’index.