Page 404 personnalisée : bien la configurer et la mettre en place

Lorsqu'un internaute suit un lien cassé, le serveur doit renvoyer un statut 404 Not Found. Pourtant, dans les projets réels, cette règle est souvent violée : le CMS renvoie 200 OK, une redirection mène à la page d'accueil, ou la page « 404 » renvoie le bon code mais s'affiche comme un écran blanc. Chacune de ces situations pose un problème distinct, pour le SEO comme pour l'utilisateur.

Une page 404 bien configurée résout trois problèmes à la fois : elle signale à Google que l'URL n'existe pas, elle garde l'internaute sur le site et l'aide à trouver la bonne rubrique, et elle protège le budget de crawl des passages inutiles. Reprenons chaque aspect dans l'ordre.

Qu'est-ce qu'une page 404

404 Not Found est le code de réponse HTTP qu'un serveur renvoie lorsque la ressource demandée n'existe pas. Ce code signifie que le serveur fonctionne et que la route a bien été résolue, mais que le document demandé est absent. C'est ce qui distingue le 404 du 500 (erreur serveur) et du 503 (service indisponible).

Une page 404 existe à deux niveaux. Le niveau HTTP est le code de réponse dans l'en-tête, celui que voit le crawler. Le niveau visuel est le contenu HTML que voit l'internaute. Les deux comptent autant : un mauvais code HTTP relève du SEO, un design médiocre relève de l'UX.

La règle principale : toujours renvoyer un HTTP 404

La première règle, la plus importante : une page d'erreur doit renvoyer le statut HTTP 404 (ou 410), jamais 200. C'est ce qu'on appelle une « hard 404 », par opposition à la « soft 404 ».

Vous pouvez vérifier le statut HTTP de n'importe quelle page directement dans le navigateur : F12 → Network → rechargez la page → repérez la première requête → colonne Status. Ou via curl dans le terminal :

# Check HTTP status of a page
curl -s -o /dev/null -w "%{http_code}" https://example.com/non-existent-url
# Expected output: 404

# Check full response headers
curl -I https://example.com/non-existent-url

Soft 404 et 410 : la différence

Au-delà de la « hard 404 », deux cas voisins sont souvent confondus en pratique : la soft 404 et le statut 410. Bien distinguer les deux est important pour gérer correctement les pages supprimées.

Google classe aussi comme soft 404 toute redirection d'une URL en 404 vers la page d'accueil ou vers une autre page sans rapport. Du point de vue du moteur, l'internaute cherchait A, il arrive sur B, et le contenu de B ne répond pas à sa requête. Cela dégrade le signal de qualité de la page de destination.

Ce que doit contenir une bonne page 404

Un internaute qui arrive sur une 404 est déjà un peu frustré. La page doit dissiper cette frustration et lui proposer une étape suivante claire. Une page 404 efficace suit une structure reconnaissable.

zoom_in

À éviter sur une page 404 : rediriger automatiquement l'internaute vers la page d'accueil en JavaScript (window.location.href = '/'). Google peut y voir une soft 404 : l'internaute attendait A, il reçoit B, dont le contenu n'a aucun rapport. Les redirections 301 au niveau serveur depuis des URL en 404 ne se justifient que lorsqu'une vraie page de remplacement existe.

Mise en œuvre : Next.js, Nginx, Apache

La configuration d'une page 404 personnalisée dépend de votre stack. Voici les trois configurations les plus courantes : Next.js App Router, Nginx et Apache.

Next.js App Router

Dans Next.js 13+ avec App Router, une page 404 personnalisée se crée avec un fichier not-found.tsx dans le dossier app/. Pour l'i18n (par exemple avec next-intl), le fichier se place dans app/[locale]/.

// app/[locale]/not-found.tsx
import Link from 'next/link';

export default function NotFound() {
  return (
    <main style={{ textAlign: 'center', padding: '4rem 1rem' }}>
      <h1>404 — Page Not Found</h1>
      <p>The link may be outdated or the address was mistyped.</p>
      <Link href="/">Back to homepage</Link>
    </main>
  );
}

// Next.js automatically returns HTTP 404 for this file.

Pour générer une 404 de façon programmatique (par exemple dans une route dynamique app/[locale]/blog/[slug]/page.tsx), utilisez la fonction notFound() de next/navigation. Son appel interrompt immédiatement le rendu, renvoie un HTTP 404 et affiche not-found.tsx.

// app/[locale]/blog/[slug]/page.tsx
import { notFound } from 'next/navigation';
import { getArticleDoc } from '@/messages/blog-articles/registry';

export default async function ArticlePage({ params }: { params: { slug: string } }) {
  const article = getArticleDoc(params.slug);

  // If slug does not exist — return HTTP 404 and render not-found.tsx
  if (!article) {
    notFound();
  }

  return <ArticleRenderer article={article} />;
}

// Pages Router: pages/blog/[slug].tsx (legacy approach)
export async function getServerSideProps({ params }) {
  const article = getArticleDoc(params.slug);

  if (!article) {
    // Next.js will return HTTP 404 and show pages/404.tsx
    return { notFound: true };
  }

  return { props: { article } };
}

Nginx

Dans Nginx, la page 404 personnalisée se configure avec la directive error_page dans le bloc server. Vérifiez que le fichier 404.html existe au chemin indiqué et que sa diffusion ne déclenche pas de redirection interne vers un code 200.

server {
    listen 80;
    server_name example.com;
    root /var/www/html;

    # Custom page for 404 errors
    error_page 404 /404.html;

    # The location for the file itself — returns 404, not 200
    location = /404.html {
        internal;
    }

    # Custom pages for other errors
    error_page 500 502 503 504 /50x.html;
    location = /50x.html {
        internal;
    }
}

Apache / .htaccess

Sous Apache, la 404 personnalisée se configure avec ErrorDocument, soit dans la configuration principale, soit dans .htaccess.

# .htaccess in the site root

# Custom 404 page
ErrorDocument 404 /404.html

# You can also point to a PHP file
# ErrorDocument 404 /404.php

# Custom pages for other errors
ErrorDocument 403 /403.html
ErrorDocument 500 /500.html

# Enable mod_rewrite for SPA routing
<IfModule mod_rewrite.c>
    RewriteEngine On
    # For React/Vue SPA: all non-existent routes → index.html
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule ^ /index.html [L]
</IfModule>

PHP (WordPress et autres CMS)

Dans WordPress, la page 404 personnalisée est le fichier 404.php de votre thème. WordPress renvoie automatiquement un HTTP 404 pour les URL inexistantes, à condition que les permaliens soient bien configurés. Si le CMS renvoie 200 au lieu de 404, le problème vient généralement du .htaccess ou de la configuration du serveur.

<?php
// themes/your-theme/404.php
// WordPress automatically returns HTTP 404
get_header();
?>
<main class="error-404">
    <h1>Page Not Found</h1>
    <p>Try using search:</p>
    <?php get_search_form(); ?>
    <p>Or return to the <a href="<?php echo home_url(); ?>">homepage</a>.</p>
</main>
<?php
get_footer();

Repérer et corriger les liens cassés

Une page 404 bien configurée ne représente que la moitié du travail. L'autre moitié consiste à repérer tous les liens qui pointent vers des pages inexistantes, puis à les traiter. Les liens cassés sont la principale cause des erreurs 404 présentes dans l'index.

# Find top-20 broken URLs in Nginx/Apache logs
grep ' 404 ' /var/log/nginx/access.log \
  | awk '{print $7}' \
  | sort \
  | uniq -c \
  | sort -rn \
  | head -20

# Example output:
# 143 /old-product-page
#  87 /blog/removed-article
#  34 /wp-login.php  (attack attempts — not critical)

Surveiller les erreurs 404

Un audit ponctuel est utile, mais de nouvelles 404 apparaissent en permanence : des pages sont renommées, des produits supprimés, des sites externes pointent vers des URL inexistantes. Il est important de mettre en place une surveillance régulière.

Pour les grands sites (plus de 10 000 pages), les logs serveur sont particulièrement précieux : ils couvrent 100 % des requêtes, y compris celles des robots, des internautes et des scripts. Search Console ne montre que ce que Googlebot a trouvé pendant l'exploration, soit une partie du tableau complet.

Checklist d'une page 404 correcte

Statut HTTP

• La page 404 renvoie le statut HTTP 404 (vérifié avec curl ou les DevTools)
• Pas de soft 404 : la page d'erreur ne renvoie pas 200 OK
• Pas de redirection JavaScript depuis les URL inexistantes vers la page d'accueil
• Le 410 Gone est utilisé pour les pages supprimées en masse, sans remplacement
• Les redirections 301 ne sont configurées que pour les URL ayant une page de remplacement pertinente

Contenu de la page

• Message d'erreur clair, en langage courant, sans jargon technique
• Un champ de recherche ou un lien vers la recherche du site est présent
• Un lien vers la page d'accueil est présent
• Des liens vers 2 à 4 rubriques ou catégories populaires sont présents
• La page reprend le style du site (en-tête, pied de page, polices)

Mise en œuvre

• Next.js : le fichier not-found.tsx est créé, et notFound() est appelé pour les slugs inexistants
• Nginx : la directive error_page 404 est configurée, et le fichier 404.html est marqué comme internal
• Apache : ErrorDocument 404 est défini dans .htaccess ou dans la configuration principale
• WordPress : le fichier 404.php existe dans le thème actif
• SPA (React ou Vue sans SSR) : une balise meta noindex est ajoutée côté client sur les pages 404

Surveillance

• Google Search Console est connectée et les alertes e-mail sont configurées
• Un crawl régulier avec Screaming Frog ou un outil équivalent est effectué (au moins une fois par mois)
• Les logs serveur sont accessibles et analysés pour les sites à fort trafic
• Tous les liens internes pointant vers des URL en 404 ont été repérés et corrigés

FAQ

Réponses aux questions courantes sur la configuration des pages 404, qui reviennent lors des audits comme du développement.