WordPress Links nach Domainwechsel falsch: Ursachen finden und sauber beheben

Wenn WordPress-Links nach einem Domainwechsel falsch sind, führen interne Verweise häufig noch auf die alte Domain, auf eine temporäre Adresse oder auf eine falsche URL-Struktur. Auch Bilder, Menüs, Canonical-Tags und Weiterleitungen können betroffen sein. In diesem Leitfaden erfährst Du, wie Du die Ursache systematisch eingrenzt, welche Einstellungen Du prüfen solltest und wie Du die Links möglichst sicher korrigierst.

Passende WordPress Hilfe zum Thema

Was bedeutet „WordPress Links nach Domainwechsel falsch“?

Die Darstellung macht sichtbar, dass nicht nur sichtbare Links, sondern auch Bilder, Weiterleitungen und technische URLs geprüft werden müssen. So lässt sich das Problem als Zusammenwirken mehrerer Website-Bereiche einordnen.

Ein Domainwechsel ist mehr als das Austauschen eines Namens im Browser. WordPress speichert die Website-Adresse an mehreren Stellen: in den Grundeinstellungen, in der Datenbank, in Beiträgen, Seiten, Widgets, Menüs, Medien und gegebenenfalls in Plugin-Einstellungen. Zusätzlich können der Webserver, ein Caching-System oder ein Content Delivery Network weiterhin auf die alte Domain verweisen.

Typische Symptome sind:

• Interne Links öffnen weiterhin die alte Domain.
• Beim Aufruf einer Seite erscheint eine Weiterleitungsschleife oder ein 404-Fehler.
• Bilder und Dateien werden nicht geladen, weil ihre URLs noch auf die bisherige Adresse zeigen.
• Das WordPress-Backend ist erreichbar, die Website im Frontend jedoch nicht.
• HTTPS, www und non-www werden uneinheitlich verwendet.
• Menüs, Canonical-URLs oder XML-Sitemaps enthalten alte Adressen.
• Links funktionieren nur für eingeloggte Nutzer oder nur im privaten Browserfenster.

Die Ursache kann eine einzelne falsche Einstellung sein. Bei gewachsenen Websites müssen jedoch oft mehrere Ebenen geprüft werden. Wichtig ist deshalb, nicht blind globale Ersetzungen auszuführen, sondern zuerst ein vollständiges Backup zu erstellen und die URL-Struktur der alten und neuen Website zu dokumentieren.

Vorbereitung: Domainwechsel sicher analysieren

Bevor Du Änderungen an der Datenbank vornimmst, solltest Du den aktuellen Zustand sichern. Ein Datenbank-Backup allein reicht bei einem Domainwechsel nicht immer aus. Sichere möglichst auch die Dateien, insbesondere wp-content, Uploads, Themes und Plugins. Wenn eine Staging-Umgebung vorhanden ist, solltest Du die Korrekturen zunächst dort durchführen.

Alte und neue URL eindeutig festlegen

Notiere die vollständige alte und neue Adresse einschließlich Protokoll und möglicher Subdomain. Beispiele sind http://alte-domain.de, https://alte-domain.de und https://www.neue-domain.de. Diese Varianten sind technisch nicht automatisch identisch.

Lege außerdem fest, welche URL künftig die kanonische Adresse sein soll. Entscheide Dich beispielsweise für HTTPS ohne www oder für HTTPS mit www. Eine klare Zieladresse verhindert, dass Du zwar die Domain änderst, aber gleichzeitig mehrere weitere Varianten im System verteilst.

Die Website nicht nur im Browser testen

Prüfe mehrere Seitentypen: Startseite, einzelne Unterseite, Blogbeitrag, Kategorie, Kontaktseite, Suchergebnisse und eine Medien-Datei. Öffne zusätzlich das Backend und kontrolliere, ob dort Warnungen oder Weiterleitungen auftreten. So lässt sich erkennen, ob das Problem nur einzelne Inhalte oder die gesamte Installation betrifft.

Die wichtigsten Ursachen für falsche Links

WordPress-Adresse und Website-Adresse stimmen nicht

WordPress verwendet in den allgemeinen Einstellungen zwei zentrale Werte: die WordPress-Adresse für die Installation und die Website-Adresse für die öffentlich erreichbare Website. In vielen Installationen sind beide Werte identisch. Nach einem Domainwechsel kann jedoch einer der beiden Einträge noch die alte Domain enthalten.

Wenn Du das Backend erreichst, findest Du die Werte unter Einstellungen > Allgemein. Prüfe Protokoll, Domain, www-Variante und mögliche Pfadangaben sorgfältig. Speichere nur dann, wenn Du sicher bist, dass die neue Adresse auf die richtige Installation zeigt.

Falls das Backend wegen einer falschen URL nicht erreichbar ist, können die Werte je nach Situation vorübergehend in der Konfigurationsdatei festgelegt werden:

define( 'WP_HOME', 'https://www.neue-domain.de' );
define( 'WP_SITEURL', 'https://www.neue-domain.de' );

Diese Angaben müssen zur tatsächlichen Installation passen. Eine falsche Konfiguration kann den Zugriff weiter erschweren. Nach der Korrektur solltest Du prüfen, ob die Werte später wieder zentral in WordPress verwaltet werden sollen.

Absolute URLs in Inhalten und Einstellungen

Viele interne Links werden als vollständige URLs gespeichert. Ein Link auf eine Unterseite kann dann beispielsweise direkt die alte Domain enthalten. Das betrifft nicht nur den sichtbaren Text eines Beitrags, sondern auch Bildquellen, Hintergrundbilder, eingebettete Inhalte, Buttons, Widgets und individuelle Felder.

Die WordPress-Datenbank enthält außerdem serialisierte Daten. Solche Daten dürfen nicht einfach mit einer unvorbereiteten Textsuche ersetzt werden, weil sich die gespeicherten Zeichenlängen ändern können. Eine beschädigte Serialisierung kann Einstellungen oder Widget-Konfigurationen unbrauchbar machen.

HTTPS, www und Weiterleitungen

Ein Domainwechsel ist häufig mit einer Umstellung auf HTTPS oder einer Änderung der www-Variante verbunden. Dadurch entstehen mehrere mögliche Adressen. Wenn WordPress auf https://neue-domain.de eingestellt ist, der Webserver aber auf https://www.neue-domain.de umleitet, kann die Website zwar funktionieren, aber unnötige Weiterleitungsketten erzeugen.

Auch widersprüchliche Regeln in .htaccess, der Serverkonfiguration oder einem Sicherheits-Plugin können zu Schleifen führen. Prüfe deshalb, welche Ebene die Weiterleitung ausführt und ob nur eine eindeutige Weiterleitung zur gewünschten Zieladresse vorhanden ist.

Cache und CDN zeigen veraltete Inhalte

Manchmal sind die URLs bereits korrekt geändert, aber ein Seiten- oder Objekt-Cache liefert noch alte HTML-Inhalte aus. Auch ein CDN, ein Reverse Proxy oder der Browser-Cache kann die Diagnose verfälschen. Leere nach einer Korrektur die betroffenen Caches kontrolliert und teste die Website zusätzlich in einem privaten Browserfenster.

Schritt-für-Schritt-Anleitung zur Korrektur

1. Vollständiges Backup erstellen

Erstelle vor jeder Datenbankänderung eine wiederherstellbare Sicherung. Prüfe nicht nur, ob ein Backup erstellt wurde, sondern ob Du weißt, wie es zurückgespielt werden kann. Bei produktiven Shops oder umfangreichen Websites ist ein getestetes Staging-System besonders sinnvoll.

2. DNS und Hosting-Ziel prüfen

Die neue Domain muss auf den richtigen Server oder das richtige Hosting-Ziel zeigen. Prüfe, ob die Domain im Hosting eingerichtet ist, ob das SSL-Zertifikat zur Domain passt und ob der Webserver die WordPress-Installation für diese Adresse ausliefert. Wenn DNS noch auf ein anderes Ziel zeigt, können Datenbankänderungen das eigentliche Problem nicht lösen.

3. WordPress-URLs korrigieren

Prüfe zunächst die beiden zentralen URL-Werte. Achte darauf, dass kein abschließender Schrägstrich erforderlich oder versehentlich doppelt eingetragen wird, und verwende genau die gewünschte HTTPS- und www-Variante.

Nach dem Speichern solltest Du Dich gegebenenfalls neu anmelden. Teste die Startseite und einige Unterseiten, bevor Du weitere globale Änderungen vornimmst. Wenn die Website danach nicht erreichbar ist, liegt möglicherweise ein Konflikt zwischen WordPress-URL, Serverkonfiguration und DNS vor.

4. Alte URLs in der Datenbank ersetzen

Für die Ersetzung alter URLs sollte ein Verfahren verwendet werden, das WordPress-Datenstrukturen und serialisierte Werte berücksichtigt. Je nach Umgebung kommen dafür ein speziell geeignetes Migrations- oder Search-and-Replace-Werkzeug, ein WP-CLI-Befehl oder eine kontrollierte technische Migration infrage.

Arbeite zunächst mit einer Vorschau oder einem Dry-Run, sofern das Werkzeug dies unterstützt. Suche nach der alten vollständigen URL und prüfe, in welchen Tabellen und Feldern Treffer vorkommen. Ersetze nicht pauschal jede ähnliche Zeichenfolge, wenn dabei externe Links, E-Mail-Adressen, Codebeispiele oder historische Inhalte verändert werden könnten.

Bei WP-CLI kann ein solcher Vorgang grundsätzlich vorbereitet werden. Die konkreten Tabellen, Optionen und Ausschlüsse müssen zur Installation passen:

wp search-replace 'https://alte-domain.de' 'https://neue-domain.de' --all-tables-with-prefix --dry-run

Ein Dry-Run verändert die Datenbank nicht. Erst nach einer sorgfältigen Prüfung der Ausgabe sollte eine tatsächliche Ersetzung erwogen werden. Bei Multisite-Installationen, ungewöhnlichen Tabellenpräfixen oder großen Datenmengen ist besondere Vorsicht notwendig.

5. Menüs, Widgets und Theme-Einstellungen kontrollieren

Menüeinträge können als individuelle Links gespeichert sein und deshalb weiterhin auf die alte Domain zeigen. Kontrolliere die Navigation im Backend und öffne anschließend alle wichtigen Menüpunkte im Frontend. Prüfe außerdem Widgets, Footer-Links, Header-Buttons, Theme-Optionen und globale Blockvorlagen.

Wenn ein Theme eigene Optionen für Logos, Social-Media-Links oder Kontaktinformationen besitzt, können dort ebenfalls alte Adressen stehen. Eine Datenbank-Ersetzung findet diese Werte möglicherweise, aber die manuelle Kontrolle zeigt Dir, ob zusätzlich eine funktionale Einstellung angepasst werden muss.

6. Medien, Downloads und CSS-Hintergründe prüfen

Öffne mehrere Beiträge mit Bildern, Galerien, PDF-Downloads und Videos. Prüfe den HTML-Quelltext oder die Browser-Entwicklertools, wenn Dateien nicht geladen werden. Ein Bild kann im Beitrag korrekt aussehen, während eine CSS-Hintergrundgrafik oder eine Datei in einem individuellen Block noch die alte Domain verwendet.

Bei Medienproblemen solltest Du auch die Upload-Pfade und Berechtigungen des Servers prüfen. Nicht jeder Fehler beim Laden einer Datei ist ein URL-Problem. Ein falscher Dateipfad, eine fehlende Datei oder eine blockierende Sicherheitsregel kann ähnlich aussehen.

7. Canonical-URLs, Sitemap und SEO-Einstellungen aktualisieren

SEO-Plugins erzeugen Canonical-Tags, XML-Sitemaps und teilweise strukturierte Daten. Nach einem Domainwechsel sollten diese Ausgaben die neue Adresse enthalten. Öffne die Sitemap direkt im Browser und prüfe mehrere Einträge. Kontrolliere außerdem den Quelltext einer Seite auf Canonical- und Open-Graph-URLs.

Wenn alte URLs weiterhin erreichbar sind, sollten sie in der Regel nachvollziehbar auf passende neue URLs weiterleiten. Eine Weiterleitung von jeder alten Seite auf die Startseite ist nicht automatisch sinnvoll, weil dabei der thematische Bezug verloren gehen kann. Prüfe daher wichtige alte URLs einzeln oder anhand einer vorher erstellten URL-Liste.

Technische Prüfung mit Browser und Server

Weiterleitungskette und HTTP-Status untersuchen

Ein Browser zeigt häufig nur das Endergebnis. Für die Ursachenanalyse ist es hilfreicher, die einzelnen Weiterleitungen zu betrachten. Prüfe, ob eine Anfrage von der alten Domain zu einer Zwischenadresse und anschließend wieder zurückgeleitet wird. Eine saubere Migration sollte möglichst direkt zur endgültigen Zieladresse führen.

Achte dabei auf unterschiedliche Protokolle und Hostnamen. Eine Kette wie alte HTTP-Adresse, alte HTTPS-Adresse, neue HTTP-Adresse und neue HTTPS-Adresse erschwert Crawlern und Nutzern den Zugriff. Die Regeln sollten so aufgebaut sein, dass die gewünschte kanonische Adresse eindeutig erreicht wird.

Gemischte Inhalte erkennen

Wenn die Seite über HTTPS geladen wird, aber einzelne Bilder, Skripte oder Stylesheets noch über HTTP angefordert werden, kann der Browser diese Inhalte blockieren oder warnen. Das ist ein anderes Problem als ein falscher interner Link, tritt nach Domain- und HTTPS-Wechseln jedoch häufig gemeinsam auf.

Die Entwicklerkonsole des Browsers kann Hinweise auf Mixed Content, blockierte Ressourcen, CORS-Probleme oder fehlende Dateien liefern. Notiere die betroffenen URLs und ordne sie anschließend der passenden Ursache zu, statt alle Meldungen mit einer einzigen Ersetzung zu behandeln.

WordPress-Debugging gezielt einsetzen

Wenn ein Plugin oder Theme URLs dynamisch erzeugt, reicht eine Datenbankkorrektur möglicherweise nicht. Für die Analyse kann temporäres WordPress-Debugging helfen. Aktiviere Protokollierung nur kontrolliert und vermeide, Fehlermeldungen öffentlich auszugeben. In produktiven Umgebungen sollten Debug-Ausgaben nicht dauerhaft sichtbar bleiben.

Prüfe nach Möglichkeit, ob ein Plugin eine eigene Basis-URL, API-Adresse oder Callback-Adresse speichert. Bei Integrationen können zusätzlich Einstellungen beim externen Dienst angepasst werden müssen. Beispiele sind Zahlungsanbieter, Newsletter-Systeme, Webhooks oder externe Bilddienste.

Typische Fehler und passende Lösungen

Problem	Mögliche Ursache	Sinnvoller nächster Schritt
Startseite öffnet alte Domain	WordPress-Adresse oder Website-Adresse ist nicht geändert	URL-Werte prüfen und anschließend Cache leeren
Interne Links zeigen auf alte Domain	Absolute URLs in Beiträgen, Menüs oder Widgets	Kontrollierte, serialisierungsfähige Ersetzung mit Vorschau durchführen
Bilder fehlen	Alte Medien-URL, falscher Pfad oder fehlende Datei	Quelltext, Dateipfad und Upload-Verzeichnis vergleichen
Weiterleitungsschleife	Widersprüchliche HTTPS- oder www-Regeln	Server-, Plugin- und WordPress-Regeln auf eine Zielvariante abstimmen
Backend funktioniert nicht	Falsche URL oder fehlerhafte Weiterleitung	Backup bereithalten und URL-Konfiguration technisch prüfen
Sitemap enthält alte URLs	SEO-Cache oder alte Plugin-Konfiguration	SEO-Einstellungen, Permalinks und Cache kontrollieren

Fehler: Nur die Startseite wird ersetzt

Eine häufige unvollständige Lösung besteht darin, nur die Website-Adresse zu ändern. Dadurch kann die Startseite funktionieren, während Inhalte, Bilder und Menüs noch alte absolute URLs enthalten. Prüfe deshalb nach der Änderung mehrere Inhaltstypen und nicht nur die erste Seite.

Fehler: Datenbank direkt mit einer einfachen SQL-Ersetzung bearbeiten

Eine direkte Ersetzung in allen Tabellen kann bei serialisierten Daten problematisch sein. Außerdem können Datenbankfelder externe URLs enthalten, die nicht verändert werden sollen. Verwende daher ein Werkzeug, das die Datenstruktur berücksichtigt, sichere die Datenbank und kontrolliere die Treffer vor der eigentlichen Änderung.

Fehler: Weiterleitungen zu früh oder zu spät einrichten

Weiterleitungen sind wichtig, ersetzen aber keine Korrektur interner URLs. Wenn interne Links dauerhaft über alte Adressen laufen, entstehen unnötige zusätzliche Anfragen. Umgekehrt darf die alte Domain nicht abgeschaltet werden, bevor die relevanten alten URLs auf passende neue Ziele zeigen und die neue Website getestet wurde.

Fehler: Caches und Browserdaten übersehen

Nach der Korrektur kann eine alte Version weiterhin angezeigt werden. Leere die beteiligten Cache-Ebenen kontrolliert: WordPress- oder Plugin-Cache, Server-Cache, CDN und gegebenenfalls Browser-Cache. Prüfe anschließend in einem unabhängigen Browser, ob die Ausgabe tatsächlich aktualisiert wurde.

Praxisbeispiel: Unternehmenswebsite mit neuer Domain

Angenommen, eine Unternehmenswebsite zieht von https://alte-domain.de nach https://neue-domain.de. Die Startseite erscheint unter der neuen Domain, aber im Footer führen mehrere Links noch zurück zur alten Adresse. Einige Bilder werden geladen, andere nicht.

Eine sinnvolle Analyse beginnt mit der Trennung der Symptome. Zuerst werden DNS, SSL und die WordPress-URL geprüft. Danach wird ein Backup erstellt und die Datenbank nach der alten vollständigen URL durchsucht. Die Treffer zeigen, dass Footer-Links in einem Widget gespeichert sind, während die fehlenden Bilder aus einem individuellen CSS-Feld stammen.

Beide Bereiche werden kontrolliert aktualisiert. Anschließend wird der Cache geleert, die Startseite mit einem privaten Browserfenster geöffnet und die wichtigsten Unterseiten getestet. Danach folgen Sitemap, Canonical-URLs, alte Weiterleitungen und einige bisherige URLs aus der Website-Struktur.

Dieses Vorgehen ist robuster, als nur den sichtbaren Footer zu ändern. Es berücksichtigt die verschiedenen Speicherorte und verhindert, dass ein scheinbar behobener Linkfehler an anderer Stelle bestehen bleibt.

Checkliste nach dem Domainwechsel

1. Backup von Dateien und Datenbank erstellt.
2. Alte und neue URL einschließlich HTTPS- und www-Variante dokumentiert.
3. DNS, Hosting-Ziel und SSL-Konfiguration geprüft.
4. WordPress-Adresse und Website-Adresse kontrolliert.
5. Interne absolute URLs in Inhalten und Einstellungen geprüft.
6. Menüs, Widgets, Theme-Optionen und globale Blöcke getestet.
7. Bilder, Downloads, CSS-Ressourcen und eingebettete Inhalte kontrolliert.
8. Weiterleitungen ohne Schleifen und unnötige Ketten eingerichtet.
9. Canonical-Tags, Sitemap und strukturierte URLs geprüft.
10. Cache-Ebenen geleert und Tests aus verschiedenen Browsern durchgeführt.
11. Wichtige alte URLs mit passenden neuen Zielen verglichen.
12. Fehlerprotokolle und Such- oder Crawling-Hinweise nach der Migration beobachtet.

FAQ

Warum zeigen WordPress-Links nach dem Domainwechsel noch auf die alte Adresse?

WordPress speichert absolute URLs an vielen Stellen. Neben den allgemeinen Einstellungen können Beiträge, Menüs, Widgets, Theme-Optionen und Plugin-Daten betroffen sein. Eine Änderung der Hauptdomain korrigiert diese gespeicherten Links nicht automatisch.

Kann ich die alte Domain einfach auf die neue Domain umleiten?

Eine Weiterleitung ist ein wichtiger Bestandteil der Migration, ersetzt aber nicht die Korrektur interner URLs. Die alte Domain sollte auf passende neue Zielseiten weiterleiten, während interne Links möglichst direkt auf die neue Domain zeigen.

Was mache ich, wenn das WordPress-Backend nicht mehr erreichbar ist?

Prüfe zunächst DNS, Hosting und die Weiterleitungskonfiguration. Halte ein Backup bereit und korrigiere die WordPress-URL gegebenenfalls über eine geeignete technische Zugriffsmöglichkeit. Änderungen sollten vorsichtig erfolgen, weil eine falsche URL den Zugriff weiter blockieren kann.

Ist eine einfache Suchen-und-Ersetzen-Funktion in der Datenbank ausreichend?

Nicht immer. WordPress und Plugins speichern teilweise serialisierte Daten. Eine unpassende Ersetzung kann deren Struktur beschädigen. Nutze ein Verfahren, das solche Daten berücksichtigt, und führe vor der Änderung eine Vorschau oder einen Dry-Run durch.

Warum fehlen nach dem Domainwechsel nur manche Bilder?

Unterschiedliche Bilder können an unterschiedlichen Stellen gespeichert sein. Einige stammen aus der Medienbibliothek, andere aus CSS, Theme-Optionen, individuellen Feldern oder externen Quellen. Prüfe die konkrete Bild-URL und unterscheide zwischen falscher Adresse, fehlender Datei und blockierter Ressource.

Wie prüfe ich, ob die Weiterleitungen korrekt funktionieren?

Teste mehrere alte URLs und beobachte die gesamte Weiterleitungskette. Jede alte Adresse sollte möglichst direkt auf die passende neue URL führen. Achte besonders auf Wechsel zwischen HTTP, HTTPS, www und non-www sowie auf mögliche Schleifen.

Was muss ich nach der Linkkorrektur für SEO prüfen?

Kontrolliere Canonical-Tags, XML-Sitemap, interne Verlinkung, strukturierte Daten und relevante Weiterleitungen. Die neue Domain sollte in allen wichtigen Ausgaben konsistent erscheinen. Zusätzlich sollten alte, weiterhin relevante URLs auf inhaltlich passende neue Seiten zeigen.

Wann ist professionelle Unterstützung sinnvoll?

Unterstützung ist besonders sinnvoll bei Multisite-Installationen, Shops, großen Datenbanken, mehreren Domains, individuellen Plugins oder einer nicht erreichbaren Website. Auch bei Weiterleitungsschleifen und unklaren Backups ist eine kontrollierte Analyse sicherer als wiederholte Änderungen ohne Rückfallmöglichkeit.

Fazit

Wenn WordPress-Links nach einem Domainwechsel falsch sind, liegt die Ursache meist nicht an einer einzigen sichtbaren Einstellung. Prüfe WordPress-URLs, Datenbankinhalte, Menüs, Medien, Themes, Plugins, Serverregeln und Caches als zusammenhängendes System. Erstelle vor Änderungen ein Backup, verwende bei Datenbankkorrekturen ein geeignetes Verfahren und teste die Website anschließend anhand einer festen Checkliste.

Der sinnvollste nächste Schritt ist eine strukturierte Bestandsaufnahme: Welche URL soll künftig gelten, wo taucht die alte Adresse noch auf und welche Weiterleitungen sind erforderlich? Mit dieser Reihenfolge lassen sich Fehler nachvollziehbar eingrenzen und die neue WordPress-Domain technisch sauber in Betrieb nehmen.