Как перенести сайт на другой хостинг

Перенос начинается с описи и способа возврата. Запишите, что меняется: площадка сайта, база, доменное имя, почтовый сервис или несколько частей сразу. Не объединяйте это в одну команду «поменять DNS». Смена хостинга не требует автоматически переносить домен к другому регистратору.

До копирования: данные, службы и ответственность

Сохраните рабочие файлы и базу, конфигурацию приложения, нужные фоновые задачи и сведения о версиях. Отдельно учтите медиа, закрытые вложения и внешние хранилища. Объем архива не доказывает, что все эти части включены.

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

Копия для проверки не второй рабочий сайт

Разверните проверочную среду с ограниченным доступом и отдельными данными. Исключите реальные платежи, отправку писем, webhooks и повторный запуск задач. Архив может содержать действующие секреты; не выкладывайте его в публичный каталог.

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

Подробности состава и возврата есть на странице backup. Проверка на копии не лицензия удалить оригиналы после первого успешного открытия.

WordPress staging: метка среды не изоляция

На 6 октября 2026 года wp_get_environment_type принимает типы local, development, staging и production через переменную или константу WP_ENVIRONMENT_TYPE. По умолчанию возвращается production, недопустимое значение также заменяется им. Константа имеет приоритет перед системной переменной.

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

До копирования согласуйте отдельную БД, учетные данные, доступ к файлам и владельца среды. После копирования подтвердите, что приложение подключается именно туда. Поддомен с названием staging не доказывает изоляцию от рабочей базы.

noindex не закрывает документы посторонним

Google Search Central описывает noindex в meta или HTTP-заголовке как правило индексации. Для его чтения Googlebot нужен доступ к странице; запрет robots.txt может помешать увидеть правило.

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

Если на рабочем сайте после создания staging появились заказы или сообщения, старый снимок нельзя считать актуальной базой для обратного переноса. Согласуйте публикацию кода и данных раздельно. Успешное обновление тестовой копии не разрешает автоматически перезаписать production.

Здесь WP_ENVIRONMENT_TYPE, robots, noindex, права доступа, базы, интеграции и настройки пользователя не менялись. Примеры в комментариях документации не использовались как команды; тестовые аккаунты и сайты не создавались.

Что меняется при сохранении и смене URL

Официальное руководство WordPress по миграции, проверенное 6 октября 2026 года, различает перенос с сохранением домена и URL от смены имени или пути. Для первого нужны файлы и БД; изменение имени базы или пользователя требует соответствующей настройки подключения.

При смене URL остаются ссылки в базе, а обычная замена строк может повредить сериализованные данные. Документ выделяет специализированные инструменты и предупреждает не менять GUID. Это пример WordPress, не универсальная инструкция SQL для всех CMS.

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

TTL не кнопка мгновенного обновления

Отдельное определение DNS TTL разбирает прежний срок, кешированный ответ и отрицательное кеширование; это не срок готовности приложения.

Документация Cloudflare о TTL определяет его как срок кеширования записи. Более длинный TTL увеличивает время действия старого ответа. У proxied-записей Cloudflare Auto соответствует 300 секундам и не редактируется; локальный кеш может задержать наблюдаемое изменение дольше пяти минут.

Это свойства Cloudflare, не предел для всех DNS-провайдеров. Nameserver TTL также выделен отдельно от TTL обычных записей. Не обещайте одинаковые «пять минут» или «48 часов» для любой схемы.

Перед переключением сохраните действующие записи и их назначение. Согласуйте, какие A/AAAA или другие значения меняются. Не заменяйте всю зону файлом неизвестного происхождения. После изменения проверяйте ожидаемый ответ и фактическую площадку из нужных точек, а не только одну открывшуюся вкладку.

Почтовые записи и ящики принимают отдельно

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

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

Для собственного сервера смотрите почтовый VPS, для готовых ящиков - почтовый хостинг. Сайт может открываться, пока почта работает неправильно; это разные критерии завершения.

Сертификат требует своего маршрута проверки

Let's Encrypt: Challenge Types описывает HTTP-01 на порту 80 с файлом в .well-known/acme-challenge. Эта проверка не выпускает wildcard-сертификат. Если веб-серверов несколько, нужный файл должен быть доступен на всех соответствующих узлах.

DNS-01 использует TXT для _acme-challenge и позволяет wildcard. Документ предупреждает о риске полных DNS API-прав на веб-сервере: рекомендуются ограниченные учетные данные либо отдельная среда проверки.

До переключения согласуйте выпуск, имена, цепочку и продление сертификата. Не исправляйте ошибку браузера отключением проверки доверия. Работающий HTTPS на старой площадке не доказывает правильную настройку новой. Учетные данные, TXT и сертификаты здесь не создавались и не менялись.

Финальная синхронизация и новые записи

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

Перед публичным переключением повторите контроль БД и файлов, проверьте нужные права и задачи. Включайте интеграции и расписание по одному согласованному плану, чтобы не отправить двойное уведомление или не выполнить импорт дважды. Общие правила есть на странице cron.

Запишите результаты приемки и время последнего согласованного состояния. Это план, не наши испытания чужого сайта или обещание переноса без простоя.

Откат: возвращают состояние, не только IP

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

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

План должен назвать условия возврата и ответственного. Успешная главная не повод отключить старый сервер; завершение подтверждают обычные операции, почта, SSL, фоновые задачи и сохранность данных.

В этой работе рабочий DNS, NS, MX, сервер, CMS, сертификаты и интеграции пользователя не менялись, письма не отправлялись. Для выбора новой среды сравните тарифы, затем согласуйте паспорт переноса и проверку копии.