Ръководство: Миграция на уебсайт без SEO негативи

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

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

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

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

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

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

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

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

Намерили сте нова хостинг компания, регистрирали сте се, създадена ви е среда. Повечето хостинги поддържат 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','https://domain-old');
define('WP_SITEURL','https://domain-old');

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

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

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

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


UPDATE wp_options SET option_value = replace(option_value, 'https://domain-old', 'https://domain-new') WHERE option_name = 'home' OR option_name = 'siteurl';
UPDATE wp_posts SET guid = replace(guid, 'https://domain-old','https://domain-new');
UPDATE wp_posts SET post_content = replace(post_content, 'https://domain-old', 'https://domain-new');
UPDATE wp_postmeta SET meta_value = replace(meta_value,'https://domain-old','https://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 (.*)$ https://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/ https://site.com/newpage/

Идеята е да имате възможно най-малко страници, които не са покрити от редиректите. По този начин постигате две неща:

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

• Второ, Google не чака особено дълго преди да изтрие от индекса си страниците, които връщат 404 код за грешка. За него няма особено значение колко линкове има към тези страници и какъв рейтинг има.

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

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

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

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

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

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

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

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

Миграция от и към SaaS системи

Интересно странично решение са така наречените SaaS системи. Software as a Service са най-често cloud базирани софтуери или системи, при които срещу регулярно заплащане клиентът получава цялостно решение за хостинг, поддръжка, разработка (най-често), ERP, маркетинг и/или други избрани от него услуги. В най-чести случай системите са готови и като се изключи изискванията за дизайн и евентуални някои специфични изисквания, те могат бързо и лесно да покрият нуждите на потребителя. Като примери можем да посочим Shopify или Wix.

Основни предимства:

1. При използване на SaaS компаниите хостват сайта си на готова cloud платформа със свой собствен data център, където софтуерът се хоства от централния доставчик. Това намалява ресурсите за инсталация, ъпгрейд или поддръжка на системата, както и необходимостта от познания в тази сфера.
2. Достъп до данните от всякъде през браузер или приложение
3. По-лесен и бърз достъп до нови разработки
4. Стабилност, сигурност, възможност за скалиране на необходимите ресурси
5. Лесно управление и лесен достъп до данните и маркетинг услуги
6. Достъп до нови възможности за сайта или приложението

Основни недостатъци:

1. Цена за преминаване – преминаването към SaaS със запазване на данните и евентуални допълнителни необходими разработки може да е скъпо.
2. Може да е трудно да се интегрира новата система с аповете и системите, които е използвала старата.
3. Зависимост от доставчика на системата – като доставчик на услугата така и като възможности за разработка – невинаги IT специалистите, които поддържат системата имат ресурсите бързо и качествено да отговорят на промяната на нуждите на клиента.
4. Ограничения на системата – поради това че SaaS използва своя собствена система е много трудно да се правят промени или да се добавят възможности, които не са съвместими или предвидени в ядрото й.
5. Тежест на сайта – поради това че SaaS най-често се предвидени да покриват много различни изисквания, не всички от които са необходими за сайта на потребителя, ядрата им са по необходимост големи и тежки. Това може да доведе до не добра скорост. Допълнителни приложения като CDN могат да бъдат решение, но не достатъчно.
6. Промяна на начина на работа и администрация със сайта – поради това че използва свой бекенд, SaaS системата ще изисква и промяна на работата с нея.
7. Цена за опериране – въпреки че цените за хостинг и употреба SaaS са конкурентни, това не винаги важи за всички типове бизнес. Понякога е по-евтино и удобно да се използва собствена ситема, откъм поддръжка и разработка.

Как да се прецени дали SaaS е най-подходяща за определен бизнес?

1. Преценете дали платформата поддържа всички необходими изисквания на вашия бизнес – дали е съвместима с интеграциите ви, дали има всички необходими за вас и вашия бизнес възможности и дали е достатъчно гъвкава, за да може да добави това, което все няма или не поддържа.
2. Преценете дали цената за такава миграция и цената за оперирането отговарят на вашите възможости.
3. Запознайте се с промяната на backend и дали и доколко ще бъде удобно да се работи с него.
4. Сравнете избраната SaaS система с други подобни – като цена, възможности и ограничения.
5. Преценете дали ограниченията за въпросната ситема ще влияят на вашия бизнес. Например, не всички са подходящи за големи онлайн магазини или не всички поддържат изискваната скорост за новинарски сайтове.

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

Първо от SaaS към SaaS (например от Shopify към Wix или обратно). В общия случай това е необходимо поради промяна на изискванията на магазина – цена, брой продукти, индексируемост на friendly филтри, възможност за интеграция с една или друга ERP система. Миграция може да се налага заради нужда от интеграция, която старата ситема не предлага или която би била трудна (и/или скъпа) за създаване и поддръжка. В повечето случаи новият SaaS има вече изготвена система за миграция, най-малко на core елемента на данните на сайта от старата система и би се наложило работа основно по дизайна и по допълнителните интеграции.

От SaaS към Open Source (например OpenCart, Magento, Woo commerce) или обратно. Open Source са по-гъвкави от готовите SaaS решения и предлагат потенциално повече възможности. Разбира се, понякога това върви ръка за ръка с по-бавна, специализирана и скъпа разработка, както и изискване за компетентност и наличност на специалисти за миграция и поддържка. В повечето случаи SaaS системите имат готови решения за миграция на ядрото от тях и отново разработки биха били необходими основно за разширенията. В обратния случай зависи от SaaS или ОpenCart системата – някои имат готови import-export модули, в други се налага частична или пълна допълнителна разработка.

От SaaS към Custom или обрано. Custom системите обикновено са специализирани за изискванията на специфичен проект и коректно изпълнени, дават най-често най-добри резултати. Разбира се, това идва ръка в ръка със съответен скок в цена, време и изискване за компетентност на разработчиците. За тях няма готови решения за мирация и всичко трябва да се изпълни ръчно.

След като е взето решение да се мигрира към ( или от ) SaaS препоръчваме да се следват някои основни стъпки.

Планиране и подготовка

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

Миграция

След като горните стъпки са изпълнени, се преминава към миграция на съдържанието на стария сайт на новата система на създадената среда за разработка. Прехвърлят се базата данни и използваните ресурси от стария сайт, основно изображения и видео файлове, спрямо предварително изготвения метод.
След като цялото съдържание се е прехвърлило, се извършва крол на новия сайт за да се удостовери дали това е станало коректно.
Проверява се дали няма загуба на съдържание, дали няма счупени връзки и дали новопрехвърлените страници все още имат всички стари ресурси. Например дали изображенията които са имали в стария сайт все още ги има или дават 404 грешка.
Проверява се дали работят изготвените горе редиректи от старите адреси към новите (ако е възможно).
Проверява се дали работи XML sitemap на новия сайт и дали адресите в него са новите адреси.
Поправят се всички грешки установени от крола и последвалите проверки.
Превърлят се външните ресурси – таг мениджъри, GSC, GA, пиксели и други подобни, които се ползват или ще се ползват в новия сайт.

След като се установи че всичко е наред, старият сайт се спира. Пренасочва се DNS към новия адрес, променя се domain адреса на новата среда или се прехвърля към новия domain адрес.
Проверява се robots.txt файла на новия сайт – дали всички правила са коректни и дали има XML sitemap.
След като новият сайт е прехвърлен на новия адрес, се премахва noindex тага и се прави нов crawl да се установи дали не са се получили нови грешки при миграцията. Например, дали са останали линкове в него с адреси към дев версията или дали са се счупили евентуално връзки.
Прави се проверка дали работят редиректите на URL адресите от стария сайт.
Извършват се необходимите корекции, където е необходимо.

След това сайтът вече е мигриран и се наблюдава в GSC как се представя и се следи периодично за нови грешки.