-
Доступ
Авторизация тестового окружения
-
Настройки
Домены, noindex и интеграции
-
Релиз
Проверка ответа снаружи
-
Приёмка
Основной открыт, стенд защищён
Тестовый сайт лучше закрывать авторизацией или сетевым доступом. Для публичной технической копии дополнительно используют noindex. Один robots.txt не скрывает данные и не гарантирует исчезновение URL из поиска. Настройки стенда и основного сайта должны храниться раздельно, чтобы при релизе вместе с кодом не перенести запрет индексации на рабочий домен.
Сначала определите, кому нужен стенд
Стенд для разработчиков и копия для демонстрации заказчику решают разные задачи. Первому часто достаточно VPN или доступа с разрешённых адресов. Второму нужна удобная авторизация, работающая на телефоне заказчика и у проверяющих сотрудников. Публичная ссылка без пароля удобнее на минуту, но создаёт постоянный риск утечки черновиков, цен и тестовых контактов.
До настройки защиты составьте перечень точек входа: домен стенда, поддомены, временный адрес хостинга, API, загрузки, изображения и файлы экспорта. Закрытая главная страница не означает, что закрыт каталог документов. Ссылку на PDF или выгрузку нужно проверить отдельно, без сохранённой сессии администратора. Секретные данные не должны становиться доступными по прямому адресу.
Чем отличаются авторизация, noindex и robots.txt
Авторизация ограничивает получение содержимого. Директива noindex просит поисковик не включать доступный документ в поиск. Robots.txt управляет обходом. У этих средств разные функции, поэтому их нельзя оценивать только по наличию строки Disallow в файле. Защиту информации начинают с доступа, а поисковые настройки проверяют уже после этого.
Чтобы прочитать noindex на публичной странице, робот должен получить её ответ. Если одновременно запретить обход этого URL, он может не увидеть директиву. Когда копия уже известна поиску, выбирайте порядок действий с учётом этого ограничения. Если там оказались закрытые сведения, приоритет — немедленно ограничить доступ, а не оставлять их публичными ради следующего обхода.
| Задача | Подход |
|---|---|
| Закрытая разработка | Авторизация или ограничение сети |
| Публичное демо без секретов | Noindex и контроль доступных разделов |
| Запрет обхода отдельного технического пути | Правила robots.txt с проверкой URL |
| Удаление уже найденной копии | Постоянная причина исключения и инструменты кабинета |
Разделите конфигурацию окружений
Рабочий домен, тестовый домен, режим индексации и адреса интеграций задают настройками окружения. Их не стоит переносить через общую резервную копию вместе со всеми значениями базы. После восстановления копии проверьте домен в canonical, sitemap, письмах и ссылках. Ошибка здесь может отправить посетителя на стенд даже при правильно работающей главной странице.
Учебный пример: production работает на shop.example, а стенд — на staging.shop.example. В обоих окружениях установлен один код, но у стенда включена авторизация, отключены реальные платежи и внешние уведомления. После развёртывания автоматическая проверка запрашивает оба домена. Для основного ожидается доступная страница без noindex, для стенда — отказ без учётных данных. Одной проверки переменной DEBUG недостаточно.
Не используйте настоящий список клиентов в тестах, если можно обойтись обезличенными данными. Копия базы может содержать телефоны, переписку, токены и пароли интеграций. Ограничение индексации не отменяет правил хранения этих данных. Перед передачей стенда подрядчику отдельно согласуйте доступы, срок работы и порядок удаления копии.
Проверьте релиз снаружи
Тест выполняют из новой сессии без служебных cookie. Откройте главную, услугу, категорию и карточку товара. Посмотрите HTTP-заголовок X-Robots-Tag и meta robots в исходном HTML. Проверка только визуального вида ненадёжна: страница может выглядеть полностью готовой, но содержать noindex, оставшийся от тестирования.
Затем проверьте robots.txt для конкретного URL. Нужно видеть, какая группа и какое правило сработали, а не просто убедиться, что файл открывается. Если есть CDN или серверный кеш, сравните ответ после обновления кеша. Настройки, добавленные на уровне прокси, могут не отображаться в панели CMS.
В проверке sitemap убедитесь, что карта основного сайта не содержит адресов стенда. Отдельно проверьте ссылки в товарном фиде и системных письмах. Они часто формируются из другой настройки базового домена, чем обычные страницы. Исправление HTML-шаблона не обязательно исправит эти каналы.
Если тестовая копия уже появилась в поиске
Сначала выясните масштаб: какие адреса доступны, есть ли конфиденциальные документы, продолжает ли сайт отдавать содержимое. Для чувствительных данных закройте доступ и оцените последствия публикации. Для обычных дублирующих страниц выберите постоянный способ исключения. Временное скрытие через кабинет ускоряет уборку выдачи, но не заменяет исправление доступности самого источника.
Не перенаправляйте все адреса стенда на главную основного сайта автоматически. Если нужна миграция публичного проекта, сопоставляют конкретные страницы. Если это техническая копия, задача обычно состоит в закрытии окружения. Смешение этих сценариев создаёт лишние редиректы и затрудняет последующие проверки.
Что включить в чек-лист приёмки
- Основной домен открывается без служебной авторизации.
- На публичных посадочных нет случайного noindex.
- Canonical, sitemap и внутренние ссылки используют рабочий домен.
- Стенд закрыт без служебного доступа, включая прямые ссылки на файлы.
- Тестовые оплаты, CRM и письма не затрагивают настоящих клиентов.
- После отката настройки каждого окружения остаются на своём месте.
Результат фиксируют не фразой «всё проверено», а адресами и наблюдаемыми ответами. Для каждого теста достаточно указать окружение, ожидаемое состояние, фактический статус и время проверки. Такой документ помогает принять следующий релиз и быстро найти отличие, если после обновления исчезнут показы или перестанут работать формы.
Проверка индексирования основного сайта продолжается после релиза. Сохраните исходный список важных страниц, затем отслеживайте доступность и сообщения поисковых кабинетов. Не меняйте одновременно всю структуру и способ закрытия стенда без необходимости: при ошибке будет сложнее определить, какая правка её вызвала. Если развёртывание повторяется вручную, перенесите эти проверки в процедуру публикации.
Для постоянной команды полезно назначить владельца каждого окружения. Он отвечает за срок существования стенда, список людей с доступом, смену временных паролей и завершение работы. Забытый демонстрационный домен через несколько месяцев становится такой же проблемой, как незакрытая копия перед запуском. Эти условия стоит включить в регламент технической поддержки, а не оставлять устной договорённостью.
