SEO и кеширование пересекаются в одном вопросе: как быстро изменения контента доезжают до индекса? С дефолтами App Router ваша «опубликованная» правка может часами сидеть за протухшим кешем.
Рабочий паттерн для контентных сайтов:
// Страница: ISR с разумным окном
export const revalidate = 3600;
// Вебхук из CMS → мгновенная инвалидация при публикации
// 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 });
}
Это даёт скорость статики (хорошо для LCP и краул-бюджета) и мгновенную свежесть при публикации. Антипаттерн — противоположный угол: force-dynamic везде «на всякий случай» — вы платите SSR-задержку на каждый обход, а краулеры ходят реже, когда TTFB медленный.
Ловушек в кешировании App Router достаточно, чтобы мы написали отдельный разбор: Как работает кеширование в Next.js v13+ с App Router.
Чеклист:
- Контентные страницы: ISR + вебхук-ревалидация, а не
force-dynamic - Публикация в CMS видимо обновляет живую страницу за секунды
- Заголовки
Cache-Controlпроверены в проде (curl -I), а не предполагаются