Adresa WordPress vs Adresa Site-ului: Diferențe Tehnice, Configurare și Capcane Comune

WordPress Address (URL) și Site Address (URL) sunt doi parametri de configurare distincți care controlează, respectiv, unde se află fișierele de bază WordPress pe server și ce URL folosește publicul pentru a accesa interfața publică a site-ului dvs. În majoritatea instalărilor standard, ambele valori sunt identice, dar pot — și uneori trebuie — să difere atunci când găzduiți fișierele WordPress într-un subdirector în timp ce serviți site-ul de la domeniul rădăcină.

Dacă aceste două valori sunt greșite, chiar și cu un singur caracter, vă puteți bloca accesul la panoul de administrare, pot apărea avertismente de conținut mixt, se pot defecta endpoint-urile REST API și se pot corupe lanțurile de redirecționare. Secțiunile de mai jos explică logica arhitecturală din spatele fiecărei setări, fiecare scenariu legitim pentru modificarea acestora și metodele exacte pentru a face acest lucru în siguranță.

Logica Arhitecturală din Spatele celor Doi Parametri URL

WordPress stochează configurația URL în două locuri simultan: tabelul de baze de date wp_options (rândurile siteurl și home) și, opțional, fișierul wp-config.php prin constante PHP. Înțelegerea sursei care are prioritate este esențială înainte de a modifica orice.

Ordinea priorităților (de la cea mai mare la cea mai mică):

1. Constante definite în wp-config.php (WP_SITEURL, WP_HOME)
2. Valori stocate în tabelul wp_options
3. Valori introduse în Settings > General din panoul de administrare

Când o constantă este definită în wp-config.php, câmpul corespunzător din Settings > General devine doar pentru citire și apare gri. Acest lucru este intenționat — previne suprascrierile accidentale prin interfața UI, permițând în același timp controlul programatic.

WordPress Address (URL) — WP_SITEURL

WordPress Address corespunde opțiunii siteurl din wp_options și constantei WP_SITEURL din wp-config.php. Îi spune WordPress-ului unde se află fizic fișierele PHP de bază, directorul wp-admin și directorul wp-includes. WordPress folosește această valoare pentru a construi fiecare referință internă la calea fișierului, inclusiv URL-ul de autentificare în administrare, endpoint-urile AJAX (/wp-admin/admin-ajax.php) și baza REST API (/wp-json/).

Exemplu: dacă instalarea WordPress se află la https://example.com/wordpress, atunci WP_SITEURL trebuie să fie https://example.com/wordpress. Navigând la https://example.com/wordpress/wp-admin veți ajunge la panoul de administrare.

Site Address (URL) — WP_HOME

Site Address corespunde opțiunii home din wp_options și constantei WP_HOME din wp-config.php. Definește URL-ul public canonic — adresa pe care utilizatorii o introduc în browserele lor și baza din care WordPress generează toate structurile de permalink pentru interfața publică.

Exemplu: chiar dacă fișierele de bază se află la https://example.com/wordpress, puteți seta WP_HOME la https://example.com astfel încât pagina principală, postările și paginile să fie servite de la domeniul rădăcină. Aceasta necesită un fișier index.php suplimentar și o regulă .htaccess la rădăcină (detaliate mai jos).

Comparație: WordPress Address vs Site Address

Când Aceste Două Valori Trebuie să Difere

Cel mai comun motiv legitim pentru a separa WP_SITEURL și WP_HOME este modelul de instalare în subdirector: doriți ca fișierele WordPress să fie izolate într-un subdirector curat (de ex., /wordpress sau /cms) în timp ce site-ul public se rezolvă la domeniul rădăcină. Aceasta este o alegere arhitecturală deliberată, nu o soluție de compromis.

Alte scenarii care necesită actualizarea uneia sau a ambelor valori:

• Migrarea domeniului — mutarea de la http://old-domain.com la https://new-domain.com necesită actualizarea ambelor valori simultan.
• Actualizarea de la HTTP la HTTPS — adăugarea unui certificat SSL înseamnă schimbarea prefixului de protocol în ambele setări de la http:// la https://. Actualizarea doar a uneia produce erori de conținut mixt.
• Promovarea din staging în producție — un mediu de staging rulează de obicei pe un subdomeniu sau un domeniu diferit; ambele valori trebuie rescrise în timpul implementării.
• Reverse proxy sau descărcare CDN — când un load balancer sau CDN termină SSL și redirecționează traficul către un server backend, setările URL WordPress trebuie să reflecte domeniul public, nu adresa serverului intern.
• Reconfigurarea rețelei Multisite — în WordPress Multisite, WP_SITEURL și WP_HOME interacționează cu constantele DOMAIN_CURRENT_SITE și PATH_CURRENT_SITE, făcând configurarea corectă și mai critică.

Metoda 1: Actualizare prin Panoul de Administrare WordPress

Aceasta este metoda potrivită atunci când aveți în continuare acces de administrator și modificarea este simplă (de ex., de la HTTP la HTTPS pe același domeniu).

1. Autentificați-vă la https://yourdomain.com/wp-admin.
2. Navigați la Settings > General.
3. Localizați câmpurile WordPress Address (URL) și Site Address (URL).
4. Actualizați ambele valori după cum este necesar.
5. Faceți clic pe Save Changes.

WordPress vă va redirecționa imediat către URL-ul actualizat al panoului de administrare. Dacă ați schimbat domeniul, browserul dvs. va urma redirecționarea către noua adresă. Dacă noul domeniu nu se rezolvă încă la server, veți pierde accesul la panoul de administrare — planificați propagarea DNS în consecință.

Metoda 2: Definirea Constantelor în wp-config.php

Această metodă este preferată pe serverele de producție deoarece previne modificările accidentale prin interfața UI, funcționează chiar și atunci când baza de date este temporar indisponibilă și poate fi ușor versionată. Într-un mediu de VPS Hosting cu acces SSH root, aceasta este cea mai fiabilă abordare.

Deschideți wp-config.php în editorul preferat:

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

Adăugați următoarele două linii deasupra comentariului /* That's all, stop editing! */:

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

Pentru modelul de instalare în subdirector unde fișierele de bază se află în /wordpress dar site-ul este servit de la rădăcină:

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

Salvați și închideți fișierul. Câmpurile din panoul de administrare vor fi acum doar pentru citire, ceea ce este comportamentul așteptat.

Instalare în Subdirector: Pașii Necesari pentru .htaccess și index.php

Când WP_HOME și WP_SITEURL diferă, WordPress singur nu poate direcționa cererile de la domeniul rădăcină către fișierele de bază din subdirector. Trebuie să plasați un fișier index.php modificat și un fișier .htaccess la rădăcina documentului.

Pasul 1: Copiați index.php din subdirectorul WordPress la rădăcină:

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

Pasul 2: Editați fișierul /var/www/html/index.php copiat pentru a indica subdirectorul:

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

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

Pasul 3: Asigurați-vă că fișierul .htaccess de la rădăcină conține blocul standard de rescriere 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

Nu copiați fișierul .htaccess din subdirector — va conține RewriteBase /wordpress/ care va defecta rutarea domeniului rădăcină.

Metoda 3: Actualizare Directă a Bazei de Date prin WP-CLI

Când panoul de administrare este inaccesibil și preferați să nu modificați permanent wp-config.php, WP-CLI oferă o soluție curată și scriptabilă. Aceasta este deosebit de utilă pe Servere Dedicate care rulează pipeline-uri de implementare automatizate.

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

Pentru a verifica dacă modificarea a fost aplicată:

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

WP-CLI respectă constantele wp-config.php — dacă WP_SITEURL sau WP_HOME sunt deja definite acolo, comanda wp option update nu le va suprascrie. Trebuie să actualizați constantele direct în fișier.

Metoda 4: Actualizare Directă MySQL (Ultimă Soluție)

Folosiți aceasta doar când accesul SSH este disponibil, dar WP-CLI nu este instalat și panoul de administrare este blocat. Identificați mai întâi prefixul tabelului (verificați $table_prefix în wp-config.php, de obicei 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';

Confirmați actualizarea:

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

Ieșiți din MySQL și ștergeți orice cache de obiecte (Redis, Memcached sau OPcache) înainte de a testa site-ul.

Configurarea SSL și Actualizările URL

Actualizarea de la HTTP la HTTPS este cel mai frecvent motiv pentru a actualiza simultan ambii parametri URL. După instalarea unui certificat SSL — fie prin Let’s Encrypt via Certbot, fie printr-un certificat comercial de la un furnizor precum cele disponibile prin Certificate SSL — trebuie să actualizați atât WP_HOME cât și WP_SITEURL pentru a utiliza prefixul https://.

Neactualizarea ambelor, sau actualizarea doar a uneia, produce avertismente de conținut mixt: browserul primește o pagină HTTPS care face referire la resurse HTTP (scripturi, foi de stil, imagini). Browserele moderne blochează complet conținutul activ mixt, ceea ce defectează funcționalitatea JavaScript și panoul de administrare.

După actualizarea constantelor URL, rulați o căutare și înlocuire în baza de date pentru a actualiza toate URL-urile serializate stocate în conținutul postărilor, postmeta și opțiuni:

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

Flag-ul --all-tables asigură că datele serializate din tabelele personalizate (WooCommerce, page builders) sunt de asemenea actualizate. Faceți întotdeauna o copie de rezervă a bazei de date înainte de a rula această comandă.

Configurarea URL-urilor WordPress cu cPanel

Dacă gestionați WordPress pe un VPS cu cPanel, puteți utiliza File Manager din cPanel pentru a edita wp-config.php fără a necesita acces SSH:

1. Autentificați-vă în cPanel și deschideți File Manager.
2. Navigați la rădăcina documentului WordPress (de obicei public_html sau un subdirector).
3. Faceți clic dreapta pe wp-config.php și selectați Edit.
4. Adăugați constantele WP_HOME și WP_SITEURL așa cum este arătat în Metoda 2.
5. Salvați fișierul.

Alternativ, utilizați instrumentul phpMyAdmin din cPanel pentru a rula instrucțiunile SQL UPDATE din Metoda 4 direct împotriva bazei de date WordPress.

Capcane Critice și Cazuri Limită

Nepotrivirea protocolului între cele două setări. Setarea WP_SITEURL la https://example.com și WP_HOME la http://example.com (sau invers) creează o buclă de redirecționare. Browserul urmează redirecționarea HTTPS de la server, dar WordPress generează link-uri HTTP pentru interfața publică, pe care serverul le redirecționează înapoi la HTTPS. Această buclă este invizibilă în panoul de administrare, dar devastatoare pentru crawlere și utilizatori.

Inconsistența slash-ului final. WordPress este sensibil la slash-urile finale în aceste constante. https://example.com și https://example.com/ sunt tratate ca valori diferite. Omiteți întotdeauna slash-ul final în ambele constante pentru a corespunde așteptărilor interne ale WordPress.

Otrăvirea cache-ului de obiecte după schimbarea URL-ului. Dacă serverul dvs. rulează un cache de obiecte persistent (Redis sau Memcached), valorile vechi ale URL-ului pot fi stocate în memorie chiar și după actualizarea bazei de date. Ștergeți cache-ul de obiecte imediat după orice schimbare de URL:

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

Date serializate în baza de date. WordPress stochează multe valori de opțiuni și metadate ale postărilor ca șiruri serializate PHP. O înlocuire naivă a șirurilor (de ex., folosind sed pe un dump al bazei de date) va corupe datele serializate prin invalidarea prefixelor de număr de octeți. Folosiți întotdeauna comanda search-replace a WP-CLI, care gestionează corect serializarea.

Considerații pentru rețeaua Multisite. Într-o instalare WordPress Multisite, WP_SITEURL se aplică administratorului rețelei, nu subsiturilor individuale. Fiecare subsite are propriile intrări siteurl și home în tabelul wp_X_options respectiv. O schimbare de URL la nivel de rețea necesită actualizarea tabelului de opțiuni al fiecărui subsite, pe care WP-CLI îl gestionează cu flag-ul --network:

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

Încrederea în anteturile reverse proxy. Pe serverele din spatele unui load balancer sau reverse proxy Nginx, WordPress poate detecta protocolul greșit dacă proxy-ul nu transmite antetul X-Forwarded-Proto. Chiar și cu constante URL corecte, link-urile interne pot reveni la HTTP. Adăugați următoarele în wp-config.php pentru a forța detectarea HTTPS:

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

Verificarea Configurației după Modificări

După actualizarea oricărui parametru URL, efectuați următorii pași de verificare înainte de a considera modificarea completă:

# 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

Flag-ul --dry-run de pe ultima comandă raportează câte înlocuiri s-ar face fără a modifica efectiv datele. Dacă numărul este zero, migrarea este curată.

Pentru echipele care gestionează mai multe instanțe WordPress pe medii de Găzduire Web Shared sau VPS, automatizarea acestui pas de verificare într-un script post-implementare elimină riscul lansării unui site cu referințe URL învechite.

Matricea de Decizie: Ce Metodă să Folosiți

Listă de Verificare a Punctelor Tehnice Cheie

• Actualizați întotdeauna WP_SITEURL și WP_HOME împreună, cu excepția cazului în care aveți nevoie intenționat de modelul subdirectorului.
• Definiți constantele în wp-config.php pe serverele de producție pentru a preveni suprascrierile accidentale prin interfața UI.
• După orice schimbare de URL, ștergeți cache-ul de obiecte și rulați wp search-replace cu --all-tables pentru a prinde datele serializate.
• Pentru migrările de la HTTP la HTTPS, actualizați mai întâi constantele URL, apoi rulați search-replace, apoi verificați cu curl pentru conținut mixt.
• În instalările în subdirector, fișierul index.php de la rădăcină trebuie să facă referire la calea subdirectorului, iar .htaccess trebuie să folosească RewriteBase /.
• Nu folosiți niciodată un slash final în constantele WP_HOME sau WP_SITEURL.
• Pe configurațiile cu reverse proxy, adăugați detectarea HTTP_X_FORWARDED_PROTO în wp-config.php sau WordPress va genera referințe de protocol incorecte indiferent de setările URL.
• În Multisite, tabelul wp_X_options al fiecărui subsite trebuie actualizat independent; folosiți flag-ul --network cu WP-CLI.

Întrebări Frecvente

Ce se întâmplă dacă WordPress Address și Site Address sunt diferite fără configurarea subdirectorului?

WordPress va încerca să încarce fișierele de bază din calea specificată în WP_SITEURL. Dacă nu există nicio instalare WordPress la acea cale, toate cererile de administrare vor returna erori 404 sau un ecran alb. Interfața publică poate încă să se încarce dacă WP_HOME este corect și regulile de rescriere sunt intacte, dar orice cerere AJAX, apel REST API sau acțiune de administrare va eșua.

Pot seta WP_HOME și WP_SITEURL la protocoale diferite (unul HTTP, unul HTTPS)?

Nu. Amestecarea protocoalelor între cele două constante creează o buclă de redirecționare pe care nici browserele, nici crawlerele nu o pot rezolva. Ambele constante trebuie să folosească același protocol. Dacă impuneți HTTPS la nivel de server (prin Nginx sau Apache), ambele constante trebuie să folosească https://.

De ce câmpul WordPress Address este gri în Settings > General?

Câmpul este doar pentru citire deoarece WP_SITEURL (sau WP_HOME) este definit ca o constantă PHP în wp-config.php. Constantele definite în cod au prioritate față de valorile din baza de date și nu pot fi suprascrise prin interfața UI. Pentru a face câmpul editabil din nou, eliminați sau comentați linia define() corespunzătoare din wp-config.php.

Schimbarea Site Address afectează SEO-ul meu și backlink-urile existente?

Da. Schimbarea WP_HOME schimbă URL-ul canonic de bază pentru fiecare pagină de pe site-ul dvs. Fără redirecționări 301 corespunzătoare de la structura URL veche la cea nouă, motoarele de căutare vor trata URL-urile vechi și noi ca pagini separate, împărțind echitatea link-urilor și potențial declanșând penalități pentru conținut duplicat. Configurați întotdeauna redirecționări 301 la nivel de server înainte sau simultan cu schimbarea URL-ului.

Cum mă recuperez dacă am introdus URL-ul greșit și acum sunt blocat din wp-admin?

Conectați-vă la server prin SSH și definiți constantele corecte în wp-config.php folosind Metoda 2, sau folosiți WP-CLI pentru a actualiza opțiunile siteurl și home direct prin Metoda 3. Dacă niciuna nu este disponibilă, folosiți phpMyAdmin sau o conexiune MySQL directă pentru a rula instrucțiunile UPDATE din Metoda 4. Odată ce accesul este restaurat, eliminați orice constante temporare dacă preferați ca panoul de administrare să gestioneze valorile în continuare.