Caché y frescura del contenido

El SEO y la caché se cruzan en una pregunta: ¿con qué rapidez llegan los cambios de contenido al índice? Con la configuración por defecto del App Router, su corrección "publicada" puede pasar horas detrás de una caché caducada.

El patrón que funciona para sitios de contenido:

// Página: ISR con una ventana razonable
export const revalidate = 3600;

// Webhook desde el CMS → invalidación inmediata al publicar
// 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 });
}

Esto da la velocidad de una página estática (excelente para el LCP y el crawl budget) y frescura inmediata al publicar. El antipatrón es el extremo contrario: force-dynamic en todas partes "por si acaso"; paga el retraso del SSR en cada rastreo, y los rastreadores visitan con menos frecuencia cuando el TTFB es lento.

Las trampas de la caché del App Router son tantas que escribimos un análisis aparte: Cómo funciona la caché en Next.js v13+ con App Router.

Checklist:

• Páginas de contenido: ISR + revalidación por webhook, no force-dynamic
• Publicar en el CMS actualiza visiblemente la página en producción en segundos
• Cabeceras Cache-Control comprobadas en producción (curl -I), no supuestas