Перенесення великого WordPress-сайту відрізняється від звичайної міграції невеликого проєкту. Значний обсяг медіафайлів, велика база даних, обмеження PHP, ліміти дискового простору та нестабільне з’єднання можуть призвести до неповного копіювання або помилок під час імпорту.
Перед будь-якими змінами варто створити резервну копію файлів і бази даних та перевірити, чи можна її завантажити або розпакувати окремо. Навіть якщо сайт уже працює нестабільно, краще зафіксувати його поточний стан. Видалення старих файлів, повторний імпорт або зміна конфігурації без копії можуть ускладнити подальше відновлення.
Обсяг файлів і бази
Спочатку потрібно визначити, що саме займає найбільше місця. У WordPress значний обсяг часто припадає на каталог wp-content/uploads, резервні копії, кеш, журнали помилок і старі версії плагінів. База даних може бути відносно невеликою, але містити мільйони записів у таблицях статистики, логів або сесій.
- Перевірте загальний розмір файлів сайту та окремо папки
wp-content. - Визначте розмір SQL-дампа або експорту бази даних.
- Перевірте вільне місце на старому й новому сервері. Для розпакування архіву часто потрібен додатковий простір, іноді більший за розмір самого архіву.
- З’ясуйте обмеження хостингу: максимальний розмір завантаження, час виконання PHP-скриптів, доступну оперативну пам’ять і ліміти диска.
Не варто переносити кеші, тимчасові файли та старі резервні копії без потреби. Водночас не можна видаляти папки або таблиці навмання: серед них можуть бути медіафайли, налаштування плагінів чи дані замовлень. Якщо структура сайту незрозуміла, безпечніше спочатку скопіювати дані, а очищення виконувати вже після перевірки працездатності.
Розбиття архівів
Один великий архів може не завантажитися через ліміт веб-панелі або обрив з’єднання. У такому випадку файли доцільно розділити на частини. Найчастіше окремо переносять файли сайту, папку із завантаженнями та базу даних.
Архів можна розбити на кілька частин за розміром або логічно: наприклад, окремо підготувати wp-content/uploads, інші компоненти WordPress і базу даних. Після завантаження частини потрібно об’єднати на новому сервері та лише потім розпакувати. Просте розпакування кожної частини як самостійного архіву може створити неповну або пошкоджену структуру.
- Створіть резервну копію повного набору файлів до поділу.
- Сформуйте контрольні суми або хоча б перевірте розмір кожної частини після завантаження.
- Перед розпакуванням переконайтеся, що всі частини присутні та мають правильні назви.
- Не видаляйте вихідні архіви, доки сайт не буде перевірено на новому сервері.
Якщо хостинг не дозволяє розпаковувати великі архіви, краще не запускати повторні спроби через браузер. Численні невдалі імпорти можуть залишити частково розпаковані файли та ускладнити визначення того, які дані вже перенесені.
Командний рядок і SFTP
Для великих сайтів командний рядок і SFTP часто надійніші за завантаження через файловий менеджер. SFTP дає змогу передавати файли з відновленням з’єднання, а командні утиліти можуть працювати з архівами без обмежень браузера.
За наявності SSH-доступу адміністратор може перевірити розмір каталогів, створити архів на сервері, розпакувати його та переглянути журнали помилок. Для бази даних використовують імпорт через консольні інструменти, якщо це дозволено хостингом. Такий підхід зменшує залежність від лімітів PHP, але вимагає уважної роботи з шляхами, правами доступу та параметрами підключення.
Перед виконанням команд перевірте, на якому сервері ви працюєте, і чи не вказано випадково бойову базу даних замість тестової. Помилка в команді видалення, розпакування або імпорту може призвести до перезапису файлів чи втрати даних. Якщо немає досвіду роботи з SSH, безпечніше передати цю частину спеціалісту та надати йому окремий обліковий запис із мінімально необхідними правами.
Після копіювання потрібно перевірити власника файлів і права доступу. Надто суворі права можуть спричинити помилки запису, а надто відкриті — створити ризик несанкціонованої зміни файлів.
Тайм-аути імпорту
Тайм-аут виникає, коли сервер не встигає завершити операцію за дозволений час. Це характерно для імпорту великої бази даних, масової обробки зображень, оновлення плагінів або запуску міграційного майстра. У браузері така операція може завершитися помилкою, хоча процес на сервері частково продовжить виконуватися.
- Перевірте журнали PHP, веб-сервера та бази даних.
- З’ясуйте значення
maxexecutiontime,memorylimit,uploadmaxfilesizeіpostmax_size. - Переконайтеся, що імпорт не запускається повторно поверх неповної попередньої спроби.
- За можливості розділіть SQL-файл на менші частини або виконайте імпорт через SSH.
Збільшення лімітів PHP не завжди вирішує проблему. Обмеження можуть встановлюватися на рівні тарифного плану, веб-сервера, проксі або самої системи керування базами даних. Крім того, довший час виконання не усуває пошкодження SQL-файлу чи нестачу дискового простору.
Після імпорту бази потрібно перевірити налаштування підключення у wp-config.php, адресу сайту в таблиці параметрів і коректність заміни старого домену на новий. Масова заміна адреси звичайним текстовим пошуком може пошкодити серіалізовані дані WordPress, тому для цього краще використовувати інструменти, які враховують структуру таких записів.
Якщо після міграції сайт показує білий екран, помилку підключення до бази, нескінченне перенаправлення або втрачає стилі, не слід одразу видаляти стару копію. У складних випадках може знадобитися Відновлення сайту після перенесення на інший сервер із порівнянням файлів, конфігурації та бази даних.
Перевірка цілісності
Завершення копіювання не означає, що сайт перенесено коректно. Потрібно послідовно перевірити файли, базу даних, домен, пошту, SSL-сертифікат і роботу критичних функцій.
- Порівняйте кількість і розмір основних каталогів на старому та новому сервері.
- Перевірте наявність зображень, документів і файлів, які відкриваються через медіабібліотеку.
- Увійдіть до адміністративної панелі та перегляньте налаштування WordPress і плагінів.
- Відкрийте головну сторінку, кілька внутрішніх сторінок, пошук і форми зворотного зв’язку.
- Перевірте авторизацію, оформлення замовлення або інші функції, важливі для бізнесу.
- Перегляньте журнали помилок після навантаження та кількох переходів по сайту.
- Окремо протестуйте створення резервної копії вже на новому сервері.
Для перевірки до зміни DNS можна тимчасово використати локальний файл hosts або тестовий піддомен. Це дає змогу перевірити нову копію, не перемикаючи всіх відвідувачів одразу. Після зміни DNS варто зберігати старий сайт доступним протягом перехідного періоду, доки не буде зрозуміло, що дані, замовлення та поштові повідомлення працюють коректно.
Спеціаліст потрібен, якщо немає повної резервної копії, база даних імпортується лише частково, сайт містить критичні дані, виявлено вірус або після перенесення зникають записи й файли. У таких ситуаціях подальші експерименти на робочій копії можуть погіршити стан сайту, тому спочатку слід зафіксувати помилки та зробити доступну копію поточних даних.