Kaip perkelti svetainę neprarasdami SEO pozicijų

Svetainės perkėlimas yra viena didžiausių rizikų turinti operacija skaitmeniniame rinkodaros pasaulyje. Pakeiskite domeną, pertvarkykite URL struktūrą, pereikite prie kito hostingo tiekėjo arba perstatykite naujoje platformoje, ir rizikuojate prarasti organinę paieškos eismą, kuris buvo kaupiamas metus. Google apdoroja daugiau nei 8,5 milijardo paieškų per dieną, ir daugeliui verslų organinė paieška generuoja 40-60% visos svetainės eismo. Nesėkmingas perkėlimas gali tai ištrinti per naktį.

Rizika kyla iš to, kaip paieškos varikliai supranta jūsų svetainę. Google jau yra surengusi indeksavimą jūsų puslapiams specifiniais URL, priskyrė jiems autoritetą pagal atgalines nuorodas ir vartotojų angažuotumo signalus bei rangavo pagal specifinius raktažodžius. Kai tie URL pasikeičia arba dingsta perkėlimo metu, Google turi vėl surinkti, vėl indeksuoti ir vėl įvertinti kiekvieną puslapį. Be tinkamo nukreipimų žemėlapių paieškos variklis jūsų naujus puslapius vertina kaip visiškai naują turinį be istorijos, todėl jūsų reitingai smunka atitinkamai.

„GRADAX“ padėjome sėkmingai perkelti daugiau nei šešiasdešimt svetainių, ir pastovumas yra toks: organizacijos, kurios planuoja migraciją atsižvelgdamos į SEO kaip į pagrindinį reikalavimą, atkuria savo pozicijas per keturias iki aštuonių savaičių. Ties tuo, kuris SEO traktuoja kaip antraplanį klausimą, dažnai stebimi 30-70% srauto kritimai, trunkantys šešis mėnesius ar ilgiau. Skirtumas nėra sėkmė, tai metodika. Toliau pateikiame tikslų procesą, kurį naudojame apsaugodami organinį srautą kiekvienoje migracijoje.

Kiekviena sėkminga migracija prasideda nuo išsamaus turimo turinio audito. Prieš rašydami nė vieną kodo eilutę ar konfigūruodami naują serverį, užfiksuokite kiekvieną dabartinės svetainės URL, jo srauto apimtį, raktažodžių pozicijas ir atgalinių nuorodų profilį. Tokie įrankiai kaip Ahrefs, Semrush ar Google Search Console suteikia šiuos duomenis. Eksportuokite juos į skaičiuoklę, kuri taps jūsų migracijos orientaciniu dokumentu, prie jo grįšite kiekviename proceso etape.

Tiksliai apibrėžkite perkėlimo apimtį. Ar keičiate domeną? Pereinate nuo HTTP prie HTTPS? Perkeliate nuo subdomeno į subkatalogą? Perstatote naujoje CMS? Kiekvienas scenarijus turi skirtingą riziką ir reikalauja skirtingų techninių priemonių. Paprastas hostingo perkėlimas, kai URL lieka nepakitę, yra mažiausiai rizikingas. Pilnas platformos perstatymas su nauja URL struktūra ir domeno keitimu yra didžiausias. Žinokite tiksliai, kas keičiasi, o kas ne, prieš pradėdami.

Nustatykite realistišką terminą. Skubus perkėlimas yra dažniausia SEO žalos priežastis. Mes skiriame minimum keturias savaites planavimui ir stagingui, vieną savaitę vykdymui ir keturias savaites post-perkėlimo stebėsenai. Sudėtingi perkėlimai, apimantys tūkstančius puslapių ar kelis domenus, reikalauja aštuonių iki dvylikos savaičių planavimo. Įtraukite rezervinį laiką netikėtoms problemoms, jos visada atsiranda, ir turint maržą išvengsite panikos skubotų sprendimų, kurie kenkia SEO.

Peradresavimo žemėlapis yra svarbiausias bet kokios migracijos dokumentas. Tai išsamus dokumentas, kuriame kiekvienas senas URL susiejamas su atitinkamu nauju URL naudojant 301 (pastovius) peradresavimus. Būtina apimti kiekvieną puslapį, paveikslėlį, PDF failą ir kitą turinį, kuris kada nors buvo indeksuotas ar susietas. Praleidus vieną didelės srauto turintį URL, prarandate to puslapio pozicijas, jo nuorodų autoritetą ir visus lankytojus, spustelėjančius esamas nuorodas ar užklausas.

Kurkite peradresavimo žemėlapį sistemingai. Pradėkite nuo sitemap.xml ir naršymo duomenų, kad nustatytumėte visus dabartinės svetainės URL. Susiekite juos su Google Search Console duomenimis, kad rastumėte indeksuotus URL, kurie gali nebūti jūsų svetainėje. Patikrinkite savo nuorodų profilį, kad nustatytumėte URL, į kuriuos nukreipia išorinės svetainės, šie turi autoritetą, kurį būtina išsaugoti. Didelėms svetainėms, turinčioms tūkstančius URL, naudokite taisykles pagal šablonus, kur tai įmanoma (pvz., nukreipkite visus /blog/2024/* į /insights/2024/*), papildomai taikydami individualias taisykles išimtis.

Išbandykite kiekvieną peradresavimą prieš paleisdami. Naudojame testavimo aplinką, kurioje įkeliamas visas peradresavimų žemėlapis, o robotas patikrina, ar kiekvienas senas URL teisingai nukreipiamas į naują paskirties vietą. Dažnos klaidos: peradresavimų grandinės (A nukreipia į B, kuri nukreipia į C), peradresavimų ciklai ir peradresavimai į puslapius, grąžinančius 404 klaidas. Kiekviena iš jų eikvoja nuskaitymo biudžetą, klaidina paieškos sistemas ir blogina naudotojo patirtį. Ištaisykite jas testavimo aplinkoje, o ne produkcinėje.

Migracija yra ideali proga atlikti turinio auditą ir jį patobulinti, tačiau tai reikia daryti atsargiai, kad būtų išvengta papildomų SEO rizikų. Nustatykite geriausiai veikiančius puslapius, tuos, kurie generuoja didžiausią organinį srautą, konversijas ir nuorodas, ir įsitikinkite, kad jie pereina kartu su turiniu, metaduomenimis ir vidinių nuorodų struktūra. Tai yra pajamas generuojantys ištekliai, todėl jiems reikia skirti didžiausią dėmesį perėjimo metu.

Silpniau veikiančius puslapius nuspręskite, ar migruoti, ar konsoliduoti, ar panaikinti. Puslapius su plonu turiniu, dublikatais arba nulinėmis vizitomais per pastaruosius dvylika mėnesių rekomenduojama konsoliduoti. Sujunkite jų turinį su stipresniais, išsamesniais puslapiais ir nukreipkite senus URL į konsoliduotą versiją. Tai iš tikrųjų pagerina jūsų SEO, koncentruodamas autoritetą mažesniame skaičiuje aukštos kokybės puslapių, o ne išskaidydamas jį tarp daugybės silpnų.

Išsaugokite visus on-page SEO elementus migracijos metu: pavadinimo žymas (title tags), meta aprašymus, antraščių struktūras, paveikslėlių alt tekstus ir struktūruotus duomenis. Gaila „patobulinti

Be nukreipimų ir turinio, migracijos metu reikia skirti ypatingą dėmesį keliems techninio SEO elementams. Jūsų robots.txt failas turi būti atnaujintas taip, kad atspindėtų naują URL struktūrą, ir neturėtų atsitiktinai blokuoti paieškos sistemų naršyklių prieigą prie svarbių puslapių. Matėme migracijų, kai staging aplinkoje esantis robots.txt su „Disallow: /“ buvo įdiegtas gamybos (production) aplinkoje, taip efektyviai nurodydamas Google deindeksuoti visą svetainę. Visada patikrinkite šį failą iškart po paleidimo.

Per pirmąsias valandas po paleidimo pateikite atnaujintą sitemap.xml failą „Google Search Console“ ir „Bing Webmaster Tools“. Naujasis sitemap turėtų nurodyti tik naujus URL ir neįtraukti senų URL, kurie dabar nukreipia. Tai pagreitina pakartotinį indeksavimą ir suteikia paieškos sistemoms aiškų dabartinės svetainės struktūros žemėlapį. Didelėms svetainėms rekomenduojame pateikti sitemap segmentais ir stebėti kiekvieno segmento indeksavimo būseną atskirai.

Canonical žymos reikalauja ypatingo dėmesio. Kiekviename naujos svetainės puslapyje turi būti savęs nuorodą rodanti canonical žyma, nukreipianti į jo pačio URL. Jei perkeliamos canonical žymos iš senosios svetainės neatnaujinant, jos rodytų į URL, kurie dabar nukreipia, sukurdamos painius signalus paieškos sistemoms. Taip pat atnaujinkite visas vidines nuorodos visoje svetainėje, kad tiesiogiai naudotų naują URL struktūrą, o ne remtumėtės nukreipimų grandinėmis. Vidinės nuorodos, einančios per nukreipimus, praranda šiek tiek nuorodų autoriteto kiekviename žingsnyje ir sulėtina vartotojo patirtį.

DNS migracija yra didžiausios techninės rizikos momentas bet kurioje migracijoje. Kai atnaujinate domeno DNS įrašus, kad jie nukreiptų į naują serverį, pokytis plinta per globalią DNS infrastruktūrą per kelias valandas ar dienas, priklausomai nuo TTL (laikas iki galiojimo pabaigos) nustatymų ir ISP talpyklų veikimo. Šio plitimo laikotarpiu dalis vartotojų pasieks senąjį serverį, o kiti, naująjį. Jei senasis serveris jau išjungtas, tie vartotojai matys klaidas.

Norėdami sumažinti sutrikdymus, 48 valandas prieš migraciją sumažinkite savo DNS TTL iki 300 sekundžių (penkių minučių). Tai užtikrins, kad DNS rezoliutoriai visame pasaulyje talpins jūsų įrašus tik penkias minutes, todėl perjungimas įvyks greitai, kai tik atnaujinsite įrašus. Paleiskite senąjį serverį ir teikite dabartinę svetainę dar bent 72 valandas po DNS pakeitimo, kad sugautumėte vėluojančius lankytojus. Tik patvirtinę, kad visas srautas teka į naująjį serverį, išjunkite senąjį.

Jei migruojate pas naują hostingo teikėją, kruopščiai ištestuokite naująjį serverį prieš keisdami DNS. Pilnai įkelkite svetainę naujajame serveryje naudodami laikiną URL arba hosts failo pakeitimą. Patikrinkite, ar visi puslapiai teisingai atsiveria, ar visi formų siuntimai veikia, ar SSL sertifikatai galioja, ir ar našumas atitinka jūsų standartus. DNS perjungimas turėtų būti paskutinis žingsnis, o ne pirmas, ir jis turėtų vykti be problemų, nes viskas naujajame serveryje jau yra patikrinta.

Darbai nesibaigia, kai naujoji svetainė tampa aktyvi. Pirmosios keturios savaitės po migracijos yra kritinės aptinkant ir taisant problemas, kol jos nepakenkia SEO ilgalaikiams rezultatams. Kasdien stebėkite „Google Search Console“ dėl naršymo klaidų, indeksavimo būsenos pokyčių ir reitingų svyravimų. Laikinai 5–15 % organinio srauto kritimas yra normalus per pirmąsias dvi savaites, kol Google pakartotinai naršo ir vertina jūsų puslapius. Kritimas virš 20 % arba trunkantis ilgiau nei tris savaites signalizuoja apie problemą, kurią reikia ištirti.

Sukurkite automatizuotą HTTP būsenos kodų stebėjimą visai svetainei. Naktinį naršyklės skriptą, kuris žymi bet kurį puslapį, grąžinantį 404, 500 arba netikėtą nukreipimą, tai padės aptikti problemas, kurios lieka nepastebėtos atliekant rankinius patikrinimus. Ypatingai atkreipkite dėmesį į dažniausiai lankomus puslapius ir tuos, kurie turi daugiausia atgalinių nuorodų, čia klaidos turi didžiausią poveikį. Konfigūruojame realaus laiko įspėjimus dėl bet kokio būsenos kodo anomalijų puslapiuose, kurie generuoja daugiau nei 100 vizitų per mėnesį.

Migracijos po laikotarpiu sekite savo raktinių žodžių reitingus bent jau pagrindiniams penkiasdešimčiai raktiniams žodžiams. Naudokite reitingų sekimo įrankį, kuris tikrina kasdien, o ne kas savaitę, kad galėtumėte susieti reitingų pokyčius su konkrečiais techniniais įvykiais. Jei raktinis žodis krenta, išanalizuokite atitinkamą puslapį dėl nukreipimų problemų, prarasto turinio, pasikeitusių metaduomenų arba naršymo klaidų. Dauguma reitingų kritimų po migracijos turi specifinę, identifikuojamą priežastį, kurią galima greitai išspręsti, jei pastebima laiku.

Nepaisant kruopštaus planavimo, kai kurios migracijos patiria netikėtus reitingų kritimus. Svarbiausia, reaguoti metodiniu, o ne reaktyviu būdu. Pradėkite nuo to, kad patikrintumėte, ar visi nukreipimai veikia teisingai, sugedusi nukreipimų žemėlapis yra dažniausia priežastis, kodėl po migracijos dingsta srautas. Naršykite senų URL sąrašą ir patikrinkite, ar kiekvienas URL grąžina 200 (per nukreipimą) arba teisingai pateikia turinį. Bet kuris URL, grąžinantis 404, turi būti nedelsiant nukreiptas į labiausiai atitinkantį puslapį naujojoje svetainėje.

Patikrinkite „Google Search Console“ dėl rankinių veiksmų arba saugumo problemų. Kartais migracija sutampa su „Google“ algoritmo atnaujinimu, ir tai, kas atrodo kaip migracijos sukelta žala, iš tikrųjų yra algoritminis posūkis. Palyginkite savo srauto modelius su bendrosios rinkos volatilumo duomenimis iš tokių įrankių kaip „Semrush Sensor“ arba „MozCast“. Jei platesnė paieškos aplinka yra nestabili, jūsų kritimas gali išsispręsti pats, kai algoritmas stabilizuosis.

Jei reitingai per šešias savaites nepasikeitė, sustiprinkite tyrimą. Peržiūrėkite savo atgalinių nuorodų profilį, įsitikindami, kad aukšto autoriteto nuorodos veikia tinkamai. Patikrinkite, ar jūsų tvarkomas „WordPress“ arba CMS konfigūracija nekuria dublikatinio turinio ar prieštaraujančių kanoninių žymų. Atlikite puslapio greičio ir „Core Web Vitals“ rodiklių auditą naujoje platformoje: lėtesnis svetainės veikimas mažesnės galios serveryje gali pabloginti reitingus nepriklausomai nuo migracijos problemų. Jei reikia ekspertų pagalbos nustatant užstrigusio atsistatymo priežastis, susisiekite su mūsų komanda išsamiam migracijos auditui.