Redirecciones, 404 y códigos de respuesta

Los buscadores leen los códigos HTTP como instrucciones. Los códigos erróneos hacen fugar fuerza de enlaces o mantienen páginas muertas en el índice.

Traslados permanentes: en next.config.mjs (devuelve 308, que Google trata como un 301):

// next.config.mjs
export default {
  async redirects() {
    return [
      {
        source: "/old-blog/:slug",
        destination: "/blog/:slug",
        permanent: true,
      },
    ];
  },
};

Redirecciones en la aplicación: elija la función acorde con la semántica:

import { redirect, permanentRedirect, notFound } from "next/navigation";

// 307 — temporal (barreras de login, routing A/B)
redirect("/login");

// 308 — permanente (el slug cambió, la URL antigua debe transmitir la fuerza)
permanentRedirect(`/blog/${post.newSlug}`);

// Un 404 real con su UI desde not-found.tsx
if (!post) notFound();

Reglas de un índice limpio:

• Cero cadenas de redirecciones: antiguo → más antiguo → actual desperdicia crawl budget y diluye las señales. Redirija siempre directamente a la URL final.
• El contenido ausente devuelve 404, no una página de "no se ha encontrado nada" con código 200 (soft 404: Google los marca en Search Console).
• Elija una forma de URL y aplíquela: con barra final o sin ella (trailingSlash en la config), minúsculas, sin duplicados www/sin-www (redirección a nivel de edge/DNS).
• Si cambia un slug, añada la redirección en el mismo PR. La arqueología retroactiva de redirecciones no ocurre jamás.

¿Cambia de plataforma? El playbook completo (inventario, mapa de redirecciones, control de paridad y monitoreo del lanzamiento) está en el tema Migración SEO.

Checklist:

• Todas las direcciones antiguas redirigen 308/301 directamente a su destino (sin cadenas)
• Un not-found.tsx propio que de verdad devuelve 404
• Una única forma canónica de URL (barra, mayúsculas/minúsculas, host) en todo el sitio
• Un cambio de slug siempre va junto con su redirección