Переезд сайта на новый хостинг часто выглядит как обычная техническая задача. Скопировать файлы, перенести базу данных, поменять DNS-записи - звучит несложно. Особенно если сайт небольшой и раньше уже приходилось что-то выгружать через панель управления или FTP.
Но на практике именно в момент переезда могут всплыть проблемы, о которых владелец сайта не догадывался.
Форма заявки перестала отправлять письма. Корзина открывается, но заказ не создается. Часть пользователей видит старую версию сайта, часть - новую. В поиске появляются дубли. А где-то в админке уже лежат свежие заявки, которые остались на старом сервере.
Чаще всего такие ситуации возникают не потому, что перенос сайта сам по себе сложный. Проблема в деталях: не проверили окружение, не сделали нормальную резервную копию, рано переключили домен, забыли про финальную синхронизацию или сразу отключили старый сервер.
В этой статье разберем, какие ошибки чаще всего ломают переезд сайта на новый хостинг. И что проверить заранее, чтобы не потерять заявки, заказы, данные и позиции в поиске.
Ошибка №1. Переезжать, не проверив новый хостинг
Иногда перенос начинают слишком спешно. Старый хостинг не подходит, сайт тормозит, поддержка отвечает долго. Хочется скорее забрать проект и переехать - понятное желание.
Однако новый хостинг сначала нужно проверить. И не только по цене или объему диска.
Важно проверить, подходит ли он именно вашему сайту, т.е.:
- Версию PHP;
- Поддержку нужной база данных;
- Наличие SSL-сертификата;
- Наличие доступа по SSH;
- Наличие нужных модулей и возможности настроить сервер под проект.
Для простого сайта-визитки это может быть не так критично. Для интернет-магазина, сайта на 1С-Битрикс, WordPress с WooCommerce или другого проекта с заказами и личными кабинетами - уже важно.
Бывает так: сайт отлично работал на старом сервере, потому что там были установлены нужные расширения и привычные настройки. Его переносят на новый хостинг, открывают и начинаются ошибки. Где-то не загружается каталог. Где-то не работает форма. Где-то админка открывается, но часть функций падает.
На этом этапе кажется, что сайт сломался, хотя на самом деле он попал в другое окружение.
Перед переносом стоит заранее сверить технические требования проекта и возможности нового хостинга. Это - один из самых важных шагов, ведь именно он снижает риск неприятных сюрпризов после миграции.
Ошибка №2. Сделать резервную копию “для галочки”
Резервная копия перед переносом нужна всегда - даже если кажется, что все под контролем. Также нужно понимать, что именно сохранено и можно ли из этого восстановить сайт.
Минимально должны быть:
- файлы сайта;
- база данных;
- важные конфигурационные файлы;
- доступы и параметры подключения, которые понадобятся при восстановлении.
Особенно осторожно нужно быть с базой данных. В ней могут храниться заказы, пользователи, заявки, настройки, комментарии, товары, статусы оплат.
Если база перенеслась криво или была взята неактуальная копия, проблема может проявиться не сразу. Сайт откроется. Главная страница тоже. А потом окажется, что в админке нет последних заказов или пользователи не могут войти в личный кабинет.
Лучше относиться к резервной копии как к точке возврата. Если что-то пойдет не так, именно она позволит откатиться назад, а не собирать сайт по кускам.
И да, резервную копию лучше хранить отдельно от сервера, на котором идут работы. Потому что если проблема случится с самим сервером, копия “под рукой” может не спасти.
Ошибка №3. Перенести файлы, но забыть про базу и настройки
Многие представляют перенос сайта как копирование папки. Забрали файлы, загрузили на новый сервер - готово.
На самом деле у большинства современных сайтов есть еще база данных. И без нее проект либо не запустится, либо запустится в очень странном виде. Особенно если это интернет-магазин, блог, корпоративный портал, личный кабинет или сайт с формами.
После переноса базы нужно проверить, что сайт действительно к ней подключается. В конфигурационных файлах могут остаться старые данные:
- адрес сервера базы,
- имя пользователя,
- пароль,
- название базы.
Иногда владельцы сайта забывают поменять один параметр и сайт сразу выдает ошибку подключения.
Еще одна частая история - права доступа к файлам и папкам. На старом сервере все работало, потому что права были настроены определенным образом. На новом сервере они другие. В итоге сайт открывается, но не загружает изображения, не пишет кэш, не сохраняет файлы, не обновляет плагины.
Снаружи это выглядит как набор случайных поломок. На деле причина может быть очень приземленной: сайт перенесли, но не довели окружение и настройки до рабочего состояния.
Поэтому после копирования файлов и базы нужно пройтись по базовым вещам: подключение к базе, права доступа, пути к папкам, работу кэша, загрузку изображений, отправку писем.
Ошибка №4. Сразу переключить домен на новый сервер
Самый нервный сценарий выглядит так: сайт загрузили на новый хостинг, сразу поменяли DNS-записи, подождали немного - и только потом начали проверять, что работает. Так делать рискованно.
Лучше сначала открыть сайт на новом сервере в тестовом режиме. До того, как туда попадут реальные пользователи. Это можно сделать через временный адрес, тестовую среду или настройку файла hosts. Для владельца бизнеса сама технология не так важна. Важен принцип - сначала проверить, потом переключить.
Проверять нужно не только главную страницу. Главная часто открывается даже тогда, когда половина сайта уже живет отдельной жизнью.
Стоит пройтись по ключевым сценариям:
- открываются ли основные страницы;
- работает ли каталог;
- отправляются ли формы;
- создается ли заказ;
- проходит ли оплата;
- работает ли авторизация;
- приходят ли письма;
- корректно ли открывается админка;
- не пропали ли изображения;
- активен ли SSL-сертификат.
Для интернет-магазина особенно важно проверить корзину и оформление заказа. Потому что сайт может выглядеть нормально, но бизнес при этом уже теряет деньги. Пользователь добавил товар, дошел до оплаты, а дальше бесконечная загрузка. Вероятнее всего, он не станет писать в поддержку подробный технический отчет. Скорее всего, просто уйдет.
Тестирование до переключения домена дает шанс найти такие проблемы заранее. Без паники и без потока жалоб от клиентов.
Ошибка №5. Не подготовить DNS заранее
DNS в переезде сайта - один из ключевых моментов.
DNS помогает браузерам понять на какой сервер вести пользователя, когда он открывает ваш домен. После переезда этот адрес нужно обновить. Проблема в том, что обновляется он не мгновенно для всех.
У одного пользователя сайт уже может открываться с нового сервера. У другого - все еще со старого. У третьего - через мобильный интернет одно, через домашний Wi-Fi другое. Это нормально для периода распространения DNS-записей, но к этому нужно подготовиться.
Перед переносом обычно снижают TTL - время, на которое DNS-записи запоминаются у провайдеров и промежуточных серверов. Если сделать это заранее, переключение пройдет быстрее и предсказуемее.
Еще важно сохранить старые значения DNS-записей. На случай отката. Потому что если после переключения обнаружится серьезная проблема, нужно быстро вернуть сайт на старый сервер, а не вспоминать в панике, какой там был IP-адрес.
DNS лучше не трогать в последний момент, когда уже все горит. Его готовят заранее, тогда и сам переезд проходит заметно легче.
Ошибка №6. Забыть про финальную синхронизацию
Есть один момент, который легко упустить. Особенно если сайт активно работает каждый день.
Вы сделали резервную копию. Перенесли файлы. Перенесли базу. Проверили новый сервер. Все вроде бы хорошо. Но пока шла подготовка, на старом сайте, скорее всего, продолжалась жизнь. Пришли новые заявки, появились заказы, пользователи зарегистрировались, кто-то оставил комментарий, менеджер поменял статус оплаты.
Если в этот момент просто переключить домен, часть свежих данных останется на старом сервере.
Для обычного сайта это неприятно. Для интернет-магазина - уже серьезный риск. Можно потерять заказ, данные клиента, информацию об оплате или заявку, которая должна была уйти в работу.
Поэтому перед финальным переключением обычно делают последнюю синхронизацию. Иногда на короткое время закрывают формы, переводят сайт в режим обслуживания или ограничивают действия в админке. Это может занять совсем немного времени. Зато данные не разъезжаются между старой и новой версией.
Здесь важно не спешить. Финальная синхронизация - тот самый шаг, который защищает бизнес от странных потерь после переезда.
Ошибка №7. Оставить старую копию открытой для поисковиков
После переезда старый сервер часто еще какое-то время остается включенным. И это правильно - он нужен для отката, проверки и спокойного завершения миграции.
Но есть нюанс. Если старая копия сайта доступна по техническому адресу или поддомену, ее могут увидеть поисковые системы. А дальше начинается не самая приятная история: в индексе появляются дубли страниц, поисковик видит две похожие версии одного сайта и может начать путаться, какую считать основной.
Сайт вроде переехал, страницы открываются, а в поиске начинаются просадки или появляются не те адреса. Иногда проблема проявляется не сразу, поэтому ее сложно связать именно с переездом. Но SEO оптимизация начинает страдать почти сразу.
Старую копию лучше закрыть от индексации. Обычно для этого используют настройки в robots.txt, ограничения доступа или другие технические способы. Главное - не оставлять ее свободно доступной для поисковиков как самостоятельную версию сайта.
При этом важно не удалить старый сервер слишком рано. Он еще может понадобиться. Просто старая копия должна быть технической страховкой, а не вторым сайтом, который внезапно появляется в поиске.
Ошибка №8. Отключить старый сервер сразу после переезда
Когда сайт открылся на новом хостинге, появляется соблазн сразу закрыть старый. Кажется, что все уже закончилось. Новый сервер работает, домен переключен, можно выдыхать. Лучше не торопиться.
Старый сервер стоит оставить активным хотя бы на несколько дней. Обычно безопаснее держать его 48–72 часа после переноса. За это время DNS-записи успевают обновиться у большинства пользователей, а команда может отследить проблемы, которые не были видны в первые минуты.
Некоторые ошибки проявляются не сразу. Например, ночью не сработала отправка писем. Утром менеджер заметил, что часть изображений не загружается. Клиент из другого региона все еще попадает на старую версию. Платежный сервис ведет себя нестабильно. В логах появились ошибки, которых не было на тесте.
Если старый сервер еще жив, у вас есть путь назад. Можно быстро откатиться, сравнить данные, забрать недостающие файлы, проверить настройки. Если его уже отключили, любой сбой становится намного неприятнее.
Что проверить после переезда
В первые часы и дни стоит проверить самые важные сценарии:
- открываются ли ключевые страницы;
- работают ли формы заявок;
- создаются ли заказы;
- проходит ли оплата;
- приходят ли письма пользователям и администраторам;
- работает ли вход в личный кабинет;
- корректно ли открывается админка;
- не пропали ли изображения и файлы;
- активен ли SSL-сертификат;
- нет ли ошибок 404 и 5xx;
- нормально ли работает мобильная версия;
- не просела ли скорость загрузки.
Для интернет-магазина лучше отдельно пройти путь клиента от товара до оплаты. Прямо руками. Добавить товар в корзину, оформить заказ, проверить письмо, посмотреть заказ в админке.
Еще полезно заглянуть в логи сервера. Там могут быть ошибки, которых пользователь пока не заметил. Например, отдельный модуль не может записать файл, скрипт падает на определенной странице, интеграция с внешним сервисом возвращает ошибку.
Переезд считается завершенным не в момент смены DNS. Он завершается тогда, когда сайт стабильно работает на новом сервере, данные на месте, бизнес-процессы не сломаны, а у команды есть резервная копия уже после переноса.
Не забыть про SEO
Есть еще одна зона, которую часто откладывают - это поисковая оптимизация.
После переезда сайт может визуально выглядеть нормально, но для поисковых систем что-то изменилось. Пропали редиректы. Открылись технические страницы. Изменилась карта сайта. Где-то появились дубли. На части страниц слетели мета-теги или alt-тексты у изображений. Вроде мелочи, но из таких мелочей потом складываются просадки.
После миграции стоит проверить:
- файл robots.txt;
- карту сайта sitemap.xml;
- основные редиректы;
- страницы с ошибками 404;
- доступность важных разделов для индексации;
- заголовки и мета-описания;
- канонические адреса страниц;
- старую копию сайта, чтобы она не попала в индекс.
Также полезно посмотреть сайт в Яндекс Вебмастере. Если поисковые системы начнут видеть проблемы, лучше узнать об этом быстро, а не через месяц, когда трафик уже просел.
Короткий чек-лист безопасного переезда
Переезд на новый хостинг - это хорошо составленный план
Перенос сайта на новый хостинг редко ломается из-за одной большой ошибки. Обычно все происходит иначе. Где-то не проверили модуль. Где-то забыли обновить подключение к базе. Где-то не сделали финальную синхронизацию. Где-то выключили старый сервер слишком рано.
Каждая такая мелочь сама по себе кажется не страшной. Вместе они могут привести к потерянным заявкам, заказам, данным и позициям в поиске.
Поэтому к переезду лучше относиться спокойно и последовательно. Сначала резервная копия. Потом тестирование. Затем DNS, финальная синхронизация, мониторинг, SEO-проверка и понятный план отката.
Если сайт приносит заявки или продажи, миграцию лучше не проводить наугад.
В Scalehost можно перенести проект на новую инфраструктуру с проверкой окружения, базы данных, DNS, резервных копий и работы сайта после переключения. Так переезд проходит аккуратнее, а у бизнеса остается меньше поводов нервничать.