Сайт на техническом обслуживании - ситуация, с которой сталкивается почти любой проект: обновление CMS, перенос на новый хостинг, замена платёжного модуля или крупная переверстка. Вопрос не в том, ставить заглушку или нет, а в том, как сделать это без потери позиций в Google и Яндексе. За практику с WordPress-магазинами и сайтами на Tilda я видел оба сценария: аккуратные три часа простоя без единой просевшей страницы и случай, когда криво настроенная заглушка выбросила карточки товаров из индекса почти на месяц.
По теме статьи
Готовое решение
AI-чатбот для сайта на Claude - отвечает как ваш менеджер, работает 24/7
Подключу к вашему сайту чат-бота на Claude API. Бот отвечает на вопросы клиентов голосом вашего бренда, знает каталог и условия доставки, забирает лиды в CRM или Telegram.
от25 000 ₽
Техподдержка
Чтобы сайт работал без сбоев
Обновления, доработки, мониторинг, резервные копии. WordPress, Tilda, самопис — всё поддерживаю. Пакет часов в месяц.
от15 000 ₽/мес
Когда действительно нужно включать заглушку на сайте
Не любая правка требует отдельной страницы обслуживания. Мелкое обновление плагина, правку текста в футере или замену картинки я делаю в фоне, без остановки сайта: посетитель в худшем случае увидит на секунду битую вёрстку при обновлении кеша.
Заглушка нужна, когда работа реально меняет структуру данных или ломает часть функционала на время: перенос базы на новый сервер, смена темы WordPress с другой структурой шаблонов, подключение нового способа оплаты вроде Т‑Банк эквайринга в WooCommerce, замена модуля расчёта зон доставки СДЭК, крупный редизайн на Tilda с полной пересборкой страниц. В таких случаях сайт какое-то время физически не может отдавать корректные страницы, и честнее показать это явно, чем оставлять пользователя перед ошибкой 500 или наполовину работающей формой заказа.
Такие работы обычно идут пакетом: перенос данных, проверка интеграций, тестовые заказы. Если объём большой, такие работы я оформляю отдельным проектом по технической доработке сайта, а не разовой правкой на скорую руку - так проще держать окно простоя под контролем и заранее прописать план отката.
Чем опасна неправильная страница технического обслуживания для SEO
Проблема не в самом факте недоступности, а в том, что именно получает поисковый робот в момент обхода. Если сервер в ответ на любой запрос отдаёт статус 200 OK с текстом «сайт на техническом обслуживании», Google и Яндекс воспринимают эту страницу как настоящий контент. При повторном обходе робот видит, что весь сайт внезапно превратился в одну страницу с двумя предложениями текста, и начинает вытеснять из индекса прежние URL.
На практике я разбирал магазин на WooCommerce, где разработчик поставил плагин-заглушку без проверки статуса ответа: тот отдавал 200 на всех адресах, включая карточки товаров. Работы заняли двое суток из-за проблем с миграцией, и за это время часть карточек вылетела из индекса Google. Восстановление позиций заняло около трёх недель после возврата сайта в рабочее состояние, хотя контент не менялся ни на секунду.
Второй частый промах - редирект всех адресов на главную страницу на время работ. Формально сайт отвечает, но с точки зрения SEO это выглядит как исчезновение сотен уникальных страниц и появление вместо них одной и той же главной, что тоже бьёт по видимости в поиске.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Код 503 и заголовок Retry-After: как правильно закрыть сайт на время работ
Правильный вариант - отвечать статусом 503 Service Unavailable на все запросы и добавлять заголовок Retry-After с примерным временем восстановления в секундах или конкретной датой. Для поисковика это однозначный сигнал: страница недоступна временно, старые адреса и их место в индексе трогать не нужно, нужно просто зайти попозже.
| Сценарий | Что видит поисковый робот | Риск для позиций |
|---|---|---|
| 503 + Retry-After | Временная недоступность, старый контент остаётся в индексе | Минимальный при простое до 1-2 суток |
| Заглушка с кодом 200 | Новая страница как будто заменила собой весь сайт | Высокий: вытеснение страниц из индекса за несколько дней |
| 301 редирект всех адресов на главную | Сотни уникальных URL пропали, остался один | Высокий: потеря видимости почти по всем запросам, кроме брендовых |
На уровне сервера это обычно решается проверкой файла-флага и отдельным заголовком:
if (-f $document_root/maintenance.flag) {
return 503;
}
add_header Retry-After 3600 always;
Значение Retry-After в секундах - это ориентир для робота, не жёсткое обещание. Если работы затянулись, лучше обновить файл и заголовок, а не оставлять таймер, который давно прошёл.
Как включить режим обслуживания на WordPress, Tilda и кастомном сайте
| Платформа | Есть готовый механизм 503 | Как обычно решаю задачу |
|---|---|---|
| WordPress | Да, через плагины вроде WP Maintenance Mode или SeedProd | Проверяю через заголовки ответа, что сервер действительно отдаёт 503, а не 200 под красивой вёрсткой |
| Tilda | Нет, конструктор не отдаёт кастомные HTTP-статусы | Готовлю новую версию страниц заранее в черновике и переключаю публикацию в окно с минимальным трафиком, обычно ночью |
| Сайт на своём коде (Laravel, Next.js и подобные) | Нет из коробки, настраивается на уровне сервера или мидлвара | Добавляю проверку переменной окружения или файла-флага, которая переключает ответ приложения на 503 |
Проверить реальный статус проще всего одной командой:
curl -I https://example.ruЕсли в ответе HTTP/1.1 200 OK вместо 503 Service Unavailable, заглушка настроена неправильно, что бы ни было написано у неё на экране.
Сколько может простаивать сайт на техобслуживании без потери позиций
Однозначного лимита в часах никто не даст, но по моим наблюдениям в проектах на WordPress и Tilda процесс выглядит так. Простой в пределах нескольких часов с корректным 503 поисковики обычно пропускают без последствий: робот приходит, видит временную недоступность, откладывает переобход, ничего не трогает в индексе. Сутки-двое тоже, как правило, проходят спокойно, если заголовок Retry-After реалистичный, а не «через час», который на деле растягивается на неделю.
Дальше начинаются риски. Если Googlebot несколько обходов подряд получает 503, он снижает частоту сканирования сайта. У Яндекса похожая логика через Яндекс.Вебмастер: в диагностике сайта появляется предупреждение о повторяющихся ошибках сервера. В таких случаях я смотрю отчёт о покрытии в Google Search Console до работ и через неделю после, чтобы убедиться, что число проиндексированных страниц не просело.
Если работы объективно требуют больше двух-трёх дней, например миграция крупного каталога с одновременной заменой движка, лучше переносить сайт поэтапно или на поддомене с последующим переключением DNS, а не держать основной домен под сплошным 503 всё это время.
Что написать на странице обслуживания, чтобы не терять заявки
Текст на странице обслуживания решает не только вопрос вежливости, он влияет на то, сколько посетителей вернётся после запуска. Пишу коротко: что происходит, ориентировочное время («вернёмся к 14:00» лучше абстрактного «скоро») и рабочий канал связи, не завязанный на сам сайт, - телефон, Telegram, WhatsApp. Для интернет-магазина на паузе имеет смысл прямо написать, что заказы временно не принимаются, а не оставлять форму, которая молча теряет заявки.
Частая ошибка - выключать сайт целиком, когда на самом деле сломан только один модуль, например виджет доставки СДЭК или приём платежей через Т‑Банк. В таких случаях правильнее держать сайт рабочим, а неисправный узел временно скрыть или заменить заглушкой только в нём: клиент может посмотреть каталог и оставить заявку, даже если онлайн-оплата на паузе.
Дублировать meta robots noindex поверх 503 не обязательно: статус уже говорит поисковику всё, что нужно, а лишний noindex иногда только путает индексацию, если работы закончились раньше, чем через сайт прошёл повторный обход поисковика.
Частые вопросы
Нужен ли meta robots noindex на странице технического обслуживания?
Обычно не нужен. Статус 503 уже сообщает поисковику, что перед ним временная страница, а не новый контент вместо старого. Дополнительный noindex скорее мешает: если работы завершатся быстрее, чем робот успеет обработать тег, есть шанс, что страница выпадет из индекса дольше, чем реально длился простой.
Что делать, если заглушка случайно провисела несколько дней с кодом 200?
Сначала исправить статус на 503 или полностью вернуть сайт в рабочее состояние. Дальше в Google Search Console через инструмент проверки URL отправить на переобход ключевые посадочные страницы, а не ждать, пока робот дойдёт до них сам. Восстановление обычно занимает от нескольких дней до трёх недель в зависимости от того, сколько страниц успело вылететь из индекса.
Можно ли сделать корректную заглушку с кодом 503 на Tilda?
Напрямую нет: конструктор не даёт управлять HTTP-статусом ответа. На практике для Tilda-проектов я готовлю обновлённую версию страниц в черновике и переключаю публикацию в окно минимального трафика, обычно ночью, чтобы сократить время, когда старая и новая версия расходятся. Если правки критичные и связаны с интеграциями вроде эквайринга или зон доставки, такие задачи логичнее решать точечным скриптом, чем полной пересборкой сайта.
Сколько может стоить настройка корректной страницы техобслуживания?
Для Tilda обычно хватает точечного скрипта и донастройки публикации, такая задача укладывается в стоимость кастомного скрипта для Tilda от 3 000 ₽. Для WordPress или сайта на своём коде корректная заглушка с 503 и Retry-After чаще идёт отдельной задачей в текущей технической поддержке, у меня она от 15 000 ₽ в месяц.