Wenn sprechende Permalinks 404 liefern, kann ein beschädigter WordPress-Rewrite-Block die Ursache sein. So erzeugen Sie nur den passenden Standardblock neu und bewahren eigene Hoster- und Sicherheitsregeln.
Die .htaccess steuert auf Apache-kompatiblen Servern Permalinks, Zugriffe, Redirects und Header. Erfahren Sie, wo sie wirkt, welche Abschnitte WordPress verwaltet und wie Änderungen sicher getestet werden.
Für gelöschte Seiten gilt keine Einheitslösung: Ein gleichwertiger Nachfolger rechtfertigt einen Redirect, bewusst dauerhaft entfernte Inhalte können 410 liefern, unbekannte URLs bleiben 404.
WordPress-Slugs sind meist kleingeschrieben, Dateien und technische Kennungen können jedoch case-sensitiv sein. So korrigieren Sie bekannte URL-Varianten, ohne Assets, APIs oder Signaturen zu beschädigen.
Wenn WordPress, Server und CDN unterschiedliche Slash-Regeln anwenden, entstehen Ketten oder Schleifen. So bestimmen Sie eine kanonische Form, ohne Dateien, Feeds oder API-Endpunkte zu beschädigen.
Wenn WWW der kanonische Host werden soll, brauchen Apex-Domain und WWW gültige DNS- und TLS-Konfigurationen. Dieser Leitfaden verhindert doppelte Redirects, Cookie-Probleme und veraltete Callback-URLs.
Für eine saubere WWW-zu-Non-WWW-Weiterleitung müssen beide Hosts per DNS und TLS erreichbar sein. So vereinheitlichen Sie WordPress, CDN und Server ohne Schleifen oder verlorene Pfade.
Beim Aufräumen von Taxonomien brauchen alte Kategorie- und Schlagwortarchive ein inhaltlich passendes Ziel. So planen und prüfen Sie direkte Weiterleitungen ohne Sprachfehler oder Redirect-Ketten.
Nach einer Slug-Änderung sollten alte Permalinks direkt auf die neue URL führen. So richten Sie einen eindeutigen 301-Redirect ein und aktualisieren interne Links, Canonical, Sitemap und Sprachvarianten.
Bei einer Domainmigration braucht jede alte URL ein passendes neues Ziel. DNS, TLS, WordPress-URLs und externe Abhängigkeiten müssen gemeinsam umziehen. So bleibt der alte Host zuverlässig erreichbar.