Dev-сервер

Dev-сервер – копия рабочего окружения сайта на отдельном адресе: обычно технический поддомен вида dev.site.ru или отдельная площадка хостинга. У него своя база данных, свои файлы и свой набор данных для проверок. Посетитель туда не попадает: доступ закрывают паролем на уровне сервера или ограничением по списку адресов.

Копия – это не только файлы сайта. Переносятся ещё база данных, настройки CMS и содержимое разделов, а вот всё, что связано с внешним миром, на dev-площадке намеренно отключают или подменяют: письма с форм уходят не клиенту, а на служебный ящик, счётчики аналитики не ставят или ставят отдельные, приём оплат работает в тестовом режиме. Иначе тестовая заявка уедет менеджерам, а визиты разработчика испортят статистику боевого сайта.

Три контура: dev, staging, production

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

Как dev закрывают от поисковых систем

• Пароль на уровне сервера – самый надёжный способ: робот получает отказ в доступе и дальше не идёт. Именно так я закрываю dev по умолчанию.
• Запрет в robots.txt строкой Disallow: / – помогает, но это указание для добросовестных роботов, а не защита. Сам файл открыт всем, и адрес dev-площадки из него прекрасно виден.
• Метатег noindex на страницах – дополнительная страховка. Её главный риск в другом: этот тег легко забыть снять при переносе, и тогда от индексации окажется закрыт уже боевой сайт.

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