Worpress: Почему не работает ЧПУ после переноса

Перенос сайта на WordPress (смена хостинга, домена или сервера) — это всегда стресс не только для владельца ресурса, но и для самой системы. Одной из самых частых проблем, с которой сталкиваются пользователи после миграции, является фатальная ошибка — перестают работать ЧПУ (человеко-понятные урлы, они же Постоянные ссылки).

Вместо красивых адресов вида /category/post-name/ пользователи видят ошибку 404, а сайт открывает только главную страницу. В этой статье мы подробно разберем все причины данного явления: от банального сброса настроек до неверных конфигураций веб-сервера. Вы узнаете, как диагностировать проблему и вернуть сайту работоспособность.

Данная информация предназначена для услуг: VPS хостинг или Хостинг сайтов

Что такое ЧПУ и зачем они ломаются при переносе?

ЧПУ в WordPress реализованы через систему маршрутизации (rewrite rules). Вся суть работы "красивых" ссылок сводится к тому, что сервер понимает: запрос вида /my-post/ нужно обработать файлом /index.php с определенными параметрами, а не искать физическую папку my-post.

При переносе сайта нарушается эта связка по нескольким причинам:

1. Изменение путей: Сайт переезжает из подпапки в корень или наоборот.

2. Различия в конфигурации серверов: На старом хостинге был Apache с mod_rewrite, на новом — Nginx, который игнорирует .htaccess .

3. Остаточные данные в базе: Старые URL в опциях WordPress ведут на несуществующие адреса.

Рассмотрим каждую причину и способ её устранения по порядку.

Причина 1: Сброс файла .htaccess и прав доступа

Самый распространенный случай на хостингах с веб-сервером Apache. При переносе файлов по FTP файл .htaccess мог быть не скопирован (так как он скрытый) либо его права доступа были изменены.

Диагностика

Подключитесь к серверу по FTP или через файловый менеджер хостинга и проверьте наличие файла .htaccess в корневой директории сайта (там же, где лежат папки wp-content, wp-admin). По умолчанию 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

Решение

1. Восстановление файла: Самый простой способ заставить WordPress пересоздать .htaccess — зайти в админ-панель, перейти в Настройки → Постоянные ссылки и нажать кнопку "Сохранить изменения", ничего не меняя. Это действие "сбрасывает" правила и перезаписывает файл (при наличии прав на запись) .

2. Ручное создание: Если у WordPress нет прав на запись в корневую папку, создайте файл .htaccess вручную, вставьте в него код выше и загрузите на сервер.

3. Проверка AllowOverride: Если файл есть, правила верны, а ЧПУ всё равно не работают, проблема может быть в конфигурации самого Apache. Необходимо, чтобы в конфиге виртуального хоста или в глобальных настройках сервера для вашей директории была разрешена перезапись директив. Найдите секцию Directory и замените AllowOverride None на AllowOverride All .

После изменений в конфигурации Apache необходимо перезапустить сервер.

Причина 2: Модуль mod_rewrite отключен

Даже если .htaccess на месте и Apache настроен на его чтение, сам модуль, который занимается преобразованием ЧПУ, может быть отключен в конфигурации сервера.

Диагностика

Создайте в корне сайта PHP-файл (например, info.php) с содержимым <?php phpinfo(); ?>. Откройте его в браузере и найдите секцию apache2handler или Loaded Modules. Просмотрите список — среди них должно быть mod_rewrite. Если его нет — модуль отключен.

Также проверить это можно через консоль сервера (для VPS):
apache2ctl -M | grep rewrite

или для CentOS:
httpd -M | grep rewrite

Решение

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

• Debian/Ubuntu:
  sudo a2enmod rewrite
sudo systemctl restart apache2

   

• CentOS/RHEL: Модуль обычно включен по умолчанию, но если нет — проверьте конфигурационные файлы в /etc/httpd/conf.modules.d/ .

Причина 3: Несовпадение URL в базе данных (сериализованные данные)

При переносе сайта на новый домен или даже просто с одного IP на другой, критически важно обновить адрес сайта в базе данных. WordPress хранит опции siteurl и home в таблице wp_options. Если эти ссылки ведут на старый домен, WordPress будет пытаться строить ЧПУ относительно него, что приведет к циклическим редиректам или 404.

Ошибка с сериализованными данными

Простая замена строк в SQL-дампе через текстовый редактор опасна. WordPress хранит некоторые настройки в сериализованном формате. Например: a:1:{s:4:"body";s:28:"Текст с ссылкой old.ru";}. Если вы просто замените old.ru на new.ru, длина строки изменится, и PHP не сможет правильно десериализовать данные, что приведет к ошибкам в работе плагинов и самого ядра, косвенно влияя на генерацию ЧПУ .

Решение

1. Стандартное (простое): Если сайт только что перенесен и контента мало, проще всего изменить адрес через админку, если она доступна: Настройки → Общие.

2. Правильное (техническое): Для изменения URL в базе используйте плагины для миграции, которые умеют работать с сериализованными данными, например, WP Syncbro или Better Search Replace .

3. Ручное (для профи): Если делаете дамп вручную, используйте запросы через phpMyAdmin с функцией REPLACE, но только для таблиц, не содержащих сериализованных данных, либо применяйте скрипты для корректного пересчета длины строк.

Причина 4: Конфликт с кодировкой и языком (Cyr-To-Lat)

Специфическая, но всё еще встречающаяся проблема на старых версиях WordPress или при использовании устаревших тем. Если ваш сайт использует ЧПУ на кириллице (например, /%postname%/, где postname написан по-русски), после переноса на сервер с другой локалью может возникнуть ошибка 404 для страниц, в то время как главная работает .

Это связано с тем, что WordPress некорректно обрабатывает преобразование URL-кодировок. Посты могут открываться, а страницы — нет, или наоборот.

Решение

1. Установите и активируйте плагин Cyr-To-Lat. Он автоматически транслитерирует русские символы в латиницу при создании ссылок, что исключает проблемы с кодировкой на любом сервере .

2. После активации плагина зайдите в Настройки → Постоянные ссылки и еще раз сохраните изменения, чтобы обновить структуру.

Причина 5: Использование Nginx вместо Apache

Это самая частая "ловушка" для новичков при переносе сайта с дешевого хостинга (где обычно Apache) на современный VPS или выделенный сервер (где часто стоит Nginx) . Nginx не использует файлы .htaccess. Все правила ЧПУ должны прописываться напрямую в конфигурационном файле хоста.

Если вы перенесли сайт на Nginx и видите 404 на всех внутренних страницах, значит, Nginx не передает управление WordPress для обработки ЧПУ.

Решение: Настройка конфигурации Nginx

Вам необходимо отредактировать конфигурационный файл сайта (обычно в директориях /etc/nginx/sites-available/ или /etc/nginx/conf.d/). В секции location / или в отдельной секции location ~ \.php$ нужно добавить правило, которое будет передавать все несуществующие файлы и папки на обработку /index.php.

Вот базовый, корректно работающий конфиг для WordPress на Nginx:
server {
    listen 80;
    server_name ваш-домен.ru;
    root /var/www/ваш-сайт;
    index index.php index.html index.htm;
   
    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/var/run/php/php8.1-fpm.sock; # Версия PHP может отличаться
    }

    location ~ /\.ht {
        deny all;
    }
}

Ключевая строка — try_files $uri $uri/ /index.php?$args;. Она говорит Nginx: "Попробуй найти файл, попробуй найти папку, и только если ничего нет — отдай на обработку index.php". После изменения конфига необходимо перезагрузить Nginx: sudo systemctl restart nginx.

Причина 6: Кэширование правил (плагины и CDN)

Современные плагины кэширования (WP Rocket, W3 Total Cache, LiteSpeed Cache) и некоторые плагины безопасности создают свои собственные правила в .htaccess или кэшируют маршруты. После переноса сайта эти правила могут конфликтовать с новым окружением.

Диагностика

Проверьте .htaccess на наличие блоков, относящихся к плагинам кэширования, расположенных ВНЕ стандартного блока # BEGIN WordPress. Иногда старые директивы могут указывать на несуществующие папки с кэшем.

Решение

1. Перед переносом рекомендуется отключить все плагины кэширования.

2. После переноса и настройки ЧПУ, активируйте их заново и заново проведите настройку (сбросьте кэш).

3. Если проблема появилась после переноса на работающем сайте, временно отключите все плагины (через FTP, переименовав папку wp-content/plugins), чтобы проверить, не в них ли дело .

Причина 7: Ошибки в конфигурации PHP (реже)

Иногда проблема с 404 при ЧПУ кроется не в веб-сервере, а в обработчике PHP. Если на новом хостинге используется неподходящая версия PHP или отсутствуют необходимые модули (например, mysqli), WordPress может некорректно парсить запросы.

Решение

Убедитесь, что версия PHP на новом хостинге соответствует требованиям вашей версии WordPress и актуальна (рекомендуется PHP 8.0+). В панели управления хостингом (ISPmanager, cPanel, DirectAdmin) можно быстро сменить версию PHP.

Пошаговый алгоритм действий (Чек-лист)

Если вы столкнулись с проблемой "ЧПУ не работают после переноса", действуйте строго по этому списку:

1. Обновление пермалинков: Зайдите в админку → Настройки → Постоянные ссылки → "Сохранить изменения". (Решает 30% проблем) .

2. Проверка .htaccess: Убедитесь, что файл существует, не пуст, и права доступа на него 644. Сравните содержимое со стандартным кодом WordPress.

3. Проверка mod_rewrite: Если сервер Apache, проверьте, включен ли модуль mod_rewrite и разрешена ли директива AllowOverride All для вашего каталога .

4. Анализ URL в базе: Проверьте таблицу wp_options, поля siteurl и home. Они должны указывать на новый домен.

5. Определение типа сервера: Apache или Nginx? Если Nginx — забудьте про .htaccess и настройте try_files в конфиге .

6. Отключение плагинов: Отключите все плагины (особенно кэширования и безопасности). Если ЧПУ заработали — ищите конфликтный плагин.

7. Логи ошибок: Посмотрите логи ошибок веб-сервера. Nginx и Apache пишут точные причины, почему запрос не был передан WordPress.

Заключение

Проблема с ЧПУ после переноса WordPress — это неприятно, но почти всегда решаемо. В 90% случаев достаточно либо "толкнуть" настройки постоянных ссылок в админке, либо скорректировать файл .htaccess, либо, если вы перешли на Nginx, просто добавить одно правило в конфигурацию.

Используя данное руководство, вы сможете не только быстро починить сайт, но и понять истинную причину неполадки, чтобы избежать её в будущем. Помните о важности корректной миграции баз данных с учетом сериализованных массивов и всегда проверяйте соответствие нового сервера техническим требованиям вашего проекта .