Jak usunąć “wordpress” z adresu URL swojej strony (kompletny przewodnik techniczny)

Gdy WordPress jest zainstalowany w podkatalogu o nazwie /wordpress, każdy publiczny adres URL zawiera ten segment ścieżki — yourdomain.com/wordpress/about, yourdomain.com/wordpress/shop — co podważa wiarygodność marki i osłabia wartość SEO. Rozwiązaniem jest kontrolowana migracja plików połączona z aktualizacją adresów URL w bazie danych: przenosisz wszystkie pliki rdzenia WordPress z podkatalogu do głównego katalogu dokumentów serwera (public_html), aktualizujesz ustawienia Adres WordPress i Adres witryny, regenerujesz reguły przepisywania i wystawiasz przekierowania 301 dla wszelkich zaindeksowanych starych adresów URL. Ponowna instalacja nie jest wymagana.

Ten przewodnik obejmuje każdą warstwę techniczną tego procesu — operacje na systemie plików, zastępowanie ciągów znaków w bazie danych, logikę przepisywania .htaccess, strategię przekierowań i walidację po migracji — w tym przypadki brzegowe, które powodują ciche błędy w większości poradników.

Dlaczego WordPress trafia do podkatalogu

Zrozumienie pierwotnej przyczyny zapobiega ponownemu wystąpieniu tego samego problemu. Najczęstsze scenariusze to:

• Domyślne ustawienia instalatora: Wiele instalatorów jednym kliknięciem (Softaculous, Installatron) domyślnie używa ścieżki podkatalogu, jeśli użytkownik nie ustawi jawnie ścieżki instalacji na /.
• Przeniesienie ze środowiska testowego do produkcyjnego: Deweloper instaluje WordPress pod adresem /wordpress do testów, a witryna zostaje uruchomiona bez korekty ścieżki.
• Planowanie wielu witryn, które nigdy nie doszło do skutku: Ktoś planował uruchomienie wielu CMS-ów pod jedną domeną i przypisał WordPress do własnego folderu.
• Dziwne zachowanie auto-instalatora cPanel: W środowiskach VPS z cPanel instalator czasami dodaje nazwę aplikacji jako podkatalog, jeśli nie zostanie to nadpisane.

Niezależnie od przyczyny, procedura migracji jest identyczna.

Lista kontrolna przed migracją

Przed dotknięciem choćby jednego pliku wykonaj każdy punkt z tej listy. Pominięcie któregokolwiek z nich jest główną przyczyną przestojów podczas tej operacji.

• Pełna kopia zapasowa witryny: Zarchiwizuj zarówno system plików, jak i bazę danych MySQL. Dobrze sprawdzają się wtyczki takie jak UpdraftPlus lub Duplicator; podobnie działa migawka na poziomie serwera, jeśli Twój dostawca VPS Hosting ją obsługuje.
• Dane dostępowe do bazy danych pod ręką: Będą potrzebne, jeśli konieczna okaże się ręczna edycja wp-config.php.
• Aktywny tryb konserwacji: Użyj wtyczki lub tymczasowo dodaj define('WP_MAINTENANCE_MODE', true);, aby zapobiec zapisom podczas okna migracji.
• Włączone logowanie błędów PHP: Ustaw WP_DEBUG_LOG na true w wp-config.php, aby wszelkie błędy po migracji były zapisywane do /wp-content/debug.log zamiast wyświetlać się na ekranie.
• Odnotowany TTL DNS: Jeśli planowana jest również zmiana DNS, obniż TTL do 300 sekund co najmniej godzinę przed rozpoczęciem.

Krok 1: Przeniesienie plików WordPress do głównego katalogu dokumentów

Celem jest skopiowanie wszystkiego, co znajduje się wewnątrz /public_html/wordpress/, bezpośrednio do /public_html/ — nie samego folderu, lecz jego zawartości.

Korzystanie z klienta FTP (FileZilla)

1. Połącz się z serwerem przez SFTP (port 22), a nie zwykłe FTP, aby uniknąć przechwycenia danych uwierzytelniających.
2. Przejdź do public_html/wordpress/.
3. Zaznacz wszystkie pliki i foldery, w tym ukryte. W FileZilla włącz opcję Widok > Pokaż ukryte pliki, aby wyświetlić .htaccess i wszelkie pliki .env.
4. Przeciągnij zaznaczenie o jeden poziom katalogu wyżej do public_html/.
5. Gdy pojawi się monit o nadpisanie index.php (jeśli w katalogu głównym istnieje plik zastępczy), potwierdź nadpisanie.

Korzystanie z wiersza poleceń (zalecane dla VPS)

Jeśli masz dostęp SSH — a powinieneś go mieć na każdym prawidłowo skonfigurowanym środowisku VPS Hosting lub Serwera Dedykowanego — podejście z wiersza poleceń jest szybsze i pozwala uniknąć problemów z przekroczeniem limitu czasu FTP przy dużych instalacjach:

# 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

Nie usuwaj jeszcze katalogu /wordpress. Pozostaw go nienaruszonym do momentu pełnej walidacji migracji. Możesz go usunąć w ostatnim kroku porządkowania.

Krytyczny przypadek brzegowy: dowiązania symboliczne i ścieżki bezwzględne we wtyczkach

Niektóre wtyczki (szczególnie wtyczki do tworzenia kopii zapasowych i zabezpieczeń) przechowują bezwzględne ścieżki do plików w bazie danych — na przykład /var/www/html/public_html/wordpress/wp-content/uploads/2024/01/image.jpg. Po przeniesieniu plików przestaną one działać bez żadnego komunikatu o błędzie. Wyszukiwanie i zastępowanie w bazie danych w Kroku 5 rozwiązuje ten problem, ale musisz uwzględnić tabelę wp_options oraz wszelkie niestandardowe tabele wtyczek w zakresie zastępowania.

Krok 2: Aktualizacja adresu WordPress i adresu witryny

WordPress przechowuje dwie kluczowe wartości adresów URL w tabeli wp_options: siteurl (adres WordPress, wskazujący miejsce przechowywania plików rdzenia WordPress) oraz home (adres witryny, adres URL używany przez odwiedzających do dotarcia do witryny). Obie wartości muszą zostać zaktualizowane.

Metoda A: Panel administracyjny WordPress

1. Zaloguj się do yourdomain.com/wordpress/wp-admin — nadal działa, ponieważ pliki są w tym momencie w obu lokalizacjach.
2. Przejdź do Ustawienia > Ogólne.
3. Zaktualizuj oba pola:

• Adres WordPress (URL): https://yourdomain.com
• Adres witryny (URL): https://yourdomain.com

1. Kliknij Zapisz zmiany.

Metoda B: Bezpośrednia edycja bazy danych (gdy panel administracyjny jest niedostępny)

Jeśli panel administracyjny jest już niedostępny, użyj WP-CLI lub phpMyAdmin:

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

Lub w phpMyAdmin uruchom:

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';

Zastąp wp_ rzeczywistym prefiksem tabeli, jeśli został zmieniony podczas instalacji.

Metoda C: Tymczasowe nadpisanie w wp-config.php

Jeśli zarówno panel administracyjny, jak i baza danych są tymczasowo niedostępne, dodaj te dwie linie do wp-config.php jako nadpisanie podczas uruchamiania:

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

Nadpisuje to wartości przechowywane w bazie danych. Usuń te linie po potwierdzeniu, że panel administracyjny jest dostępny i wartości w bazie danych zostały trwale zaktualizowane.

Krok 3: Weryfikacja i aktualizacja pliku .htaccess

Plik .htaccess w głównym katalogu dokumentów kontroluje przepisywanie adresów URL przez Apache dla WordPress. Po przeniesieniu plików plik ten powinien już znajdować się w public_html/ — ale jego dyrektywa RewriteBase musi odzwierciedlać nową instalację na poziomie katalogu głównego.

Otwórz public_html/.htaccess i upewnij się, że zawiera dokładnie następujący blok przepisywania WordPress:

# 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

Kluczową zmianą w stosunku do instalacji w podkatalogu jest RewriteBase / zamiast RewriteBase /wordpress/. Jeśli ta linia jest nieprawidłowa, wszystkie przyjazne bezpośrednie linki zwracają błędy 404, podczas gdy strona główna ładuje się poprawnie — klasyczny objaw diagnostyczny błędnie skonfigurowanego RewriteBase.

Użytkownicy Nginx: WordPress nie używa .htaccess. Zamiast tego zaktualizuj dyrektywę try_files w bloku serwera:

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

Krok 4: Odświeżenie struktury bezpośrednich linków

WordPress buforuje reguły przepisywania w bazie danych. Po zmianie adresu URL witryny te zbuforowane reguły odwołują się do starej struktury ścieżek i muszą zostać zregenerowane.

1. Przejdź do Ustawienia > Bezpośrednie linki w panelu administracyjnym WordPress.
2. Nie modyfikując wybranej struktury bezpośrednich linków, kliknij Zapisz zmiany.

Wymusza to na WordPress odbudowanie i zbuforowanie reguł przepisywania względem nowej ścieżki na poziomie katalogu głównego. Alternatywnie użyj WP-CLI:

wp rewrite flush --hard

Flaga --hard regeneruje plik .htaccess oprócz opróżniania pamięci podręcznej bazy danych — przydatne, jeśli nie masz pewności, czy .htaccess jest poprawny.

Krok 5: Zastępowanie adresów URL w całej bazie danych

Przeniesienie plików i aktualizacja siteurl/home nie wystarczy. WordPress przechowuje serializowane ciągi adresów URL w całej bazie danych — w treści wpisów, postmeta, ustawieniach widżetów, opcjach motywów i tabelach konfiguracji wtyczek. Wszelkie pozostałe odwołania do ścieżki /wordpress spowodują uszkodzone obrazy, nieprawidłowe tagi kanoniczne i nieprawidłowo działające funkcje wtyczek.

Korzystanie z wtyczki Better Search Replace

1. Zainstaluj i aktywuj wtyczkę Better Search Replace.
2. Przejdź do Narzędzia > Better Search Replace.
3. Skonfiguruj zastępowanie:

• Szukaj: https://yourdomain.com/wordpress
• Zastąp przez: https://yourdomain.com

1. Zaznacz wszystkie tabele bazy danych.
2. Odznacz opcję Uruchom jako próbny przebieg? dopiero po potwierdzeniu, że próbny przebieg pokazuje oczekiwaną liczbę zastąpień.
3. Kliknij Uruchom wyszukiwanie/zastępowanie.

Wykonaj również drugi przebieg dla bezwzględnej ścieżki serwera:

• Szukaj: /public_html/wordpress
• Zastąp przez: /public_html

Korzystanie z WP-CLI (preferowane dla środowisk produkcyjnych)

Polecenie search-replace w WP-CLI poprawnie obsługuje serializowane dane, czego zwykła funkcja SQL REPLACE() nie robi:

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

Wykonaj drugi przebieg dla bezwzględnych ścieżek systemu plików:

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

Flaga --precise używa zastępowania z obsługą serializacji PHP zamiast wyrażeń regularnych, co zapobiega uszkodzeniu serializowanych tablic przechowywanych w bazie danych.

Krok 6: Implementacja przekierowań 301 dla ciągłości SEO

Jeśli witryna była publicznie dostępna pod adresami URL /wordpress — a zwłaszcza jeśli te adresy URL zostały zaindeksowane przez Google lub są linkowane z zewnętrznych źródeł — stałe przekierowania są obowiązkowe, a nie opcjonalne. Bez nich każdy zaindeksowany adres URL staje się błędem 404, a cały zgromadzony kapitał linków zostaje utracony.

Dodaj następującą regułę przekierowania do public_html/.htaccess, powyżej bloku przepisywania WordPress:

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

Ta reguła przechwytuje każde żądanie zaczynające się od wordpress/ i przekierowuje je do równoważnej ścieżki na poziomie katalogu głównego. Na przykład:

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

Ważna uwaga dotycząca kolejności: Ten blok przekierowania musi pojawić się przed komentarzem # BEGIN WordPress. Własne reguły przepisywania WordPress przechwycą żądanie jako pierwsze, jeśli przekierowanie zostanie umieszczone po nich.

Dla Nginx dodaj to do bloku serwera:

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

Krok 7: Walidacja po migracji

Systematyczne testowanie zapobiega niezauważeniu cichych błędów w środowisku produkcyjnym.

Sprawdzenia funkcjonalne

Walidacja z wiersza poleceń

# 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

Prześlij zaktualizowaną mapę witryny w Google Search Console natychmiast po walidacji. Użyj narzędzia Sprawdzanie adresów URL, aby zażądać ponownego zaindeksowania strony głównej. Monitoruj raport Pokrycie przez następne 48–72 godziny pod kątem ewentualnego wzrostu liczby błędów 404, co wskazywałoby na pominięte zastąpienia adresów URL.

Krok 8: Porządkowanie i końcowe zabezpieczenie

Gdy witryna działa stabilnie pod głównym adresem URL przez 24–48 godzin:

1. Usuń podkatalog /wordpress z serwera. Pozostawienie go na miejscu stwarza ryzyko duplikowania treści i odsłania dodatkowy punkt wejścia do instalacji WordPress.

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

1. Usuń stałą WP_MAINTENANCE_MODE z wp-config.php, jeśli ją dodałeś.
2. Usuń tymczasowe definicje WP_HOME/WP_SITEURL z wp-config.php, jeśli użyłeś Metody C w Kroku 2.
3. Zweryfikuj pokrycie SSL: Jeśli Twój Certyfikat SSL został wystawiony dla yourdomain.com/wordpress jako zakres oparty na ścieżce (rzadkie, ale możliwe w niektórych konfiguracjach), potwierdź, że certyfikat poprawnie obejmuje domenę główną.
4. Zaktualizuj wszelkie zewnętrzne konfiguracje DNS lub CDN, które mogły zbuforować starą strukturę ścieżek.
5. Wyczyść wszystkie warstwy pamięci podręcznej: Wyczyść pamięć podręczną stron po stronie serwera, pamięć podręczną obiektów (Redis/Memcached) i pamięć podręczną CDN. Nieaktualne wpisy pamięci podręcznej dla adresów URL /wordpress będą serwować nieprawidłową treść nawet po zakończeniu migracji.

Porównanie: metody migracji w skrócie

Dla każdego środowiska z dostępem SSH — w tym Serwerów Dedykowanych i niezarządzanych instancji VPS — podejście z WP-CLI jest najbardziej niezawodną i najmniej podatną na błędy opcją.

Macierz decyzji technicznych

Użyj tej macierzy, aby określić, które kroki są obowiązkowe, a które opcjonalne w Twoim konkretnym scenariuszu:

Najważniejsze wnioski

• Podstawowa operacja to: skopiowanie plików do katalogu głównego dokumentów, aktualizacja siteurl i home w bazie danych, naprawienie .htaccess RewriteBase, uruchomienie wyszukiwania i zastępowania z obsługą serializacji, dodanie przekierowań 301.
• Nigdy nie używaj zwykłego SQL REPLACE() na tabelach WordPress bez obsługi serializacji — spowoduje to uszkodzenie wartości opcji i ciche awarie wtyczek.
• Dyrektywa .htaccess RewriteBase / jest najczęściej błędnie konfigurowanym elementem podczas tej migracji; nieprawidłowa wartość powoduje błędy 404 dla wszystkich adresów URL opartych na bezpośrednich linkach, podczas gdy strona główna nadal ładuje się poprawnie.
• Przekierowania 301 nie są kosmetyczne — przenoszą kapitał linków i zapobiegają fragmentacji indeksu. Są obowiązkowe dla każdej witryny z istniejącą widocznością w wyszukiwarkach.
• Usuń oryginalny katalog /wordpress dopiero po 24-godzinnym oknie stabilnej obserwacji.
• Jeśli korzystasz z WordPress na VPS z cPanel, użyj opcji Pokaż ukryte pliki w Menedżerze plików, aby upewnić się, że .htaccess jest uwzględniony w operacji kopiowania.

Często zadawane pytania

Czy usunięcie /wordpress z adresu URL wpłynie na moje pozycje w wynikach wyszukiwania?

Krótkoterminowo należy spodziewać się niewielkich wahań pozycji, gdy Googlebot ponownie przeszuka nowe adresy URL. Jeśli przekierowania 301 są poprawnie zaimplementowane, kapitał linków zostaje w pełni przeniesiony, a pozycje zazwyczaj stabilizują się w ciągu dwóch do czterech tygodni. Pominięcie przekierowań 301 powoduje trwałą utratę pozycji dla wszystkich wcześniej zaindeksowanych stron.

Co zrobić, jeśli panel administracyjny WordPress jest niedostępny po przeniesieniu plików?

Najczęstszą przyczyną jest niezgodność między wartością siteurl w bazie danych a rzeczywistą lokalizacją plików. Użyj WP-CLI (wp option update siteurl) lub dodaj define('WP_SITEURL', 'https://yourdomain.com'); do wp-config.php jako tymczasowe nadpisanie, aby przywrócić dostęp.

Czy po przeniesieniu WordPress do katalogu głównego muszę aktualizować wp-config.php?

W większości przypadków nie. Plik wp-config.php używa ścieżek względnych do połączenia z bazą danych i nie koduje na stałe ścieżki instalacji. Wyjątkiem jest sytuacja, gdy ABSPATH zostało ręcznie zdefiniowane jako ścieżka bezwzględna wskazująca na stary katalog /wordpress — w takim przypadku zaktualizuj lub usuń tę linię.

Dlaczego obrazy nadal są uszkodzone po uruchomieniu Better Search Replace?

Zazwyczaj oznacza to, że wtyczka działała na podzbiorze tabel i pominęła niestandardowe tabele wtyczek lub tabelę wp_postmeta. Uruchom ponownie zastępowanie z zaznaczonymi wszystkimi tabelami i sprawdź również bezwzględne ścieżki systemu plików (np. /public_html/wordpress/wp-content/uploads/) oprócz ciągów opartych na adresach URL.

Jak obsłużyć to w instalacji WordPress Multisite?

Multisite wymaga dodatkowych stałych w wp-config.php (DOMAIN_CURRENT_SITE, PATH_CURRENT_SITE), a adresy URL witryn w sieci muszą zostać zaktualizowane zarówno w tabelach wp_site, jak i wp_blogs. Standardowa procedura dla pojedynczej witryny jest niewystarczająca — potraktuj to jako pełną migrację sieci i najpierw przetestuj na kopii środowiska testowego.