Wie man “wordpress” aus Ihrer Website-URL entfernt (Vollständige technische Anleitung)

Wenn WordPress in ein Unterverzeichnis namens /wordpress installiert wird, enthält jede öffentlich zugängliche URL dieses Pfadsegment — yourdomain.com/wordpress/about, yourdomain.com/wordpress/shop — was die Markenglaubwürdigkeit untergräbt und das SEO-Potenzial verwässert. Die Lösung ist eine kontrollierte Datei-Migration kombiniert mit Datenbank-URL-Aktualisierungen: Sie verschieben alle WordPress-Kerndateien aus dem Unterverzeichnis in das Dokumentenstammverzeichnis des Servers (public_html), aktualisieren die Einstellungen für WordPress-Adresse und Website-Adresse, regenerieren Rewrite-Regeln und richten 301-Weiterleitungen für alle indizierten Legacy-URLs ein. Eine Neuinstallation ist nicht erforderlich.

Dieser Leitfaden behandelt jede technische Ebene dieses Prozesses — Dateisystemoperationen, Datenbank-String-Ersetzung, .htaccess Rewrite-Logik, Weiterleitungsstrategie und Validierung nach der Migration — einschließlich Sonderfälle, die in den meisten Tutorials zu stillen Fehlern führen.

Warum WordPress in einem Unterverzeichnis landet

Das Verständnis der Grundursache verhindert, dass dasselbe Problem erneut auftritt. Die häufigsten Szenarien sind:

• Installer-Standardeinstellungen: Viele Ein-Klick-Installer (Softaculous, Installatron) verwenden standardmäßig einen Unterverzeichnispfad, wenn der Benutzer den Installationspfad nicht explizit auf / setzt.
• Staging-zu-Produktions-Überführung: Ein Entwickler installiert WordPress unter /wordpress zum Testen und die Website geht live, ohne eine Pfadkorrektur vorzunehmen.
• Multi-Site-Planung, die nie umgesetzt wurde: Jemand plante, mehrere CMSes unter einer Domain zu betreiben, und ordnete WordPress einem eigenen Ordner zu.
• cPanel Auto-Installer-Eigenheiten: In VPS mit cPanel-Umgebungen fügt der Installer manchmal den Anwendungsnamen als Unterverzeichnis hinzu, sofern dies nicht überschrieben wird.

Unabhängig vom Ursprung ist das Migrationsverfahren identisch.

Checkliste vor der Migration

Bevor Sie eine einzige Datei anfassen, vervollständigen Sie jeden Punkt auf dieser Liste. Das Überspringen auch nur eines Punktes ist die häufigste Ursache für Ausfallzeiten bei diesem Vorgang.

• Vollständiges Website-Backup: Archivieren Sie sowohl das Dateisystem als auch die MySQL-Datenbank. Plugins wie UpdraftPlus oder Duplicator eignen sich gut; ebenso ein serverseitiger Snapshot, wenn Ihr VPS Hosting-Anbieter dies unterstützt.
• Datenbank-Zugangsdaten zur Hand: Sie werden diese benötigen, falls eine manuelle wp-config.php-Bearbeitung erforderlich wird.
• Wartungsmodus aktiviert: Verwenden Sie ein Plugin oder fügen Sie vorübergehend define('WP_MAINTENANCE_MODE', true); hinzu, um Schreibvorgänge während des Migrationsfensters zu verhindern.
• PHP-Fehlerprotokollierung aktiviert: Setzen Sie WP_DEBUG_LOG auf true in wp-config.php, damit alle Fehler nach der Migration in /wp-content/debug.log geschrieben werden, anstatt auf dem Bildschirm zu erscheinen.
• DNS-TTL notiert: Wenn auch eine DNS-Änderung involviert ist, senken Sie die TTL mindestens eine Stunde vor dem Start auf 300 Sekunden.

Schritt 1: WordPress-Dateien in das Dokumentenstammverzeichnis verschieben

Das Ziel ist es, alles innerhalb von /public_html/wordpress/ direkt in /public_html/ zu kopieren — nicht den Ordner selbst, sondern seinen Inhalt.

Mit einem FTP-Client (FileZilla)

1. Verbinden Sie sich mit Ihrem Server über SFTP (Port 22) anstatt über einfaches FTP, um das Abfangen von Zugangsdaten zu vermeiden.
2. Navigieren Sie zu public_html/wordpress/.
3. Wählen Sie alle Dateien und Ordner einschließlich versteckter Dateien aus. Aktivieren Sie in FileZilla Ansicht > Versteckte Dateien anzeigen, um .htaccess und alle .env-Dateien sichtbar zu machen.
4. Ziehen Sie die Auswahl eine Verzeichnisebene nach oben in public_html/.
5. Wenn Sie aufgefordert werden, index.php zu überschreiben (falls ein Platzhalter im Stammverzeichnis vorhanden ist), bestätigen Sie das Überschreiben.

Mit der Befehlszeile (Empfohlen für VPS)

Wenn Sie SSH-Zugang haben — was Sie auf jedem ordnungsgemäß konfigurierten VPS Hosting– oder Dedicated Server-System haben sollten — ist der Befehlszeilenansatz schneller und vermeidet FTP-Timeout-Probleme bei großen Installationen:

# Navigate to the document root
cd /var/www/html/public_html

# Copy all contents (including hidden files) from the subdirectory to the root
cp -a wordpress/. .

# Verify the copy succeeded before deleting anything
ls -la | head -30

Löschen Sie das /wordpress-Verzeichnis noch nicht. Lassen Sie es intakt, bis die Migration vollständig validiert ist. Sie können es im abschließenden Bereinigungsschritt entfernen.

Kritischer Sonderfall: Symlinks und absolute Pfade in Plugins

Einige Plugins (insbesondere Backup- und Sicherheits-Plugins) speichern absolute Dateipfade in der Datenbank — zum Beispiel /var/www/html/public_html/wordpress/wp-content/uploads/2024/01/image.jpg. Diese werden nach dem Verschieben stillschweigend fehlschlagen. Die Datenbank-Suche-und-Ersetzen in Schritt 5 behandelt dies, aber Sie müssen die wp_options-Tabelle und alle benutzerdefinierten Plugin-Tabellen in den Ersetzungsbereich einbeziehen.

Schritt 2: WordPress-Adresse und Website-Adresse aktualisieren

WordPress speichert zwei kritische URL-Werte in der wp_options-Tabelle: siteurl (die WordPress-Adresse, die auf den Speicherort der WordPress-Kerndateien verweist) und home (die Website-Adresse, die URL, die Besucher verwenden, um die Website zu erreichen). Beide müssen aktualisiert werden.

Methode A: WordPress-Dashboard

1. Melden Sie sich bei yourdomain.com/wordpress/wp-admin an — dies funktioniert noch, da sich die Dateien zu diesem Zeitpunkt noch an beiden Speicherorten befinden.
2. Gehen Sie zu Einstellungen > Allgemein.
3. Aktualisieren Sie beide Felder:

• WordPress-Adresse (URL): https://yourdomain.com
• Website-Adresse (URL): https://yourdomain.com

1. Klicken Sie auf Änderungen speichern.

Methode B: Direkte Datenbankbearbeitung (wenn das Dashboard nicht zugänglich ist)

Wenn das Dashboard bereits nicht erreichbar ist, verwenden Sie WP-CLI oder phpMyAdmin:

# Using WP-CLI from the document root
wp option update siteurl 'https://yourdomain.com'
wp option update home 'https://yourdomain.com'

Oder führen Sie in phpMyAdmin folgendes aus:

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

Ersetzen Sie wp_ durch Ihr tatsächliches Tabellenpräfix, falls es während der Installation geändert wurde.

Methode C: Temporäre wp-config.php-Überschreibung

Wenn sowohl das Dashboard als auch die Datenbank vorübergehend nicht zugänglich sind, fügen Sie diese zwei Zeilen zu wp-config.php als Bootstrap-Überschreibung hinzu:

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

Dies überschreibt alles, was in der Datenbank gespeichert ist. Entfernen Sie diese Zeilen, nachdem Sie bestätigt haben, dass das Dashboard zugänglich ist und die Datenbankwerte dauerhaft aktualisiert wurden.

Schritt 3: Die .htaccess-Datei überprüfen und aktualisieren

Die .htaccess-Datei im Dokumentenstammverzeichnis steuert Apaches URL-Rewriting für WordPress. Nach dem Verschieben der Dateien sollte diese Datei bereits in public_html/ vorhanden sein — aber ihre RewriteBase-Direktive muss die neue Installation auf Stammebene widerspiegeln.

Öffnen Sie public_html/.htaccess und stellen Sie sicher, dass es genau den folgenden 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

Die wesentliche Änderung gegenüber einer Unterverzeichnis-Installation ist RewriteBase / anstelle von RewriteBase /wordpress/. Wenn diese Zeile falsch ist, geben alle Pretty-Permalinks 404-Fehler zurück, während die Startseite korrekt lädt — ein klassisches Diagnosemerkmal einer falsch konfigurierten RewriteBase.

Nginx-Benutzer: WordPress verwendet kein .htaccess. Aktualisieren Sie stattdessen die try_files-Direktive Ihres Server-Blocks:

location / {
    try_files $uri $uri/ /index.php?$args;
}

Schritt 4: Permalink-Struktur leeren

WordPress speichert die Rewrite-Regeln in der Datenbank zwischen. Nach dem Ändern der Website-URL referenzieren diese zwischengespeicherten Regeln die alte Pfadstruktur und müssen neu generiert werden.

1. Gehen Sie im WordPress-Dashboard zu Einstellungen > Permalinks.
2. Klicken Sie auf Änderungen speichern, ohne die ausgewählte Permalink-Struktur zu ändern.

Dies zwingt WordPress, die Rewrite-Regeln gegen den neuen Pfad auf Stammebene neu zu erstellen und zwischenzuspeichern. Alternativ können Sie WP-CLI verwenden:

wp rewrite flush --hard

Das --hard-Flag regeneriert die .htaccess-Datei zusätzlich zum Leeren des Datenbank-Caches — nützlich, wenn Sie nicht sicher sind, ob die .htaccess korrekt ist.

Schritt 5: Datenbankweite URL-Ersetzung

Das Verschieben von Dateien und das Aktualisieren von siteurl/home ist nicht ausreichend. WordPress speichert serialisierte URL-Strings in der gesamten Datenbank — in Post-Inhalten, Postmeta, Widget-Einstellungen, Theme-Optionen und Plugin-Konfigurationstabellen. Alle verbleibenden /wordpress-Pfadreferenzen führen zu defekten Bildern, falschen Canonical-Tags und fehlerhaften Plugin-Funktionen.

Mit dem Better Search Replace Plugin

1. Installieren und aktivieren Sie das Better Search Replace-Plugin.
2. Gehen Sie zu Werkzeuge > Better Search Replace.
3. Konfigurieren Sie die Ersetzung:

• Suchen nach: https://yourdomain.com/wordpress
• Ersetzen durch: https://yourdomain.com

1. Wählen Sie alle Datenbanktabellen aus.
2. Deaktivieren Sie Als Probelauf ausführen? erst, nachdem Sie bestätigt haben, dass der Probelauf die erwartete Anzahl von Ersetzungen anzeigt.
3. Klicken Sie auf Suchen/Ersetzen ausführen.

Führen Sie auch einen zweiten Durchlauf für den absoluten Serverpfad durch:

• Suchen nach: /public_html/wordpress
• Ersetzen durch: /public_html

Mit WP-CLI (Bevorzugt für Produktionsumgebungen)

WP-CLIs search-replace-Befehl verarbeitet serialisierte Daten korrekt, was die einfache SQL-REPLACE()-Funktion nicht tut:

wp search-replace 'https://yourdomain.com/wordpress' 'https://yourdomain.com' --all-tables --precise --report-changed-only

Führen Sie einen zweiten Durchlauf für absolute Dateisystempfade durch:

wp search-replace '/public_html/wordpress' '/public_html' --all-tables --precise --report-changed-only

Das --precise-Flag verwendet PHPs serialisierungsbewusste Ersetzung anstelle von Regex, was eine Beschädigung serialisierter Arrays in der Datenbank verhindert.

Schritt 6: 301-Weiterleitungen für SEO-Kontinuität implementieren

Wenn die Website öffentlich unter /wordpress-URLs zugänglich war — und insbesondere wenn diese URLs von Google indiziert oder von externen Quellen verlinkt wurden — sind permanente Weiterleitungen zwingend erforderlich, nicht optional. Ohne sie wird jede indizierte URL zu einem 404-Fehler, und das gesamte angesammelte Link-Potenzial geht verloren.

Fügen Sie die folgende Weiterleitungsregel zu public_html/.htaccess hinzu, oberhalb des WordPress-Rewrite-Blocks:

# Redirect legacy /wordpress/ URLs to root
RewriteEngine On
RewriteRule ^wordpress/(.*)$ /$1 [R=301,L]

Diese Regel erfasst alle Anfragen, die mit wordpress/ beginnen, und leitet sie zum entsprechenden Pfad auf Stammebene weiter. Zum Beispiel:

• yourdomain.com/wordpress/about/ → yourdomain.com/about/
• yourdomain.com/wordpress/wp-admin/ → yourdomain.com/wp-admin/

Wichtiger Hinweis zur Platzierung: Dieser Weiterleitungsblock muss vor dem # BEGIN WordPress-Kommentar erscheinen. WordPresss eigene Rewrite-Regeln fangen die Anfrage zuerst ab, wenn die Weiterleitung danach platziert wird.

Für Nginx fügen Sie dies zum Server-Block hinzu:

rewrite ^/wordpress/(.*)$ /$1 permanent;

Schritt 7: Validierung nach der Migration

Systematische Tests verhindern, dass stille Fehler in der Produktion unentdeckt bleiben.

Funktionale Überprüfungen

Befehlszeilen-Validierung

# Verify the homepage returns 200
curl -I https://yourdomain.com

# Verify the legacy URL issues a 301
curl -I https://yourdomain.com/wordpress/

# Check that wp-admin is reachable
curl -I https://yourdomain.com/wp-admin/

Google Search Console

Reichen Sie die aktualisierte Sitemap in der Google Search Console unmittelbar nach der Validierung ein. Verwenden Sie das URL-Prüfung-Tool, um eine Neuindizierung der Startseite anzufordern. Überwachen Sie den Abdeckung-Bericht in den folgenden 48–72 Stunden auf einen Anstieg von 404-Fehlern, was auf verpasste URL-Ersetzungen hinweisen würde.

Schritt 8: Bereinigung und abschließende Härtung

Sobald die Website 24–48 Stunden stabil unter der Stamm-URL läuft:

1. Löschen Sie das /wordpress-Unterverzeichnis vom Server. Wenn es bestehen bleibt, entsteht ein Risiko für doppelte Inhalte und es wird ein sekundärer Einstiegspunkt zur WordPress-Installation freigelegt.

rm -rf /var/www/html/public_html/wordpress

1. Entfernen Sie die WP_MAINTENANCE_MODE-Konstante aus wp-config.php, falls Sie sie hinzugefügt haben.
2. Entfernen Sie die temporären WP_HOME/WP_SITEURL-Definitionen aus wp-config.php, falls Sie Methode C in Schritt 2 verwendet haben.
3. SSL-Abdeckung überprüfen: Wenn Ihr SSL-Zertifikat für yourdomain.com/wordpress als pfadbasierter Geltungsbereich ausgestellt wurde (ungewöhnlich, aber in einigen Konfigurationen möglich), bestätigen Sie, dass das Zertifikat die Apex-Domain korrekt abdeckt.
4. Aktualisieren Sie alle externen DNS- oder CDN-Konfigurationen, die möglicherweise die alte Pfadstruktur zwischengespeichert haben.
5. Alle Caching-Ebenen leeren: Löschen Sie den serverseitigen Seiten-Cache, den Objekt-Cache (Redis/Memcached) und den CDN-Cache. Veraltete Cache-Einträge für /wordpress-URLs liefern auch nach Abschluss der Migration falsche Inhalte.

Vergleich: Migrationsmethoden auf einen Blick

Für jede Umgebung mit SSH-Zugang — einschließlich Dedicated Server und nicht verwaltete VPS-Instanzen — ist der WP-CLI-Ansatz die zuverlässigste und fehlerunanfälligste Option.

Technische Entscheidungsmatrix

Verwenden Sie diese Matrix, um zu bestimmen, welche Schritte für Ihr spezifisches Szenario obligatorisch oder situationsabhängig sind:

Wichtigste Erkenntnisse

• Der Kernvorgang ist: Dateien in das Dokumentenstammverzeichnis kopieren, siteurl und home in der Datenbank aktualisieren, .htaccess RewriteBase korrigieren, serialisierungsbewusstes Suchen-Ersetzen ausführen, 301-Weiterleitungen hinzufügen.
• Verwenden Sie niemals ein einfaches SQL-REPLACE() auf WordPress-Tabellen ohne Serialisierungsbehandlung — es beschädigt Optionswerte und bricht Plugins stillschweigend.
• Die .htaccess RewriteBase /-Direktive ist das am häufigsten falsch konfigurierte Element bei dieser Migration; ein falscher Wert erzeugt 404-Fehler bei allen permalink-basierten URLs, während die Startseite weiterhin lädt.
• 301-Weiterleitungen sind nicht kosmetisch — sie übertragen Link-Potenzial und verhindern Index-Fragmentierung. Sie sind für jede Website mit bestehender Suchsichtbarkeit obligatorisch.
• Löschen Sie das ursprüngliche /wordpress-Verzeichnis erst nach einem 24-stündigen stabilen Beobachtungsfenster.
• Wenn Sie WordPress auf einem VPS mit cPanel betreiben, verwenden Sie die Option Versteckte Dateien anzeigen im Dateimanager, um sicherzustellen, dass .htaccess in den Kopiervorgang einbezogen wird.

Häufig gestellte Fragen

Wirkt sich das Entfernen von /wordpress aus der URL auf meine SEO-Rankings aus?

Kurzfristig sind leichte Ranking-Schwankungen zu erwarten, während Googlebot die neuen URLs neu crawlt. Wenn 301-Weiterleitungen korrekt implementiert sind, wird das Link-Potenzial vollständig übertragen und die Rankings stabilisieren sich typischerweise innerhalb von zwei bis vier Wochen. Das Überspringen der 301-Weiterleitungen führt zu einem dauerhaften Ranking-Verlust für alle zuvor indizierten Seiten.

Was tun, wenn mein WordPress-Dashboard nach dem Verschieben der Dateien nicht zugänglich ist?

Die häufigste Ursache ist eine Diskrepanz zwischen dem siteurl-Wert in der Datenbank und dem tatsächlichen Dateispeicherort. Verwenden Sie WP-CLI (wp option update siteurl) oder fügen Sie define('WP_SITEURL', 'https://yourdomain.com'); zu wp-config.php als temporäre Überschreibung hinzu, um den Zugang wiederherzustellen.

Muss ich wp-config.php aktualisieren, nachdem ich WordPress in das Stammverzeichnis verschoben habe?

In den meisten Fällen nein. Die wp-config.php-Datei verwendet relative Pfade für die Datenbankverbindung und kodiert den Installationspfad nicht fest. Die Ausnahme ist, wenn ABSPATH manuell als absoluter Pfad definiert wurde, der auf das alte /wordpress-Verzeichnis zeigt — in diesem Fall aktualisieren oder entfernen Sie diese Zeile.

Warum sind Bilder nach der Ausführung von Better Search Replace immer noch defekt?

Dies bedeutet normalerweise, dass das Plugin gegen eine Teilmenge von Tabellen ausgeführt wurde und benutzerdefinierte Plugin-Tabellen oder die wp_postmeta-Tabelle verpasst hat. Führen Sie die Ersetzung erneut mit allen ausgewählten Tabellen aus und überprüfen Sie auch absolute Dateisystempfade (z. B. /public_html/wordpress/wp-content/uploads/) zusätzlich zu den URL-basierten Strings.

Wie gehe ich damit bei einer WordPress Multisite-Installation um?

Multisite erfordert zusätzliche Konstanten in wp-config.php (DOMAIN_CURRENT_SITE, PATH_CURRENT_SITE) und die Website-URLs des Netzwerks müssen sowohl in den wp_site– als auch in den wp_blogs-Tabellen aktualisiert werden. Das Standard-Einzelseiten-Verfahren ist unzureichend — behandeln Sie dies als vollständige Netzwerk-Migration und testen Sie zuerst auf einem Staging-Klon.