SEO Sprendimai | 301 peradresavimai: kas tai ir kada jų prireikia keičiant svetainę
Svetainė perkelta į naują domeną, senas adresas paliktas be peradresavimų. Po trijų mėnesių Google Search Console rodo, kad visi indeksuoti puslapiai grąžina 404 klaidas, organinis srautas nukrito 70%, o metų metais kauptos atgalinės nuorodos į senuosius URL dabar veda į niekur. 301 peradresavimų konfigūracija prireikė diegti skubiai, kai žala jau buvo padaryta.
Tokia situacija pasikartoja reguliariai, ir jos priežastis beveik visada ta pati: peradresavimai suplanuojami po migracijos, o ne prieš ją. Domeno perkėlimas, HTTPS migracija, URL struktūros keitimas ar puslapio šalinimas, kiekviena iš šių situacijų reikalauja veiksmų iš anksto. Tai techninė detalė, kuri sprendžiama per kelias valandas, jei žinote, ką daryti, arba atstatoma per kelis mėnesius, jei ją praleidžiate.
HTTP būsenos kodas 301 reiškia, kad puslapis visam laikui perkeltas į kitą adresą. Kai naršyklė ar Googlebot kreipiasi į seną URL ir gauna 301 atsakymą, sistema automatiškai nukreipiama į naują adresą ir išsaugo šį pakeitimą ateičiai.
302 kodas reiškia laikiną peradresavimą. Naršyklė nukreipiama, bet nėra instrukcijos atnaujinti žymes ar nuorodos atitikmenį. Google į 302 reaguoja kitaip nei į 301: link juice perduodamas ne taip patikimai, o naujas URL gali nebūti indeksuotas kaip galutinis.
Keičiant URL struktūrą, migruojant domeną ar šalinant senus puslapius, reikia naudoti 301. 302 tinka tik tada, kai turinys tikrai laikinai neprieinamas, pavyzdžiui, produktas laikinai išparduotas ir rodomas laikinas puslapis. 302 vietoje 301 yra klaida, kuri pasikartoja dažnai, ypač kai peradresavimus diegia žmonės, nesuprantantys skirtumo, arba kai WordPress įskiepis pagal nutylėjimą naudoja netinkamą kodą.
Domeno perkėlimas. Kiekvienas senojo domeno URL turi turėti 301 į atitinkamą naujojo domeno URL. Ne tik pagrindinis puslapis, bet kiekvienas straipsnis, kategorija ir produktas, nes kiekvienas jų gali turėti išorinių atgalinių nuorodų arba yra indeksuotas Google.
HTTPS migracija. Perėjimas nuo HTTP prie HTTPS reikalauja 301 peradresavimų nuo kiekvieno HTTP URL į atitinkamą HTTPS variantą. Dauguma hostingo tiekėjų tai automatizuoja, bet verta patikrinti, ar konfigūracija apima visus puslapius, o ne tik pagrindinį.
URL struktūros keitimas. Keičiant kategorijų struktūrą, puslapių pavadinimus ar URL formatą, seni URL turi peradresuoti į naujus. Palikti senuosius URL be peradresavimų reiškia 404 klaidas visur, kur jie buvo indeksuoti ar kur į juos veda nuorodos.
Puslapio pašalinimas. Jei šalinamas puslapis, kuris turėjo atgalinių nuorodų ar organinių pozicijų, 301 į tematiškai artimiausią puslapį išsaugo link equity. 410 kodas naudojamas tik tada, kai nėra jokio tinkamo alternatyvaus tikslo.
301 peradresavimas perduoda maždaug 90–99% link equity iš senojo URL į naująjį. Tai Google oficiali pozicija, patvirtinta John Mueller per Google Search Central Live 2021 m. Gerai suplanuota migracija išsaugo didžiąją dalį nuorodų profilio vertės.
Redirect grandinė, kai URL A nukreipia į B, o B toliau į C, kiekvienu papildomu žingsniu mažina perduodamą vertę. Grandinė iš trijų peradresavimų perduoda žymiai mažiau nei tiesioginis A į C peradresavimas, o kiekvienas papildomas žingsnis lėtina Googlebot šliaužimą ir tiesiogiai veikia crawl budget.
Redirect kilpa, kai URL A peradresuoja į B, o B grįžta atgal į A, blokuoja indeksavimą visiškai. Naršyklė tokiu atveju rodo Too Many Redirects klaidą, Googlebot sustoja. Screaming Frog identifikuoja tiek grandines, tiek kilpas per viso sito auditą, todėl tai pirmasis žingsnis prieš bet kokią migraciją.
Peradresavimo žemėlapis yra dokumentas, kuriame kiekvienam senajam URL priskiriamas tikslinis naujasis URL. Jis sudaromas prieš migraciją. Dažniausia klaida, matoma perdirdinėjant svetainės migracijas, yra ta, kad peradresavimai kuriami jau po to, kai organinis srautas nukrito, ir tai atstatymo procesą ženkliai apsunkina.
Migracijos plano minimalūs žingsniai:
Šis procesas neužtrunka savaičių, tačiau jo praleidimas dažnai kainuoja mėnesių atstatymo darbo.
Peradresavimo diegimo metodas priklauso nuo serverio tipo, ir čia pradedantieji dažnai painiojasi.
Apache serveriai (dauguma shared hostingo, įskaitant Hostinger ir daugelis lietuviškų tiekėjų) valdo peradresavimus per .htaccess failą, esantį svetainės šakniniame kataloge. Vieno URL peradresavimas atrodo taip: Redirect 301 /senas-puslapis https://jusudomenas.lt/naujas-puslapis. Masinis peradresavimas su RegEx taisyklėmis leidžia vienu įrašu aptverti šimtus URL pagal URL struktūros modelį.
Nginx serveriai naudoja rewrite taisykles konfigūracijos faile – sintaksė skiriasi, ir .htaccess ten tiesiog neveikia. Tai dažna klaida, kai svetainė perkelta nuo Apache prie Nginx serverio, o .htaccess peradresavimai nustoja veikti.
WordPress svetainėms yra paprastesnis kelias: Redirection plugin’as (Jonas Gauffin sukurtas, aktyvus nuo 2007 m.) leidžia valdyti peradresavimus per administratoriaus panelę be jokio kodo, su visų peradresavimų žurnalavimu ir 404 klaidų stebėjimu. Tai rekomenduojamas sprendimas verslams be techninės komandos.
Reikia pasakyti atvirai: 301 peradresavimai yra žalos mažinimo, ne žalos panaikinimo priemonė.
Jei senasis URL neturėjo jokių atgalinių nuorodų ir nebuvo indeksuotas – peradresavimas jam nieko neprideda. Konfigūruoti peradresavimus kiekvienam niekada neindeksuotam URL (pvz., administratoriaus puslapiams, testavimo URL) yra laiko švaistymas ir crawl budget eikvojimas.
Be to: 301 peradresavimas neatkuria organinių pozicijų automatiškai. Po migracijos Google turi pakartotinai nuskaityti, perskaičiuoti ir perindeksuoti visus peradresuotus puslapius – tai procesas, trunkantis nuo kelių savaičių iki kelių mėnesių, priklausomai nuo svetainės dydžio ir crawl budget. Tikėtis, kad pozicijos grįš per savaitę po migracijos – nelogiška. Tikėtis, kad jos grįš per tris mėnesius su tinkamais peradresavimais – realistiška.
Šis atvejis pasitaiko stulbinamai dažnai net tvarkingose svetainėse.
Jei www.jusudomenas.lt ir jusudomenas.lt rodo tą patį turinį be peradresavimo į vieną kanoninę versiją – Google gali juos indeksuoti kaip du atskirus domenus su duplikuotu turiniu. Tą pačią problemą sukuria ir https://jusudomenas.lt/puslapis/ vs https://jusudomenas.lt/puslapis (su ir be trailing slash).
Sprendimas: pasirinkite vieną kanoninę versiją – su www ar be, su trailing slash ar be – ir 301 peradresuokite visas kitas kombinacijas į ją. Canonical žyma papildomai sustiprina šį signalą HTML lygmeniu, bet negali pakeisti serverio lygio peradresavimo.
URL normalizavimas yra techninis SEO pagrindas, bet jis dažniausiai aptinkamas tik tada, kai problemos jau kyla – arba audito metu.
Jei niekada neatlikus peradresavimų audito – tai pirmas žingsnis, ir jis nereikalauja didelių investicijų.
Screaming Frog SEO Spider nemokamoje versijoje leidžia nuskaityti iki 500 URL ir identifikuoja visas 301, 302, 404 ir kitas būsenos klaidas per vieną nuskaitymą. Eksportuodami 3xx (peradresavimų) ataskaitą matote visas grandines ir galite nustatyti, ar yra ilgesnių nei dviejų žingsnių grandinių – kurias reikia sutrumpinti.
Google Search Console “Indeksavimas” → “Puslapiai” ataskaita rodo 404 klaidas, kurių Google aptiko šliaužimo metu. Jei sąrašas ilgas ir jame yra puslapiai, kurie anksčiau turėjo turinį – tai nepakonfigūruotų peradresavimų žymė.
Per artimiausias 30 dienų patikrinkite vieną dalykų, kurį daugelis atideda: ar jūsų svetainė teisingai peradresuoja HTTP → HTTPS ir www → non-www (arba atvirkščiai). Atidarykite naršyklę ir rankiniu būdu įveskite keturias versijas: http://, http://www., https://, https://www. – visas keturias. Visų galutinis adresas turi būti identiškas. Jei bent viena iš jų rodo skirtingą URL ar 404 – tai aktyvus duplikato turinio ir URL normalizavimo klausimas, kuris veikia ir vartotojo patirtį, ir organines pozicijas.
SEO Sprendimai atlieka peradresavimų auditus, sudaro migracijos planus ir konfigūruoja 301 peradresavimus Lietuvos verslo svetainėms – nuo .htaccess konfigūracijos iki WordPress plugin’ų ir serverio lygio taisyklių. Susisiekite, jei planuojate svetainės migraciją arba pastebite neaiškią pozicijų smukimo kryptį po nesenų URL pakeitimų.
