Kaks-kolm ümbersuunamist indekseerimist ei riku, aga igaüks maksab päringu
Googlebot läbib kuni 10 ümbersuunamist järjest, mistõttu leht kahe-kolmeosalise ahela taga indekseerub tavaliselt. Kahju on teisel kujul: iga lüli on eraldi päring serverile ja lisaring ootamist inimese jaoks. Google'i saidi kolimise dokumentatsioon aga palub hoida ahela mitte pikema kui 3 lüli ja igal juhul alla 5.
Kui ma 12. oktoobril 2026 selle skeemi enda saidi peal läbi jooksutasin, oli adlab.ee pikim tee 4 ümbersuunamist.
Google'i piirid: 10 ümbersuunamist lehtedel, 5 robots.txt-il
Kolm numbrit Google'i dokumentatsioonist, kontrollitud 12. oktoobril 2026, määravad, kus ahel on lihtsalt üleliigne ja kus juba ohtlik.
| Mida küsitakse | Piir | Mis edasi saab |
|---|---|---|
| Tavaleht, Googlebot | kuni 10 ümbersuunamist | ahela läbimine katkeb; millist staatust Search Console'is näed, dokument ei täpsusta |
| robots.txt | vähemalt 5 ümbersuunamist | fail käsitletakse kui 404: roomamispiiranguid pole, Disallow-reegleid ei rakendata |
| Saidi kolimine, soovitus | mitte üle 3, igal juhul alla 5 | ahel pikendab kasutaja ooteaega ja kõik brauserid ei pea pikki ahelaid vastu |
Robots.txt rida on neist ohtlikum. Piir on viis, aga fail asub sageli samade reeglite taga (http → https ja www → ilma www), mis kogu saidil. Kui selle peale lisandub veel vana ümbersuunamine eelmiselt domeenilt, läheb ahel kergesti üle viie lüli, Disallow-reeglid lakkavad kehtimast ja suletud jaotised roomatakse. Mida sellesse faili üldse panna, olen kirjutanud artiklis sitemap.xml-ist ja robots.txt-ist.
Veel üks reservatsioon koodide kohta. Google'i jaoks on 301 ja 308 tugev signaal, et lõpp-URL peaks saama kanooniliseks, 302 ja 307 aga nõrk. Kuidas ta ajutist ümbersuunamist ahela keskel kaalub, dokumentatsioon ei ütle ja ma ei oska arvata: ahelates, mida parandan, jätan alles ainult 301 või 308.
Kuidas ahel elavas saidis välja näeb: neli reeglit, neli lüli
Siin on, mida adlab.ee vastab ümbernimetatud artikli vanal aadressil, kui tulla http://www ja kaldkriipsuga lõpus. Mõõtmine 12. oktoobrist 2026, iga lüli on kood 308.
Iga reegel on eraldi vaadates õige. Kaks esimest lüli, protokoll ja host, tuleb majutusplatvormilt (päistes on Server: Vercel), mitte minu rakenduse koodist. Kolmanda, kaldkriipsu aadressi lõpus, eemaldab Next.js. Neljas on rida minu failis next.config.mjs: artikkel seo-mebelnogo-magazina-estoniya-2017 kolis eestikeelsele slug'ile eesti-mooblipoe-seo-liiklus-kasvas-3x ja vana aadress viib uuele ühe reegliga. Neid nelja lüli kokku liita mul pole kuhugi: kolm neist pole minu koodis.
Minu võimuses on aadressid, millele viidatakse. Kontrollisin: adlab.ee sitemap.xml-i 141 aadressist vastavad kõik 141 esimesel päringul koodiga 200, ühtegi ümbersuunamist pole. Fail robots.txt aadressil http://www.adlab.ee/robots.txt läbib 2 ümbersuunamist, mis on alla piiri 5. Serverilogidest ma seda ei kontrollinud, seega ei tea ma, kas Googlebot üldse neljalüliselt teelt tuleb. Kättesaadav on see ainult vanas vormis välise lingi kaudu.
Ahela hind on mõõdetav. Viis curl-mõõtmist minu arvutist andsid otsese aadressi puhul 0,12–0,17 s ja kolme 308-ga tee puhul 0,23–0,42 s. See pole laboratoorne test, üks masin ja üks võrk. Suurusjärk on aga näha: iga lüli lisab ühe tiiru serverini ja tagasi.
Kust ahelad tulevad
Ahel kasvab kihtide kaupa: adlab.ee peal on 4 reeglit kirjutatud eri ajal ja eri kohtades. Igaüks, kes reegli lisab, vaatab enda ees olevat aadressi, mitte kogu teed. Sama mehhanism töötab igal ajalooga saidil, aga klientide kohta valimit mul pole, seega sagedusi ei nimeta. Kihte on neli:
- Protokoll ja host: http → https ning www-st ilma www-ta. Kaks lüli, mis on igal saidil ja mis iseenesest on normaalsed.
- Kaldkriips ja suurtähed: CMS või raamistik viib aadressi ühtsele kujule ja see on veel üks lüli.
- Struktuurimuutus: jaotis nimetati ümber, vanad aadressid viivad uutele, aasta hiljem nimetati uuesti ümber, aga esimese korra reeglit ei uuendanud keegi. Tulemus on
A → B → Cseal, kus peaks olemaA → C. - Domeenivahetus: vana domeen suunab vahedomeenile, see uuele. Kuidas selliseid sabasid kolimisel kokku pannakse, olen lahti seletanud veebilehe kolimise kontrollnimekirjas.
Kuidas kõik ahelad üles leida
Ühe aadressi kontrollib üks käsk. Lipp -L käib ümbersuunamised läbi (--max-redirs 15 katkestab viieteistkümnendal, Googlebot peatub kümnendal), -w trükib ümbersuunamiste arvu ja lõppaadressi.
curl -sIL --max-redirs 15 -o /dev/null -w '%{num_redirects} %{url_effective} %{http_code}\n' http://www.example.com/old-page/
Kogu sitemap'i kontrollib tsükkel. --max-redirs 0 keelab ümbersuunamisi järgida, nii et vastuseks jääb iga aadressi esimene kood: kõik, mis pole 200, on parandamise kandidaat.
curl -s https://example.com/sitemap.xml | grep -o '<loc>[^<]*</loc>' | sed 's/<[^>]*>//g' \
| while read u; do curl -s -o /dev/null --max-redirs 0 -w '%{http_code} %{url_effective}\n' "$u"; done \
| grep -v '^200'
Kui väljund on tühi, nagu minul, on sitemap puhas. Kui seal on 301 ja 308, pole parandus ümbersuunamistes, vaid sitemapis endas: sinna peavad sattuma ainult lõppaadressid, lähemalt artiklis duplikaatlehtedest.
Kogu saidi jaoks on vaja roomajat. Screaming Frog'is on see aruanne Reports → Redirects → Redirect Chains: see näitab ahela algust, iga lüli ja lõppu ning kohe on näha, millistel lehtedel on algusele viitavad lingid. Search Console'is vaata aruandes „Lehtede indekseerimine“ staatust „Ümbersuunamisega leht“: see on loetelu sellest, mille Google leidis ümbersuunamise taga, mitte valmis ahelate nimekiri, aga selle järgi on näha, kust otsida.
Kontrolli eraldi neli kohta, kuhu ahela algus kõige sagedamini satub: robots.txt (piir seal on vaid 5 ümbersuunamist), sitemap.xml, canonical ja hreflang. Hreflang-link ümbersuunatud aadressile, nagu hreflangi artiklis analüüsisin, katkestab keeleversioonide vahelise seose vaikselt.
Mis järjekorras parandada
- Kirjuta välja iga ahela lõpp: lõppaadress, mis vastab 200-ga ja mida tahad otsingutulemustes näha.
- Kirjuta reeglid ümber nii, et iga algus viib kohe lõppu. Ära lisa reeglit peale, vaid asenda vana:
A → C, mitteA → BplussB → C. - Paranda allikad: menüü, jalus, leivapuru, canonical, hreflang, sitemap. Google palub samas kolimise dokumentatsioonis eraldi asendada siselingid uute aadressidega vastavustabeli järgi. See samm annab rohkem kui ümbersuunamine ise, sest eemaldab ümbersuunamise seal, kus sa seda juhid: siselingid ei tohiks üldse ümbersuunamistele viia.
- Jäta vanad reeglid alles. Google soovitab hoida ümbersuunamisi nii kaua kui võimalik, tavaliselt vähemalt aasta, ja lubab hoida neid piiramatult.
- Kontrolli uuesti eelmise jaotise käsuga ja roomajaga nädal pärast parandust.
Millal ahelat mitte puutuda
Iga ahel ei vääri tööpäeva. Kui saidil on kuni mõnisada aadressi (adlab.ee sitemapis on neid 141), ahel koosneb tavalistest http → https ja www → ilma www ümbersuunamistest ning algusele viitavad ainult vanad välised allikad, pole midagi parandada: esimesed 2 lüli kuuluvad platvormile ja kahju piirdub ühe päringuga.
Aega tasub kulutada kolmel juhul: ahel on pikem kui 3 lüli (Google'i kolimise dokumentatsiooni lävi), ahela algus asub sinu menüüs, sitemapis või canonical'is, või see puudutab robots.txt-i 5 ümbersuunamise piiriga. Mitme kolimise ajalooga kataloogid ja saidid, mis on läbinud kolimise, kuuluvad sellesse rühma esimeses järjekorras. Seal söövad ahelad lisaks osa roomamiseelarvest: kolm lüli ühe asemel tähendab kolme päringut sama lehe jaoks.
Kustutatud lehed sellesse analüüsi ei kuulu. Kui aadressil asendust pole, on 301 avalehele kahjulik, ja sellest kirjutasin artiklis 404, 410 ja ümbersuunamise kohta.
