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

Содержание:

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

Эта статья не повторяет пошаговую инструкцию по переносу сайта на другой хостинг. Здесь — критерии выбора и проверка площадки до переключения домена.

Начните с требований сайта, а не с тарифа

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

Маркетинговые названия тарифов у провайдеров несопоставимы. Сравнивайте измеримые лимиты и условия.

Какой тип размещения выбрать

Виртуальный хостинг

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

VPS или облачный сервер

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

Управляемая инфраструктура

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

Проверка совместимости с WordPress и 1С-Битрикс

Для WordPress важны актуальные версии PHP и СУБД, HTTPS, cron и возможность управлять кэшем. Для 1С‑Битрикс дополнительно проверяют требования редакции, окружение, обмены и результаты встроенной проверки системы. Нельзя переносить проект на платформу, ориентируясь только на заявление «подходит для CMS».

Резервные копии и восстановление

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

Безопасность и доступы

• индивидуальные учётные записи вместо общего пароля;
• двухфакторная аутентификация панели;
• ограничение SSH и SFTP;
• журналы доступа и действий;
• защита от сетевых атак и вредоносных запросов;
• регулярные обновления серверного ПО;
• понятный процесс отзыва доступов подрядчиков.

Как проверить производительность до переезда

Разверните копию сайта на временном адресе, прогрейте кэш и проведите сценарные тесты: открытие каталога, поиск, оформление заказа, работу административной части и фоновые обмены. Синтетический тест одной страницы не показывает поведение всего проекта.

Что спросить у поддержки провайдера

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

Чек-лист готовности к переключению

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

Связь хостинга с поддержкой сайта

Провайдер отвечает за инфраструктуру в пределах тарифа, а команда поддержки сайта — за CMS, код и интеграции. На практике сбой может находиться на границе зон ответственности, поэтому полезны единый мониторинг и специалист, который умеет читать серверные и прикладные журналы. Для WordPress такие задачи можно включить в доработку и поддержку сайта; для Битрикс — в сопровождение проекта на 1С‑Битрикс.

Как рассчитать необходимые ресурсы

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

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

SLA, мониторинг и ответственность

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

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

Почта, DNS и внешние сервисы

После смены хостинга сайт иногда перестаёт отправлять письма, потому что меняются IP, DNS-записи или правила авторизации домена. До переезда зафиксируйте MX, SPF, DKIM и DMARC, способ отправки транзакционных сообщений и адреса, которые используют формы. Если почта размещена отдельно, не переносите её записи вместе с веб-сайтом автоматически.

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

Как провести тестовый переезд

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

• сверить версии окружения и расширений;
• проверить права файлов и расписание cron;
• выполнить сценарии с авторизацией и формами;
• измерить время ответа без и с кэшем;
• проверить резервное копирование и восстановление;
• подготовить команду и критерий отката.

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

Что делать дальше

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

Частые вопросы