Ошибка 503: почему сайт «временно недоступен» и что это делает с позициями

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

Отдельно разберу популярный совет «закройте сайт кодом 503 с заголовком Retry-After, и робот вернётся позже» — я проверил его по справке Яндекса, и там всё не так, как повторяют на форумах. Если окажется, что падения повторяются каждую неделю и дело не в одной кнопке, есть продвижение сайта в Яндексе под ключ: техническую часть я в любом случае начинаю с того, какие коды ответа сервер отдаёт роботу.

Что именно сообщает код 503 и чем он отличается от 500

Пятисотые коды означают, что виноват сервер, — но внутри них важно различать три штуки. Код 500 в справочнике Яндекса описан так: «Сервер столкнулся с непредвиденным условием, которое не позволяет ему выполнить запрос». Это поломка в коде: ошибка в PHP, конфликт плагинов, кривая строка в конфигурации. Код 502 — «Сервер получил недопустимый ответ от следующего сервера в цепочке запросов»: так отвечает nginx, когда обращается к PHP, а тот молчит.

А 503 сформулирован иначе: «Возникла ошибка из-за временной перегрузки или отключения на техническое обслуживание сервера». Ключевое слово — «временной». Это не поломка, а отказ обслуживать здесь и сейчас. Сервер принял запрос, понял, чего от него хотят, и осознанно ответил: не сегодня.

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

Лежит у всех или только у вас: проверка за две минуты

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

Дальше смотрим, что сервер отдаёт роботу, а не браузеру. В Вебмастере есть инструмент «Проверка ответа сервера»: вбиваете адрес и видите тот код, который получит поисковая машина. Там же, в разделе «Индексирование» → «Статистика обхода», видна история кодов за последние дни. Если за вчерашний вечер внезапно полторы тысячи строк с пятисотыми — падение длилось не пять минут, а всю ночь.

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

Откуда берётся 503 на сайте малого бизнеса

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

Лимиты тарифа. Хостинг считает нагрузку за сутки, и когда вы выбираете квоту процессорного времени, сайт уводят на заглушку до конца расчётного периода. Владелец уверен, что «ничего не менялось», а месяц назад поставили плагин, который каждые пять минут опрашивает внешний сервис.

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

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

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

Что видите на экране, что за этим стоит и куда смотреть

Что видите	Вероятная причина	Что проверить первым
503 на всех страницах, включая админку	Сервер или база легли целиком	Панель хостинга: жив ли сайт как услуга, не приостановлен ли тариф
503 у посетителей, админка открывается	Включён режим обслуживания или заглушка кэша	Файл-флаг обслуживания в корне, настройки плагина обновлений
503 то появляется, то пропадает	Перегрузка: лимит процессов кончается на пиках	График нагрузки в панели, число одновременных посетителей
503 ровно с определённого часа каждый день	Задача по расписанию или выборка квоты суток	Список заданий cron, потребление ресурсов по часам
503 только у части разделов	Отваливается один тяжёлый модуль или внешний сервис	Логи ошибок за время падения, какие адреса дают ошибку
503 и тысячи запросов с одних подсетей	Наплыв ботов или парсинг	Список IP по частоте обращений, какие адреса они дёргают
Не 503, а 500 или 502	Это не перегрузка, а поломка кода или связки серверов	Лог ошибок PHP, последние изменения на сайте

Последнюю строку добавил не зря: половина обращений «у нас 503» на проверке оказывается пятисотым или пятьсот вторым. Как отделить проблему хостинга от проблемы плагина, я показывал на примере ошибки 500 в WordPress.

Порядок действий, если сайт отдаёт 503 прямо сейчас

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

Второе. Посмотрите графики нагрузки за сутки: процессор, память, число процессов. Линия упёрлась в потолок и стоит там — это перегрузка, вопрос только в том, что её создаёт.

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

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

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

Шестое. Если нагрузку создают роботы, снижайте её адресно. Яндекс в справке «Как снизить нагрузку на сайт или сервер» предлагает сначала убрать лишние страницы из обхода — директивами Clean-param и Disallow, — и только потом трогать коды: «Если вы считаете, что нагрузка не связана с лишними страницами, вы можете настроить сервер так, чтобы он отвечал HTTP-кодом 429». Такой ответ «укажет на то, что сервер испытывает затруднения с нагрузкой — робот Яндекса уменьшит число обращений». Обратите внимание: для этой задачи Яндекс называет 429, а не 503. Скорость обхода при этом настраивается отдельно, в Вебмастере: «Индексирование» → «Скорость обхода», где по умолчанию стоит «Доверять Яндексу». Старый способ через директиву Crawl-delay в robots.txt уже не работает — Яндекс перестал её учитывать с 22 февраля 2018 года, так что если она до сих пор стоит в вашем файле, это мёртвая строка.

Как код 503 выглядит со стороны поискового робота

Здесь я разойдусь с половиной статей в интернете. Для робота 404 и 503 — принципиально разные сигналы. Код 404 означает «документа не существует» и утверждает нечто о будущем: страницы нет и не будет. Код 503 означает «сейчас не отдам», без утверждений о завтрашнем дне. Поэтому отдавать 503 на время работ осмысленнее, чем 404 или, хуже того, двухсотый код с текстом «ведутся работы»: в последнем случае робот получает формально успешный ответ и вправе считать заглушку новым содержимым страницы.

Но дальше начинается то, чего в мифе нет. В официальном блоге Яндекса для вебмастеров про серверные ошибки сказано прямо: «если страницы не отвечают http-кодом 200 ОК, то они будут вовсе исключены из поиска по мере обхода робота и обновления поисковой базы. Это также относится к кодам 5ХХ». То есть 503 не создаёт неприкосновенности. Он мягче 404 по смыслу, но при длительной отдаче страницы всё равно уходят из выдачи.

Теперь про Retry-After. Это стандартный заголовок HTTP, которым сервер сообщает, через сколько имеет смысл повторить запрос. Совет «отдавайте 503 с Retry-After, и робот придёт ровно через указанное время» кочует из статьи в статью. Единственное место, где Яндекс вообще упоминает этот заголовок, относится к коду 429: «Ответ может сопровождаться заголовком Retry-After, который указывает, через какое время можно повторить запрос. Яндекс не учитывает этот заголовок». Применительно к 503 в справке он не описан никак.

Отсюда правило, которым я пользуюсь на клиентских проектах: заголовок ставить можно, он корректен по стандарту и его понимают другие системы. Но строить план техработ на обещании «робот подождёт столько, сколько мы написали» нельзя — Яндекс такого обещания не давал, а в одном задокументированном случае прямо сказал, что заголовок игнорирует. Показательно и то, что рекомендует сама справка в описании 503: «При плановых технических работах обеспечьте быстрое восстановление работоспособности сервера». Не «поставьте заголовок», а «восстановите быстрее». Значение имеет длительность простоя, и никакой заголовок этого не отменяет.

Плановые работы: как увести сайт на обслуживание и сколько можно лежать

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

Заглушка отдаётся с кодом 503, а не с двухсотым. Это единственное обязательное техническое требование. Проверяется инструментом проверки ответа: увидели 503 — настроено верно; увидели 200 — вы прямо сейчас скармливаете роботу текст «сайт на обслуживании» в качестве содержимого всех страниц. После окончания работ главная и ключевые разделы отправляются на переобход: «Индексирование» → «Переобход страниц».

Про сроки честный ответ такой: точного порога Яндекс не публикует. Формулировка из блога — «по мере обхода робота и обновления поисковой базы», а это разное время для разных сайтов: популярный магазин обходят несколько раз в сутки, редко обновляемый сайт услуг — раз в несколько дней. Рабочее правило, которое я даю клиентам: до часа обычно не успевают заметить; несколько часов — заметят, но восстановится само; сутки и дольше — готовьтесь к просадке и к возврату страниц переобходом. И отдельная строка: если сайт падает регулярно по десять минут, суммарный эффект хуже одного планового часа, потому что робот раз за разом упирается в ошибку.

Что проверить после того, как сайт поднялся

Сайт открылся в браузере — и все выдохнули. А половина работы ещё впереди.

Что проверяем	Где смотреть	Что считать нормой
Код ответа главной и разделов	Проверка ответа сервера в Вебмастере	200 на всех проверенных адресах
Заглушка обслуживания убрана	Корень сайта, настройки плагина обновлений	Файла-флага нет, сайт открывается из инкогнито
Статистика обхода	Вебмастер → Индексирование → Статистика обхода	Пятисотые прекратились, снова растут страницы с кодом 200
Формы заявок	Тестовая заявка со стороннего адреса почты	Письмо дошло, заявка видна там, где вы её ждёте
Оплата и корзина	Тестовый заказ до шага оплаты	Шаги проходятся без ошибок
Переобход ключевых страниц	Вебмастер → Индексирование → Переобход страниц	Главная и 5–10 важных адресов отправлены
Причина падения устранена	Логи ошибок, графики нагрузки	Пик не повторяется вторые сутки

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

Когда инструкция не сработает и когда нужен специалист

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

Падения повторяются, а нагрузку создаёт не трафик — так бывает при парсинге, переборе паролей к админке, заражённом сайте. Нужен разбор логов и правила на уровне сервера, а не кнопка в панели.

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

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

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

Можно ли просто перезагрузить сервер и забыть?

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

Нужно ли закрывать сайт в robots.txt на время работ?

Нет. Запрет в robots.txt — это про обход, а не про временную недоступность, он решает другую задачу. Хуже того, забытая строчка запрета живёт годами и выносит из поиска целые разделы. На время работ достаточно корректного кода 503 на заглушке.

Что делать, если хостинг отвечает «у нас всё работает»?

Дайте фактуру вместо эмоций: точное время падения с минутами, снимок кода ответа из инструмента проверки, строки из лога ошибок за эти минуты, адрес конкретной страницы. С таким письмом разговор переходит из «у вас что-то не так» в «вот наш лог за 03:12». Заодно попросите график потребления ресурсов — там видно, упёрлись вы в лимит тарифа или нет.

Падение сайта — это проблема продвижения или проблема сервера?

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

Коротко

Код 503 означает временную перегрузку или отключение на обслуживание — сервер жив и отвечает осознанно. Это другая ветка диагностики, чем 500 (поломка кода) и 502 (обрыв между серверами).

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

Для поиска 503 мягче, чем 404, потому что не утверждает «страницы не существует». Но иммунитета он не даёт: в блоге Яндекса сказано, что страницы, отвечающие не кодом 200, исключаются из поиска по мере обхода, и к кодам 5ХХ это тоже относится.

Заголовок Retry-After при 503 в справке Яндекса не описан. Единственное упоминание относится к коду 429, и там сказано, что Яндекс этот заголовок не учитывает. Ставьте его по стандарту, но не стройте на нём план работ.

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

После подъёма проверяется не только «открывается ли сайт»: коды ответа, статистика обхода, формы заявок, оплата — и главное, названа ли причина падения словами.

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