Adres WordPress a Adres Witryny: Różnice Techniczne, Konfiguracja i Typowe Pułapki

WordPress Address (URL) i Site Address (URL) to dwa odrębne parametry konfiguracyjne, które kontrolują odpowiednio: miejsce przechowywania plików rdzenia WordPress na serwerze oraz adres URL, którego użytkownicy używają do uzyskania dostępu do front-endu witryny. W większości standardowych instalacji obie wartości są identyczne, jednak mogą — a czasem muszą — się różnić, gdy pliki WordPress są hostowane w podkatalogu, a witryna jest serwowana z domeny głównej.

Błędne ustawienie tych dwóch wartości, nawet o jeden znak, może zablokować dostęp do panelu administracyjnego, wywołać ostrzeżenia o mieszanej zawartości, uszkodzić punkty końcowe REST API i zepsuć łańcuchy przekierowań. Poniższe sekcje wyjaśniają logikę architektoniczną każdego ustawienia, wszystkie uzasadnione scenariusze ich zmiany oraz dokładne metody bezpiecznego wprowadzania zmian.

Logika Architektoniczna Dwóch Parametrów URL

WordPress przechowuje konfigurację URL jednocześnie w dwóch miejscach: w tabeli bazy danych wp_options (wiersze siteurl i home) oraz opcjonalnie w pliku wp-config.php za pomocą stałych PHP. Zrozumienie, które źródło ma pierwszeństwo, jest niezbędne przed wprowadzeniem jakichkolwiek zmian.

Kolejność priorytetów (od najwyższego do najniższego):

1. Stałe zdefiniowane w wp-config.php (WP_SITEURL, WP_HOME)
2. Wartości przechowywane w tabeli wp_options
3. Wartości wprowadzone w Ustawienia > Ogólne w panelu administracyjnym

Gdy stała jest zdefiniowana w wp-config.php, odpowiednie pole w Ustawienia > Ogólne staje się tylko do odczytu i jest wyszarzone. Jest to zamierzone działanie — zapobiega przypadkowemu nadpisaniu przez interfejs użytkownika, jednocześnie umożliwiając kontrolę programową.

WordPress Address (URL) — WP_SITEURL

WordPress Address odpowiada opcji siteurl w wp_options oraz stałej WP_SITEURL w wp-config.php. Informuje WordPress, gdzie fizycznie znajdują się jego podstawowe pliki PHP, katalog wp-admin i katalog wp-includes. WordPress używa tej wartości do konstruowania każdego wewnętrznego odwołania do ścieżki pliku, w tym adresu URL logowania do panelu administracyjnego, punktów końcowych AJAX (/wp-admin/admin-ajax.php) i bazy REST API (/wp-json/).

Przykład: jeśli instalacja WordPress znajduje się pod adresem https://example.com/wordpress, to WP_SITEURL musi być ustawione na https://example.com/wordpress. Przejście do https://example.com/wordpress/wp-admin spowoduje otwarcie panelu administracyjnego.

Site Address (URL) — WP_HOME

Site Address odpowiada opcji home w wp_options oraz stałej WP_HOME w wp-config.php. Definiuje kanoniczny publiczny adres URL — adres wpisywany przez użytkowników w przeglądarkach oraz bazę, na podstawie której WordPress generuje wszystkie struktury permalinków front-endu.

Przykład: nawet jeśli pliki rdzenia znajdują się pod adresem https://example.com/wordpress, możesz ustawić WP_HOME na https://example.com, aby strona główna, wpisy i strony były serwowane z domeny głównej. Wymaga to dodatkowego pliku index.php i reguły .htaccess w katalogu głównym (omówione poniżej).

Porównanie: WordPress Address a Site Address

Kiedy Te Dwie Wartości Muszą Się Różnić

Najczęstszym uzasadnionym powodem rozdzielenia WP_SITEURL i WP_HOME jest wzorzec instalacji w podkatalogu: chcesz, aby pliki WordPress były izolowane w czystym podkatalogu (np. /wordpress lub /cms), podczas gdy publiczna witryna jest dostępna pod domeną główną. Jest to świadomy wybór architektoniczny, a nie obejście problemu.

Inne scenariusze wymagające aktualizacji jednej lub obu wartości:

• Migracja domeny — przeniesienie z http://old-domain.com na https://new-domain.com wymaga jednoczesnej aktualizacji obu wartości.
• Przejście z HTTP na HTTPS — dodanie certyfikatu SSL oznacza zmianę prefiksu protokołu w obu ustawieniach z http:// na https://. Aktualizacja tylko jednego z nich powoduje błędy mieszanej zawartości.
• Przeniesienie ze środowiska testowego na produkcyjne — środowisko testowe zazwyczaj działa na subdomenie lub innej domenie; obie wartości muszą zostać przepisane podczas wdrożenia.
• Odciążenie przez reverse proxy lub CDN — gdy load balancer lub CDN kończy połączenie SSL i przekazuje ruch do serwera backend, ustawienia URL WordPress muszą odzwierciedlać domenę publiczną, a nie wewnętrzny adres serwera.
• Rekonfiguracja sieci Multisite — w WordPress Multisite, WP_SITEURL i WP_HOME współdziałają ze stałymi DOMAIN_CURRENT_SITE i PATH_CURRENT_SITE, co sprawia, że prawidłowa konfiguracja jest jeszcze bardziej krytyczna.

Metoda 1: Aktualizacja przez Panel Administracyjny WordPress

Jest to odpowiednia metoda, gdy nadal masz dostęp do panelu administracyjnego, a zmiana jest prosta (np. HTTP na HTTPS na tej samej domenie).

1. Zaloguj się do https://yourdomain.com/wp-admin.
2. Przejdź do Ustawienia > Ogólne.
3. Znajdź pola WordPress Address (URL) i Site Address (URL).
4. Zaktualizuj obie wartości zgodnie z wymaganiami.
5. Kliknij Zapisz zmiany.

WordPress natychmiast przekieruje Cię na zaktualizowany adres URL panelu administracyjnego. Jeśli zmieniłeś domenę, przeglądarka podąży za przekierowaniem do nowego adresu. Jeśli nowa domena nie jest jeszcze rozwiązywana do serwera, utracisz dostęp do panelu administracyjnego — zaplanuj propagację DNS odpowiednio wcześniej.

Metoda 2: Definiowanie Stałych w wp-config.php

Ta metoda jest preferowana na serwerach produkcyjnych, ponieważ zapobiega przypadkowym zmianom przez interfejs użytkownika, działa nawet gdy baza danych jest tymczasowo niedostępna i jest łatwa do kontroli wersji. W środowisku VPS Hosting z dostępem SSH do roota jest to najbardziej niezawodne podejście.

Otwórz wp-config.php w preferowanym edytorze:

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

Dodaj następujące dwie linie powyżej komentarza /* That's all, stop editing! */:

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

Dla wzorca instalacji w podkatalogu, gdzie pliki rdzenia znajdują się w /wordpress, ale witryna jest serwowana z katalogu głównego:

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

Zapisz i zamknij plik. Pola w panelu administracyjnym będą teraz tylko do odczytu, co jest oczekiwanym zachowaniem.

Instalacja w Podkatalogu: Wymagane Kroki dla .htaccess i index.php

Gdy WP_HOME i WP_SITEURL różnią się, sam WordPress nie może kierować żądań z domeny głównej do plików rdzenia w podkatalogu. Musisz umieścić zmodyfikowany plik index.php i plik .htaccess w katalogu głównym dokumentów.

Krok 1: Skopiuj index.php z podkatalogu WordPress do katalogu głównego:

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

Krok 2: Edytuj skopiowany /var/www/html/index.php, aby wskazywał na podkatalog:

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

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

Krok 3: Upewnij się, że Twój główny .htaccess zawiera standardowy 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

Nie kopiuj .htaccess z podkatalogu — będzie zawierał RewriteBase /wordpress/, co zepsuje routing domeny głównej.

Metoda 3: Bezpośrednia Aktualizacja Bazy Danych przez WP-CLI

Gdy panel administracyjny jest niedostępny i wolisz nie modyfikować wp-config.php na stałe, WP-CLI zapewnia czyste, skryptowalne rozwiązanie. Jest to szczególnie przydatne na Serwerach Dedykowanych obsługujących zautomatyzowane potoki wdrożeniowe.

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

Aby zweryfikować, czy zmiana została zastosowana:

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

WP-CLI respektuje stałe wp-config.php — jeśli WP_SITEURL lub WP_HOME są już tam zdefiniowane, polecenie wp option update nie nadpisze ich. Musisz zaktualizować stałe bezpośrednio w pliku.

Metoda 4: Bezpośrednia Aktualizacja MySQL (Ostateczność)

Użyj tej metody tylko wtedy, gdy dostęp SSH jest dostępny, ale WP-CLI nie jest zainstalowany, a panel administracyjny jest zablokowany. Najpierw zidentyfikuj prefiks tabeli (sprawdź $table_prefix w wp-config.php, zazwyczaj 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';

Potwierdź aktualizację:

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

Wyjdź z MySQL i wyczyść pamięć podręczną obiektów (Redis, Memcached lub OPcache) przed przetestowaniem witryny.

Konfiguracja SSL i Aktualizacje URL

Przejście z HTTP na HTTPS jest najczęstszym powodem jednoczesnej aktualizacji obu parametrów URL. Po zainstalowaniu certyfikatu SSL — czy to przez Let’s Encrypt za pomocą Certbot, czy certyfikatu komercyjnego od dostawcy, takiego jak dostępne przez Certyfikaty SSL — musisz zaktualizować zarówno WP_HOME, jak i WP_SITEURL, aby używały prefiksu https://.

Nieaktualizowanie obu lub aktualizacja tylko jednego powoduje ostrzeżenia o mieszanej zawartości: przeglądarka otrzymuje stronę HTTPS, która odwołuje się do zasobów HTTP (skrypty, arkusze stylów, obrazy). Nowoczesne przeglądarki całkowicie blokują aktywną mieszaną zawartość, co psuje funkcjonalność JavaScript i panel administracyjny.

Po zaktualizowaniu stałych URL uruchom wyszukiwanie i zamianę w bazie danych, aby zaktualizować wszystkie serializowane adresy URL przechowywane w treści wpisów, postmeta i opcjach:

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

Flaga --all-tables zapewnia, że serializowane dane w niestandardowych tabelach (WooCommerce, kreatory stron) są również aktualizowane. Zawsze wykonaj kopię zapasową bazy danych przed uruchomieniem tego polecenia.

Konfigurowanie URL WordPress za pomocą cPanel

Jeśli zarządzasz WordPress na VPS z cPanel, możesz użyć Menedżera Plików cPanel do edycji wp-config.php bez konieczności dostępu SSH:

1. Zaloguj się do cPanel i otwórz Menedżer Plików.
2. Przejdź do katalogu głównego dokumentów WordPress (zazwyczaj public_html lub podkatalog).
3. Kliknij prawym przyciskiem myszy wp-config.php i wybierz Edytuj.
4. Dodaj stałe WP_HOME i WP_SITEURL jak pokazano w Metodzie 2.
5. Zapisz plik.

Alternatywnie użyj narzędzia phpMyAdmin w cPanel, aby uruchomić instrukcje SQL UPDATE z Metody 4 bezpośrednio na bazie danych WordPress.

Krytyczne Pułapki i Przypadki Brzegowe

Niezgodność protokołów między dwoma ustawieniami. Ustawienie WP_SITEURL na https://example.com i WP_HOME na http://example.com (lub odwrotnie) tworzy pętlę przekierowań. Przeglądarka podąża za przekierowaniem HTTPS z serwera, ale WordPress generuje linki front-endu HTTP, które serwer następnie przekierowuje z powrotem do HTTPS. Ta pętla jest niewidoczna w panelu administracyjnym, ale katastrofalna dla crawlerów i użytkowników.

Niespójność końcowego ukośnika. WordPress jest wrażliwy na końcowe ukośniki w tych stałych. https://example.com i https://example.com/ są traktowane jako różne wartości. Zawsze pomijaj końcowy ukośnik w obu stałych, aby spełnić wewnętrzne oczekiwania WordPress.

Zatruwanie pamięci podręcznej obiektów po zmianie URL. Jeśli Twój serwer używa trwałej pamięci podręcznej obiektów (Redis lub Memcached), stare wartości URL mogą być przechowywane w pamięci nawet po aktualizacji bazy danych. Wyczyść pamięć podręczną obiektów natychmiast po każdej zmianie URL:

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

Serializowane dane w bazie danych. WordPress przechowuje wiele wartości opcji i metadanych wpisów jako serializowane ciągi PHP. Naiwne zastępowanie ciągów (np. użycie sed na zrzucie bazy danych) uszkodzi serializowane dane przez unieważnienie prefiksów liczby bajtów. Zawsze używaj polecenia search-replace WP-CLI, które poprawnie obsługuje serializację.

Uwagi dotyczące sieci Multisite. W instalacji WordPress Multisite, WP_SITEURL dotyczy administratora sieci, a nie poszczególnych podwitryn. Każda podwitryna ma własne wpisy siteurl i home w swojej tabeli wp_X_options. Zmiana URL obejmująca całą sieć wymaga aktualizacji tabeli opcji każdej podwitryny, co WP-CLI obsługuje za pomocą flagi --network:

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

Zaufanie do nagłówków reverse proxy. Na serwerach za load balancerem lub reverse proxy Nginx, WordPress może wykryć nieprawidłowy protokół, jeśli proxy nie przekazuje nagłówka X-Forwarded-Proto. Nawet przy prawidłowych stałych URL, wewnętrzne linki mogą powracać do HTTP. Dodaj następujące elementy do wp-config.php, aby wymusić wykrywanie HTTPS:

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

Weryfikacja Konfiguracji Po Zmianach

Po zaktualizowaniu któregokolwiek parametru URL wykonaj następujące kroki weryfikacji przed uznaniem zmiany za zakończoną:

# 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

Flaga --dry-run w ostatnim poleceniu raportuje, ile zamian zostałoby wykonanych bez faktycznej modyfikacji danych. Jeśli liczba wynosi zero, migracja jest czysta.

Dla zespołów zarządzających wieloma instancjami WordPress na Hostingu Współdzielonym lub środowiskach VPS, automatyzacja tego kroku weryfikacji w skrypcie po wdrożeniu eliminuje ryzyko uruchomienia witryny z nieaktualnymi odwołaniami URL.

Macierz Decyzyjna: Którą Metodę Wybrać

Lista Kontrolna Kluczowych Wniosków Technicznych

• Zawsze aktualizuj WP_SITEURL i WP_HOME razem, chyba że celowo potrzebujesz wzorca podkatalogu.
• Definiuj stałe w wp-config.php na serwerach produkcyjnych, aby zapobiec przypadkowemu nadpisaniu przez interfejs użytkownika.
• Po każdej zmianie URL wyczyść pamięć podręczną obiektów i uruchom wp search-replace z --all-tables, aby wychwycić serializowane dane.
• W przypadku migracji z HTTP na HTTPS najpierw zaktualizuj stałe URL, następnie uruchom wyszukiwanie i zamianę, a potem zweryfikuj za pomocą curl pod kątem mieszanej zawartości.
• W instalacjach w podkatalogu, główny index.php musi odwoływać się do ścieżki podkatalogu, a .htaccess musi używać RewriteBase /.
• Nigdy nie używaj końcowego ukośnika w stałych WP_HOME lub WP_SITEURL.
• W konfiguracjach z reverse proxy dodaj wykrywanie HTTP_X_FORWARDED_PROTO do wp-config.php, w przeciwnym razie WordPress będzie generował nieprawidłowe odwołania do protokołu niezależnie od ustawień URL.
• W Multisite, tabela wp_X_options każdej podwitryny musi być aktualizowana niezależnie; używaj flagi --network z WP-CLI.

Często Zadawane Pytania

Co się stanie, jeśli WordPress Address i Site Address różnią się bez konfiguracji podkatalogu?

WordPress spróbuje załadować pliki rdzenia ze ścieżki określonej w WP_SITEURL. Jeśli pod tą ścieżką nie istnieje żadna instalacja WordPress, wszystkie żądania do panelu administracyjnego będą zwracać błędy 404 lub biały ekran. Front-end może nadal działać, jeśli WP_HOME jest prawidłowy i reguły przepisywania są nienaruszone, ale każde żądanie AJAX, wywołanie REST API lub akcja administracyjna zakończy się niepowodzeniem.

Czy mogę ustawić WP_HOME i WP_SITEURL na różne protokoły (jeden HTTP, jeden HTTPS)?

Nie. Mieszanie protokołów między dwiema stałymi tworzy pętlę przekierowań, której ani przeglądarki, ani crawlery nie mogą rozwiązać. Obie stałe muszą używać tego samego protokołu. Jeśli wymuszasz HTTPS na poziomie serwera (przez Nginx lub Apache), obie stałe muszą używać https://.

Dlaczego pole WordPress Address jest wyszarzone w Ustawienia > Ogólne?

Pole jest tylko do odczytu, ponieważ WP_SITEURL (lub WP_HOME) jest zdefiniowane jako stała PHP w wp-config.php. Stałe zdefiniowane w kodzie mają pierwszeństwo przed wartościami bazy danych i nie mogą być nadpisane przez interfejs użytkownika. Aby ponownie umożliwić edycję pola, usuń lub zakomentuj odpowiednią linię define() w wp-config.php.

Czy zmiana Site Address wpływa na SEO i istniejące linki zwrotne?

Tak. Zmiana WP_HOME zmienia kanoniczny bazowy adres URL każdej strony w Twojej witrynie. Bez odpowiednich przekierowań 301 ze starej struktury URL do nowej, wyszukiwarki będą traktować stare i nowe adresy URL jako oddzielne strony, dzieląc kapitał linków i potencjalnie wywołując kary za zduplikowaną treść. Zawsze konfiguruj przekierowania 301 na poziomie serwera przed zmianą URL lub jednocześnie z nią.

Jak odzyskać dostęp, jeśli wprowadziłem błędny URL i jestem teraz zablokowany w wp-admin?

Połącz się z serwerem przez SSH i zdefiniuj prawidłowe stałe w wp-config.php używając Metody 2, lub użyj WP-CLI do bezpośredniej aktualizacji opcji siteurl i home przez Metodę 3. Jeśli żadna z nich nie jest dostępna, użyj phpMyAdmin lub bezpośredniego połączenia MySQL, aby uruchomić instrukcje UPDATE z Metody 4. Po przywróceniu dostępu usuń wszelkie tymczasowe stałe, jeśli wolisz, aby panel administracyjny zarządzał wartościami w przyszłości.