Как да премахнете „wordpress” от URL адреса на вашия сайт (Пълно техническо ръководство)

Когато WordPress е инсталиран в поддиректория с име /wordpress, всеки публично достъпен URL носи този сегмент от пътя — yourdomain.com/wordpress/about, yourdomain.com/wordpress/shop — което подкопава доверието в марката и разпилява SEO стойността. Решението е контролирана миграция на файлове, комбинирана с актуализиране на URL адресите в базата данни: премествате всички основни файлове на WordPress от поддиректорията в основната директория на сървъра (public_html), актуализирате настройките WordPress Address и Site Address, регенерирате правилата за пренаписване и издавате 301 пренасочвания за всички индексирани стари URL адреси. Не се изисква преинсталиране.

Това ръководство обхваща всеки технически слой на този процес — операции с файловата система, замяна на низове в базата данни, логика за пренаписване в .htaccess, стратегия за пренасочване и валидиране след миграцията — включително гранични случаи, които причиняват мълчаливи грешки в повечето уроци.

Защо WordPress завършва в поддиректория

Разбирането на основната причина предотвратява повторното възникване на същия проблем. Най-честите сценарии са:

• Настройки по подразбиране на инсталатора: Много инсталатори с едно кликване (Softaculous, Installatron) по подразбиране използват път с поддиректория, ако потребителят изрично не зададе пътя за инсталиране на /.
• Прехвърляне от тестова към продукционна среда: Разработчик инсталира WordPress на /wordpress за тестване и сайтът влиза в употреба без корекция на пътя.
• Планиране за мулти-сайт, което никога не се реализира: Някой е предвиждал да управлява множество CMS системи под един домейн и е ограничил WordPress до собствена папка.
• Особености на автоматичния инсталатор на cPanel: В среди с VPS с cPanel, инсталаторът понякога добавя името на приложението като поддиректория, освен ако не бъде заменено.

Независимо от произхода, процедурата за миграция е идентична.

Контролен списък преди миграцията

Преди да докоснете дори един файл, изпълнете всеки елемент от този списък. Пропускането на който и да е от тях е водещата причина за престой по време на тази операция.

• Пълно резервно копие на сайта: Архивирайте както файловата система, така и MySQL базата данни. Плъгини като UpdraftPlus или Duplicator работят добре; същото важи за снимка на ниво сървър, ако вашият доставчик на VPS Hosting го поддържа.
• Данни за достъп до базата данни под ръка: Ще ви трябват, ако се наложи ръчно редактиране на wp-config.php.
• Активиран режим на поддръжка: Използвайте плъгин или временно добавете define('WP_MAINTENANCE_MODE', true);, за да предотвратите записи по време на прозореца за миграция.
• Активирано логване на PHP грешки: Задайте WP_DEBUG_LOG на true в wp-config.php, така че всички грешки след миграцията да се записват в /wp-content/debug.log, вместо да се показват на екрана.
• Отбелязан DNS TTL: Ако е включена и DNS промяна, намалете TTL до 300 секунди поне един час преди началото.

Стъпка 1: Преместване на файловете на WordPress в основната директория

Целта е да копирате всичко вътре в /public_html/wordpress/ директно в /public_html/ — не самата папка, а нейното съдържание.

Използване на FTP клиент (FileZilla)

1. Свържете се към сървъра си чрез SFTP (порт 22), а не обикновен FTP, за да избегнете прихващане на идентификационни данни.
2. Навигирайте до public_html/wordpress/.
3. Изберете всички файлове и папки, включително скритите файлове. В FileZilla активирайте View > Show Hidden Files, за да разкриете .htaccess и всички .env файлове.
4. Плъзнете избраното едно ниво нагоре в директорията в public_html/.
5. Когато бъдете подканени за презаписване на index.php (ако в основната директория съществува заместващ файл), потвърдете презаписването.

Използване на командния ред (препоръчително за VPS)

Ако имате SSH достъп — какъвто трябва да имате на всяка правилно конфигурирана среда с VPS Hosting или Dedicated Server — подходът с командния ред е по-бърз и избягва проблеми с изтичане на времето при FTP при големи инсталации:

# 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

Не изтривайте директорията /wordpress все още. Оставете я непокътната, докато миграцията не бъде напълно валидирана. Можете да я премахнете в последната стъпка за почистване.

Критичен граничен случай: Символни връзки и абсолютни пътища в плъгини

Някои плъгини (особено плъгини за резервни копия и сигурност) съхраняват абсолютни файлови пътища в базата данни — например /var/www/html/public_html/wordpress/wp-content/uploads/2024/01/image.jpg. Те ще се счупят мълчаливо след преместването. Търсенето и замяната в базата данни в Стъпка 5 се справя с това, но трябва да включите таблицата wp_options и всички персонализирани таблици на плъгини в обхвата на замяната.

Стъпка 2: Актуализиране на WordPress Address и Site Address

WordPress съхранява две критични URL стойности в таблицата wp_options: siteurl (WordPress Address, сочещ към местоположението на основните файлове на WordPress) и home (Site Address, URL адресът, който посетителите използват за достъп до сайта). И двете трябва да бъдат актуализирани.

Метод А: Административен панел на WordPress

1. Влезте в yourdomain.com/wordpress/wp-admin — това все още работи, тъй като файловете все още са на двете места в този момент.
2. Отидете на Settings > General.
3. Актуализирайте и двете полета:

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

1. Кликнете Save Changes.

Метод Б: Директно редактиране на базата данни (когато административният панел е недостъпен)

Ако административният панел вече е недостъпен, използвайте WP-CLI или phpMyAdmin:

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

Или в phpMyAdmin изпълнете:

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

Заменете wp_ с действителния префикс на вашата таблица, ако е бил променен по време на инсталацията.

Метод В: Временно заместване чрез wp-config.php

Ако и административният панел, и базата данни са временно недостъпни, добавете тези два реда в wp-config.php като заместване при зареждане:

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

Това заменя каквото е съхранено в базата данни. Премахнете тези редове след потвърждаване, че административният панел е достъпен и стойностите в базата данни са актуализирани постоянно.

Стъпка 3: Проверка и актуализиране на файла .htaccess

Файлът .htaccess в основната директория контролира пренаписването на URL адреси от Apache за WordPress. След преместването на файловете, този файл вече трябва да е в public_html/ — но неговата директива RewriteBase трябва да отразява новата инсталация на ниво основна директория.

Отворете public_html/.htaccess и се уверете, че съдържа точно следния блок за пренаписване на 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

Ключовата промяна спрямо инсталацията в поддиректория е RewriteBase / вместо RewriteBase /wordpress/. Ако този ред е грешен, всички красиви постоянни връзки връщат грешки 404, докато началната страница се зарежда правилно — класическа диагностична характеристика на неправилно конфигуриран RewriteBase.

Потребители на Nginx: WordPress не използва .htaccess. Вместо това актуализирайте директивата try_files на вашия сървърен блок:

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

Стъпка 4: Изчистване на структурата на постоянните връзки

WordPress кешира правилата за пренаписване в базата данни. След промяна на URL адреса на сайта, тези кеширани правила препращат към старата структура на пътя и трябва да бъдат регенерирани.

1. Отидете на Settings > Permalinks в административния панел на WordPress.
2. Без да променяте избраната структура на постоянните връзки, кликнете Save Changes.

Това принуждава WordPress да преизгради и кешира правилата за пренаписване спрямо новия път на ниво основна директория. Алтернативно, използвайте WP-CLI:

wp rewrite flush --hard

Флагът --hard регенерира файла .htaccess в допълнение към изчистването на кеша на базата данни — полезно е, ако не сте сигурни дали .htaccess е правилен.

Стъпка 5: Замяна на URL адреси в цялата база данни

Преместването на файловете и актуализирането на siteurl/home не е достатъчно. WordPress съхранява сериализирани URL низове в цялата база данни — в съдържанието на публикациите, postmeta, настройките на уиджетите, опциите на темата и таблиците за конфигурация на плъгините. Всички останали препратки към пътя /wordpress ще доведат до счупени изображения, неправилни канонични тагове и неизправни функции на плъгините.

Използване на плъгина Better Search Replace

1. Инсталирайте и активирайте плъгина Better Search Replace.
2. Отидете на Tools > Better Search Replace.
3. Конфигурирайте замяната:

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

1. Изберете всички таблици в базата данни.
2. Премахнете отметката от Run as dry run? само след потвърждаване, че пробното изпълнение показва очаквания брой замени.
3. Кликнете Run Search/Replace.

Изпълнете и втори проход за абсолютния сървърен път:

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

Използване на WP-CLI (предпочитано за продукционна среда)

Командата search-replace на WP-CLI обработва сериализираните данни правилно, за разлика от обикновената SQL функция REPLACE():

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

Изпълнете втори проход за абсолютните пътища на файловата система:

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

Флагът --precise използва замяна, съобразена със сериализацията на PHP, вместо регулярни изрази, което предотвратява повреждането на сериализирани масиви, съхранени в базата данни.

Стъпка 6: Прилагане на 301 пренасочвания за SEO приемственост

Ако сайтът е бил публично достъпен на /wordpress URL адреси — и особено ако тези URL адреси са били индексирани от Google или свързани от външни източници — постоянните пренасочвания са задължителни, а не по избор. Без тях всеки индексиран URL адрес се превръща в 404, а цялата натрупана стойност на връзките се губи.

Добавете следното правило за пренасочване в public_html/.htaccess, над блока за пренаписване на WordPress:

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

Това правило прихваща всяка заявка, започваща с wordpress/, и я пренасочва към еквивалентния път на ниво основна директория. Например:

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

Важна бележка за позицията: Този блок за пренасочване трябва да се появи преди коментара # BEGIN WordPress. Собствените правила за пренаписване на WordPress ще прихванат заявката първи, ако пренасочването е поставено след тях.

За Nginx добавете това към сървърния блок:

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

Стъпка 7: Валидиране след миграцията

Систематичното тестване предотвратява мълчаливите грешки да останат незабелязани в продукционна среда.

Функционални проверки

Валидиране чрез командния ред

# 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

Подайте актуализираната карта на сайта в Google Search Console веднага след валидирането. Използвайте инструмента URL Inspection, за да поискате повторно индексиране на началната страница. Наблюдавайте отчета Coverage през следващите 48–72 часа за всякакъв скок в грешките 404, което би показало пропуснати замени на URL адреси.

Стъпка 8: Почистване и окончателно укрепване

След като сайтът работи стабилно на основния URL адрес в продължение на 24–48 часа:

1. Изтрийте поддиректорията /wordpress от сървъра. Оставянето й на място създава риск от дублирано съдържание и разкрива вторична точка за достъп до инсталацията на WordPress.

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

1. Премахнете константата WP_MAINTENANCE_MODE от wp-config.php, ако сте я добавили.
2. Премахнете временните дефиниции WP_HOME/WP_SITEURL от wp-config.php, ако сте използвали Метод В в Стъпка 2.
3. Проверете SSL покритието: Ако вашият SSL Certificate е издаден за yourdomain.com/wordpress като обхват, базиран на пътя (рядко, но възможно при някои конфигурации), потвърдете, че сертификатът покрива правилно основния домейн.
4. Актуализирайте всички външни DNS или CDN конфигурации, които може да са кеширали старата структура на пътя.
5. Изчистете всички слоеве на кеширане: Изчистете кеша на страниците на ниво сървър, кеша на обектите (Redis/Memcached) и кеша на CDN. Остарелите кеш записи за /wordpress URL адреси ще обслужват неправилно съдържание дори след завършване на миграцията.

Сравнение: Методи за миграция с един поглед

За всяка среда с SSH достъп — включително Dedicated Servers и неуправлявани VPS инстанции — подходът с WP-CLI е най-надеждният и най-малко склонен към грешки вариант.

Матрица за технически решения

Използвайте тази матрица, за да определите кои стъпки са задължителни спрямо ситуационни за вашия конкретен сценарий:

Основни изводи

• Основната операция е: копирайте файловете в основната директория, актуализирайте siteurl и home в базата данни, поправете .htaccess RewriteBase, изпълнете търсене и замяна, съобразено със сериализацията, добавете 301 пренасочвания.
• Никога не използвайте обикновен SQL REPLACE() върху таблици на WordPress без обработка на сериализацията — това ще повреди стойностите на опциите и ще счупи плъгините мълчаливо.
• Директивата .htaccess RewriteBase / е единственият най-често неправилно конфигуриран елемент в тази миграция; грешна стойност води до грешки 404 на всички URL адреси, базирани на постоянни връзки, докато началната страница продължава да се зарежда.
• 301 пренасочванията не са козметични — те прехвърлят стойността на връзките и предотвратяват фрагментирането на индекса. Те са задължителни за всеки сайт с налична видимост в търсачките.
• Изтрийте оригиналната директория /wordpress само след 24-часов прозорец за стабилно наблюдение.
• Ако управлявате WordPress на VPS с cPanel, използвайте опцията Show Hidden Files на File Manager, за да се уверите, че .htaccess е включен в операцията по копиране.

Често задавани въпроси

Ще засегне ли премахването на /wordpress от URL адреса моите SEO класирания?

В краткосрочен план очаквайте незначителни колебания в класирането, докато Googlebot повторно обходи новите URL адреси. Ако 301 пренасочванията са правилно приложени, стойността на връзките се прехвърля напълно и класиранията обикновено се стабилизират в рамките на две до четири седмици. Пропускането на 301 пренасочванията причинява трайна загуба на класиране за всички предварително индексирани страници.

Какво да направя, ако административният панел на WordPress е недостъпен след преместването на файловете?

Най-честата причина е несъответствие между стойността siteurl в базата данни и действителното местоположение на файловете. Използвайте WP-CLI (wp option update siteurl) или добавете define('WP_SITEURL', 'https://yourdomain.com'); в wp-config.php като временно заместване за възстановяване на достъпа.

Трябва ли да актуализирам wp-config.php след преместването на WordPress в основната директория?

В повечето случаи не. Файлът wp-config.php използва относителни пътища за връзката с базата данни и не кодира твърдо пътя на инсталацията. Изключението е, ако ABSPATH е бил ръчно дефиниран като абсолютен път, сочещ към старата директория /wordpress — в такъв случай актуализирайте или премахнете този ред.

Защо изображенията все още са счупени след изпълнението на Better Search Replace?

Обикновено това означава, че плъгинът е изпълнен само върху подмножество от таблици и е пропуснал персонализирани таблици на плъгини или таблицата wp_postmeta. Изпълнете замяната отново с избрани всички таблици и проверете и за абсолютни пътища на файловата система (напр. /public_html/wordpress/wp-content/uploads/) в допълнение към низовете, базирани на URL.

Как да се справя с това при инсталация на WordPress Multisite?

Multisite изисква допълнителни константи в wp-config.php (DOMAIN_CURRENT_SITE, PATH_CURRENT_SITE) и URL адресите на сайтовете в мрежата трябва да бъдат актуализирани в таблиците wp_site и wp_blogs. Стандартната процедура за единичен сайт е недостатъчна — третирайте това като пълна мрежова миграция и тествайте първо на клонинг за тестване.