Cum să Eliminați “wordpress” Din URL-ul Site-ului Dvs. (Ghid Tehnic Complet)

Când WordPress este instalat într-un subdirector numit /wordpress, fiecare URL public conține acel segment de cale — yourdomain.com/wordpress/about, yourdomain.com/wordpress/shop — ceea ce subminează credibilitatea brandului și diluează capitalul SEO. Soluția constă într-o migrare controlată a fișierelor combinată cu actualizări ale URL-urilor din baza de date: mutați toate fișierele de bază WordPress din subdirector în rădăcina documentelor serverului (public_html), actualizați setările WordPress Address și Site Address, regenerați regulile de rescriere și emiteți redirecționări 301 pentru orice URL-uri vechi indexate. Nu este necesară reinstalarea.

Acest ghid acoperă fiecare nivel tehnic al acestui proces — operațiuni pe sistemul de fișiere, înlocuirea șirurilor din baza de date, logica de rescriere .htaccess, strategia de redirecționare și validarea post-migrare — inclusiv cazurile limită care cauzează eșecuri silențioase în majoritatea tutorialelor.

De ce ajunge WordPress într-un subdirector

Înțelegerea cauzei principale previne reapariția aceleiași probleme. Cele mai frecvente scenarii sunt:

• Setări implicite ale programului de instalare: Multe programe de instalare cu un singur clic (Softaculous, Installatron) utilizează implicit o cale de subdirector dacă utilizatorul nu setează explicit calea de instalare la /.
• Promovarea din staging în producție: Un dezvoltator instalează WordPress la /wordpress pentru testare, iar site-ul devine live fără o corecție a căii.
• Planificare multi-site care nu s-a materializat: Cineva a anticipat rularea mai multor CMS-uri sub un singur domeniu și a limitat WordPress la propriul folder.
• Particularități ale programului de instalare automată cPanel: În mediile VPS cu cPanel, programul de instalare adaugă uneori numele aplicației ca subdirector dacă nu este suprascris.

Indiferent de origine, procedura de migrare este identică.

Listă de verificare pre-migrare

Înainte de a atinge un singur fișier, completați fiecare element de pe această listă. Omiterea oricăruia dintre ele este principala cauză a întreruperilor în timpul acestei operațiuni.

• Backup complet al site-ului: Arhivați atât sistemul de fișiere, cât și baza de date MySQL. Plugin-uri precum UpdraftPlus sau Duplicator funcționează bine; la fel și un snapshot la nivel de server dacă furnizorul dvs. de VPS Hosting îl suportă.
• Credențialele bazei de date la îndemână: Veți avea nevoie de ele dacă devine necesară o editare manuală a wp-config.php.
• Modul de mentenanță activ: Utilizați un plugin sau adăugați temporar define('WP_MAINTENANCE_MODE', true); pentru a preveni scrierile în timpul ferestrei de migrare.
• Jurnalizarea erorilor PHP activată: Setați WP_DEBUG_LOG la true în wp-config.php astfel încât orice erori post-migrare să fie scrise în /wp-content/debug.log în loc să apară pe ecran.
• TTL DNS notat: Dacă este implicată și o modificare DNS, reduceți TTL-ul la 300 de secunde cu cel puțin o oră înainte de a începe.

Pasul 1: Mutați fișierele WordPress în rădăcina documentelor

Scopul este de a copia tot ce se află în /public_html/wordpress/ direct în /public_html/ — nu folderul în sine, ci conținutul său.

Folosind un client FTP (FileZilla)

1. Conectați-vă la server prin SFTP (portul 22) mai degrabă decât FTP simplu pentru a evita interceptarea credențialelor.
2. Navigați la public_html/wordpress/.
3. Selectați toate fișierele și folderele, inclusiv fișierele ascunse. În FileZilla, activați View > Show Hidden Files pentru a expune .htaccess și orice fișiere .env.
4. Trageți selecția cu un nivel de director mai sus în public_html/.
5. Când vi se solicită suprascrierea index.php (dacă există un placeholder în rădăcină), confirmați suprascrierea.

Folosind linia de comandă (recomandat pentru VPS)

Dacă aveți acces SSH — ceea ce ar trebui să aveți pe orice mediu VPS Hosting sau Dedicated Server configurat corespunzător — abordarea prin linia de comandă este mai rapidă și evită problemele de timeout FTP la instalările mari:

# 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

Nu ștergeți încă directorul /wordpress. Lăsați-l intact până când migrarea este complet validată. Îl puteți elimina în pasul final de curățare.

Caz limită critic: Symlink-uri și căi absolute în plugin-uri

Unele plugin-uri (în special plugin-urile de backup și securitate) stochează căi absolute de fișiere în baza de date — de exemplu, /var/www/html/public_html/wordpress/wp-content/uploads/2024/01/image.jpg. Acestea se vor defecta silențios după mutare. Căutarea și înlocuirea în baza de date din Pasul 5 rezolvă acest lucru, dar trebuie să includeți tabelul wp_options și orice tabele personalizate ale plugin-urilor în domeniul de înlocuire.

Pasul 2: Actualizați WordPress Address și Site Address

WordPress stochează două valori URL critice în tabelul wp_options: siteurl (WordPress Address, indicând unde se află fișierele de bază WordPress) și home (Site Address, URL-ul pe care vizitatorii îl folosesc pentru a accesa site-ul). Ambele trebuie actualizate.

Metoda A: Panoul de administrare WordPress

1. Conectați-vă la yourdomain.com/wordpress/wp-admin — aceasta funcționează în continuare deoarece fișierele se află încă în ambele locații în acest moment.
2. Accesați Settings > General.
3. Actualizați ambele câmpuri:

• WordPress Address (URL): https://yourdomain.com
• Site Address (URL): https://yourdomain.com

1. Faceți clic pe Save Changes.

Metoda B: Editare directă a bazei de date (când panoul de administrare este inaccesibil)

Dacă panoul de administrare este deja inaccesibil, utilizați WP-CLI sau phpMyAdmin:

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

Sau în phpMyAdmin, rulați:

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

Înlocuiți wp_ cu prefixul real al tabelului dacă acesta a fost modificat în timpul instalării.

Metoda C: Suprascrierea temporară în wp-config.php

Dacă atât panoul de administrare, cât și baza de date sunt temporar inaccesibile, adăugați aceste două linii în wp-config.php ca suprascrierea de bootstrap:

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

Aceasta suprascrie orice este stocat în baza de date. Eliminați aceste linii după confirmarea că panoul de administrare este accesibil și că valorile din baza de date au fost actualizate permanent.

Pasul 3: Verificați și actualizați fișierul .htaccess

Fișierul .htaccess din rădăcina documentelor controlează rescrierea URL-urilor Apache pentru WordPress. După mutarea fișierelor, acest fișier ar trebui să se afle deja în public_html/ — dar directiva sa RewriteBase trebuie să reflecte noua instalare la nivel de rădăcină.

Deschideți public_html/.htaccess și asigurați-vă că conține exact următorul bloc 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

Modificarea cheie față de o instalare în subdirector este RewriteBase / în loc de RewriteBase /wordpress/. Dacă această linie este greșită, toate permalink-urile frumoase returnează erori 404 în timp ce pagina principală se încarcă corect — o semnătură de diagnostic clasică a unui RewriteBase configurat greșit.

Utilizatori Nginx: WordPress nu folosește .htaccess. Actualizați în schimb directiva try_files a blocului de server:

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

Pasul 4: Resetați structura permalink-urilor

WordPress stochează în cache regulile de rescriere în baza de date. După modificarea URL-ului site-ului, acele reguli stocate în cache fac referire la structura veche a căii și trebuie regenerate.

1. Accesați Settings > Permalinks în panoul de administrare WordPress.
2. Fără a modifica structura de permalink selectată, faceți clic pe Save Changes.

Aceasta forțează WordPress să reconstruiască și să stocheze în cache regulile de rescriere față de noua cale la nivel de rădăcină. Alternativ, utilizați WP-CLI:

wp rewrite flush --hard

Indicatorul --hard regenerează fișierul .htaccess pe lângă golirea cache-ului bazei de date — util dacă nu sunteți sigur dacă .htaccess este corect.

Pasul 5: Înlocuirea URL-urilor la nivelul întregii baze de date

Mutarea fișierelor și actualizarea siteurl/home nu este suficientă. WordPress stochează șiruri URL serializate în întreaga bază de date — în conținutul postărilor, postmeta, setările widget-urilor, opțiunile temei și tabelele de configurare ale plugin-urilor. Orice referințe rămase la calea /wordpress vor produce imagini rupte, etichete canonice incorecte și funcționalități defecte ale plugin-urilor.

Folosind plugin-ul Better Search Replace

1. Instalați și activați plugin-ul Better Search Replace.
2. Accesați Tools > Better Search Replace.
3. Configurați înlocuirea:

• Search for: https://yourdomain.com/wordpress
• Replace with: https://yourdomain.com

1. Selectați toate tabelele bazei de date.
2. Debifați Run as dry run? numai după confirmarea că rularea de test arată numărul așteptat de înlocuiri.
3. Faceți clic pe Run Search/Replace.

Rulați și o a doua trecere pentru calea absolută a serverului:

• Search for: /public_html/wordpress
• Replace with: /public_html

Folosind WP-CLI (preferat pentru producție)

Comanda search-replace a WP-CLI gestionează corect datele serializate, ceea ce funcția SQL naivă REPLACE() nu face:

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

Rulați o a doua trecere pentru căile absolute ale sistemului de fișiere:

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

Indicatorul --precise utilizează înlocuirea conștientă de serializare a PHP în loc de regex, ceea ce previne coruperea array-urilor serializate stocate în baza de date.

Pasul 6: Implementați redirecționări 301 pentru continuitatea SEO

Dacă site-ul a fost accesibil public la URL-uri /wordpress — și mai ales dacă acele URL-uri au fost indexate de Google sau legate din surse externe — redirecționările permanente sunt obligatorii, nu opționale. Fără ele, fiecare URL indexat devine un 404, iar tot capitalul de link-uri acumulat se pierde.

Adăugați următoarea regulă de redirecționare în public_html/.htaccess, deasupra blocului de rescriere WordPress:

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

Această regulă captează orice cerere care începe cu wordpress/ și o redirecționează către calea echivalentă la nivel de rădăcină. De exemplu:

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

Notă importantă privind plasarea: Acest bloc de redirecționare trebuie să apară înainte de comentariul # BEGIN WordPress. Regulile de rescriere proprii ale WordPress vor intercepta cererea mai întâi dacă redirecționarea este plasată după ele.

Pentru Nginx, adăugați aceasta în blocul de server:

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

Pasul 7: Validarea post-migrare

Testarea sistematică previne ca eșecurile silențioase să treacă nedetectate în producție.

Verificări funcționale

Validare prin linia de comandă

# 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

Trimiteți sitemap-ul actualizat în Google Search Console imediat după validare. Utilizați instrumentul URL Inspection pentru a solicita re-indexarea paginii principale. Monitorizați raportul Coverage în următoarele 48–72 de ore pentru orice creștere a erorilor 404, care ar indica înlocuiri de URL-uri ratate.

Pasul 8: Curățare și consolidare finală

Odată ce site-ul a funcționat stabil la URL-ul rădăcină timp de 24–48 de ore:

1. Ștergeți subdirectorul /wordpress de pe server. Lăsarea lui în loc creează un risc de conținut duplicat și expune un punct de intrare secundar în instalarea WordPress.

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

1. Eliminați constanta WP_MAINTENANCE_MODE din wp-config.php dacă ați adăugat-o.
2. Eliminați definițiile temporare WP_HOME/WP_SITEURL din wp-config.php dacă ați folosit Metoda C din Pasul 2.
3. Verificați acoperirea SSL: Dacă Certificatul SSL a fost emis pentru yourdomain.com/wordpress ca domeniu de aplicare bazat pe cale (neobișnuit, dar posibil în unele configurații), confirmați că certificatul acoperă corect domeniul apex.
4. Actualizați orice configurații externe DNS sau CDN care ar putea fi stocat în cache structura veche a căii.
5. Goliți toate straturile de cache: Ștergeți cache-ul de pagini la nivel de server, cache-ul de obiecte (Redis/Memcached) și cache-ul CDN. Intrările de cache expirate pentru URL-urile /wordpress vor servi conținut incorect chiar și după finalizarea migrării.

Comparație: Metode de migrare dintr-o privire

Pentru orice mediu cu acces SSH — inclusiv Servere Dedicate și instanțe VPS neadministrate — abordarea WP-CLI este cea mai fiabilă și mai puțin predispusă la erori.

Matricea de decizie tehnică

Utilizați această matrice pentru a determina care pași sunt obligatorii față de situaționali pentru scenariul dvs. specific:

Concluzii cheie

• Operațiunea de bază este: copiați fișierele în rădăcina documentelor, actualizați siteurl și home în baza de date, corectați .htaccess RewriteBase, rulați căutare-înlocuire conștientă de serializare, adăugați redirecționări 301.
• Nu utilizați niciodată un SQL simplu REPLACE() pe tabelele WordPress fără gestionarea serializării — va corupe valorile opțiunilor și va defecta plugin-urile silențios.
• Directiva .htaccess RewriteBase / este elementul cel mai frecvent configurat greșit în această migrare; o valoare greșită produce erori 404 pe toate URL-urile bazate pe permalink în timp ce pagina principală continuă să se încarce.
• Redirecționările 301 nu sunt cosmetice — ele transferă capitalul de link-uri și previn fragmentarea indexului. Sunt obligatorii pentru orice site cu vizibilitate existentă în căutare.
• Ștergeți directorul original /wordpress numai după o fereastră de observare stabilă de 24 de ore.
• Dacă rulați WordPress pe un VPS cu cPanel, utilizați opțiunea Show Hidden Files din File Manager pentru a vă asigura că .htaccess este inclus în operațiunea de copiere.

Întrebări frecvente

Va afecta eliminarea /wordpress din URL pozițiile mele SEO?

Pe termen scurt, așteptați-vă la fluctuații minore ale pozițiilor pe măsură ce Googlebot re-crawlează noile URL-uri. Dacă redirecționările 301 sunt implementate corect, capitalul de link-uri se transferă complet, iar pozițiile se stabilizează de obicei în două până la patru săptămâni. Omiterea redirecționărilor 301 cauzează pierderea permanentă a pozițiilor pentru toate paginile indexate anterior.

Ce se întâmplă dacă panoul de administrare WordPress este inaccesibil după mutarea fișierelor?

Cea mai frecventă cauză este o nepotrivire între valoarea siteurl din baza de date și locația reală a fișierelor. Utilizați WP-CLI (wp option update siteurl) sau adăugați define('WP_SITEURL', 'https://yourdomain.com'); în wp-config.php ca suprascrierea temporară pentru a restabili accesul.

Trebuie să actualizez wp-config.php după mutarea WordPress în rădăcină?

În majoritatea cazurilor, nu. Fișierul wp-config.php folosește căi relative pentru conexiunea la baza de date și nu codifică hard calea de instalare. Excepția este dacă ABSPATH a fost definit manual ca o cale absolută care indică vechiul director /wordpress — în acest caz, actualizați sau eliminați acea linie.

De ce imaginile sunt încă rupte după rularea Better Search Replace?

Aceasta înseamnă de obicei că plugin-ul a rulat împotriva unui subset de tabele și a ratat tabelele personalizate ale plugin-urilor sau tabelul wp_postmeta. Rulați din nou înlocuirea cu toate tabelele selectate și verificați, de asemenea, căile absolute ale sistemului de fișiere (de ex., /public_html/wordpress/wp-content/uploads/) pe lângă șirurile bazate pe URL.

Cum gestionez acest lucru pe o instalare WordPress Multisite?

Multisite necesită constante suplimentare în wp-config.php (DOMAIN_CURRENT_SITE, PATH_CURRENT_SITE) și URL-urile site-ului din rețea trebuie actualizate atât în tabelele wp_site, cât și wp_blogs. Procedura standard pentru un singur site este insuficientă — tratați aceasta ca o migrare completă a rețelei și testați mai întâi pe o clonă de staging.