Перенесення WordPress-сайту: без даунтайму та втрат даних

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

Як мігрувати WordPress без даунтайму?

Планування починається за 48 годин: знижуємо TTL запису A до 300 секунд. Це скоротить час очікування DNS-пропагації після перемикання. Для самого перенесення обираємо один із трьох підходів:

WP-CLI + rsync у 10 разів швидший за плагіни міграції: перенесення файлів у 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 (рекомендується)

1. Експорт із джерела:

   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/
   

2. На новому сервері налаштування оточення:

   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
   

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

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

4. Заміна URL в БД:

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

   wp search-replace коректно обробляє серіалізовані дані — на відміну від ручного SQL UPDATE.
5. Тестування на новому сервері (до зміни DNS): додайте в /etc/hosts на своєму комп'ютері 1.2.3.4 new-host.com www.new-host.com. Перевірте: головна сторінка, товари/пости, форми, оплата, авторизація, зображення.
6. Зміна DNS: після перемикання чекати поширення (зазвичай 1–4 години).

Типові помилки при міграції

Що входить в роботу

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

За 5+ років досвіду та 50+ успішних міграцій ми гарантуємо цілісність даних. Економія на хостингу після оптимізації може скласти до 30%. Звертайтеся — оцінимо проект за один день.

Різні версії 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 ГБ з тестуванням і перемиканням DNS — 3–5 годин. Великий сайт з додатковими інтеграціями — 6–8 годин. Точна оцінка — після ознайомлення з проектом. Отримайте консультацію з міграції прямо зараз — це безкоштовно та займе не більше 15 хвилин.

Редизайн та міграція сайту: зміна CMS, збереження SEO

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

Чому міграції ламають 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-кеш для динамічного пошуку.

Міграція контенту з різних 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 тижні.

Вартість розраховується індивідуально за обсягом. Середня економія клієнта за рахунок збереження трафіку після міграції — суттєва сума для бізнесу.

Отримайте консультацію по вашому проекту — ми відповімо протягом дня. Замовте передміграційний аудит вашого сайту та отримайте точний кошторис з планом редиректів. Зв'яжіться з нами, щоб обговорити деталі.