WordPress 404 на VDS после переноса: как настроить Nginx, .htaccess и постоянные ссылки

Автор: Виктория Ковалева | Опубликовано: 20.08.2026

После переноса WordPress на VDS чаще всего ломается не сам сайт, а маршрутизация: главная открывается, а записи, рубрики и страницы дают 404. На практике причина обычно одна из трех: не работает правило rewrite на уровне веб-сервера, WordPress пишет ссылки не в тот путь, либо Nginx и Apache настроены так, что .htaccess вообще не участвует в обработке запроса.

Если у вас на новом сервере открывается только главная, а любой URL вида /blog/post-name/ падает в 404, не начинайте с переустановки плагинов. Сначала проверьте серверный слой и только потом — WordPress.

Как понять, где именно ломается маршрут

Диагностика здесь важнее самого исправления. Один и тот же симптом может означать разные проблемы, и если сразу править постоянные ссылки в админке, можно просто замаскировать ошибку конфигурации.

Что проверить в первую очередь

открывается ли /wp-admin/ без редиректов и ошибок;
работает ли главная страница сайта;
падают ли в 404 только «красивые» URL записей и страниц;
есть ли на сервере Nginx, Apache или связка Nginx + Apache;
совпадает ли DocumentRoot с реальным каталогом WordPress;
не переписан ли путь в настройках siteurl и home.

Если админка открывается, а записи — нет, почти всегда проблема в rewrite. Если не открывается даже админка, смотрите путь установки, права на файлы и ошибки веб-сервера.

Быстрая проверка через WP-CLI

На VDS удобнее всего проверить базовые параметры через WP-CLI. Это быстрее, чем искать их в базе вручную.

wp option get home
wp option get siteurl
wp rewrite list
wp rewrite flush --hard

Команда wp rewrite list покажет, есть ли правила вообще. Если список пустой или явно не соответствует структуре сайта, WordPress не может собрать маршруты корректно.

Почему после переноса появляются 404

На практике встречаются три сценария.

Причина	Как выглядит	Что делать
Нет правил rewrite на сервере	Главная работает, записи и страницы — 404	Проверить конфиг Nginx/Apache и перезаписать правила
WordPress установлен в подпапку, а URL указывает на корень	Часть ссылок ведет не туда	Сверить `home`, `siteurl` и путь установки
Права или владелец файлов неверные	Файлы есть, но сервер не читает `.htaccess` или PHP	Исправить владельца и права на каталоги

Если у вас Nginx, файл .htaccess не решает проблему сам по себе. Его правила нужно перенести в конфигурацию сервера. Если Apache — проверьте, включен ли mod_rewrite и разрешен ли AllowOverride для каталога сайта.

Пошаговое решение для Nginx и Apache

Ниже — рабочая последовательность, которую имеет смысл выполнять по порядку. Она подходит для большинства переносов WordPress на VDS.

1. Сверьте адреса сайта в базе

После миграции часто забывают обновить URL. Тогда WordPress строит ссылки на старый домен или на старый путь в каталоге.

wp option update home 'https://example.ru'
wp option update siteurl 'https://example.ru'

Если сайт стоит не в корне, а в подпапке, укажите реальный путь. Например, https://example.ru/blog. После этого проверьте, не осталось ли старых значений в базе и в файле wp-config.php.

2. Сбросьте правила постоянных ссылок

Даже если настройки выглядят правильно, WordPress может держать старый набор rewrite-правил. Сброс нужен после переноса, смены структуры URL или правки конфигурации сервера.

wp rewrite flush --hard

Если WP-CLI недоступен, откройте в админке Настройки → Постоянные ссылки и просто нажмите «Сохранить изменения» без правок. Это пересобирает правила.

3. Проверьте конфигурацию Nginx

Для Nginx нужен корректный блок location / с передачей запроса в index.php, если файл или каталог не найден. Без этого WordPress не сможет обрабатывать «красивые» ссылки.

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

location ~ \.php$ {
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_pass unix:/run/php/php8.2-fpm.sock;
}

Имя сокета PHP-FPM может отличаться. Не копируйте его вслепую: проверьте, какой сокет или порт реально используется на вашем сервере.

4. Проверьте Apache, если он участвует в обработке

Для Apache в корне WordPress должен быть рабочий .htaccess. Минимальный набор правил выглядит так:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

Если сайт в подпапке, RewriteBase должен указывать на нее. Ошибка в этом параметре — частая причина 404 после переноса.

5. Исправьте права и владельца файлов

Неверные права не всегда дают явную ошибку. Иногда сайт открывается, но сервер не может читать конфиг или писать кэш, из-за чего поведение становится нестабильным.

find /var/www/example.ru -type d -exec chmod 755 {} \;
find /var/www/example.ru -type f -exec chmod 644 {} \;
chown -R www-data:www-data /var/www/example.ru

Пользователь и группа www-data подходят не для всех систем. На некоторых дистрибутивах это может быть nginx или другой сервисный пользователь. Сначала проверьте, под кем работает веб-сервер.

Как проверить, что исправление сработало

После правок не ограничивайтесь открытием главной страницы. Проверка должна быть по нескольким типам URL.

откройте запись с ЧПУ;
проверьте страницу рубрики;
проверьте вложенную страницу;
откройте /wp-admin/ и сохраните постоянные ссылки еще раз;
посмотрите логи веб-сервера на предмет 404 и 500;
проверьте ответ через curl -I.

Пример проверки заголовков ответа:

curl -I https://example.ru/sample-post/

Если все настроено правильно, вы должны увидеть не 404, а нормальный ответ сервера и редиректы только там, где они действительно нужны. Для WordPress важно не просто открыть страницу в браузере, а убедиться, что сервер отдает корректный код ответа.

Частые ошибки и как их исправить

Сохранили постоянные ссылки, но 404 остались

Это значит, что WordPress правила пересобрал, но веб-сервер их не применяет. На Nginx ищите try_files, на Apache — mod_rewrite и AllowOverride.

Сайт открывается только по `index.php`

Так бывает, если rewrite не работает вообще. Это не проблема темы или плагина. Сначала чинится серверная конфигурация, потом уже проверяется WordPress.

После переноса остались старые URL в базе

Если в контенте, меню или настройках плагинов остались абсолютные ссылки на старый домен, часть переходов будет вести не туда. В этом случае нужен поиск и замена по базе, но делать ее надо аккуратно и только после бэкапа.

Сайт стоит в подпапке, а правила написаны для корня

Это типичная ошибка при переносе на новый VDS. Проверьте, совпадает ли реальный путь установки с home, siteurl и RewriteBase.

Что делать, если на сервере несколько сайтов

На VDS часто крутится не один WordPress, а несколько виртуальных хостов. Тогда проблема может быть не в самом WordPress, а в том, что запросы попадают не в тот server block или не в тот DocumentRoot.

Проверьте:

какой server_name указан для домена;
какой каталог назначен как root;
не перехватывает ли запросы дефолтный виртуальный хост;
не конфликтуют ли редиректы www/non-www и HTTP/HTTPS.

Если есть отдельный редирект с HTTP на HTTPS, убедитесь, что он не зацикливается. Иногда 404 маскирует неправильную схему редиректов, особенно если сертификат и веб-сервер настраивали вручную.

Практические советы по безопасности и производительности

Когда маршрут уже починен, имеет смысл сразу закрыть типовые слабые места. Это не ускорит сайт магически, но уберет лишние риски на VDS.

не оставляйте права 777 на каталоги;
не храните резервные копии в веб-доступном каталоге;
проверьте, что wp-config.php не доступен извне;
после переноса обновите salts в wp-config.php при подозрении на компрометацию;
включите логирование ошибок PHP на время диагностики, но не держите его открытым постоянно;
если используете кеш-плагин, очистите кеш после правок rewrite.

Если на сайте много технических дублей, лишних архивов и служебных страниц, можно дополнительно посмотреть в сторону Clearfy Pro: он помогает убрать часть SEO-дублей и служебного мусора, но не заменяет серверную настройку. Сначала должен быть корректный маршрут, потом уже оптимизация индексации.

Главный критерий успеха простой: все типы URL открываются с правильным кодом ответа, а логи сервера больше не показывают массовые 404 на существующие страницы. Если это выполнено, перенос на VDS можно считать настроенным нормально, а не «почти рабочим».

⭐⭐⭐⭐⭐