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

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

Почему главная открывается, а внутренняя страница нет

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

Обычно источник проблемы находится в одном из трех мест: настройки постоянных ссылок, файл .htaccess или конфигурация сервера. Реже виноваты плагины, тема или кэш. Внешне ошибка выглядит одинаково, но путь к ней может быть совсем разным.

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

«Большинство 404 в WordPress на красивых URL связано не с контентом, а с переписыванием адресов на уровне сервера».

«Если главная открывается, а вложенные страницы нет, первым делом проверяют правила перезаписи и права на файл конфигурации».

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

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

Откройте раздел с постоянными ссылками и просто нажмите сохранение, не меняя ничего в структуре. Этот простой шаг заставляет WordPress заново записать правила маршрутизации. На практике он часто возвращает к жизни и записи, и страницы, и архивы.

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

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

Файл .htaccess и правила перезаписи

Если сайт работает на Apache, стоит проверить файл .htaccess. Для WordPress это один из ключевых элементов, который отвечает за красивый адрес вместо длинной служебной строки. Когда файл поврежден, удален или содержит лишние правила, сайт легко уходит в 404 на всех внутренних адресах.

Типичная ситуация после ручного редактирования или установки плагина безопасности: в файл попадают дополнительные строки, которые перебивают стандартные правила WordPress. Иногда проблема возникает после переноса сайта, если старый .htaccess не был перенесен или права доступа на него выставлены неверно.

Если файл есть, проверьте, выглядит ли он как стандартный блок WordPress. Для ориентира часто используют такой набор правил:

Что проверить	На что обратить внимание
Наличие .htaccess	Файл должен лежать в корне сайта, рядом с wp-config.php
Права доступа	Файл не должен быть закрыт для записи сервером
Стандартный блок WordPress	Проверьте, не удалены ли строки с mod_rewrite
Лишние правила выше блока WordPress	Они могут ломать маршрутизацию

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

Плагины и тема тоже способны сломать маршруты

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

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

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

Как понять, что виноват плагин или тема

Если ошибка появилась сразу после установки расширения, искать долго не придется. Часто это кэш, SEO-плагин, модуль безопасности или плагин для ЧПУ. Такие инструменты полезны, но при неудачной настройке способны изменить адресацию так, что внутренние страницы перестают находиться.

Когда проблема связана с темой, признаки обычно шире. Могут не открываться не только записи, но и архивы, категории, страницы авторов. При этом в админке все выглядит нормально, что только сбивает с толку.

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

Что еще проверить, если базовые шаги не помогли

Если постоянные ссылки сохранены, .htaccess приведен в порядок, а плагины не виноваты, стоит идти глубже. На некоторых сайтах причиной становятся неверные настройки сервера, ограниченные права на директории или ошибки после переноса базы данных. Внешне все это проявляется одинаково, но технически причины разные.

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

Еще один момент связан с кэшем. Браузерный, серверный и плагинный кэш иногда держат старые правила, даже когда вы уже все исправили. После чистки кэша стоит протестировать сайт в приватном окне и с другого устройства. Это помогает отделить реальную ошибку от закэшированного старого ответа.

Пошаговая схема проверки

• Сохранить постоянные ссылки без изменений.
• Проверить наличие и содержимое .htaccess.
• Отключить все плагины и проверить сайт.
• Переключиться на стандартную тему.
• Очистить все виды кэша.
• Проверить настройки домена, HTTPS и адрес сайта в WordPress.

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

Если вы работаете с сайтом клиента, полезно фиксировать, что именно менялось перед появлением ошибки. Обновление плагина, смена хостинга, импорт демо-данных, редактирование .htaccess или правки в теме часто оставляют очень понятный след. Чем точнее хронология, тем быстрее находится поломка.

Когда проблема на стороне сервера

Иногда WordPress тут почти ни при чем. На Nginx, например, маршрутизация настраивается через конфигурационный файл сервера, а не через .htaccess. Если правило переписывания сломано или отсутствует, главная страница может открываться напрямую, а все внутренние адреса будут вести в 404.

То же касается хостингов с жесткими ограничениями. Бывает, что доступ к файлам есть, а права на переписывание адресов закрыты или настроены не так, как нужно. В таких случаях без поддержки хостинга можно долго ходить по кругу, хотя исправление находится на уровне сервера.

Если вы уже перепробовали все в WordPress, а поведение не меняется, стоит запросить у хостера проверку конфигурации. Нужны обычные вещи: поддержка ЧПУ, корректная обработка запросов к несуществующим файлам и правильные правила редиректа. Это не редкая история, особенно после миграции между разными типами серверов.

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

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