Un client m'a appelé en 2022 -- un opérateur e-commerce basé au Royaume-Uni avec environ 14 000 pages produits -- furieux d'avoir perdu 34% de son 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 on a trouvé le problème en 90 minutes : leur pagination générait automatiquement des milliers d'URLs quasi-dupliquées, Google les avait crawlées à la place des vraies pages produits, et leur budget de crawl é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.Auditing a 10,000-page site is not a bigger small-site audit: the failure modes are crawl budget, templates, and indexation at scale, and the checklist changes accordingly.
C'est ça, le SEO pour les gros sites. Les problèmes ne sont pas plus difficiles à comprendre -- ils sont juste catastrophiquement plus graves dans leurs conséquences. Une balise canonical mal configurée sur un site de 20 pages, c'est agaçant. 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 franchit les 10 000 pages. Sans ordre d'importance particulier -- parce que chaque gros site a sa propre hiérarchie de catastrophes.Seahawk Media when a site crosses the 10,000-page mark. In no particular order of importance -- because every large site has its own hierarchy of disasters.
---
Commencez par le Budget de Crawl -- 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.
Budget de crawl, pour ceux qui en ont besoin de la version simple : c'est le nombre d'URLs que Googlebot crawlera sur votre site dans un laps de temps donné. La documentation propre de Google sur le budget de crawl mérite vraiment d'être lue ici -- ils sont très spécifiques sur ce qui le gaspille.Google's own documentation on crawl budget is genuinely worth reading here -- they're quite specific about what wastes it.
Qu'est-ce qui brûle votre budget ?
Récupérez d'abord vos logs serveur. Pas les données GSC -- les logs serveur réels. J'utilise GoAccess pour une analyse rapide sur les gros fichiers de logs parce que ça gère le volume sans broncher. Ce que vous cherchez :GoAccess for quick analysis on large log files because it handles volume without crying. What you're looking for:
- Les URLs de navigation facettée (par ex., /shoes?colour=red&size=10&sort=price)
/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
/page/1and/) both being crawled - Les pages de résultats de recherche interne qui ne sont pas bloquées
N'importe quel site de plus de 10 000 pages avec une navigation à facettes active gaspille presque certainement son budget de crawl. Presque certainement. La solution n'est pas glamour -- c'est un disallow dans robots.txt sur les patterns de paramètres, ou idéalement, une bonne gestion des paramètres d'URL via GSC combinée à des balises canonicals sur les pages à facettes elles-mêmes.proper URL parameter handling via GSC combined with canonical tags on the faceted pages themselves.
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.noindex, follow and disallowed the heavy combinatorial patterns in robots.txt. Within six weeks, average crawl frequency on real product pages dropped to every 3-4 days.
---
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. in Google gives you a rough figure. Don't rely on it for precision, but it's a quick sanity check. Cross-reference with GSC's Index Coverage report.
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ée, pas de problèmes -- OK, laissez comme ça -- fine, leave it
- Exclus : noindex -- intentionnel ? Confirmez-le -- intentional? Confirm it is
- Exclus : crawlé, actuellement non indexé -- c'est celui-là qui devrait vous alarmer -- this is the one that should alarm you
- Exclus : découvert, non crawlé -- problème de budget de crawl, revenez à la section un -- crawl budget problem, come back up to section one
« 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.I got here, I looked around, and I decided not to bother.That usually means thin content, near-duplicate content, or a quality signal so weak Google is making an active choice to skip it. On product pages, this often happens with auto-generated descriptions that are three sentences of boilerplate. Google has seen a thousand versions of "This product is available in multiple colours and ships within 3-5 working days." It doesn't want another one.
---
Balises Canonical à Grande Échelle
Les canonicals sont l'endroit où je vois les dégâts les plus spectaculaires qu'on s'inflige soi-même sur les gros sites. 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'URL.
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.Classic example: a paginated category page where page/2 has a canonical pointing to itself instead of page/1 or the root category. Multiply that by 400 category pages with 8 pages of pagination each and you've got 2,800+ pages with broken canonical signals.
Les chaînes de canonicals. La page A se canonicalise vers la page B, qui se canonicalise vers la page C. Google suit les chaînes de canonicals, mais il n'en est pas enthousiaste. Trois sauts c'est déjà limite. J'ai vu des sites avec des chaînes à cinq sauts construites au fil des années de migrations et de redesigns. L'onglet « Canonical » de Screaming Frog te le montrera directement -- exporte-le, filtre les chaînes.Page A canonicalises to Page B, which canonicalises to Page C. Google follows canonical chains, but it's not enthusiastic about them. Three hops is already pushing it. I've seen sites with five-hop chains built up over years of migrations and redesigns. Screaming Frog's "Canonical" tab will show you this directly -- export it, filter for chains.
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 URL ou 50 Mo par fichier sitemap -- mais atteindre cette limite n'est pas le point. Le point est qu'un sitemap monolithique avec 40 000 URL est difficile à surveiller 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 a-t-elle de l'importance ? Parce que quand quelque chose casse -- et ça cassera -- vous pouvez isoler le problème. Si Google cesse soudainement de récupérer 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 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.only include URLs you actually want indexed in your sitemap.This sounds obvious. You'd be surprised. I've audited sites where the sitemap was auto-generated by a plugin and included tag pages, author archives, attachment pages, and half-a-dozen other URL types that had noindex on them. Pointless noise.
Validez votre sitemap avec le Rich Results Test de Google si vous devez aussi gérer 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 de 301 ou, mon dieu, un 404.Google's Rich Results Test if you're also dealing with structured data -- and check raw sitemap delivery in a browser to confirm your server is returning a 200, not a 301 chain or, god forbid, a 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 éditeur en 2023 -- environ 18 000 articles sur un vertical actualités et lifestyle. Leurs pages de catégorie en haut de l'entonnoir recevaient un trafic décent. Mais leur contenu d'archive plus profond -- du contenu de 2015 à 2019 qui avait toujours une demande de recherche réelle -- était presque invisible. Pas parce que le contenu était mauvais. Parce que rien ne pointait plus vers lui. Ils avaient redessiné leur navigation de catégorie trois fois, et à chaque fois, le contenu plus ancien était enfoui un niveau plus profond.
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.WordPress plugin that identified articles with relevant keyword overlap and inserted contextual links. Click depth on their archival content dropped from an average of 7.2 clicks from the homepage to 3.1. Organic impressions on those pages rose 28% over the following quarter.
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 correctement implémentée et qu'elle utilise du vrai texte d'ancre, pas juste « Catégorie > Sous-catégorie » avec des libellés génériques
- Vérifiez les pages vers lesquelles pointe un seul lien interne -- c'est à peine mieux que des pages orphelines
---
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.Product schema with Offer,Review, and AggregateRating properties, you're leaving SERP real estate on the 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 (en particulier price et priceCurrency sur les pages Product -- ce sont des omissions courantes)
priceandpriceCurrencyon Product pages -- these are common omissions) - Données structurées incohérentes (le schéma indique un nom de produit, la <title> en indique un autre)
<title>says another) - Types de schema dépréciés -- DataFeedElement et certains anciens modèles microdata itemscope méritent un audit
DataFeedElementand some olderitemscopemicrodata patterns are worth auditing out - Vérifiez le schema qui viole les directives de Google pour les snippets d'avis -- des avis de première partie marqués comme des avis tiers, ou des scores agrégés à partir d'échantillons minusculesGoogle's review snippet guidelines -- first-party reviews marked up as third-party, or aggregated scores from tiny sample sizes
---
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. matter. But here's the thing that doesn't get said enough: auditing CWV across 10,000 pages and trying to fix every individual URL is a fool's errand. You audit by template, then fix by template.
Exécutez un échantillon -- 20-30 URL par type de modèle -- via PageSpeed Insights ou WebPageTest. Si vos pages produit ont un LCP moyen de 4,8s, c'est un problème au niveau du modèle. La solution est dans votre pipeline de livraison d'images, votre CSS critique, ou votre temps de réponse serveur -- pas en touchant à des pages individuelles.WebPageTest. If your product pages have an average LCP of 4.8s, that's a template-level problem. The fix is in your image delivery pipeline, your critical CSS, or your server response time -- not in touching individual pages.
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 plan qui convenait à 2 000 produits s'effondre souvent à 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 a peut-être 4-6 modèles de page vraiment différents. Auditez chaque type de modèle en profondeur avec un échantillon représentatif (minimum 20-30 URL), et vos conclusions s'appliqueront sur l'ensemble du modèle. L'exception, c'est l'identification des pages orphelines et la découverte des chaînes de redirections -- celles-ci ont besoin d'une couverture complète du crawl, pas du sampling.
Quel est le correctif à plus fort impact sur la plupart des gros sites ?
Le budget de crawl, neuf fois sur dix. Spécifiquement, bloquer ou canonicaliser les URL de navigation facettisée qui n'ont pas de demande de recherche et pas de contenu unique. J'ai vu ce simple correctif faire plus effet que n'importe quel autre changement sur les sites e-commerce avec de gros catalogues. C'est du travail ingrat -- éditions robots.txt, tags canonical, configurations de paramètres -- mais ça produit souvent des résultats plus rapides que n'importe quel effort de création de contenu ou de link-building.
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.DeepCrawl (now Lumar)for cloud-based crawling that doesn't depend on your local machine's RAM.
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 pour les gros sites n'est pas une discipline différente -- ce sont les mêmes principes à une échelle où les conséquences de la négligence s'accumulent rapidement. La checklist ci-dessus ne restera pas statique. Chaque site a son propre chaos particulier. Mais si vous travaillez sur le budget de crawl, l'indexation, les canonicals, les sitemaps, les liens internes, les données structurées, la vitesse des pages et les redirections dans cet ordre approximatif -- vous trouverez 80% de ce qui est cassé avant même d'avoir regardé un seul mot-clé.
Commencez par l'infrastructure. Les classements suivront.