Как правильно закрыть сайт WordPress на обслуживание, чтобы не потерять позиции в поиске
Владелец сайта решает обновить тему, перенести сайт на новый хостинг или разобраться с ошибкой после взлома. Первое, что приходит в голову — поставить заглушку с надписью «сайт на технических работах» и спокойно заняться делом. Но заглушка сама по себе ничего не защищает.
Если заглушка настроена неправильно и остается на сайте достаточно долго, поисковые системы могут начать воспринимать временную страницу как новое содержимое сайта, снизить частоту обхода или со временем исключить отдельные адреса из поиска.
Заглушка — это только внешняя часть режима обслуживания. Гораздо важнее то, что происходит «под капотом»: какой код ответа отдает сервер, видят ли страницы поисковые роботы, и как долго сайт находится в таком состоянии. Именно этим техническим деталям посвящена эта статья.
Что значит «закрыть сайт на обслуживание»
Закрытие сайта на обслуживание — это временное ограничение доступа к публичной части ресурса на период, пока с ним выполняются работы, которые могут временно нарушить его нормальную работу. Обычно это связано с такими задачами:
- обновление WordPress, темы или плагинов;
- перенос сайта на другой сервер или домен;
- изменение структуры разделов;
- исправление ошибок, из-за которых сайт работает нестабильно;
- восстановление после взлома;
- операции с базой данных, где риск потери или повреждения данных особенно велик;
- крупные изменения дизайна или функциональности, которые нельзя без риска вносить на живом сайте.
Здесь важно различать два принципиально разных случая. Первый — короткий технический перерыв на несколько минут или пару часов, например обновление плагинов или установка новой версии WordPress. Второй — длительное закрытие на дни или недели, когда идет масштабная переработка сайта или восстановление после серьезной проблемы. Требования к этим двум ситуациям разные: то, что допустимо на пятнадцать минут, может быть рискованным на две недели, и наоборот — то, что выглядит избыточным для короткого обновления, становится обязательным при долгой заморозке сайта.
Когда сайт действительно нужно закрывать
Закрывать сайт стоит тогда, когда работы могут привести к тому, что посетитель увидит незавершенную страницу, столкнется с ошибкой, введет данные в форму, которая в этот момент не обрабатывается, или когда есть риск повреждения данных при одновременном обращении к базе.
Например, при обновлении крупного плагина, который меняет структуру таблиц в базе данных, лучше временно ограничить доступ — если пользователь в этот момент оформит заказ, данные могут потеряться или записаться некорректно. То же самое касается миграции сайта на новый сервер: пока идет перенос файлов и базы, старая и новая версии могут временно рассинхронизироваться, и посетитель рискует увидеть смесь старого и нового содержимого.
Важно: Восстановление после взлома — отдельный случай, где закрытие сайта почти всегда оправдано. Публичную часть сайта лучше временно закрыть, отдавая посетителям и поисковым роботам корректный код 503, пока не будет проверено, что вредоносный код полностью удален.
При этом далеко не каждое обновление требует полного закрытия. Небольшое обновление плагина, которое не затрагивает базу данных и не меняет критичную логику сайта, чаще всего можно выполнить без остановки работы — просто в период минимальной посещаемости и с готовой резервной копией на случай проблем.
Когда закрывать весь сайт не нужно
В своей работе я стараюсь придерживаться правила: закрытие всего сайта — это крайняя мера, а не привычное действие перед любым обновлением. Часто есть более щадящие варианты.
Если готовится серьезное изменение — новая версия дизайна, смена конструктора форм, миграция на другую CMS — разумнее сначала все проверить на тестовой копии сайта, а на боевой версии переключиться только тогда, когда все точно работает. Это снимает необходимость закрывать сайт вообще: посетители продолжают видеть рабочую версию, пока за кулисами готовится новая.
Если проблема касается только одного раздела, например каталога товаров или личного кабинета, есть смысл ограничить доступ именно к этой части, оставив остальной сайт открытым. Это можно сделать через правила в файле конфигурации сервера или через настройки плагина, если он позволяет закрывать отдельные разделы.
Работы, которые не связаны с изменением базы данных и не мешают показу страниц, часто можно провести незаметно для посетителей в период, когда трафика меньше всего — обычно это ночные часы по времени основной аудитории сайта.
Наконец, крупные обновления удобно проводить поэтапно: сначала протестировать один компонент, затем следующий, вместо того чтобы одним рывком менять всё и держать сайт закрытым несколько дней. Такой подход снижает риск долгого простоя и упрощает откат, если что-то пойдет не так.
Почему обычная заглушка может навредить SEO
Проблема не в самой заглушке, а в том, что она обычно отдает неправильный технический ответ серверу поисковой системы. Разберемся, что именно может пойти не так.
Если заглушка выводится на всех адресах сайта, но при этом сервер отвечает кодом 200 — тем же кодом, что и обычная рабочая страница — поисковая система формально видит, что страница существует и доступна, только теперь на ней вместо прежнего содержимого текст «сайт на обслуживании». Для робота это выглядит как замена содержимого: если такая ситуация сохраняется достаточно долго, есть риск, что старое содержимое начнет вытесняться из индекса, а сама заглушка займет его место в результатах поиска. Это не происходит мгновенно, но при длительном закрытии сайта такая вероятность растет.
Важно: Другая крайность — сайт вместо заглушки массово отдает код 404, «страница не найдена». Для поисковой системы это сигнал, что страницы больше не существует. Если робот регулярно обходит сайт и видит 404 на месте прежних URL, со временем эти адреса могут быть исключены из индекса.
Код 500, «внутренняя ошибка сервера», тоже не подходит. Он говорит роботу, что с сайтом что-то серьезно не так на уровне инфраструктуры, и при частом повторении такого ответа поисковая система может снизить частоту обхода сайта, посчитав его технически нестабильным.
Отдельно стоит сказать о robots.txt и метатеге noindex. Иногда администраторы сайта, желая перестраховаться, закрывают сайт от индексации через robots.txt или ставят noindex на все страницы на время работ. Логика понятна — «пусть робот вообще не трогает сайт, пока идут работы». Но на практике это может создать больше проблем, чем решить: полное закрытие через robots.txt мешает роботу увидеть даже корректный код 503 и понять, что происходит временная техническая пауза, а массовый noindex, если его забыть снять, приводит к тому, что страницы начинают выпадать из индекса уже после завершения работ.
Обратите внимание: Здесь важно не пугаться раньше времени. Риски, о которых идет речь, зависят от продолжительности закрытия сайта, от того, как часто поисковый робот вообще обходит конкретный ресурс, и от того, насколько технически грамотно реализовано закрытие. Технический перерыв на двадцать минут с правильным кодом ответа почти никогда не создает заметных проблем. Риски начинают накапливаться, когда сайт остается закрытым надолго и при этом отдает неправильный статус.
Какой HTTP-статус должен отдавать сайт
Правильный технический ответ во время обслуживания — код 503 Service Unavailable. Он сообщает поисковой системе и браузеру одну простую вещь: сайт временно недоступен, но это не значит, что страница исчезла или её содержимое изменилось навсегда. Робот воспринимает такую ситуацию как техническую паузу и, как правило, возвращается позже, чтобы проверить сайт снова, не спеша убирать прежние страницы из индекса.
Вместе с кодом 503 желательно передавать заголовок Retry-After. Простыми словами, это подсказка роботу и браузеру, через какое примерное время имеет смысл заглянуть на сайт снова — например, «Retry-After: 3600» означает «загляните через час». Это не жесткое обещание и не гарантия, что сайт откроется ровно в указанный момент, а скорее ориентир, который помогает поисковой системе не тратить ресурсы на слишком частые проверки закрытого сайта.
Важный момент — код 503 предназначен для кратковременной технической недоступности. Если обслуживание затягивается, стоит заранее продумать другой сценарий, а не оставлять сайт в режиме 503 на длительное время. Если сайт закрыт неделями, само по себе наличие правильного кода уже не решает всех вопросов — об этом отдельно ниже, в разделе про длительное закрытие.
| HTTP-статус | Что означает | Подходит ли для обслуживания |
|---|---|---|
| 200 | Страница существует и доступна как обычно | ❌ Нет — заглушка с кодом 200 может восприниматься как замена содержимого |
| 302 | Временное перенаправление | ❌ Нет — обычно не требуется, правильнее отдавать 503 |
| 404 | Страница не найдена | ❌ Нет — сигнализирует об удалении страницы |
| 500 | Внутренняя ошибка сервера | ❌ Нет — выглядит как техническая неисправность |
| 503 | Сервис временно недоступен | ✅ Да — корректно сообщает о временном характере недоступности |
Важное уточнение по строке с 302: показать посетителю страницу обслуживания можно и без изменения адреса в браузере. Сервер способен обработать запрошенный URL напрямую и вернуть на нем код 503 с содержимым страницы обслуживания — адресная строка при этом останется прежней, а не переключится на отдельный служебный URL. Именно так и настраиваются примеры для Apache и Nginx дальше в статье.
Как должна выглядеть правильная страница обслуживания
Техническая часть решает вопрос с поисковыми системами, но у сайта остаются живые посетители, и им тоже важно понятно объяснить, что происходит. Хорошая страница обслуживания не должна пугать пользователя и не должна выглядеть как ошибка.
На странице стоит разместить понятное сообщение без лишних технических подробностей — посетителю не нужно знать, что вы обновляете плагин кэширования или меняете структуру таблицы заказов, ему достаточно знать, что сайт временно недоступен и скоро заработает снова. Если срок восстановления действительно известен и вы уверены, что уложитесь в него, его можно указать. Если уверенности нет — лучше не называть точное время: ничего хорошего в обещании, которое не будет выполнено, нет ни для доверия посетителей, ни для собственного спокойствия.
Практика: Полезно оставить контакты — телефон, почту или ссылку на мессенджер, — чтобы человек, которому срочно нужно решить вопрос, мог связаться напрямую, а не просто закрыть вкладку. Если у сайта активны социальные сети, где публикуются новости, можно дать на них ссылку.
Пример простого и спокойного текста для такой страницы:
«На сайте проводятся технические работы. Мы скоро вернемся. По срочным вопросам можно связаться по телефону или в мессенджере — контакты ниже».
Дизайн такой страницы не обязан быть сложным, но должен быть выдержан в общем стиле сайта и не создавать впечатления, что что-то сломалось. Разница между «мы проводим плановые работы» и «на сайте произошла ошибка» считывается пользователем моментально, и от этого зависит, вернется ли он позже или уйдет к конкурентам.
Как сохранить доступ для администратора
Пока сайт закрыт для обычных посетителей, специалисту, который выполняет работы, доступ нужен обязательно. Есть несколько вариантов, и у каждого свои плюсы и ограничения.
Доступ для авторизованных администраторов
Пользователь, вошедший в систему под своей учетной записью, видит рабочую версию сайта, а все остальные — страницу обслуживания.
- ✓ Не требует доп. настроек
- ✗ Требует, чтобы вход в панель был доступен
Ограничение по IP-адресу
Сайт открыт только для конкретных адресов, с которых работает специалист.
- ✓ Надежный способ
- ✗ Неудобно при динамическом IP
- ✗ Сложно при работе нескольких специалистов
Отдельный служебный адрес
Дополнительный поддомен или временный URL для доступа к рабочей версии сайта.
- ✓ Удобно для проверок
- ✗ Требует, чтобы адрес не индексировался
Тестовая копия сайта
Работа на отдельной копии, не трогая боевой сайт.
- ✓ Самый безопасный вариант
- ✗ Требует подготовки копии
Временный пароль, закрывающий доступ ко всему сайту через базовую HTTP-аутентификацию, — простое решение для коротких работ, но неудобно тем, что пароль нужно сообщать всем, кому доступ действительно нужен, включая заказчика, если он хочет посмотреть промежуточный результат.
Как закрыть сайт WordPress на обслуживание
Рассмотрим конкретные технические способы — от встроенных возможностей WordPress до настроек на уровне сервера.
Встроенный режим WordPress
Сам WordPress включает режим обслуживания автоматически на время обновления ядра, темы или плагинов. В этот момент в корневой папке сайта создается файл .maintenance, внутри которого записывается время начала обновления. Пока режим активен, посетители видят стандартную страницу с корректным кодом 503 и заголовком Retry-After — эту часть WordPress берет на себя.
Обратите внимание: WordPress не просто проверяет наличие файла .maintenance — он смотрит на отметку времени внутри него. Если с момента создания файла прошло больше десяти минут, ядро WordPress перестает считать режим обслуживания активным и показывает сайт как обычно, даже если файл физически остался на месте.
Если требуется удалить файл .maintenance вручную — например, чтобы сразу вернуть сайт в рабочий режим, не дожидаясь истечения десяти минут, — перед этим стоит убедиться, что обновление действительно закончилось и файлы сайта в порядке.
Плагин режима обслуживания
Плагины — самый доступный способ для тех, кто не хочет вручную работать с файлами сайта или настройками сервера. У них есть очевидные плюсы: включение занимает пару минут, дизайн страницы можно настроить без знания кода, а доступ для администратора обычно сохраняется автоматически.
Важно: Не каждый плагин действительно отдает корректный код 503 — некоторые показывают красиво оформленную заглушку, но сервер при этом продолжает отвечать кодом 200, что возвращает нас к проблеме, описанной выше.
Перед использованием любого плагина стоит обязательно проверить, какой код ответа сайт отдает на самом деле, а не полагаться на внешний вид заглушки.
Apache Через файл .htaccess
Для серверов на Apache есть способ настроить режим обслуживания напрямую через файл .htaccess, без установки дополнительных плагинов. Логика такая: сервер отдает код 503 непосредственно на запрошенном адресе, кроме случаев, когда запрос идет с IP специалиста, либо когда запрашивается сама страница обслуживания или её ресурсы.
RewriteEngine On
# Разрешить доступ с IP специалиста
RewriteCond %{REMOTE_ADDR} !^123\.123\.123\.123$
# Не блокировать сам файл страницы обслуживания
RewriteCond %{REQUEST_URI} !^/maintenance\.html$
# При необходимости разрешить ресурсы страницы обслуживания
RewriteCond %{REQUEST_URI} !^/maintenance-assets/
RewriteRule ^ - [R=503,L]
ErrorDocument 503 /maintenance.html
Header always set Retry-After "3600"
Здесь 123.123.123.123 нужно заменить на свой реальный IP-адрес. Правило RewriteRule ^ - [R=503,L] не выполняет внешний переход на другой адрес — оно оставляет запрошенный URL без изменений и лишь помечает ответ кодом 503, после чего Apache подставляет в качестве содержимого документ, указанный в ErrorDocument 503. Адресная строка в браузере посетителя при этом не меняется.
Важно: Перед внесением правила обязательно сделайте резервную копию текущего файла .htaccess — при ошибке в синтаксисе сайт может стать недоступен полностью, включая доступ для вас самих.
Nginx Через конфигурацию Nginx
На серверах с Nginx правила настраиваются иначе, поскольку файл .htaccess там не используется — конфигурация задается в файлах, доступ к которым обычно есть только у администратора сервера или хостинг-провайдера.
Обратите внимание: Универсальной конфигурации для Nginx не существует. Правила режима обслуживания необходимо встраивать в уже существующий блок server с учетом того, как на конкретном сайте настроена маршрутизация PHP, обработка статических файлов и кэширование.
Поэтому для Nginx правильнее не искать типовой пример в интернете, а обратиться к администратору сервера или хостинг-провайдеру и подготовить конфигурацию под конкретный сайт.
PHP Через PHP или функционал темы
Технически можно добавить проверку прямо в файл functions.php темы, которая будет показывать заглушку и отдавать код 503 при выполнении определенных условий. Но добавлять такой временный код в рабочую тему я бы не рекомендовал без серьезной необходимости: при следующем обновлении темы изменения могут потеряться, а сам код, оставленный в файле дольше, чем планировалось, легко забыть и не убрать вовремя.
add_action('init', function() {
if (is_user_logged_in() && current_user_can('manage_options')) {
return;
}
http_response_code(503);
header('Retry-After: 3600');
echo 'На сайте ведутся технические работы. Мы скоро вернемся.';
exit;
});
Лучше делать это в дочерней теме, которая не затрагивается обновлениями родительской темы, или же рассмотреть решение на уровне сервера — оно надежнее и не зависит от того, что происходит внутри WordPress.
Как проверить, что режим обслуживания настроен правильно
После включения заглушки стоит потратить несколько минут на проверку — это избавит от неприятных сюрпризов.
Проверить реальный HTTP-код можно несколькими способами. В браузере это делается через инструменты разработчика — вкладку сетевых запросов, где видно, каким статусом ответил сервер на главный запрос страницы. Через терминал подойдет команда вроде curl -I адрес_сайта, которая покажет заголовки ответа, включая код статуса.
Кэширование страницы обслуживания
Отдельный момент, который легко упустить — это кэш. Если ответ 503 и содержимое страницы обслуживания попадут в кэш и надолго там задержатся, можно столкнуться с обратной ситуацией: работы давно закончены, а часть посетителей или даже поисковый робот все еще видят заглушку вместо рабочего сайта.
Обратите внимание: Проверять стоит все уровни, где может храниться кэш: кэш самого WordPress, серверный кэш на уровне хостинга, обратный прокси, если он используется, и CDN, если сайт через неё раздается.
Для самой страницы обслуживания разумно настроить запрет кэширования или минимальное время его хранения. После открытия сайта стоит проверить его не только в своем браузере, где кэш и cookie могут маскировать реальную картину, но и в режиме инкогнито или, что еще надежнее, через внешний запрос вроде curl -I, который не зависит от локального кэша браузера.
Длительное закрытие сайта — отдельный сценарий
Код 503 создавался для временной недоступности, и чем дольше сайт продолжает его отдавать, тем выше вероятность, что поисковая система снизит частоту обхода сайта, а со временем начнет исключать отдельные адреса из индекса. Жесткого срока, после которого это гарантированно произойдет, не существует — риск зависит от конкретного сайта.
Важно: Если бизнес приостанавливается на более долгий срок — например, сайт закрывается на несколько недель для капитальной переработки, — Google рекомендует не держать весь сайт на 503 все это время, а сделать доступной индексируемую главную страницу с кодом 200, на которой размещена актуальная информация для клиентов.
Это принципиально другой сценарий, и его не стоит путать с коротким техническим обслуживанием. Если речь идет о часах или паре дней — 503 полностью решает задачу. Если закрытие растягивается на недели, стоит заранее продумать вариант с индексируемой заглушкой-страницей вместо того, чтобы просто продлевать режим 503 на неопределенный срок.
Robots.txt во время обслуживания
Отдельно стоит сказать про сам файл /robots.txt. Его желательно оставлять доступным с обычным кодом 200 в течение всего периода обслуживания — это тот файл, который поисковый робот проверяет в первую очередь, и от его доступности зависит, как робот будет вести себя дальше.
Типичная ошибка: Не стоит закрывать сайт директивой Disallow: / в robots.txt — это не решает задачу режима обслуживания и создает ситуацию, когда робот вообще не может увидеть корректный код 503 на страницах сайта.
Поисковый робот должен иметь возможность в любой момент запросить страницы сайта и увидеть на них временный код 503 — именно это, а не блокировка через robots.txt, сообщает ему о характере паузы.
Типичные ошибки
За годы работы с сайтами на WordPress одни и те же ошибки при закрытии на обслуживание встречаются снова и снова.
⚠ Заглушка отдает код 200
Вместо 503 сервер отвечает 200, и поисковая система воспринимает заглушку как обычную страницу с новым содержимым.
⚠ Массовый редирект на страницу заглушки
Все страницы перенаправляются на одну служебную страницу вместо того, чтобы отдавать 503 на исходных адресах.
⚠ Некорректные коды (404 / 500)
Сайт отдает 404 или 500 вместо 503, что вводит поисковую систему в заблуждение.
⚠ Избыточная блокировка через robots.txt
Закрытие сайта через Disallow: / мешает роботу увидеть корректный код 503.
⚠ Забыли открыть сайт после работ
Код 503 остается висеть на сайте дни и недели после завершения всех работ.
⚠ Блокировка собственного доступа
Специалист по ошибке блокирует доступ сам себе, например задав IP-адрес с опечаткой.
Также встречается удаление файла .maintenance до того, как обновление точно завершилось, внесение изменений на рабочем сайте без резервной копии и отсутствие проверки форм и функциональных частей после открытия сайта.
Что делать после завершения обслуживания
Возвращение сайта в рабочий режим — это тоже отдельный этап, а не просто нажатие кнопки «выключить заглушку».
Что проверить перед открытием сайта
- Отключен сам режим обслуживания — удален файл, деактивирован плагин или убрано правило из конфигурации
- Очищен кэш самого сайта
- Сброшен серверный кэш, обратный прокси и CDN, чтобы посетители не видели старую заглушку
- Открыта главная страница и несколько внутренних
- Проверены формы обратной связи
- На сайтах с продажами — проверена корзина и процесс оплаты целиком
- Проверен вход в личный кабинет
- Проверена мобильная версия сайта
- Сайт снова отдает код 200 вместо 503
- Файл robots.txt не содержит правил, оставшихся с периода обслуживания
- Метатег noindex, если он использовался, снят со всех страниц
- Проверена актуальность карты сайта
- Проверены Яндекс Вебмастер и Google Search Console на наличие ошибок за время закрытия
Отправлять весь сайт на переобход после каждого короткого и технически корректного режима обслуживания обычно не требуется — если 503 был настроен правильно и держался недолго, поисковые системы возвращаются к обычному сканированию сами.
Как я закрываю сайты на обслуживание в своей работе
В своей работе я придерживаюсь четкой последовательности действий, которая помогает снизить риски при обслуживании сайта. Перед обновлениями, изменениями файлов, базы данных, структуры или функциональности я обязательно проверяю наличие свежей рабочей резервной копии — и важно, чтобы эта копия хранилась не только на том же сервере, где расположен сайт.
Там, где это возможно, я стараюсь переносить основную часть работы на тестовую копию сайта, чтобы боевая версия вообще не участвовала в экспериментах.
Если закрытие сайта все же необходимо, я держу его закрытым ровно столько, сколько реально нужно, а не «на всякий случай подольше». Для публичной части в этот период настраивается корректный код 503, а доступ для администратора сохраняется — обычно через авторизацию или ограничение по IP, в зависимости от того, как удобнее в конкретном проекте.
После завершения работ я не открываю сайт сразу, а сначала провожу техническую проверку: смотрю, как отображаются ключевые страницы, работают ли формы, корректно ли ведет себя адаптивная верстка на мобильных устройствах, очищен ли кэш и отдает ли сервер правильные HTTP-коды. Только после этой проверки сайт открывается для всех посетителей.
Итог
Итог
Правильно организованный режим обслуживания решает сразу несколько задач одновременно: защищает сайт во время технических работ, не мешает специалисту, который эти работы выполняет, понятно информирует посетителей о том, что происходит, не вводит в заблуждение поисковые системы неправильными кодами ответа, и обязательно отключается сразу после завершения всех работ.
Если сайту предстоит обновление, перенос, восстановление или серьезная доработка, разумнее заранее продумать порядок закрытия, подготовить резервную копию и спланировать проверку после завершения работ. Это не превращает простое обновление в сложный проект, но заметно снижает риск потери данных, ошибок и проблем с индексацией — тех самых неприятностей, которые потом занимают куда больше времени, чем сама техническая пауза.
Частые вопросы
Можно ли закрыть сайт через robots.txt?
Технически можно, но для режима обслуживания это неверный способ. Полная блокировка через Disallow: / мешает поисковому роботу увидеть корректный код 503 на страницах сайта, а сам файл robots.txt лучше в течение всего обслуживания оставлять доступным с кодом 200.
Как долго можно держать сайт в режиме обслуживания?
Однозначного срока не существует, но чем короче период закрытия, тем меньше рисков. Код 503 предназначен для кратковременной технической паузы. Если обслуживание затягивается, лучше не держать весь сайт на 503 все это время, а сделать доступной индексируемую страницу с актуальной информацией и кодом 200.
Как проверить, что сайт отдает код 503?
Проще всего — через инструменты разработчика в браузере, во вкладке с сетевыми запросами, где отображается статус ответа сервера. Также подойдет команда curl -I адрес_сайта в терминале или любой онлайн-сервис проверки HTTP-статуса по адресу страницы.
Что делать, если WordPress застрял в режиме обслуживания?
Файл .maintenance в корне сайта содержит отметку времени, и если с момента её создания прошло больше десяти минут, WordPress сам перестает считать режим обслуживания активным. Если сайт все же не открывается, стоит проверить, действительно ли обновление завершилось, а затем удалить файл вручную через доступ к файлам сайта.
Нужно ли закрывать сайт при обновлении плагинов?
Не всегда. Небольшие обновления, которые не затрагивают структуру базы данных, часто можно проводить без остановки работы, особенно в период низкой посещаемости и при наличии свежей резервной копии.
Влияет ли закрытие сайта на позиции в поиске?
Само по себе кратковременное и технически правильно оформленное закрытие сайта редко приводит к заметной потере позиций. Риски растут при долгом закрытии, неправильных HTTP-кодах, блокировке через robots.txt или избыточных ограничениях вроде тега noindex на всех страницах.
📋 Чек-лист владельца сайта
- Сделана резервная копия сайта, и она хранится не только на самом сервере
- Определено, действительно ли нужно закрывать весь сайт, а не только его часть
- Настроен корректный код ответа 503 для публичной части
- Добавлен заголовок Retry-After — только к ответам 503, а не ко всем ответам сайта
- Страница обслуживания содержит понятный текст и контакты
- Сохранен доступ к сайту для администратора
- Файл robots.txt остается доступным с кодом 200 и не блокирует сайт директивой Disallow
- Тег noindex не проставлен массово на все страницы
- После включения заглушки проверены HTTP-код, мобильная версия и работа админ-доступа
- Проверено, что страница обслуживания и её ответ не задерживаются надолго в кэше или CDN
- Для длительного закрытия рассмотрена индексируемая страница-заглушка с кодом 200 вместо многодневного 503
- После завершения работ режим обслуживания отключен, кэш и CDN очищены
- Проверены формы, оплата и личный кабинет после открытия сайта
- Проверены robots.txt, метатеги и доступность сайта в Яндекс Вебмастере и Google Search Console
- Проверен HTTP-код нескольких внутренних страниц, а не только главной
Если понадобится помощь с обслуживанием или восстановлением сайта — напишите.