Cache i świeżość treści

SEO i cache przecinają się w jednym pytaniu: jak szybko zmiany treści docierają do indeksu? Z domyślnymi ustawieniami App Routera twoja „opublikowana" poprawka może godzinami siedzieć za przeterminowanym cache.

Wzorzec, który działa dla witryn contentowych:

// Strona: ISR z rozsądnym oknem
export const revalidate = 3600;

// Webhook z CMS → natychmiastowa inwalidacja przy publikacji
// 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 });
}

To daje prędkość strony statycznej (świetne dla LCP i crawl budgetu) oraz natychmiastową świeżość przy publikacji. Antywzorzec to przeciwny róg: force-dynamic wszędzie „na wszelki wypadek" — płacisz opóźnienie SSR przy każdym crawlu, a crawlery odwiedzają rzadziej, gdy TTFB jest wolny.

Pułapek w cache App Routera jest dość, że napisaliśmy osobną analizę: Jak działa cache w Next.js v13+ z App Routerem.

Checklista:

• Strony contentowe: ISR + rewalidacja webhookiem, a nie force-dynamic
• Publikacja w CMS widocznie aktualizuje żywą stronę w sekundy
• Nagłówki Cache-Control sprawdzone na produkcji (curl -I), a nie zakładane