WordPress Address vs Site Address: Technische Unterschiede, Konfiguration und häufige Fallstricke

WordPress Address (URL) und Site Address (URL) sind zwei unterschiedliche Konfigurationsparameter, die jeweils steuern, wo sich die WordPress-Kerndateien auf dem Server befinden und welche URL die Öffentlichkeit verwendet, um das Frontend Ihrer Website zu erreichen. Bei den meisten Standardinstallationen sind beide Werte identisch, sie können jedoch – und müssen manchmal – voneinander abweichen, wenn Sie WordPress-Dateien in einem Unterverzeichnis hosten, während die Website über die Root-Domain bereitgestellt wird.

Wenn diese beiden Werte falsch sind, selbst um ein einziges Zeichen, können Sie aus dem Admin-Dashboard ausgesperrt werden, Mixed-Content-Warnungen auslösen, REST API-Endpunkte beschädigen und Weiterleitungsketten korrumpieren. Die folgenden Abschnitte erläutern die architektonische Logik hinter jeder Einstellung, alle legitimen Szenarien für deren Änderung sowie die genauen Methoden, dies sicher durchzuführen.

Die architektonische Logik hinter den zwei URL-Parametern

WordPress speichert seine URL-Konfiguration gleichzeitig an zwei Stellen: in der wp_options-Datenbanktabelle (Zeilen siteurl und home) und optional in der wp-config.php-Datei über PHP-Konstanten. Es ist wichtig zu verstehen, welche Quelle Vorrang hat, bevor Sie irgendetwas ändern.

Prioritätsreihenfolge (höchste bis niedrigste):

1. In wp-config.php definierte Konstanten (WP_SITEURL, WP_HOME)
2. In der wp_options-Tabelle gespeicherte Werte
3. In Einstellungen > Allgemein im Dashboard eingegebene Werte

Wenn eine Konstante in wp-config.php definiert ist, wird das entsprechende Feld in Einstellungen > Allgemein schreibgeschützt und ausgegraut. Dies ist beabsichtigt – es verhindert versehentliche Überschreibungen über die Benutzeroberfläche und ermöglicht gleichzeitig die programmatische Steuerung.

WordPress Address (URL) — WP_SITEURL

Die WordPress Address entspricht der siteurl-Option in wp_options und der WP_SITEURL-Konstante in wp-config.php. Sie teilt WordPress mit, wo sich seine PHP-Kerndateien, das wp-admin-Verzeichnis und das wp-includes-Verzeichnis physisch befinden. WordPress verwendet diesen Wert, um jeden internen Dateipfadverweis zu erstellen, einschließlich der Admin-Login-URL, AJAX-Endpunkte (/wp-admin/admin-ajax.php) und die REST API-Basis (/wp-json/).

Beispiel: Wenn Ihre WordPress-Installation unter https://example.com/wordpress liegt, muss WP_SITEURL auf https://example.com/wordpress gesetzt sein. Das Aufrufen von https://example.com/wordpress/wp-admin führt zum Dashboard.

Site Address (URL) — WP_HOME

Die Site Address entspricht der home-Option in wp_options und der WP_HOME-Konstante in wp-config.php. Sie definiert die kanonische öffentliche URL – die Adresse, die Benutzer in ihren Browser eingeben, und die Basis, von der aus WordPress alle Frontend-Permalink-Strukturen generiert.

Beispiel: Selbst wenn die Kerndateien unter https://example.com/wordpress liegen, können Sie WP_HOME auf https://example.com setzen, sodass die Startseite, Beiträge und Seiten von der Root-Domain bereitgestellt werden. Dies erfordert eine zusätzliche index.php-Datei und eine .htaccess-Regel im Root-Verzeichnis (weiter unten beschrieben).

Vergleich: WordPress Address vs. Site Address

Wann diese zwei Werte voneinander abweichen müssen

Der häufigste legitime Grund, WP_SITEURL und WP_HOME zu trennen, ist das Unterverzeichnis-Installationsmuster: Sie möchten WordPress-Dateien in einem sauberen Unterverzeichnis isolieren (z. B. /wordpress oder /cms), während die öffentliche Website über die Root-Domain erreichbar ist. Dies ist eine bewusste architektonische Entscheidung, keine Umgehungslösung.

Weitere Szenarien, die eine Aktualisierung eines oder beider Werte erfordern:

• Domain-Migration — der Wechsel von http://old-domain.com zu https://new-domain.com erfordert die gleichzeitige Aktualisierung beider Werte.
• HTTP-zu-HTTPS-Upgrade — das Hinzufügen eines SSL-Zertifikats bedeutet, das Protokollpräfix in beiden Einstellungen von http:// auf https:// zu ändern. Wenn nur eine aktualisiert wird, entstehen Mixed-Content-Fehler.
• Staging-zu-Produktions-Überführung — eine Staging-Umgebung läuft typischerweise auf einer Subdomain oder einer anderen Domain; beide Werte müssen während der Bereitstellung neu geschrieben werden.
• Reverse-Proxy oder CDN-Offloading — wenn ein Load Balancer oder CDN SSL beendet und den Datenverkehr an einen Backend-Server weiterleitet, müssen die WordPress-URL-Einstellungen die öffentlich zugängliche Domain widerspiegeln, nicht die interne Serveradresse.
• Multisite-Netzwerk-Neukonfiguration — in WordPress Multisite interagieren WP_SITEURL und WP_HOME mit den Konstanten DOMAIN_CURRENT_SITE und PATH_CURRENT_SITE, was eine korrekte Konfiguration noch wichtiger macht.

Methode 1: Aktualisierung über das WordPress-Dashboard

Dies ist die geeignete Methode, wenn Sie noch Admin-Zugang haben und die Änderung unkompliziert ist (z. B. HTTP zu HTTPS auf derselben Domain).

1. Melden Sie sich bei https://yourdomain.com/wp-admin an.
2. Navigieren Sie zu Einstellungen > Allgemein.
3. Suchen Sie die Felder WordPress Address (URL) und Site Address (URL).
4. Aktualisieren Sie beide Werte nach Bedarf.
5. Klicken Sie auf Änderungen speichern.

WordPress leitet Sie sofort zur aktualisierten Admin-URL weiter. Wenn Sie die Domain geändert haben, folgt Ihr Browser der Weiterleitung zur neuen Adresse. Wenn die neue Domain noch nicht auf den Server zeigt, verlieren Sie den Dashboard-Zugang – planen Sie die DNS-Propagierung entsprechend.

Methode 2: Konstanten in wp-config.php definieren

Diese Methode wird auf Produktionsservern bevorzugt, da sie versehentliche UI-Änderungen verhindert, auch dann funktioniert, wenn die Datenbank vorübergehend nicht verfügbar ist, und leicht versionskontrolliert werden kann. In einer VPS Hosting-Umgebung mit Root-SSH-Zugang ist dies der zuverlässigste Ansatz.

Öffnen Sie wp-config.php in Ihrem bevorzugten Editor:

nano /var/www/html/wp-config.php

Fügen Sie die folgenden zwei Zeilen oberhalb des /* That's all, stop editing! */-Kommentars hinzu:

define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );

Für das Unterverzeichnis-Installationsmuster, bei dem sich die Kerndateien in /wordpress befinden, die Website aber vom Root-Verzeichnis aus bereitgestellt wird:

define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com/wordpress' );

Speichern und schließen Sie die Datei. Die Dashboard-Felder sind nun schreibgeschützt, was das erwartete Verhalten ist.

Unterverzeichnis-Installation: Die erforderlichen .htaccess- und index.php-Schritte

Wenn WP_HOME und WP_SITEURL voneinander abweichen, kann WordPress allein keine Root-Domain-Anfragen an die Kerndateien im Unterverzeichnis weiterleiten. Sie müssen eine modifizierte index.php-Datei und eine .htaccess-Datei im Dokumenten-Root platzieren.

Schritt 1: Kopieren Sie index.php aus dem WordPress-Unterverzeichnis in das Root-Verzeichnis:

cp /var/www/html/wordpress/index.php /var/www/html/index.php

Schritt 2: Bearbeiten Sie die kopierte /var/www/html/index.php-Datei, um auf das Unterverzeichnis zu verweisen:

<?php
// WordPress view bootstrapper
define( 'WP_USE_THEMES', true );

/** Loads the WordPress Environment and Template */
require __DIR__ . '/wordpress/wp-blog-header.php';

Schritt 3: Stellen Sie sicher, dass Ihre Root-.htaccess-Datei den Standard-WordPress-Rewrite-Block enthält:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Kopieren Sie nicht die .htaccess-Datei aus dem Unterverzeichnis — sie enthält RewriteBase /wordpress/, was das Root-Domain-Routing beschädigt.

Methode 3: Direkte Datenbankaktualisierung über WP-CLI

Wenn das Dashboard nicht zugänglich ist und Sie wp-config.php nicht dauerhaft ändern möchten, bietet WP-CLI eine saubere, skriptfähige Lösung. Dies ist besonders nützlich auf Dedicated Servers, die automatisierte Deployment-Pipelines ausführen.

wp option update siteurl 'https://example.com' --path=/var/www/html
wp option update home 'https://example.com' --path=/var/www/html

Um zu überprüfen, ob die Änderung angewendet wurde:

wp option get siteurl --path=/var/www/html
wp option get home --path=/var/www/html

WP-CLI respektiert wp-config.php-Konstanten — wenn WP_SITEURL oder WP_HOME dort bereits definiert sind, überschreibt der wp option update-Befehl diese nicht. Sie müssen die Konstanten direkt in der Datei aktualisieren.

Methode 4: Direkte MySQL-Aktualisierung (letzter Ausweg)

Verwenden Sie dies nur, wenn SSH-Zugang verfügbar ist, WP-CLI jedoch nicht installiert ist und das Dashboard gesperrt ist. Ermitteln Sie zuerst Ihr Tabellenpräfix (überprüfen Sie $table_prefix in wp-config.php, üblicherweise wp_).

mysql -u db_user -p db_name

UPDATE wp_options SET option_value = 'https://example.com' WHERE option_name = 'siteurl';
UPDATE wp_options SET option_value = 'https://example.com' WHERE option_name = 'home';

Bestätigen Sie die Aktualisierung:

SELECT option_name, option_value FROM wp_options WHERE option_name IN ('siteurl', 'home');

Beenden Sie MySQL und leeren Sie alle Objekt-Caches (Redis, Memcached oder OPcache), bevor Sie die Website testen.

SSL-Konfiguration und URL-Aktualisierungen

Das Upgrade von HTTP auf HTTPS ist der häufigste Grund, beide URL-Parameter gleichzeitig zu aktualisieren. Nach der Installation eines SSL-Zertifikats — ob über Let’s Encrypt via Certbot oder ein kommerzielles Zertifikat von einem Anbieter wie den über SSL Certificates verfügbaren — müssen Sie sowohl WP_HOME als auch WP_SITEURL aktualisieren, um das https://-Präfix zu verwenden.

Wenn Sie beide nicht aktualisieren oder nur eine aktualisieren, entstehen Mixed-Content-Warnungen: Der Browser empfängt eine HTTPS-Seite, die auf HTTP-Assets (Skripte, Stylesheets, Bilder) verweist. Moderne Browser blockieren gemischte aktive Inhalte vollständig, was die JavaScript-Funktionalität und das Admin-Dashboard beschädigt.

Nach der Aktualisierung der URL-Konstanten führen Sie eine Suche und Ersetzung in der Datenbank durch, um alle serialisierten URLs in Beitragsinhalten, Postmeta und Optionen zu aktualisieren:

wp search-replace 'http://example.com' 'https://example.com' --all-tables --path=/var/www/html

Das --all-tables-Flag stellt sicher, dass serialisierte Daten in benutzerdefinierten Tabellen (WooCommerce, Page Builder) ebenfalls aktualisiert werden. Erstellen Sie immer ein Datenbank-Backup, bevor Sie diesen Befehl ausführen.

WordPress-URLs mit cPanel konfigurieren

Wenn Sie WordPress auf einem VPS mit cPanel verwalten, können Sie den cPanel File Manager verwenden, um wp-config.php ohne SSH-Zugang zu bearbeiten:

1. Melden Sie sich bei cPanel an und öffnen Sie den File Manager.
2. Navigieren Sie zu Ihrem WordPress-Dokumenten-Root (typischerweise public_html oder ein Unterverzeichnis).
3. Klicken Sie mit der rechten Maustaste auf wp-config.php und wählen Sie Bearbeiten.
4. Fügen Sie die Konstanten WP_HOME und WP_SITEURL wie in Methode 2 gezeigt hinzu.
5. Speichern Sie die Datei.

Alternativ können Sie das phpMyAdmin-Tool in cPanel verwenden, um die SQL-UPDATE-Anweisungen aus Methode 4 direkt gegen Ihre WordPress-Datenbank auszuführen.

Kritische Fallstricke und Sonderfälle

Protokollkonflikt zwischen den zwei Einstellungen. Das Setzen von WP_SITEURL auf https://example.com und WP_HOME auf http://example.com (oder umgekehrt) erzeugt eine Weiterleitungsschleife. Der Browser folgt der HTTPS-Weiterleitung vom Server, aber WordPress generiert HTTP-Frontend-Links, die der Server dann wieder zu HTTPS weiterleitet. Diese Schleife ist im Dashboard unsichtbar, aber verheerend für Crawler und Benutzer.

Inkonsistenz bei abschließenden Schrägstrichen. WordPress reagiert empfindlich auf abschließende Schrägstriche in diesen Konstanten. https://example.com und https://example.com/ werden als unterschiedliche Werte behandelt. Lassen Sie den abschließenden Schrägstrich in beiden Konstanten immer weg, um den internen Erwartungen von WordPress zu entsprechen.

Objekt-Cache-Vergiftung nach URL-Änderung. Wenn Ihr Server einen persistenten Objekt-Cache (Redis oder Memcached) betreibt, können die alten URL-Werte im Speicher gecacht sein, selbst nachdem die Datenbank aktualisiert wurde. Leeren Sie den Objekt-Cache sofort nach jeder URL-Änderung:

wp cache flush --path=/var/www/html

Serialisierte Daten in der Datenbank. WordPress speichert viele Optionswerte und Beitrags-Metadaten als PHP-serialisierte Strings. Ein einfacher Zeichenkettenersatz (z. B. mit sed auf einem Datenbank-Dump) korrumpiert serialisierte Daten, indem Byte-Zählpräfixe ungültig gemacht werden. Verwenden Sie immer den WP-CLI-Befehl search-replace, der die Serialisierung korrekt behandelt.

Multisite-Netzwerk-Überlegungen. In einer WordPress-Multisite-Installation gilt WP_SITEURL für den Netzwerk-Admin, nicht für einzelne Subsites. Jede Subsite hat ihre eigenen siteurl– und home-Einträge in ihrer jeweiligen wp_X_options-Tabelle. Eine netzwerkweite URL-Änderung erfordert die Aktualisierung der Optionstabelle jeder Subsite, was WP-CLI mit dem --network-Flag handhabt:

wp search-replace 'http://old-domain.com' 'https://new-domain.com' --all-tables --network --path=/var/www/html

Vertrauen in Reverse-Proxy-Header. Auf Servern hinter einem Load Balancer oder Nginx-Reverse-Proxy erkennt WordPress möglicherweise das falsche Protokoll, wenn der Proxy den X-Forwarded-Proto-Header nicht weiterleitet. Selbst mit korrekten URL-Konstanten können interne Links auf HTTP zurückfallen. Fügen Sie Folgendes zu wp-config.php hinzu, um die HTTPS-Erkennung zu erzwingen:

if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && 'https' === $_SERVER['HTTP_X_FORWARDED_PROTO'] ) {
    $_SERVER['HTTPS'] = 'on';
}

Überprüfung der Konfiguration nach Änderungen

Nach der Aktualisierung eines der URL-Parameter führen Sie die folgenden Überprüfungsschritte durch, bevor Sie die Änderung als abgeschlossen betrachten:

# Confirm wp_options values reflect the change
wp option get siteurl --path=/var/www/html
wp option get home --path=/var/www/html

# Check for mixed-content issues using curl
curl -sI https://example.com | grep -i location

# Verify the REST API is reachable at the correct base
curl -s https://example.com/wp-json/ | python3 -m json.tool | head -20

# Confirm no HTTP references remain in post content
wp search-replace --dry-run 'http://example.com' 'https://example.com' --all-tables --path=/var/www/html

Das --dry-run-Flag beim letzten Befehl gibt an, wie viele Ersetzungen vorgenommen würden, ohne die Daten tatsächlich zu ändern. Wenn die Anzahl null ist, ist die Migration sauber.

Für Teams, die mehrere WordPress-Instanzen in Shared Web Hosting– oder VPS-Umgebungen verwalten, eliminiert die Automatisierung dieses Überprüfungsschritts in einem Post-Deployment-Skript das Risiko, eine Website mit veralteten URL-Referenzen zu starten.

Entscheidungsmatrix: Welche Methode verwenden

Technische Checkliste der wichtigsten Erkenntnisse

• Aktualisieren Sie WP_SITEURL und WP_HOME immer gemeinsam, es sei denn, Sie benötigen absichtlich das Unterverzeichnis-Muster.
• Definieren Sie Konstanten in wp-config.php auf Produktionsservern, um versehentliche UI-Überschreibungen zu verhindern.
• Leeren Sie nach jeder URL-Änderung den Objekt-Cache und führen Sie wp search-replace mit --all-tables aus, um serialisierte Daten zu erfassen.
• Aktualisieren Sie bei HTTP-zu-HTTPS-Migrationen zuerst die URL-Konstanten, führen Sie dann die Suche und Ersetzung durch und überprüfen Sie anschließend mit curl auf Mixed-Content.
• Bei Unterverzeichnis-Installationen muss die Root-index.php-Datei auf den Unterverzeichnispfad verweisen, und .htaccess muss RewriteBase / verwenden.
• Verwenden Sie niemals einen abschließenden Schrägstrich in den Konstanten WP_HOME oder WP_SITEURL.
• Fügen Sie bei Reverse-Proxy-Setups die HTTP_X_FORWARDED_PROTO-Erkennung zu wp-config.php hinzu, da WordPress sonst unabhängig von den URL-Einstellungen falsche Protokollreferenzen generiert.
• In Multisite muss die wp_X_options-Tabelle jeder Subsite unabhängig aktualisiert werden; verwenden Sie das --network-Flag mit WP-CLI.

Häufig gestellte Fragen

Was passiert, wenn WordPress Address und Site Address ohne das Unterverzeichnis-Setup unterschiedlich sind?

WordPress versucht, Kerndateien von dem in WP_SITEURL angegebenen Pfad zu laden. Wenn unter diesem Pfad keine WordPress-Installation vorhanden ist, geben alle Admin-Anfragen 404-Fehler oder einen weißen Bildschirm zurück. Das Frontend lädt möglicherweise noch, wenn WP_HOME korrekt ist und die Rewrite-Regeln intakt sind, aber jede AJAX-Anfrage, jeder REST API-Aufruf oder jede Admin-Aktion schlägt fehl.

Kann ich WP_HOME und WP_SITEURL auf unterschiedliche Protokolle setzen (eines HTTP, eines HTTPS)?

Nein. Das Mischen von Protokollen zwischen den zwei Konstanten erzeugt eine Weiterleitungsschleife, die weder Browser noch Crawler auflösen können. Beide Konstanten müssen dasselbe Protokoll verwenden. Wenn Sie HTTPS auf Serverebene erzwingen (über Nginx oder Apache), müssen beide Konstanten https:// verwenden.

Warum ist das WordPress Address-Feld in Einstellungen > Allgemein ausgegraut?

Das Feld ist schreibgeschützt, weil WP_SITEURL (oder WP_HOME) als PHP-Konstante in wp-config.php definiert ist. Im Code definierte Konstanten haben Vorrang vor Datenbankwerten und können nicht über die Benutzeroberfläche überschrieben werden. Um das Feld wieder bearbeitbar zu machen, entfernen oder kommentieren Sie die entsprechende define()-Zeile in wp-config.php aus.

Beeinflusst die Änderung der Site Address meine SEO und bestehenden Backlinks?

Ja. Das Ändern von WP_HOME ändert die kanonische Basis-URL für jede Seite Ihrer Website. Ohne ordnungsgemäße 301-Weiterleitungen von der alten URL-Struktur zur neuen behandeln Suchmaschinen die alten und neuen URLs als separate Seiten, was die Link-Equity aufteilt und möglicherweise Duplicate-Content-Strafen auslöst. Konfigurieren Sie immer serverseitige 301-Weiterleitungen vor oder gleichzeitig mit der URL-Änderung.

Wie kann ich mich erholen, wenn ich die falsche URL eingegeben habe und nun aus wp-admin ausgesperrt bin?

Verbinden Sie sich über SSH mit Ihrem Server und definieren Sie die korrekten Konstanten in wp-config.php mit Methode 2, oder verwenden Sie WP-CLI, um die Optionen siteurl und home direkt über Methode 3 zu aktualisieren. Wenn keines davon verfügbar ist, verwenden Sie phpMyAdmin oder eine direkte MySQL-Verbindung, um die UPDATE-Anweisungen aus Methode 4 auszuführen. Sobald der Zugang wiederhergestellt ist, entfernen Sie alle temporären Konstanten, wenn Sie möchten, dass das Dashboard die Werte weiterhin verwaltet.