Un client m'a appelé en 2022, un e-commerce britannique avec environ 14 000 pages produit, furieux d'avoir perdu 34 % du trafic organique en six semaines. Pas de pénalité manuelle. Pas d'annonce d'algorithme. Juste un effondrement lent et silencieux. On a lancé un crawl complet avec Screaming Frog et trouvé le problème en 90 minutes : leur pagination générait automatiquement des milliers d'URLs quasi-dupliquées, Google les avait toutes crawlées au lieu des vraies pages produit, et leur crawl budget était complètement épuisé. Gaspillé. Chaque mois.
Point clé : Auditer un site de 10 000 pages n'est pas simplement un audit de petit site à plus grande échelle : les modes de défaillance sont le budget de crawl, les templates et l'indexation à l'échelle, et la checklist change en conséquence.
C'est ça, le SEO sur gros sites. Les problèmes ne sont pas plus difficiles à comprendre, juste catastrophiquement plus graves dans leurs conséquences. Une balise canonical mal configurée sur un site de 20 pages, c'est pénible. Sur un site de 14 000 pages, ça peut étouffer silencieusement tout votre index.
C'est la checklist d'audit que j'utilise chez Seahawk Media quand un site dépasse les 10 000 pages. Sans ordre de priorité particulier, parce que chaque gros site a sa propre hiérarchie de désastres.
---
Commencer par le Crawl Budget, Pas les Mots-clés
La plupart des gens commencent un audit de gros site en regardant les classements. Mauvais ordre. Complètement faux. Les classements sont en aval de l'indexation, et l'indexation est en aval du budget de crawl. Corrigez l'ordre des opérations.
Crawl budget, pour ceux qui en ont besoin en version simple : c'est le nombre d'URLs que Googlebot va crawler sur votre site pendant une période donnée. La documentation Google sur le crawl budget vaut vraiment le coup d'être lue, ils sont très précis sur ce qui le gaspille.
Qu'est-ce qui brûle votre budget ?
Récupérez d'abord vos server logs. Pas les données GSC, les vraies server logs. J'utilise GoAccess pour une analyse rapide sur gros volumes de logs parce que ça gère le volume sans crise. Ce que vous cherchez :
- Les URLs de navigation facettée (par ex., /shoes?colour=red&size=10&sort=price)
- Les IDs de session ajoutés aux URLs
- Les implémentations de scroll infini ou « charger plus » qui génèrent des chaînes de paramètres uniques
- Les URLs paginées en doublon (/page/1 et /) qui sont toutes les deux crawlées
- Les pages de résultats de recherche interne qui ne sont pas bloquées
Tout site de plus de 10 000 pages avec une navigation par facettes active saigne presque certainement le crawl budget. Presque certainement. La solution n'est pas glamour, c'est un disallow robots.txt sur les patterns de paramètres, ou idéalement, un bon URL parameter handling via GSC combiné avec des balises canoniques sur les pages par facettes elles-mêmes.
Au début de 2021, Seahawk avait un client meublier avec 23 000 URLs produits. Ça avait l'air correct en surface. Mais leur analyse des logs montrait que Googlebot passait 61% de ses crawls sur des combinaisons de filtres à facettes qui avaient zéro demande de recherche et zéro contenu unique. Leurs vraies pages produits étaient crawlées à peu près une fois tous les 14 jours. On a mis les paramètres de facette en noindex, follow et on a disallowed les patterns combinatoires lourds dans robots.txt. En six semaines, la fréquence moyenne de crawl sur les vraies pages produits a baissé à tous les 3-4 jours.
---
Audit d'Indexation : Qu'est-ce qui est réellement dans l'Index de Google ?
site:yourdomain.com dans Google vous donne une figure approximative. Ne vous y fiez pas pour la précision, mais c'est une vérification rapide. Recoupez avec le rapport Index Coverage de GSC.
L'écart entre « les pages que vous voulez indexer » et « les pages que Google a indexées » c'est là que l'argent se trouve. Sur les gros sites, cet écart tend à être énorme et entièrement évitable.
Les quatre états qui vous intéressent
- Indexé, pas de problème, d'accord, laissez tomber
- Exclu : noindex, intentionnel ? Confirmez-le
- Exclue : crawlée, actuellement non indexée, c'est celle-ci qui devrait vous alarmer
- Exclue : découverte, non crawlée, problème de budget de crawl, retournez à la section un
« Crawlé, actuellement non indexé » est la façon qu'a Google de dire : je suis arrivé ici, j'ai regardé autour de moi, et j'ai décidé que ce n'était pas la peine. Cela signifie généralement du contenu mince, du contenu quasi-dupliqué, ou un signal de qualité si faible que Google fait activement le choix de le sauter. Sur les pages produit, cela arrive souvent avec des descriptions auto-générées qui sont trois phrases de passe-partout. Google a vu mille versions de « Ce produit est disponible en plusieurs couleurs et livré sous 3 à 5 jours ouvrables. » Il n'en veut pas une de plus.
---
Balises Canonical à Grande Échelle
Les canonicals sont l'endroit où je vois les dégâts les plus spectaculaires s'auto-infliger sur les grands sites. Non pas parce qu'ils sont compliqués, ils ne le sont pas, mais parce qu'à 10 000+ pages, une seule erreur de template se propage instantanément sur des milliers d'URLs.
Les deux défaillances que je vois constamment :
Les canoniques auto-référentes qui ne pointent pas vraiment au bon endroit. Exemple classique : une page de catégorie paginée où page/2 a une canonique qui pointe vers elle-même au lieu de page/1 ou de la catégorie racine. Multipliez ça par 400 pages de catégories avec 8 pages de pagination chacune et vous avez 2 800+ pages avec des signaux canoniques cassés.
Les chaînes canonicals. La Page A se canonicalise vers la Page B, qui se canonicalise vers la Page C. Google suit les chaînes canonicals, mais ne les traite pas avec enthousiasme. Trois sauts, c'est déjà pousser. J'ai vu des sites avec des chaînes à cinq sauts accumulées au fil des années de migrations et de redesigns. L'onglet "Canonical" de Screaming Frog vous le montrera directement, exportez-le, filtrez les chaînes.
Effectuez un audit canonical complet sur chaque type de modèle séparément. Pages produit. Pages de catégorie. Articles de blog. Archives de tags. Pages auteur. Chaque modèle a son propre mode de défaillance, et vous ne les attraperez pas tous à partir d'un échantillon aléatoire.
---
Plans de Site XML : Plus Importants qu'On Ne Le Pense
À 10 000+ pages, un seul fichier sitemap commence à devenir un problème. La limite de Google est de 50 000 URLs ou 50 Mo par fichier sitemap, mais atteindre cette limite n'est pas le point. Le point, c'est qu'un sitemap monolithique avec 40 000 URLs est difficile à monitorer et difficile à déboguer quand les choses tournent mal.
Fragmentez-le. Utilisez un fichier d'index sitemap pointant vers des sitemaps segmentés :
- Sitemap des produits
- Sitemap des catégories
- Sitemap des blogs/contenus éditoriaux
- Sitemap des pages de marque ou de fabricant (si applicable)
Pourquoi la segmentation compte-t-elle ? Parce que quand quelque chose casse, et ça cassera, vous pouvez isoler le problème. Si Google ne récupère soudainement pas vos nouvelles pages produit, vous vérifiez la date de crawl du sitemap produits dans GSC et vous déboguez à partir de là. Un sitemap monolithique ne vous laisse nulle part où regarder.
Aussi : incluez uniquement dans votre sitemap les URLs que vous voulez vraiment indexer. Ça semble évident. Vous seriez surpris. J'ai audité des sites où le sitemap était auto-généré par un plugin et incluait des pages de tags, des archives d'auteur, des pages de pièces jointes et une demi-douzaine d'autres types d'URLs qui avaient noindex sur elles. Du bruit inutile.
Validez votre sitemap avec Google's Rich Results Test si vous gérez aussi des données structurées, et vérifiez la livraison brute du sitemap dans un navigateur pour confirmer que votre serveur retourne un 200, pas une chaîne 301 ou, mon dieu, un 404.
---
Linking interne à l'échelle : celui qu'on sous-estime
Le PageRank existe toujours. Il circule par les liens internes. Sur un gros site, l'architecture de votre stratégie de linking interne décide effectivement quelles pages ont de l'autorité et lesquelles sont des orphelins qui meurent silencieusement dans un coin.
Seahawk avait un client éditorial en 2023, environ 18 000 articles répartis sur un vertical news et lifestyle. Leurs pages de catégorie de haut de funnel généraient du trafic décent. Mais leur contenu archivé plus profond, du contenu de 2015 à 2019 qui avait toujours une vraie demande de recherche, était pratiquement invisible. Non pas parce que le contenu était mauvais. Parce que plus rien ne renvoyait vers lui. Ils avaient redessiné leur navigation de catégorie trois fois, et à chaque fois, le contenu plus ancien s'enfonçait un niveau de plus.
La solution n'était pas glamour : nous avons construit une stratégie de linking interne programmatique en utilisant un plugin WordPress personnalisé qui identifiait les articles avec un chevauchement de mots-clés pertinent et insérait des liens contextuels. La profondeur de clic sur leur contenu archivé a baissé d'une moyenne de 7,2 clics depuis la page d'accueil à 3,1. Les impressions organiques sur ces pages ont augmenté de 28% au cours du trimestre suivant.
Voici une liste de contrôle rapide pour le linking interne sur les gros sites :
- Aucune page que vous voulez indexer ne doit être à plus de 3 clics de la page d'accueil
- Les pages orphelines (zéro lien interne qui pointe vers elles) doivent être traitées comme une urgence, pas comme un élément du backlog
- La navigation par fil d'Ariane compte comme un lien interne, assurez-vous qu'elle est implémentée correctement et utilise du vrai texte d'ancre, pas juste « Catégorie > Sous-catégorie » avec des étiquettes génériques
- Recherchez les pages avec un seul lien interne pointant vers elles, c'est à peine mieux qu'orphelin
---
Données structurées et schéma à grande échelle
Si vous avez 10 000+ pages produits et qu'aucune n'a de schéma Product avec les propriétés Offer, Review et AggregateRating, vous laissez de l'espace SERP sur la table.
Mais les données structurées à grande échelle introduisent aussi leurs propres exigences d'audit. Une erreur de schéma dans un modèle signifie des milliers d'instances de balisage invalides. Je vérifie les données structurées avec deux outils en combinaison : le test de résultats enrichis de Google pour l'échantillonnage d'URL individuelle, et une extraction de schéma au niveau du crawl dans Screaming Frog (Configuration → Custom Extraction → XPath pour les blocs JSON-LD) pour obtenir une vue globale sur tous les types de page.
Ce qu'il faut rechercher :
- Propriétés requises manquantes (notamment price et priceCurrency sur les pages Produit, ce sont des omissions courantes)
- Données structurées incohérentes (le schéma indique un nom de produit, la <title> en indique un autre)
- Types de schéma dépréciés, DataFeedElement et certains anciens motifs de microdata itemscope méritent un audit de dépréciation
- Examinez les schémas qui violent les directives de Google pour les extraits d'avis, les avis internes marqués comme tiers, ou les scores agrégés issus d'échantillons minuscules
---
Vitesse de page à grande échelle : n'auditez pas ce que vous ne pouvez pas corriger
Les Core Web Vitals, c'est important. Mais voilà ce qu'on ne dit pas assez : auditer les CWV sur 10 000 pages et essayer de corriger chaque URL individuellement, c'est une perte de temps. Vous auditez par template, puis vous corrigez par template.
Exécutez un échantillon de 20 à 30 URLs par type de modèle via PageSpeed Insights ou WebPageTest. Si vos pages produit affichent un LCP moyen de 4,8 s, c'est un problème au niveau du modèle. La solution réside dans votre pipeline de distribution d'images, votre CSS critique ou votre temps de réponse serveur, pas dans des retouches page par page.
Sur les grands sites WordPress spécifiquement (ce avec quoi on travaille surtout chez Seahawk), les coupables habituels à grande échelle sont :
- Les images de produit WooCommerce non optimisées livrées sans conversion WebP
- Trop de requêtes HTTP provenant d'enqueues de plugin mal scopées sur des pages qui n'ont pas besoin de ces scripts
- Des niveaux d'hébergement qui n'ont pas évolu avec la croissance du site, un forfait qui fonctionnait à 2 000 produits est souvent débordé à 12 000
Mettez d'abord votre hébergement en ordre. Tout le reste, c'est de la décoration.
---
Audit des redirections : Le problème de la dette de migration
Les grands sites accumulent les chaînes de redirection comme les vieilles maisons accumulent les câblages pourris. Chaque redesign, chaque migration de domaine, chaque restructuration d'URL ajoute une couche supplémentaire. Après quatre ou cinq ans, il n'est pas rare de trouver des chaînes de redirection quatre ou cinq bonds de profondeur.
Chaque saut coûte du temps. Chaque saut dilue le signal PageRank qui est transmis. Et certaines très anciennes redirections 302 qui étaient censées être temporaires sont toujours là en train de causer des dégâts très permanents.
Mon processus :
- Crawler avec Screaming Frog, exporter toutes les réponses 3xx
- Filtrer les chaînes (A → B → C, ou plus longues)
- Mettre à jour tous les liens source pour qu'ils pointent directement vers la destination finale
- Confirmer que la destination finale retourne un 200, pas une autre redirection
- Signaler les 302 qui devraient être des 301 et les faire changer au niveau du serveur
Aussi vérifier : certaines de vos URL du plan du site XML retournent-elles des redirections ? Parce que c'est une erreur courante. Un sitemap ne devrait contenir que des URL qui retournent 200. Si votre sitemap est rempli de 301, vous faites le travail de Google à sa place et vous le faites mal.
---
FAQ
Combien de temps prend un audit technique SEO pour un site de 10 000+ pages ?
Honnêtement, ça dépend de la qualité de l'instrumentation du site. S'il y a une GSC configurée correctement, des logs serveur accessibles, et que Screaming Frog peut crawler sans se limiter lui-même, un audit complet me prend environ 3-5 jours ouvrables rien que pour la phase collecte et analyse. Le reporting, c'est encore 1-2 jours. Quiconque vous dit qu'il peut faire un audit significatif sur un gros site en une après-midi fait du sampling, pas un audit.
Dois-je auditer chaque page unique ou puis-je travailler à partir d'échantillons ?
Travaillez à partir de modèles, pas de pages individuelles. Un site avec 12 000 pages produit ne compte que 4 à 6 modèles de page vraiment significatifs. Auditez chaque type de modèle à fond avec un échantillon représentatif (minimum 20 à 30 URLs), et vos conclusions s'appliqueront à tout le modèle. L'exception concerne l'identification des pages orphelines et la découverte des chaînes de redirections, qui nécessitent une couverture d'exploration complète, pas un échantillonnage.
Quel est le correctif à plus fort impact sur la plupart des gros sites ?
Budget d'exploration, neuf fois sur dix. Spécifiquement, bloquer ou canonicaliser les URLs de navigation à facettes qui n'ont pas de demande de recherche et pas de contenu unique. J'ai vu ce seul correctif bouger l'aiguille plus que tout autre changement sur les sites e-commerce avec de grands catalogues. C'est du travail peu glamour, des éditions robots.txt, des balises canoniques, des configurations de paramètres, mais cela produit souvent des résultats plus rapides que n'importe quel effort de création de contenu ou de construction de liens.
Dois-je utiliser Screaming Frog ou Sitebulb pour les gros sites ?
Les deux sont bons. J'utilise Screaming Frog pour la majorité de mon travail de crawl parce que je connais ses formats d'export sur le bout des doigts après des années d'utilisation, et ses options d'extraction personnalisée sont excellentes. Sitebulb a une couche de visualisation vraiment meilleure et son rapport d'audit est plus lisible pour les clients. Pour les sites de plus de 50 000 pages, vous pourriez aussi regarder DeepCrawl (maintenant Lumar) pour un crawling cloud qui ne dépend pas de la RAM de votre machine locale.
Quel est le problème le plus souvent manqué dans les audits de gros sites ?
La profondeur des liens internes. Tout le monde vérifie les liens cassés et les canoniques. Très peu de gens identifient systématiquement les pages qui sont à six ou sept clics de la page d'accueil et demandent pourquoi on s'attend à ce qu'elles se classent pour quelque chose de compétitif. La profondeur de clic est un indicateur de priorité de crawl et de distribution d'autorité. Auditez-la à chaque fois.
---
Le SEO de site large n'est pas une discipline différente, c'est les mêmes principes à une échelle où les conséquences de la négligence s'accumulent rapidement. La liste de vérification ci-dessus ne restera pas statique. Chaque site a son propre chaos particulier. Mais si vous travaillez via le budget d'exploration, l'indexation, les canoniques, les sitemaps, les liens internes, les données structurées, la vitesse de page et les redirections dans cet ordre approximatif, vous trouverez 80 % de ce qui est cassé avant d'avoir examiné un seul mot-clé.
Commencez par l'infrastructure. Les classements suivront.