SPA et SEO : rendre une Single Page Application crawlable

Un site e-commerce de 12 000 fiches produits migre vers React SPA. Six mois plus tard, 73 % des pages produit ont disparu de l'index Google. Le trafic organique a chuté de 58 %. Le coupable : un <div id="root"></div> vide servi au crawler, avec tout le contenu généré côté client après exécution JavaScript. Ce scénario n'est pas hypothétique — c'est le pattern de défaillance le plus fréquent en JavaScript SEO.

Comment Googlebot traite une SPA : le pipeline de rendering en deux phases

Googlebot ne fonctionne pas comme un navigateur classique qui charge une page et attend que tout soit prêt. Le crawl se décompose en deux étapes distinctes, séparées par une file d'attente dont le délai est imprévisible.

Phase 1 : crawl HTTP et parsing du HTML brut

Le crawler envoie une requête HTTP GET, reçoit le HTML, et en extrait immédiatement les liens, les balises <title>, <meta>, les <link rel="canonical">, et le contenu textuel visible. Cette phase est rapide et peu coûteuse en ressources.

Pour une SPA classique bootstrappée côté client, voici ce que Googlebot reçoit à cette étape :

<!DOCTYPE html>
<html lang="fr">
<head>
  <meta charset="UTF-8">
  <title>Mon App</title>
  <meta name="description" content="">
  <link rel="stylesheet" href="/static/css/main.a1b2c3.css">
</head>
<body>
  <div id="root"></div>
  <script src="/static/js/bundle.7d8e9f.js"></script>
  <script src="/static/js/vendor.4a5b6c.js"></script>
</body>
</html>

Pas de contenu. Pas de liens internes. Pas de données structurées. Pas de titre de page pertinent. Le crawler voit une coquille vide.

Phase 2 : rendering JavaScript via Web Rendering Service (WRS)

La page est placée dans une file d'attente de rendering. Le WRS (basé sur une version headless de Chrome) exécute le JavaScript, attend que le DOM se stabilise, puis indexe le résultat. Selon la documentation officielle de Google sur le rendering JavaScript, ce processus peut prendre de quelques secondes à plusieurs jours.

Le problème fondamental : entre la phase 1 et la phase 2, Google a déjà pris des décisions. Si le HTML brut ne contient aucun lien interne, le crawler ne découvre pas les autres pages de votre SPA. Si le <title> est générique, le signal de pertinence est nul. Si la balise canonical est absente du HTML initial, Google peut choisir une URL canonique arbitraire.

Le coût réel du rendering côté Google

Google ne dit pas publiquement combien de pages il peut renderer par jour pour un site donné. Mais les données de la Search Console racontent une histoire claire : sur un site de 15 000 pages en SPA pure (React, client-side rendering uniquement), le rapport de couverture montre typiquement 2 000 à 4 000 pages "Découverte, actuellement non indexée" — des pages que Googlebot a trouvées mais n'a pas encore rendues, ou dont le rendering a échoué silencieusement.

Ce phénomène s'aggrave avec le crawl budget. Chaque page qui nécessite un rendering JavaScript consomme significativement plus de ressources qu'une page HTML statique. Sur les gros sites, Google fait des choix — et vos pages produit les moins populaires passent en dernier.

Le routing SPA : History API vs hash fragments

Le choix du mécanisme de routing dans votre SPA a un impact direct et immédiat sur la crawlabilité.

Hash fragments : le piège classique

Les premiers frameworks SPA (AngularJS 1.x, Backbone) utilisaient des URLs à base de hash :

https://shop.example.fr/#/categorie/chaussures
https://shop.example.fr/#/produit/nike-air-max-90

Googlebot ignore tout ce qui suit le #. Ces deux URLs sont identiques pour le crawler : https://shop.example.fr/. Résultat : une seule page indexée au lieu de milliers. Le schéma #! (hashbang) avec _escaped_fragment_ était un workaround que Google a officiellement déprécié en 2015.

Si votre SPA utilise encore des hash routes, c'est un blocage total à l'indexation. Pas un frein — un blocage.

History API : la base obligatoire

L'API History (pushState, replaceState) permet de manipuler l'URL du navigateur sans rechargement de page, tout en générant de vraies URLs :

// Router basique utilisant l'API History
class SPARouter {
  constructor(routes) {
    this.routes = routes;
    window.addEventListener('popstate', () => this.resolve());
  }

  navigate(path) {
    window.history.pushState({}, '', path);
    this.resolve();
  }

  resolve() {
    const path = window.location.pathname;
    const route = this.routes.find(r => r.path === path);

    if (route) {
      // Met à jour le DOM, le <title>, la meta description
      document.title = route.title;
      document.querySelector('meta[name="description"]')
        ?.setAttribute('content', route.description);
      document.getElementById('root').innerHTML = route.render();
    }
  }
}

// Utilisation
const router = new SPARouter([
  {
    path: '/chaussures/nike-air-max-90',
    title: 'Nike Air Max 90 - Livraison gratuite | ShopExample',
    description: 'Achetez la Nike Air Max 90 à partir de 129€...',
    render: () => renderProductPage('nike-air-max-90')
  }
]);

L'History API résout le problème des URLs. Mais elle ne résout pas le problème du contenu : au moment où Googlebot crawle /chaussures/nike-air-max-90, le serveur doit retourner quelque chose de pertinent — pas une coquille HTML vide qui attend l'exécution de bundle.js pour afficher du contenu.

Configuration serveur : le fallback qui piège les crawlers

Toute SPA avec l'History API nécessite que le serveur redirige toutes les routes vers index.html. C'est le fameux fallback. Voici la configuration Nginx typique :

server {
    listen 80;
    server_name shop.example.fr;
    root /var/www/shop/dist;

    # Fichiers statiques servis directement
    location ~* \.(js|css|png|jpg|webp|svg|woff2|ico)$ {
        expires 1y;
        add_header Cache-Control "public, immutable";
        try_files $uri =404;
    }

    # Toutes les autres requêtes -> index.html (SPA fallback)
    location / {
        try_files $uri $uri/ /index.html;
    }
}

Le piège : cette configuration renvoie un HTTP 200 avec le contenu de index.html pour toute URL, y compris celles qui n'existent pas. /chaussures/xyz-inexistant retourne un 200 avec la même coquille vide. Googlebot ne reçoit jamais de 404. Votre site signale à Google que des milliers d'URLs fantômes sont des pages valides. C'est la porte ouverte à l'index bloat.

La SPA doit gérer les 404 côté client ET côté serveur. Si le routing client détecte une URL inconnue, la réponse HTTP doit idéalement être un 404 — ce qui nécessite un minimum de logique serveur (SSR partiel, middleware, ou au minimum un fichier de routes connu côté serveur).

Les stratégies de rendering : SSR, SSG, ISR, prerendering dynamique

Le rendering côté serveur est la solution fondamentale au problème SPA + SEO. Mais "SSR" recouvre des réalités techniques très différentes.

Server-Side Rendering (SSR) complet

Le serveur exécute le JavaScript de votre SPA à chaque requête, génère le HTML complet, et l'envoie au client. Le navigateur reçoit une page avec du contenu visible, puis "hydrate" le JavaScript pour retrouver l'interactivité SPA.

C'est ce que font Next.js (React), Nuxt (Vue), et Angular Universal. Le HTML retourné ressemble à une page web classique :

<!DOCTYPE html>
<html lang="fr">
<head>
  <title>Nike Air Max 90 - Livraison gratuite | ShopExample</title>
  <meta name="description" content="Achetez la Nike Air Max 90 à partir de 129€. Livraison offerte dès 50€. Retours gratuits sous 30 jours.">
  <link rel="canonical" href="https://shop.example.fr/chaussures/nike-air-max-90">
  <script type="application/ld+json">
  {
    "@context": "https://schema.org",
    "@type": "Product",
    "name": "Nike Air Max 90",
    "offers": { "@type": "Offer", "price": "129.00", "priceCurrency": "EUR" }
  }
  </script>
</head>
<body>
  <div id="root">
    <header><!-- Navigation complète avec liens internes --></header>
    <main>
      <h1>Nike Air Max 90</h1>
      <p>La Air Max 90, iconique depuis 1990...</p>
      <!-- Tout le contenu produit est dans le HTML -->
    </main>
    <footer><!-- Liens catégories, mentions légales --></footer>
  </div>
  <script src="/static/js/bundle.7d8e9f.js" defer></script>
</body>
</html>

Googlebot voit immédiatement le contenu, les liens internes, les données structurées, la canonical, le title. Pas besoin d'attendre le WRS.

Le trade-off : chaque requête exécute du JavaScript côté serveur, ce qui augmente le TTFB (Time To First Byte). Sur un catalogue de 12 000 produits, les requêtes API vers la base de données s'ajoutent au temps de rendering. Un serveur Node.js mal dimensionné peut facilement atteindre 800ms-1.2s de TTFB sous charge, ce qui dégrade le LCP et donc les Core Web Vitals.

Static Site Generation (SSG) et Incremental Static Regeneration (ISR)

La SSG pré-génère toutes les pages au moment du build. Chaque page est un fichier HTML statique servi par CDN. Temps de réponse minimal, excellente crawlabilité.

Mais pour un catalogue e-commerce qui change quotidiennement (prix, stocks, nouveaux produits), rebâtir 12 000 pages à chaque modification est impraticable. C'est là qu'intervient l'ISR, introduite par Next.js : les pages sont générées statiquement, puis re-générées en arrière-plan selon un TTL configurable.

// Next.js App Router - page produit avec ISR
// app/produits/[slug]/page.tsx

import { notFound } from 'next/navigation';
import { getProduct, getAllProductSlugs } from '@/lib/api';
import type { Metadata } from 'next';

// Pré-génère les 500 produits les plus populaires au build
export async function generateStaticParams() {
  const slugs = await getAllProductSlugs({ limit: 500 });
  return slugs.map((slug) => ({ slug }));
}

// Meta tags dynamiques pour le SEO
export async function generateMetadata(
  { params }: { params: { slug: string } }
): Promise<Metadata> {
  const product = await getProduct(params.slug);
  if (!product) return {};

  return {
    title: `${product.name} - Dès ${product.price}€ | ShopExample`,
    description: product.metaDescription,
    alternates: {
      canonical: `https://shop.example.fr/produits/${params.slug}`,
    },
  };
}

export default async function ProductPage(
  { params }: { params: { slug: string } }
) {
  const product = await getProduct(params.slug);
  if (!product) notFound(); // Renvoie un vrai 404

  return (
    <main>
      <h1>{product.name}</h1>
      <p>{product.description}</p>
      {/* Contenu complet rendu côté serveur */}
    </main>
  );
}

// Revalidation toutes les 3600 secondes (1 heure)
export const revalidate = 3600;

Les 500 produits les plus populaires sont pré-générés. Les 11 500 restants sont générés à la première visite, puis mis en cache. Le notFound() garantit un vrai 404 HTTP pour les slugs invalides — pas de soft 404.

Cette approche est particulièrement adaptée aux sites où le ratio pages consultées / pages totales est très déséquilibré (loi de Pareto). Pour un site média avec 30 000 articles, pré-générer les 2 000 articles les plus récents et laisser l'ISR gérer l'archive est un bon compromis.

Prerendering dynamique (Dynamic Rendering)

Le dynamic rendering consiste à servir du HTML pré-rendu aux crawlers et la SPA classique aux utilisateurs. Google a explicitement documenté cette approche comme acceptable mais la qualifie de "workaround", pas de solution long terme.

En pratique, un service comme Prerender.io ou Rendertron intercepte les requêtes des bots (détectés via User-Agent), exécute le JavaScript dans un headless Chrome, et met en cache le HTML résultant.

# Configuration Nginx pour dynamic rendering via Prerender.io
map $http_user_agent $is_bot {
    default 0;
    ~*(googlebot|bingbot|yandex|baiduspider|facebookexternalhit|linkedinbot) 1;
}

server {
    listen 80;
    server_name shop.example.fr;

    location / {
        if ($is_bot = 1) {
            # Proxy vers le service de prerendering
            rewrite .* /https://shop.example.fr$request_uri break;
            proxy_pass https://service.prerender.io;
            proxy_set_header X-Prerender-Token YOUR_TOKEN;
        }

        # Utilisateurs humains : SPA classique
        try_files $uri $uri/ /index.html;
    }
}

Les limites du dynamic rendering sont réelles :

Cloaking potentiel : si le contenu pré-rendu diffère significativement de ce que l'utilisateur voit, Google peut considérer ça comme du cloaking. En théorie, le contenu doit être identique. En pratique, des dérives s'installent (contenu personnalisé, A/B tests, composants qui dépendent du viewport).
Coût de maintenance : vous maintenez deux pipelines de delivery. Quand le code de la SPA évolue, le cache de prerendering doit être invalidé.
Délai de cache : un produit ajouté à 9h sera visible pour les utilisateurs immédiatement, mais le crawler verra l'ancienne version en cache jusqu'à son expiration.

Le dynamic rendering reste pertinent dans un cas précis : vous avez une SPA existante en production, la migration vers SSR est planifiée mais va prendre 6 mois, et vous avez besoin d'une solution immédiate pour restaurer la visibilité organique. C'est un pansement — efficace, mais temporaire.

Audit technique : diagnostiquer les problèmes SEO d'une SPA existante

Avant de choisir une stratégie de rendering, il faut mesurer l'ampleur exacte du problème. Voici le workflow de diagnostic.

Étape 1 : comparer le HTML brut et le DOM rendu

Ouvrez Chrome DevTools, allez dans le panneau Network, et rechargez une page produit. Examinez la réponse HTTP brute (pas le DOM — la réponse réseau). Si le <body> ne contient que <div id="root"></div> et des <script>, vous avez un problème de rendering. Comparez avec le DOM dans l'onglet Elements après exécution JS.

En ligne de commande, curl vous donne exactement ce que Googlebot voit en phase 1 :

# HTML brut reçu par le crawler (pas de JS exécuté)
curl -s -A "Googlebot" https://shop.example.fr/chaussures/nike-air-max-90 | head -50

# Vérifier le status code (soft 404 ?)
curl -s -o /dev/null -w "%{http_code}" https://shop.example.fr/chaussures/url-qui-nexiste-pas

# Comparer le contenu rendu via un headless Chrome
npx puppeteer-cli screenshot --url https://shop.example.fr/chaussures/nike-air-max-90 --output rendered.png

Si le curl retourne 200 pour une URL inexistante, votre SPA a un problème de soft 404.

Étape 2 : Search Console — rapport de couverture et inspection d'URL

Dans Google Search Console, le rapport "Pages" (anciennement "Couverture") révèle trois signaux d'alerte propres aux SPA :

"Découverte, actuellement non indexée" en grande quantité : Googlebot a trouvé les URLs (probablement via le sitemap) mais ne les a pas encore rendues ou le rendering a échoué.
"Explorée, actuellement non indexée" : Googlebot a crawlé la page, le HTML était trop pauvre pour justifier l'indexation. C'est ce qui arrive quand le contenu est uniquement dans le JS.
"Page en double sans URL canonique sélectionnée par l'utilisateur" : toutes les pages retournent le même HTML vide, Google les considère comme des duplicatas.

L'outil d'inspection d'URL permet de voir le HTML rendu tel que Googlebot le perçoit après rendering. Comparez systématiquement le "HTML brut" et le "HTML rendu" pour vos pages stratégiques. Vous pouvez automatiser ce diagnostic via l'URL Inspection API.

Étape 3 : crawl avec Screaming Frog en mode JavaScript

Screaming Frog propose deux modes de crawl : "Text only" (HTML brut) et "JavaScript rendering" (exécute le JS via un Chrome embarqué). Crawlez votre site dans les deux modes et comparez :

Nombre de pages découvertes (les liens internes générés en JS sont invisibles en mode texte)
Titles et meta descriptions (souvent génériques ou vides en HTML brut)
Profondeur de crawl (sans liens internes dans le HTML, la structure est plate)
Taille du HTML (une page SPA client-side peut peser 500 octets en HTML brut vs 45 Ko après rendering)

Un delta important entre les deux modes confirme une dépendance excessive au JavaScript pour le contenu critique.

Scénario concret : migration d'une SPA React vers Next.js SSR

Prenons un cas réaliste. ShopExemple est un e-commerce mode avec 14 200 pages (8 400 fiches produit, 320 pages catégories, 5 480 pages de filtres à facettes). Le site tourne sur une SPA React (Create React App) avec React Router et client-side rendering pur.

Situation initiale (mesurée)

Pages indexées dans Google : 1 840 sur 14 200 (13 %)
Trafic organique : 12 400 sessions / mois (contre un potentiel estimé à 45 000+)
TTFB moyen : 120ms (HTML statique vide, très rapide mais inutile)
LCP moyen : 4.2s (tout le contenu chargé après exécution JS + appels API)
6 200 pages en statut "Découverte, actuellement non indexée" dans la Search Console
Le sitemap XML listait toutes les URLs mais Googlebot ne pouvait pas les rendre assez vite

Plan de migration

Migration vers Next.js App Router avec ISR (revalidate: 1800 pour les produits, revalidate: 86400 pour les catégories)
Pré-génération au build des 500 top produits et de toutes les catégories
Gestion stricte des 404 via notFound() pour tout slug invalide
Mapping des redirections 301 pour les URLs qui changent de structure (de /p/12345 vers /chaussures/nike-air-max-90)
Suppression des pages de filtres à facettes non pertinentes de l'index (5 480 pages réduites à 800 combinaisons utiles, le reste bloqué via noindex ou exclu du robots.txt)
Ajout de données structurées Product directement dans le HTML SSR

Résultats après 3 mois

Pages indexées : 9 200 (de 13 % à 65 % du total pertinent indexable de ~14 200 pages, les pages de filtres non stratégiques étant volontairement exclues)
Trafic organique : 38 600 sessions / mois (+211 %)
LCP moyen : 1.8s (le contenu est dans le HTML initial, les images en lazy loading pour le below-the-fold)
"Découverte, non indexée" : de 6 200 à 340 pages
CLS passé de 0.18 à 0.04 (l'hydration ne provoque plus de layout shifts grâce au HTML pré-rendu)

Le coût principal : 4 mois de développement, la gestion des chaînes de redirections héritées de l'ancienne structure d'URLs, et un plan de migration rigoureux pour ne pas perdre l'équité des liens existants.

Les pièges techniques qui persistent même avec SSR

Le passage à SSR ne résout pas tout automatiquement. Plusieurs pièges techniques subsistent.

Hydration mismatch et contenu divergent

Si le HTML généré côté serveur ne correspond pas exactement au DOM que React/Vue produisent côté client, le framework "corrige" le DOM pendant l'hydration. Cela peut provoquer un flash de contenu, un CLS élevé, et dans le pire cas, un contenu différent de ce que Googlebot a indexé.

Cas fréquent : un composant qui affiche "il y a 3 minutes" côté serveur (basé sur l'horloge du serveur) et "il y a 5 minutes" côté client (horloge du navigateur). Ou un prix formaté différemment selon la locale détectée. Testez systématiquement que le HTML SSR et le DOM hydraté sont identiques pour le contenu indexable.

Liens internes générés dynamiquement

Si votre navigation par catégories, votre fil d'Ariane (BreadcrumbList), ou vos liens de pagination sont chargés via des appels API après le rendering initial, ils sont invisibles pour Googlebot en phase 1. Même avec SSR, si le composant de navigation fait un useEffect + fetch pour charger les catégories, ces liens manquent du HTML initial.

Règle : tout lien interne critique pour le maillage doit être présent dans le HTML retourné par le serveur. Les données de navigation doivent être injectées dans le HTML SSR, pas chargées en async.

Le trailing slash et le routing SPA

Un point souvent négligé : la cohérence du trailing slash dans le routing SPA. Si Next.js génère /chaussures/nike-air-max-90 mais que votre CDN ou reverse proxy redirige vers /chaussures/nike-air-max-90/, chaque page a potentiellement deux URLs, diluant les signaux. Configurez trailingSlash: false (ou true) dans next.config.js et assurez-vous que le serveur, le sitemap, et les canonicals sont cohérents.

Gestion des états de chargement

Les skeletons screens et spinners sont d'excellents patterns UX. Mais si le SSR retourne un skeleton HTML (le composant rend un placeholder en attendant les données), c'est ce que Googlebot indexe. Le contenu réel n'apparaît qu'après hydration et fetch des données.

Chaque page dont le contenu dépend d'une API doit résoudre les données côté serveur AVANT de retourner le HTML. Dans Next.js App Router, c'est le comportement par défaut des Server Components. Dans le Pages Router, c'est getServerSideProps ou getStaticProps. Ne laissez jamais un useEffect charger du contenu critique qui devrait être dans le HTML initial.

Monitoring continu : détecter les régressions avant Google

Le problème avec les SPA en production : une mise à jour de code anodine peut casser le SSR sans que personne ne s'en aperçoive. Un nouveau composant qui utilise window (indisponible côté serveur) fait crasher le rendering. Le serveur bascule sur un fallback client-side. Le HTML redevient vide. Le trafic organique chute 2 à 4 semaines plus tard, quand Google a re-crawlé et désindexé les pages affectées.

La vérification manuelle n'est pas scalable. Vous n'allez pas curl 14 000 pages chaque jour. Ce qu'il faut :

Tests automatisés dans la CI/CD : un script qui vérifie que le HTML SSR de 20-50 pages stratégiques contient le <h1>, la meta description, le canonical, et les données structurées. Si un de ces éléments disparaît, le build échoue.
Monitoring synthétique : un outil de monitoring comme Seogard qui crawle régulièrement vos pages et alerte immédiatement quand une meta disparaît, quand le contenu SSR se vide, ou quand un status code change. La différence entre détecter une régression en 1 heure et la découvrir 3 semaines plus tard dans la Search Console, c'est la différence entre un hotfix et une perte de trafic de 40 %.
Comparaison HTML brut vs DOM rendu : surveillez le delta. Si le ratio de contenu textuel entre le HTML brut et le DOM rendu dépasse un certain seuil (par exemple, moins de 30 % du contenu final présent dans le HTML initial), c'est un signal d'alerte.

Croisez ces données avec le rapport "Exploration" de la Search Console et l'URL Inspection API pour confirmer que Google indexe effectivement ce que vous pensez lui servir.

Résumé actionable

Une SPA sans SSR est un site invisible pour Google. L'History API est un prérequis, pas une solution. Le rendering côté serveur (SSR, SSG ou ISR selon votre cas) est la seule approche durable pour garantir que le contenu, les liens internes, les metas et les données structurées sont dans le HTML au moment où Googlebot crawle.

Le vrai risque n'est pas la mise en place — c'est la régression silencieuse. Un SSR qui casse en production peut passer inaperçu pendant des semaines. Un monitoring technique continu, automatisé, qui compare le HTML servi à ce qu'il devrait être, est ce qui sépare les sites qui maintiennent leur visibilité organique de ceux qui la perdent par à-coups, sans comprendre pourquoi.