Вы открываете страницу сайта, а вместо статьи, товара или формы появляется 404 Not Found. Иногда не работает одна старая ссылка, иногда после переноса внезапно исчезают все внутренние страницы, а бывает и так, что главная открывается нормально, но любой другой адрес заканчивается ошибкой.
Код 404 означает, что сервер получил запрос, но не нашел ресурс по указанному адресу. Сам сервер при этом доступен. Это важная подсказка: ошибка 404 отличается от ситуации, когда сайт вообще не отвечает, домен не направлен на сервер или веб-сервер возвращает ошибку 500.
Причина может быть совершенно безобидной — пользователь ошибся в адресе или страница действительно удалена. Но если 404 неожиданно появилась на существующих страницах, искать проблему придется в структуре URL, настройках CMS, файлах сайта, правилах перенаправления или конфигурации хостинга.
Главное — не начинать исправление наугад. Сначала нужно понять масштаб проблемы. Одна страница с 404 и весь сайт с сотнями таких ошибок — два совершенно разных случая.
Почему появляется ошибка 404 и как быстро найти причину
Начните с главной страницы. Если она тоже не открывается, проблема может быть шире обычной ошибки отдельного URL. Если главная работает, откройте несколько заведомо существующих страниц.
Предположим, главная открывается, раздел услуг тоже работает, а 404 возникает только по адресу одной статьи. В таком случае сервер и сайт в целом исправны. Скорее всего, проблема связана именно с этой страницей или ее адресом.
Проверьте URL внимательно. Лишний символ, пропущенная буква, неправильный слеш или старый адрес после изменения структуры сайта могут привести на несуществующий ресурс.
На некоторых серверах имеет значение регистр символов в именах файлов. Для человека Image.jpg и image.jpg выглядят почти одинаково, но сервер может считать их разными файлами. Это особенно заметно после переноса проекта с локальной среды или другой операционной системы.
Следующий вопрос — существует ли сама страница.
Если материал удалили намеренно и замены ему нет, ответ 404 может быть совершенно правильным. Не каждая ошибка 404 означает техническую поломку, которую необходимо устранить.
Другая ситуация возникает, когда страницу переименовали или перенесли на новый URL. Старый адрес продолжает встречаться в поиске, закладках, социальных сетях и на других сайтах, но по нему уже ничего нет. Тогда нужно решить, существует ли подходящая новая страница, на которую имеет смысл перенаправить посетителя.
Если новая версия есть, обычно используют постоянное перенаправление 301 со старого URL на наиболее подходящий новый. Если аналогичной страницы больше нет, искусственно отправлять всех на главную только ради исчезновения 404 не стоит.
Особенно подозрительна ситуация, когда ошибка одновременно появляется у большого количества страниц.
Например, вчера сайт работал нормально, а сегодня главная открывается, но все статьи и категории возвращают 404. Маловероятно, что десятки файлов исчезли независимо друг от друга. Гораздо вероятнее проблема с правилами обработки URL.
Вспомните, что происходило непосредственно перед появлением ошибки. Обновлялась CMS? Менялась структура постоянных ссылок? Редактировался .htaccess? Сайт переносили на другой хостинг? Менялся домен? Устанавливался плагин кеширования или безопасности?
Последнее изменение часто приводит к причине быстрее, чем перебор всех возможных вариантов.
После переноса сайта проверьте, действительно ли все файлы оказались на новом сервере и загружены в правильную директорию. Если документ существует в базе данных CMS, но связанные файлы или конфигурация перенесены неправильно, сайт может вести себя непредсказуемо.
Для статического сайта диагностика еще проще. Если ссылка ведет на /contacts.html, соответствующий файл должен существовать там, где его ожидает веб-сервер. Если файла нет или он лежит в другом каталоге, сервер закономерно отвечает 404.
Для сайтов на CMS адрес страницы часто вообще не соответствует физическому HTML-файлу. URL обрабатывается самой системой через правила веб-сервера. Поэтому наличие файлов WordPress на месте еще не означает, что красивые адреса записей будут работать.
Что делать, если WordPress показывает 404
У WordPress есть характерная ситуация: главная страница работает, административная панель доступна, записи существуют, но при попытке открыть любую из них появляется 404.
Первое, что стоит проверить в таком случае — постоянные ссылки.
Откройте административную панель WordPress, перейдите в Настройки, затем в Постоянные ссылки. Посмотрите, какая структура выбрана, и сохраните настройки еще раз.
Это простое действие заставляет WordPress обновить правила обработки постоянных ссылок. После этого снова откройте проблемную страницу.
Если страницы заработали, причина была не в удаленных материалах и не в базе данных, а в правилах маршрутизации URL.
Если проблема осталась, следующий кандидат — файл .htaccess на сервере Apache. Он обычно находится в корневой директории сайта и может быть скрыт в файловом менеджере из-за точки в начале имени.
Перед любыми изменениями сделайте его копию.
WordPress использует правила перезаписи URL, чтобы адрес вроде /uslugi/remont/ обрабатывался системой, хотя физического каталога /uslugi/remont/ на сервере может вообще не существовать.
Если .htaccess был удален, поврежден или в нем появились конфликтующие правила, красивые постоянные ссылки могут перестать работать.
Не стоит бездумно копировать большой чужой .htaccess из случайной инструкции. В нем могут находиться правила для другой структуры сайта, версии сервера, HTTPS, поддомена или плагинов. Гораздо безопаснее сохранить текущий файл и восстановить стандартные правила WordPress, соответствующие вашей конфигурации.
Есть еще один важный нюанс: .htaccess относится прежде всего к Apache и совместимым сценариям. Если сайт работает на Nginx, правила маршрутизации задаются в конфигурации веб-сервера иначе. Поэтому совет отредактировать .htaccess не является универсальным решением любой ошибки 404.
Если вы пользуетесь обычным виртуальным хостингом и не знаете, какой веб-сервер используется, это можно уточнить в документации или технической поддержке провайдера.
Ошибка может появиться и после изменения адреса конкретной записи. Например, был URL /remont-kvartir/, а редактор изменил его на /otdelka-kvartir/. Новый адрес работает, старый больше не существует.
В таком случае проблема уже не в WordPress как системе. Нужно настроить перенаправление со старого адреса на новый, если содержимое действительно было перемещено.
Отдельно проверьте плагины, если 404 появилась сразу после установки или обновления расширения. Особенно внимательно стоит относиться к плагинам, которые меняют структуру URL, перенаправления, мультиязычность, кеширование или правила безопасности.
Не нужно сразу удалять половину сайта. Если есть подозрение на конкретное расширение, сначала создайте резервную копию и проведите контролируемую проверку. Для рабочего коммерческого сайта такие эксперименты безопаснее выполнять на тестовой копии.
Если WordPress находится не в корне домена, а в подкаталоге, дополнительно проверьте базовый адрес сайта и конфигурацию маршрутизации. Неправильное сочетание URL WordPress, URL сайта и серверных правил тоже способно привести к 404.
Почему 404 появляется после переноса сайта или смены домена
Переезд на другой хостинг — один из моментов, когда ошибки 404 проявляются особенно часто. На старом сервере все работало, файлы и база вроде бы скопированы, домен уже направлен на новый хостинг, но часть адресов исчезла.
Сначала убедитесь, что сайт размещен в правильной корневой папке домена.
У одного хостинга это может быть public_html, у другого используется собственная структура каталогов. Если домен смотрит не в ту директорию, веб-сервер будет искать страницы совсем не там, куда вы загрузили проект.
На VPS этот параметр задается в конфигурации виртуального хоста. Ошибка в DocumentRoot способна создать очень странную картину: домен работает, веб-сервер отвечает, но нужного содержимого по ожидаемым адресам нет.
Далее проверьте полноту переноса.
При копировании по FTP можно не заметить пропущенный файл или скрытый .htaccess. Архив мог распаковаться в дополнительную вложенную папку. В результате вместо содержимого корня сайта появляется каталог с еще одним каталогом внутри.
Для CMS нужно перенести не только файлы, но и базу данных, а затем проверить конфигурацию подключения к ней.
Если менялся домен, внутри базы и настроек могут остаться старые URL. Это не всегда приводит именно к серверному 404, но создает битые ссылки на изображения, страницы и другие ресурсы.
После смены структуры сайта старые адреса нужно сопоставить с новыми. Если страница переехала с одного URL на другой и продолжает выполнять ту же функцию, настройте 301 редирект.
Не отправляйте сотни исчезнувших адресов на главную страницу только потому, что так проще. Посетитель, который искал конкретную инструкцию, не получает ответа, а поисковой системе такое перенаправление тоже не объясняет, где теперь находится прежний материал.
Если подходящего аналога нет и страница действительно удалена навсегда, 404 является нормальным ответом. Ее можно оставить, предварительно убрав внутренние ссылки на несуществующий URL.
После переезда также проверьте внутреннее меню, ссылки в статьях, изображения, CSS и JavaScript. Ошибка 404 может относиться не только к HTML-странице. Браузер способен успешно открыть сам материал, но получить 404 при запросе изображения, шрифта или скрипта.
Посетитель в таком случае может вообще не увидеть надпись 404. Вместо нее он заметит пропавшую фотографию, сломанную верстку или неработающую кнопку.
Такие ошибки удобно искать через инструменты разработчика браузера и журналы запросов сервера. Если один и тот же отсутствующий файл запрашивается на каждой странице, он способен создавать тысячи ненужных запросов.
Еще один источник проблемы после переезда — различия серверной конфигурации. Правила, работавшие на Apache, нельзя автоматически считать корректными для Nginx. Старые директивы, особенности обработки URL и настройки CMS необходимо проверять уже в новом окружении.
Поэтому после миграции важно протестировать не только главную страницу. Откройте несколько записей, категории, форму обратной связи, поиск, изображения и другие типовые разделы. Рабочая главная еще не означает успешный перенос всего сайта.
Нужно ли исправлять все ошибки 404 и как они влияют на сайт
Сам по себе код 404 не является чем-то неправильным. Если ресурса действительно нет, сервер должен честно об этом сообщить.
Проблема начинается, когда 404 получает адрес, который должен работать, либо когда сайт продолжает активно ссылаться на удаленную страницу.
Представьте интернет-магазин, в котором товар снят с продажи. Если у него появился прямой аналог, посетителя можно перенаправить на соответствующую новую страницу. Если товар исчез навсегда и равноценной замены нет, бессмысленно автоматически отправлять человека на главную или случайную категорию.
С информационными материалами похожая логика. Две статьи объединили в одну — старый URL можно перенаправить на объединенный материал. Удалили устаревшую новость, которой нет замены — допустимо оставить корректный ответ об отсутствии страницы.
Поэтому задача владельца сайта заключается не в том, чтобы добиться нулевого количества 404 любой ценой, а в том, чтобы убрать ошибочные и ненужные 404.
Особенно важно исправлять внутренние битые ссылки. Если меню, статья или карточка товара ведут на несуществующую страницу, посетитель сталкивается с тупиком, созданным самим сайтом.
Проверять такие адреса можно с помощью инструментов для обхода сайта, систем аналитики, панели вебмастера и серверных логов. Для небольшого проекта полезно хотя бы периодически просматривать отчеты об ошибочных URL после крупных изменений структуры.
Собственная страница 404 тоже полезна, но она не исправляет саму ошибку.
Хорошая страница может объяснить посетителю, что нужный материал не найден, предложить перейти на главную, воспользоваться поиском или открыть основные разделы. Она помогает человеку продолжить работу с сайтом вместо закрытия вкладки.
При этом сервер должен продолжать возвращать правильный HTTP-код 404. Страница с красивой надписью Не найдено, которая технически отвечает кодом 200 OK, создает уже другую проблему: для сервера и поискового робота это выглядит как существующий документ.
Если 404 появилась внезапно сразу на большом количестве рабочих страниц, не начинайте массово создавать редиректы. Сначала найдите общую техническую причину. Исправление постоянных ссылок или серверной конфигурации может вернуть сотни URL за одно действие.
А если ошибка возникла только у одной страницы, действуйте от ее истории: существует ли она, менялся ли адрес, есть ли новая версия и откуда пользователи попадают на старый URL.
Получается довольно простой алгоритм. Одна 404 — проверяем конкретный адрес и существование страницы. Массовые 404 при работающей главной — смотрим маршрутизацию, постоянные ссылки, .htaccess или конфигурацию веб-сервера. Ошибки после переноса — проверяем корневую директорию, полноту файлов, базу данных и старые URL. Ошибки у изображений и скриптов — ищем неверные пути к ресурсам.
И только после определения причины решаем, что действительно нужно сделать: восстановить страницу, исправить ссылку, поправить конфигурацию, настроить 301 редирект или оставить честный 404.
Именно поэтому ошибка 404 не всегда означает проблему с хостингом. Наоборот, сервер часто работает совершенно нормально и лишь сообщает, что по запрошенному адресу ничего не найдено. Хорошая диагностика начинается не со смены хостинга и не с установки очередного плагина, а с простого вопроса: какой именно URL не работает и должен ли по нему вообще существовать ресурс.
