Зачем нужна отдельная тестовая копия сайта

Отделите данные и адреса

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

Используйте отличающиеся имена баз и понятные служебные пометки. Если копируются реальные данные, ограничьте доступ и обезличьте сведения там, где это возможно. Robots.txt управляет обходом поисковиком, но не заменяет авторизацию.

Отключите внешние последствия

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

Например, проверка повторного уведомления оплаты выполняется на синтетическом заказе с тестовым режимом. Она не должна создавать право в рабочем магазине или отправлять письмо реальному клиенту. Для разных сред используйте отдельные cookie и закрытые конфигурации.

Различайте копию и read-only демо

На тестовой копии разработчик обычно должен сохранять изменения для проверки редакторских сценариев. Публичная демонстрация предназначена для просмотра: она использует синтетические данные и фактического пользователя БД только с SELECT. Это разные задачи и разные права.

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

Продолжить работу

Проверьте процедуру на отдельной копии сайта. Сопоставьте задачу с возможностями ядра. Другой материал этого раздела: Проверка дистрибутива по SHA-256 и манифесту.