Kas iš tikrųjų nutinka per svetainės migraciją
Svetainės migracija – tai vienas iš tų procesų, kurio daugelis svetainių savininkų bijo kaip ugnies. Ir ne be reikalo. Netinkamai atlikta migracija gali per kelias dienas sunaikinti metų darbo rezultatus – organinio srauto kritimas 40-60% nėra jokia retenybė, o tikra realybė, su kuria susiduria šimtai projektų kasmet.
Bet štai kas įdomu: migracija pati savaime nėra problema. Problema yra tai, kaip ji atliekama. Kai žmonės girdi žodį „migracija”, dažniausiai galvoja apie techninį procesą – perkelti failus, pakeisti domeną, atnaujinti duomenų bazę. Tačiau iš SEO perspektyvos tai yra kur kas sudėtingesnis žaidimas, kuriame kiekvienas neteisingas žingsnis kainuoja.
Šiame straipsnyje kalbėsime apie tai, kaip atlikti svetainės migraciją taip, kad „Google” ir kiti paieškos varikliai kuo mažiau pajustų pokyčius, o jūsų organinis srautas išliktų stabilus arba net augtų.
Migracijos tipai – ne viskas yra vienodai rizikinga
Pirmiausia reikia suprasti, kad „svetainės migracija” yra gana plati sąvoka. Tai gali būti:
- Domeno keitimas – pvz., iš senasvardas.lt į naujasvardas.lt
- HTTP į HTTPS perėjimas – techniškai irgi migracija, nors ir mažesnė
- URL struktūros keitimas – kai keičiasi puslapių adresai, bet domenas lieka tas pats
- CMS keitimas – pvz., iš WordPress į Drupal arba į custom sprendimą
- Subdomeno į pagrindinį domeną perkėlimas – pvz., iš blog.svetaine.lt į svetaine.lt/blog
- Kelių svetainių sujungimas – kai du ar daugiau domenų konsoliduojami į vieną
Kiekvienas iš šių tipų turi savo rizikos lygį. HTTP į HTTPS perėjimas, jei atliktas teisingai, šiandien jau beveik nebekelia problemų – „Google” tai supranta labai gerai. Tačiau domeno keitimas kartu su URL struktūros pertvarka ir dizaino atnaujinimu vienu metu – tai jau tikras SEO košmaras, kurio reikėtų vengti bet kokia kaina.
Praktinis patarimas: Jei galite, niekada nedarykite kelių didelių pokyčių vienu metu. Jei reikia keisti domeną ir URL struktūrą – darykite tai atskirais etapais. Taip bus daug lengviau identifikuoti problemą, jei kas nors nutiktų.
Prieš migraciją: auditas, kuris išgelbės jūsų gyvenimą
Viena didžiausių klaidų, kurią daro žmonės – pradeda migraciją be tinkamo pasiruošimo. „Aha, tiesiog nustatysim redirectus ir viskas” – tokia logika paprastai baigiasi ašaromis.
Prieš bet kokią migraciją būtina atlikti išsamų esamos svetainės auditą. Štai ką konkrečiai reikia padaryti:
1. Surinkite visus esamus URL
Naudokite Screaming Frog, Sitebulb arba panašų crawler’į, kad gautumėte pilną svetainės URL sąrašą. Taip pat eksportuokite duomenis iš Google Search Console – ten rasite URL, kurie iš tikrųjų gauna organinį srautą. Šie du sąrašai dažnai skiriasi, ir abu yra svarbūs.
2. Identifikuokite svarbiausius puslapius
Ne visi puslapiai yra vienodai svarbūs. Naudodami Google Analytics arba Search Console, suraskite puslapius, kurie generuoja daugiausiai organinio srauto, turi daugiausiai backlink’ų (Ahrefs arba SEMrush padės), ir yra svarbiausi konversijų požiūriu. Šie puslapiai yra jūsų prioritetas – jie turi veikti tobulai po migracijos.
3. Eksportuokite backlink’ų profilį
Ahrefs, Majestic arba Moz – pasirinkite įrankį ir eksportuokite visus backlink’us. Ypač svarbu žinoti, kurie išoriniai puslapiai nukreipia į jūsų svetainę, nes po migracijos šie nuorodos turi būti tinkamai peradresuotos.
4. Dokumentuokite meta duomenis
Title tagus, meta aprašymus, H1 antraštes, canonical tagus – visa tai turi būti eksportuota ir saugoma. Migracija yra puiki proga juos atnaujinti, bet tik jei žinote, nuo ko pradedate.
5. Patikrinkite struktūrizuotus duomenis
Schema markup, Open Graph tagai – visa tai turi būti perkelti į naują svetainę. Naudokite Google Rich Results Test, kad patikrintumėte, kas šiuo metu veikia.
301 redirectai – ne tik „nukreipk ir pamiršk”
301 redirect’as yra SEO migracijos pagrindas. Tai HTTP atsakas, kuris sako paieškos varikliams: „šis puslapis persikėlė čia visam laikui, perkelk ir visą SEO vertę.” Teoriškai skamba paprastai. Praktikoje – kur kas sudėtingiau.
Keletas dalykų, kuriuos žmonės dažnai pamiršta apie redirectus:
Redirect grandinės yra blogai. Jei URL A nukreipia į URL B, o URL B nukreipia į URL C – tai yra redirect grandinė. Kiekvienas papildomas žingsnis grandinėje sumažina perduodamą „link equity” ir lėtina puslapio įkėlimą. Visada siekite tiesioginių redirectų: A → C.
Redirect kilpos yra katastrofa. URL A nukreipia į URL B, URL B nukreipia atgal į URL A. Tai sukelia begalinę kilpą, kurios rezultatas – puslapis visai neįkeliamas. Prieš paleidžiant naują svetainę, visada patikrinkite redirectus su tokiais įrankiais kaip Redirect Checker arba Screaming Frog.
Kiekvienas svarbus URL turi turėti redirectą. Tai skamba akivaizdžiai, bet praktikoje labai dažnai pamatome situacijas, kai 80% URL peradresuoti, o 20% – pamiršti. Ypač dažnai pamirštami URL su parametrais, puslapių numeracija (/page/2, /page/3 ir t.t.) ir senosios kampanijų nukreipimo puslapiai.
Praktinis patarimas: Sukurkite Excel lentelę su dviem stulpeliais – „senas URL” ir „naujas URL”. Kiekvienam senajam URL turi būti atitinkamas naujas. Jei naujoje svetainėje nebeegzistuoja atitinkamo puslapio – nukreipkite į artimiausią kategorijos puslapį arba į pagrindinį puslapį. Geriau bet koks 301 nei 404 klaida.
Techniniai niuansai, kurie nulemia sėkmę
Redirectai yra svarbu, bet tai tik viena migracijos dalis. Yra keletas techninių aspektų, kurie dažnai lieka nuošalyje, bet gali turėti didelę įtaką SEO rezultatams.
Canonical tagai naujoje svetainėje
Po migracijos patikrinkite, ar canonical tagai rodo į teisingus URL. Labai dažna klaida – naujoje svetainėje canonical tagai vis dar rodo į senus URL arba į staging aplinką (pvz., staging.svetaine.lt). Tai gali sukelti rimtų duplikato turinio problemų.
Robots.txt ir noindex tagai
Staging aplinkoje svetainė turi būti uždrausta paieškos varikliams (robots.txt: Disallow: / arba noindex header). Tačiau po migracijos į produkciją šie draudimai turi būti pašalinti. Skamba trivialiai, bet tai viena dažniausių klaidų – svetainė paleidžiama su robots.txt, kuris blokuoja visą crawling’ą, ir savininkas stebisi, kodėl Google neindeksuoja puslapių.
XML sitemap
Nauja svetainė turi turėti atnaujintą XML sitemapą su visais naujais URL. Sitemapas turi būti pateiktas Google Search Console iš karto po migracijos. Tai pagreitins naujų URL indeksavimą.
Puslapio greitis
Migracija dažnai yra proga pakeisti hosting’ą arba CMS. Įsitikinkite, kad nauja svetainė yra bent jau tokia pat greita kaip senoji – o geriausia, greitesnė. Core Web Vitals šiandien yra oficialus Google reitingavimo faktorius, todėl lėtesnė nauja svetainė gali reikšti pozicijų kritimą net ir su tobulais redirectais.
Mobilusis optimizavimas
Google naudoja mobile-first indexing, tai reiškia, kad svetainės indeksavimas ir reitingavimas pagrįstas mobiliąja versija. Jei nauja svetainė turi problemų mobiliuosiuose įrenginiuose – tai tiesiogiai paveiks SEO.
Hreflang tagai daugiakalbėms svetainėms
Jei turite daugiakalbę svetainę, hreflang tagai turi būti teisingai sukonfigūruoti naujoje struktūroje. Tai vienas sudėtingiausių techninių aspektų, kurį rekomenduoju patikrinti su specialiu hreflang testeriu.
Migracijos diena ir pirmos savaitės – ką stebėti
Pati migracijos diena yra stresinga, bet jei pasiruošimas buvo tinkamas – ji turėtų praeiti sklandžiai. Štai kaip turėtų atrodyti migracijos dienos planas:
Geriausia migraciją atlikti antradienį arba trečiadienį, ryte (pagal jūsų tikslinės auditorijos laiko juostą). Kodėl? Nes taip turite visą darbo savaitę stebėti ir reaguoti į problemas. Penktadienio vakaras yra blogiausias pasirinkimas – jei kažkas negerai, savaitgalį gali būti sunku gauti techninę pagalbą.
Iš karto po migracijos patikrinkite:
- Ar pagrindinis puslapis įkeliamas teisingai
- Ar HTTPS veikia ir sertifikatas galioja
- Ar robots.txt neblokuoja paieškos variklių
- Ar keletas svarbiausių puslapių pasiekiami ir turi teisingus canonical tagus
- Ar Google Analytics ir Search Console kodai veikia naujoje svetainėje
- Ar XML sitemap pasiekiamas ir pateiktas Search Console
Per pirmąsias 48 valandas Google Googlebot pradės crawlinti naują svetainę ir sekti redirectus. Galite tai stebėti Search Console skiltyje „Coverage” – matysite, kaip seni URL palaipsniui pakeičiami naujais indeksuotuose puslapiuose.
Per pirmąsias dvi savaites organinis srautas gali šiek tiek svyruoti – tai normalu. Google perkainoja puslapius po migracijos, ir šis procesas užtrunka. Tačiau jei srautas krenta daugiau nei 20-30% ir nekyla atgal – tai signalas, kad kažkas negerai.
Ką stebėti kasdien pirmas dvi savaites:
- Organinis srautas Google Analytics
- 404 klaidos Search Console
- Crawl klaidos Search Console
- Indeksuotų puslapių skaičius
- Pozicijos svarbiausiems raktažodžiams
Kai kažkas eina ne taip – problemų diagnostika
Net ir geriausiai suplanuota migracija kartais susiduria su problemomis. Svarbu žinoti, kaip jas greitai identifikuoti ir spręsti.
Scenarijus 1: Srautas nukrito 50%+ ir nekyla
Pirmiausia patikrinkite robots.txt – ar jis neblokuoja paieškos variklių. Tada patikrinkite, ar svarbiausių puslapių canonical tagai teisingi. Patikrinkite, ar redirectai veikia teisingai. Naudokite Google Search Console „URL Inspection” įrankį, kad pamatytumėte, kaip Google mato konkretų puslapį.
Scenarijus 2: Daug 404 klaidų Search Console
Eksportuokite 404 klaidų sąrašą ir patikrinkite, ar šie URL turėjo redirectus. Jei ne – pridėkite juos. Ypač atkreipkite dėmesį į URL, kurie turi backlink’ų – tai prioritetiniai.
Scenarijus 3: Seni URL vis dar indeksuojami po kelių savaičių
Tai normalu pirmas 2-4 savaites. Tačiau jei praėjo mėnuo ir seni URL vis dar rodomi paieškos rezultatuose – patikrinkite, ar redirectai iš tikrųjų veikia (gali būti, kad jie buvo sukonfigūruoti tik serverio lygmeniu, bet ne visoms URL variacijoms – su ir be trailing slash, su ir be www).
Scenarijus 4: Nauji URL neindeksuojami
Patikrinkite, ar sitemap pateiktas Search Console. Naudokite „URL Inspection” įrankį ir rankiniu būdu prašykite indeksavimo svarbiausiems puslapiams. Patikrinkite, ar puslapiai pasiekiami be JavaScript – jei svetainė yra SPA (Single Page Application), gali kilti JavaScript rendering problemų.
Praktinis patarimas: Sukurkite monitoringo sistemą naudodami Google Search Console API arba trečiųjų šalių įrankius kaip Ahrefs Rank Tracker. Automatiniai įspėjimai apie staigų pozicijų kritimą leis reaguoti greitai, o ne po savaitės, kai žiūrite statistiką.
Migracija kaip galimybė, o ne tik rizika
Baigiant reikia pasakyti tai, ką daugelis SEO specialistų pamiršta paminėti: migracija nėra tik rizika, kurią reikia minimizuoti. Tai galimybė, kurią reikia išnaudoti.
Kai jau darote migraciją, turite unikalią progą sutvarkyti visus tuos techninius SEO skolinius, kurie kaupėsi metų metus. Tą URL struktūrą, kuri niekada nebuvo logiška. Tuos puslapius su duplikatu turiniu, kurie niekada nebuvo sutvarkyti. Tą lėtą hosting’ą, kurį vis atidėliojote keisti.
Geriausios migracijos, kurias esu matęs, ne tik išsaugojo esamą organinį srautą, bet ir jį padidino – būtent todėl, kad buvo išnaudotos kaip kompleksinio SEO audito ir optimizavimo galimybė.
Svarbiausi principai, kuriuos reikia įsiminti:
- Planavimas užima 70% migracijos sėkmės – neskubėkite
- Kiekvienas svarbus URL turi turėti tiesioginį 301 redirectą
- Stebėkite intensyviai pirmas 4 savaites po migracijos
- Niekada nedarykite kelių didelių pokyčių vienu metu
- Dokumentuokite viską – tai padės, jei reikės atlikti post-mortem analizę
Svetainės migracija be SEO praradimų yra visiškai įmanoma. Tai nėra magiška formulė ar slapta žinojimas – tai kruopštus planavimas, teisingas techninis įgyvendinimas ir aktyvus stebėjimas po migracijos. Žmonės, kurie praranda srautą per migracijas, dažniausiai ne nežino, ką daryti – jie tiesiog neskyrė pakankamai laiko tai padaryti teisingai. O skirtumas tarp „greitai” ir „teisingai” čia gali kainuoti mėnesius ar net metus, kol srautas atsigauna.
