SEO en cache kruisen elkaar bij één vraag: hoe snel komen contentwijzigingen in de index terecht? Met de standaardinstellingen van de App Router kan je "gepubliceerde" fix urenlang achter een verouderde cache zitten.
Het patroon dat werkt voor contentsites:
// Pagina: ISR met een redelijk venster
export const revalidate = 3600;
// Webhook vanuit het CMS → directe invalidatie bij publicatie
// 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 });
}
Dat geeft de snelheid van een statische pagina (top voor LCP en crawlbudget) en directe versheid bij publicatie. Het antipatroon is de tegenovergestelde hoek: overal force-dynamic "voor de zekerheid". Dan betaal je SSR-vertraging bij elke crawl, en crawlers komen minder vaak langs als de TTFB traag is.
De cache van de App Router heeft genoeg valkuilen voor een aparte analyse: Hoe de cache in Next.js v13+ met de App Router werkt.
Checklist:
- Contentpagina's: ISR + revalidatie via webhook, geen
force-dynamic - Een publicatie in het CMS werkt de live pagina zichtbaar binnen seconden bij
-
Cache-Control-headers in productie gecontroleerd (curl -I), niet aangenomen