Как удалить “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 перестроить и кэшировать правила перезаписи для нового пути на уровне корня. Alternatively, используйте WP-CLI:

wp rewrite flush --hard

Флаг --hard перегенерирует файл .htaccess в дополнение к сбросу кэша базы данных — полезно, если вы не уверены в правильности .htaccess.

Шаг 5: Замена URL во всей базе данных

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

Использование плагина 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, чтобы запросить повторную индексацию главной страницы. Отслеживайте отчёт 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, если вы использовали метод C на шаге 2.
3. Проверьте покрытие SSL: Если ваш SSL-сертификат был выдан для yourdomain.com/wordpress как область на основе пути (редко, но возможно в некоторых конфигурациях), убедитесь, что сертификат корректно покрывает корневой домен.
4. Обновите все внешние конфигурации DNS или CDN, которые могли кэшировать старую структуру путей.
5. Очистите все уровни кэширования: Очистите серверный кэш страниц, кэш объектов (Redis/Memcached) и кэш CDN. Устаревшие записи кэша для URL /wordpress будут отдавать некорректный контент даже после завершения миграции.

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

Для любой среды с SSH-доступом — включая выделенные серверы и неуправляемые 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 на мои позиции в поиске?

В краткосрочной перспективе ожидайте незначительных колебаний позиций, пока 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-среды.