SEO Programmatique : Le Guide Technique pour Déployer à Grande Échelle

Le choix du framework de rendu n’est pas anodin en SEO programmatique. Sur des volumes importants, la différence entre un rendu client-side (React classique) et un Server-Side Rendering ou Static Site Generation se mesure directement dans le budget crawl et dans les scores Core Web Vitals.

Pourquoi le SSR/SSG est critique pour Googlebot : un rendu entièrement client-side oblige le Googlebot à exécuter JavaScript pour voir le contenu. Ce second passage de rendu consomme du budget crawl et introduit des délais d’indexation. Avec le SSR, la page HTML complète est servie au premier appel — Googlebot ne doit rien exécuter.

Next.js s’est imposé comme le standard pour ce type de projet. Sa fonction getStaticProps permet de générer statiquement des milliers de pages à partir d’une base de données au moment du build :

// pages/[category]/[location]/[slug].js

export async function getStaticProps({ params }) {
  const { category, location, slug } = params;

  // Requête PostgreSQL via l'API interne
  const page = await db.query(
    `SELECT * FROM pages_seo WHERE slug = $1 AND status = 'published'`,
    [`${category}-${location}-${slug}`]
  );

  if (!page.rows[0]) return { notFound: true };

  return {
    props:      { pageData: page.rows[0] },
    revalidate: 86400 // ISR : revalidation toutes les 24h
  };
}

export async function getStaticPaths() {
  const pages = await db.query(
    `SELECT category, location, slug FROM pages_seo WHERE status = 'published' LIMIT 10000`
  );

  return {
    paths: pages.rows.map(p => ({
      params: { category: p.category, location: p.location, slug: p.slug }
    })),
    fallback: 'blocking' // SSR pour les pages non pré-générées
  };
}

L’option fallback: ‘blocking’ est particulièrement utile pour les très grands volumes : vous pré-générez statiquement les 10 000 pages les plus importantes, et les autres sont rendues en SSR à la première requête puis mises en cache. C’est ce qu’on appelle l’Incremental Static Regeneration (ISR) — un compromis optimal entre performance et coût de build.

Pour les Core Web Vitals, l’architecture CDN edge est déterminante sur les pages programmatiques. Un TTFB (Time to First Byte) inférieur à 200ms est atteignable avec cette stack, même sur des pages générées dynamiquement.