Les moteurs de recherche lisent les codes HTTP comme des instructions. De mauvais codes font fuir la puissance des liens ou maintiennent des pages mortes dans l'index.
Déplacements définitifs : dans next.config.mjs (renvoie une 308, traitée par Google comme une 301) :
// next.config.mjs
export default {
async redirects() {
return [
{
source: "/old-blog/:slug",
destination: "/blog/:slug",
permanent: true,
},
];
},
};
Redirections dans l'application : choisissez la fonction qui correspond à la sémantique :
import { redirect, permanentRedirect, notFound } from "next/navigation";
// 307 — temporaire (portes de connexion, routage A/B)
redirect("/login");
// 308 — définitive (le slug a changé, l'ancienne URL doit transmettre sa puissance)
permanentRedirect(`/blog/${post.newSlug}`);
// Une vraie 404 avec votre UI issue de not-found.tsx
if (!post) notFound();
Règles d'un index propre :
- Zéro chaîne de redirections : ancien → plus ancien → actuel gaspille du budget de crawl et dilue les signaux. Redirigez toujours directement vers l'URL finale.
- Un contenu manquant renvoie une 404, et non une page « rien trouvé » avec un code 200 (soft 404 : Google les signale dans la Search Console).
- Choisissez une seule forme d'URL et imposez-la : avec ou sans barre oblique finale (
trailingSlashdans la config), minuscules, pas de doublons www/sans-www (redirection au niveau edge/DNS). - Vous changez un slug ? Ajoutez la redirection dans la même PR. L'archéologie rétroactive des redirections n'arrive jamais.
Vous changez de plateforme ? Le playbook complet (inventaire, table de redirections, contrôle de parité et suivi du lancement) se trouve dans le sujet Migration SEO.
Checklist :
- Toutes les anciennes adresses redirigent en 308/301 directement vers leur destination (sans chaînes)
- Un
not-found.tsxpersonnalisé qui renvoie réellement une 404 - Une seule forme canonique d'URL (barre oblique, casse, hôte) sur tout le site
- Un changement de slug part toujours avec sa redirection
