Reading Time: 15 minutes

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

Дошло е време. Сега, освен ако не сте решили, че е време сайтът да се премести на Великия небесен сървър (или в определено мазе в Александрия), извършването на една миграция на уебсайт изисква определена работа, особено ако искате да запазите максимално натрупаните от сайта позиции в мрежата. Каква точно ще е тя зависи от това каква миграция искате да направите.

Преди да започнете каквато и да е миграция

Първо,  силно ви препоръчваме да направите цялостен бекъп на сайта си – цялостен архив на файловете и архив на базите данни. Изтеглете го и на локална машина допълнително, ако имате такава възможност.
export DB

Отделно изведете основните си конфигурационни файлове за по-нататъчна справка. Сканирайте сайта си, с каквито тулове разполагате, преминете през Google Search Console, за да съхраните данните, класирания и връзки. Специално внимание отделете на sitemap.xml файла (файловете му). Ако имате възможност, направете му и един SEO Анализ, за да определите слабостите в оптимизацията му, които евентуално може да бъдат поправени при една миграция.

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

Archive website

Миграция към нов хостинг

Решили сте да смените хостинга си по някаква причина. Една такава миграция се състои обикновено от две части – прехвърляне на самия сайт и прехвърляне на връзката към него. Повечето хостинг компании имат услуга, чрез която самите те да извършат прехвърлянето на сайта ви на прилична цена. Ако не сте сигурни в уменията си, препоръчваме ви да я използвате. Ако искате да извършите прехвърлянето ръчно, това са основните стъпки, които се предприемат.

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

В противен случай изчакайте да пренасочите записите си или да прехвърлите домейна за след установяването на файловете. Така когато DNS сървърите променят записите си, новите ще сочат към новоустановения ви сайт и прехвърлянето може и да не се усети (ако е извършено коректно).

База данни

Първо трябва да качите базата си от данни (независимо дали е mysql или postgers), за да избегнете евентуални конфигурациони проблеми (особено ако системата на сайта ви е по-чувствителна).

Създайте база данни и потребител към нея (съгласувайте правата). По възможност се постарайте да съответстват на тези използвани на предишния ви хостинг. Ако не е възможно, не е голям проблем. Просто отбележете разликите. След това влезте в съответния инструмент за работа с този тип база данни (phpMyAdmin или phpPgAmdin), избирате така създадената база данни и импортнете е нея .sql файла, съдържащ базата ви данни, който изтеглихте като бекъп по-рано.

Ъплоуд на файлове

След като сте качили базата си от данни трябва да прехвърлете файловете на сайта си на новото им място. Ако това е основният домейн като потребител, то най-вероятно това е папката /public_html . Ако не то точното местоположение ще зависи от това как сте настроили (или планирате да настоите) вашия addon домейн.

След като сте установили къде трябва да отидат файловете ви следва да ги качите. Има редица начини да го направите, обикновено се използва FTP клиент за тази цел. В зависимост от това как сте запазили файлове при вас може да се наложи да ги разархивирате. Когато сте готови следва да редактирате конфигурационните си файлове.

За WordPress това е основно файлът wp-config.php в главната ви директория. Ако сте успели да създадете базата данни и потребителя, така че те да съответстват на предишните, не ги пипайте. В противен случай нанесете промените в

define(‘DB_NAME’, ‘ ‘);
define(‘DB_USER’, ‘ ‘);
define(‘DB_PASSWORD’, ‘ ‘);

Ако използвате различна система файла и командите може да са различни, но принципът ще е същия.

Полезно:

Ако сайтът ви е на WordPress и желаете да си спестите всички тези главоболия, можете да използвате плъгина All-in-One WP Migration.

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

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

След като сте качили файловете и данните си,и сте ги свързали сайтът ви е готов да бъде пуснат от новия си дом. Ако сайтът ви има инсталиран SSL сертификат на стария хостинг, прехвърлете и него или го инсталирайте повторно на новото място. Уверете се, че сте копирали htaccess и robots.txt файловете си.

Ако все още не сте прехвърлили NS записите си (или домейна си), сега е времето да го направите.

Ако сте се справили успешно с горните инструкции, след миграцията сайтът ви ще се е прехвърлил на новия си хостинг, запазвайки старата си url структура. По този начин запазвате придобитите SEO резултати до този момент, както свързаните с търсещите машини, така и тези, постигнати през социалните мрежи.

Миграция към нов домейн

Проверка на домейна, преди каквото и да било действие

Преди да започнете да правите една миграция към ново име на сайта си, ще е добре да проверите домейна, на който ще искате да прехвърлите сайта си дали не е използван преди и ако е как и на какво е ранквал, както и какъв авторитет е имал домейнът. Има различни инструменти с които може да извърши една такава проверка, SemRush е идеален за целта.

Ако домейнът е чист/ не е бил използван до този момент, това няма да има SEO последици. В повечето случаи когато един собственик на уебсайт реши да смени името на сайта си, той търси такъв, понеже иска единствено самият той да бъде разпознаван с този бранд или това име. Може обаче да се окаже, че името на новия домейн преди това е било използвано от друга фирма, дори и в друга част на света и този домейн е натрупал известна история.

Преди да решите да се прехвърлите на един такъв домейн, проверете го внимателно и определете показателите му, проверете как се е класирал, на кои ключови думи, от кои и от какви сайтове има линкове, какви анкор текстове сочат към него, чрез Ahrefs. Ако тези ключови думи, сайтове и линкове са тематично свързани със сайта, който искате да мигрирате на това име, това може да ви донесе SEO ползи. Ако обаче не са, и особено ако има натрупани линкове от сайтове с лош авторитет, това може сериозно да навреди на класиранията ви за много дълъг период от време.

След миграцията на нов домейн – спад в позициите ще има!

Друго нещо, което трябва да имате предвид, когато се готвите да извършите миграция към нов домейн е това, че едно такова действие обезателно ще се отрази негативно на класирането ви, макар и временно. Докато Google и другите търсачки отбележат промяната, актуализират данните си и се приспособят към промените ще забележите значително влошаване на резултатите си, както и на трафика генериран към сайта ви. Това е временно, нормално и се случва всеки път когато се извършва такава промяна. При правилно извършена такава промяна обаче времето за възстановяване и нивото на спад може значително да се понижи.

Разбира се може да сте решили да преместите сайта си на домейн, като например такъв за тестване, разработка на нов дизайн или функционалност и не искате да прекъсвате работата на сайта си или да навредите на SEO оптимизацията си. Тогава новият домейн (или поддомейн) задължително ще трябва да бъде блокиран да не се индексира или обхожда от роботите. Удобен начин да се осъществи това е добавянето на

User-agent: *
Disallow: /

в robots.txt файла в главната му директория както и на noindex, nofollow таг в head частта на кода му.

Миграция към нов домейн в няколко стъпки

Преди да започнете една такава миграция подсигурете се с цялостен бекъп на сайта си, както описахме в началото. След това ще трябва да решите как да направите въпросната миграция. Основно има два начина – единият е по-лесен, другият по-сигурен.

Разликата се състои основно в това дали искате (и можете) файловете и базата данни на сайта ви да останат на същото място. Това може да се постигне само, ако старият и новият ви домейн се хостват на едно и също място и ако използвате CPanel на един и същ акаунт (т.е. можете да направите настройките на домейна си така че да използват една и съща папка). Това би било по-лесният начин. Тогава ще трябва да правите необходимите промени във файловете и база даннните си на текущия ви сайт.

Ако нямате такава възможност, или просто ако решите да се подсигурите срещу евентуални проблеми (което е според нас е препоръчително) тогава новият ви домейн ще се намира на друго място и ще се наложи да мигрирате файловете и базата си данни там. Ако сте се подсигурили новият ви домейн да е регистриран на същия хостинг акаунт, тогава създайте нов addon domain за него и му задайте основна папка за дестинация различна от тази на стария ви домейн (примерно /public-html/domain-new/). След това копирате съдържанието на папката съдържаща текущия ви сайт (заедно със всички подпапки и техните файлове) във въпросната папка.

Работа с инструментите на хостинг доставчика

Чрез phpMyAdmin или съответния му phpPgAdmin вариант правите копие на текущата си база данни с ново име. Ако искате да използвате същия DB потребител за новия домейн трябва да настроите привилегиите  на новата база данни за него. Ако не, създайте нов потребител и му дайте на него права върху нея. Редактирайте конфигурационните файлове на копираната инсталация, така че да използва новата база данни. При WordPress това е wp-config.php. Редактирайте полетата.


define('DB_NAME', ' ');
define('DB_USER', ' ');
define('DB_PASSWORD', ' ');

Когато намерите тези полета

define('WP_HOME','http://domain-old');
define('WP_SITEURL','http://domain-old');

редактирайте ги така, че да отразяват новия домейн.

Ако новият сайт не е на същия хостинг акаунт – то тогава мигрирате файловете и базата си данни както описахме в „миграция към нов хостинг“.

След като файловете ви са качени в папката на новия домейн и базата данни e свързана с тях, следва да направите съответните корекции в тях, така че те да отговарят на новия домейн. Това значи да обходите базата си данни и да замените всяка инстанция, в която има „http://domain-old“ с „http://domain-new„. Това, разбира се са примерни имена, заменят се съответно с имената на стария и новия ви домейн. Също http може да трябва да бъде сменено с https, ако сайтовете ви имат (и/или ще имат) инсталиран SSL сертификат. Същото трябва да се направи и с всички файлове – да се провери кои и къде в тях го има стария домейн и да бъде заменен с новия.

Ако използвате WordPress и имате достъп до phpMyAdmin или достъп до конзола то съответните SQL команди ще извършат основната замяна:


UPDATE wp_options SET option_value = replace(option_value, 'http://domain-old', 'http://domain-new') WHERE option_name = 'home' OR option_name = 'siteurl';
UPDATE wp_posts SET guid = replace(guid, 'http://domain-old','http://domain-new');
UPDATE wp_posts SET post_content = replace(post_content, 'http://domain-old', 'http://domain-new');
UPDATE wp_postmeta SET meta_value = replace(meta_value,'http://domain-old','http://domain-new');

Миграция на WordPress уебсайт с плъгин

Друг начин е да използвате плъгин като  WP Migrate Pro да мигрирате базата си данни, ако не се чувствате удобно да редактирате ръчно.
Или както при миграцията към нов хостинг можете просто да направите чиста инсталация на WordPress на новия домейн и чрез EXPORT/IMPORT функцията на All-in-One WP Migration да мигрирате целия сайт с базата данни, съдържание и файлове, спестявайки си повечето от работата, описана по-горе. Плъгинът ще отрази автоматично разликите в имената на домейните, където ги открие в базата данни. За статичните файловете ще се наложи да отбележите промените ръчно. След така направените промени сайта ви вече трябва да се отваря на новия си адрес.

След като сайтът ви е прехвърлен на новото място обърнете внимание на системните файлове robots.txt и .htaccess в основната му папка. В тях също ще трябва да нанесете промяната на домейна на всяко място, където се среща името на стария.

При една такава миграция е важно да се запази URL структирата на сайта с подходящи 301 редиректи. Правилно извършени редиректи ще подсигурят запазването на връзките (вътрешни и външни) към стария ви сайт и така посетителите му да бъдат отведени до правилното място на новия, така че това да не доведе до загубата им, както и на класиране в търсачките.
Начин да се извърши това е добавянето на подобен код или негов вариант:


RewriteEngine On
RewriteCond %{HTTP_HOST} ^domain-old.com$ [OR]
RewriteCond %{HTTP_HOST} ^www.domain-old.com$
RewriteRule (.*)$ http://domain-new.com/$1 [R=301,L]

 

в htaccess файловете си. Ще трябват минимални промени, ако например новият ви домейн има инсталиран SSL или ако искате новият домейн да се сервира с www.

Google Search Console и миграциите на сайтове

След като редиректите ви са готови, идва времето да уведомите Google за направените промени. Това се осъществява през Google Search Console. След като влезете успешно в него, избирате сайта си и потърсете в лявото меню Change of Address под Configuration. Там – под „Add and verify your new site to Webmaster Tools“ трябва да въведете новия си адрес и да го верифицирате, за да знае Google, че сте извършили трансфер към нов домейн и той следва да предприеме необходимите действия, за да запази класирането ви, доколкото може.

След това следва да отразите преместването и отделните профили на сайта си в социалните мрежи, ако използвате API в неговите връзки, ще ви трябва и нов Google Analytics код.

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

Миграция към нов дизайн

Ако един сайт се задържи достатъчно дълго в мрежата, неизбежно идва времето, когато собственикът му го поглежда и решава, че визията му е вече остаряла или че на сайта му е необходимо да се преработи, за да може да изпълнява допълнителни или различни функции. Решава се, че е необходим Нов Сайт. Тук обаче идва и деликатният момент, че един Нов Сайт обикновено води и до ново SEO – появява се сериозната опасност да загубите почти всички SEO ползи, които старият ви сайт е натрупал през историята на съществуването си. За да се избегне това има някои действия, които могат да се предприемат.

Нов дизайн или надграждане над стария?

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

От гледна точка на SEO всяка страница, натрупала някаква положителна история, е добре да се запази, или най-малкото да се запази URL адресът й. Това важи за всеки елемент на един сайт, който е бил индексиран. Ранкингът на един сайт зависи от ранкинга на всички елементи, които го съставят, и ако част от тези елементи изчезнат, тежестта която са натрупали и дават на сайта ви също ще изчезне. За да намалите влиянието на този фактор, се препоръчва при една такава миграция да се запази максимално от URL структурата на сайта. Частите, които сте решили че не ви трябват, трябва да се пренасочат с redirect 301 към адреси, които да поемат функцията им, съобразявайки се с тематичността на съдържанието им.

Затова преди да се извърши една такава миграция старият сайт трябва да се обходи внимателно, да се запише адресната му структура, линковете и ресурсите, които са индексирани на него (изображения, видео файлове, документи).

Ако сте взели решението да запазите възможно повече от сайта си, следва да мигрирате негово копие на нов хостинг за преработка (забранен за индексация).  Ако сте решили да запазите може би само по-важната част от URL структурата, части от съдържанието или определени ресурси, тогава прехвърлете само тях. Или можете да започнете от нула, ако искате да започнете начисто или по някаква причина това се налага – загуба на сайта ви, загуба на достъп до хостинга му,  ексцентричност на програмистите …

Добре, минало е определено време, имате новия сайт, изготвен на някакъв тестов сървър и сте достатъчно доволни от резултата. Време да го пуснете в действие. Преди да започнете самата миграция е необходимо да се извършат определени действия, за да може тя да мине възможно по-гладко и да се минимизира отражението й върху SEO оптимизацията на сайта.

На новия сайт изтеглете адресната структура – през сайтмапа или през други инструменти, без значение.

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

След като сте сравнили URL адресите на сайтовете си, отбележете техните съответствия и разлики. Препоръчително от SEO гледна точка е да промените на новия сайт адресите си, така че те да отговарят на тези на стария, където е възможно. От друга страна, ако адресите на старите страници не са USER FRIENDLY или просто не съществуват в новия сайт, тогава бихме ви препоръчали да изготвите таблица, която да отразява възможно най-близките им съответствия (например блог постове от преди пет години сте решили да не бъдат мигрирани, тогава тяхно съответствие би било по-късни постове по темата или просто страницата на блога).

След като имате така изготвения списък следва да създадете и въведете необходимите редиректи в htaccess файла на новия си сайт, преди да сте започнали миграцията. Прост пример за един такъв редирект:

Redirect 301 /oldpage/ http://site.com/newpage/

Идеята е да имате възможно най-малко страници, които не са покрити от редиректите. По този начин постигате две неща. Първо – след преместването на сайта всеки линк към старите страници, през търсачките или през други сайтове, ще бъде бързо и плавно прехвърлен към новите страници и така няма да губите трафик. Второ – Google има навика да не чака особено дълго преди да изтрие от индекса си страниците, които връщат 404 код за грешка. Няма особено значение за него колко линкове има към тези страници и какъв й е рейтинга.

При така направен редирект ботът получава съобщение, че страницата е преместена за постоянно на ново място и съответно търсачката ще преиндексира връзката към новия линк и ще прехвърли ранкинга й към новата страница (обикновено) стига разбира се съдържанието на старата страница (повече или по-малко) да се е запазило и да няма нови On-Page грешки на нея.

Причината да съветваме да запазите възможно повече от оригиналната URL структура е да имате възможно най-малко на брой отделни редиректи. Всеки един такъв редирект увеличава големината на htaccess файла, което съответно затруднява ботовете и съответно преиндексирането на сайта. Всяка страница, която запази стария си адрес, е страница, която не е необходимо да се пренасочва, да се преиндексира и освен това липсата на пренасочвания намалява големината на веригата от пренасочвания (redirect chain), която може да се получи за отделните страници.

След като имате така редактирания htaccess файл, можете да преминете към самото мигриране. То може спокойно да се извърши по начина описан в „мигриране към нов домейн“. Причината е ,че освен ако сайтът ви не се изработва на тестов сървър с DNS описващ домейна му само за разработчите, то той ще има име на домейна си различно от името на сайта, който трябва да замести.

Ако пък той наистина е инсталиран на такъв сървър, то тогава миграцията ще се извърши по метода описан в „мигрирани към нов хостинг„. Разликата тук, обаче, е че няма да е необходимо да се нанасят корекции на NS записите. Разбира се, ако това е случаят, то вие най-вероятно вече знаете всичко описано дотук и дори можете да спорите по въпроса (моля пестете развалените домати).

При така извършена миграция към нов дизайн допълнителните действия, след като сайтът бъде вече онлайн са за щастие малко. След като запазвате домейна си допълнителни действия в Google Search Console няма да бъдат необходими. Хубаво би било да обходите списъка на връзките към сайта си и може би да нанесете съответните редакции в сайтовете, от които ги получавате. Ако не можете, или не желаете, редиректите в htaccess файла ще извършват необходимите пренасочвания автоматично и ще запазят доколкото е възможно ефекта на тези връзки.

Презентация: Как да не изгубим SEO след миграция или нов дизайн?

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

Ето основните:
1. Документация от разработчиците – В България се случва много рядко разработчиците да изготвят такава документация, още по-рядко да я предоставят, но ако можете – изисквайте я. Ако знаете кое и как е направeно, после по-бързо и лесно ще поправите възникналите бъгове.

2. Поддържайте връзка с разработчиците. Изгответе си въпросник на елементите на сайта ви, които имате съмнения как са направени (ако не са ви дали горната документация) и поискайте да го попълнят.

3. Убедете се че имате robots.txt файл и че той е конфигуриран правилно.
4. Направете същото за XML сайтмапа ви. Има значителна опасност старият да е останал на сайта или след миграцията новият да се е прехвърлил с адресите на разработването. Регенерирайте го наново, ако не ви затруднява.
5. Можете да качите наново XML Sitemap в Google Search Console. Проверете наново сайта си през нея. В първите няколко седмици проверявайте отново и често – там първо ще се отразят SEO спадовете.
6. Проверете страниците си дали имат Title и Meta Description тагове, и дали те са правилно генерирани. Това е доста често допускан пропуск при правене на нов дизайн и може да навреди на SEO оптимизацията ви.
7. Убедете се, че имате един H1 заглавен таг на всяка страница. Правилно конфигурирани H2, H3 и т.н. тагове са бонуси, но ги използвайте йерархично.
8. Сканирайте за хакове и слабости в защитата на новия сайт.
9. Уверете се, че имате достъп до Cpanel, FTP, web admin на сайта си с максимални права. Ще е голям проблем да намерите грешка и да не можете да я поправите.
10. Убедете се, че сайтът ви има правилно настроен редирект от http към https, ако имате инсталиран SSL сертификат, за да избегнете страниците с дублирано съдържание.
11. Убедете се, че страниците ви не носят Noindex / Nofollow тагове. Случва се след миграция разработчикът да забрави да махне атрибутите забраняващи на ботовете да обхождат страниците ви. Те са много необходими по време на разработка, но могат да навредят сериозно на SEO кампанията, ако не се махнат след като сайтът е пуснат.

Сканиране с няколко инструмента

До сега не сме открили инструмент, който да открива всички възможни грешки, макар някои като SemRush да са доста подходящи.

След сканирането, обърнете специално внимание на някои допълнитени проблеми

1. Да предположим, че вече сте сигурни в URL структурата си. След нея се уверете, че Hreflang връзките на сайта ви са налични и правилно изпълнени. Този пропуск може сериозно да събори международното индексиране на сайта ви.
2. Уверете се, че Canonical таговете както и Prev и Next релациите на новия сайт не са пропуснати, за да избегнете дублирани заглавия и мета в архивите си, както и проблеми със съдържанието и индексирането им.
3. Проверете скоростта на сайта си през различните инструменти (Google Page Speed и GTMetrix например). Лоши резултати могат на навредят на класирането ви.
4. Уверете се, че страниците ви са правилно маркирани по {Schema.org} и {Open Graph}.
5. Проверете линк сока и анкорите на вътрешните си връзки спрямо стария си сайт. Прегледайте кода си (CTR + U)

Дори един сайт да се изпълнява добре и да не отчита грешки, пак е възможно да се намерят малки слабости в кода, които сериозно да му навредят.

Ето някои:
1. Дублирани менюта (случва се понякога когато сайта има десктоп и мобилна версия, които на теория са разделени).
2. Скрити тесктове, сайтбарове и друг код, който излишно натоварва HTML ви и може да доведе до дублирано съдържание.
3. Като стана въпрос за дублирано съдържание, уверете се, че в кода ви няма такова.
4. Убедете се, че нямате твърде много h6 тага. На теория те имат много нисък ефект, но търсачките все пак ги приемат за заглавни тагове. Поради това, не е добре да се прекалява с броят им по страниците на сайта.
5. Уверете се, че нямате твърде много излишен html код в сайта си. Колкото по-малък е сайтът, толкова е по-бърз и съответно по-добре се класира.
6. Уверете се, че можете да достигнете до всеки пост и страница с максимум от 4 клика.
7. Убедете се, че дизайнът ви не е копиран. Google обича уникалния дизайн.

След миграция

Без значение кой вид миграция се извършили, след нея ще последва период на тестване. В този период влиза и отстраняване на бъгове и евентуални редакции по сайта ви. Следете класирането си, трафика и внимавайте за грешки.

Желаем ви успех!