WordPress показывает ошибку 404 на всех страницах

Автор:vkuzyomko

WordPress показывает ошибку 404 на всех страницах

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

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

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

Причина

Ошибка 404 означает, что сервер или WordPress не нашёл страницу по указанному адресу. Но когда 404 появляется сразу на всех внутренних страницах, а главная открывается, чаще всего сами страницы не удалены. Проблема обычно в маршрутизации URL.

WordPress использует постоянные ссылки. Красивый URL вида /usluga/ должен быть преобразован сервером в запрос к WordPress. Если rewrite rules не работают, сервер не передаёт запрос в WordPress, и пользователь видит 404.

Симптом Возможная причина Что проверить
Главная работает, все страницы 404 сломаны постоянные ссылки или .htaccess Настройки → Постоянные ссылки, .htaccess
404 после переноса сайта не перенеслись rewrite rules или сервер отличается Apache/Nginx, AllowOverride, config сайта
404 после смены хостинга сервер не читает .htaccess или нет rewrite module mod_rewrite, Nginx location rules
404 только у товаров WooCommerce сломан product base или flush rewrite rules WooCommerce permalinks, product slug
404 только у кастомных post types не обновлены rewrite rules CPT register_post_type, rewrite, flush rules
404 после установки плагина конфликт rewrite rules или slug плагины, slug страниц, debug.log
404 только на русском/украинском URL кодировка, TranslatePress, редиректы, кеш языковые URL, плагины перевода, permalink
404 в админке при preview тема или код меняет query functions.php, pre_get_posts, theme filters

Если страницы показывают не 404, а 403, это другая проблема: доступ запрещён. Для такого случая есть отдельная статья WordPress показывает ошибку 403.

Диагностика

Диагностика должна идти от простого к сложному. В большинстве случаев 404 на всех страницах WordPress решается пересохранением постоянных ссылок или восстановлением .htaccess. Но если сайт на Nginx, после миграции или с кастомными типами записей, может понадобиться проверка server config.

1. Проверьте, главная страница работает или нет

Если главная страница открывается, а внутренние страницы нет, это почти всегда проблема маршрутизации. Если не открывается и главная, смотрите более общий материал Сайт WordPress не открывается: что делать.

  • откройте главную страницу сайта;
  • откройте обычную страницу;
  • откройте запись блога;
  • откройте рубрику или метку;
  • откройте товар WooCommerce, если есть магазин;
  • проверьте URL через режим инкогнито;
  • очистите кеш браузера и сайта.

2. Пересохраните постоянные ссылки

Самый быстрый тест — открыть админку WordPress и перейти:

Настройки → Постоянные ссылки → Сохранить изменения

Менять структуру не обязательно. Само сохранение обновляет rewrite rules WordPress. После этого проверьте страницы в браузере.

Если после пересохранения всё заработало, причина была в сброшенных правилах постоянных ссылок. Такое бывает после обновлений, миграции, смены темы, установки плагинов или регистрации кастомных типов записей.

3. Проверьте .htaccess

На Apache-серверах WordPress использует .htaccess для обработки красивых URL. Если файл удалён, повреждён или сервер его не читает, внутренние страницы могут отдавать 404.

Файл должен находиться в корне сайта:

/.htaccess

Проверьте, есть ли в нём стандартный блок WordPress. Если его нет, WordPress может не передавать запросы на index.php.

4. Проверьте Apache mod_rewrite и AllowOverride

Если .htaccess правильный, но не работает, сервер может его игнорировать. На VPS это часто связано с отключённым mod_rewrite или настройкой AllowOverride None.

Что проверить:

  • включён ли Apache mod_rewrite;
  • разрешён ли AllowOverride для директории сайта;
  • нет ли ошибок в Apache config;
  • перезапущен ли веб-сервер после изменений;
  • правильная ли DocumentRoot директория.

5. Проверьте Nginx rules

Nginx не использует .htaccess. Если сайт работает на Nginx, правила WordPress должны быть прописаны в конфигурации server block.

Для WordPress обычно нужна логика:

try_files $uri $uri/ /index.php?$args;

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

6. Проверьте плагины и тему

Иногда 404 вызывают не rewrite rules, а плагин или тема. Особенно если проблема появилась после обновления, установки SEO-плагина, мультиязычности, кеша, редиректов или custom post type.

  • отключите последние установленные плагины;
  • проверьте плагины редиректов;
  • проверьте SEO-плагин;
  • проверьте плагины мультиязычности;
  • проверьте кеш-плагин;
  • временно переключитесь на стандартную тему;
  • проверьте код в functions.php.

Если 404 появился после установки или обновления плагина, проверьте инструкцию после обновления плагина сломался сайт WordPress.

Нужно быстро решить проблему на сайте?

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

Оставить заявку

Решение

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

1. Сохраните постоянные ссылки

Откройте:

Настройки → Постоянные ссылки

Нажмите “Сохранить изменения”. После этого проверьте несколько внутренних страниц.

Если проблема ушла, дополнительно очистите кеш сайта и CDN. Если 404 возвращается снова, значит кто-то постоянно сбрасывает или перезаписывает rewrite rules.

2. Восстановите стандартный .htaccess

Перед изменением сохраните старый .htaccess. Потом вставьте стандартный блок WordPress.

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

После сохранения файла проверьте сайт. Если используются дополнительные редиректы, кеш или правила безопасности, добавляйте их аккуратно и проверяйте после каждого блока.

3. Проверьте права на .htaccess

Если WordPress не может записать .htaccess, пересохранение постоянных ссылок может не сработать.

  • проверьте, существует ли файл .htaccess;
  • проверьте права файла;
  • проверьте владельца файла;
  • проверьте, может ли WordPress писать в корень сайта;
  • проверьте блокировки security-плагина или хостинга.

Обычно для файла подходит 644, но на некоторых хостингах политика может отличаться.

4. Исправьте Nginx config

Если сайт на Nginx, .htaccess не поможет. Нужно править server block. В location / должна быть обработка через index.php.

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

После изменения конфигурации нужно проверить синтаксис и перезагрузить Nginx. Делать это стоит только при доступе к серверу и понимании конфигурации.

5. Проверьте custom post types

Если 404 только у кастомных записей, товаров, кейсов, документов или портфолио, возможно проблема в register_post_type, rewrite slug или конфликте slug с существующей страницей.

Проверьте:

  • есть ли параметр rewrite;
  • не совпадает ли slug с обычной страницей;
  • не менялся ли custom post type;
  • не отключён ли плагин, который регистрирует CPT;
  • пересохранены ли постоянные ссылки после регистрации CPT.

6. Проверьте WooCommerce permalinks

Если 404 только у товаров или категорий товаров, проверьте WooCommerce → Настройки → Постоянные ссылки. Иногда конфликтует product base, category base или slug страницы магазина.

  • проверьте страницу Shop;
  • проверьте product base;
  • проверьте category base;
  • пересохраните постоянные ссылки;
  • очистите кеш;
  • проверьте, не совпадает ли slug товара со страницей.

Код

Важно: код и команды ниже могут повлиять на доступность сайта, постоянные ссылки, товары WooCommerce, страницы, редиректы и SEO. Перед изменениями сделайте backup файлов и базы. Не меняйте серверную конфигурацию без понимания, особенно на рабочем сайте.

Пересохранить rewrite rules через WP-CLI

Куда выполнять: SSH в корне сайта.

wp rewrite flush

Если на сайте есть custom post types, после их регистрации можно выполнить:

wp rewrite flush --hard

Команда –hard пытается обновить .htaccess, если сервер и права позволяют это сделать.

Посмотреть структуру постоянных ссылок

wp option get permalink_structure

Установить стандартную структуру постоянных ссылок

Пример для структуры “Название записи”.

wp option update permalink_structure '/%postname%/'
wp rewrite flush --hard

Стандартный .htaccess для WordPress

Куда вставлять: файл .htaccess в корне сайта.

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Nginx правило для WordPress

Куда вставлять: server block Nginx внутри location /. После изменения нужно проверить конфиг.

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

Проверка конфигурации Nginx:

nginx -t

Перезагрузка Nginx:

systemctl reload nginx

Проверить, включён ли Apache mod_rewrite

Куда выполнять: SSH на сервере.

apache2ctl -M | grep rewrite

Если модуль выключен, на Ubuntu/Debian обычно используют:

a2enmod rewrite
systemctl restart apache2

Проверить .htaccess и права

ls -la .htaccess

Обычно можно использовать:

chmod 644 .htaccess

Результат

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

Хороший результат:

  • главная страница открывается;
  • обычные страницы не отдают 404;
  • записи блога открываются;
  • рубрики и метки работают;
  • товары WooCommerce открываются, если есть магазин;
  • custom post types не показывают 404;
  • .htaccess содержит правильный WordPress-блок;
  • Nginx передаёт запросы в index.php;
  • кеш очищен;
  • Search Console постепенно перестаёт видеть массовые 404.

Дополнительные способы

Проверить slug-конфликты

Если одна страница, рубрика, товар или custom post type использует одинаковый slug, WordPress может неправильно определить нужный объект. Особенно часто это бывает с товарами, услугами, категориями и страницами с одинаковыми адресами.

Проверить языковые плагины

Если 404 появляется только в языковых версиях сайта, проверьте TranslatePress, WPML, Polylang или другой multilingual-плагин. Проблема может быть в языковом префиксе, кешировании, slug, редиректах или sitemap.

Проверить редиректы

Плагины редиректов, SEO-плагины и .htaccess могут отправлять пользователя на URL, которого нет. Проверьте цепочки 301/302 и убедитесь, что финальный адрес существует.

Проверить тему

Если даже URL вида ?p=123 показывает 404, проблема может быть не в .htaccess, а в теме или кастомном коде, который меняет основной запрос WordPress.

Проверить pre_get_posts

Код в теме или плагине может неправильно менять главный запрос. Например, фильтр должен работать только на главной, но применяется ко всем страницам и ломает выборку.

Проверить кеш и CDN

После исправления постоянных ссылок очистите:

  • кеш WordPress-плагина;
  • серверный кеш;
  • OPcache;
  • Cloudflare или другой CDN;
  • кеш браузера.

Частые ошибки

Удалять страницы, потому что они показывают 404

Если 404 на всех страницах, почти всегда проблема не в самих страницах. Удаление контента только ухудшит ситуацию.

Править .htaccess без копии

В .htaccess могут быть важные редиректы, правила кеша, защиты и HTTPS. Перед заменой сохраните старую версию.

Думать, что Nginx читает .htaccess

Nginx не использует .htaccess. Если сайт на Nginx, нужно проверять конфигурацию сервера.

Не очищать кеш после исправления

Кеш может продолжать отдавать старые 404, даже если постоянные ссылки уже исправлены.

Не проверять custom post types

Если обычные страницы работают, а товары, кейсы или услуги 404, нужно проверять CPT, rewrite slug и flush rewrite rules.

Игнорировать миграцию

После переноса сайта часто меняется сервер, путь к сайту, .htaccess, Nginx config, DocumentRoot или доступность mod_rewrite.

Переименовывать slug без 301

Если URL менялись осознанно, старые адреса должны вести на новые через 301. Иначе в Google появятся реальные 404.

Диагностика проблем

Проблема: главная работает, остальные страницы 404

Возможная причина: постоянные ссылки, .htaccess, Apache rewrite или Nginx try_files.

Что делать: пересохранить постоянные ссылки, восстановить .htaccess, проверить mod_rewrite или Nginx config.

Проблема: 404 после переноса сайта

Возможная причина: сервер не читает .htaccess, другой веб-сервер, неправильный DocumentRoot, не перенеслись правила.

Что делать: проверить .htaccess, Nginx/Apache config, AllowOverride, mod_rewrite, путь к сайту и кеш.

Проблема: 404 только у товаров WooCommerce

Возможная причина: product base, category base, конфликт slug, не обновлены rewrite rules.

Что делать: проверить WooCommerce permalinks, страницу Shop, пересохранить постоянные ссылки и очистить кеш.

Проблема: 404 только у custom post type

Возможная причина: ошибка register_post_type, rewrite slug, отключён плагин, конфликт URL.

Что делать: проверить код регистрации CPT, plugin activation, slug, flush rewrite rules.

Проблема: 404 только в одной языковой версии

Возможная причина: языковой префикс, TranslatePress/WPML/Polylang, кеш, sitemap или редиректы.

Что делать: пересохранить permalinks, проверить языковые настройки, очистить кеш и проверить sitemap.

Проблема: 404 после установки плагина

Возможная причина: плагин зарегистрировал новый slug, изменил rewrite rules или конфликтует с существующей страницей.

Что делать: отключить плагин для теста, пересохранить постоянные ссылки, проверить slug-конфликты.

Проблема: ?p=123 тоже показывает 404

Возможная причина: не .htaccess, а тема, pre_get_posts, custom query, статус записи или проблема базы.

Что делать: переключиться на стандартную тему, отключить плагины, проверить functions.php и debug.log.

Краткие AI-friendly ответы

Почему WordPress показывает 404 на всех страницах?

Чаще всего из-за постоянных ссылок, .htaccess, rewrite rules, Nginx try_files, Apache mod_rewrite, кеша, плагина, темы или ошибки после миграции сайта.

Что делать первым при 404 на всех страницах?

Зайдите в Настройки → Постоянные ссылки и нажмите “Сохранить изменения”. Затем проверьте .htaccess, кеш, Apache/Nginx правила и конфликт плагинов.

Почему главная работает, а остальные страницы 404?

Главная открывается напрямую через index.php, а внутренние красивые URL требуют rewrite rules. Если rewrite не работает, внутренние страницы получают 404.

Как исправить 404 на Nginx?

Нужно проверить server block и добавить в location / правило try_files $uri $uri/ /index.php?$args;. .htaccess на Nginx не работает.

FAQ

Почему WordPress показывает 404 на всех страницах, кроме главной?

Обычно потому что сломаны постоянные ссылки или rewrite rules. Главная открывается, а внутренние URL не передаются правильно в WordPress.

Как быстро исправить 404 на всех страницах WordPress?

Перейдите в Настройки → Постоянные ссылки и нажмите “Сохранить изменения”. Если не помогло, проверьте .htaccess, mod_rewrite, Nginx config, кеш и плагины.

Может ли .htaccess вызвать 404?

Да. Если .htaccess удалён, повреждён или сервер его не читает, WordPress не сможет обрабатывать красивые URL.

Что делать, если сайт работает на Nginx?

Проверить конфигурацию Nginx. Для WordPress нужен try_files $uri $uri/ /index.php?$args; в правильном location-блоке.

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

После переноса мог измениться сервер, путь, DocumentRoot, .htaccess, Nginx config, mod_rewrite или AllowOverride. Нужно проверить серверные правила и пересохранить permalinks.

Почему 404 только у товаров WooCommerce?

Причина может быть в product base, category base, slug-конфликте, странице магазина или не обновлённых rewrite rules.

Можно ли удалить .htaccess?

Можно временно переименовать для теста, но перед этим сохраните копию. После проверки нужно создать новый стандартный .htaccess WordPress.

Почему 404 остаётся после пересохранения постоянных ссылок?

Возможны проблемы с правами .htaccess, Apache AllowOverride, Nginx config, кешем, конфликтом плагина, темой или custom post type.

Как понять, виновата тема?

Если даже URL вида ?p=123 показывает 404, временно переключитесь на стандартную тему. Если страницы заработали, проблема может быть в functions.php, pre_get_posts или кастомных запросах темы.

Когда обращаться к специалисту?

Если 404 появился после миграции, на Nginx/VPS, в WooCommerce, в языковых версиях, у custom post types или после обновления плагинов, лучше проверить сервер, rewrite rules, тему, плагины и логи аккуратно.

Вывод

Если WordPress показывает ошибку 404 на всех страницах, а главная работает, чаще всего страницы не удалены. Проблема обычно в постоянных ссылках, .htaccess, rewrite rules, Apache/Nginx, кеше, плагине, теме или миграции.

Безопасный порядок такой: пересохранить постоянные ссылки, проверить .htaccess, очистить кеш, проверить Apache mod_rewrite или Nginx try_files, затем проверить плагины, тему, WooCommerce и custom post types.

Главное — не удалять страницы и не менять URL наугад. Сначала нужно восстановить маршрутизацию WordPress, а потом проверить, что все важные страницы, записи, товары, рубрики и sitemap снова работают корректно.

Об авторе

vkuzyomko administrator

Свежие записи

Рубрики