Un site e-commerce de 20 000 produits avec une profondeur de crawl moyenne de 9 clics : voilà ce qu'on découvre régulièrement en auditant des catalogues qui ont grandi sans stratégie de maillage interne. Le résultat est prévisible — 40 à 60 % des fiches produit ne reçoivent aucune visite organique, non pas parce que le contenu est mauvais, mais parce que Googlebot ne les atteint tout simplement pas efficacement.
Le maillage interne d'un e-commerce ne se résume pas à "mettre des liens dans le footer". C'est un problème d'architecture de graphe, de distribution de PageRank, et d'ingénierie logicielle quand le catalogue dépasse quelques milliers de références.
Le vrai problème : la profondeur de crawl explose avec le catalogue
Sur un site de 500 pages, la structure naturelle (header → catégories → sous-catégories → produits) maintient une profondeur raisonnable de 3-4 clics. Sur un catalogue de 15 000 à 50 000 pages, cette même structure arborescente crée mécaniquement des profondeurs de 7 à 12 clics.
Pourquoi c'est critique
Chaque niveau de profondeur supplémentaire réduit la fréquence de crawl et la quantité de PageRank transmise. Google l'a documenté dans ses guidelines : les pages profondes sont crawlées moins souvent et peuvent mettre des semaines à être réindexées après une mise à jour. Pour un e-commerce qui modifie ses prix quotidiennement ou lance des promotions flash, c'est un problème business direct.
Prenons un scénario concret. Un retailer mode avec :
- 12 catégories principales
- 85 sous-catégories
- 18 000 fiches produit
- Pagination classique de 48 produits par page
La structure arborescente donne : Homepage → Catégorie → Sous-catégorie → Page de listing (pagination) → Fiche produit. Une fiche produit sur la page 8 d'une sous-catégorie est à 5 clics minimum. Ajoutez la navigation à facettes qui génère des URL supplémentaires, et vous atteignez facilement des profondeurs abyssales.
Mesurer la profondeur réelle
Screaming Frog calcule la crawl depth nativement. Mais la métrique qui compte vraiment, c'est la profondeur pondérée par le PageRank — une page à 3 clics depuis la homepage mais linkée uniquement depuis un footer n'a pas le même poids qu'une page à 3 clics linkée depuis le contenu principal de pages à fort trafic.
Exportez le rapport "Crawl Depth" de Screaming Frog et croisez-le avec les données d'impressions de la Search Console :
import pandas as pd
# Export Screaming Frog + Search Console
sf = pd.read_csv('screaming_frog_internal.csv')
gsc = pd.read_csv('search_console_pages.csv')
# Merge sur l'URL
merged = sf.merge(gsc, left_on='Address', right_on='page', how='left')
# Corrélation profondeur / impressions
depth_perf = merged.groupby('Crawl Depth').agg({
'impressions': 'mean',
'clicks': 'mean',
'Address': 'count'
}).rename(columns={'Address': 'page_count'})
print(depth_perf)
# Identifier les pages profondes à fort potentiel (impressions > 0 mais depth > 5)
orphan_potential = merged[
(merged['Crawl Depth'] > 5) &
(merged['impressions'] > 100)
].sort_values('impressions', ascending=False)
print(f"\n{len(orphan_potential)} pages profondes avec potentiel SEO inexploité")
print(orphan_potential[['Address', 'Crawl Depth', 'impressions', 'clicks']].head(20))Ce script identifie les pages qui reçoivent déjà des impressions (Google les connaît) mais qui sont enfouies dans l'architecture. Ce sont vos quick wins : ramener ces pages à 2-3 clics de profondeur peut suffire à doubler leur trafic organique.
Architecture hub-and-spoke adaptée aux grands catalogues
L'architecture hub-and-spoke classique — une page catégorie (hub) qui lie vers toutes ses pages produit (spokes) — atteint ses limites quand une catégorie contient 2 000 produits. Vous ne pouvez pas lier 2 000 URLs depuis une seule page sans détruire l'expérience utilisateur et diluer massivement le PageRank.
Le pattern des "sous-hubs" thématiques
La solution consiste à créer des niveaux intermédiaires qui ne sont pas de simples paginations, mais de véritables pages à valeur ajoutée. Plutôt qu'une catégorie "Chaussures femme" paginée sur 40 pages, structurez ainsi :
/chaussures-femme/ (hub principal - 1 page)
├── /chaussures-femme/sneakers/ (sous-hub - liens vers 150 produits)
├── /chaussures-femme/escarpins/ (sous-hub - liens vers 80 produits)
├── /chaussures-femme/bottes/ (sous-hub - liens vers 120 produits)
├── /chaussures-femme/sandales/ (sous-hub - liens vers 90 produits)
├── /chaussures-femme/mocassins/ (sous-hub - liens vers 60 produits)
└── /chaussures-femme/meilleures-ventes/ (sous-hub éditorial)
Chaque sous-hub est une page catégorie optimisée avec du contenu unique, un maillage dense vers ses produits, et des liens croisés vers les autres sous-hubs pertinents.
Le cross-linking intelligent entre sous-hubs
Le maillage entre sous-hubs est ce qui différencie une architecture plate d'un vrai graphe de liens efficace. Chaque page "sneakers" doit lier vers "sandales" et "mocassins", pas seulement remonter vers le hub parent.
Implémentez ce cross-linking via un composant de navigation contextuelle :
<!-- Composant "Explorez aussi" sur /chaussures-femme/sneakers/ -->
<nav class="related-categories" aria-label="Catégories associées">
<h2>Explorez aussi</h2>
<ul>
<li>
<a href="/chaussures-femme/mocassins/">
<img src="/img/cat/mocassins-thumb.webp" alt="" width="120" height="80" loading="lazy">
<span>Mocassins femme</span>
<span class="count">60 modèles</span>
</a>
</li>
<li>
<a href="/chaussures-femme/sandales/">
<img src="/img/cat/sandales-thumb.webp" alt="" width="120" height="80" loading="lazy">
<span>Sandales femme</span>
<span class="count">90 modèles</span>
</a>
</li>
<li>
<a href="/accessoires-femme/chaussettes/">
<img src="/img/cat/chaussettes-thumb.webp" alt="" width="120" height="80" loading="lazy">
<span>Chaussettes</span>
<span class="count">45 modèles</span>
</a>
</li>
</ul>
</nav>Le troisième lien est intentionnel : il crée un pont vers une catégorie d'un autre silo ("accessoires"). Ces ponts inter-silos empêchent la formation d'îlots isolés dans le graphe de liens et distribuent le PageRank de manière plus homogène.
Un point critique : ce composant doit être rendu côté serveur. Si vous êtes sur un framework JavaScript qui génère ces liens en client-side rendering, vérifiez que Googlebot peut les voir. Un composant React de "produits similaires" chargé via une API après le render initial est invisible pour le crawl dans de nombreux cas.
Automatiser le maillage produit-à-produit à grande échelle
Le maillage entre fiches produit est le levier le plus sous-exploité sur les grands catalogues. Chaque fiche produit devrait lier vers 4 à 8 autres produits pertinents, créant un réseau dense qui réduit la profondeur effective de l'ensemble du catalogue.
Le problème des recommandations client-side
La majorité des moteurs de recommandation (Algolia Recommend, Dynamic Yield, Nosto) injectent les produits recommandés via JavaScript client-side. Ces liens sont fonctionnellement invisibles pour Googlebot dans la plupart des configurations. Vous avez un beau bloc "Vous aimerez aussi" pour vos utilisateurs, mais zéro valeur SEO.
Si vous utilisez un framework SSR comme Next.js ou Nuxt, la solution est d'appeler l'API de recommandation côté serveur :
// pages/product/[slug].tsx - Next.js App Router
import { getProduct, getRelatedProducts } from '@/lib/catalog';
// Types pour la recommandation produit
interface RelatedProduct {
slug: string;
name: string;
price: number;
thumbnail: string;
category: string;
averageRating: number;
}
interface RecommendationContext {
productId: string;
categoryId: string;
priceRange: [number, number];
attributes: Record<string, string>;
}
// Appel serveur - ces liens seront dans le HTML initial
async function getSSRRecommendations(
context: RecommendationContext
): Promise<RelatedProduct[]> {
// Stratégie hybride : algorithme maison + données de vente
const [algoRecs, salesRecs, categoryRecs] = await Promise.all([
// 1. Produits similaires par attributs (taille, couleur, matière)
fetch(`${process.env.INTERNAL_API}/recommendations/similar`, {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({
productId: context.productId,
attributes: context.attributes,
limit: 4
}),
next: { revalidate: 3600 } // Cache 1h côté serveur
}).then(r => r.json()),
// 2. "Souvent achetés ensemble" (données transactionnelles)
fetch(`${process.env.INTERNAL_API}/recommendations/copurchase`, {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({
productId: context.productId,
limit: 4
}),
next: { revalidate: 86400 } // Cache 24h - données plus stables
}).then(r => r.json()),
// 3. Meilleures ventes de la même catégorie (fallback)
fetch(`${process.env.INTERNAL_API}/recommendations/category-best`, {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({
categoryId: context.categoryId,
excludeProductId: context.productId,
limit: 4
}),
next: { revalidate: 3600 }
}).then(r => r.json())
]);
// Déduplication et scoring
const seen = new Set<string>();
const merged: RelatedProduct[] = [];
// Priorité : co-achat > similarité > catégorie
for (const product of [...salesRecs, ...algoRecs, ...categoryRecs]) {
if (!seen.has(product.slug) && merged.length < 8) {
seen.add(product.slug);
merged.push(product);
}
}
return merged;
}
export default async function ProductPage({
params
}: {
params: { slug: string }
}) {
const product = await getProduct(params.slug);
const related = await getSSRRecommendations({
productId: product.id,
categoryId: product.categoryId,
priceRange: [product.price * 0.7, product.price * 1.3],
attributes: product.attributes
});
return (
<main>
{/* ... contenu produit ... */}
<section aria-labelledby="related-heading">
<h2 id="related-heading">Produits complémentaires</h2>
<div className="product-grid">
{related.map((item) => (
<a
key={item.slug}
href={`/produit/${item.slug}`}
className="product-card"
>
<img
src={item.thumbnail}
alt={item.name}
width={280}
height={280}
loading="lazy"
/>
<h3>{item.name}</h3>
<span className="price">{item.price.toFixed(2)} €</span>
</a>
))}
</div>
</section>
</main>
);
}Trois détails importants dans ce code :
Le cache différencié. Les recommandations par co-achat changent peu (24h de cache). Les recommandations par attributs sont plus volatiles (1h). Ce n'est pas du sur-engineering : sur un catalogue de 18 000 produits, générer les recommandations SSR pour chaque page à chaque requête ferait exploser le TTFB.
Les liens sont des balises <a> standard avec des href absolus. Pas de onClick avec un router.push(). Pas de composant <Link> qui pourrait être conditionnel. Ce sont des liens HTML natifs que n'importe quel crawler peut suivre.
La diversité des sources. Ne linkez pas uniquement vers des produits de la même sous-catégorie. Les liens cross-catégorie ("Souvent achetés ensemble" : une paire de chaussures + un produit d'entretien) créent des chemins de crawl transversaux qui aplatissent l'architecture globale.
Le cas des produits en rupture
Un produit en rupture de stock qui disparaît du maillage interne, c'est un lien en moins pour tous les produits qu'il référençait. Sur un catalogue avec 15 % de rupture permanente, vous perdez potentiellement des centaines de liens internes.
La stratégie optimale est documentée dans notre guide sur les pages produit en rupture : maintenez la page avec un maillage renforcé vers des alternatives, plutôt que de la supprimer ou de la rediriger. Google a d'ailleurs resserré ses règles sur le traitement des pages de produits indisponibles, incitant les e-commerçants à gérer ces pages proprement plutôt qu'à les laisser dériver en soft 404.
Le PageRank sculpting en 2026 : ce qui fonctionne encore
Le concept de "PageRank sculpting" via nofollow est mort depuis que Google a changé le modèle de distribution en 2009. Si une page a 10 liens sortants dont 5 en nofollow, les 5 liens followed ne reçoivent pas chacun 1/5 du PageRank — ils reçoivent chacun 1/10. Le PageRank alloué aux liens nofollow est simplement perdu.
Ce qui fonctionne : le sculpting par la structure
Le vrai sculpting passe par la structure du template. Les liens dans le contenu principal (zone <main>) ont plus de poids que ceux dans le header, le footer ou les sidebars. Google utilise une notion de "reasonable surfer model" qui pondère les liens selon leur probabilité de clic.
Concrètement, pour un template de page catégorie e-commerce :
<body>
<header>
<!-- Navigation globale : liens présents sur toutes les pages.
PageRank dilué car répété sur 18 000 pages.
Gardez ≤ 30 liens ici. -->
<nav aria-label="Navigation principale">
<ul>
<li><a href="/femme/">Femme</a></li>
<li><a href="/homme/">Homme</a></li>
<li><a href="/enfant/">Enfant</a></li>
<!-- Sous-menus chargés au hover/click, PAS dans le HTML initial.
Technique : <template> ou injection JS au focus. -->
</ul>
</nav>
</header>
<main>
<!-- ZONE HAUTE PRIORITÉ : liens ici = maximum de poids -->
<!-- Breadcrumb : liens ascendants (catégorie parente, homepage) -->
<nav aria-label="Fil d'Ariane">
<ol itemscope itemtype="https://schema.org/BreadcrumbList">
<li itemprop="itemListElement" itemscope itemtype="https://schema.org/ListItem">
<a itemprop="item" href="/"><span itemprop="name">Accueil</span></a>
<meta itemprop="position" content="1">
</li>
<li itemprop="itemListElement" itemscope itemtype="https://schema.org/ListItem">
<a itemprop="item" href="/femme/"><span itemprop="name">Femme</span></a>
<meta itemprop="position" content="2">
</li>
<li itemprop="itemListElement" itemscope itemtype="https://schema.org/ListItem">
<span itemprop="name">Chaussures femme</span>
<meta itemprop="position" content="3">
</li>
</ol>
</nav>
<!-- Sous-catégories : les liens descendants les plus importants -->
<section aria-label="Sous-catégories">
<a href="/chaussures-femme/sneakers/">Sneakers femme (152)</a>
<a href="/chaussures-femme/escarpins/">Escarpins (84)</a>
<a href="/chaussures-femme/bottes/">Bottes et bottines (123)</a>
<!-- Chaque lien = un sous-hub qui distribue le PR aux produits -->
</section>
<!-- Grille produit : liens vers les fiches produit -->
<section aria-label="Produits">
<!-- 48 produits par page = 48 liens. Acceptable. -->
<article>
<a href="/produit/nike-air-max-90-femme-blanc/">
<img src="..." alt="Nike Air Max 90 Femme Blanc" width="300" height="300">
<h3>Nike Air Max 90 Femme Blanc</h3>
<span class="price">149,99 €</span>
</a>
</article>
<!-- ... -->
</section>
<!-- Contenu éditorial : liens contextuels à forte valeur -->
<section aria-label="Guide d'achat">
<h2>Comment choisir vos chaussures femme</h2>
<p>Pour le running urbain, nos <a href="/chaussures-femme/sneakers/">sneakers
à semelle amortissante</a> offrent le meilleur rapport confort/style.
Si vous cherchez une option pour le bureau, explorez notre sélection
d'<a href="/chaussures-femme/escarpins/">escarpins confort</a>
avec talons de 5 cm maximum.</p>
</section>
<!-- Cross-linking inter-silos -->
<section aria-label="Catégories associées">
<h2>Complétez votre look</h2>
<a href="/sacs-femme/">Sacs femme</a>
<a href="/accessoires-femme/ceintures/">Ceintures</a>
<a href="/vetements-femme/jeans/">Jeans femme</a>
</section>
</main>
<footer>
<!-- Liens légaux, CGV, plan du site.
NE PAS mettre 200 liens vers toutes les catégories ici. -->
</footer>
</body>Le mega-menu : ami ou ennemi ?
Un mega-menu avec 200 liens sur chaque page du site dilue massivement le PageRank interne. Sur un site de 18 000 pages, si chaque page distribue du PageRank vers 200 destinations via le header, vos liens in-content (les plus importants) ne reçoivent qu'une fraction du poids.
La solution n'est pas de supprimer le mega-menu — il a une vraie valeur UX. C'est de le charger conditionnellement :
<!-- Le mega-menu n'est PAS dans le HTML initial -->
<nav aria-label="Navigation principale">
<button
aria-expanded="false"
aria-controls="mega-menu"
data-menu-trigger
>
Catégories
</button>
<!-- Le contenu du mega-menu est dans un <template>
ou chargé via JS au hover/focus -->
<template id="mega-menu-template">
<div id="mega-menu" role="menu">
<!-- 200 liens ici, mais absents du DOM initial -->
</div>
</template>
</nav>
<script>
// Injection au hover ou focus - pas exécuté par Googlebot
const trigger = document.querySelector('[data-menu-trigger]');
const template = document.getElementById('mega-menu-template');
let menuInjected = false;
function injectMenu() {
if (menuInjected) return;
const clone = template.content.cloneNode(true);
trigger.parentElement.appendChild(clone);
menuInjected = true;
trigger.setAttribute('aria-expanded', 'true');
}
trigger.addEventListener('mouseenter', injectMenu);
trigger.addEventListener('focus', injectMenu);
</script>Cette technique exploite le fait que Googlebot n'exécute pas les interactions utilisateur (hover, click, scroll). Les liens du mega-menu restent accessibles aux humains mais ne diluent pas le budget de liens pour le crawl. Les seuls liens que Googlebot voit dans le header sont les 5-10 liens de navigation principale.
Trade-off : vous perdez la capacité du mega-menu à distribuer du PageRank vers vos sous-catégories via le header. C'est un choix délibéré — vous préférez que ce PageRank soit distribué par les liens in-content, plus ciblés et plus pertinents contextuellement. Si vos sous-catégories manquent de liens internes par ailleurs, cette technique peut être contre-productive.
L'analyse de logs pour valider l'architecture de liens
Les outils de crawl comme Screaming Frog montrent la structure telle que vous l'avez conçue. L'analyse de logs montre la structure telle que Googlebot la perçoit réellement. Les deux peuvent diverger significativement.
Scénario concret : le retailer mode post-migration
Un retailer mode (18 000 fiches produit, 85 catégories) migre d'une architecture plate vers le modèle hub-and-spoke décrit ci-dessus. Avant la migration :
- Profondeur moyenne de crawl : 7,2 clics
- Pages crawlées par jour par Googlebot : ~3 200
- Pages indexées dans la Search Console : 14 200 / 18 000 (79 %)
- Pages recevant au moins 1 clic organique / mois : 6 800 (38 %)
Après refonte de l'architecture de liens internes (sans toucher au contenu ni aux URLs) :
- Profondeur moyenne réduite à 3,8 clics
- Pages crawlées par jour : ~5 800 (+81 %)
- Pages indexées à 3 mois : 17 100 / 18 000 (95 %)
- Pages recevant au moins 1 clic / mois à 6 mois : 11 200 (62 %)
Le gain de +63 % de pages actives en organique provient uniquement du maillage interne. Aucune création de contenu, aucune acquisition de backlinks.
Pour traquer ce type d'évolution, croisez trois sources de données :
- Logs serveur : fréquence de crawl par section du site. Un awk basique suffit :
# Extraire les hits Googlebot par répertoire de premier niveau
# Format de log : IP - - [date] "METHOD /path HTTP/x.x" status size "referer" "UA"
zcat access.log.*.gz | \
grep -i "googlebot" | \
awk '{print $7}' | \
sed 's/\?.*//g' | \
awk -F'/' '{
if (NF >= 3) print "/" $2 "/" $3 "/";
else if (NF >= 2) print "/" $2 "/";
else print "/";
}' | \
sort | uniq -c | sort -rn | head -50-
Search Console > Paramètres > Statistiques d'exploration : le rapport natif montre le nombre de requêtes de crawl par jour et le temps de réponse moyen. Si le temps de réponse augmente après l'ajout de recommandations SSR, votre stratégie de cache serveur doit être revue.
-
Screaming Frog en mode delta : crawlez le site avant et après la refonte, exportez les deux datasets, et comparez les distributions de crawl depth. La fonctionnalité "Crawl Comparison" de Screaming Frog automatise cette comparaison.
Gérer la cannibalisation induite par le maillage
Un effet secondaire fréquent d'un maillage interne agressif : la cannibalisation de mots-clés. Quand une page catégorie "Sneakers femme Nike" et une fiche produit "Nike Air Max 90 Femme" ciblent des requêtes proches et se lient mutuellement avec des ancres similaires, Google peut hésiter sur la page à positionner.
Principes de différenciation par les ancres
L'ancre de lien est un signal fort pour Google sur le sujet de la page cible. Utilisez des ancres qui renforcent le rôle de chaque page dans l'architecture :
- Liens vers les pages catégories : ancres génériques ("sneakers femme", "collection sneakers", "tous les sneakers")
- Liens vers les fiches produit : ancres spécifiques incluant la marque et le modèle ("Nike Air Max 90 blanc", "voir la Air Max 90")
- Liens vers les guides/contenus éditoriaux : ancres informationnelles ("comment choisir ses sneakers", "guide taille Nike")
Évitez absolument les ancres génériques type "cliquez ici", "en savoir plus", "voir le produit". Elles gaspillent un signal contextuel précieux.
L'audit d'ancres internes à grande échelle
Sur un catalogue de 18 000 pages, l'audit manuel des ancres est impossible. Screaming Frog permet d'exporter toutes les ancres internes (Bulk Export > Links > All Inlinks). Filtrez ensuite par page cible et analysez la distribution des textes d'ancre :
Si une fiche produit reçoit 80 % de ses liens internes avec l'ancre "Voir le produit", vous perdez l'opportunité de signaler à Google de quoi parle cette page. Remplacez par des ancres descriptives générées dynamiquement à partir du nom du produit et de ses attributs clés.
Monitoring continu : détecter les régressions de maillage
L'architecture de liens internes n'est pas un projet one-shot. Chaque mise à jour du catalogue, chaque ajout de catégorie, chaque suppression de produit modifie le graphe de liens. Les régressions sont silencieuses : une catégorie qui perd ses liens croisés suite à un refacto de template, un bloc de recommandations qui passe en client-side après une mise à jour de dépendances, un breadcrumb qui se casse sur un type de page spécifique.
Les signaux à monitorer :
- Nombre de liens internes par page : une chute soudaine sur un template (toutes les fiches produit passent de 45 à 12 liens internes) indique un composant cassé.
- Profondeur de crawl moyenne : un drift progressif vers des valeurs plus élevées signale une croissance non maîtrisée du catalogue.
- Pages orphelines : des pages avec 0 ou 1 lien interne entrant. Sur un e-commerce, ce sont souvent des produits nouvellement ajoutés qui n'ont pas été correctement intégrés dans le maillage des catégories et des recommandations.
- Cohérence du rendu SSR : vérifiez régulièrement que vos blocs de liens internes (recommandations, cross-sell, catégories associées) sont bien présents dans le HTML rendu côté serveur. Un outil de monitoring comme Seogard peut détecter automatiquement quand un composant de liens disparaît du HTML servi à Googlebot, avant que l'impact sur le trafic ne devienne visible.
Programmez un crawl