Досі трапляються українські сайти, які роками працюють на хостингу в Росії – просто за інерцією. Колись так налаштували, сайт працює, і ніхто не наважується чіпати. Проблема не лише в тому, де фізично лежать дані. Такі хостинги майже не оновлюють PHP, повільніше вантажать сторінки для української аудиторії, а будь-якої миті можуть просто заблокувати доступ. Ми нещодавно переносили саме такий сайт, і цей кейс виявився показовим: майже кожен етап приніс несподіванку, про яку не пишуть у типових інструкціях. Розповідаємо чесно – що ламалось, чим це вирішувалось і чому саме такими інструментами.
Вихідні дані: усе проти нас
Сайт на WordPress, вік – близько п’ятнадцяти років. Домен у зоні .ru, хостинг у Росії на панелі ISPmanager з PHP 5.4 (версія, яку востаннє оновлювали приблизно тоді, коли виходив перший iPhone). Великий контентний проєкт: понад дві тисячі записів, майже тисяча сторінок, база даних на пів гігабайта. Завдання – перенести все на український хостинг з новим доменом .com.ua, зберегти контент, позиції в пошуку й монетизацію.
І одразу перша стіна: російський хостинг блокував підключення з українських IP. FileZilla по FTP просто відвалювалась по таймауту – з’єднання навіть не встановлювалось. Пробували SFTP на 22 порту – те саме. Підключення через VPN з нейтральною країною теж не рятувало: сервер вперто рвав з’єднання. По суті, у нас лишався тільки веб-доступ у панель через браузер – і все.
Як витягнути сайт, коли по FTP не зайти
Коли класичний шлях (FTP + експорт бази) недоступний, доводиться імпровізувати. У панелі ISPmanager, на яку вдалось зайти через браузер, провайдер вирізав половину функцій: не було ні файлового менеджера, ні вбудованих бекапів – система відповідала “функція вам недоступна, зверніться до адміністратора”. Тобто ані заархівувати файли на сервері, ані створити резервну копію штатно ми не могли.
Базу вдалось витягнути через phpMyAdmin – експортом дампа. Але й тут не без нюансу: файл на пів гігабайта завантажувався близько двох годин через нестабільне з’єднання, і його довелось качати кількома підходами, поки не зібрався повністю.
З файлами було складніше. Першим пробували плагін Duplicator – стандартний інструмент для перенесення WordPress. Але на великій базі він падав: сервер обривав збірку через нестачу пам’яті (memory_limit) і ліміти часу виконання. Помилка “Couldn’t close zip archive” на етапі пакування – класика для слабких хостингів. У безкоштовній версії Duplicator ще й не дає розділити файли й базу, щоб зменшити навантаження, – ця опція лише в Pro.
Рішенням став інший плагін – WPvivid Backup. Його ключова перевага саме для таких випадків: він ділить архів на частини по кілька сотень мегабайт і збирає бекап окремо від бази. Ми зробили копію тільки файлів (базу вже мали), і WPvivid розбив її на чотири zip-частини, які спокійно завантажились через браузер по черзі, не впираючись у ліміти сервера. Там, де Duplicator падав, WPvivid дійшов до кінця.
Ще одна деталь, яка врятувала на старті: щоб узагалі потрапити в адмінку старого сайту й поставити ці плагіни, ми додали адміністратора напряму через SQL-запит у phpMyAdmin – коли доступ до wp-admin під питанням, це найнадійніший спосіб зайти.
Розгортання на новому місці: теж не без сюрпризів
Домен .com.ua зареєстрували, український хостинг замовили, NS вказали. Далі – залити назад базу й файли. І тут виліз наступний бар’єр.
Базу на пів гігабайта phpMyAdmin відмовлявся імпортувати – впирався в ліміт часу виконання скрипта (max_execution_time). Заливка доходила до великих таблиць SEO-плагіна й обривалась. Стиснення дампа в .gz допомагало частково, але не гарантовано. Врятував власний інструмент імпорту хостера (у нормальних українських провайдерів він є) – імпорт бази через панель на рівні сервера, без обмежень phpMyAdmin. Файл залили по FTP у корінь сайту й запустили імпорт прямо звідти. Мораль: велику базу краще заливати серверними засобами, а не через веб-phpMyAdmin, і не соромитись писати в підтримку – для них це рутина на п’ять хвилин.
Далі – хитрість із розгортанням файлів. Формат WPvivid вручну архіватором не зібрати (усередині вкладені архіви), тому відновлювати треба тим самим плагіном. Але плагін працює всередині робочого WordPress, а ставити чистий WordPress не можна – він затер би вже залиту базу. Вихід: поставили чистий WordPress на окрему тимчасову базу, у ньому підняли WPvivid, відновили файли з чотирьох частин, а потім у wp-config.php переключили сайт на основну базу з контентом. Тимчасову базу потім просто видалили.
Приховані пастки, про які мовчать типові чек-листи
Стандартна інструкція закінчується на “перевірили, все працює”. У реальності саме тут для багатьох сайтів усе тільки починається.
Старий код і новий PHP говорять різними мовами. Коли ми переключили PHP зі старого 5.4 на сучасну версію, сайт одразу впав з критичною помилкою. Причина ховалась у двох рядках коду теми, якій більше десяти років: вкладена тернарна конструкція без дужок і місце, де після відкриваючого тега PHP забракло пробілу. У старому PHP це мовчазне попередження, у сучасному – фатальна помилка, яка кладе весь сайт. Побачити таке “на око” неможливо. Тимчасове рішення – відкотити версію PHP на проміжну (7.4), де код ще працює, а вже потім спокійно чистити тему. Саме тому перевірка сумісності теми й плагінів – не формальність для галочки.
Заміна домену в базі – це не “знайти й замінити”. Після переїзду сайт скрізь посилався на старий домен: у налаштуваннях, у тексті записів, у шляхах до картинок. WordPress зберігає частину даних у серіалізованому вигляді, і груба SQL-заміна їх ламає. Правильний інструмент – плагін Better Search Replace, який коректно обробляє серіалізовані дані. На цьому сайті він зробив понад чотирнадцять тисяч замін старого домену на новий по всій базі. Нюанс: свіжа версія плагіна вимагала новішого PHP, тому під нашу тимчасову 7.4 довелось ставити стару сумісну версію – її можна скачати в розділі “попередні версії” на wordpress.org.
Заміна в базі не чіпає файли теми. Частина посилань на старий домен виявилась захардкодженою прямо в шаблонах теми (header.php та інші), а також – окремим сюрпризом – у контенті головної сторінки виявились сторонні рекламні вставки, які колись додав попередній розробник. Знайти все це допомогло звичайне “Знайти в файлах” у Notepad++ по папці теми та SQL-запит з умовою LIKE по контенту. Висновок: після масової заміни обов’язково перевіряйте вихідний код сторінки на залишки старого домену.
Google не “переїжджає” разом із сайтом. AdSense, Search Console, прив’язка до Google-акаунтів – усе доводиться підтверджувати заново для нового домену: окремий файл ads.txt, окрема верифікація власності, окремий запис у Search Console. Добра новина для монетизації: баланс AdSense прив’язаний до акаунта, а не до сайту, тому накопичені кошти при переїзді не зникають – але новий домен треба заново додати на перевірку й дочекатись схвалення, і лише потім вмикати перенаправлення зі старого.
Немає доступу до старого сервера – теж не привід зупинятись. 301-редиректи зі старих адрес, які передають пошукову вагу на новий домен, можна налаштувати навіть без доступу до .htaccess – через невеликий плагін прямо з адмінки. Головне – тримати старий домен активним ще півроку-рік, поки Google переіндексує сайт за новою адресою.
Головне – не поспішати з останнім кроком
Найбільше сайтів “ламається” не під час копіювання файлів, а на етапі перемикання домену й перевірки після нього. Пропустиш перевірку форм, забудеш про редиректи, не проконтролюєш заміну домену в базі – і втратиш або заявки, або напрацьовані позиції в пошуку. А відновлювати це довше, ніж від початку зробити правильно.
Окремо варто закласти запас часу на “хвіст” після переїзду: тимчасова просадка трафіку на кілька тижнів під час зміни домену – це нормально, головне – не панікувати й дати Google переіндексувати сайт.
Якщо ваш сайт досі на застарілому чи російському хостингу і ви хочете перенести його без ризику для позицій у Google – розкажіть нам деталі. Ми вже проходили весь цей шлях, включно з заблокованим доступом, базою на дві години й падінням на новому PHP – і знаємо, де підстелити соломку. Деталі на сторінці Створення сайтів.
