Ошибка 500 на WordPress: как отличить проблему хостинга от плагина

Ошибка 500 на WordPress не даёт ни одной подсказки: сервер отвечает «внутренняя ошибка» и замолкает. За этой формулировкой одинаково прячутся и сломанный плагин, и переполненный диск на хостинге, и лишняя строчка в служебном файле. Владелец сайта в такой ситуации обычно начинает звонить хостеру, а хостер отвечает, что у него всё работает — и оба правы, потому что никто не смотрит туда, где лежит ответ.

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

Чем 500 отличается от 502 и 503

Три соседних кода означают три разных состояния, и путать их дорого: направление поиска у них противоположное.

500 — внутренняя ошибка сервера. Запрос дошёл до обработчика, обработчик начал работу и упал. Это ошибка вашего кода или конфигурации: PHP, служебный файл, права доступа. В подавляющем большинстве случаев причина на стороне сайта, а не площадки.

502 — плохой ответ от вышестоящего сервиса. Фронтальный сервер обратился к обработчику PHP и получил обрыв или невнятный ответ. Типовые причины: процесс PHP упал по нехватке памяти, интерпретатор перезапускается, кончились свободные обработчики. Здесь причина чаще на стороне хостинга или тарифных лимитов.

503 — сервис временно недоступен. Сервер сознательно отказывает: перегрузка, режим обслуживания, срабатывание защиты от наплыва запросов. WordPress отдаёт этот код и сам — во время обновления, когда в корне лежит служебный файл режима обслуживания.

Практический вывод простой. Увидели 500 — начинайте с сайта. Увидели 502 или 503 — начинайте с хостинга и лимитов. Смысл остальных кодов и их влияние на индекс собраны в материале «Коды ответа сервера: руководство с примерами использования».

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

Где смотреть журнал ошибок сервера

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

Искать надо в трёх местах, и в этом порядке. Первое — панель хостинга, раздел журналов. Там обычно два файла: журнал обращений и журнал ошибок. Нужен второй. Второе — файл error_log в корне сайта или в папке того каталога, где произошла ошибка: многие конфигурации складывают его прямо рядом со скриптами. Третье — собственный журнал WordPress, который включается константами в wp-config.php:

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

Третий вариант работает только тогда, когда ошибка происходит внутри PHP и ядро успевает загрузиться. Если 500 отдаёт сам веб-сервер — например, из-за синтаксической ошибки в служебном файле, — журнал WordPress останется пустым, а причина будет видна только в журнале сервера.

Что искать в строках. Ключевые слова: Fatal error, Allowed memory size, Maximum execution time, Invalid command, Premature end of script headers, Permission denied. Каждое из них указывает на свой класс причин, и следующий шаг определяется именно этим словом, а не догадками.

Ещё один источник, о котором забывают, — журналы за прошлые дни. Если ошибка появляется вспышками, свежий журнал может быть чистым, а вчерашний содержать десятки записей. Просите у хостинга архив за неделю, если своими средствами до него не добраться. Что вообще можно вытащить из серверных журналов, разбирал в материале «Логи сервера в SEO: что в них видит робот и чего не видите вы».

Лимиты памяти и времени выполнения

Две директивы PHP отвечают за большую часть пятисотых ответов на нагруженных сайтах: предельный объём памяти на скрипт и предельное время его выполнения.

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

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

Поднимаются лимиты в трёх местах, и не все они доступны на каждом тарифе: в панели хостинга (самый надёжный путь), в файле php.ini или пользовательской конфигурации PHP, и константами WordPress для памяти. Константа WP_MEMORY_LIMIT не может превысить серверное значение — это часто становится сюрпризом.

Важно не путать симптом с причиной. Если сайту месяц назад хватало 128 мегабайт, а теперь не хватает 256, что-то изменилось: добавился плагин, вырос каталог, начал работать импорт. Поднятый лимит купит вам месяц, после чего вы упрётесь снова. Похожая логика применима и к скорости в целом — разбор реальных причин торможения собран в статье «WordPress тормозит не из-за плагинов: где искать настоящую причину».

Битый .htaccess и права на файлы

Служебный файл .htaccess — самая частая причина 500, которую находят последней. Особенность в том, что он читается сервером до запуска PHP, и одна неверная директива роняет весь сайт целиком, включая админку и статические файлы.

Проверяется быстрее всего: переименуйте .htaccess в корне, добавив к имени любой суффикс, и обновите сайт. Если ошибка исчезла — причина найдена. Главная страница при этом откроется, а внутренние адреса начнут отдавать 404: без правил перезаписи WordPress не умеет разбирать красивые адреса. Это нормально и лечится пересохранением настроек постоянных ссылок, после чего файл создастся заново с корректным базовым блоком.

Типовые источники битого файла: директива, которую поддерживает не каждая сборка сервера (плагины кэширования и безопасности любят их добавлять), правило, скопированное с чужого сайта, обрезанный при закачке по FTP файл, и накопление блоков от нескольких плагинов, которые конфликтуют друг с другом.

Вторая причина того же класса — права доступа. Веб-сервер должен иметь возможность читать файлы и не должен иметь возможность их выполнять с избыточными правами. Рабочая схема почти всегда одинакова: 644 для файлов, 755 для папок, 600 или 640 для wp-config.php. Права 777, которые советуют на форумах для решения проблем с загрузкой, на многих конфигурациях дают ровно обратный эффект: сервер отказывается исполнять скрипт, доступный на запись всем, и отдаёт 500.

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

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

Конфликт плагинов: как локализовать

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

Шаг	Действие	Ошибка исчезла	Ошибка осталась
1	Переименовать .htaccess в корне	Причина в служебном файле: пересохранить постоянные ссылки	Идти дальше, вернуть имя файла
2	Переименовать папку plugins	Причина среди плагинов: включать половинами	Идти дальше, вернуть имя папки
3	Переименовать папку активной темы	Причина в теме: проверить правки в functions.php	Идти дальше
4	Поднять лимит памяти и время выполнения	Упирались в лимиты: искать, что столько потребляет	Идти дальше
5	Проверить права: 644 на файлы, 755 на папки	Причина в правах или владельце файлов	Идти дальше
6	Заменить папки wp-admin и wp-includes из официального архива	Были повреждены файлы ядра	Причина на стороне сервера — писать в поддержку

Метод половинного деления на втором шаге сокращает перебор радикально: для тридцати плагинов достаточно пяти проверок вместо тридцати. Включаете половину списка, проверяете страницу, где ошибка воспроизводилась. Упало — виновник здесь, делите дальше. Не упало — берёте вторую половину.

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

Отдельный случай — ошибка появляется только у части посетителей. Обычно это означает, что падает не сама страница, а какой-то её вариант: версия для авторизованного пользователя, страница с товаром в корзине, результат отправки формы. Проверять такие сценарии надо целиком, повторяя действия посетителя, а не открывая адрес напрямую.

Хостинг или сайт: как понять за пять минут

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

Проверка	Указывает на хостинг	Указывает на сайт
Статический файл: robots.txt или картинка из папки загрузок	Не открывается или тоже отдаёт ошибку	Открывается мгновенно
Другой сайт на том же аккаунте	Отдаёт ошибку одновременно	Работает нормально
Код ответа	502 или 503	500
Время появления	Ночью, без ваших действий, у нескольких сайтов сразу	Сразу после обновления, правки файлов или установки плагина
Переименование .htaccess и папки плагинов	Ничего не меняет	Сайт оживает на любом из шагов
Свободное место на диске в панели	Ноль или близко к нулю	Место есть
Ошибка при обращении к phpMyAdmin	Панель тоже не открывается	Панель работает, база доступна

Если проверки указали на хостинг, обращение в поддержку стоит формулировать конкретно: адрес сайта, точный код ответа, время появления, что уже проверено. Полезные вопросы: не превышены ли лимиты по процессам, памяти и подключениям на моём тарифе; есть ли записи в журнале ошибок за указанное время; не срабатывала ли система защиты от нагрузки; не было ли плановых работ. Ответ на такое письмо приходит на порядок быстрее и по делу. Общий список серверных параметров, которые стоит держать под контролем, я собирал в статье «9 серверных проверок, которые влияют на ранжирование сильнее, чем перелинковка».

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

Почему частые 500 роняют скорость обхода

Для поисковой системы пятисотый ответ — сигнал аварии на сервере. Реакция у робота предсказуемая и защитная: он снижает частоту обращений, чтобы не добивать площадку, которая и так не справляется.

Разовое срабатывание безобидно: робот отложит визит и вернётся через некоторое время. Но регулярные ошибки — например, каждый вечер в час пик или на одной десятой части адресов — воспринимаются иначе. Сайт получает репутацию нестабильного, и лимит обхода урезается надолго.

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

Отдельный неприятный сценарий — когда 500 отдают не все страницы, а конкретный тип: например, карточки товара при обращении с определённым параметром. Владелец этого не замечает, потому что вручную такие адреса не открывает, а робот ходит именно по ним и накапливает ошибки месяцами. Найти это можно только двумя способами: регулярной проверкой кодов ответа по списку адресов из карты сайта и разбором журнала сервера с фильтром по обращениям робота. Как заметить такие отклонения на раннем этапе, писал в материале «Аномалии в обходе сайта: ранний сигнал бана, который все пропускают».

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

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

Частые вопросы

Почему после переименования .htaccess главная открылась, а внутренние страницы дают 404? Потому что правила перезаписи адресов лежали именно в этом файле. Зайдите в настройки постоянных ссылок и нажмите «Сохранить» без изменений — файл создастся заново с корректным блоком.

Помогает ли отключение кэша при ошибке 500? Иногда да: плагины кэширования добавляют свои директивы в служебный файл и создают собственные обработчики. Отключение стоит проверить на четвёртом-пятом шаге, но самой частой причиной кэш не бывает.

Может ли 500 быть следствием взлома? Может. Вредоносный код часто добавляется в начало файлов темы или в служебный файл и ломает синтаксис. Признаки: изменённые даты у файлов, незнакомые директивы перенаправления, всплеск страниц в индексе. Тогда порядок другой: чистка и переустановка ядра, а не поиск плагина.

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

Может ли причиной быть сам хостинг-провайдер при коде 500? Может, хотя это редкость: например, если на сервере обновили версию PHP без предупреждения и ваш код с ней несовместим. Проверяется просмотром текущей версии в панели и датой её изменения.

Нужно ли сообщать поисковику, что ошибки исправлены? Отдельного механизма нет. Достаточно, чтобы адреса начали стабильно отдавать 200. Ускорить возврат можно отправкой ключевых страниц на переобход и свежей картой сайта.

Стоит ли настраивать красивую страницу для ошибки 500? Для посетителей — да, это лучше белого экрана. Но код ответа при этом обязан оставаться 500: если оформленная страница начнёт отдавать 200, поисковик сочтёт её нормальным содержимым и проиндексирует.

Коротко

• Код 500 указывает на проблему сайта, коды 502 и 503 — чаще на проблему сервера или лимитов тарифа; направление поиска у них противоположное.
• Текст настоящей ошибки лежит в журнале сервера в панели хостинга или в файле error_log, а не на экране посетителя.
• Порядок проверки: служебный файл, папка плагинов, папка темы, лимиты памяти и времени, права и владелец файлов, файлы ядра.
• Права 777 не решают проблему загрузки, а создают новую: многие конфигурации отказываются исполнять такие файлы и отдают ошибку.
• Проверять надо именно проблемную страницу: пятисотая ошибка часто локальна и не видна на главной.
• Регулярные ошибки урезают скорость обхода надолго; хуже всего сценарий, когда падает один тип адресов, который владелец сам никогда не открывает.

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