Смяната на хостинг не изисква непременно нов дизайн или нови адреси. Посетителят може да продължи да отваря същите страници, докато зад тях вече работи друг сървър. Трудната част е да се прехвърлят всички зависимости и да не останат нови поръчки, снимки или писма само на старото място.
Планът по-долу е за запазен домейн и същите публични адреси. Ако едновременно променяте структурата, използвайте и ръководството за редизайн и пренасочвания. Разделете двете задачи, за да е ясно коя промяна е причинила евентуален проблем.
Какво всъщност трябва да преместите
Поискайте списък на услугите, преди да прекратите стария абонамент. Домейнът, DNS управлението, уеб хостингът и пощата могат да са при четири различни доставчика. Фактурата за един от тях не означава, че той управлява всичко.
| Част | Какво проверявате | Как изглежда завършената задача |
|---|---|---|
| Файлове | Тема, разширения, качени снимки, сървърни правила | Новият сървър има необходимите версии и права |
| База данни | Съдържание, настройки, потребители, поръчки | Копието е от договорения момент |
| Домейн и DNS | Кой може да променя записите | Има достъп и запазени предишни стойности |
| Поща | Къде са кутиите и как изпраща сайтът | Получаване и изпращане се проверяват отделно |
| Външни услуги | Плащания, куриери, графици, задачи по разписание | Известно е кои настройки зависят от сървъра |
При WordPress файловете сами по себе си не са достатъчни. Официалното ръководство за миграция разглежда отделно преместването със запазени адреси и това със смяна на домейна. Не променяйте адресите в базата само защото хостингът е нов.
Подгответе копието, преди да насочите посетителите
Новата среда трябва да поддържа нужната версия на PHP, базата, разширенията и необходимите сървърни функции. Поискайте проверка на конкретния сайт, а не само уверение, че планът „поддържа WordPress“. Стара тема може да създаде проблем при различна версия на PHP.
Използвайте отделна тестова среда с ограничен достъп. Тя не бива да изпраща реални клиентски известия, да приема плащания или да изпълнява автоматични задачи като работещия сайт. За проверка с истинския домейн разработчикът може временно да насочи само своя компютър към новия сървър. Това не е публична DNS промяна.
Проверете представителни страници: начало, услуга или продукт, снимки, търсене и администрация. Отворете ги през HTTPS и проследете дали ресурси още се теглят от стария адрес. Проверете формата в изолирания режим и настройките ѝ за получател. При магазин включете вариантите, количката и правилата за доставка, без реално плащане.
Запазете пощата като отделна задача
Условен пример: фирмата премества WordPress от хостинг А към хостинг Б, но служителите продължават да използват същата външна поща. Променя се маршрутът към сайта; MX записите не се заменят автоматично с тези на хостинг Б. Ако се сменят и DNS сървърите, необходимите пощенски записи трябва да присъстват в новата зона.
Запазете стойностите за MX, SPF, DKIM и DMARC и ги сверете с доставчика на пощата. Проверете и как сайтът изпраща писма: новият сървър може да няма същите разрешения или настройки. Cloudflare описва пощенските записи, но точните стойности зависят от услугата, която използвате.
Реален пример за тази зависимост е обработката на запитвания в DrNiki: прегледаният код използва PHP mail(). Копирането на страниците не доказва, че нов сървър ще изпраща по същия начин. Това е пример от кода, не твърдение за извършена миграция. Подробната проверка е в ръководството за липсващи имейли от форма.
Уговорете момента на прехвърляне
При сайт с редки редакции последното копиране може да е лесно. При магазин нови поръчки се записват непрекъснато. Уточнете период за ограничаване на записите или друг надежден начин за последно синхронизиране. Иначе старият и новият сървър могат да започнат да събират различни данни.
Запишете кой разрешава публичната промяна и кой я извършва. Той трябва да знае кои точно DNS записи променя, какви са старите стойности и кога е направено последното копие. По-нисък TTL, зададен предварително, може да съкрати живота на кеширани записи; не означава, че всички посетители ще преминат едновременно.
Не премахвайте стария хостинг веднага. Google препоръчва наблюдение на стария и новия сървър и спиране на стария, когато трафикът действително е преминал. Проверете също дали тестовите ограничения или noindex не са останали на публичната версия.
Определете кога се връщате назад
Планът за връщане не е само „ще върнем DNS“. Ако новият магазин вече е приел поръчки, връщането към стара база може да ги скрие. Първо трябва да се запазят новите записи и да се реши как ще бъдат пренесени. Това решение се уточнява преди преместването.
Приемете конкретни основания за спиране: недостъпна основна страница, счупено поръчване, липсващи снимки или отказ на критична интеграция. Запазете старите настройки и проверено резервно копие. Не изтривайте новата среда, докато се изяснява причината.
Предаването приключва с кратък отчет: кои адреси са проверени, кога е сменен DNS, как е проверена пощата и кой наблюдава следващия работен ден. Добре извършеното преместване има доказуеми проверки и възможност за реакция, без обещание за абсолютно нулев риск или автоматично по-добри позиции.
Често задавани въпроси
Трябва ли да прехвърля домейна при новия хостинг?
Не непременно. Регистрацията на домейна и уеб хостингът са отделни услуги. Важното е да имате достъп до DNS управлението и ясен план за необходимите записи.
Достатъчно ли е началната страница да се отваря?
Не. Проверете вътрешните страници, снимките, администрацията, формите и важните интеграции. При магазин включете и данните, записани около момента на преместването.