SEO und Caching treffen sich in einer Frage: Wie schnell gelangen Inhaltsänderungen in den Index? Mit den Standardeinstellungen des App Routers kann Ihre „veröffentlichte" Korrektur stundenlang hinter einem veralteten Cache hängen.
Ein Muster, das für Content-Websites funktioniert:
// Seite: ISR mit einem vernünftigen Zeitfenster
export const revalidate = 3600;
// Webhook aus dem CMS → sofortige Invalidierung bei der Veröffentlichung
// 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 });
}
Das liefert die Geschwindigkeit einer statischen Seite (gut für LCP und Crawl-Budget) und sofortige Aktualität bei der Veröffentlichung. Das Gegenmuster liegt in der anderen Ecke: force-dynamic überall „zur Sicherheit" – Sie zahlen bei jedem Crawl die SSR-Verzögerung, und Crawler kommen seltener, wenn die TTFB langsam ist.
Die Fallstricke im Cache des App Routers sind zahlreich genug, dass wir dazu eine eigene Analyse geschrieben haben: Wie der Cache in Next.js v13+ mit dem App Router funktioniert.
Checkliste:
- Inhaltsseiten: ISR + Revalidierung per Webhook statt
force-dynamic - Eine Veröffentlichung im CMS aktualisiert die Live-Seite sichtbar innerhalb von Sekunden
-
Cache-Control-Header in Produktion geprüft (curl -I), nicht nur angenommen