Atvejo analizė: kaip elektroninė parduotuvė tapo iš dalies nepasiekiama vartotojams ir paieškos sistemoms, nors įprastose ataskaitose reikšmingų pokyčių nesimatė.
Svetainės lankomumo ir pardavimų ataskaitos gali atrodyti įprastai net tada, kai dalis vartotojų svetainės nepasiekia. Jei užklausa baigiasi serverio klaida dar prieš tinkamai įkeliant puslapį, toks apsilankymas įprastose ataskaitose gali likti nepastebėtas.
Tai paaiškėjo atliekant vienos elektroninės parduotuvės auditą. Svetainėje nebuvo vykdoma nuosekli SEO priežiūra, todėl audito metu buvo tikrinama ne tik paieškos optimizavimo būklė, bet ir techninis svetainės pasiekiamumas.
Atliekant techninį patikrinimą paaiškėjo, kad į svetainę negali patekti net tokie svetainių analizės įrankiai kaip „Ahrefs“ ir „Semrush“. Tai paskatino patikrinti, ar problema susijusi tik su jų robotais, ar gali paveikti ir dalį realių svetainės lankytojų.
Atsakymą padėjo rasti serverio žurnalai. Juose fiksuojamos į svetainę siunčiamos užklausos ir serverio pateikiami atsakymai, todėl galima pamatyti ne tik sėkmingas užklausas, bet ir atvejus, kai serveris į jas atsako klaida.
Šiuo atveju paaiškėjo, kad maždaug kas aštunta naršymo užklausa baigdavosi klaida – vietoje pageidaujamo puslapio serveris grąžindavo klaidos pranešimą.
Ką atskleidė dviejų valandų serverio duomenys
Analizuojant kliento e. parduotuvės serverio žurnalus, pasirinktas dviejų valandų laikotarpis ramiausiu paros metu, kai svetainės apkrova buvo mažesnė. Nors analizuotas laikotarpis gana trumpas, per jį serveris gavo beveik 47 tūkst. užklausų, todėl tokios duomenų apimties pakako pagrindinėms tendencijoms įvertinti.
Iš visų pateiktų užklausų serveris atmetė 17,5 %. Į šį skaičių pateko tiek robotų ir realių vartotojų užklausos. Atsižvelgus tik į įprastas naršyklių užklausas, klaida buvo grąžinta 12,9 % atvejų – maždaug kas aštuntai užklausai.
Iš vartotojo pusės problema galėjo pasireikšti skirtingai:
- naršydamas katalogą vartotojas paspaudžia ant prekės, tačiau vietoj jos atidaromas klaidos puslapis;
- vartotojas paspaudžia mygtuką „Įsiminti prekę“, tačiau šis nereaguoja – tokių nepavykusių veiksmų buvo daugiau nei ketvirtadalis;
- pirmą kartą apsilankęs vartotojas puslapio laukia ilgiau nei kiti, o ilgiausiai užtrukusios užklausos siekė 14 sekundžių.
Šie atvejai svarbūs tuo, kad vartotojas ne visada gali suprasti, jog susidūrė su technine problema. Jis gali tiesiog uždaryti puslapį arba pereiti į kitą svetainę.
Ką matė „Google“ ir AI įrankiai
Paieškos sistemos svetaines tikrina automatiniais robotais. Jie aplanko puslapius ir surenka informaciją, kuri vėliau naudojama paieškos rezultatuose. Jei robotui bandant pasiekti puslapį serveris grąžina klaidą, jis negali normaliai perskaityti jo turinio.
Šiuo atveju „Googlebot“ klaidą gaudavo 17,5 % užklausų – dažniau nei įprastos naršyklės, kurių klaidų dalis siekė 12,9 %.
„Google Search Console“ duomenys patvirtino problemos mastą. Birželio pabaigoje nepasiekiamų puslapių buvo apie 4 000, o po dviejų mėnesių jų skaičius išaugo iki 18 467.
Kadangi svetainės kataloge naudojami filtrai, buvo galima manyti, kad didelę dalį nepasiekiamų URL sudaro jų sugeneruoti adresai. Tačiau duomenys parodė kitaip: iš tūkstančio „Google“ pateiktų adresų 81 % sudarė įprasti prekių puslapiai, o filtrų adresai – tik 8,5 %.
Be to, aštuoni iš dešimties imties adresų neturėjo jokių parametrų. Tai buvo paprasti prekių puslapiai su prekės kodu URL gale.
Problema buvo ne tik „Google“
„Bing“ paieškos robotas per visą stebimą laikotarpį negavo nė vieno sėkmingo atsakymo. Jį blokavo ne svetainės apkrova, o atskira „Cloudflare“ taisyklė, kurios atsiradimo datos žurnaluose nustatyti nepavyko. Kol ji galiojo, „Bing“ ir „Copilot“ galėjo remtis vis senesne svetainės versija.
Kuo skiriasi AI robotai?
AI sistemų robotai gali svetainę pasiekti kitaip nei tradiciniai paieškos robotai. Šiuo atveju „ChatGPT“ bandė pasiekti svetainę 56 kartus, o beveik pusė šių užklausų baigėsi klaida.
Jei AI robotui svetainės pasiekti nepavyksta, jis gali atsakymą formuoti iš kitų turimų duomenų. Vartotojas apie nesėkmingą bandymą gali net nesužinoti.
Skiriasi ir pakartotinių bandymų pobūdis: paieškos robotai svetainę tikrina periodiškai, o AI roboto užklausa gali būti susijusi su konkrečiu vartotojo klausimu. Todėl nesėkmingas bandymas nebūtinai bus pakartotas tuo pačiu būdu.
Kodėl to nesimatė ataskaitose
E. parduotuvėje ilgą laiką nebuvo atliekami SEO darbai, todėl nebuvo ir reguliarių SEO ataskaitų. Buvo žiūrima į tai, ką dažniausiai stebi verslas: pardavimus, reklamos rezultatus ir lankytojų statistiką. Nė viename iš šių grafikų nebuvo staigaus kritimo, kuris būtų privertęs ieškoti techninės problemos.
Tačiau net ir SEO ataskaitos nebūtinai parodytų pačią techninės problemos priežastį. Jos daugiausia parodo rezultatą – parodymus, paspaudimus, pozicijas ar kitus rodiklius. Jei robotas negali pasiekti puslapio, ataskaitoje pirmiausia matome šio sutrikimo pasekmę, o ne serverio klaidą.
Su vartotojais situacija panaši. Žmogus, kuris gavo klaidą ir išėjo, gali būti užregistruotas lankytojų statistikoje, tačiau vien iš jos neįmanoma nustatyti, kodėl jis išėjo.
Šiuo atveju problema buvo matoma „Google Search Console“ nuskaitymo statistikoje: klaidų kreivė augo visą ketvirtį. Tačiau į šiuos duomenis reguliariai nebuvo žiūrima, todėl signalas liko nepastebėtas.
Svarbu ir tai, kad tokios problemos poveikis pradžioje nebūtinai atrodo dramatiškas. Rezultatai gali po truputį blogėti arba tiesiog nustoti augti. Tam galima rasti ne vieną paaiškinimą – sezoniškumą, algoritmo atnaujinimą, konkurencijos pokyčius. Todėl techninė problema gali likti nepastebėta tol, kol jos poveikis tampa akivaizdus.
Kodėl taip nutinka
Šiuo atveju problema susidarė ne dėl vienos klaidos, o dėl kelių techninių sprendimų sąveikos.
- Katalogo filtrai sukuria daug skirtingų URL. Kiekvienas filtro pasirinkimas ar jų kombinacija gali sukurti atskirą interneto adresą. Robotui tai yra atskiras URL, kurį reikia aplankyti ir patikrinti, net jei jo turinys mažai skiriasi nuo kitų filtro kombinacijų.
- Kiekvieną tokią užklausą turi apdoroti serveris. Kuo daugiau tokių adresų robotai aplanko, tuo daugiau užklausų tenka apdoroti serveriui. Dalis šio darbo gali tekti puslapiams, kurie nesukuria reikšmingos vertės nei vartotojui, nei paieškai.
- Pasiekus serverio apsaugos ribą, dalis užklausų atmetama. Sistema pradeda grąžinti klaidas, kurias gali gauti tiek paieškos robotai, tiek realūs vartotojai.
Šiuo atveju nuskaitymo statistika parodė, kad 82 % viso „Googlebot“ darbo teko jau žinomiems puslapiams patikrinti. Tai rodo, kad robotas daug kartų grįždavo prie jau anksčiau aplankytų adresų.
Dar vienas duomenų pjūvis parodė, kiek serverio darbo teko filtrų adresams. Per keturis mėnesius šie adresai bent kartą buvo parodyti paieškoje ir kartu surinko vos du paspaudimus, tačiau stebimą naktį jiems teko 70 % viso serverio darbo.
Taigi problema buvo ne patys filtrai ir ne pati serverio apsauga. Problema atsirado tada, kai daug URL generuojanti katalogo struktūra, intensyvus robotų atliekamas svetainės nuskaitymas ir apsaugos nuo perteklinio srauto taisyklės pradėjo veikti kartu.
Ką tai padarė rezultatams
Nuo rugpjūčio vidurio svetainės matomumas ėmė kristi. Paspaudimai iš paieškos per tris savaites sumažėjo nuo 340 iki 235 per parą, tai yra beveik trečdaliu. Tuo pačiu metu vidutinė pozicija nepasikeitė – visą tą laiką ji laikėsi ties dešimtuoju rezultatu.
Dar aiškiau situacija matėsi palyginus dienas. Kai serverio klaidų buvo mažai, svetainė gaudavo vidutiniškai 362 paspaudimus. Dienomis, kai klaidų buvo daug, – 276. Pozicija abiem atvejais buvo tokia pati.
Metų palyginimas rodė panašią tendenciją: pozicija per metus pagerėjo, o paspaudimų sumažėjo beveik trečdaliu.
Šie duomenys savaime neįrodo, kad serverio klaidos sukėlė visą paspaudimų kritimą. Tačiau paspaudimų sumažėjimas sutapo su didesniu serverio klaidų skaičiumi, todėl techninį svetainės pasiekiamumą buvo būtina vertinti kartu su paieškos duomenimis.
Šiame atvejyje taip pat buvo pastebėta, kad dalis paieškos rezultatų vis dar rodė senesnę informaciją. Tai galėjo būti susiję su tuo, kad „Google“ negalėjo iš naujo pasiekti dalies puslapių ir perskaityti jų atnaujinto turinio.
Ką reikėjo pakeisti
Pagrindiniai pakeitimai buvo susiję su nustatymais ir serverio veikimu.
Sutvarkyti filtrų URL valdymą. Patys filtrai kataloge reikalingi, tačiau ne visi jų sugeneruoti adresai turi būti prieinami paieškos robotams. Reikia atskirti URL, kurie turi paieškos vertę, nuo tų, kurių nuskaitymas tik eikvoja serverio resursus.
Paruošti dažniausiai lankomus puslapius. Jei serveris tą patį puslapį turi generuoti iš naujo kiekvienam apsilankymui, didėja jo apkrova. Todėl verta įvertinti, kaip dažnai lankomus puslapius būtų galima pateikti iš anksto paruoštus ir taip sumažinti serveriui tenkantį darbą.
Peržiūrėti apsaugos taisykles. Apsauga nuo perteklinio srauto reikalinga, tačiau jos taisyklės neturėtų netyčia blokuoti įprastų vartotojų. Šiuo atveju reikėjo įvertinti, kaip skaičiuojama užklausų riba ir kodėl ją pasiekus klaidas gaudavo ir atsitiktiniai lankytojai.
Įjungti stebėseną. Reikalingas automatinis įspėjimas, kuris praneštų apie reikšmingą klaidų skaičiaus ar svetainės greičio pokytį. Tokiu būdu problema būtų pastebėta anksčiau, o ne po kelių mėnesių.
Dalis šių darbų e. parduotuvėje jau atlikta, darbai tęsiasi.
Ką patikrinti savo svetainėje
Toks pats ciklas gali susidaryti ir kitose svetainėse, ypač jei jose yra daug filtrų, dinamiškai generuojamų URL ir apsaugos nuo perteklinio srauto taisyklių. Pirmiausia verta išsiaiškinti, kiek jūsų serverio srauto sudaro robotai. Šią informaciją galima rasti serverio žurnaluose arba naudojamos apsaugos paslaugos analitikoje.
Taip pat verta patikrinti „Search Console“ nuskaitymo statistiką ir pažiūrėti, kokia dalis užklausų baigiasi serverio klaidomis.
Penki klausimai savo komandai ar svetainės administratoriams:
- Kokia dalis užklausų mūsų serveryje baigiasi klaida? Tai galima matyti serverio žurnaluose, o dalį informacijos – „Search Console“ nuskaitymo statistikoje.
- Kiek skirtingų adresų sugeneruoja mūsų katalogo filtrai ir kiek jų yra vertingi paieškoje? Svarbu žinoti ne tik URL skaičių, bet ir tai, kiek jų realiai gauna parodymų ar paspaudimų.
- Kokią dalį serverio srauto sudaro robotai? Lankytojų statistikoje šio vaizdo paprastai nepakanka. Atsakymo reikėtų ieškoti serverio žurnaluose arba apsaugos paslaugos analitikoje.
- Ar išorės specialistų robotai gali pasiekti į mūsų svetainę? Tai galima patikrinti atliekant techninį SEO auditą. Jei išorinis SEO įrankis negali normaliai pasiekti svetainės, verta išsiaiškinti priežastį.
- Ar paspaudimai mažėja, nors pozicijos išlieka panašios? „Search Console“ rezultatų ataskaitoje galima kartu vertinti paspaudimus ir vidutinę poziciją. Toks neatitikimas savaime neparodo priežasties, tačiau yra signalas atlikti papildomą analizę.
Ko tikėtis iš tokio taisymo
Jei paaiškėja, kad svetainę riboja serverio klaidos, robotų srautas ar netinkamai sukonfigūruotos apsaugos taisyklės, tokių problemų pašalinimas savaime nesukuria naujos paklausos. Tačiau jis gali padėti susigrąžinti dalį srauto ir pasiekiamumo, kurie buvo prarasti dėl techninių kliūčių.
Atlikus pirmuosius pakeitimus, tipinis serverio atsakas tapo perpus greitesnis, o paieškos robotas, kuris anksčiau negaudavo nė vieno sėkmingo atsakymo, vėl pradėjo normaliai nuskaityti svetainę.
Momentinio pokyčio tikėtis nereikėtų. Paieškos sistemoms reikia laiko puslapiams iš naujo peržiūrėti, o galutiniams rezultatams įtakos turi ne vien techninis svetainės pasiekiamumas, bet ir kiti SEO bei verslo veiksniai.
Šią problemą radome ne ieškodami serverio klaidų, o užkliuvę už jos darydami visai kitą darbą. Todėl jei jūsų ataskaitos atrodo normaliai, bet rezultatai lėtai prastėja arba tiesiog nustojo augti, verta patikrinti ir tai, ko įprastos ataskaitos nerodo.
Serverio žurnalų peržiūra yra viena iš mūsų SEO paslaugų: peržiūrime, ką serveris atsako vartotojams ir robotams, ir padedame nustatyti, ką reikėtų keisti.
