Cache et fraîcheur du contenu

Le SEO et le cache se rejoignent sur une question : à quelle vitesse les changements de contenu atteignent-ils l'index ? Avec les réglages par défaut de l'App Router, votre correction « publiée » peut rester des heures derrière un cache périmé.

Le schéma qui fonctionne pour les sites de contenu :

// Page : ISR avec une fenêtre raisonnable
export const revalidate = 3600;

// Webhook depuis le CMS → invalidation immédiate à la publication
// app/api/revalidate/route.ts
import { revalidatePath } from "next/cache";

export async function POST(request: Request) {
  const { slug, secret } = await request.json();
  if (secret !== process.env.REVALIDATE_SECRET) {
    return Response.json({ ok: false }, { status: 401 });
  }
  revalidatePath(`/blog/${slug}`);
  return Response.json({ ok: true });
}

Cela donne la vitesse d'une page statique (excellent pour le LCP et le budget de crawl) et une fraîcheur instantanée à la publication. L'anti-schéma est le coin opposé : force-dynamic partout « au cas où ». Vous payez la latence du SSR à chaque exploration, et les robots reviennent moins souvent quand le TTFB est lent.

Les pièges du cache de l'App Router sont assez nombreux pour que nous en ayons fait une analyse à part : Comment fonctionne le cache dans Next.js v13+ avec l'App Router.

Checklist :

• Pages de contenu : ISR + revalidation par webhook, et non force-dynamic
• Une publication dans le CMS met visiblement à jour la page en ligne en quelques secondes
• En-têtes Cache-Control vérifiés en production (curl -I), et non supposés