Як видалити “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) за замовчуванням використовують шлях підкаталогу, якщо користувач явно не встановив шлях інсталяції як /.
• Перенесення зі staging-середовища у production: Розробник встановлює 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, а не відображалися на екрані.
• Зафіксовано TTL DNS: Якщо також передбачено зміну 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, який відвідувачі використовують для доступу до сайту). Обидва необхідно оновити.

Метод A: Панель керування 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.

Метод B: Пряме редагування бази даних (коли панель керування недоступна)

Якщо панель керування вже недоступна, використовуйте 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_ на ваш фактичний префікс таблиці, якщо він був змінений під час інсталяції.

Метод C: Тимчасове перевизначення через 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 (рекомендовано для production)

Команда 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

Якщо сайт був публічно доступний за URL-адресами /wordpress — і особливо якщо ці 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: Перевірка після міграції

Систематичне тестування запобігає непомітним збоям у production.

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

Перевірка через командний рядок

# 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, щоб запросити повторну індексацію головної сторінки. Протягом наступних 48–72 годин відстежуйте звіт Coverage на предмет будь-якого стрибка помилок 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, якщо ви використовували метод C на кроці 2.
3. Перевірте покриття SSL: Якщо ваш SSL Certificate був виданий для yourdomain.com/wordpress як область на основі шляху (нечасто, але можливо в деяких конфігураціях), переконайтеся, що сертифікат коректно покриває кореневий домен.
4. Оновіть будь-які зовнішні конфігурації DNS або CDN, які могли кешувати стару структуру шляху.
5. Очистіть усі рівні кешування: Очистіть серверний кеш сторінок, кеш об’єктів (Redis/Memcached) та кеш CDN. Застарілі записи кешу для URL-адрес /wordpress будуть обслуговувати некоректний вміст навіть після завершення міграції.

Порівняння: методи міграції на перший погляд

Для будь-якого середовища з 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. Стандартна процедура для одного сайту є недостатньою — розглядайте це як повну міграцію мережі та спочатку протестуйте на клоні staging-середовища.