Architecture flat vs deep : profondeur de clic et crawl SEO

Un site e-commerce de 22 000 pages produit voit 40 % de ses URLs jamais crawlées en 90 jours. Screaming Frog montre une profondeur de clic moyenne à 7. Les pages enterrées au-delà du niveau 5 ne reçoivent aucun lien interne significatif et stagnent hors de l'index. Le diagnostic est structurel, pas technique au sens serveur : l'architecture du site est trop profonde.

Le débat "flat vs deep" ne se résume pas à "mettre toutes les pages à 1 clic de la homepage". C'est un problème d'ingénierie du maillage interne qui impacte directement le crawl budget, la distribution du PageRank interne, et la vitesse d'indexation. Voici comment le modéliser, le mesurer, et le corriger.

Ce que "profondeur de clic" signifie réellement pour Googlebot

La profondeur de clic (click depth) mesure le nombre minimum de clics nécessaires depuis la page d'entrée (généralement la homepage) pour atteindre une URL donnée. Ce n'est pas la profondeur de l'URL dans l'arborescence des répertoires — example.fr/a/b/c/d.html peut très bien être à 2 clics de la homepage si un lien direct existe.

Google a confirmé à plusieurs reprises que la profondeur de clic influence la priorité de crawl. John Mueller l'a formulé ainsi dans un Webmaster Hangout de 2018 : les pages plus proches de la homepage sont considérées comme plus importantes. Ce n'est pas une heuristique abstraite — c'est directement lié à la façon dont Googlebot découvre les pages : en suivant les liens depuis les pages déjà connues, avec un budget fini.

La mécanique du crawl budget face à la profondeur

Googlebot alloue un nombre limité de requêtes par session de crawl à chaque site. Ce budget dépend de deux facteurs documentés par Google dans sa documentation sur le crawl budget :

Crawl rate limit : la capacité maximale de crawl sans dégrader l'expérience utilisateur (liée à la vitesse de réponse du serveur).
Crawl demand : l'intérêt de Google pour vos URLs (popularité, fraîcheur, type de contenu).

Dans une structure deep, Googlebot doit traverser 5, 6, 7 niveaux de liens pour atteindre les pages les plus profondes. À chaque niveau, il fait des choix : il ne suit pas tous les liens de chaque page. Les pages profondes ont donc une probabilité exponentiellement décroissante d'être atteintes dans une session de crawl donnée.

Concrètement, si votre page produit est accessible uniquement via Homepage → Catégorie → Sous-catégorie → Sous-sous-catégorie → Pagination page 8 → Produit, vous avez 6 niveaux. Si Googlebot explore 50 % des liens à chaque niveau (ce qui est optimiste), la probabilité qu'il atteigne cette page dans une session est de 0.5^6 ≈ 1.5 %.

Mesurer la profondeur réelle avec Screaming Frog

La mesure la plus fiable de la profondeur de clic se fait via un crawl complet. Dans Screaming Frog, la colonne "Crawl Depth" de l'onglet Internal donne directement cette information. Voici comment extraire une distribution exploitable :

# Exporter les données de crawl Screaming Frog en CLI
screamingfrogseospider --crawl https://www.votresite.fr \
  --headless \
  --output-folder /tmp/crawl-output \
  --export-tabs "Internal:All"

# Puis extraire la distribution de profondeur avec awk
awk -F'\t' 'NR>1 {depth[$NF]++} END {for (d in depth) print d, depth[d]}' \
  /tmp/crawl-output/internal_all.tsv | sort -n

Le résultat devrait ressembler à :

Si plus de 20 % de vos pages indexables sont au-delà du niveau 4, vous avez un problème d'architecture. Croisez ces données avec vos logs serveur pour vérifier la corrélation entre profondeur et fréquence de crawl — c'est le lien causal le plus fiable. L'analyse de logs pour comprendre le comportement de Googlebot est indispensable pour valider cette hypothèse sur votre site spécifique.

Structure flat : avantages, limites et cas d'usage

Une architecture "flat" (plate) vise à placer le maximum de pages à 1 ou 2 clics de la homepage. Dans sa forme extrême, cela signifie que la homepage lie directement à toutes les pages importantes du site.

Quand la structure flat fonctionne

La structure flat est optimale dans un cas précis : un nombre limité de pages à forte valeur, toutes au même niveau d'importance. Un SaaS avec 50 pages (landing pages, features, blog) n'a aucune raison d'avoir plus de 2 niveaux de profondeur. Un site vitrine de 200 pages peut parfaitement fonctionner avec une homepage qui maille vers des hubs thématiques, eux-mêmes liant directement aux pages finales.

L'avantage principal : la distribution du PageRank interne est quasi uniforme. Le jus transmis depuis la homepage (qui concentre typiquement 30-50 % des backlinks externes) se répartit directement sur les pages de niveau 1, sans dilution intermédiaire.

Le piège de la flat structure à grande échelle

Le problème apparaît quand vous appliquez une logique flat à un site de 10 000+ pages. Si votre homepage lie vers 500 catégories, chaque lien transmet 1/500ème du PageRank disponible — une quantité négligeable. Pire, une page qui affiche 500 liens internes pose un problème de signal : Googlebot ne peut pas déterminer quels liens sont importants.

Il y a une contrainte technique rarement évoquée : le nombre de liens que Googlebot suit par page. Historiquement, la limite documentée était de 100-150 liens par page. Cette limite a été assouplie (Google a confirmé pouvoir traiter des pages avec des milliers de liens), mais la distribution de poids entre ces liens reste inversement proportionnelle à leur nombre. Plus de liens = moins de poids par lien.

Voici un pattern HTML anti-pattern qu'on rencontre fréquemment sur les e-commerces qui tentent de "flatter" leur architecture :

<!-- Anti-pattern : mega-menu qui liste TOUTES les sous-catégories -->
<nav class="mega-menu">
  <ul>
    <li><a href="/chaussures/">Chaussures</a>
      <ul>
        <li><a href="/chaussures/running/">Running</a></li>
        <li><a href="/chaussures/trail/">Trail</a></li>
        <li><a href="/chaussures/running-femme/">Running Femme</a></li>
        <li><a href="/chaussures/running-homme/">Running Homme</a></li>
        <!-- ... 40 sous-catégories -->
      </ul>
    </li>
    <!-- ... 25 catégories principales x 40 sous-catégories = 1000+ liens -->
  </ul>
</nav>

Ce mega-menu, présent sur chaque page du site, génère plus de 1 000 liens internes par page. Résultat : chaque lien transmet un poids infinitésimal, et les liens contextuels dans le corps de la page (ceux qui ont le plus de valeur sémantique) sont noyés dans la masse.

La solution : flat sélective

L'approche qui fonctionne est la flat sélective : garder les pages stratégiques à faible profondeur (1-3 clics) tout en acceptant que les pages longue traîne soient plus profondes (3-5 clics). Concrètement :

Niveau 0 : Homepage
Niveau 1 : Catégories principales (max 15-20)
Niveau 2 : Sous-catégories + pages piliers
Niveau 3 : Pages produit / articles
Niveau 4 : Pages longue traîne, variantes produit

L'enjeu est de s'assurer que les pages de niveau 3-4 reçoivent suffisamment de liens internes contextuels pour compenser leur profondeur. C'est là que le maillage interne avancé entre en jeu.

Structure deep : quand la profondeur est inévitable (et comment l'atténuer)

Certaines architectures sont structurellement profondes. Un site e-commerce avec des facettes (taille, couleur, marque, prix) génère mécaniquement des couches supplémentaires. Un site média avec 15 ans d'archives a des articles à 8+ clics de la homepage. Un site de petites annonces avec localisation + catégorie + sous-catégorie + type d'offre crée 4 niveaux avant même d'arriver aux annonces.

Le cas concret : migration d'un e-commerce mode de 18 000 pages

Prenons un site e-commerce mode qui gère 18 000 pages indexables : 120 catégories, 850 sous-catégories, 15 000 fiches produit, 2 000 pages de contenu (guides, lookbooks). Avant restructuration, l'architecture ressemblait à :

Homepage (niveau 0)
└── Femme / Homme / Enfant (niveau 1, 3 pages)
    └── Vêtements / Chaussures / Accessoires (niveau 2, 9 pages)
        └── Robes / Jupes / Pantalons... (niveau 3, 120 pages)
            └── Robes d'été / Robes de soirée... (niveau 4, 850 pages)
                └── Pagination: page 1, 2, 3... (niveau 5-8)
                    └── Fiches produit (niveau 6-9)

L'analyse des logs montrait une corrélation nette :

Profondeur	Pages	Crawl moyen/mois	% indexées
1-2	12	450 hits	100%
3	120	180 hits	98%
4	850	85 hits	91%
5	3200	22 hits	72%
6	6800	8 hits	41%
7+	7000	2 hits	18%

Plus de 58 % des fiches produit (niveaux 6+) n'étaient pas indexées. Le trafic organique était concentré sur les catégories et sous-catégories de niveaux 3-4.

Les leviers pour réduire la profondeur effective

1. Liens contextuels cross-catégories

Plutôt que de compter uniquement sur la navigation hiérarchique, injectez des liens contextuels entre pages de même niveau. Un bloc "Produits similaires" ou "Complétez votre look" sur chaque fiche produit crée des connexions horizontales qui réduisent la profondeur effective.

<!-- Bloc de maillage contextuel sur une fiche produit -->
<section class="related-products" aria-label="Produits complémentaires">
  <h2>Complétez votre look</h2>
  <ul>
    <li>
      <a href="/chaussures/escarpins/escarpin-noir-cuir-elena/">
        Escarpin noir cuir Elena
      </a>
    </li>
    <li>
      <a href="/accessoires/sacs/pochette-soiree-dore/">
        Pochette de soirée dorée
      </a>
    </li>
    <li>
      <a href="/bijoux/colliers/collier-pendentif-cristal/">
        Collier pendentif cristal
      </a>
    </li>
  </ul>
</section>

L'avantage de ce pattern : il lie des pages de niveau 6 directement entre elles, sans passer par les niveaux intermédiaires. Pour Googlebot, une page produit qui reçoit 15-20 liens internes depuis d'autres fiches produit est effectivement plus "proche" du cœur du site qu'une page isolée en bout de branche.

2. Pages hub intermédiaires

Créez des pages de type "hub" qui agrègent des liens vers les pages les plus profondes. Une page "Nos 200 meilleures ventes" ou "Nouveautés de la semaine" liée depuis la homepage crée un raccourci direct vers des fiches produit qui seraient sinon à 6+ clics.

3. Sitemap HTML stratégique

Un sitemap HTML n'est pas une relique des années 2000. Sur un site de 18 000 pages, un sitemap HTML segmenté par catégorie, lié depuis le footer, réduit mécaniquement la profondeur maximale de 2-3 niveaux.

4. Pagination optimisée

La pagination est le premier facteur de profondeur excessive. Si une sous-catégorie contient 400 produits affichés par 20, vous avez 20 pages de pagination — et les produits de la page 20 sont à +20 niveaux de profondeur par rapport à la catégorie.

Solutions concrètes :

Augmenter le nombre de produits par page (60-100 au lieu de 20) en utilisant le lazy loading
Implémenter un "load more" en JavaScript avec rendu des liens côté serveur (attention au SSR vs CSR et ses pièges)
Ajouter des liens directs vers les pages de pagination intermédiaires (1, 2, 3... 10, 20)

Le problème de navigation à facettes aggrave encore ce phénomène en multipliant les combinaisons et donc les niveaux de profondeur.

Modéliser la distribution du PageRank interne

Le débat flat vs deep est fondamentalement un problème de distribution de PageRank interne. Le PageRank d'une page se distribue (de manière simplifiée) de façon égale entre tous ses liens sortants. Dans une structure hiérarchique pure, le PageRank se dilue exponentiellement à chaque niveau.

Simulation avec un modèle simplifié

Voici un script Python qui modélise la distribution de PageRank dans une architecture à N niveaux, avec un facteur de branchement (nombre de liens sortants par page) configurable :

import numpy as np

def simulate_pagerank_distribution(levels: int, branching_factor: int, 
                                     damping: float = 0.85, 
                                     homepage_pr: float = 100.0) -> dict:
    """
    Simule la distribution de PR dans une structure arborescente pure.
    
    Args:
        levels: nombre de niveaux sous la homepage
        branching_factor: nombre de liens enfants par page
        damping: facteur d'amortissement (0.85 standard)
        homepage_pr: PR initial de la homepage
    
    Returns:
        dict avec le PR moyen par page à chaque niveau
    """
    results = {0: homepage_pr}
    
    for level in range(1, levels + 1):
        pages_at_level = branching_factor ** level
        # Chaque page du niveau parent distribue son PR entre ses enfants
        parent_pr = results[level - 1]
        # PR transmis = PR parent * damping / nombre de liens sortants
        # (simplifié : on ignore les liens de navigation globale)
        pr_per_child = (parent_pr * damping) / branching_factor
        results[level] = pr_per_child
    
    return results

# Scénario 1 : structure deep (7 niveaux, 20 liens par page)
deep = simulate_pagerank_distribution(levels=7, branching_factor=20)
print("=== Structure deep (7 niveaux, 20 liens/page) ===")
for level, pr in deep.items():
    pages = 20 ** level if level > 0 else 1
    print(f"Niveau {level}: PR/page = {pr:.4f} | Pages = {pages:,}")

# Scénario 2 : structure flat (3 niveaux, 200 liens par page)
flat = simulate_pagerank_distribution(levels=3, branching_factor=200)
print("\n=== Structure flat (3 niveaux, 200 liens/page) ===")
for level, pr in flat.items():
    pages = 200 ** level if level > 0 else 1
    print(f"Niveau {level}: PR/page = {pr:.4f} | Pages = {pages:,}")

Le résultat est instructif : dans la structure deep, les pages de niveau 6 reçoivent un PR de ~0.0002 alors que dans la structure flat, les pages de niveau 3 reçoivent ~0.0018 — un ordre de grandeur supérieur. Mais le nombre de pages à niveau 3 dans la structure flat est aussi bien plus élevé (8 millions vs quelques milliers), ce qui montre que la structure flat pure est un leurre à grande échelle.

La vraie solution est de créer des raccourcis dans le graphe : des liens qui connectent directement des pages profondes à des pages de haut niveau. Chaque lien contextuel cross-catégorie, chaque bloc "populaire cette semaine", chaque recommandation produit est un raccourci qui court-circuite la hiérarchie et redistribue du PageRank là où il manque.

Auditer et monitorer la profondeur de votre site

Audit initial avec Screaming Frog + Google Search Console

La première étape est de cartographier votre profondeur actuelle et de la croiser avec les données de crawl réel de Google.

Dans Google Search Console, le rapport "Statistiques d'exploration" (Settings > Crawl Stats) donne la distribution du temps de réponse et du nombre de requêtes par jour. Mais il ne donne pas la profondeur. Pour obtenir cette corrélation, il faut croiser deux sources :

Screaming Frog pour la profondeur de clic de chaque URL
Logs serveur pour la fréquence de crawl Googlebot par URL

Exportez les deux datasets et joignez-les par URL. Un script rapide :

# Extraire les hits Googlebot par URL depuis les logs (format Combined)
grep -i "Googlebot" /var/log/nginx/access.log \
  | awk '{print $7}' \
  | sort \
  | uniq -c \
  | sort -rn \
  | head -1000 > googlebot_hits_by_url.tsv

# Joindre avec l'export Screaming Frog (CSV avec colonnes Address, Crawl Depth)
# En Python pour plus de flexibilité
python3 << 'EOF'
import pandas as pd

sf = pd.read_csv('internal_all.csv', usecols=['Address', 'Crawl Depth'])
logs = pd.read_csv('googlebot_hits_by_url.tsv', sep='\s+', 
                     names=['hits', 'url'], header=None)

merged = sf.merge(logs, left_on='Address', right_on='url', how='left')
merged['hits'] = merged['hits'].fillna(0)

# Agrégation par profondeur
summary = merged.groupby('Crawl Depth').agg(
    pages=('Address', 'count'),
    avg_hits=('hits', 'mean'),
    median_hits=('hits', 'median'),
    zero_hits_pct=('hits', lambda x: (x == 0).mean() * 100)
).round(2)

print(summary.to_string())
EOF

Ce tableau de synthèse vous donne immédiatement la corrélation entre profondeur et crawl sur votre site. Si vous constatez un décrochage brutal (par exemple, les pages de profondeur 5 ont 3x moins de crawl que celles de profondeur 4), c'est votre seuil critique.

Monitoring continu : détecter les régressions d'architecture

L'architecture d'un site n'est pas statique. Chaque déploiement peut modifier la profondeur de pages existantes : une refonte de menu qui supprime des liens, une migration de catégories qui casse des raccourcis, un redesign de template produit qui retire le bloc "produits associés".

Ces régressions sont silencieuses. Personne ne vérifie manuellement la profondeur de clic de 15 000 pages après chaque mise en production. C'est exactement le type de problème qu'un outil de monitoring continu comme Seogard détecte automatiquement — une augmentation soudaine de la profondeur moyenne ou la disparition de liens internes clés entre deux crawls. Sans monitoring automatisé, ces régressions SEO passent inaperçues pendant des semaines, le temps que la Search Console reflète la baisse de trafic.

L'approche d'audits ponctuels ne suffit pas pour ce type de dégradation progressive. Entre deux audits trimestriels, un site peut accumuler des dizaines de micro-régressions architecturales qui, individuellement, semblent mineures mais qui, cumulées, font chuter le taux de crawl des pages profondes de 40 %.

Implémenter une architecture optimisée : checklist technique

Définir votre budget de liens par template

Chaque template de page a un "budget de liens" : le nombre total de liens internes qu'il affiche. Ce budget se répartit entre navigation (header, footer, sidebar, breadcrumb), liens contextuels (contenu, blocs relatés), et liens fonctionnels (pagination, filtres).

L'objectif est de maximiser la part des liens contextuels — ceux qui portent le plus de signal sémantique — tout en gardant une navigation fonctionnelle.

Exemple de budget de liens pour un template de page catégorie e-commerce :

Zone	Liens	% du budget
Header/navigation	25	16%
Breadcrumb	3	2%
Sous-catégories	15	10%
Produits affichés	60	39%
Blocs "populaire" / "nouveau"	12	8%
Liens contextuels guides/contenus	8	5%
Footer	20	13%
Pagination	10	7%
Total	153	100%

Restez sous 200 liens internes par page. Au-delà, la dilution de PageRank rend chaque lien individuel insignifiant.

Breadcrumbs structurés : le raccourci sous-estimé

Les breadcrumbs sont souvent implémentés comme un élément UX secondaire. En réalité, ils sont critiques pour l'architecture SEO car ils créent un chemin de liens directs depuis chaque page profonde vers les niveaux supérieurs — et ils sont rendus côté serveur sur chaque page.

Implémentez-les avec le balisage structuré BreadcrumbList :

<nav aria-label="Breadcrumb">
  <ol itemscope itemtype="https://schema.org/BreadcrumbList">
    <li itemprop="itemListElement" itemscope itemtype="https://schema.org/ListItem">
      <a itemprop="item" href="https://www.votresite.fr/">
        <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="https://www.votresite.fr/femme/">
        <span itemprop="name">Femme</span>
      </a>
      <meta itemprop="position" content="2" />
    </li>
    <li itemprop="itemListElement" itemscope itemtype="https://schema.org/ListItem">
      <a itemprop="item" href="https://www.votresite.fr/femme/robes/">
        <span itemprop="name">Robes</span>
      </a>
      <meta itemprop="position" content="3" />
    </li>
    <li itemprop="itemListElement" itemscope itemtype="https://schema.org/ListItem">
      <span itemprop="name">Robe longue fleurie Alma</span>
      <meta itemprop="position" content="4" />
    </li>
  </ol>
</nav>

Chaque breadcrumb crée un lien "remontant" vers les niveaux supérieurs, renforçant le poids des pages catégorie. Et depuis chaque page catégorie, les liens vers les pages enfants sont naturellement présents dans le listing. Ce maillage bidirectionnel parent-enfant est le squelette minimum de votre architecture.

Surveiller l'impact post-restructuration

Après une restructuration, surveillez ces métriques dans Google Search Console et vos logs :

Pages explorées par jour (Crawl Stats) : devrait augmenter dans les 2-4 semaines
Pages indexées vs soumises (Index Coverage) : le delta devrait se réduire
Fréquence de crawl par profondeur (logs) : les pages précédemment profondes et non crawlées devraient commencer à recevoir des hits

Sur l'e-commerce mode de 18 000 pages mentionné plus haut, la restructuration (réduction de la profondeur max de 9 à 5, ajout de blocs cross-link, sitemap HTML) a produit ces résultats sur 8 semaines :

Pages crawlées quotidiennement par Googlebot : +65 % (de 1 200 à 1 980)
Pages indexées : +34 % (de 11 700 à 15 700)
Trafic organique sur les fiches produit : +28 %

Le gain de trafic n'est pas venu d'un meilleur contenu ni de nouveaux backlinks. Uniquement de pages enfin crawlées et indexées grâce à une architecture qui les rendait accessibles.

Le bon compromis : ni flat ni deep, mais un graphe optimisé

Le débat flat vs deep est un faux dilemme. La bonne architecture n'est ni un arbre plat ni un arbre profond — c'est un graphe orienté avec des raccourcis stratégiques. Les pages les plus importantes (celles qui génèrent du revenu ou du trafic) doivent être à 3 clics maximum. Les pages longue traîne peuvent être à 4-5 clics, à condition de recevoir suffisamment de liens internes contextuels pour compenser.

Mesurez votre profondeur réelle (Screaming Frog), croisez-la avec votre fréquence de crawl (logs serveur), identifiez le seuil critique où le crawl décroche, puis injectez des raccourcis ciblés — blocs de liens contextuels, hubs intermédiaires, breadcrumbs structurés. Monitorez ces métriques en continu : une architecture SEO se dégrade à chaque sprint si personne ne surveille les seuils d'alerte. C'est un travail d'ingénierie permanent, pas un audit ponctuel.