Kaip migruoti domeną nesugriaunant paieškos reitingų

Domeno keitimas yra vienas iš nedaugelio SEO projektų, kuriame techniškai maža klaida labai greitai gali tapti labai matoma. Trūkstamas peradresavimas, užblokuotas nuskaitymo kelias arba pamiršta kanoninė nuoroda paprastą prekės ženklo atnaujinimą gali paversti keliomis reitingų svyravimo savaitėmis.

Tam tikras judėjimas yra normalus. Paieškos sistemoms reikia laiko nuskaityti senus URL, aptikti peradresavimus, apdoroti signalus ir įtvirtinti naują domeną indekse. Tikslas nėra išvengti kiekvieno kritimo. Tikslas — padaryti migraciją nuobodžią: vienas senas URL nukreipia į vieną atitinkamą naują URL, serveris atsako aiškiai, o niekas svarbaus nedingsta.

Pradėkite nuo inventoriaus, ne nuo peradresavimo taisyklės

Dažniausia migracijos nesėkmė — laikyti ją serverio konfigūracijos užduotimi. Taip nėra. Tai informacijos architektūros užduotis, kuri galiausiai baigiasi serverio konfigūracija.

Prieš liesdami DNS, sudarykite svarbių URL sąrašą:

• URL, kurie gauna organinį srautą
• URL su išorinėmis atgalinėmis nuorodomis
• URL, kurie konvertuoja, generuoja potencialius klientus arba palaiko kampanijas
• Kanoniniai URL, šiuo metu esantys jūsų XML svetainės schemoje
• PDF, vaizdai ir atsisiunčiami failai, į kuriuos pateiktos išorinės nuorodos
• Didelės vertės seni URL, kurių gali nebūti dabartinėje navigacijoje

Kiekvienam senam URL priskirkite paskirties vietą naujame domene. Daugeliu atvejų ta paskirties vieta turėtų būti tas pats puslapis su ta pačia paskirtimi. Jei /pricing tampa https://newdomain.com/pricing, tai paprasta. Jei trys seni produktų puslapiai sujungiami į vieną naują vadovą, sąmoningai užfiksuokite šį sprendimą.

Venkite tingaus modelio: viską peradresuoti į naują pagrindinį puslapį. Tai patogu, bet prarandamas aktualumas. Tiek paieškos sistemos, tiek naudotojai tikisi, kad paskirties vieta atsakys į tą patį poreikį kaip ir pradinis URL.

Kur galite, išsaugokite URL struktūrą

Domeno migracija lengvesnė, kai keliai išlieka stabilūs. Perėjimas iš oldsite.com/blog/example į newsite.com/blog/example yra daug švaresnis nei tuo pačiu metu keisti domeną, CMS, nuorodų dalis, aplankų struktūrą ir turinį.

Kartais dizaino atnaujinimas arba CMS migracija URL pakeitimus padaro neišvengiamus. Jei taip, atskirkite sprendimus:

1. Kas keičiasi dėl to, kad keičiasi domenas?
2. Kas keičiasi dėl to, kad keičiasi svetainės struktūra?
3. Kas yra šalinama, sujungiama arba perrašoma?

Kuo daugiau kintamųjų įvedate, tuo sunkiau vėliau diagnozuoti problemas. Jei migracija svarbi, o dabartinė svetainė veikia gerai, apsvarstykite galimybę pirmiausia perkelti domeną, o dizainą atnaujinti vėliau.

Naudokite nuolatinius, vieno šuolio peradresavimus

Tikrai domeno migracijai naudokite serverio pusės 301 arba 308 peradresavimus iš senų URL į jų naujus atitikmenis. Laikini peradresavimai skirti laikinoms situacijoms. JavaScript peradresavimai, meta refresh ir „minkštieji“ peradresavimai yra silpnesni signalai ir juos lengviau sugadinti.

Jūsų peradresavimo tikslai paprasti:

• Kiekvienas svarbus senas URL grąžina nuolatinį peradresavimą.
• Kiekvienas peradresavimas veda tiesiai į galutinę paskirties vietą.
• HTTP tvarkingai peradresuoja į HTTPS.
• www ir ne www variantai tvarkomi nuosekliai.
• Peradresavimai nepriklauso nuo trapaus užklausos eilutės elgesio, nebent tai būtina.

Bloga grandinė atrodo taip:

http://oldsite.com/page → https://oldsite.com/page → https://www.oldsite.com/page → https://newsite.com/page → https://www.newsite.com/page

Galiausiai tai gali nuvesti į tinkamą puslapį, bet yra lėta, sunkiau nuskaitoma ir labiau tikėtina, kad paslėps klaidas. Siekite vieno šuolio iš kiekvieno seno varianto į galutinį naują URL.

Tikrinant veikimą, nagrinėkite tikruosius HTTP atsakymus, o ne pasikliaukite tuo, ką rodo naršyklė. Čia praverčia mūsų vadovas apie peradresavimų ir HTTP antraščių derinimą produkcinėje aplinkoje, nes naršyklės yra pernelyg mandagios: jos seka grandinę ir paslepia netvarkingas dalis.

Paruoškite DNS ir sertifikatus prieš paleidimą

DNS tiesiogiai neperduoda reitingų, bet blogas DNS gali priversti migraciją atrodyti sugedusią. Prieš paleidimo langą sumažinkite TTL reikšmes, kad pakeitimai plistų nuspėjamiau. Patvirtinkite, kad naujasis domenas turi teisingus įrašus žiniatinklio srautui, el. paštui ir visiems reikalingiems subdomenams.

Taip pat reikia galiojančių TLS sertifikatų abiem domenams. Tai lengva pražiopsoti. Senasis domenas po migracijos vis dar turi aptarnauti HTTPS peradresavimus. Jei jo sertifikatas nustos galioti, naudotojai ir nuskaitymo robotai gali susidurti su naršyklės įspėjimais dar prieš pasiekdami naują svetainę.

Jei perkėlimas paveikia el. paštą, nelaikykite to antraeiliu dalyku. Domeno keitimai dažnai sugadina SPF, DKIM, DMARC, MX įrašus, sekimo nuorodas ir transakcinį paštą. Jei norite prisiminti svarbius įrašus, žr. mūsų kūrėjams draugišką vadovą apie MX, SPF, DKIM ir DMARC.

Patikrinkite kanonines nuorodas, vidines nuorodas ir svetainės schemas

Po paleidimo naujasis domenas turėtų elgtis taip, lyg visada būtų buvę kanoniniai turinio namai.

Tai reiškia:

• Kanoninės žymos nurodo į naujus URL, o ne į seną domeną.
• Vidinės nuorodos naudoja naują domeną arba šaknies atžvilgiu santykinius kelius.
• XML svetainės schemose yra tik galutiniai, indeksuojami nauji URL.
• hreflang anotacijos, jei naudojamos, nurodo naujus URL.
• Open Graph, struktūrizuoti duomenys ir alternatyvios nuorodos yra atnaujinti.
• Robots.txt neblokuoja svarbių skyrių.

Neskelbkite svetainės schemos, pilnos senų URL, tikėdamiesi, kad peradresavimai viską sutvarkys. Svetainės schema turėtų būti URL, kuriuos norite indeksuoti, sąrašas. Po migracijos tai reiškia galutinius URL naujame domene.

Taip pat stebėkite kanoninių nuorodų prieštaravimus. Puslapis, kuris peradresuoja iš seno į naują, bet turi kanoninę nuorodą atgal į seną domeną, siunčia mišrius signalus. Paieškos sistemos paprastai gali susitvarkyti su tam tikru nenuoseklumu, bet neturėtumėte jų to prašyti.

Paleidimo dieną nekeiskite visko

Migracija jau savaime yra pakankamai didelis įvykis. Jei įmanoma, venkite ją derinti su dideliu turinio genėjimu, šablonų perrašymu, navigacijos pakeitimais, JavaScript atvaizdavimo pakeitimais arba nauju našumo profiliu.

Tai nėra prietaras. Tai derinimo disciplina. Jei po paleidimo reitingai krenta, turite žinoti, ar priežastis yra peradresavimų susiejimas, nuskaitymo prieiga, pakeistas turinys, lėtesnis atvaizdavimas, trūkstami struktūrizuoti duomenys ar kas nors kita.

Pradinį paleidimą laikykite kuo artimesnį senai svetainei, kiek praktiška. Kai naujasis domenas stabilizuosis, didesnius redakcinius ir dizaino pakeitimus darykite mažesnėmis partijomis.

Praneškite paieškos sistemoms, kas pasikeitė

Google Search Console patvirtinkite ir seną, ir naują domeną. Tada naudokite Change of Address įrankį, kai perkėlimas yra domeno lygmens pakeitimas, o turinys keliauja į naują domeną. Po paleidimo pateikite naują svetainės schemą.

Tai nepakeičia peradresavimų. Tai juos palaiko. Paieškos sistemoms vis tiek reikia nuskaitomų, nuolatinių peradresavimų, kad suprastų URL lygmens susiejimą.

Bing ir kitoms paieškos sistemoms naudokite jų webmaster tools, kur jie prieinami. Taip pat atnaujinkite vietas, kurias kontroliuojate: socialinių tinklų profilius, verslo katalogus, reklamos paskirties vietas, el. pašto paraštes, dokumentaciją, partnerių nuorodas ir kanonines nuorodas sindikuotame turinyje.

Ne visos išorinės nuorodos bus atnaujintos, ir tai normalu. Tačiau svarbiausios turėtų būti. Jei didelis partneris, programėlių prekyvietė, dokumentacijos portalas arba spaudos puslapis pateikia nuorodą į seną domeną, paprašykite atnaujinti.

Po paleidimo stebėkite tinkamus dalykus

Pirmos kelios dienos po migracijos turėtų būti aktyvios stebėsenos, o ne šventimo laikas.

Tikrinkite:

• Serverio žurnalus dėl nuskaitymo veiklos senuose ir naujuose domenuose
• 404 ir netikėtas 5xx klaidas
• Peradresavimo grandines ir ciklus
• Indeksavimo būseną Search Console
• Svetainės schemos aptikimą ir apdorojimą
• Organinius įėjimo puslapius ir užklausų modelius
• Konversijos kelius, kurie priklauso nuo senų URL
• Analitikos filtrus ir persiuntimų išimtis

Tikėkitės ataskaitų triukšmo. Kai kurie analitikos įrankiai naują domeną laiko nauja nuosavybe, nebent jie tinkamai sukonfigūruoti. Kai kurios suvestinės lygina seno domeno srautą su naujo domeno srautu ir migraciją parodo blogesnę, nei ji yra.

Paieškos matomumas kelias savaites gali svyruoti. Ko nenorite, tai modelio, kai didelės vertės seni URL nuolat nuskaitomi, bet nėra tinkamai peradresuojami, arba kai nauji puslapiai aptinkami, bet pažymimi kaip seno domeno dublikatai.

Našumo taip pat nereikėtų ignoruoti. Jei naujasis domenas paleidžiamas su sunkesniais šablonais, sugedusiu talpinimu podėlyje arba neoptimizuotais ištekliais, naudotojai migraciją gali pajusti kaip sulėtėjimą. Jei tikrinimuose naudojate Lighthouse, skaitykite rezultatus turėdami omenyje prioritetus; mūsų tekstas apie tai, kaip skaityti Lighthouse ataskaitą nepanikuojant paaiškina, kaip atskirti reikšmingas problemas nuo triukšmo.

Seną domeną laikykite ilgai

Neleiskite senam domenui pasibaigti vien todėl, kad migracija „veikia“. Laikykite jį registruotą, sertifikatus galiojančius, o peradresavimus veikiančius kuo ilgiau. Praktikoje tai dažnai reiškia metus.

Senos nuorodos ir toliau egzistuoja tinklaraščių įrašuose, žymėse, dokumentacijoje, PDF, el. laiškuose ir socialinių tinklų įrašuose. Peradresavimai yra tiltas tarp šio istorinio pėdsako ir naujo domeno. Per anksti juos išjungus, nutrūksta naudotojų keliai ir iššvaistomi sukaupti signalai.

Taip pat pasilikite peradresavimų žemėlapio ir paleidimo pastabų kopiją. Po šešių mėnesių, kai kas nors paklaus, kodėl senas URL elgiasi tam tikru būdu, džiaugsitės, kad tai dokumentavote.

<!-- tool-cta:start -->

💡 Išbandykite tai: Po perėjimo patikrinkite savo senus URL naudodami Redirect Checker, kad įsitikintumėte, jog kiekvienas jų vienu 301 peradresavimo žingsniu nukreipiamas į tinkamą naują puslapį.

<!-- tool-cta:end -->

Protingas migracijos kontrolinis sąrašas

Prieš paleidimą:

• Patvirtinkite abu domenus Search Console.
• Nuskaitykite dabartinę svetainę ir eksportuokite svarbius URL.
• Sudarykite vienas su vienu peradresavimų žemėlapį.
• Sumažinkite DNS TTL.
• Paruoškite TLS sertifikatus senam ir naujam domenams.
• Atnaujinkite kanonines nuorodas, vidines nuorodas, hreflang, struktūrizuotus duomenis ir svetainės schemas.
• Ištestuokite peradresavimus parengiamojoje arba kontroliuojamoje aplinkoje.

Paleidimo dieną:

• Įdiekite peradresavimus.
• Patvirtinkite HTTP į HTTPS elgseną.
• Ištestuokite svarbius URL pavyzdžius iš kiekvieno šablono tipo.
• Pateikite naują svetainės schemą.
• Kur tinkama, naudokite Change of Address įrankį.
• Stebėkite serverio klaidas, peradresavimo ciklus ir užblokuotus išteklius.

Po paleidimo:

• Stebėkite nuskaitymo klaidas ir indeksavimo ataskaitas.
• Kur galite, atnaujinkite svarbias išorines nuorodas.
• Lyginkite srautą pagal įėjimo puslapio paskirtį, ne tik pagal domenų sumas.
• Peradresavimus laikykite veikiančius neribotą laiką.
• Atidėkite nesusijusius dizaino atnaujinimus ar turinio eksperimentus, kol perkėlimas stabilizuosis.

Domeno migracijos nėra be rizikos, bet jas galima suvaldyti. Reitingai paprastai nukenčia tada, kai migracija siunčia neaiškius signalus: trūksta peradresavimų, pakeistas turinys, prieštaringos kanoninės nuorodos, užblokuoti nuskaitymo robotai arba pamirštas senas domenas. Suteikite paieškos sistemoms ir naudotojams aiškų žemėlapį, ir perkėlimas taps daug mažiau dramatiškas.