Architecture flat vs deep : profondeur de clic et crawl SEO

Un e-commerce de 28 000 pages dont 40 % ne reçoivent aucune visite organique. L'audit révèle que 11 000 URLs sont à plus de 6 clics de la homepage. Googlebot les crawl une fois par trimestre, quand il les crawl. Le problème n'est ni le contenu, ni les backlinks — c'est l'architecture.

La distinction entre architecture "flat" (peu de niveaux, beaucoup de liens par niveau) et "deep" (beaucoup de niveaux, peu de liens par niveau) est au cœur de la performance SEO technique. Mais la réalité est plus nuancée qu'un simple "flat = bien, deep = mal".

Profondeur de clic : ce que Googlebot voit vraiment

La profondeur de clic (click depth) est le nombre minimum de clics nécessaires depuis la homepage pour atteindre une URL. Ce n'est pas la profondeur de l'URL dans l'arborescence du path (/cat/subcat/product/ = 3 segments, mais peut-être 2 clics si la homepage lie directement vers la sous-catégorie).

Google ne documente pas explicitement un seuil de profondeur au-delà duquel il arrête de crawler. Mais les données d'analyse de logs sont sans ambiguïté : la fréquence de crawl décroît de façon quasi-exponentielle avec la profondeur de clic.

Observation empirique sur les logs

Sur un site média de 18 000 articles, voici la distribution de crawl observée sur 30 jours via une analyse de logs Googlebot :

Profondeur de clic	Nombre de pages	Crawl moyen / page / mois
1	45	312
2	680	87
3	4 200	23
4	8 100	6
5+	4 975	1,2

La chute entre profondeur 3 et 4 est le point critique. Au-delà de 4 clics, la majorité des pages sont crawlées moins d'une fois par semaine — insuffisant pour un site dont le contenu évolue régulièrement.

Mesurer la profondeur réelle

Screaming Frog calcule la click depth nativement. Mais attention : il suit tous les liens, y compris ceux rendus en JavaScript. Pour obtenir la profondeur telle que Googlebot la perçoit, il faut configurer le crawler en mode "JavaScript rendering" et comparer avec les données de la Search Console (rapport de couverture) et les logs serveur.

Pour extraire la profondeur de clic depuis un export Screaming Frog et identifier les pages problématiques :

import pandas as pd

# Export Screaming Frog "Internal > All" en CSV
df = pd.read_csv('internal_all.csv')

# Filtrer les pages indexables uniquement
indexable = df[
    (df['Status Code'] == 200) &
    (df['Indexability'] == 'Indexable')
]

# Distribution de la profondeur
depth_dist = indexable.groupby('Crawl Depth').agg(
    pages=('Address', 'count'),
    avg_inlinks=('Inlinks', 'mean')
).reset_index()

print(depth_dist)

# Pages indexables à profondeur 5+
deep_pages = indexable[indexable['Crawl Depth'] >= 5][['Address', 'Crawl Depth', 'Inlinks']]
deep_pages.to_csv('deep_pages_to_fix.csv', index=False)
print(f"\n{len(deep_pages)} pages à profondeur >= 5 nécessitent une action")

Ce script vous donne immédiatement la liste des pages à remonter dans l'architecture. Le champ Inlinks permet de distinguer les pages profondes mais bien maillées (potentiellement OK) de celles qui sont à la fois profondes ET orphelines (urgence).

Pour compléter cette analyse côté serveur, l'analyse de logs permet de valider que Googlebot atteint effectivement les pages que vous pensez accessibles.

Architecture flat : avantages réels et limites structurelles

Une architecture flat place le maximum de pages à 1-3 clics de la homepage. Le cas extrême : toutes les pages liées depuis la homepage. C'est l'approche historique recommandée par beaucoup de guides SEO — et elle a ses mérites.

Pourquoi ça fonctionne (jusqu'à un certain point)

Dans une architecture flat, le PageRank interne se distribue de façon plus homogène. La homepage concentre généralement le plus d'autorité (backlinks externes, liens internes). Si elle lie directement vers 500 catégories et sous-catégories, chacune reçoit une part du jus. Les pages à 2 clics héritent encore d'une quantité significative de cette autorité.

Pour un site vitrine de 200 pages ou un blog de 500 articles, c'est souvent la structure optimale. Un footer exhaustif, une navigation principale bien pensée et quelques hubs thématiques suffisent.

Le point de rupture

Le problème survient à l'échelle. Prenez un e-commerce mode avec :

120 catégories
800 sous-catégories
15 000 pages produit
3 000 pages de filtre (couleur, taille, prix)

Lier toutes les catégories depuis la homepage impliquerait un méga-menu de 120+ liens. Ajouter les sous-catégories porterait la homepage à 900+ liens internes. Le résultat :

Dilution du PageRank : chaque lien transmet une fraction de l'autorité. Avec 900 liens, chacun transmet ~0,1 % du PageRank de la homepage.
Surcharge cognitive UX : un méga-menu de 900 entrées est inutilisable.
Poids du DOM : un menu de navigation inline de 900 liens ajoute facilement 50-80 Ko de HTML pur au <body>, impactant le Time to Interactive.

Voici ce que ça donne concrètement dans le DOM :

<!-- Anti-pattern : méga-menu "flat" avec 120 catégories -->
<nav class="mega-menu">
  <ul>
    <li><a href="/femme/robes/">Robes</a>
      <ul>
        <li><a href="/femme/robes/longues/">Robes longues</a></li>
        <li><a href="/femme/robes/courtes/">Robes courtes</a></li>
        <li><a href="/femme/robes/cocktail/">Robes cocktail</a></li>
        <!-- ... 8 sous-catégories -->
      </ul>
    </li>
    <!-- ... 119 autres catégories avec chacune 5-10 sous-catégories -->
    <!-- Total : 800+ liens dans le <nav> -->
  </ul>
</nav>

<!-- Résultat : 
     - DOM size > 3000 éléments rien que pour le menu
     - 800+ liens internes sur CHAQUE page du site
     - PageRank dilué vers des catégories à faible potentiel
-->

Un site avec 800 liens dans le header fait passer le même poids à la sous-catégorie "Robes cocktail" (50 recherches/mois) qu'à "Robes" (12 000 recherches/mois). C'est un gaspillage d'autorité.

Architecture deep : quand la hiérarchie a du sens

Une architecture deep structure l'information en entonnoir : homepage → univers → catégories → sous-catégories → produits. Chaque niveau ne lie que vers le niveau immédiatement inférieur. Le résultat : des pages produit à 4-5 clics de la homepage.

Avantages structurels

La hiérarchie permet de concentrer le PageRank interne là où il est utile. Si la homepage lie vers 8 univers, chacun reçoit ~12,5 % de l'autorité (simplifié). Chaque univers distribue vers 15 catégories, etc. Les pages stratégiques (catégories à fort volume) reçoivent proportionnellement plus d'autorité que dans un modèle flat dilué.

C'est aussi la structure naturelle pour les breadcrumbs, qui renforcent la compréhension hiérarchique par Google et améliorent la présentation SERP.

Le risque : les pages enterrées

Sur l'e-commerce de 28 000 pages mentionné en introduction, voici l'arborescence réelle :

Homepage (profondeur 0)
└── 8 univers (profondeur 1)
    └── 15 catégories par univers = 120 catégories (profondeur 2)
        └── ~8 sous-catégories par catégorie = ~960 sous-catégories (profondeur 3)
            └── ~15 produits par sous-catégorie = ~14 400 produits (profondeur 4)
                └── Variantes couleur/taille = ~11 000 variantes (profondeur 5-6)

Les 11 000 variantes produit à profondeur 5-6 ne sont presque jamais crawlées. Les 14 400 pages produit à profondeur 4 sont crawlées sporadiquement. Seules les pages jusqu'à profondeur 3 bénéficient d'un crawl régulier.

Si les pages produit portent des requêtes longue traîne significatives (et c'est souvent le cas en e-commerce), cette architecture enterre littéralement votre trafic potentiel.

L'approche hybride : architecture pyramidale avec shortcuts

La solution n'est ni full flat ni full deep. C'est une architecture pyramidale avec des liens transversaux stratégiques — ce que j'appelle des "shortcuts" — qui réduisent la profondeur effective des pages critiques sans écraser la structure hiérarchique.

Principes de conception

Hiérarchie principale : homepage → univers → catégories → sous-catégories → produits (structure deep classique)
Shortcuts depuis la homepage : liens directs vers les 20-30 catégories/sous-catégories à plus fort potentiel SEO (pas dans le menu principal — dans un bloc "Catégories populaires", une bande de mise en avant, etc.)
Cross-links catégoriels : chaque page catégorie lie vers 5-10 catégories liées du même univers et 2-3 catégories d'univers différents
Maillage produit-produit : "Produits similaires", "Complétez votre look", "Les clients ont aussi aimé" — chaque produit lie vers 4-8 autres produits

Pour une stratégie de maillage interne e-commerce plus détaillée, notamment sur les blocs de cross-selling et la gestion du maillage à grande échelle, ces patterns sont approfondis.

Implémentation des shortcuts

Voici un composant serveur (Next.js App Router) qui génère dynamiquement un bloc de catégories populaires sur la homepage, basé sur les données réelles de trafic :

// app/components/PopularCategories.tsx
// Composant serveur — rendu côté serveur, crawlable nativement

import { db } from '@/lib/database';

interface Category {
  slug: string;
  name: string;
  monthlySearchVolume: number;
  productCount: number;
}

async function getPopularCategories(limit: number = 24): Promise<Category[]> {
  // Sélection basée sur le volume de recherche ET le nombre de produits actifs
  // Exclure les catégories saisonnières hors saison
  const categories = await db.query<Category>(`
    SELECT c.slug, c.name, c.monthly_search_volume, 
           COUNT(p.id) as product_count
    FROM categories c
    JOIN products p ON p.category_id = c.id 
      AND p.status = 'active' 
      AND p.stock > 0
    WHERE c.monthly_search_volume > 500
      AND c.is_seasonal = false
    GROUP BY c.id
    HAVING COUNT(p.id) >= 5
    ORDER BY c.monthly_search_volume DESC
    LIMIT $1
  `, [limit]);

  return categories;
}

export default async function PopularCategories() {
  const categories = await getPopularCategories();

  return (
    <section aria-labelledby="popular-categories">
      <h2 id="popular-categories">Nos catégories les plus recherchées</h2>
      <div className="category-grid">
        {categories.map((cat) => (
          <a 
            key={cat.slug} 
            href={`/c/${cat.slug}/`}
            className="category-card"
          >
            <span className="category-name">{cat.name}</span>
            <span className="product-count">
              {cat.productCount} produits
            </span>
          </a>
        ))}
      </div>
    </section>
  );
}

Ce bloc ajoute 24 liens internes depuis la homepage vers les catégories à plus fort potentiel — sans toucher au méga-menu. Les sous-catégories qui étaient à profondeur 3 passent à profondeur 1 (un clic depuis la homepage). Et parce que c'est un composant serveur, le HTML est présent dans la réponse initiale — aucun risque de divergence SSR/CSR.

Attention : ce composant doit générer des liens en HTML standard (<a href>). Si vous utilisez un framework JavaScript qui produit du routing client-side sans <a> natifs, Googlebot peut ne pas suivre les liens. C'est un piège classique des SPA.

Impact mesuré : le cas du e-commerce mode

Revenons à notre e-commerce de 28 000 pages. Après implémentation de l'architecture hybride :

Avant (deep strict) :

Profondeur moyenne des pages indexables : 4,2
Pages à profondeur 5+ : 11 000 (39 %)
Crawl quotidien Googlebot : ~1 200 pages/jour
Pages recevant du trafic organique : 16 800 (60 %)

Actions réalisées :

Bloc "Catégories populaires" sur la homepage (24 liens, profondeur effective réduite de 1 niveau)
Blocs "Sous-catégories liées" sur chaque page catégorie (8 liens cross-catégories)
Module "Produits similaires" sur chaque fiche produit (6 liens produit-produit)
Pagination revue : passage du "load more" JS à une pagination HTML avec liens <a> vers les pages 2, 3, dernière (les pages de pagination en JavaScript étaient invisibles pour Googlebot — un classique des pièges React côté SEO)

Après (3 mois plus tard) :

Profondeur moyenne des pages indexables : 3,1
Pages à profondeur 5+ : 2 300 (8 %)
Crawl quotidien Googlebot : ~2 800 pages/jour (×2,3)
Pages recevant du trafic organique : 21 400 (76 %)

Le gain de 4 600 pages supplémentaires recevant du trafic organique correspond à un delta de +16 points de couverture. La majorité de ces pages sont des fiches produit longue traîne qui étaient simplement enterrées trop profondément.

Gestion de la navigation à facettes dans l'architecture

La navigation à facettes est le cas d'usage où le conflit flat vs deep est le plus violent. Chaque combinaison de filtres génère potentiellement une URL. Un catalogue de 800 sous-catégories × 10 couleurs × 8 tailles × 5 tranches de prix = 320 000 URLs.

Le piège de l'ultra-flat

Si vous rendez tous les filtres crawlables (liens <a> avec des URLs paramétrées), vous créez une architecture artificiellement "flat" — chaque page catégorie lie vers des centaines de combinaisons de filtres. Résultat :

Explosion du crawl budget : Googlebot passe son temps à crawler des pages quasi-identiques
Dilution de la pertinence : Google ne sait plus quelle URL positionner pour "robe rouge taille M"
Cannibalisation : /robes/?couleur=rouge vs /robes/rouges/ se battent pour le même mot-clé

La bonne approche

Seules les combinaisons à volume de recherche significatif méritent une URL indexable. Le reste doit être géré via noindex, canonical vers la catégorie parente, ou blocage par robots.txt / balise meta.

Configuration Nginx pour bloquer les combinaisons de filtres multiples tout en laissant les filtres simples indexables :

server {
    # Autoriser les filtres simples (un seul paramètre)
    # /femme/robes/?couleur=rouge → crawlable

    # Bloquer les combinaisons multiples (2+ paramètres de filtre)
    # /femme/robes/?couleur=rouge&taille=m&prix=50-100 → X-Robots-Tag noindex
    location ~ ^/[a-z-]+/[a-z-]+/ {
        # Compter le nombre de paramètres de filtre
        set $filter_count 0;
        
        if ($arg_couleur) { set $filter_count "${filter_count}1"; }
        if ($arg_taille)  { set $filter_count "${filter_count}1"; }
        if ($arg_prix)    { set $filter_count "${filter_count}1"; }
        if ($arg_marque)  { set $filter_count "${filter_count}1"; }
        if ($arg_matiere) { set $filter_count "${filter_count}1"; }

        # Si 2+ filtres actifs (string "11" ou plus long), noindex
        if ($filter_count ~ "^.{2,}$") {
            add_header X-Robots-Tag "noindex, follow" always;
        }
    }

    # Pages de tri : jamais indexables
    if ($arg_sort) {
        add_header X-Robots-Tag "noindex, follow" always;
    }

    # Pagination au-delà de la page 5 : noindex
    # Les premières pages concentrent 95% du potentiel SEO
    if ($arg_page ~ "^[6-9]|[1-9][0-9]+$") {
        add_header X-Robots-Tag "noindex, follow" always;
    }
}

Le follow est important : même si la page combinée n'est pas indexée, Googlebot suit les liens qu'elle contient. Les liens internes sur ces pages (vers des produits, vers d'autres catégories) conservent leur valeur pour le maillage. Bloquer complètement le crawl via robots.txt couperait ce flux de PageRank.

Auditer et monitorer la profondeur de clic en continu

Un audit ponctuel de l'architecture donne une photo à un instant T. Mais l'architecture se dégrade naturellement : nouvelles catégories ajoutées sans liens, produits en rupture qui créent des impasses, refonte partielle du menu qui casse des chemins de navigation.

Signaux d'alerte à monitorer

Dans la Search Console :

Rapport "Pages" > "Découverte – actuellement non indexée" : augmentation = symptôme de pages que Googlebot découvre via le sitemap mais ne juge pas assez importantes pour indexer (souvent corrélé à une profondeur excessive)
Rapport "Exploration" > "Statistiques d'exploration" : baisse du nombre de pages crawlées/jour sans changement de volume = Googlebot priorise différemment (signe potentiel de problème architectural)

Dans Screaming Frog :

Comparer les exports de crawl depth mois par mois. Toute page stratégique dont la profondeur augmente de 1+ niveau est un signal d'alarme.

Dans les logs serveur :

Ratio crawl des pages profondes vs pages superficielles. Si le ratio se dégrade, l'architecture perd en efficacité. L'analyse de logs est le seul moyen fiable de mesurer ce que Googlebot crawle réellement, par opposition à ce qu'il pourrait théoriquement crawler.

Automatiser la détection

Un audit Screaming Frog hebdomadaire est réaliste pour un site de 5 000 pages. Pour un site de 30 000 pages, le crawl prend plusieurs heures et mobilise des ressources serveur. C'est là qu'un monitoring continu comme Seogard apporte de la valeur : la détection automatique de pages qui passent au-dessus d'un seuil de profondeur, ou de liens internes qui disparaissent suite à un déploiement, permet de réagir avant que l'impact SEO ne se matérialise.

Les régressions architecturales sont d'ailleurs parmi les régressions SEO les plus fréquentes : un menu modifié, un composant de maillage qui cesse de se rendre côté serveur, une chaîne de redirections qui s'allonge et coupe un chemin de navigation.

Le rôle des sitemaps XML dans l'architecture

Le sitemap XML ne remplace pas une bonne architecture de liens internes. Il agit comme un filet de sécurité — un signal de découverte qui dit à Googlebot "ces URLs existent". Mais un sitemap ne transmet pas de PageRank et ne donne aucune indication de hiérarchie.

En pratique, sur le cas du e-commerce de 28 000 pages, les 11 000 pages profondes étaient toutes dans le sitemap. Googlebot les connaissait. Il choisissait simplement de ne pas les crawler souvent, car le signal d'importance transmis par les liens internes était trop faible.

Le sitemap est utile pour la découverte initiale et pour les sites dont le maillage interne est imparfait. Mais c'est un pansement, pas une solution architecturale. Si vous devez vous reposer sur le sitemap pour que vos pages soient crawlées, l'architecture a un problème.

Checklist de décision : flat, deep ou hybride

La bonne architecture dépend de la taille du site, du rythme de publication, et de la distribution du potentiel SEO entre les pages.

Sites < 500 pages (blogs, SaaS, sites vitrine)

Architecture flat ou quasi-flat. Objectif : toutes les pages à 3 clics max.

Navigation principale avec toutes les catégories
Footer avec liens vers les pages stratégiques
Maillage contextuel entre articles liés
Un sitemap suffit comme complément

Sites 500 à 5 000 pages (médias, e-commerce moyen)

Architecture pyramidale avec shortcuts ciblés. Objectif : 90 % des pages à 3 clics, 100 % à 4 clics.

Méga-menu structuré avec univers et catégories principales (pas toutes les sous-catégories)
Blocs de catégories populaires sur la homepage
Cross-linking inter-catégories
Maillage interne contextuel dans le contenu
Breadcrumbs sur toutes les pages

Sites > 5 000 pages (gros e-commerce, marketplaces, médias à fort volume)

Architecture hiérarchique stricte avec shortcuts dynamiques et contrôle granulaire des facettes. Objectif : pages stratégiques à 3 clics, pages longue traîne à 4 clics max.

Hiérarchie claire (univers → catégories → sous-catégories → produits)
Shortcuts dynamiques basés sur les données (volume de recherche, taux de conversion, saisonnalité)
Navigation à facettes contrôlée avec indexation sélective
Modules de cross-selling / up-selling comme vecteurs de maillage
Monitoring continu de la profondeur et de la couverture de crawl
Audit de logs mensuel minimum pour valider le comportement réel de Googlebot

Les sites à ce niveau de complexité doivent aussi anticiper l'impact de chaque migration ou refonte sur l'architecture de liens. Un changement d'URL structure qui ajoute un niveau de profondeur à 10 000 pages peut faire chuter le trafic organique de 15-20 % en quelques semaines.

L'architecture d'un site n'est pas un choix binaire entre flat et deep. C'est un système de distribution d'autorité et de signaux de crawl qui doit s'adapter au volume de pages, à la distribution du potentiel SEO, et aux contraintes UX. La règle fondamentale reste simple : chaque page qui mérite de se positionner doit être à 3 clics maximum de la homepage — et la seule façon de s'en assurer dans la durée, c'est de monitorer cette métrique en continu, pas une fois par trimestre lors d'un audit.