Това ръководство за миграция на WordPress показва как да преместите сайт от един хостинг на друг на ръка: файловете през SFTP, базата данни през phpMyAdmin или WP-CLI, а накрая DNS. Всяка стъпка има два варианта. Първият изисква само контролен панел и SFTP клиент. Вторият е за тези, които имат SSH и искат да свършат работата с няколко команди.

Написах първата версия през 2015 г. в стария си блог. Част от съветите в нея не издържаха проверката на времето, а един от тях може тихо да счупи сайт. Затова това е пренаписана статия, а не повторна публикация.

Кога ръчната миграция на WordPress има смисъл

Плъгини за миграция като Duplicator, All-in-One WP Migration и Migrate Guru вършат добра работа за повечето малки сайтове. Ако някой от тях ви върши работа, ползвайте го. Ръчната миграция си заслужава, когато сайтът е надраснал безплатния план на плъгина или лимита за качване на новия хостинг. Тя е правилният избор и когато миграция с плъгин вече се е провалила и трябва да видите на коя стъпка.

Освен това ще разберете какво всъщност представлява една миграция на WordPress. Всеки плъгин минава през същите стъпки, само че не ги виждате.

Преди да започнете

• SFTP достъп до двата хостинга, плюс phpMyAdmin или SSH и на двата. Обикновеният FTP праща паролата ви некриптирана, затова ползвайте SFTP навсякъде, където хостингът го предлага.
• SFTP клиент. FileZilla е напълно достатъчен, но го сваляйте само от официалния сайт. За SSH не ви трябва PuTTY: Windows 10 и 11 вече имат вграден OpenSSH и командата ssh работи от всеки терминал.
• Сайтът, добавен като домейн или акаунт на новия хостинг, с празна база данни, потребител за нея и парола. Ако не знаете как, попитайте поддръжката на новия хостинг.
• PHP версията на стария сайт. В wp-admin я има в Tools > Site Health > Info > Server. Настройте новия хостинг на същата версия или на по-нова, която темата и плъгините ви поддържат.
• По-нисък DNS TTL. Ден преди преместването сменете TTL на A записа на домейна на 300 секунди. Така смяната в стъпка 9 ще се разпространи за минути, а не за часове.

Планирайте и замразяване на съдържанието. Всеки коментар, поръчка или изпратена форма, които пристигнат на стария сайт след експорта на базата, няма да ги има на новия. За блог това означава един тих час. За WooCommerce магазин означава режим на поддръжка.

1. Експорт на базата данни от стария хостинг

Без SSH: отворете phpMyAdmin, изберете базата на сайта, натиснете Export, оставете метода Quick и формата SQL и натиснете Go. Ако базата е голяма, изберете метода Custom и задайте компресия gzip. phpMyAdmin импортира .sql.gz файлове директно, а компресираният файл често е десет пъти по-малък.

Със SSH: влезте в директорията на WordPress и оставете WP-CLI сам да прочете данните за достъп от wp-config.php:

cd ~/public_html
wp db export ~/site.sql
gzip ~/site.sql

Пазете този файл и след като миграцията мине успешно. Това е вашият backup на стария сайт.

Докато сте в базата, запишете си префикса на таблиците. Таблиците се казват например wp_options и wp_posts, а частта преди options е префиксът. Ще ви трябва в стъпка 3.

2. Копиране на файловете

Без SSH: свържете се със стария хостинг през FileZilla и свалете цялата директория на WordPress. Преди това включете Server > Force showing hidden files, иначе .htaccess остава на стария сървър, а с него и пренасочванията ви и всички собствени правила. След това се свържете с новия хостинг и качете всичко в директорията на сайта. Натиснете F5, ако новите файлове не се появят в списъка.

Хиляди малки файлове се прехвърлят бавно през SFTP. Ако и двата хостинга имат File Manager в cPanel или Plesk, архивирайте директорията на стария хостинг, прехвърлете единствения файл и го разархивирайте на новия.

Със SSH можете да прехвърлите файловете директно от единия сървър на другия през собствения си компютър. Не остава архив на нито един от дисковете, а двата сървъра не е нужно да имат достъп един до друг:

ssh user@old-host "tar czf - -C ~/public_html ." | ssh user@new-host "tar xzf - -C ~/public_html"

Копирайте цялата инсталация, заедно с файловете на ядрото, вместо да сваляте нов WordPress и да добавяте само wp-content. И двата подхода работят. При пълното копие има едно място по-малко, където може да се скрие разлика във версиите.

3. Редакция на wp-config.php на новия хостинг

Отворете wp-config.php в директорията на новия сайт и попълнете базата данни, която създадохте на новия хостинг:

define( 'DB_NAME', 'new_database_name' );
define( 'DB_USER', 'new_database_user' );
define( 'DB_PASSWORD', 'new_database_password' );
define( 'DB_HOST', 'localhost' );

Проверете DB_HOST при новия хостинг, вместо да приемате, че е localhost. При managed хостинг и облачни бази данни често е отделно име на хост. Грешна стойност ви дава само „Error establishing a database connection“ и нищо друго.

По-надолу във файла проверете дали $table_prefix съвпада с префикса, който си записахте в стъпка 1. Ако не съвпада, WordPress не намира таблици с този префикс и предлага да се инсталира наново. Потърсете и абсолютни пътища, които са били нужни на стария хостинг, например в WP_CONTENT_DIR или в константа на кеширащ плъгин, и ги сменете с пътищата на новия сървър.

Със SSH WP-CLI редактира файла вместо вас:

wp config set DB_NAME new_database_name
wp config set DB_USER new_database_user
wp config set DB_PASSWORD 'new_database_password'
wp config set DB_HOST localhost

4. Импорт на базата данни

Без SSH: отворете phpMyAdmin на новия хостинг, изберете празната база, натиснете Import, посочете файла от стъпка 1 и натиснете Go. Ако phpMyAdmin го откаже като твърде голям, първо го компресирайте с gzip. Ако пак е над лимита, помолете поддръжката на хостинга да го импортира вместо вас. Повечето го правят до час.

Със SSH: качете файла и го импортирайте от директорията на WordPress. WP-CLI взема данните за достъп от wp-config.php, който току-що редактирахте. Затова стъпка 3 е преди тази:

cd ~/public_html
gunzip ~/site.sql.gz
wp db import ~/site.sql

Една грешка се среща често, когато старият хостинг е с MySQL 8, а новият с MariaDB: Unknown collation: 'utf8mb4_0900_ai_ci'. MariaDB не познава тази колация. Отворете .sql файла в текстов редактор, заменете всяко utf8mb4_0900_ai_ci с utf8mb4_unicode_ci и импортирайте отново. Тази замяна е безопасна, защото засяга дефинициите на таблиците, а не съдържанието ви.

5. Замяна на стария домейн и пътища

Пропуснете тази стъпка, ако домейнът остава същият и нищо в базата не сочи към структурата на директориите на стария сървър. В противен случай внимавайте: ако нещо се обърка при ръчна миграция на WordPress, обикновено е точно тук.

Версията от 2015 г. съветваше да отворите SQL файла в Notepad++ и да замените домейна с find and replace. Не го правете. WordPress и плъгините пазят widgets, настройки на темата и настройки на плъгини като сериализиран PHP, където до всеки низ е записана дължината му, например s:22:"http://old-domain.com/". Ако новият домейн е с различна дължина, записаната дължина вече не съвпада. WordPress не може да прочете стойността и тихо я пропуска, така че widgets, менюта и настройки на темата изчезват без нито едно съобщение за грешка.

Със SSH: WP-CLI разбира сериализирани данни. Пуснете го първо с --dry-run, което само казва колко замени би направил:

wp search-replace 'https://old-domain.com' 'https://new-domain.com' --all-tables --skip-columns=guid --dry-run
wp search-replace 'https://old-domain.com' 'https://new-domain.com' --all-tables --skip-columns=guid

Със същата команда се оправят и старите пътища на сървъра, например /home2/olduser/public_html, заменен с директорията на новия сайт. Някои плъгини пазят такива пътища за кеш, логове и качени файлове, а след преместване те сочат към директория, която вече не съществува.

Без SSH: ползвайте Search-Replace-DB на interconnect/it. Качете папката му в основната директория на сайта под случайно име, което никой няма да познае, отворете я в браузъра, пуснете пробно изпълнение и после истинската замяна. Изтрийте папката веднага след това. Ако остане на сървъра, всеки, който я намери, получава пълен достъп за запис до базата ви.

6. Тест на новия сайт преди смяната на DNS

Домейнът все още сочи към стария хостинг, но можете да кажете на собствения си компютър друго. Добавете ред в hosts файла с IP адреса на новия сървър:

203.0.113.10  example.com www.example.com

На Windows файлът е C:\Windows\System32\drivers\etc\hosts и се редактира с редактор, пуснат като администратор. На macOS и Linux е /etc/hosts. Рестартирайте браузъра, отворете сайта и го разгледайте: началната страница, няколко поста, формата за контакт, вход в wp-admin. Новият хостинг най-вероятно още няма SSL сертификат за домейна, така че на този етап очаквайте предупреждение за сертификата. Всичко останало трябва да работи.

Махнете реда, когато приключите. Иначе ще продължите да виждате новия сървър и след смяната на DNS и няма да забележите, ако самият DNS е сгрешен.

7. Права на файловете

Файловете, копирани от друг сървър, понякога пристигат с грешни права. WordPress очаква 755 за директориите и 644 за файловете. Със SSH пуснете това в директорията на WordPress:

find . -type d -exec chmod 755 {} +
find . -type f -exec chmod 644 {} +
chmod 640 wp-config.php

+ накрая подава много файлове на едно извикване на chmod, което е много по-бързо от едно извикване за всеки файл. wp-config.php съдържа паролата за базата, затова получава по-строги права. Ако след последната команда сайтът покаже бяла страница, PHP на този хостинг работи с друга група. Опитайте 600 или попитайте поддръжката коя стойност препоръчват.

Без SSH същото може да се направи с FileZilla. Щракнете с десен бутон върху директорията на WordPress, изберете File permissions, въведете 755, отметнете Recurse into subdirectories и изберете Apply to directories only. Повторете с 644 и Apply to files only.

8. Permalinks и кеш

В wp-admin отворете Settings > Permalinks и натиснете Save Changes, без да променяте нищо. Това преизгражда правилата за пренасочване и оправя повечето случаи на „404 на всяка страница освен началната“ след преместване. После изчистете кеша на кеширащия плъгин и на CDN, ако ползвате такъв.

wp rewrite flush
wp cache flush

9. Смяна на DNS

При DNS доставчика си насочете A записа на домейна и на www към IP адреса на новия сървър, а също и AAAA записа, ако имате такъв. Не пипайте MX записите, освен ако не местите и пощата. Лесно е да счупите имейла с миграция, която е трябвало да премести само сайта.

С намаления предния ден TTL повечето посетители ще стигнат до новия сървър за минути. Някои резолвъри не спазват TTL, затова пазете стария хостинг акаунт поне седмица.

10. SSL сертификат

Let’s Encrypt проверява дали домейнът сочи към сървъра, който иска сертификата, така че тази стъпка трябва да изчака смяната на DNS. Повечето контролни панели издават сертификата с едно щракване, често автоматично. Ако след това сайтът показва катинарче с предупреждение, част от съдържанието все още се зарежда през http://. Пуснете отново search-replace от стъпка 5, от http://example.com към https://example.com.

Ако след смяната браузърът покаже „Your connection is not private“, в ръководството ми как да оправите тази SSL грешка са описани обичайните причини.

11. Проверка на error log

Всеки хостинг е настроен малко по-различно и плъгин, който е работил тихо на стария сървър, може да започне да се оплаква на новия. PHP error log на хостинга обикновено е в контролния панел. За собствения лог на WordPress добавете тези редове в wp-config.php за ден-два:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Тогава грешките отиват в wp-content/debug.log, без да се показват на страницата. Върнете WP_DEBUG на false, когато приключите, защото на много сървъри лог файлът може да се прочете през уеб. Ако не можете да разберете някоя грешка, пратете я на поддръжката на новия хостинг. Това е част от услугата, за която им плащате.

След преместването

Пазете стария хостинг и dump-а на базата поне седмица. Следете error log-а, проверете дали формите за контакт още пращат имейли и отворете сайта от телефон с мобилни данни, който ползва различен DNS резолвър от домашната ви мрежа. Прекратете стария акаунт едва когато мине седмица без изненади.

А ако оставим AI агент да го направи?

Пробвах. За тази версия написах промпт за агент с достъп до shell и го пуснах с Claude Code срещу два тестови WordPress сървъра в Docker. Агентът се справи добре с първата половина. Направи инвентаризация на двата хоста, забеляза нестандартния префикс на таблиците, направи backup на базата и файловете, прехвърли файловете, попълни wp-config.php, без нито веднъж да покаже парола, и спря за одобрение там, където промптът му казваше.

После стигна до импорта на базата и защитният слой на самия Claude Code отказа да го изпълни, дори след като бях одобрил стъпката. Презаписването на база данни на отдалечен сървър е точно от действията, които тези инструменти оставят на човек. Мисля, че това е правилно, но значи, че най-рисковата стъпка в цялата миграция остава при вас. Агентът може да ви спести време с подготовката и с проверката на резултата след това. Стъпки 4 и 5 планирайте да изпълните сами.

Ако всичко това ви се струва повече, отколкото искате да поемете, да наемете някой да го направи е напълно разумен избор. Счупената миграция обикновено излиза по-скъпо от платената.