Як перенести WordPress на VPS без втрати пошти
Як перенести сайт WordPress зі shared-хостингу на VPS, не втративши пошту й доступність через DNS
Перенесення WordPress зі shared-хостингу на віртуальний приватний сервер (VPS) дає більше контролю над PHP, ресурсами сервера та його конфігурацією. Але якщо сприймати перенесення як просте копіювання файлів, можуть виникнути проблеми з поштою або відвідувачі потраплятимуть не туди. Головне — відокремити сайт від інших сервісів, які вже використовують ваш домен.
Якщо ви шукаєте, як перенести WordPress зі shared-хостингу на VPS, спершу з’ясуйте, які послуги надає поточний хостинг-провайдер. Домен може бути зареєстрований в одній компанії, DNS обслуговуватися іншою, електронна пошта — третьою, а WordPress — четвертою. Переносити всі ці послуги одночасно не обов’язково.
1. Визначте межі перенесення: відокремте сайт від сервісів, які залишаться
Запишіть, де зберігаються файли й база даних WordPress, а потім з’ясуйте, хто відповідає за кожен пов’язаний сервіс. Перевірте реєстратора домену, DNS-провайдера, поштовий сервіс і додаткові послуги, наприклад CDN або сховище зображень. Деякі відомості можуть бути в панелі керування хостингом, але саме сервери імен домену та DNS-записи показують, куди насправді спрямовується трафік.
Наприклад, сайт може працювати на shared-хостингу, DNS — керуватися через Cloudflare, а корпоративна пошта — обслуговуватися Google Workspace. У такому разі для перенесення WordPress на VPS не потрібно переносити домен чи поштові скриньки. Зазвичай достатньо змінити записи, які спрямовують вебтрафік, і залишити поштові записи без змін.
Перш ніж щось змінювати, складіть простий перелік. Занотуйте поточну адресу вебсайту, сервери імен і всі відомі записи, пов’язані з поштою. Якщо не впевнені, чи стосується певний запис пошти, зверніться до поштового провайдера або перевірте його інструкції з налаштування, а не видаляйте його. Через відсутність поштового запису вхідні листи можуть перестати надходити, навіть якщо сайт працюватиме справно.
2. Перевірте залежності, які легко пропустити під час звичайного копіювання сайту
Резервна копія WordPress може містити файли сайту й базу даних, але не всі сервіси, від яких він залежить. Перевірте заплановані завдання, налаштування вихідної пошти, зовнішні сховища, перенаправлення, конфігурацію SSL та специфічні для сервера параметри. Наприклад, сайт із системою членства може використовувати заплановане завдання для завершення строку дії облікових записів, а інтернет-магазин — надсилати повідомлення про замовлення через зовнішній SMTP-сервіс.
Перевірте заплановані завдання в панелі керування хостингом і плагінах WordPress. Вбудована система завдань WordPress може запускатися під час завантаження сторінки відвідувачем, тоді як серверне cron-завдання може викликати певний скрипт за розкладом. Для кожного завдання запишіть команду, періодичність і часовий пояс. Якщо на VPS не буде відповідного cron-запису, завдання, яке на старому хостингу виконувалося щогодини, після перенесення може припинити працювати.
З’ясуйте, як сайт надсилає пошту. Запишіть, чи використовує він поштовий сервер хостинг-провайдера, SMTP-плагін або сервіс транзакційної пошти, і перевірте, з якої адреси надсилаються листи. Якщо поштовий сервер надавав старий хостинг, ті самі налаштування можуть не працювати з VPS. Уточніть у поштового провайдера, чи обмежує він підключення та чи вимагає певного способу автентифікації.
Також перелічіть зовнішні сховища й налаштування сервера. Плагін медіатеки може зберігати завантаження в об’єктному сховищі, а не в каталозі завантажень WordPress. Сайт може залежати від певної версії PHP, розширень PHP, правил перенаправлення або параметрів у файлі .htaccess. Збережіть ці відомості: спроби вгадати налаштування після запуску можуть перетворити невелику проблему сумісності на тривалий простій.
3. Налаштуйте VPS відповідно до фактичних потреб сайту
Виберіть конфігурацію VPS відповідно до реальних потреб сайту, а потім визначте, як сервер оброблятиме вебзапити. Серед поширених варіантів — Apache і Nginx, але правильний вибір залежить від поточного сайту й того, хто його адмініструватиме. Перш ніж встановлювати робоче серверне середовище, перевірте потрібну версію PHP та розширення, необхідні для коду сайту, плагінів і теми.
Налаштуйте базу даних, вебсервер і обробник PHP, а потім встановіть власників і права доступу до файлів так, щоб WordPress міг їх читати й записувати лише туди, де це потрібно. Не робіть усі файли доступними для запису лише заради того, щоб приховати помилку. Обмежте адміністративний доступ, увімкніть брандмауер і налаштуйте резервне копіювання бази даних та файлів сайту.
Перш ніж переносити робочий сайт, протестуйте VPS. Переконайтеся, що вебсервер може показати звичайну сторінку, PHP працює належним чином, а база даних приймає тестове підключення. Задокументуйте встановлені версії програм і файли конфігурації. Ці записи допоможуть з’ясувати, чому плагін поводиться інакше на новому сервері.
4. Перенесіть файли й базу даних, не змінюючи роботу поточного сайту
Створіть повну копію файлів WordPress і бази даних, залишивши початковий сайт доступним для відвідувачів. Плагін для міграції може запакувати сайт, а інструменти командного рядка чи резервна копія від хостинг-провайдера дадуть більше контролю. Який би спосіб ви не обрали, переконайтеся, що копія містить базу даних, завантаження, теми, плагіни та всі користувацькі файли конфігурації.
Якщо сайт часто оновлюється, заздалегідь продумайте, як обробити нові замовлення, коментарі чи дописи, створені після першого копіювання. Один із варіантів — створити початкову копію, перевірити її в приватному режимі, а потім повторно перенести базу даних під час короткого вікна технічного обслуговування. Для інтернет-магазину не приймайте замовлення на обох копіях: усунути дублікати або втрату даних про замовлення складніше, ніж ненадовго призупинити приймання замовлень, попередивши про це клієнтів. Такий поетапний підхід допоможе виконати перенесення сайту WordPress без втрати пошти: робоча пошта й поштові записи залишаються без змін, поки ви переносите сайт.
Перенесіть файли й базу даних на VPS, а потім за потреби оновіть у конфігурації WordPress назву бази даних, ім’я користувача, пароль і адресу сервера. Надійно збережіть старі та нові значення. Якщо змінюються домен або шляхи до файлів, обережно оновіть налаштування сайту. Масова заміна тексту може пошкодити серіалізовані дані в базі, якщо інструмент не враховує їхню структуру.
Поки що не спрямовуйте публічний DNS на VPS. Під час перевірки приватної копії публічний трафік має йти на старий хостинг, а новий сервер не повинен отримувати справжні запити від клієнтів, доки ви не будете готові перемкнутися.
5. Перевірте сайт у приватному режимі, перш ніж змінювати публічний DNS
Використайте зміну файлу hosts на своєму комп’ютері або тимчасове тестове доменне ім’я, щоб спрямувати браузер на VPS, не змінюючи публічний DNS. Зміна файлу hosts впливає лише на пристрій, де її внесено, тому це зручний спосіб перевірити новий сайт, перш ніж його побачать інші відвідувачі. Після тестування видаліть цей запис, щоб не сплутати приватний маршрут із публічним.
Перевірте і зовнішню частину сайту, і панель керування WordPress. Переконайтеся, що працюють сторінка входу, ключові сторінки, пошук, форми, завантаження файлів, перенаправлення та функції оформлення замовлення чи членства, якщо сайт їх використовує. Надішліть тестову форму й перевірте, куди надійшло повідомлення. Якщо сайт надсилає пошту, перевірте доставлення листів і папку спаму: повідомлення про успішне надсилання форми на екрані ще не означає, що лист справді надійшов.
Перевірте заплановані завдання та інтеграції, які звертаються до сайту ззовні. Наприклад, платіжний сервіс може надсилати сповіщення на певну URL-адресу, а сервіс моніторингу — очікувати конкретну відповідь. Також переконайтеся, що на VPS працює HTTPS. Тестове доменне ім’я може не відповідати робочому сертифікату, тому заздалегідь перевірте, як буде налаштовано сертифікат для робочого домену.
Перевірте перенаправлення та канонічні URL-адреси робочого домену. Якщо показник відмов високий, непрацююча цільова сторінка чи перенаправлення можуть погіршити ситуацію. У цьому посібнику пояснюється, який показник відмов на сайті вважається нормальним і як його інтерпретувати. Під час перевірки міграції зосередьтеся на конкретних збоях: наприклад, форма повертає помилку або завантажене зображення не з’являється на сайті.
6. Перемкніть DNS за планом, подбавши про пошту та можливість відкату
Перед зміною DNS збережіть поточні записи й точно зазначте, які записи сайту плануєте оновити. Якщо для сайту використовується A-запис, змініть його адресу на IP-адресу VPS. Якщо для вебпіддомену використовується CNAME, за потреби оновіть цей запис. Не змінюйте поштові записи, зокрема MX і TXT-записи для автентифікації пошти, якщо тільки ви навмисно не переносите пошту до іншого провайдера. Перш ніж починати, розберіться, як змінити DNS для сайту на VPS, не зачепивши записи, потрібні для електронної пошти.
Якщо заздалегідь зменшити час життя DNS-записів (TTL), деякі DNS-резолвери можуть швидше підхопити нову адресу, але це не гарантує миттєвого оновлення в усьому світі. Перш ніж редагувати записи, перевірте поточні налаштування DNS і рекомендації провайдера. Якщо ви користуєтеся проксі або CDN, з’ясуйте, чи має сервер-джерело вказувати безпосередньо на VPS і чи відповідає режим SSL у проксі встановленому сертифікату.
Заплануйте перемикання на час, коли зможете стежити за сайтом і реагувати на проблеми. Змініть потрібний вебзапис, а потім перевірте домен через кілька мереж або сервісів перевірки DNS. Заздалегідь підготуйте письмову інструкцію для відкату: як повернути попередню адресу сайту, хто може це зробити та як отримати доступ до старого облікового запису хостингу. Не видаляйте старий сайт, поки DNS-кеші ще можуть спрямовувати туди відвідувачів.
Під час перемикання окремо перевірте пошту. Надішліть лист із зовнішньої адреси на адресу вашого домену, а якщо можливо — дайте з неї відповідь. Якщо пошта перестала працювати, перш ніж щось змінювати, порівняйте поточні DNS-записи зі збереженою копією. Для перенесення вебсервера поштові записи видаляти не потрібно.
7. Переконайтеся, що після запуску все працює належним чином
Коли публічний трафік почне надходити на VPS, перевірте HTTPS, ключові сторінки, форми, вхід до системи та всі важливі для доходу функції. Перегляньте журнали WordPress і сервера: шукайте помилки PHP, відмови в доступі до файлів, невдалі підключення до бази даних і повторні запити до відсутніх URL-адрес. Головна сторінка може здаватися цілком справною, тоді як помилка плагіна непомітно ламає контактну форму.
Переконайтеся, що на VPS працює резервне копіювання і ви знаєте, як відновити дані. Перевірте місце зберігання копій і впевніться, що остання копія містить і базу даних, і файли. Налаштуйте моніторинг доступності сайту та строку дії сертифіката, а також перевірте, чи працює пошта в обох напрямках. Зробіть це до скасування попереднього тарифу хостингу.
Не вимикайте старий хостинг, доки новий сайт не пройде всі заплановані перевірки, а зміни DNS не набудуть чинності. Збережіть остаточну копію старих файлів і бази даних відповідно до власних правил зберігання даних. Коли VPS обслуговуватиме сайт, пошта працюватиме, а порядок відновлення буде задокументовано, можна буде вирішити, коли закрити старий обліковий запис, не гадаючи, від яких послуг він ще залежить.
