Тестовый и временный хостинг

Когда тестовый хостинг действительно помогает, а когда результат теста ничего не гарантирует

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

Для статического HTML-сайта проверка сравнительно короткая: открыть несколько страниц, убедиться, что загружаются изображения и стили, проверить форму, редиректы и HTTPS. Для WordPress список длиннее. Нужно войти в админку, сохранить запись, загрузить изображение, проверить постоянные ссылки, плагины, cron и отправку писем. У WooCommerce добавляются корзина, оформление заказа, уведомления и фоновые задания.

Тестировать лучше действия пользователя. Посетитель отправляет форму — отправьте её. Редактор загружает фотографии — загрузите несколько файлов. Сайт импортирует каталог — запустите импорт. По расписанию создаётся резервная копия — проверьте не только наличие cron-события, но и появление самой копии.

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

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

Что должно совпадать между тестовым и будущим рабочим хостингом

Чем ближе тестовое окружение к будущему рабочему серверу, тем больше смысла в проверке. WordPress может без ошибок работать на PHP 8.1, а после переноса на другую версию PHP получить Fatal error в старом плагине. Аналогичная история бывает с расширениями PHP, настройками базы, лимитами памяти и обработчиком PHP.

Побитовое совпадение двух серверов не требуется. Нужно сравнить параметры, которые реально влияют на приложение.

При наличии SSH базовую информацию можно получить так:

php -v
php -m
php -i | grep memory_limit

У этих команд есть ограничение: они показывают параметры PHP в CLI. Веб-сайт может работать через PHP-FPM с другим файлом конфигурации и даже другой версией PHP. Поэтому вывод CLI стоит сверить с панелью хостинга, временной страницей phpinfo() или разделом Site Health в WordPress.

Если php -v показывает PHP 8.2, а сайт в панели назначен на PHP 8.1, противоречия здесь нет. Просто проверяются два разных SAPI. Именно по этой причине увеличение memory_limit в конфигурации CLI иногда никак не влияет на ошибку WordPress.

Файл с phpinfo() после проверки лучше удалить. Он раскрывает много информации о конфигурации сервера и на публичном сайте не нужен.

Также сравните не только версии программ, но и принципиально разные элементы окружения. Если тест проходит напрямую на origin-сервере, а рабочий домен будет идти через CDN или reverse proxy, часть маршрута остаётся непроверенной. То же касается SMTP, внешнего API и webhook: доступность сайта сама по себе ничего о них не говорит.

Как проверить сайт до подключения настоящего домена

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

Технический адрес или тестовый поддомен

Самый простой вариант — технический URL, который выдаёт хостинг, либо отдельный поддомен вроде test.example.com. Такой способ удобен для разработки, но у WordPress могут возникнуть дополнительные редиректы из-за сохранённого адреса сайта.

Технический URL не всегда воспроизводит реальный запуск. На основном домене могут отличаться SSL, правила редиректа, cookie, настройки WordPress, CORS или поведение внешних интеграций. Поэтому технический адрес удобен для первичной проверки, а перед переключением лучше протестировать именно рабочее доменное имя.

Проверка через файл hosts

Можно заставить только свой компьютер открывать домен с нового IP. В Windows файл находится здесь:

C:\Windows\System32\drivers\etc\hosts

Пример записи:

203.0.113.10 example.com
203.0.113.10 www.example.com

203.0.113.10 здесь используется только как пример. В реальной записи нужен IP нового сервера.

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

nslookup при такой проверке может всё ещё показывать публичную DNS-запись: утилита обычно обращается к DNS-серверу напрямую и не служит надёжной проверкой содержимого hosts. ping тоже не доказывает, что нужный виртуальный хост корректно обслуживает HTTP или HTTPS.

Проверка через curl без редактирования hosts

Для HTTPS особенно удобен curl --resolve. Команда отправляет запрос на указанный IP, но сохраняет настоящее имя сайта для HTTP Host и TLS SNI:

curl -I --resolve example.com:443:203.0.113.10 https://example.com/

Так можно увидеть HTTP-код и цепочку редиректов до глобального переключения DNS. Если сертификата для домена на новом сервере ещё нет, TLS-проверка завершится ошибкой — и это тоже полезный результат.

Есть важное ограничение. Если рабочий домен будет обслуживаться через Cloudflare, другой CDN или reverse proxy, curl --resolve на IP origin-сервера проверяет именно origin. Маршрут через прокси при этом обходится. До запуска желательно проверить оба сценария: сначала сам новый сервер, затем публичный адрес после включения проксирования.

Почему WordPress на временном адресе начинает перенаправлять на старый домен

WordPress может сразу перебрасывать посетителя с тестового URL на основной домен, потому что адрес сайта хранится внутри CMS. В первую очередь нужно проверить параметры home и siteurl, а не менять настройки сервера наугад.

Если доступен WP-CLI:

wp option get home
wp option get siteurl

При необходимости значения можно временно изменить:

wp option update home 'https://test.example.com'
wp option update siteurl 'https://test.example.com'

Но WordPress — не единственный источник редиректа. Код 301 или 302 может отдавать плагин, .htaccess, конфигурация Nginx, кеш или внешний reverse proxy. Поэтому сначала полезно посмотреть сам ответ сервера:

curl -I https://test.example.com/

Если редирект появляется уже в первом ответе, изучите заголовок Location и идите по цепочке. Если WordPress отправляет на старый адрес — смотрите настройки CMS. Если редирект возникает ещё до выполнения PHP, источник нужно искать в веб-сервере или прокси. Не меняйте всё одновременно: после этого уже трудно понять, что именно исправило проблему.

Почему опасен обычный SQL REPLACE

После переноса WordPress часто требуется заменить старые URL на новые. Делать глобальный REPLACE() по всей базе рискованно: плагины и сама CMS могут хранить сериализованные структуры, в которых учитывается длина строки.

WP-CLI умеет корректно обрабатывать такие значения. Сначала стоит посмотреть будущие изменения:

wp search-replace 'https://old.example.com' 'https://test.example.com' --dry-run

Если результат ожидаемый, команду повторяют без --dry-run. Перед массовой заменой всё равно нужна резервная копия базы.

Почему после замены URL редирект может остаться

Если home и siteurl уже правильные, а браузер продолжает уходить на старый домен, проверьте кеш. Старый 301 мог сохраниться в браузере, серверном кеше или CDN. Для диагностики удобнее смотреть ответ через curl -I в обход браузерной истории и сравнивать его с тем, что показывает DevTools.

Если в Location уже указан новый домен, а браузер всё равно открывает старый, проблема может находиться не на текущем сервере. Вот здесь особенно полезно разделить серверный ответ и поведение клиента.

Как проверить PHP, базу данных и файловые права за первые 10 минут

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

1. Проверить версию PHP.
2. Убедиться, что доступны нужные расширения.
3. Создать тестовую базу MySQL/MariaDB.
4. Подключиться к ней реальными реквизитами.
5. Проверить чтение и простой запрос.
6. Загрузить файл через панель или CMS.
7. Проверить запись в рабочий каталог сайта.
8. Посмотреть error_log.
9. Проверить свободное место и квоту.

Проверка PHP

При наличии SSH пригодятся:

php -v
php -m
df -h
pwd
ls -la

df -h показывает использование файловых систем, но на shared-хостинге не всегда отражает персональную квоту аккаунта. Если в панели есть отдельный показатель Disk Usage или Quota, ориентироваться лучше на него.

Проверка подключения к MySQL/MariaDB

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

mysql -h DB_HOST -u DB_USER -p DB_NAME

После подключения достаточно простого запроса:

SELECT VERSION();
SELECT DATABASE();

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

Не обязательно использовать CLI: тот же смысл имеет подключение через установщик CMS или диагностический скрипт. Но сообщение «база создана» в панели ещё не доказывает, что приложение сможет к ней подключиться.

Проверка файловых прав

При SSH можно посмотреть владельца и режим доступа каталога:

ls -ld .
ls -ld wp-content wp-content/uploads

Для грубой проверки записи от SSH-пользователя можно создать и удалить временный файл:

touch hosting-write-test.txt
ls -l hosting-write-test.txt
rm hosting-write-test.txt

Но здесь есть ловушка. Успешный touch подтверждает права SSH-пользователя, а PHP-FPM может работать от другого пользователя. Поэтому для WordPress обязательно повторите проверку через саму CMS: загрузите изображение или создайте файл тем механизмом, который будет работать в production.

Если SSH пишет файл, а WordPress получает Permission denied, проблема уже не в свободном месте. Смотрите владельца каталогов и пользователя PHP-FPM. Если в логе появляется No space left on device, наоборот, смена chmod не поможет — нужно проверять квоту, свободный диск или inodes.

Если WordPress уже установлен, Site Health даст дополнительную информацию о PHP, базе и некоторых серверных параметрах. Но этот экран не заменяет реальное действие. Загрузите изображение, сохраните запись и выполните операцию, ради которой сайт вообще переносится.

Какие ограничения временного хостинга проявляются только во время реальной работы сайта

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

Поэтому пригодность среды нельзя оценивать только по скорости открытия главной. CPU, память, I/O, число процессов и PHP workers могут вообще не проявить себя в таком тесте.

Как отличить нехватку памяти от другой проблемы

Если после активации конкретного плагина появляется HTTP 500, первым делом нужен error_log, а не увеличение всех лимитов подряд. Сообщение вроде:

Allowed memory size of ... bytes exhausted

прямо указывает, что PHP упёрся в лимит памяти. Здесь есть основание проверять memory_limit и фактическое потребление скрипта.

Если вместо этого видно:

Maximum execution time of ... seconds exceeded

проблема уже другая: операция не уложилась в допустимое время. Увеличение памяти может вообще ничего не изменить.

HTTP 503 без PHP Fatal тоже не доказывает нехватку RAM. Ответ может быть связан с лимитом процессов, занятыми PHP workers, веб-сервером, прокси или временной недоступностью backend. В таком случае PHP пока не трогаем.

Практическая последовательность диагностики

Когда тяжёлая операция падает не всегда, полезно перестать менять настройки наугад и привязать ошибку ко времени.

1. Повторите операцию, которая вызывает проблему.
2. Запишите точное время ошибки.
3. Сразу откройте PHP- и web-server-логи за этот интервал.
4. Сопоставьте событие со статистикой CPU, RAM, I/O и процессов в панели, если она доступна.
5. Отделите ошибку приложения от ресурсного ограничения.
6. Меняйте только тот параметр, для которого появилось подтверждение.

На VPS можно дополнительно смотреть системные метрики, но на shared-хостинге пользователь часто видит только Resource Usage в панели. Этого уже бывает достаточно: если на момент 503 упирается число процессов, увеличение memory_limit не лечит причину.

Универсального значения «достаточно 1 ГБ RAM» или «нужно минимум четыре PHP worker» нет. Два WordPress-сайта одинакового размера могут создавать совершенно разную нагрузку. Проверять нужно характерную операцию конкретного проекта.

Почему HTTPS и SSL нужно проверять отдельно от самого сайта

Работа сайта по HTTP не подтверждает корректную работу HTTPS. После включения SSL добавляются сертификат, TLS, новые редиректы и требования к адресам ресурсов. Именно на этом этапе часто обнаруживается mixed content или цикл HTTP → HTTPS → HTTP.

Начать можно с двух запросов:

curl -I http://example.com/
curl -I https://example.com/

Проверьте итоговый код ответа и заголовок Location. Нормальный сценарий для сайта с принудительным HTTPS обычно выглядит как один понятный редирект с HTTP на HTTPS, после которого сервер отдаёт страницу.

Если браузер показывает ERR_TOO_MANY_REDIRECTS, нужно искать несколько одновременно работающих правил: например, WordPress включает HTTPS, веб-сервер делает свой редирект, а reverse proxy сообщает приложению неверную схему запроса.

Что именно проверить в сертификате

Сам сертификат можно посмотреть через OpenSSL:

openssl s_client -connect example.com:443 -servername example.com

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

Особенно полезен параметр -servername: он передаёт SNI. Без него сервер с несколькими HTTPS-сайтами может вернуть сертификат другого виртуального хоста, и диагностика пойдёт не туда.

Почему страница может быть HTTPS, а часть ресурсов — нет

После этого откройте DevTools → Console и Network. Сообщения Mixed Content покажут ресурсы, которые страница всё ещё пытается загрузить по http://. До включения HTTPS такой дефект просто невозможно увидеть.

Для WordPress причиной часто остаются старые абсолютные URL в базе, теме или настройках плагина. Но не нужно сразу запускать глобальный search-replace: сначала посмотрите, какой именно ресурс загружается по HTTP и откуда формируется его адрес.

Если основной сайт работает через CDN, финальная HTTPS-проверка должна идти через публичный домен. Проверка origin-сервера отдельно полезна для диагностики, но не подтверждает, что весь путь клиент → CDN → origin настроен правильно.

Как проверить отправку писем, cron и другие функции, которые легко пропустить

Почту, cron и фоновые задачи нужно тестировать отдельно: обычный просмотр страниц не показывает их состояние. Форма может вывести сообщение «Отправлено», хотя почтовая функция завершилась ошибкой. Событие WordPress может присутствовать в расписании, но не запускаться вовремя.

Проверка почты

Отправьте реальное тестовое письмо через тот механизм, который будет использовать сайт: SMTP-плагин, приложение или wp_mail(). Затем проверьте не только сообщение на странице, но и фактическое получение письма.

SMTP принял письмо — это ещё не Inbox. Сервер мог успешно передать сообщение следующему почтовому узлу, а дальнейшая доставка зависит от SPF, DKIM, DMARC, репутации отправителя и политики принимающей стороны. Поэтому для диагностики полезно разделять факт отправки и конечную доставку.

Проверка WordPress Cron

Список событий можно посмотреть через WP-CLI:

wp cron event list

Наличие события доказывает только то, что WordPress его запланировал. Чтобы убедиться в работе задачи, нужен результат: созданный backup, отправленное письмо, обработанная очередь или запись в журнале. Запись в расписании ещё не означает, что задача выполнилась.

Для системного cron при наличии SSH:

crontab -l

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

Webhook и внешние API

Если сайт обращается к платёжной системе, CRM, Telegram API или другому внешнему сервису, сделайте отдельный тест. Новый сервер может иметь другие сетевые ограничения, другой исходящий IP или отличаться набором PHP-модулей. Страница при этом будет открываться совершенно нормально.

Проверяйте не только код ответа самого сайта, но и результат интеграции: появилась ли запись в CRM, принял ли webhook внешний сервис, вернулся ли ожидаемый ответ API. Ошибка интеграции нередко живёт полностью за пределами браузера.

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

У staging-копии есть обратная проблема: она может работать слишком хорошо. Если просто скопировать production WordPress вместе с базой и настройками, тестовый сайт способен начать отправлять настоящие письма клиентам, выполнять cron, обращаться к CRM и слать webhook на рабочие endpoint.

Нет одной универсальной команды, которая безопасно «выключит staging». У плагинов и приложений разные механизмы. Перед первым открытием копии проверьте почту, cron, API-ключи и webhook. Особенно внимательно — WooCommerce и проекты с CRM.

Копия production-базы также может содержать персональные данные пользователей. Тестовый статус сервера не делает такие данные публичными или некритичными. Доступ к staging лучше ограничить, а ненужные реальные данные по возможности не использовать.

Когда временный хостинг уже нельзя считать адекватной заменой рабочего

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

Семь признаков, что стенд уже стал production

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

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

Что проверить, если хостинг действительно нужен временно, но для рабочего сайта

Иногда проект действительно нужно запустить на несколько дней или недель: постоянный сервер ещё не готов, идёт переезд или временная площадка используется на переходный период. Это уже не staging. Для такого сценария условия временной площадки стоит сравнивать с обычным shared-хостингом, особенно по резервным копиям, ресурсам и сроку хранения данных.

До запуска проверьте условия конкретной услуги:

• когда заканчивается доступ к аккаунту;
• что произойдёт после окончания тестового или оплаченного периода;
• удаляются ли данные и через какой срок;
• можно ли выгрузить файлы и базу обычным способом;
• доступны ли резервные копии и как они хранятся;
• можно ли подключить собственный домен и SSL;
• работают ли SMTP, cron и исходящие соединения;
• есть ли ограничения ресурсов, отличающиеся от постоянной услуги;
• можно ли продолжить работу на той же площадке без очередной миграции.

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

Как закрыть тестовую копию от посторонних

Если стенд доступен извне, поисковый робот может обнаружить его по ссылке. Для публичной тестовой копии полезно отдельно проверить, как заблокировать тестовый домен для поисковых роботов. Одного robots.txt недостаточно как средства защиты содержимого: URL всё равно может попасть в индекс без текста страницы.

Для действительно закрытого staging надёжнее ограничить доступ на уровне HTTP-авторизации, панели хостинга, VPN или другим серверным механизмом. noindex полезен как дополнительная защита от индексации, но это не контроль доступа. Если на копии лежит production-база с пользовательскими данными, разница принципиальная.

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

Как перенести проверенный сайт с временного хостинга без повторного поиска ошибок

Перенос считается законченным не после копирования файлов, а после повторной проверки функций. Даже точная копия сайта может вести себя иначе после смены домена, SSL, PHP, DNS и настроек базы.

До переноса

• Создайте свежую резервную копию файлов и базы.
• Запишите используемую версию PHP.
• Сохраните список нужных PHP-модулей.
• Зафиксируйте cron-задачи.
• Проверьте текущие URL WordPress.
• Убедитесь, что тестовая копия не индексируется.
• Определите, какая база в момент переключения считается источником истины.

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

Как не потерять новые записи в базе между тестом и переносом

Для динамического сайта схема «создали копию → три дня тестировали → просто включили её» опасна. За эти три дня на старом сайте могли появиться заказы, пользователи, комментарии и новые настройки.

Перед финальным переносом нужно выбрать стратегию. Самая понятная — короткое окно обслуживания:

1. Остановить или ограничить новые записи на старом сайте.
2. Создать свежий дамп production-базы.
3. Импортировать его на новый сервер.
4. Выполнить необходимые изменения URL и конфигурации.
5. Провести короткий контрольный тест.
6. Переключить DNS или прокси.

Если одновременно изменялись и staging, и production, задача сложнее: бездумно импортировать одну базу поверх другой нельзя. Нужно определить, какие изменения должны сохраниться с каждой стороны. Для небольшого WordPress-проекта часто проще повторить изменения конфигурации на свежей production-базе, чем пытаться «слить» две независимо изменявшиеся базы.

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

Во время переноса

• Скопируйте файлы.
• Импортируйте актуальную базу.
• Укажите новые реквизиты подключения к БД.
• Проверьте владельца и права файлов.
• Замените временные URL на рабочий домен.
• Подключите домен.
• Выпустите и проверьте SSL-сертификат.

Для WordPress сначала выполните безопасную проверку замены:

wp search-replace 'https://test.example.com' 'https://example.com' --dry-run

Посмотрите количество найденных замен и убедитесь, что адреса указаны правильно. После этого команду можно выполнить без --dry-run.

Что делать с DNS перед переключением

После изменения A/AAAA-записи не все пользователи обязательно начинают ходить на новый IP в одну секунду. Рекурсивные DNS-серверы могут держать старое значение до истечения TTL.

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

После смены записи полезно проверить несколько независимых резолверов:

dig +short A example.com @1.1.1.1
dig +short A example.com @8.8.8.8

В Windows можно использовать:

nslookup example.com 1.1.1.1
nslookup example.com 8.8.8.8

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

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

При использовании CDN картина может отличаться: публичная DNS-запись может вести не на origin, а на прокси. Тогда переключается адрес origin внутри панели CDN или меняется другая часть цепочки. Проверяйте тот маршрут, который реально используют посетители.

После переноса

• Откройте главную и несколько внутренних страниц.
• Войдите в административную часть.
• Загрузите изображение.
• Отправьте форму.
• Проверьте фактическое получение письма.
• Запустите фоновую задачу.
• Посмотрите error_log.
• Проверьте HTTPS и цепочку редиректов.
• Убедитесь, что последние заказы, заявки или записи базы на месте.
• Очистите серверный кеш и кеш CMS, если они используются.
• Удалите временные диагностические файлы.

HTTP-ответ удобно проверить отдельно:

curl -I https://example.com/

Не нужно требовать код 200 от каждого первого запроса: перенаправление с www на основной домен или с HTTP на HTTPS может быть нормальным. Подозрительны неожиданные цепочки 301/302, циклы и переходы обратно на тестовый адрес.

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

Как понять за 15 минут, можно ли запускать сайт

Перед переключением нужен короткий smoke test. Он не доказывает, что сайт будет стабилен под любой нагрузкой и что суточный cron обязательно сработает завтра. Его задача проще: найти очевидные причины, из-за которых запуск сейчас лучше остановить.

1. Откройте сайт по HTTPS.
2. Проверьте главную и 3–5 разных внутренних страниц.
3. Авторизуйтесь в CMS.
4. Загрузите тестовое изображение.
5. Отправьте форму.
6. Убедитесь, что письмо реально получено.
7. Выполните одну характерную тяжёлую операцию: импорт, backup или генерацию файлов.
8. Проверьте cron или другую фоновую задачу.
9. Откройте error_log.
10. Проверьте HTTP-коды и редиректы.
11. Посмотрите дисковую квоту.
12. Проверьте, не остались ли ссылки на тестовый URL.
13. Проверьте правила индексации.
14. Убедитесь, что последние реальные данные присутствуют в базе.
15. Создайте свежий backup перед окончательным переключением.

Если сайт визуально работает, но error_log после каждого запроса пополняется новыми Fatal error, запускать проект рано. Ошибка уже существует — просто посетитель ещё не попал в сценарий, который её покажет.

То же относится к 503 и таймаутам на типичной рабочей операции. Если главная страница стабильна, а импорт, backup или оформление заказа регулярно падают, smoke test не пройден.

Что контролировать сразу после переключения

Успешный 15-минутный тест означает только одно: очевидной причины отменять запуск не найдено. После переключения сайт всё равно нужно наблюдать.

В первые контрольные проверки входят:

• новые записи в error_log;
• HTTP 5xx;
• поступление реальных заявок и заказов;
• доставка системных писем;
• выполнение cron;
• свободное место и квота;
• работа внешних API и webhook;
• наличие обращений к старому серверу во время DNS-перехода.

На тестовом сервере всё могло быть чисто, а после переключения часть пользователей ещё некоторое время попадёт на старый IP из DNS-кеша. Это уже не проблема WordPress. Поэтому старый сервер не стоит отключать сразу после изменения записи.

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