Individuelle 404-Seite: richtig konfigurieren und umsetzen

Ruft ein Nutzer einen defekten Link auf, muss der Server den Status 404 Not Found zurückgeben. In echten Projekten wird diese Regel aber erstaunlich oft verletzt: Das CMS liefert 200 OK, eine Weiterleitung führt auf die Startseite, oder die „404“-Seite gibt zwar technisch den richtigen Code zurück, sieht aber wie eine leere Seite aus. Jede dieser Situationen ist ein eigenes Problem – für SEO und für den Nutzer.

Eine korrekt konfigurierte 404-Seite löst gleichzeitig drei Probleme: Sie signalisiert Google, dass die URL nicht existiert, hält den Nutzer auf der Website und hilft ihm, den richtigen Bereich zu finden, und sie schützt das Crawl-Budget vor unnötigen Crawls. Gehen wir die Aspekte der Reihe nach durch.

Was ist eine 404-Seite

404 Not Found ist der HTTP-Antwortcode, den ein Server zurückgibt, wenn die angeforderte Ressource nicht existiert. Der Code zeigt an, dass der Server einwandfrei arbeitet und die Route aufgelöst wurde, das angeforderte Dokument aber fehlt. So unterscheidet sich 404 von 500 (Serverfehler) und 503 (Dienst nicht verfügbar).

Eine 404-Seite existiert auf zwei Ebenen. Die HTTP-Ebene ist der Antwortcode im Header, den der Suchcrawler sieht. Die visuelle Ebene ist der HTML-Inhalt, den der Nutzer sieht. Beide Ebenen sind gleich wichtig: Ein falscher HTTP-Code ist ein SEO-Problem, ein schwaches visuelles Design ein UX-Problem.

Die wichtigste Regel: immer HTTP 404

Die wichtigste Grundregel: Eine Fehlerseite muss den HTTP-Status 404 (oder 410) zurückgeben, niemals 200. Dies wird als „Hard-404“ bezeichnet, im Gegensatz zum „Soft-404“.

Den HTTP-Status jeder Seite prüfen Sie direkt im Browser: F12 → Network → Seite neu laden → erste Anfrage suchen → Spalte Status. Oder per curl im 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 und 410: der Unterschied

Neben dem „Hard-404“ gibt es zwei verwandte Fälle, die in der Praxis oft verwechselt werden: Soft-404 und der Status 410. Den Unterschied zu kennen ist wichtig, um gelöschte Seiten richtig zu verwalten.

Google stuft außerdem jede Weiterleitung von einer 404-URL auf die Startseite oder eine andere unpassende Seite als Soft-404 ein. Aus Sicht der Suchmaschine hat der Nutzer nach A gesucht, landet auf B, und der Inhalt von B beantwortet die Suchanfrage nicht. Das schwächt das Qualitätssignal der Zielseite.

Was eine gute 404-Seite enthalten sollte

Ein Nutzer, der auf einer 404-Seite landet, ist bereits leicht frustriert. Die Aufgabe der Seite ist es, diese Frustration abzubauen und einen klaren nächsten Schritt anzubieten. Eine wirksame 404-Seite folgt einer erkennbaren Struktur.

zoom_in

Was Sie auf einer 404-Seite nicht tun sollten: den Nutzer per JavaScript automatisch auf die Startseite weiterleiten (window.location.href = '/'). Google kann das als Soft-404 werten: Der Nutzer erwartete A, erhielt B, und der Inhalt ist nicht relevant. Serverseitige 301-Weiterleitungen von 404-URLs sind nur sinnvoll, wenn es tatsächlich eine passende Ersatzseite gibt.

Umsetzung: Next.js, Nginx, Apache

Wie Sie eine individuelle 404-Seite konfigurieren, hängt von Ihrem Stack ab. Wir behandeln die drei häufigsten Setups: Next.js App Router, Nginx und Apache.

Next.js App Router

In Next.js 13+ mit App Router erstellen Sie eine individuelle 404-Seite über die Datei not-found.tsx im Verzeichnis app/. Bei i18n (z. B. mit next-intl) liegt die Datei in 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.

Für eine programmatische 404-Antwort (z. B. in einer dynamischen Route app/[locale]/blog/[slug]/page.tsx) verwenden Sie die Funktion notFound() aus next/navigation. Ihr Aufruf beendet das Rendering sofort, liefert HTTP 404 und rendert 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

In Nginx konfigurieren Sie die individuelle 404-Seite über die Direktive error_page im Block server. Achten Sie darauf, dass die Datei 404.html am angegebenen Pfad liegt und ihre Auslieferung keine interne Weiterleitung auf 200 auslöst.

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

Bei Apache konfigurieren Sie die 404-Seite über ErrorDocument – entweder in der Hauptkonfiguration oder in .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 und andere CMS)

In WordPress ist die individuelle 404-Seite die Datei 404.php in Ihrem Theme. WordPress liefert bei nicht vorhandenen URLs automatisch HTTP 404, sofern die Permalinks korrekt konfiguriert sind. Antwortet das CMS stattdessen mit 200, liegt das Problem meist in der .htaccess oder der Serverkonfiguration.

<?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();

Defekte Links finden und beheben

Eine korrekt konfigurierte 404-Seite ist nur die halbe Arbeit. Die andere Hälfte besteht darin, alle Links zu finden, die auf nicht existierende Seiten zeigen, und sie zu beheben. Defekte Links sind die Hauptursache dafür, dass 404-Fehler im Index erscheinen.

# 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)

404-Fehler überwachen

Eine einmalige Prüfung ist gut. Doch neue 404-Fehler entstehen laufend: Seiten werden umbenannt, Produkte gelöscht, externe Websites verlinken auf nicht existierende URLs. Deshalb ist eine regelmäßige Überwachung wichtig.

Bei großen Websites (10.000+ Seiten) sind Server-Logs besonders wertvoll: Sie erfassen 100 % aller Anfragen, auch von Bots, Nutzern und Skripten. Die Search Console zeigt dagegen nur, was Googlebot beim Crawlen gefunden hat, also einen Ausschnitt des Gesamtbilds.

Checkliste für eine korrekte 404-Seite

HTTP-Status

• Die 404-Seite liefert HTTP-Status 404 (geprüft mit curl oder DevTools)
• Kein Soft-404: Die Fehlerseite antwortet nicht mit 200 OK
• Keine JavaScript-Weiterleitung von nicht vorhandenen URLs auf die Startseite
• 410 Gone ist für massenhaft gelöschte Seiten ohne Ersatz eingerichtet
• 301-Weiterleitungen sind nur für URLs eingerichtet, die eine passende Ersatzseite haben

Seiteninhalt

• Klare, verständliche Fehlermeldung ohne Fachjargon
• Suchfeld oder Link zur Websitesuche ist vorhanden
• Link zur Startseite ist vorhanden
• Links zu 2–4 beliebten Bereichen oder Kategorien sind vorhanden
• Die Seite entspricht dem Markendesign der Website (Header, Footer, Schriften)

Umsetzung

• Next.js: Datei not-found.tsx angelegt; notFound() wird für nicht existierende Slugs aufgerufen
• Nginx: Direktive error_page 404 konfiguriert; die Datei 404.html ist als internal markiert
• Apache: ErrorDocument 404 ist in .htaccess oder der Hauptkonfiguration gesetzt
• WordPress: 404.php existiert im aktiven Theme
• SPA (React/Vue ohne SSR): Meta-Tag noindex wird auf 404-Seiten clientseitig ergänzt

Monitoring

• Google Search Console ist verbunden und E-Mail-Benachrichtigungen sind eingerichtet
• Regelmäßiges Crawling mit Screaming Frog oder einem vergleichbaren Tool (mindestens monatlich)
• Server-Logs sind zugänglich und werden bei stark frequentierten Websites ausgewertet
• Alle internen Links, die auf 404-URLs zeigen, sind gefunden und behoben

FAQ

Antworten auf häufige Fragen zur Konfiguration von 404-Seiten, die bei Audits und in der Entwicklung auftauchen.