Технические работы на сайте: как правильно вернуть 503

Если действующий сайт нужно ненадолго остановить для обновления базы, переноса оборудования или рискованного релиза, сервер должен честно сообщить о временной недоступности. Для этого предназначен HTTP-код 503 Service Unavailable. Он говорит браузеру и поисковому роботу: содержимое URL сейчас получить нельзя, причина временная, запрос следует повторить позже.

Самая опасная ошибка — показать всем адресам одинаковую заглушку с кодом 200. Тогда робот получает «успешную» страницу и может принять служебный текст за новое содержание тысяч URL. Не лучше отдавать 404 или 410: эти ответы означают отсутствие ресурса, а не короткие работы. Добавление noindex тоже неверно для краткой остановки, потому что просит удалить страницы из результатов.

503 полезен только как кратковременный режим. Он не сохраняет позиции бессрочно и не подходит для закрытия сайта на недели. Актуальные рекомендации Google предупреждают, что многодневные серверные ошибки снижают обход и могут привести к выпадению URL; Яндекс также советует быстро восстановить работоспособность. Планируйте окно в часах, задавайте Retry-After, следите за ответами и имейте способ отката.

Когда нужен код 503

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

Типичные сценарии — миграция базы с короткой блокировкой записи, обновление CMS, переключение хранилища, обслуживание дата-центра, восстановление после аварии. Если каталог доступен, но нельзя оформить заказ, не обязательно закрывать весь сайт. Оставьте информационные и товарные страницы с 200, честно отключите недоступное действие, а 503 возвращайте только endpoint, который действительно не может выполнить запрос.

Код не предназначен для новой страницы, которая ещё не опубликована, или удалённого товара без замены. Для отсутствующего ресурса используются 404 либо 410, для постоянного переноса — 301. Разница между группами ответов объяснена в материале об HTTP-кодах. Неправильный код искажает смысл даже при красивом сообщении в браузере.

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

Почему режим должен быть кратким

Когда робот видит 5xx, он временно уменьшает частоту запросов. Это защищает перегруженный сервер, но одновременно замедляет обновление данных. Если ошибки продолжаются, поисковая система перестаёт считать ситуацию краткой. В актуальной документации Google для управления обходом упоминается риск негативного эффекта уже при режиме дольше одного-двух дней, а постоянные серверные ошибки способны привести к удалению URL из индекса.

Не воспринимайте число дней как безопасную квоту. Частота обхода различается по сайту и URL, а восстановление после долгой паузы не мгновенно. Правильная цель — минимальное окно, обычно минуты или часы. Для сложных работ заранее подготовьте миграцию, прогоните её на копии данных, снизьте DNS TTL при необходимости и измерьте реальную длительность репетиции.

У режима должны быть владелец и крайнее время. Если операция не завершилась, команда либо откатывается, либо переходит на заранее подготовленный сценарий частичной доступности. Решение «оставим 503 до завтра и разберёмся утром» превращает контролируемое обслуживание в инцидент. Мониторинг должен напомнить о превышении окна раньше поискового отчёта.

После возврата 200 робот постепенно восстанавливает обход; нет кнопки, которая гарантированно вернёт прежний ритм мгновенно. Не включайте массовый IndexNow или переобход до проверки, иначе поисковик быстрее увидит неисправную версию. Сначала подтвердите коды, содержание и навигацию, затем сообщайте об изменениях при необходимости.

Из чего состоит правильный ответ

Минимальный ответ содержит строку статуса 503 Service Unavailable, понятный Content-Type и небольшое тело с сообщением пользователю. Код должен приходить на исходном URL: человек открывает карточку или статью и получает временный ответ именно с этого адреса. Не требуется массово перенаправлять все запросы на отдельную страницу с 200.

Полезно добавить Retry-After с реалистичной оценкой восстановления. Для временной страницы настройте кеширование так, чтобы CDN и браузер не продолжали показывать её после запуска. Часто используют Cache-Control: no-store либо короткую политику, согласованную с инфраструктурой. Проверьте фактическое поведение каждого кеширующего слоя — одного заголовка в приложении может быть недостаточно.

Тело 503 не должно зависеть от базы, шаблонизатора и API, которые обслуживаются. Лучше статический HTML с inline CSS, небольшим логотипом или вовсе без внешнего изображения. Если страница тянет десяток скриптов с того же недоступного сервера, посетитель увидит пустой экран, а нагрузка возрастёт. Google также рекомендует минимизировать внешние ресурсы для такого режима.

Не добавляйте к заглушке meta noindex. Поисковые системы игнорируют тело 5xx для индексирования, а noindex передаёт другой смысл и становится опасным, если код по ошибке превратится в 200. Не меняйте canonical всех страниц на адрес заглушки. Исходные URL сохраняют идентичность; временный ответ описывается HTTP-кодом.

Пока URL отвечает 503, Google не может обновлять его Title, Description, другие метаданные и структурированные данные. Поэтому не совмещайте окно обслуживания с публикацией изменений, которые должны сразу появиться в поиске. Сначала верните штатный ответ, проверьте новый HTML и только затем ожидайте очередного обхода. Retry-After подсказывает время повторного запроса, но не назначает момент переиндексации и не заставляет поисковик принять обновления в указанную секунду. Это ещё одна причина отделять обслуживание инфраструктуры от контентного релиза.

Как настроить Retry-After

Заголовок Retry-After сообщает ожидаемое время следующей попытки. Допустимы два формата: количество секунд либо дата HTTP. Для окна, которое началось неожиданно и предположительно закончится через 30 минут, можно передать Retry-After: 1800. Для запланированного точного окончания подходит дата в корректном формате GMT.

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

Проверьте, что заголовок присутствует в фактическом ответе CDN и балансировщика. Приложение может отправить Retry-After, но прокси заменит страницу собственной ошибкой. Обратная ситуация — edge продолжает добавлять старое значение после восстановления. Запрашивайте несколько URL из внешней сети и смотрите финальные заголовки, а не только конфигурационный файл.

Retry-After не делает длительный 503 безопасным и не гарантирует сохранение URL. Это дополнительная информация для клиентов и роботов. Главные условия — временность, правильный код и быстрое восстановление. Не пытайтесь с помощью далёкой даты превратить закрытый сайт в законсервированный индекс.

Отдельно задайте политику кеширования заглушки. Если CDN сохранит ответ надолго, часть посетителей продолжит видеть работы после восстановления; если каждый запрос безусловно доходит до перегруженного backend, заглушка не выполняет защитную роль. Обычно короткое контролируемое кеширование на внешнем слое сочетают с явной очисткой при открытии. Фактический статус и Retry-After проверяют как при включении, так и после очистки.

Значение должно быть одинаково объяснимым для главной, статьи и карточки товара. Не рассчитывайте время отдельно по User-Agent и не отдавайте роботу более оптимистичный ответ, чем человеку. Если разные части сервиса восстановятся поэтапно, открывайте только проверенные маршруты, а на остальных сохраняйте собственный реалистичный 503. Это точнее, чем обещать единый срок для системы с разными зависимостями.

Как сделать полезную страницу работ

Сообщение должно прямо сказать, что сервис временно недоступен, когда ожидается возвращение и что может сделать человек. Избегайте формулировки «страница не найдена»: она противоречит 503. Если доступны телефон, статус-страница или поддержка на независимой инфраструктуре, дайте контакт. Не обещайте точную минуту, если команда не уверена.

Сохраните узнаваемое название компании и простой дизайн, но не копируйте весь обычный шаблон. Меню ведёт на те же 503 и создаёт круг; форма поиска не работает; чат может зависеть от отключённого API. Лучше одна лёгкая страница с текстом и внешним каналом помощи. Она должна корректно читаться с телефона и программами доступности.

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

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

Какие URL закрывать, а какие оставить

Самый безопасный для SEO и бизнеса вариант — не отключать то, что может работать. Если недоступна только оплата, каталог, статьи, контакты и история заказов могут остаться с 200. Кнопка заказа честно сообщает об ограничении, не принимает данные и не обещает выполнение. API оплаты возвращает соответствующую временную ошибку. Так люди продолжают получать информацию, а робот не видит массовый сбой.

При полной остановке 503 возвращают рабочие HTML-URL и зависимые endpoint. Однако robots.txt желательно оставить доступным с 200 и прежними правилами. Текущая документация Google отдельно предупреждает не возвращать 503 для robots.txt при временной приостановке, потому что это способно блокировать весь обход. Не заменяйте файл на Disallow: /: это иной сигнал и не нужен для короткого окна.

Sitemap можно оставить статически доступным, если инфраструктура позволяет, но не обновлять ложными URL. Статус-страница и сам минимальный файл заглушки также должны загружаться. CSS лучше встроить, чтобы не создавать исключения для ресурсов. Если CDN продолжает отдавать изображения, это не означает, что HTML должен отвечать 200.

Административный доступ ограничивают отдельно от публичного режима. Инженеры могут входить через VPN или специальный hostname, но поисковый робот не должен получать обход 503 по User-Agent. Не делайте правило «людям 503, Googlebot 200» или наоборот: подмена создаёт риск клоакинга и мешает честной проверке. Исключение основано на авторизации и сети команды, а не на названии робота.

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

Лучшее место — слой, который остаётся доступным, когда приложение остановлено: CDN, reverse proxy, load balancer или отдельный временный сервер. Если 503 формирует сама CMS, обновление CMS может лишить её способности отвечать. Конфигурация на внешнем уровне позволяет вывести backend из работы и продолжать отдавать маленький корректный ответ.

В Nginx обычно настраивают условие обслуживания, return 503 или перехват ошибки и статический файл, добавляют Retry-After и исключают необходимые служебные пути. В Apache используют ErrorDocument, правила обслуживания и заголовки. Не копируйте конфигурацию без проверки: порядок location, rewrite, кеша и прокси различается, а внутренняя страница ошибки может случайно изменить статус на 200.

В PHP минимальный ответ задаётся через http_response_code(503) и header('Retry-After: 3600'), после чего выводится статический HTML. Этот способ покрывает только запросы, дошедшие до PHP, и зависит от работоспособности runtime. Статические файлы, кеш и другой backend могут продолжить отвечать иначе. Поэтому результат проверяют снаружи.

Подготовьте переключатель заранее и храните конфигурацию в системе версий. У него два однозначных состояния, журнал времени и ограниченный круг операторов. Автоматическое выключение по таймеру полезно как предохранитель, но не должно открывать неисправный сайт: перед восстановлением нужен healthcheck. Репетиция на staging подтверждает механику, а финальный smoke-тест — реальные правила продакшена.

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

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

Почему нельзя использовать 200, 404 и noindex

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

Коды 404 и 410 означают, что ресурса нет. Google относит большинство 4xx, кроме 429, к отсутствующему контенту и со временем удаляет ранее известные URL. Для короткого обслуживания это противоположно цели. Полезная страница 404 нужна действительно несуществующим адресам; её устройство описано в материале про страницу 404.

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

Массовый 302 на главную или страницу статуса меняет адрес назначения и не объясняет недоступность исходного ресурса. Пользователь теряет контекст, робот получает множество перенаправлений в одну точку. Гораздо точнее вернуть 503 прямо с исходного URL и показать одинаковое тело, сохранив код. Если ресурс действительно переехал, применяют правила редиректов из статьи о 301 и 302.

Как проверить 503 до и во время работ

До окна разверните режим в окружении, близком к продакшену. Проверьте главную, несколько разделов, карточки, статьи, URL с параметрами, 404, API, статические ресурсы, robots.txt и Sitemap. Зафиксируйте ожидаемый ответ для каждого типа. Не требуйте 503 от того, что должно оставаться доступным, и не позволяйте рабочим страницам случайно отвечать 200 с заглушкой.

Используйте запрос, который показывает заголовки и не скрывает переходы. Проверьте статус, Retry-After, Content-Type, Cache-Control, Location и тело. Затем запросите тот же URL через разные CDN-точки или внешние локации. Браузерная проверка важна для вида страницы, но панель «Network» или командный клиент подтверждает фактический код.

Во время работ мониторинг разделяют. Первый сигнал — доля URL с ожидаемым 503; внезапный 200 может означать обход режима, 404 — ошибочное правило, 502 — сломанный прокси. Второй — работоспособность независимой статус-страницы и robots.txt. Третий — доступность административного пути для команды. Четвёртый — таймер окна и готовность отката.

Не используйте один публичный healthcheck, который всегда отвечает 200, как доказательство здоровья всего сайта. Для открытия трафика нужен внутренний тест базы, приложения и критичных зависимостей, затем внешняя выборка пользовательских URL. Постоянный контроль кодов удобно встроить в SEO-мониторинг сайта, а время ответа — сопоставлять с рекомендациями из материала про TTFB.

Закрепите этот набор как SEO-регрессионную проверку релиза: до окна он подтверждает механику 503, а после — исчезновение заглушки, восстановление прежних canonical, robots и внутренних ссылок. Тогда следующая операция использует готовый контракт, а не заново составленный вручную список.

Включите в выборку URL с разным прежним состоянием. Действующая страница до работ должна вернуться к 200, постоянный редирект — снова вести на свою утверждённую цель, а реально удалённый адрес — отвечать прежним 404 или 410. Нельзя после выключения режима требовать 200 от всех запросов: это скроет ошибку маршрутизации и создаст soft 404. Отдельно проверьте методы HEAD и GET, вариант домена, HTTPS, страницы с параметрами и ответы из нескольких точек CDN. Тело заглушки может быть одинаковым, но заголовки не должны случайно добавлять canonical на страницу статуса или noindex, который сохранится в кеше. Зафиксируйте контрольные значения до окна, чтобы после восстановления сравнивать не с памятью команды, а с проверяемой базой. Если открытие идёт частями, ведите список уже возвращённых маршрутов и не считайте общее здоровье по одной главной странице.

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

Числовой пример: окно работ на 90 минут

Интернет-магазин с 24 000 каноническими URL планирует миграцию базы с 22:00 до 23:30, то есть на 90 минут, или 5 400 секунд. За неделю до даты команда дважды повторила операцию на копии: первый прогон занял 104 минуты, после оптимизации — 68. Окно оставили 90 минут, а откат должен начаться, если контрольная точка не пройдена к 70-й минуте.

Для внешней проверки подготовили 120 адресов: 20 категорий, 60 товаров, 20 статей, 10 API-запросов и 10 служебных ресурсов. Сумма: 20 + 60 + 20 + 10 + 10 = 120. В режиме обслуживания 116 запросов должны возвращать 503; четыре исключения — robots.txt, Sitemap, независимая статус-страница и внутренний файл заглушки — остаются доступными согласно конфигурации.

В 22:00 edge включил статическую страницу и Retry-After: 5400. Через три внешние точки выполнили весь набор: 3 × 120 = 360 запросов. Получили 348 ожидаемых 503 и 12 ожидаемых 200, потому что в каждой точке было четыре исключения: 3 × 4 = 12. Ни один бизнес-URL не ответил 200, 404 или редиректом.

Миграция завершилась за 74 минуты. После внутреннего healthcheck режим выключили в 23:18, то есть фактическая недоступность составила 78 минут. Кеш заглушки очистили, затем 116 бизнес-URL проверили в трёх точках: 116 × 3 = 348 ответов. Все вернулись к ожидаемым 200 или ранее существовавшим адресным редиректам; остаточных 503 не было.

Как вернуть сайт и проконтролировать восстановление

Не выключайте 503 только потому, что процесс миграции завершился. Сначала внутренне проверьте соединение с базой, чтение и запись, авторизацию, ключевые API, очереди и кеш. Затем откройте небольшой объём трафика или одну точку, выполните smoke-тест и только после этого снимайте режим полностью. Если проверка не пройдена, исправляйте или откатывайтесь в рамках заранее заданного времени.

После открытия запросите главную и представители всех шаблонов из внешней сети. Проверьте не только 200, но и содержание, canonical, robots meta, ссылки и формы. Убедитесь, что Retry-After исчез, CDN не хранит заглушку, robots.txt отвечает 200, а старые адресные редиректы сохранились. Если используется CDN, особенности кеша стоит сверить с материалом о CDN и правилами Cache-Control.

Следующие сутки наблюдайте 5xx, время ответа, обход роботов и бизнес-операции. В Яндекс Вебмастере коды видны в статистике обхода и мониторинге важных страниц; в Search Console — в статистике сканирования и индексировании. Не паникуйте из-за единичной записи, сделанной роботом во время окна: важно, что сайт быстро вернулся и снова стабильно отвечает.

Если после работ трафик меняется, расследуйте дату, страницы, запросы и каналы, а не приписывайте всё одному 503. Краткий корректный ответ снижает риск неверной обработки, но не является гарантией позиции. Методика расследования изложена в статье о падении трафика. В журнале инцидента сохраните время, фактические коды, Retry-After, длительность, ошибки и улучшения следующей процедуры.

Главный вывод

Для коротких технических работ действующий URL должен вернуть 503 Service Unavailable и, по возможности, реалистичный Retry-After. Статичная лёгкая страница объясняет ситуацию человеку, а код сообщает временность клиентам и роботам. Нельзя заменять его одинаковой заглушкой с 200, кодами 404/410, noindex или массовым редиректом: эти сигналы описывают другие состояния. При этом 503 не является бессрочной защитой — окно планируют в часах, robots.txt оставляют доступным, ответы проверяют из внешней сети, а после восстановления контролируют кеш, 5xx и обход. Безопасность создаёт не один заголовок, а короткий, отрепетированный и измеримый процесс.