Миграция сайта WordPress на новый хостинг: как перенести без потерь

Мы часто видим, как перенос WordPress превращается в головную боль: абсолютные пути в БД, сериализованные данные, разные версии PHP — и в итоге сайт ломается. Правильный порядок действий и профессиональные инструменты сводят риск к нулю, а downtime — к минутам. Недавно мы мигрировали интернет-магазин на 5000 товаров — downtime составил всего 2 минуты, все данные остались целы. В этой статье делимся реальным опытом: как мигрировать WordPress без потерь, используя WP-CLI, и что важно проверить до и после переезда.

Как мигрировать WordPress без даунтайма?

Планирование начинается за 48 часов: снижаем TTL записи A до 300 секунд. Это сократит время ожидания DNS-пропагации после переключения. Для самого переноса выбираем один из трёх подходов:

WP-CLI + rsync лучше плагинов миграции: перенос файлов в 10 раз быстрее, контроль над процессом полный. Для VPS это однозначно предпочтительный вариант — полный контроль, автоматическая обработка сериализованных данных, возможность инкрементального копирования. На shared-хостинге проще взять готовый плагин, но для влажного теста до переключения DNS используйте /etc/hosts.

Почему сериализованные данные — проблема?

Ручная замена http://old-site.com на https://new-site.com через SQL — частая ошибка. Сериализованные строки хранят длину данных, и при замене длины меняются, что ломает массив. wp search-replace решает это за вас:

wp search-replace 'http://old-site.com' 'https://new-site.com' --all-tables --report-changed-only
# Для staging (не менять URL сразу):
wp search-replace 'old-site.com' 'new-site.com' --all-tables --skip-columns=guid

Этот инструмент пересчитывает длины, поэтому данные остаются валидными. Подробнее о сериализованных данных можно прочитать в Wikipedia. Если же вы используете phpMyAdmin или sed — рискуете получить битый сайт и потерять время на восстановление.

Инструменты

WP-CLI + rsync — профессиональный подход для VPS. Полный контроль процесса, минимальное downtime. Плагин All-in-One WP Migration удобен для shared-хостинга, ограничение по размеру файла в бесплатной версии (512 MB). Duplicator создаёт installer-пакет, устанавливается как обычный сайт.

Миграция через WP-CLI (рекомендуется)

Экспорт с источника:

rsync -avz --exclude='.git' --exclude='node_modules' /var/www/old-host.com/ user@new-server:/var/www/new-host.com/
wp db export --add-drop-table - | gzip > /tmp/wordpress-db.sql.gz
scp /tmp/wordpress-db.sql.gz user@new-server:/tmp/

На новом сервере настройка окружения:

mysql -u root -e "
CREATE DATABASE wordpress_new CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'wp_user'@'localhost' IDENTIFIED BY 'new-password';
GRANT ALL PRIVILEGES ON wordpress_new.* TO 'wp_user'@'localhost';"

gunzip -c /tmp/wordpress-db.sql.gz | mysql -u root wordpress_new

Обновить wp-config.php:

define('DB_NAME', 'wordpress_new');
define('DB_USER', 'wp_user');
define('DB_PASSWORD', 'new-password');
define('DB_HOST', 'localhost');

Замена URL в БД:

wp search-replace 'http://old-host.com' 'https://new-host.com' --all-tables --report-changed-only

wp search-replace корректно обрабатывает сериализованные данные — в отличие от ручного SQL UPDATE.

Тестирование на новом сервере (до смены DNS): добавьте в /etc/hosts на своём компьютере 1.2.3.4 new-host.com www.new-host.com. Проверьте: главная страница, товары/посты, формы, оплата, авторизация, изображения.

Смена DNS: после переключения ждать распространения (обычно 1–4 часа).

Типичные ошибки при миграции

Что входит в работу

• Полный бекап исходного сайта (файлы + БД)
• Перенос на новый сервер с настройкой окружения (PHP, MySQL, Nginx)
• Замена URL в БД через wp search-replace
• Настройка SSL-сертификата (Certbot)
• Тестирование всех критических страниц и функционала
• Инструкция по смене DNS
• Часовая поддержка после миграции

У нас за плечами 5+ лет опыта и 50+ успешных миграций WordPress. Экономия на хостинге после оптимизации может быть существенной. Обращайтесь — оценим проект за один день.

Разные версии PHP

Если старый хостинг — PHP 7.4, новый — PHP 8.2: проверить совместимость всех плагинов и тем. Большинство современных плагинов поддерживают PHP 8.x, но некоторые старые — нет. Проверьте логи PHP на новом сервере (например, tail -f /var/log/php/error.log).

SSL на новом сервере

После миграции выпустите сертификат через Certbot. Убедитесь, что FORCE_SSL_ADMIN в wp-config.php установлен.

Сроки

Миграция WordPress-сайта до 5 GB с тестированием и переключением DNS — 3–5 часов. Крупный сайт с дополнительными интеграциями — 6–8 часов. Точная оценка — после ознакомления с проектом. Получите консультацию по миграции прямо сейчас — это бесплатно и займёт не более 15 минут.

Редизайн и миграция сайта: смена CMS, сохранение SEO

Клиент пришёл через 6 недель после самостоятельного редизайна: «Мы переехали с WordPress на Tilda, трафик упал на 70%». Открываю Google Search Console — 847 страниц отдают 404, URL-структура полностью изменилась, не было ни одного 301-редиректа. Яндекс ещё не переиндексировал новый сайт, позиции рухнули. Восстановление заняло 4 месяца и обошлось в потерю выручки около 2 млн рублей за квартал. Наш опыт — более 7 лет и 80+ успешных миграций, гарантируем сохранение позиций при правильном подходе.

Почему миграции ломают SEO

Поисковики проиндексировали конкретные URL. Если /catalog/shoes/nike-air-max-270 превратился в /products/nike-air-max-270 без 301-редиректа — весь ссылочный вес страницы, весь трафик, все позиции уходят в никуда. Google говорит, что 301 передаёт ~99% PageRank, но на практике позиции восстанавливаются за 2–8 недель, а не мгновенно.

Чаще всего SEO ломают не из злого умысла, а потому что разработчик не думает о URL-структуре как о публичном API. Вот типичные поломки:

Как восстановить трафик после неудачной миграции?

Если трафик упал — действуйте немедленно:

1. Краул нового сайта на 404 и сравнение с предмиграционным списком URL.
2. Создание редиректов для всех потерянных страниц с трафиком >0.
3. Проверка структурированных данных и мета-тегов на тестовой выборке.
4. Ежедневный мониторинг Coverage в Search Console и позиций по топ-50 запросам.
5. Если спустя 2 недели трафик не восстанавливается — глубокий аудит редиректов (транзитивность, цепочки, циклы).

В нашей практике такой случай: крупный интернет-магазин потерял 50% трафика при переезде с Битрикса на React + Strapi. За три дня восстановили 95% редиректов, через 3 недели трафик вернулся на 90% от исходного.

Предмиграционный аудит: что нельзя пропустить

До начала разработки нового сайта нужно:

1. Полный краул текущего сайта через Screaming Frog или Sitebulb. Получить список всех индексируемых URL с трафиком из Google Search Console.
2. Выгрузить все страницы с органическим трафиком >0 за последние 6 месяцев — это приоритет для редиректов.
3. Зафиксировать все внешние ссылки (backlinks) на конкретные страницы — Ahrefs, Semrush.
4. Сфотографировать текущие позиции по ключевым запросам — база для сравнения после миграции.
5. Сохранить Core Web Vitals из Search Console за предыдущие 90 дней.

Таблица для фиксации:

Свяжитесь с нами для детального предмиграционного аудита — мы поможем выявить все риски и составить план действий.

Маппинг URL и редиректы

Для проекта с 200+ страницами создаём таблицу маппинга: старый URL → новый URL → статус (301, объединён с другой страницей, удалён). Каждая строка проходит проверку: реально ли контент переехал именно сюда.

В Laravel редиректы через конфигурационный файл и middleware, не через .htaccess — это быстрее и управляемо. Для WordPress → Next.js: редиректы настраиваются в next.config.js (статические) и на уровне Nginx/CDN для динамических. Старый .htaccess на shared хостинге с 500+ строками редиректов — особый ад. Каждый редирект проверяется последовательно, производительность падает. Переносим в Nginx map директиву или Redis-кэш для динамического поиска. Подробнее в Wikipedia: HTTP 301.

Миграция контента из разных CMS

WordPress → Headless CMS (Contentful, Strapi, Sanity):
WordPress REST API или WP All Export для экспорта постов, метаполей, медиафайлов. Скрипт миграции на Node.js: парсим экспорт, трансформируем структуру, загружаем через API CMS. Медиафайлы перегружаем в новое хранилище, обновляем ссылки в контенте. Типичная проблема — shortcodes в контенте WordPress ([gallery id="123"]): нужен парсер и трансформация в новый формат.

1С-Битрикс → современный стек:
Битрикс хранит контент в нестандартных таблицах с IBLOCK_ELEMENT_PROPERTY. Прямой SQL-экспорт через phpMyAdmin или Bitrix API. Трансформация — самая долгая часть из-за специфики структуры данных Битрикса.

Тяжёлые WYSIWYG → структурированный контент:
Годы редактирования в FCKEditor/TinyMCE оставляют inline-стили, нестандартные теги, сломанные атрибуты. HTML sanitize + трансформация в Markdown или Portable Text (Sanity) с ручной проверкой проблемных страниц.

SEO-сохранение технических элементов

Структурированные данные (Schema.org) — если на старом сайте были Product, Article, BreadcrumbList разметки, они должны быть и на новом. Google Search Console → Enhancement reports покажут потерю rich snippets.

Sitemap XML: генерируется автоматически, отправляется в GSC через день после запуска. Старый sitemap остаётся до полной переиндексации.

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

Open Graph и Twitter Card мета-теги — часто забывают при смене шаблона, страницы перестают корректно отображаться при шаринге в соцсетях.

Запуск и мониторинг первых недель

DNS propagation: переключение DNS занимает до 48 часов, планируйте запуск с запасом. Cloudflare как DNS-провайдер — propagation занимает минуты, не часы.

После запуска ежедневно мониторим: Search Console → Coverage (ошибки индексации), Analytics → органический трафик, сравнение с аналогичным периодом прошлого года, краулинг сайта на 404-ошибки.

Первые 2 недели — критический период. Если трафик падает на 30%+ — немедленный аудит редиректов и сравнение с предмиграционным краулом.

Что входит в работу

Результаты, которые вы получаете:

1. План миграции с маппингом URL и редиректов в формате Excel/Google Sheets.
2. Настроенные 301 редиректы на серверном уровне (Nginx/Cloudflare/Vercel).
3. Перенесённый контент с проверкой целостности: изображения, мета-поля, ссылки.
4. Структурированные данные (Schema.org) на новом сайте, идентичные старым или улучшенные.
5. Отчёт по SEO: динамика позиций через 1, 3 и 6 недель после запуска.
6. Мониторинг Coverage в Search Console с уведомлениями об ошибках.
7. Гарантия сохранения позиций: если трафик падает более чем на 15% в течение первого месяца — бесплатный аудит и коррекция.

Сроки и ориентиры

• Редизайн с миграцией небольшого сайта (до 100 страниц): 4–8 недель.
• Миграция e-commerce с 500+ страниц товаров: 8–16 недель.
• Только техническая часть миграции (редиректы, метаданные) без редизайна: 1–3 недели.

Стоимость рассчитывается индивидуально по объёму. Средняя экономия клиента за счёт сохранения трафика после миграции — от 300 000 до 500 000 рублей в год.

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