„Redirect error“ Google Search Console: priežastys ir sprendimai

Ką Search Console reiškia „Redirect error“

„Redirect error“ yra viena iš priežasčių Google Search Console ataskaitos „Page indexing“ lentelėje „Why pages aren't indexed“. Ji atsiranda, kai Googlebot seka jūsų URL peradresavimą, bet taip ir nepasiekia paskirties vietos, kurią galėtų nuskaityti, todėl šiuo keliu nesuindeksuojamas nei pradinis URL, nei paskirties URL.

Ją lengva supainioti su būsena „Page with redirect“, tad aiškiai: ta būsena yra normali. Ji reiškia, kad peradresavimas suveikė: URL neindeksuojamas, nes nukreipia kitur, o Google paskirties URL vertina atskirai. „Redirect error“ reiškia, kad pats peradresavimas nepavyko.

Ją rasite skiltyje Indexing › Pages. Spustelėkite eilutę „Redirect error“, kad pamatytumėte paveiktus URL, ir naudokite Export, kad atsisiųstumėte visą sąrašą.

Dažniausios „Redirect error“ priežastys

Google „Page indexing“ ataskaitos dokumentacijoje nurodytos keturios situacijos, slypinčios už šios būsenos. Praktikoje dažnai pasitaiko dar dvi.

1. Per ilga peradresavimų grandinė

Kiekvienas URL, kuris peradresuoja į kitą, prideda šuolį. Google robotai seka iki 10 peradresavimų, kaip nurodyta Google nuskaitymo dokumentacijoje. Po to Googlebot pasiduoda, o Search Console praneša apie peradresavimo klaidą. Grandinės paprastai auga palaipsniui: taisyklė iš HTTP į HTTPS, tada www taisyklė, tada pasvirojo brūkšnio pabaigoje taisyklė, o ant viršaus dar ir svetainės migracija.

2. Peradresavimų ciklas

URL A peradresuoja į URL B, o URL B atgal į URL A (arba į bet ką, kas veda atgal į A). Grandinė niekada neišsisprendžia, todėl joks puslapis nepasiekiamas. Ciklai dažnai atsiranda iš dviejų viena kitai prieštaraujančių taisyklių, pavyzdžiui, kai viena prideda pasvirąjį brūkšnį pabaigoje, o kita jį pašalina.

3. Peradresavimo URL viršija didžiausią ilgį

Jei peradresavimo taisyklė kiekvieno šuolio metu kažką prideda prie URL, pavyzdžiui, parametrą ar kelio segmentą, adresas auga, kol viršija didžiausią URL ilgį, ir grandinė nutrūksta.

4. Blogas arba tuščias URL grandinėje

Rašybos klaida, pavyzdžiui, htp:// vietoj http://, santykinis kelias, vedantis ne ten, arba tuščia Location antraštė nutraukia peradresavimą tame šuolyje.

5. Paskirties URL, kurio Google negali nuskaityti

Jei galutinis URL užblokuotas robots.txt faile, Googlebot negali jo gauti. Patikrinkite, ar kiekvieno peradresavimo tikslą galima nuskaityti, o ne tik ar jis egzistuoja.

6. Prieštaraujančios peradresavimo taisyklės skirtingose vietose

Peradresavimai, nustatyti CMS, įskiepyje, žiniatinklio serveryje ir CDN, gali kauptis vienas ant kito arba vienas kitam prieštarauti. Viename sluoksnyje pridėta taisyklė gali grąžinti URL į kito sluoksnio taisyklę, ir būtent taip atsiranda dauguma grandinių ir ciklų.

Kaip diagnozuoti „Redirect error“

Pradėkite nuo tikslių URL, kuriuos pažymi Search Console, tada atsekite, kas nutinka užklausus kiekvieną iš jų.

Naudokite URL Inspection

Įklijuokite paveiktą URL į tikrinimo juostą Search Console viršuje. Skiltyje „Page indexing“ matyti, kada Google paskutinį kartą jį nuskaitė ir ar puslapio gavimas pavyko. Spustelėkite Test live URL, kad patikrintumėte dabartinį elgesį, nes ataskaita gali atsilikti nuo jūsų pataisymų.

Atsekite visą peradresavimo kelią

Užklauskite URL ir sekite kiekvieną šuolį. Iš terminalo:

curl -sIL https://example.com/old-page | grep -iE "^(HTTP|location)"

Išvestyje iš eilės pateikiamas kiekvienas būsenos kodas ir Location antraštė. Ieškote daugiau nei vieno šuolio, URL, kuris pasikartoja du kartus (ciklas), netaisyklingos Location reikšmės arba paskutinio atsako, kuris nėra 200.

Jei nenorite naudoti terminalo, nemokamas SEO auditas SEOcrawl AI Crawler puslapyje suskaičiuoja bet kurio URL peradresavimo šuolius, o SEOcrawl AI MCP serverio įrankis fetch_url grąžina galutinį URL, būsenos kodą ir visą peradresavimų grandinę tiesiai Claude, ChatGPT ar Cursor.

Patikrinkite galutinį atsako kodą

Įsitikinkite, kad paskutinis kelio URL grąžina 200, o ne dar vieną 3xx, 4xx ar 5xx. Kai grandinė baigiasi klaida, problema yra paskirties vietoje: skaitykite mūsų vadovus apie Not found (404) ir Blocked due to other 4xx issue.

Kaip ištaisyti kiekvieną priežastį

Sprendimas beveik visada grindžiamas ta pačia idėja: nukreipkite pradinį URL į galutinę paskirties vietą vienu švariu šuoliu.

• ›Per ilga grandinė: nukreipkite pirmą URL tiesiai į galutinį 200 URL ir pašalinkite tarpinius šuolius. Jei į tą pačią grandinę veda keli seni URL, atnaujinkite kiekvieną iš jų.
• ›Peradresavimų ciklas: suraskite dvi viena į kitą rodančias taisykles ir vieną ištrinkite arba pataisykite, kad kelias baigtųsi tikrame puslapyje.
• ›Per ilgas URL: pataisykite taisyklę, kuri vis prideda prie URL, tada patikrinkite, ar paskirties puslapis įsikelia.
• ›Blogas arba tuščias tikslas: ištaisykite rašybos klaidą ar tuščią Location reikšmę ir naudokite absoliučius URL.
• ›Paskirties URL užblokuotas robots.txt: leiskite nuskaityti paskirties URL arba peradresuokite į neužblokuotą URL.
• ›Prieštaraujančios taisyklės: laikykite peradresavimus vienoje vietoje, kad CMS, serveris ir CDN neperrašytų vienas kito.

Tada atnaujinkite vidines nuorodas, kad jos rodytų į galutinį URL, o ne į peradresuojantį, ir XML svetainės žemėlapyje nurodykite tik galutinius URL. Crawler visoje svetainėje pažymi abu atvejus: vidines nuorodas, kurios grąžina 3xx, ir svetainės žemėlapius, kuriuose yra peradresuojančių URL. Jei norite patikrinti vien svetainės žemėlapį, paleiskite jį per nemokamą svetainės žemėlapio tikrintuvą, kuris kiekvienam jame nurodytam URL patikrina būsenos kodus ir peradresavimų grandines.

Geroji peradresavimų praktika

Keli įpročiai užkerta kelią daugumai peradresavimo klaidų dar prieš joms atsirandant.

• ›Naudokite tinkamą būsenos kodą. 301 peradresavimas (arba 308) yra stiprus signalas, kad reikia indeksuoti paskirties URL: naudokite jį nuolatiniams perkėlimams. 302 peradresavimas (arba 307) yra silpnas signalas, paliekantis rezultatuose pradinį URL: naudokite jį tik laikinam perkėlimui.
• ›Rinkitės serverio pusės peradresavimus. Google seka ir momentinius meta refresh bei JavaScript peradresavimus, bet JavaScript rekomenduoja naudoti tik tada, kai serverio pusės ar meta refresh peradresavimai neįmanomi.
• ›Laikykite grandines trumpas. Idealu – vienas šuolis. Kiekvienas papildomas šuolis lėtina naudotojus, eikvoja nuskaitymo biudžetą ir prideda dar vieną gedimo tašką.
• ›Visada peradresuokite į URL, kuris grąžina 200, niekada į kitą peradresavimą.
• ›Atnaujinkite vidines nuorodas ir svetainės žemėlapius, kad jie rodytų į galutinius URL, tada Google ir lankytojai peradresavimą visiškai aplenks.
• ›Viską patikrinkite iš naujo po kiekvienos migracijos ar CMS, serverio ar CDN taisyklių pakeitimo, nes būtent tada atsiranda naujų grandinių ir ciklų.

Kaip patvirtinti pataisymą

Kai peradresavimas vienu šuoliu veda į 200 puslapį:

1. ›Paleiskite URL Inspection paveiktam URL ir spustelėkite Test live URL, kad patvirtintumėte, jog Google dabar pasiekia paskirties vietą.
2. ›Svarbiausiems URL spustelėkite Request indexing.
3. ›Ataskaitoje „Page indexing“ atidarykite problemą „Redirect error“ ir spustelėkite Validate fix, kad Google iš naujo nuskaitytų kiekvieną paveiktą URL.
4. ›Stebėkite patvirtinimo būseną. Tai gali užtrukti kelias dienas ar porą savaičių; URL dingsta iš problemos sąrašo, kai yra nuskaitomi iš naujo.

Būkite žingsniu priekyje peradresavimo klaidų

Peradresavimo klaidos retai apie save praneša. Jos atsiranda ataskaitoje „Page indexing“, o didelėje svetainėje gali likti nepastebėtos, kol nukrenta srautas. Rankinis Search Console tikrinimas kiekvienai nuosavybei yra lėtas darbas, kurį lengva praleisti.

SEOcrawl AI rodinys Indexation grupuoja jūsų URL pagal Search Console aprėpties būseną, todėl matote, kurie URL patenka į klaidos būseną, ir stebite, kaip jų skaičius kinta laikui bėgant. Paveiktus URL galite žymėti pagal taisykles, rankiniu būdu arba per MCP serverį ir dirbti su jais, kol kiekvienas bus išspręstas. Jei dirbate su DI asistentu, Google Search Console auditas vienu promptu patikrina indekso aprėptį ir kiekvienam pataisymui sukuria užduotį.

Dažniausiai užduodami klausimai

Kas sukelia „Redirect error“ Google Search Console?

Google nurodo keturias priežastis: per ilgą peradresavimų grandinę, peradresavimų ciklą, peradresavimo URL, kuris galiausiai viršija didžiausią URL ilgį, ir blogą ar tuščią URL grandinėje. Visais atvejais Googlebot negali pasiekti veikiančio galutinio puslapio.

Kaip ištaisyti „Redirect error“?

Nukreipkite pradinį URL į galutinę paskirties vietą vienu šuoliu. Pašalinkite tarpinius peradresavimus, nutraukite bet kokį ciklą ir įsitikinkite, kad paskutinis URL grąžina 200 būsenos kodą. Atnaujinkite vidines nuorodas, kad jos rodytų į paskirties URL, tada paleiskite URL Inspection ir ataskaitoje „Page indexing“ spustelėkite Validate fix.

Kas yra peradresavimų grandinė ir peradresavimų ciklas?

Peradresavimų grandinė yra peradresavimų seka, kai URL A veda į B, B į C ir taip toliau, kol pasiekiamas galutinis puslapis. Peradresavimų ciklas yra grandinė, kuri niekada nesibaigia, nes URL rodo vienas į kitą. Abu gali sutrukdyti Google pasiekti puslapį, kurį reikia suindeksuoti.

301 ar 302: kurį naudoti?

Nuolatiniam perkėlimui naudokite 301 (arba 308): Google tai laiko stipriu signalu indeksuoti paskirties URL. 302 (arba 307) naudokite tik laikinam perkėlimui, kai norite, kad paieškos rezultatuose liktų pradinis URL.

Ar „Page with redirect“ yra tas pats kaip „Redirect error“?

Ne. „Page with redirect“ reiškia, kad peradresavimas suveikė: URL neindeksuojamas, nes nukreipia į kitą puslapį. „Redirect error“ reiškia, kad Google bandė sekti peradresavimą ir taip ir nepasiekė veikiančio puslapio.

Per kiek laiko „Redirect error“ išnyksta?

Spustelėjus Validate fix, Google per kelias ateinančias dienas, kartais iki dviejų savaičių, iš naujo nuskaito paveiktus URL. Būsena atnaujinama apdorojant kiekvieną URL, todėl nereikia rankiniu būdu prašyti indeksuoti kiekvieno URL.