Прехвърляне на сайт на нов хостинг без прекъсване стъпка по стъпка

Собственик на малък фирмен сайт, който планира прехвърляне на сайт на нов хостинг в края на месеца, трябва да започне подготовката поне седем дни по-рано. Google съветва стойността TTL в DNS да се свали до няколко часа най-малко седмица преди преместването (Google Search Central). Тогава посетителите минават бързо към новия сървър, а старият продължава да работи паралелно, докато трафикът към него не спадне до нула.

Защо прехвърлянето на сайт на нов хостинг започва с DNS

TTL е времето в секунди, през което този, който е запитал DNS, може да пази отговора в кеша си (MDN Web Docs (Mozilla)). При голяма стойност част от хората ще отварят стария сървър дълго след като сте сменили адреса. В cPanel тази стойност стои в отделна колона в Zone Editor, до всеки запис (cPanel Documentation).

За ориентир, „няколко часа“ може да са например 3 часа, тоест 10 800 секунди по наше изчисление по данни на Google и Mozilla (Google Search Central, MDN Web Docs (Mozilla)). Седмицата преди смяната е запас, в който изтичат кешовете, запазили още старата, по-дълга стойност.

Адресът на сайта е в запис A за IPv4 и в запис AAAA за IPv6 (cPanel Documentation). При смяна на хостинга сменяте именно тях, а останалите записи пренасяте в новата зона без промяна.

Графикът на преместването в една таблица

Как да копирате файловете и базата данни

В cPanel резервното копие на домашната директория съдържа public_html и пощата за домейните на акаунта, а базите MySQL се изтеглят отделно като файл.sql (cPanel Documentation). Пълното копие не се възстановява от самия cPanel, а само от WHM, така че за него трябва да помолите доставчика. Частичните копия можете да качите и сами, например съдържанието на public_html през File Manager.

При WordPress сайт, чийто домейн остава същият, обикновено стига да копирате файловете и базата (WordPress.org). Когато на новия сървър базата има друго име или потребител, поправете wp-config.php. Ако още се чудите между споделен хостинг и VPS, първо прочетете за видовете хостинг и после плащайте.

Последния експорт на базата правете точно преди смяната на DNS. Поръчка или коментар, записани в старата база след експорта, просто няма да стигнат до новия сървър, затова за тези няколко часа спрете формите и магазина (Google Search Central, WordPress.org).

Проверка на новия сървър преди смяната на DNS

Тествайте копието на временен адрес, отворен само за вашия IP или публичен, но с noindex, за да не влезе в търсачката (Google Search Central). WordPress позволява същото, като временно смените siteurl и home в таблицата wp_options (WordPress.org). С инструмента за проверка на URL в Search Console вижте дали Googlebot стига до новия сървър и дали защитна стена или защита срещу DoS не го спира.

Потвърждението на собствеността в Search Console трябва да работи и на новото копие, независимо дали е HTML файл, мета таг или Google Analytics (Google Search Central). Ако още нямате профил, започнете от първите стъпки в Google Search Console.

SSL сертификатът и пощата при смяната

Let's Encrypt прави проверката HTTP-01 само на порт 80 и търси файл в /.well-known/acme-challenge/ (Let's Encrypt). Докато домейнът сочи към стария IP адрес, проверката отива на стария сървър, така че по наш извод сертификат по HTTP-01 на новия хостинг реално се издава чак след смяната. Пренасочванията не ѝ пречат, защото се следват до 10 подред.

Има и друг вариант. При DNS-01 добавяте TXT запис _acme-challenge, така че сертификатът може да се издаде предварително, дори wildcard, но доставчикът на DNS трябва да има API (Let's Encrypt). Ключовете за това API, оставени на уеб сървъра, сами по себе си са риск за сигурността.

Пощата често се забравя. Когато тя остава при сегашния доставчик или при външна услуга, копирайте MX записите в новата зона точно, заедно с приоритета, където 0 е най-високият (cPanel Documentation). Ако пощата се мести заедно със сайта, копието на домашната директория в cPanel съдържа и писмата, а пренасочванията и филтрите са в отделен архив (cPanel Documentation).

Денят на смяната и първата седмица

Махнете забраните в robots.txt и noindex от новото копие и едва тогава сменете DNS записите (Google Search Central). Гледайте логовете и на двата сървъра, защото заявките трябва постепенно да минат от стария към новия. Публичните инструменти за проверка на DNS показват дали доставчиците в различни страни вече виждат новия адрес.

Спадът в обхождането веднага след старта е нормален. Google описва временно намаляване, след което в следващите дни обхождането се връща, понякога над предишното ниво (Google Search Central). Отчетите за индексиране в Search Console показват дали има грешки.

Стария хостинг спрете едва когато трафикът към него е нула и никой, включително Googlebot, не разчита на него (Google Search Central). Ако домейнът има DNSSEC, при прехвърляне промените може да се разпространяват до 72 часа, а след като премахнете DS записа при регистратора, чакате поне 24 часа, преди да изтриете ключа (cPanel Documentation). По наш извод договорът със стария доставчик не бива да изтича в деня на смяната, а при DNSSEC трябва да остане поне 72 часа след нея.

Чести грешки при преместване на WordPress

Наръчникът на Google, на който се опира графикът, важи само ако адресите остават същите; при смяна на домейна редът е друг (Google Search Central). Най-често щетите идват от обикновено търсене и замяна в базата. Някои теми и уиджети пазят серийни данни заедно с дължината на текста и те се чупят (WordPress.org).

WordPress препоръчва командата search-replace на WP-CLI или специален плъгин, и то само за таблицата wp_posts (WordPress.org). Колоната GUID не се пипа в никакъв случай, иначе RSS четците ще покажат старите статии като нови.

Постоянните връзки са отделна точка. Изключете .htaccess и ги настройте наново, когато сайтът тръгне на новия сървър (WordPress.org). Временните стойности (transients) може да изчистите, но след резервно копие. За поддръжката след преместването вижте основите на WordPress, а за защитата на новата инсталация – сигурността на WordPress.