Un catalogue e-commerce de 23 000 fiches produits, construit en Angular SPA. Taux d'indexation : 14 %. Après mise en place du prerendering sur les routes produits et catégories, le taux monte à 89 % en six semaines. Ce n'est pas un cas théorique — c'est le type exact de scénario où le prerendering transforme la visibilité organique d'un site sans imposer une réécriture complète du front.
Ce que prerendering signifie réellement (et ce qu'il n'est pas)
Le terme "prerendering" est utilisé dans au moins trois contextes différents, et la confusion entre eux cause des erreurs d'architecture coûteuses.
Prerendering au sens SEO : générer du HTML statique à l'avance
Dans le contexte du référencement, le prerendering désigne le fait de générer le HTML complet d'une page avant qu'un utilisateur ou un crawler ne la demande. Le résultat est un fichier HTML statique ou quasi-statique, servi directement par le serveur, sans exécution JavaScript côté client nécessaire pour afficher le contenu principal.
C'est fondamentalement différent du SSR (Server-Side Rendering), où le HTML est généré à chaque requête. Et c'est fondamentalement différent du CSR (Client-Side Rendering), où le HTML est une coquille vide que JavaScript doit remplir.
Prerendering au sens navigateur : l'API Speculation Rules
Chrome propose une API Speculation Rules (anciennement <link rel="prerender">) qui permet au navigateur de charger et rendre une page en arrière-plan avant que l'utilisateur ne clique. Ce mécanisme concerne la performance perçue, pas le SEO. Ne confondez pas les deux.
Prerendering via service tiers (Prerender.io, Rendertron)
Un proxy intercepte les requêtes des crawlers (détectés par User-Agent), exécute le JavaScript dans un headless browser, puis sert le HTML résultant. Cette approche est souvent appelée "dynamic rendering" — Google la documente comme une solution transitoire, pas comme une solution pérenne.
La distinction est critique pour vos choix d'architecture. Ce qui suit couvre les trois approches, avec les cas où chacune est pertinente.
Quand le prerendering est le bon choix (et quand il ne l'est pas)
Le prerendering n'est pas une solution universelle. Voici une grille de décision basée sur des critères techniques concrets.
Le prerendering statique est idéal quand :
Le contenu change rarement. Pages produits avec mise à jour hebdomadaire, articles de blog, pages institutionnelles, documentation technique. Si le contenu peut être périmé de quelques minutes (ou heures) sans conséquence business, le prerendering statique est optimal.
Le nombre de pages est gérable. En dessous de 50 000 pages, la génération statique au build reste viable avec les frameworks modernes. Au-delà, les temps de build deviennent problématiques — c'est exactement pour ça que l'ISR existe comme compromis.
Vous êtes sur une SPA que vous ne pouvez pas réécrire. C'est le cas le plus fréquent en entreprise. Un front Angular ou React "pur" (sans framework de rendering serveur) avec des centaines de milliers de lignes de code. Réécrire en Next.js coûterait 6 à 18 mois. Le prerendering via service tiers ou au build est alors le chemin le plus pragmatique.
Le prerendering est un mauvais choix quand :
Le contenu est hautement dynamique. Un fil d'actualité en temps réel, un dashboard, une page de résultats de recherche interne avec des milliers de combinaisons de filtres — le prerendering ne peut pas suivre le rythme des changements. Le SSR est alors nécessaire.
Le contenu est personnalisé par utilisateur. Pages avec prix négociés, recommandations personnalisées dans le contenu principal (pas dans un widget latéral). Le prerendering sert le même HTML à tout le monde — si le contenu personnalisé fait partie de ce que Google doit indexer, ça ne fonctionne pas.
Vous avez déjà un framework SSR en place. Si vous êtes déjà sur Next.js, Nuxt ou SvelteKit avec du SSR fonctionnel, ajouter une couche de prerendering est redondant et introduit de la complexité inutile.
Implémentation avec les frameworks modernes
Next.js : Static Generation et ISR
Next.js distingue clairement le prerendering statique (SSG) du rendu serveur. Depuis l'App Router (Next.js 13+), le comportement par défaut est le rendu statique — sauf si vous utilisez des fonctions dynamiques.
Pour une page produit d'un e-commerce de 15 000 références, voici l'approche avec generateStaticParams :
// app/produits/[slug]/page.tsx
import { getProduct, getAllProductSlugs } from '@/lib/api';
import { notFound } from 'next/navigation';
import type { Metadata } from 'next';
// Génère les paths statiques au build
export async function generateStaticParams() {
const slugs = await getAllProductSlugs();
// Sur 15K produits, on peut pré-générer les top 2000
// et laisser les autres se générer à la première visite
return slugs.slice(0, 2000).map((slug) => ({ slug }));
}
// Metadata dynamique pour chaque produit
export async function generateMetadata({
params
}: {
params: { slug: string }
}): Promise<Metadata> {
const product = await getProduct(params.slug);
if (!product) return {};
return {
title: `${product.name} - ${product.brand} | MonSite`,
description: product.metaDescription,
alternates: {
canonical: `https://monsite.fr/produits/${params.slug}`,
},
};
}
// Revalidation ISR : la page est regénérée en arrière-plan
// après 3600 secondes (1h) si une requête arrive
export const revalidate = 3600;
export default async function ProductPage({
params
}: {
params: { slug: string }
}) {
const product = await getProduct(params.slug);
if (!product) notFound();
return (
<main>
<h1>{product.name}</h1>
<script
type="application/ld+json"
dangerouslySetInnerHTML={{
__html: JSON.stringify({
'@context': 'https://schema.org',
'@type': 'Product',
name: product.name,
description: product.description,
sku: product.sku,
offers: {
'@type': 'Offer',
price: product.price,
priceCurrency: 'EUR',
availability: product.inStock
? 'https://schema.org/InStock'
: 'https://schema.org/OutOfStock',
},
}),
}}
/>
{/* Reste du composant */}
</main>
);
}Points clés de cette implémentation :
generateStaticParamsne pré-génère que les 2 000 produits les plus importants (top sellers, pages avec le plus de backlinks). Les 13 000 autres sont générés à la première visite puis cachés — c'est le comportement par défaut de Next.js avecdynamicParams = true.revalidate = 3600active l'ISR : après une heure, la prochaine requête sert le cache existant et déclenche une régénération en arrière-plan. Le crawler Google reçoit toujours un HTML complet, jamais une page en loading.- Les données structurées sont injectées dans le HTML statique — elles sont donc visibles au crawl sans exécution JavaScript.
Nuxt 3 : route rules et rendu hybride
Nuxt 3 permet un contrôle granulaire du mode de rendering par route via routeRules. C'est particulièrement adapté aux sites qui mélangent des sections statiques (blog, pages catégories) et des sections dynamiques (espace client, panier).
// nuxt.config.ts
export default defineNuxtConfig({
routeRules: {
// Pages catégories : prerendered au build
'/categorie/**': { prerender: true },
// Pages produits : ISR avec revalidation toutes les 2h
'/produit/**': {
isr: 7200,
headers: { 'Cache-Control': 'public, max-age=7200, stale-while-revalidate=86400' }
},
// Blog : full static, régénéré uniquement au redéploiement
'/blog/**': { prerender: true },
// Espace client : SSR pur, jamais caché côté CDN
'/compte/**': { ssr: true, headers: { 'Cache-Control': 'private, no-store' } },
// API : pas de prerendering
'/api/**': { cors: true },
},
// Génère la liste des routes à prerender
nitro: {
prerender: {
// Crawle automatiquement les liens internes à partir de la homepage
crawlLinks: true,
routes: ['/sitemap.xml', '/'],
},
},
});L'option crawlLinks: true est remarquablement utile : Nitro (le moteur serveur de Nuxt) parcourt les liens internes à partir des routes de départ et pré-génère automatiquement toutes les pages atteignables. Pas besoin de maintenir manuellement une liste de 15 000 URLs.
SPA existante + Prerender.io : l'approche pragmatique
Quand réécrire n'est pas une option, un service de prerendering externe reste la meilleure solution à court terme. Voici la configuration Nginx pour router les crawlers vers Prerender.io tout en servant la SPA aux utilisateurs :
server {
listen 443 ssl http2;
server_name monsite.fr;
# Détection des crawlers par User-Agent
set $prerender 0;
if ($http_user_agent ~* "googlebot|bingbot|yandex|baiduspider|facebookexternalhit|twitterbot|linkedinbot|slurp") {
set $prerender 1;
}
# Ne pas prerender les fichiers statiques
if ($uri ~* "\.(js|css|xml|less|png|jpg|jpeg|gif|pdf|txt|ico|rss|zip|mp3|rar|exe|wmv|doc|avi|ppt|mpg|mpeg|tif|wav|mov|psd|ai|xls|mp4|m4a|swf|dat|dmg|iso|flv|m4v|torrent|ttf|woff|woff2|svg|eot)$") {
set $prerender 0;
}
# Ne pas prerender les appels API
if ($uri ~* "^/api/") {
set $prerender 0;
}
location / {
if ($prerender = 1) {
rewrite (.*) /https://monsite.fr$1 break;
proxy_pass https://service.prerender.io;
proxy_set_header X-Prerender-Token VOTRE_TOKEN_ICI;
proxy_set_header X-Prerender-Int-Type SEO;
}
# SPA classique pour les utilisateurs
try_files $uri $uri/ /index.html;
}
}Cette configuration a un défaut majeur connu : elle repose sur la détection d'User-Agent, ce qui constitue techniquement du cloaking. Google tolère cette approche tant que le contenu servi aux crawlers est identique à celui que les utilisateurs voient après exécution JavaScript. Mais c'est un terrain glissant — si le contenu diverge (prix différent, texte supplémentaire, liens absents), vous risquez une action manuelle.
Le scénario complet : migration d'une SPA Angular vers le prerendering
Contexte réaliste : un site e-commerce spécialisé en équipement de bureau, 23 000 pages (produits, catégories, guides d'achat), construit en Angular 14 en CSR pur. Trafic organique : 8 200 sessions/mois — anormalement bas pour un catalogue de cette taille.
Diagnostic initial
En inspectant le site avec Screaming Frog configuré en mode "JavaScript Rendering", puis en comparant avec un crawl en mode "Text Only" :
- Mode Text Only : 94 % des pages retournent un
<div id="app"></div>vide. Aucun<title>distinct, aucune<meta description>— Angular les injecte dynamiquement. - Mode JavaScript : les pages s'affichent correctement après 3 à 8 secondes de rendering.
Dans Google Search Console, l'onglet "Pages" confirme : 19 400 pages "Discovered - currently not indexed" ou "Crawled - currently not indexed". Google découvre les URLs via le sitemap mais ne parvient pas (ou ne prend pas la peine) de les indexer après rendering JavaScript.
Le problème de fond : Googlebot peut exécuter JavaScript, mais il le fait dans une file d'attente séparée (le Web Rendering Service). Pour un site de 23 000 pages sans autorité exceptionnelle, le crawl budget alloué au rendering JavaScript est insuffisant pour tout indexer. C'est exactement le cas documenté dans notre analyse sur pourquoi Google voit une page blanche sur votre SPA.
Choix de la solution
Trois options évaluées :
- Réécriture en Angular Universal (SSR) : estimation 4 mois de développement. Risques d'hydration mismatch sur les composants complexes du configurateur produit.
- Migration vers Next.js : estimation 8-12 mois. Solution idéale à long terme, irréaliste à court terme.
- Prerender.io + optimisation du build Angular : 2 semaines de mise en place. Solution immédiate.
Le choix s'est porté sur l'option 3 comme solution à court terme, avec l'option 1 planifiée pour le trimestre suivant.
Résultats mesurés
Semaine 1-2 : mise en place de Prerender.io avec la config Nginx ci-dessus. Coût : environ 80 $/mois pour 23 000 pages en cache.
Semaine 3 : vérification dans Search Console. Les rapports d'indexation montrent une augmentation progressive. Inspection URL sur 50 pages échantillon → toutes retournent un HTML complet avec <title>, <meta description>, et contenu visible.
Semaine 6 : 20 500 pages indexées (contre 3 200 avant). Trafic organique : 14 800 sessions/mois (+80 %).
Semaine 12 : stabilisation à 21 200 pages indexées. Trafic : 22 400 sessions/mois. Les pages catégories, qui agrègent des liens internes, bénéficient massivement de l'indexation des pages produits.
Le gain de trafic ne vient pas d'une "amélioration du ranking" — il vient simplement du fait que des pages qui n'existaient pas pour Google existent maintenant.
Pièges techniques et edge cases
Le piège du cache périmé
Avec un service comme Prerender.io, le HTML est mis en cache. Si vous modifiez un prix produit ou une fiche, le cache peut servir l'ancien prix pendant des heures (ou des jours, selon la config). Solutions :
- Configurez un webhook qui invalide le cache Prerender.io à chaque mise à jour produit dans votre CMS ou PIM.
- Utilisez l'API de recache de Prerender.io :
POST https://api.prerender.io/recacheavec l'URL à rafraîchir. - Surveillez les divergences entre le HTML caché servi aux crawlers et le contenu réel. Un outil de monitoring comme SEOGard peut détecter automatiquement quand le contenu servi aux bots diverge du contenu client, signalant un cache périmé avant que Google ne voie des informations obsolètes.
Les canonical et hreflang mal gérés
Un problème fréquent avec le prerendering via proxy : les balises <link rel="canonical"> et hreflang sont souvent injectées par JavaScript côté client. Si le service de prerendering met en cache une version de la page avant que ces balises soient injectées (timeout trop court), vous obtenez des pages sans canonical — ou pire, avec un canonical générique pointant vers la homepage.
Vérifiez systématiquement avec curl que le HTML prerendered contient bien vos balises critiques :
# Simuler un crawl Googlebot sur une page prerendered
curl -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
-s https://monsite.fr/produit/chaise-ergonomique-x500 | \
grep -E "(canonical|hreflang|<title>|meta name=\"description\")"Si la sortie est vide ou incorrecte, le problème vient du timing de rendering du service de prerendering. Augmentez le renderAfter (délai d'attente avant capture du DOM) ou, mieux, migrez ces balises dans le HTML initial servi par le serveur plutôt que de les injecter en JavaScript.
Le cloaking involontaire
Le dynamic rendering est par nature une forme de différenciation du contenu basé sur l'User-Agent. La frontière avec le cloaking est mince. Règles strictes :
- Le contenu textuel, les liens et les images servis aux crawlers doivent être identiques à ceux visibles par les utilisateurs après chargement JavaScript.
- Les éléments interactifs (modals, onglets, accordéons) peuvent différer dans leur état initial — Google s'attend à recevoir le contenu des onglets dépliés dans le HTML prerendered.
- Les prix, disponibilités et autres données commerciales doivent être synchronisés. Un décalage de quelques minutes est tolérable ; un décalage de plusieurs jours ne l'est pas.
Testez régulièrement avec l'outil d'inspection d'URL de Search Console (qui montre ce que Google voit) et comparez avec Chrome DevTools côté utilisateur.
Le cas des pages à paramètres d'URL
Les pages à facettes (/categorie/chaises?couleur=noir&materiau=cuir) posent un problème spécifique : le nombre de combinaisons explose. Si votre service de prerendering tente de cacher chaque combinaison, vous vous retrouvez avec des dizaines de milliers de variantes en cache, des coûts qui explosent, et du contenu dupliqué.
La règle : ne prerendez que les URLs que vous voulez voir indexées. Pour les facettes, cela signifie généralement uniquement les combinaisons à un seul filtre qui ont un volume de recherche, et un <link rel="canonical"> vers la page catégorie parente pour toutes les autres.
Mesurer l'impact et monitorer dans la durée
Le prerendering n'est pas un "set and forget". Trois métriques à suivre :
Taux d'indexation : dans Google Search Console, suivez le ratio pages indexées / pages soumises dans le sitemap. Un taux qui chute brutalement après plusieurs semaines de stabilité indique un problème de prerendering (service down, cache corrompu, modification de la config serveur).
Couverture des balises critiques : vérifiez régulièrement que 100 % des pages prerendered contiennent un <title> unique, une <meta description>, un canonical correct. Un crawl Screaming Frog en mode "Text Only" sur le User-Agent Googlebot vous donne cette vue. Si vous gérez un site à plus de 10 000 pages, un monitoring automatisé avec SEOGard détecte ces régressions en moins de 24 h — sans attendre le prochain audit trimestriel.
Temps de réponse pour les crawlers : le HTML prerendered doit être servi en moins de 500 ms. Si votre service de prerendering ajoute 2-3 secondes de latence, Googlebot peut throttle le crawl — exactement l'inverse de l'effet recherché. Monitorez avec les logs serveur ou le rapport "Exploration" de Search Console.
Comparer avant/après avec Search Console
L'onglet "Performances" de Search Console ne montre pas directement l'impact du prerendering. Ce que vous cherchez :
- Augmentation des impressions sur les pages qui étaient précédemment non indexées. Filtrez par URL contenant
/produit/(ou votre pattern) et comparez les 4 semaines avant/après activation. - Augmentation des pages avec clics > 0 : une page indexée qui ne génère aucun clic n'a pas de valeur SEO. Surveillez la distribution.
- Diminution des erreurs d'exploration : dans le rapport de couverture, les erreurs "Soft 404" et "Crawled - currently not indexed" doivent diminuer.
Quand passer du prerendering tiers à une vraie solution SSR/SSG
Le prerendering via service tiers (Prerender.io, Rendertron) est une solution de transition. Les signaux indiquant qu'il est temps de migrer :
- Les coûts du service dépassent 300-500 $/mois (seuil où un investissement en architecture devient rentable).
- Vous constatez des divergences fréquentes entre le contenu caché et le contenu réel, malgré une gestion rigoureuse du cache.
- Google a explicitement qualifié le dynamic rendering de "workaround" dans sa documentation officielle, et rien ne garantit que cette tolérance sera éternelle.
- Vos besoins en Core Web Vitals augmentent : le prerendering résout le problème de crawl, mais pas celui de la performance utilisateur. Un vrai SSR/SSG avec hydratation optimisée améliore LCP et FID là où le prerendering ne change rien pour l'utilisateur.
La migration vers un framework avec rendering hybride (Next.js, Nuxt 3, SvelteKit) reste l'objectif à moyen terme. Le prerendering vous achète du temps — et du trafic — en attendant.
Le prerendering est l'outil le plus sous-estimé pour débloquer l'indexation des SPA à grande échelle. La clé est de le traiter comme une infrastructure critique — avec du monitoring, de la validation automatisée et un plan de migration vers une architecture de rendering native.