404-Weiterleitung

Das Subsite-404-Redirect-Modul ersetzt die Standard-WordPress-404-Seite durch eine saubere Weiterleitung auf ein konfigurierbares Ziel. Statt einer nackten Fehlerseite landen Besucher bei einem Tippfehler in der URL auf der Startseite, einer bestimmten Seite oder einer frei angegebenen URL.

Allgemein

Konfiguration

Das Weiterleitungsziel wird pro Subsite im Dashboard unter Weinhold → 404 Redirect definiert – zur Wahl stehen die Startseite, eine bestimmte WordPress-Seite aus einer Auswahlliste, oder eine frei eingegebene URL. Zusätzlich lässt sich zwischen temporärer (302) und dauerhafter (301) Weiterleitung wählen, und ob eingeloggte Nutzer sowie Administratoren ebenfalls umgeleitet werden sollen (Admins standardmäßig ausgenommen, zum Debuggen).

Ausnahmepfade

Eigene Pfade (einer pro Zeile, z. B. api/webhook) lassen sich von der Weiterleitung ausnehmen. Technische WordPress-Pfade (wp-json, wp-login.php, wp-cron.php, xmlrpc.php, robots.txt, favicon.ico, Feeds) sowie AJAX- und REST-Requests sind fest eingebaut immer ausgenommen.

Pro Site

Da jede Subsite im Netzwerk unterschiedliche Inhalte und Strukturen haben kann, ist die Konfiguration bewusst pro Site getrennt. Eine öffentliche Seite kann z. B. auf die Startseite weiterleiten, während eine interne Site auf die Login-Seite umleitet. Subsites ohne aktivierte Konfiguration behalten die Standard-WordPress-404-Seite.

Dateien

modules/subsite_404_redirect.php – einzige Datei des Moduls: Weiterleitungslogik, Einstellungen, Admin-Seite, Cleanup.

Für Entwickler

Einstellungen (Option weinhold_subsite_404_redirect_settings)

Schlüssel	Bedeutung
target_mode	home, page oder custom_url
target_page_id	Ziel-Seiten-ID bei target_mode=page
target_custom_url	Ziel-URL bei target_mode=custom_url
status_code	301 oder 302
apply_for_logged_in	Auch eingeloggte Nutzer umleiten
allow_admin_debug	Administratoren von der Weiterleitung ausnehmen
append_from404	Hängt from404=1 und den fehlenden Pfad als missing-Parameter an die Ziel-URL an
exception_custom_paths	Zusätzliche, frei definierte Ausnahmepfade

Ablauf

Hängt an template_redirect und greift nur bei echten 404-Antworten außerhalb des Admin-Bereichs. Reihenfolge der Prüfungen: aktiver Wartungsmodus bricht sofort ab, dann Modul aktiv?, dann technische/Ausnahmepfade, dann Admin-Debug-Ausnahme, dann eingeloggte Nutzer, dann eigene Ausnahmepfade. Zeigt die aufgelöste Ziel-URL zufällig auf den aktuellen (404-)Pfad, wird ebenfalls nicht umgeleitet – verhindert eine Weiterleitung auf sich selbst.

Besonderheiten

Wartungsmodus hat Vorrang: Ist das Wartungsmodus-Modul aktiv, greift die 404-Weiterleitung gar nicht erst – die eigene Weiterleitung des Wartungsmodus soll nicht überschrieben werden.

REST- und AJAX-Requests sind immer ausgenommen, auch ohne manuelle Konfiguration – ein 404 innerhalb der REST-API soll als echter API-Fehler beim aufrufenden System ankommen, nicht als HTML-Weiterleitung.

Beim Modul-Reset werden zusätzlich mehrere Legacy-Optionen früherer Versionen entfernt (enabled/target/status/exceptions/exception_page_ids einzeln) – Überbleibsel, bevor die Einstellungen in ein einziges Array zusammengeführt wurden.

Versionshistorie

Version	Datum	Änderung
1.0.0	22.09.2026	Einführung der Versionierung.

404 Redirect

The Subsite 404 Redirect module replaces the default WordPress 404 page with a clean redirect to a configurable destination. Instead of a bare error page, visitors with a typo in the URL land on the homepage, a specific page, or a freely entered URL.

General

Configuration

The redirect destination is defined per subsite in the dashboard under Weinhold → 404 Redirect — options are the homepage, a specific WordPress page from a dropdown, or a freely entered URL. You can also choose between a temporary (302) and a permanent (301) redirect, and whether logged-in users and administrators should also be redirected (admins excluded by default, for debugging).

Exception Paths

Custom paths (one per line, e.g. api/webhook) can be excluded from the redirect. Technical WordPress paths (wp-json, wp-login.php, wp-cron.php, xmlrpc.php, robots.txt, favicon.ico, feeds) as well as AJAX and REST requests are always excluded, built in.

Per Site

Since each subsite in the network can have different content and structure, the configuration is intentionally separated per site. A public site can redirect to the homepage, while an internal site redirects to the login page. Subsites without an enabled configuration keep the default WordPress 404 page.

Files

modules/subsite_404_redirect.php – the module’s only file: redirect logic, settings, admin page, cleanup.

For Developers

Settings (Option weinhold_subsite_404_redirect_settings)

Key	Meaning
target_mode	home, page, or custom_url
target_page_id	Target page ID when target_mode=page
target_custom_url	Target URL when target_mode=custom_url
status_code	301 or 302
apply_for_logged_in	Also redirect logged-in users
allow_admin_debug	Exempt administrators from the redirect
append_from404	Appends from404=1 and the missing path as a missing parameter to the target URL
exception_custom_paths	Additional, freely defined exception paths

Flow

Hooks into template_redirect and only applies on genuine 404 responses outside the admin area. Order of checks: active maintenance mode aborts immediately, then whether the module is enabled, then technical/exception paths, then the admin debug exemption, then logged-in users, then custom exception paths. If the resolved target URL happens to match the current (404) path, no redirect happens either — prevents redirecting to itself.

Special Cases

Maintenance mode takes precedence: if the maintenance mode module is active, the 404 redirect doesn’t apply at all — its own redirect shouldn’t be overridden.

REST and AJAX requests are always excluded, even without manual configuration — a 404 within the REST API should reach the calling system as a genuine API error, not as an HTML redirect.

On module reset, several legacy options from earlier versions are additionally removed (enabled/target/status/exceptions/exception_page_ids individually) — leftovers from before the settings were merged into a single array.

Version History

Version	Date	Change
1.0.0	22.09.2026	Introduction of versioning.

subsite-404-redirect