SEO technique e-commerce : crawl, rendu et indexation à grande échelle

Le SEO technique e-commerce, c'est le travail qui permet aux moteurs de recherche d'explorer, de rendre et d'indexer les bonnes URL d'une boutique en ligne, et de comprendre ce que vend chaque fiche produit. Il couvre le contrôle du crawl, le rendu JavaScript, les règles d'indexation par type de page, l'architecture du site, la pagination, les sitemaps XML, les données structurées et la vitesse des pages. Sur un site vitrine de dix pages, la plupart de ces points se règlent d'eux-mêmes. Sur un catalogue, non, car chaque produit, variante, filtre, ordre de tri, numéro de page et langue multiplie le nombre d'URL qu'un crawler peut trouver.

Ce guide s'adresse aux boutiques qui ont déjà fait les bases. Si tu as besoin d'un premier passage, commence par l'audit SEO e-commerce, et pour les filtres, lis le guide SEO de la navigation à facettes. Ici, on descend d'un niveau : comment mesurer ce que Googlebot fait réellement sur ta boutique, et comment définir des règles par template qui tiennent quand le catalogue double.

L'inventaire des URL : compte ce qu'un crawler pourrait trouver avant de corriger quoi que ce soit

La plupart des problèmes de SEO technique des boutiques sont de l'arithmétique. Avant de modifier la moindre balise, note combien d'URL chaque template peut produire. Prenons comme fil rouge une boutique d'équipement outdoor :

• 4 200 produits, dont 1 300 avec des variantes, soit 11 000 SKU de variantes au total.
• 180 catégories, chacune avec 5 filtres, 4 ordres de tri et 24 produits par page.
• 3 langues (anglais, néerlandais, allemand) dans des sous-dossiers.
• Sélection des variantes via un paramètre ?variant=, recherche interne sur /search?q=.

Les produits seuls donnent 12 600 URL produit sur trois langues. Les paramètres de variante en ajoutent jusqu'à 33 000 de plus s'ils sont liés. Les catégories, avec 3 pages en moyenne, donnent 1 620 URL de listing, et les 4 ordres de tri les multiplient pour atteindre 6 480 avant même qu'un seul filtre soit cliqué. Combine deux filtres et tu arrives à six chiffres. La boutique veut environ 14 200 URL dans l'index : les produits, les catégories et leur pagination, en trois langues.

Cet écart entre URL possibles et URL souhaitées, c'est tout le travail. Chaque règle de la suite de ce guide empêche des URL indésirables d'être trouvées, indique à Google quelle version indexer, ou rend les URL souhaitées plus faciles à atteindre et à comprendre.

Les logs serveur montrent ce que Googlebot demande réellement

Un crawler comme Screaming Frog montre ce qui peut être trouvé depuis la page d'accueil. Tes logs serveur montrent ce que Googlebot a vraiment récupéré, à quelle fréquence et avec quelle réponse. Sur un catalogue, c'est rarement la même chose. Demande à ton hébergeur ou à ta plateforme les logs d'accès bruts sur au moins 30 jours, filtre sur le user agent Googlebot et écarte les requêtes qui échouent à une vérification DNS inverse, car beaucoup de scrapers imitent ce user agent.

Regroupe ensuite chaque requête par template, à l'aide des modèles d'URL que tu connais déjà (/products/, /collections/, ?sort=, ?page=, /search). Les questions utiles sont simples :

• Part des requêtes par template. Si les URL de tri et de filtre prennent 40 % des requêtes de Googlebot alors que les produits n'en prennent que 25 %, l'activité de crawl va au mauvais endroit.
• Jours depuis le dernier crawl par produit. Les produits que Googlebot n'a pas demandés depuis 30 jours afficheront des prix et un stock périmés dans la recherche.
• Codes de statut par template. Une pile de 301 sur les URL produit signifie en général que des liens internes pointent encore vers d'anciennes URL.
• Produits jamais explorés. Les produits de ton export catalogue qui n'apparaissent pas dans 30 jours de logs sont en pratique invisibles.

Si tu ne peux pas obtenir les logs, le rapport Statistiques sur l'exploration (Crawl Stats) de Search Console est la meilleure source suivante. Il ventile les requêtes par code de réponse, type de fichier, type de Googlebot et objectif, où la découverte désigne une URL que Google n'a jamais explorée et l'actualisation un nouveau crawl d'une page connue. Une boutique qui lance 300 nouveaux produits par semaine et ne voit presque aucune requête de découverte a un problème de découverte, en général dans les sitemaps ou les liens internes.

Crawl gaspillé sur un catalogue : soft 404, chaînes de redirections et noindex

Le guide de Google sur le budget de crawl est écrit pour les sites d'1 million de pages uniques ou plus qui changent environ chaque semaine, ou de 10 000 pages ou plus qui changent chaque jour. Une boutique de 4 200 produits est sous ces deux seuils, mais les combinaisons de filtres et de tris peuvent pousser le nombre d'URL explorables bien au-dessus, et les changements de prix ou de stock font changer les fiches produit chaque jour. Considère donc l'efficacité du crawl comme une vraie contrainte dès que tes logs montrent que Googlebot passe la plupart de son temps hors de tes URL souhaitées.

Le même guide liste ce qui gaspille le crawl sur les boutiques :

• Soft 404. Une fiche produit épuisée qui affiche « plus disponible » avec un statut 200 continue d'être explorée. Renvoie un vrai 404 ou 410 pour les produits qui ont disparu, ou redirige-les vers un successeur proche.
• Longues chaînes de redirections. Un produit renommé trois fois peut se trouver derrière trois sauts. Fais pointer les liens internes et les entrées du sitemap directement vers l'URL finale.
• Le noindex pour économiser du crawl. Google demande quand même une page en noindex puis l'écarte, donc le noindex n'économise pas de crawl. Utilise le robots.txt pour les modèles d'URL que tu ne veux jamais voir explorés, comme les ordres de tri et la recherche interne.
• Absence de lastmod. Google lit les sitemaps régulièrement. Un <lastmod> exact sur les produits modifiés l'aide à choisir ce qu'il doit explorer à nouveau.
• Pas de support du 304. Les serveurs qui répondent 304 Not Modified pour les pages inchangées permettent à Google de réutiliser sa copie, ce qui compte quand des milliers de fiches produit n'ont pas changé depuis la dernière visite.

La santé du serveur compte aussi. Quand la boutique répond avec des erreurs 5xx ou des limites de débit 429, Google ralentit le crawl et n'accélère à nouveau que progressivement. Un template de catégorie lent pendant des soldes peut te coûter le nouveau crawl des produits mêmes dont tu viens de changer le prix.

Rendu : ce que Googlebot voit avant et après le JavaScript

Google traite les sites JavaScript en trois phases : crawl, rendu et indexation. Selon les bases du SEO JavaScript de Google, chaque page avec un statut 200 entre dans une file de rendu, où elle peut attendre quelques secondes ou plus. Deux conséquences comptent pour les boutiques. D'abord, Google ne découvre que les liens qui sont des éléments <a> avec un href, donc un carrousel « produits associés » construit avec des gestionnaires de clic ne transmet aucun lien. Ensuite, tout ce qui n'existe qu'après le rendu arrive plus tard que ce qui se trouve dans le HTML.

Ce deuxième point est critique pour les données produit. Google indique que le balisage Product généré dynamiquement peut rendre les crawls Shopping moins fréquents et moins fiables, ce qui pose problème pour un contenu qui change vite comme le prix et la disponibilité. Si ton thème ou ton front-end headless injecte le JSON-LD Product avec du JavaScript après un appel API côté client, déplace-le dans le HTML rendu côté serveur.

Un test rapide par template : ouvre le code source de la page (pas l'inspecteur) et cherche le nom du produit, le prix, le GTIN et les deux premiers liens de catégorie. Lance ensuite l'outil d'inspection d'URL dans Search Console et compare avec le HTML rendu. Tout ce qui manque dans le source mais apparaît après le rendu dépend de la file de rendu.

• Doit être dans le HTML serveur : balise title, canonical, meta robots, H1, prix, disponibilité, JSON-LD Product, liens du fil d'Ariane, liens vers les produits sur les pages de catégorie, liens de pagination.
• Peut être rendu côté client : widgets d'avis sous la ligne de flottaison, articles récemment consultés, recommandations personnalisées, chat.

Des règles d'indexation par template, écrites une fois pour tout le catalogue

Les décisions URL par URL ne passent pas à l'échelle. Écris une règle par template et applique-la dans le thème ou les réglages de la plateforme. Pour la boutique outdoor, cela donne ceci :

Les règles au niveau des champs, comme les titres, descriptions et images de chaque fiche produit, sont traitées dans le guide SEO des fiches produit. Les réglages propres à chaque plateforme se trouvent dans la checklist SEO Shopify et le guide SEO Magento.

Architecture de site pour les grands catalogues : profondeur, hubs et produits orphelins

L'architecture détermine la vitesse à laquelle un crawler atteint un produit et le poids de liens internes qu'il reçoit. Sur un catalogue, le menu pointe vers les catégories, les catégories vers les produits, et les produits pointent latéralement vers des produits associés et remontent par le fil d'Ariane. Trois vérifications gardent cette structure saine à mesure que le catalogue grandit :

• Profondeur de clic. Explore depuis la page d'accueil et compte les clics jusqu'à chaque produit. Si les pages de listing ne pointent que vers la page suivante, un produit en page 6 d'une catégorie de 140 produits se trouve à 7 clics de la page d'accueil. Diviser cette catégorie en quatre sous-catégories de 35 produits le ramène à 4.
• Taille des catégories. Une catégorie de 1 200 produits à 24 par page compte 50 pages, et les produits des dernières pages sont les moins explorés. Des sous-catégories basées sur de vrais attributs (type d'isolation, poids de garnissage) raccourcissent cette traîne et te donnent des pages d'atterrissage pour de vraies requêtes.
• Orphelins. Compare les URL de ton export produits avec les URL atteintes par un crawler. Les produits présents dans l'export mais absents du crawl n'ont aucun lien interne : souvent des articles rattachés à aucune catégorie, ou listés seulement dans une catégorie masquée du menu.

Les orphelins sont en général un problème de données produit, pas de thème. Un produit avec un champ catégorie vide n'apparaît jamais sur une page de listing. Corrige d'abord le rattachement aux catégories dans ton catalogue, puis vérifie que le template affiche le lien sous forme de <a href> explorable.

Numéros de page, boutons « charger plus » et scroll infini

Les recommandations de Google sur la pagination pour l'e-commerce sont courtes et précises. Donne à chaque page sa propre URL, par exemple ?page=2. Ne définis pas la page 1 comme canonical de toute la série, car cela indique à Google que les pages 2 et suivantes sont des doublons et les produits qui s'y trouvent perdent un chemin de découverte. Relie les pages entre elles avec des liens <a href> normaux. Google n'utilise plus rel="next" et rel="prev", même si d'autres moteurs de recherche peuvent le faire.

Les boutons « charger plus » et le scroll infini demandent de l'attention. Les crawlers de Google ne cliquent pas sur les boutons et ne déclenchent en général pas le JavaScript qui nécessite une action de l'utilisateur. Si ta catégorie utilise le scroll infini, garde derrière une version paginée avec de vrais liens, et assure-toi que chaque produit figure aussi dans ton sitemap XML ou dans un feed Merchant Center pour qu'il puisse être trouvé sans le listing.

Deux conseils propres aux catalogues : choisis une taille de page qui garde la plupart des catégories sous cinq pages, et ne mets jamais les numéros de page derrière un fragment #, car Google ignore les identifiants de fragment.

Des sitemaps XML générés à partir des données produit

Un sitemap est une liste des URL que tu veux voir dans la recherche. Sur une boutique, il doit être généré à partir du catalogue, pas d'un crawl. La documentation de Google sur les sitemaps fixe les limites et les règles :

• Chaque sitemap contient au maximum 50 000 URL ou 50 Mo non compressés. Utilise un index de sitemaps pour combiner plusieurs fichiers.
• Utilise des URL absolues et ne liste que les URL canoniques, la version que tu veux voir dans les résultats.
• Google ignore <priority> et <changefreq>, alors n'y passe pas de temps.
• Google n'utilise <lastmod> que s'il est exact de façon constante. Modifie-le pour des mises à jour significatives du contenu principal, des données structurées ou des liens, pas pour une nouvelle année de copyright.

Divise les sitemaps par template et par langue, par exemple products-en.xml, products-nl.xml et categories-en.xml. Search Console rapporte alors l'indexation par fichier, et tu peux voir que 96 % des produits anglais sont indexés contre seulement 61 % des allemands. Laisse de côté les URL redirigées, en noindex, canonicalisées vers une autre page et supprimées. Et pilote <lastmod> depuis la fiche produit : un changement de prix met à jour le balisage Offer, donc il compte comme un changement de données structurées.

Données structurées à grande échelle : génère-les depuis le catalogue, pas depuis le thème

La plupart des boutiques produisent le balisage Product depuis un template de thème, ce qui fonctionne jusqu'à ce que les données derrière soient incomplètes ou que les variantes se compliquent. À l'échelle d'un catalogue, traite les données structurées comme un export de tes données produit et vérifie-les comme tu vérifies un feed.

Pour les variantes, Google prend en charge le balisage ProductGroup. Le parent porte un productGroupID (le SKU parent), variesBy nomme les dimensions qui changent, et hasVariant liste chaque variante comme un Product. Les valeurs variesBy prises en charge sont color, size, suggestedAge, suggestedGender, material et pattern. Il existe deux configurations :

• Page unique : toutes les variantes vivent sur une seule page, avec une seule URL canonique pour le groupe. Chaque variante a quand même besoin d'une URL distincte qui la présélectionne, en général un paramètre de requête.
• Multi-pages : chaque variante a sa propre page avec un balisage complet et autonome. Il n'y a pas de canonical unique pour le groupe.

Prends une doudoune vendue en 3 couleurs et 5 tailles : 15 variantes, chacune avec son propre GTIN, prix et stock. Si le template lit la couleur et la taille sur le parent, les 15 objets de variante indiquent les mêmes valeurs et Google voit des doublons. Si 4 des 15 GTIN sont vides, ces variantes partent sans identifiant. Aucun de ces problèmes n'apparaît dans un aperçu du thème, et les deux se corrigent dans les données, pas dans le balisage.

Vérifications pratiques à grande échelle : valide une URL par template avec le test des résultats enrichis, puis surveille les rapports Fiches marchand et Extraits de produits dans Search Console pour repérer les erreurs réparties sur de nombreuses URL. Compte les valeurs GTIN, marque, couleur et taille vides par catégorie dans ton catalogue avant d'accuser le template. Pour un exemple de référence auquel comparer ta sortie, utilise le générateur de schema produit.

Images LCP, décalages de mise en page et scripts d'apps sur les templates de catalogue

Les problèmes de vitesse des boutiques se répètent par template, alors mesure une fiche produit et une page de catégorie par type de template sur un téléphone de milieu de gamme, puis corrige le template. L'image produit est en général l'élément Largest Contentful Paint. Ne la charge jamais en lazy-load, rends-la découvrable dans le code source HTML au lieu de l'injecter avec du JavaScript, et donne-lui fetchpriority="high". Décompose un LCP lent en ses parties (réponse du serveur, délai de chargement, durée de chargement et délai de rendu) avant d'acheter un hébergement plus rapide, car le retard vient souvent d'un script qui s'exécute avant que l'image soit demandée.

Les décalages de mise en page sur les pages de catalogue viennent souvent des données : images sans largeur ni hauteur, pastilles de couleur qui se chargent après le prix, badge « stock faible » qui pousse le bouton d'ajout au panier vers le bas. Stocke les dimensions des images avec la fiche image pour que le template puisse réserver l'espace. Les délais d'interaction viennent en général des scripts de filtres et des apps tierces, alors liste chaque script d'une page de catégorie avec l'app qui le charge et supprime ce que personne n'utilise.

Une routine trimestrielle de SEO technique pour un catalogue en croissance

Plusieurs de ces vérifications commencent dans le catalogue plutôt que dans le code. L'analyse de couverture des sitemaps de WISEPIM associe les URL de ton sitemap aux fiches produit, et l'analyse des liens internes liste les produits orphelins à côté de leurs données Search Console. Comme WISEPIM garde les GTIN, les catégories et les attributs de variante complets avant qu'ils soient poussés vers ta boutique, les données structurées et les sitemaps construits à partir de ces données restent corrects à mesure que le catalogue grandit.