Domains 11

 

Знакомо чувство, когда после «успешного» переноса сайта посещаемость падает в пропасть, а поддержка нового хостинга разводит руками? Уверен, многие кивнут. Переезд на новый сервер — это как перевозка хрустальной вазы в картонной коробке по ухабистой дороге. Сделаешь одно неверное движение — и прощай, результат месяцев работы. А ведь переезжать-то часто нужно: то тариф подорожал, то скорость не радует, то ресурсов не хватает.

Но вот в чем парадокс: чаще всего сайт «ломается» не из-за хостинга, а из-за наших собственных ошибок. Я сам наступил на эти грабли не раз, пока не выработал для себя четкий план. Сегодня делюсь топом главных промахов, которые могут стоить вам до 70% трафика и бессонных ночей. Давайте разберем их по косточкам, чтобы ваш переезд был безопасным.

Десятка промахов, которые лучше не повторять

Сразу оговорюсь — список составлен не по возрастанию «опасности». Каждая ошибка из этой десятки может привести к катастрофе. Начнем, пожалуй, с самой коварной, связанной с SEO.

1. Фатальное игнорирование 301 редиректов

Ох, это классика жанра! Кажется, что файлы перенесены, база данных работает, сайт открывается. Ан-нет. Вы забыли сказать поисковым системам, что страницы переехали на новый адрес. Для Google и Яндекса старый URL и новый — это две совершенно разные страницы. Результат? Вы теряете вес страниц, а вместе с ним и позиции. Трафик может рухнуть на те самые 70%, а восстанавливать все придется месяцами.

Как не облажаться:

• На новом сервере в первую очередь настройте 301 редирект со старых URL на новые. Делается это через файл .htaccess для Apache или конфиг Nginx.
• Не поленитесь зайти в Google Search Console и Яндекс.Вебмастер. Проверьте, нет ли дублей, и отправьте новую карту сайта.
• Да, и обновите саму XML-карту сайта (sitemap) и ссылку на нее в robots.txt.

Личное мнение: Тестируйте редиректы локально или на тестовом поддомене, до того как начнете возиться с DNS. Сэкономите кучу нервов.
[ИЗОБРАЖЕНИЕ: Сравнение 301 и 302 редиректов схемы]

2. Смена DNS-записей — первым делом! (Очень плохая идея)

Руки чешутся поскорее указать новые DNS-серверы у регистратора? Остановитесь! Это одна из самых распространенных и грубых ошибок. Как только вы смените записи, ваш сайт на 24-72 часа (а иногда и дольше!) попадет в цифровое чистилище. Пользователи будут хаотично попадать то на старый сервер, то на новый, теряя сессии и корзины. Заказы — в трубу.

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

1. Весь перенос (файлы, база, настройки) и, главное, тестирование делаем ДО смены DNS.
2. За сутки до переключения снижаем TTL (Time To Live) записей до минимума, скажем, до 300 секунд. Это ускорит распространение новых данных.
3. И только когда на тестовом домене (о нем ниже) всё идеально, меняем DNS. После стабилизации TTL можно вернуть к нормальным значениям.

[ВИДЕО: Что такое DNS простыми словами]

3. Резервная копия? А зачем, я же всё аккуратно копирую!

Горький смех. Полная и проверенная резервная копия — это ваш спасательный круг. Без нее вы в открытом море без весла. Старый хостинг может удалить данные раньше срока, что-то пойдет не так при копировании, файлы повредятся… Сценариев масса.

Обязательные действия:

• Продлите старый хостинг хотя бы на месяц-два после переезда. Это ваш плацдарм для отступления.
• Сделайте полный бэкап: все файлы сайта и дамп базы данных через панель управления или SSH.
• Скачайте эту копию к себе на компьютер и проверьте, что архивы открываются, а база не битая.

4. WordPress не работает? Скорее всего, косяк в wp-config.php

Типичная картина после переноса WordPress-сайта: белый экран смерти или ошибка соединения с базой данных. Паника! Но в 95% случаев проблема в одном файле — wp-config.php. На новом хостинге другие параметры для подключения к MySQL.

Быстрое решение:

1. В панели нового хостинга создайте новую базу данных и пользователя для нее.
2. Откройте файл wp-config.php в корне вашего сайта и найдите строки с DB_NAME, DB_USER, DB_PASSWORD, DB_HOST.
3. Замените старые значения на новые, которые вам выдал хостинг. Сохраните файл и загрузите на сервер.

[ИЗОБРАЖЕНИЕ: Пример настройки wp-config.php файла]

5. Запуск «в лоб», без тестовой среды

«Да оно же и так работает!» — знаменитые последние слова. Запускать сайт на новом месте без проверки — это игра в русскую рулетку. Вылезут битые ссылки, сломаются формы отправки, плагины начнут конфликтовать.

Как тестировать грамотно:

• Разверните точную копию сайта на поддомене (например, test.vashesite.ru). Обязательно закройте его от индексации (noindex в robots.txt и заголовках)!
• На этой копии проверьте ВСЁ: отправку форм, работу корзины, авторизацию пользователей, скорость загрузки.
• Сымитируйте нагрузку. Хватит ли ресурсов новому серверу, если придут посетители?

Быстрый взгляд на последствия ошибок

Ошибка	Что будет	Время на исправление
Нет 301 редиректов	Падение трафика до 70%	6–12 месяцев на восстановление
Ранняя смена DNS	Простой сайта до 72 часов	2–3 дня на стабилизацию
Отсутствие бэкапа	Безвозвратная потеря данных	Невозможно
Проблемы с wp-config.php	Белый экран, сайт не работает	10-30 минут

6. HTTPS перестал работать после переезда

Вроде и сертификат тот же, а браузер кричит, что соединение небезопасно. Знакомая история? SSL-сертификат привязан к серверу. После переезда его нужно переустановить или получить новый (бесплатный Let’s Encrypt — наш друг).

План действий:

1. Установите SSL-сертификат на новом хостинге. Многие панели (cPanel, ISPmanager) делают это в пару кликов.
2. Проверьте цепочку сертификата на ssllabs.com.
3. Настройте принудительное перенаправление с HTTP на HTTPS через тот же .htaccess.

7. Файлы ошибок? Не, не слышал

После миграции сайт вроде открывается, но некоторые страницы выдают 404 или 500 ошибку. А вы и не в курсе! Логи ошибок (error.log в Apache/Nginx) — это ваша медицинская карта сайта. Игнорировать их — все равно что игнорировать боль.

Что делать:

• Найдите и откройте error.log на новом сервере. Там будут все «косяки».
• Пройдитесь по сайту краулером (типа Screaming Frog) и выловите битые ссылки и кривые редиректы.
• Исправляйте ошибки в SQL-запросах, недостающие файлы библиотек.

8. Потеря аналитики и счетчиков

Переехали, а данные в Яндекс.Метрике и Google Analytics будто обнулились. На самом деле, вы просто забыли перенести коды счетчиков в шаблон нового сайта. Останетесь без важнейших данных для аналитики.

Решение простое до безобразия: убедитесь, что коды счетчиков (и тегов Google Tag Manager) корректно вставлены в код страницы, обычно в <head> или перед закрывающим </body>. Проверьте работу в реальном времени.

9. Права доступа (chmod) съехали

Картинки не грузятся, скрипты не работают, в админку не войти. Частая причина — сбившиеся права доступа к файлам и папкам на Unix-сервере.

Золотой стандарт: для папок — 755, для файлов — 644. Выставить их можно через FTP-клиент (типа FileZilla) или командой chmod через SSH. Не забудьте проверить владельца файлов (chown).

[ИЗОБРАЖЕНИЕ: Настройка прав доступа chmod в FileZilla]

10. «А новый хостинг точно мощнее?» — проверка производительности

Кажется, все сделали правильно, но сайт стал грузиться медленнее. Виноваты могут быть ограничения нового сервера: лимиты оперативной памяти для PHP (memory_limit), время выполнения скриптов.

Финишная проверка:

1. Сравните ключевые настройки PHP (php.ini) на старом и новом хостинге.
2. Дайте небольшую нагрузку с помощью бесплатных инструментов вроде Loader.io.
3. После запуска мониторьте скорость через GTmetrix или PageSpeed Insights.

Чек-лист для идеального (или почти) переноса

Чтобы ничего не забыть, держите эту памятку. Распечатайте и вычеркивайте пункты.

• До переноса: Резервная копия старого сайта. Оплата старого хостинга с запасом. Снижение TTL DNS-записей.
• Процесс переноса: Копирование файлов и базы данных. Корректировка wp-config.php (для WordPress). Настройка 301 редиректов.
• Тестирование: Развертывание на тестовом поддомене (с noindex). Проверка всех функций, форм, HTTPS, скорости. Установка SSL-сертификата. Проверка логов ошибок.
• Запуск: Перенос кодов аналитики. Финальная синхронизация базы данных (если были новые данные). Смена DNS-записей у регистратора.
• После запуска: Мониторинг сайта 48 часов. Проверка редиректов и индексации в Search Console. Контроль скорости и ошибок.

Частые вопросы (FAQ)

Информация в статье основана на личном опыте и анализе технических материалов. При подготовке использовались данные из открытых источников: Rush Analytics, FirstVDS, GlobalCIO, Cetera, Habr.