Что делать, если на сайте появились ошибки 404, 500 или 403

Ошибки 404, 500 и 403 на сайте выглядят похоже только для владельца: «что-то не открывается». Технически это разные ситуации. 404 означает, что запрошенный ресурс не найден. 403 говорит, что сервер понял запрос, но отказался его выполнять. 500 — это внутренняя ошибка сервера, когда он столкнулся с неожиданным условием и не смог нормально обработать запрос. MDN описывает HTTP-статусы как коды ответа, которые показывают, был ли запрос успешно выполнен; 4xx относятся к ошибкам клиента, а 5xx — к серверным ошибкам.

Для WordPress это особенно важно, потому что за одним кодом может стоять много причин: сломанные ссылки, неправильные постоянные ссылки, конфликт плагина, ошибка темы, проблема с .htaccess, права на файлы, серверные лимиты, PHP-ошибка, кэш, редиректы или последствия обновления. Поэтому не нужно лечить все ошибки одним способом. 404, 500 и 403 требуют разной диагностики.

Как выглядит проблема

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

Ошибка 403 выглядит жёстче: доступ запрещён. Страница или раздел существуют, но сервер не отдаёт их пользователю. Часто это связано с правами доступа, настройками безопасности, блокировкой IP, ошибками в .htaccess, настройками хостинга, firewall или защитными плагинами.

Ошибка 500 — самая неприятная для владельца, потому что она часто не объясняет причину. Сервер просто сообщает, что не смог выполнить запрос. MDN прямо называет 500 generic catch-all response для серверных проблем, когда сервер не может подобрать более точный 5xx-код.

В WordPress официальная документация относит internal server error, белый экран, ошибку подключения к базе, maintenance mode и другие сбои к типовым проблемам. Среди частых причин указаны конфликты плагинов, несовместимость темы, неподходящая версия PHP, memory limit и повреждённые файлы WordPress.

Что могло её вызвать

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

Ошибка 403 чаще связана не с отсутствием страницы, а с запретом доступа. Это могут быть права на файлы и папки, правила в .htaccess, настройки Nginx/Apache, security-плагин, блокировка по IP, защита админки, запрет на выполнение PHP в определённых папках или серверный firewall. Сервер как бы говорит: «Я понял, что ты хочешь, но не дам». Очень вежливо, но сайту от этого не легче.

Ошибка 500 обычно говорит о внутренней проблеме. В WordPress это может быть фатальная ошибка PHP, конфликт плагинов, ошибка в functions.php, несовместимость с версией PHP, нехватка памяти, проблема базы данных, повреждённый .htaccess, кэш, неправильно подключённый код или сбой на стороне хостинга.

Если ошибка появилась после обновления, нужно думать не только про сам код ошибки, но и про последнее изменение. Иногда сайт работал нормально годами, потом обновился один плагин, и внезапно «сайт сам сломался». Сам, конечно. Просто совпало с обновлением, как обычно.

Что проверить безопасно

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

Дальше проверьте, где именно ошибка: на одной странице, во всём сайте, только в админке, только на мобильной версии, только после отправки формы, только на старых URL или после входа в аккаунт. Это сильно сужает поиск.

Для 404 в WordPress безопасно проверить постоянные ссылки: зайти в настройки постоянных ссылок и сохранить их заново без изменения структуры. Это может обновить правила rewrite. Но если на сайте сложная SEO-структура, категории, кастомные типы записей и редиректы, лучше сначала зафиксировать текущие настройки.

Для 500 безопаснее начать не с отключения всего подряд, а с логов. WordPress поддерживает WP_DEBUG, а официальная документация указывает, что эта константа включает debug-режим и обычно задаётся в wp-config.php. На рабочем сайте лучше не выводить ошибки посетителям, а писать их в лог.

Более безопасная диагностическая связка выглядит так:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_DISPLAY', false );
define( 'WP_DEBUG_LOG', true );

Learn WordPress объясняет, что такая конфигурация включает отладку, отключает показ ошибок на экране и включает запись в wp-content/debug.log.

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

Чего делать не стоит

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

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

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

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

Особенно опасная идея — выставлять права 777, чтобы «точно заработало». Иногда после этого действительно что-то начинает открываться. А потом начинает открываться то, что вообще не должно было открываться. Отличная победа, если целью было сделать сайт гостеприимным для проблем.

Когда уже нужна техподдержка

Техподдержка нужна, если ошибка 500 повторяется, сайт перестал открываться, 403 блокирует админку, 404 появились массово после редизайна или переноса, а также если для диагностики нужны доступы к хостингу, FTP/SFTP, логам, базе данных, .htaccess, Nginx/Apache-конфигам или настройкам безопасности.

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

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