Inžinierius tikrina fintech svetainės veikimą

JavaScript SEO finansų svetainėms: kaip Google mato jūsų turinį

Jei jūsų fintech svetainė sukurta su React, Vue, Angular ar Next.js, Google gali matyti visai ne tą puslapį, kurį mato klientas. Kainodara, palūkanų normos, licencijos informacija ir produktų aprašymai, kurie atsiranda tik paleidus JavaScript, į indeksą patenka vėliau, netiksliai arba visai nepatenka. Sprendimas paprastas principu, bet reikalauja techninės disciplinos: svarbiausias turinys, nuorodos ir metaduomenys turi būti jau pradiniame HTML, o atvaizdavimo būdas parenkamas pagal puslapio paskirtį. Žemiau rasite, kaip Google apdoroja JavaScript, kurį atvaizdavimo modelį rinktis, kada dar tinka dinaminis atvaizdavimas ir kaip patikrinti, ar jūsų puslapiai indeksuojami teisingai.

Seocheaper
seocheaper.lt
Patikrinkite fintech svetainės techninį SEO
Seocheaper teikia techninį SEO auditą fintech įmonėms, siekiančioms pagerinti matomumą paieškoje ir DI platformose.

Gaukite pasiūlymą

Trumpai

  • Google JavaScript turinį apdoroja trimis etapais: nuskaito, atvaizduoja ir tik tada indeksuoja. Viskas, kas atsiranda tik po atvaizdavimo, į paiešką patenka lėčiau.
  • Viešiems finansų puslapiams (kainodara, produktai, gidai) rinkitės SSR arba SSG. Kliento pusės atvaizdavimą (CSR) palikite prisijungusių vartotojų zonai.
  • Dinaminis atvaizdavimas yra laikinas apėjimo būdas, o ne ilgalaikis sprendimas. Taip teigia pati Google.
  • Dažniausios klaidos: nuorodos be href, URL su #, canonical ir title keitimas per JavaScript, „soft 404“ ir turinys, kuris įkeliamas tik paspaudus.
  • Tikrinkite su Search Console URL tikrinimo įrankiu ir SEO metaduomenis tvirtinkite automatiniais testais kiekviename išleidime.

Turinys

Kodėl JavaScript finansų svetainėje tampa SEO problema

Fintech produktų svetainės dažnai kuriamos ta pačia technologija kaip ir pati programa. Tai logiška kūrėjų požiūriu: vienas kodas, vienas komponentų rinkinys, greitas darbas. Tačiau paieškos sistemai toks puslapis iš pradžių gali atrodyti kaip tuščias apvalkalas su vienu scenarijaus failu.

Finansų sektoriuje tai kainuoja daugiau nei kitur. Žmogus, ieškantis mokėjimų sprendimo, sąskaitos įmonei ar valiutos keitimo kurso, nori rasti konkrečius skaičius: mokesčius, terminus, limitus. Jei šie skaičiai rodomi tik per JavaScript, Google gali juos pamatyti pavėluotai, o konkurentų puslapiai su paprastu HTML tuo metu jau rodomi rezultatuose.

Verslo savininkas telefone stebi mokėjimų mokesčius

Antra priežastis yra pasitikėjimas. Finansų tema paieškos sistemoms jautri, todėl jos ypač vertina aiškiai pateiktą, patikrinamą informaciją: kas teikia paslaugą, kokia licencija, kokios sąlygos. Kai ši informacija paslėpta už scenarijų, signalai tampa silpnesni.

Trečia, JavaScript klaidos retai matomos iš karto. Svetainė veikia, klientai registruojasi, o organinis srautas lėtai mažėja. Todėl verta žinoti, kaip matuoti ankstyvą SEO pažangą dar prieš tai, kai pokyčiai atsispindi pajamose: indeksuotų puslapių skaičius ir parodymai pasako apie problemą anksčiau nei pardavimai.

Kaip Google apdoroja JavaScript: trys etapai

Google oficialioje dokumentacijoje aprašo, kad JavaScript puslapiai apdorojami trimis etapais: nuskaitymu (crawling), atvaizdavimu (rendering) ir indeksavimu (indexing).

  1. Nuskaitymas. Googlebot parsisiunčia URL ir gauna pradinį HTML. Jau šiame etape jis ieško nuorodų ir tikrina robots taisykles.
  2. Atvaizdavimas. Puslapiai, grąžinantys 200 HTTP būsenos kodą, patenka į atvaizdavimo eilę, nebent robots meta žyma ar antraštė nurodo jų neindeksuoti. Tada „Chromium“ pagrindu veikianti naršyklė be grafinės sąsajos paleidžia JavaScript. Toje pačioje dokumentacijoje nurodoma, kad puslapis eilėje gali praleisti kelias sekundes, bet gali laukti ir ilgiau.
  3. Indeksavimas. Google naudoja atvaizduotą HTML, iš jo surenka turinį ir naujas nuorodas, kurios vėl keliauja į nuskaitymo eilę.

Iš to kyla keli praktiniai dalykai, kuriuos turi žinoti kiekviena fintech kūrėjų komanda:

  • Noindex pradiniame HTML sustabdo viską. Jei Google pradiniame kode randa noindex, puslapio jis neatvaizduoja ir neindeksuoja, net jei JavaScript vėliau tą žymą pašalintų.
  • Būsena tarp puslapių neišsaugoma. Google atvaizdavimo paslauga išvalo Local Storage, Session Storage ir slapukus tarp puslapių įkėlimų. Jei jūsų kainodaros puslapis rodo turinį tik pagal slapuke įrašytą šalį ar kalbą, Google gali pamatyti tuščią ar numatytąją versiją.
  • Ne visi robotai vykdo JavaScript. Google pažymi, kad serverio pusės atvaizdavimas arba išankstinis atvaizdavimas naudingi, nes ne kiekvienas robotas geba paleisti scenarijus. Tai svarbu ir DI paieškos įrankiams, kurie vis dažniau cituoja finansų šaltinius.

Atvaizdavimo būdai: CSR, SSR, SSG, ISR ir dinaminis atvaizdavimas

Didžiausią įtaką JavaScript SEO turi ne atskiros klaidos, o pasirinktas atvaizdavimo modelis. Šiuolaikiniai karkasai leidžia skirtingiems puslapiams taikyti skirtingas strategijas, todėl nereikia rinktis vieno būdo visai svetainei.

Būdas Kaip veikia Ką gauna Google pirmu bandymu Kur tinka fintech svetainėje
CSR (kliento pusės) Serveris siunčia minimalų HTML, naršyklė parsisiunčia JavaScript ir sukuria turinį Beveik tuščią apvalkalą, turinys tik po atvaizdavimo Interneto bankas, kliento paskyra, vidiniai įrankiai
SSR (serverio pusės) Pilnas HTML sugeneruojamas serveryje kiekvienai užklausai Visą turinį iš karto Valiutų kursai, dažnai kintančios sąlygos, personalizuoti vieši puslapiai
SSG (statinis generavimas) HTML puslapiai sukuriami kūrimo (build) metu Visą turinį iš karto, greitai Produktų puslapiai, gidai, žinių bazė, apie įmonę
ISR (laipsniškas atnaujinimas) Statiniai puslapiai atnaujinami po kūrimo nustatytu intervalu Visą turinį iš karto Kainodara, palūkanų lentelės, kurios kinta kartą per dieną ar savaitę
Dinaminis atvaizdavimas Robotams pateikiama iš anksto atvaizduota versija, žmonėms įprasta JavaScript versija Atvaizduotą HTML, jei robotas atpažintas Tik kaip laikinas sprendimas senai sistemai

Paprasta taisyklė: jei puslapis turi būti randamas paieškoje, jo turinys turi ateiti iš serverio. Jei puslapis skirtas tik prisijungusiam klientui, SEO jam nesvarbus ir CSR visiškai tinka.

Tipinėje mokėjimų platformoje tai atrodo taip: pagrindinis puslapis, produktų ir gidų skiltis generuojamos statiškai, kainodara atnaujinama ISR būdu, kursų skaičiuoklė pateikiama per SSR su pradine reikšme HTML kode, o kliento paskyra lieka CSR. Rezultatas: Google iš karto gauna viską, kas parduoda, o programos dalis išlieka greita ir interaktyvi.

Dinaminis atvaizdavimas: kada jis dar turi prasmę

Dinaminis atvaizdavimas (dynamic rendering) kadaise buvo populiarus greitas sprendimas: serveris atpažįsta robotą ir pateikia jam paruoštą HTML. Šiandien Google tiesiai rašo, kad tai apėjimo būdas, o ne ilgalaikis sprendimas, ir rekomenduoja serverio pusės atvaizdavimą, statinį atvaizdavimą arba hidrataciją (hydration).

Priežastis praktiška: reikia palaikyti dvi puslapio versijas, stebėti, kad jos sutaptų, ir valdyti papildomą infrastruktūrą. Finansų svetainėje, kur sąlygos ir skaičiai turi būti vienodi visiems, dvi versijos reiškia ir papildomą atitikties riziką: robotas gali matyti senesnį mokestį nei klientas.

Dinaminis atvaizdavimas vis dar gali būti protingas tarpinis žingsnis, kai:

  • turite didelę seną vieno puslapio programą (SPA), kurios perrašymas užtruks kelis mėnesius;
  • dalis viešo turinio generuojama per JavaScript ir greitai jo perkelti į serverį neįmanoma;
  • reikia skubiai grąžinti indeksavimą, kol kuriamas SSR ar SSG sprendimas.

Tokiu atveju nustatykite aiškų terminą, kada laikinas sprendimas bus pakeistas, ir reguliariai lyginkite robotui bei vartotojui pateikiamą turinį.

Kurie fintech puslapiai turi būti pradiniame HTML

Ne kiekvienas puslapis vienodai svarbus. Pirmenybę teikite tiems, kurie atveda klientus ir kuria pasitikėjimą:

  • Kainodara ir mokesčiai. Skaičiai, planų pavadinimai ir sąlygos turi būti tekste, o ne tik interaktyvioje skaičiuoklėje.
  • Produktų ir paslaugų puslapiai. Mokėjimų sprendimai, sąskaitos verslui, kortelės, valiutų keitimas, kriptovaliutų paslaugos.
  • Licencijos ir reguliavimo informacija. Kas teikia paslaugą, kuri institucija prižiūri, kur rasti teisinius dokumentus.
  • Gidai ir žinių bazė. Būtent šie puslapiai dažniausiai pritraukia informacinių užklausų srautą ir DI citatas.
  • Kontaktai ir įmonės informacija. Juridinis pavadinimas, adresas, rekvizitai.

Jei svetainėje yra kelios kalbos ar šalys, kiekviena versija turi turėti savo URL ir savo pilną HTML. Kalbos parinkimas pagal slapuką ar naršyklės nustatymus, kai visos versijos rodomos tuo pačiu adresu, paieškos sistemai lieka nematomas. Daugiau apie tai, ką reguliuojamai įmonei būtina suderinti su teisininkais, rasite mūsų SEO atitikties kontroliniame sąraše.

Dažniausios JavaScript SEO klaidos

Šios klaidos kartojasi beveik kiekviename fintech ir SaaS projekte, kurį tenka tikrinti:

Klaida Kas nutinka Kaip taisyti
Nuorodos be href, tik su onclick Google patikimai seka tik a elementus su href atributu, todėl puslapiai lieka neatrasti Naudokite tikras nuorodas su pilnu URL
URL su fragmentu, pvz., /#/kainos Google fragmentų nelaiko atskirais puslapiais Naudokite History API ir švarius URL
„Soft 404“ Neegzistuojantis puslapis grąžina 200 kodą ir rodo klaidos tekstą Grąžinkite tikrą 404 arba nukreipkite į puslapį, kuris grąžina 404
Canonical keičiamas per JavaScript Atsiranda dvi skirtingos canonical žymos, Google gauna prieštaringus signalus Teisingą canonical įrašykite pradiniame HTML ir jo nekeiskite
Title ir aprašymas tik po atvaizdavimo Paieškos rezultatuose rodomas bendras ar netinkamas pavadinimas Kiekvienam puslapiui unikalūs metaduomenys iš serverio
Turinys įkeliamas tik paspaudus DUK, sąlygos ar tarifai lieka nematomi Turinį laikykite HTML kode, o paspaudimu tik jį rodykite
Robots meta žyma su noindex šablone Google puslapio neatvaizduoja ir neindeksuoja Noindex dėkite tik ten, kur jo tikrai reikia

Google JavaScript SEO pagrinduose aprašo ir rekomenduojamą elgesį su būsenos kodais, fragmentais ir canonical žyma. Jei canonical vis dėlto įterpiamas per JavaScript, svarbu, kad jis būtų vienintelis ir nesikirstų su pradiniame HTML esančiu. Platesnį sąrašą klaidų, kurios mažina matomumą ir DI paieškoje, rasite straipsnyje apie fintech SEO klaidas.

Kaip patikrinti, ar puslapiai indeksuojami teisingai

Patikra užtrunka nuo kelių minučių vienam puslapiui iki kelių dienų visai svetainei. Pradėkite nuo svarbiausių 10 ar 20 URL.

  1. Atsidarykite Search Console URL tikrinimo įrankį. Įveskite puslapio adresą ir paleiskite tiesioginį testą. Google rekomenduoja peržiūrėti atvaizduotą DOM, įkeltus išteklius ir JavaScript klaidas.
  2. Palyginkite pradinį HTML su atvaizduotu. Peržiūrėkite puslapio šaltinį naršyklėje ir ieškokite pagrindinių frazių: produkto pavadinimo, kainos, mokesčio dydžio. Jei jų nėra šaltinyje, bet yra atvaizduotame variante, turinys priklauso nuo JavaScript.
  3. Patikrinkite užblokuotus išteklius. Jei robots.txt draudžia scenarijų ar API adresus, Google negalės sukurti viso puslapio.
  4. Peržiūrėkite metaduomenis. Ar title, aprašymas, canonical ir robots žymos atvaizduotame variante tokie, kokių tikitės, ir ar nėra jų dublikatų.
  5. Išbandykite su išjungtu JavaScript. Jei išjungus scenarijus puslapis tuščias, vertinkite tai kaip įspėjimą: dalis robotų jį matys būtent taip.
  6. Stebėkite indeksavimo ataskaitą. Search Console puslapių ataskaitoje ieškokite būsenų „Nuskaityta, bet neindeksuota“ ir „Soft 404“.

Kai patikrinsite pagrindinius puslapius, atsakymus sudėkite į vieną planą. Kaip tai daroma sistemiškai, aprašėme techninės SEO analizės vadove, o rezultatus vertinti padės mūsų gidas apie fintech svetainės SEO metrikas.

Kaip neprarasti indeksavimo per kiekvieną išleidimą

Fintech komandos išleidžia atnaujinimus dažnai, o SEO klaidos JavaScript programose retai atrodo kaip įprastos klaidos: puslapis veikia, testai praeina, bet canonical rodo ne ten arba šablone liko noindex. Todėl naudinga SEO metaduomenis traktuoti kaip programos kontraktą ir tikrinti juos automatiškai.

Praktiškai tai reiškia:

  • Automatiniai testai CI/CD eigoje. Kiekvienam svarbiam šablonui patikrinkite, ar serverio atsakyme yra title, aprašymas, vienas canonical ir tinkama robots reikšmė.
  • Turinio testai. Tikrinkite, ar pradiniame HTML yra pagrindinis tekstas ir vidinės nuorodos, o ne tik komponentų vietos.
  • Būsenos kodų testai. Neegzistuojantis URL turi grąžinti 404, perkeltas puslapis 301.
  • Atskira aplinka be noindex klaidų. Testinė aplinka turi būti uždaryta, bet noindex taisyklė neturi patekti į gamybinę versiją.
  • Stebėsena po išleidimo. Po didesnio atnaujinimo per kelias dienas patikrinkite svarbiausius URL Search Console įrankiu.

Taip SEO tampa ne vienkartiniu projektu, o kokybės dalimi, kaip ir saugumo ar našumo testai.

DI paieška ir JavaScript turinys

Vis daugiau finansų paslaugų pirkėjų pradeda paiešką ne tik Google, bet ir DI asistentuose. Jau minėjome, kad Google pati pažymi, jog ne visi robotai geba vykdyti JavaScript. Todėl turinys, kuris pasiekiamas tik po atvaizdavimo, rizikuoja likti nepastebėtas būtent ten, kur šiandien formuojasi pirmoji nuomonė apie paslaugos teikėją.

Tas pats principas veikia abiem kryptimis: aiškus HTML, struktūrizuotos antraštės, tikslūs skaičiai ir aiški įmonės tapatybė padeda ir Google, ir DI įrankiams suprasti, kas jūs ir ką siūlote. Kaip šį matomumą stebėti ir didinti, aprašėme 90 dienų DI matomumo plane fintech įmonėms.

Mūsų požiūris

Dirbdami su fintech ir SaaS įmonėmis matome, kad JavaScript SEO problema beveik niekada nėra vien techninė. Kūrėjai daro tai, ko prašoma: greitą, gražią programą. Rinkodaros vadovas mato, kad srautas neauga. O tarp jų nėra žmogaus, kuris paklaustų, ką Google gauna pirmu bandymu.

Todėl techninį auditą visada pradedame nuo paprasto palyginimo: ką mato klientas, ką mato Googlebot ir ką mato robotas, kuris JavaScript nevykdo. Šis vienas palyginimas dažnai paaiškina daugiau nei dešimtys rodiklių.

Mūsų nuomone, finansų svetainėje viešas turinys turi būti serverio atsakyme be išimčių. Kainos, sąlygos, licencijos informacija ir gidai yra tai, kuo klientas ir paieškos sistema vertina jūsų patikimumą. Dinaminį atvaizdavimą laikome tik tiltu, kol komanda pereina prie SSR ar SSG.

Svarbiausia, kad rezultatai būtų pamatuojami per aiškius terminus, o ne žadami kažkada ateityje. Todėl auditą susiejame su turinio planu, publikavimu ir DI matomumo stebėsena: pataisytas puslapis turi ne tik būti indeksuojamas, bet ir atvesti klientų.

Bartas

Techninis auditas ir SEO jūsų fintech svetainei

Jei jūsų svetainė veikia JavaScript pagrindu ir nesate tikri, ką iš tikrųjų mato Google, pradėkite nuo techninio SEO audito. Mūsų paketas „Viskas viename: SEO sprendimas“ kainuoja 250 € per mėnesį ir apima techninį auditą (GEO), SEO optimizuotą turinį, mėnesinį turinio planą, publikavimą, nuorodų kūrimą, DI matomumo stebėseną ir Reddit atradimų sistemą.

Seocheaper

Dirbame tik su fintech ir SaaS sektoriumi, todėl žinome, kaip suderinti techninius pataisymus su atitikties reikalavimais. Peržiūrėkite mūsų SEO paketą arba pirmiausia susipažinkite, kaip vyksta fintech svetainių SEO audito patikra.

DUK

Ar Google iš tikrųjų indeksuoja JavaScript turinį?

Taip, Google atvaizduoja JavaScript su „Chromium“ pagrindu veikiančia naršykle ir indeksuoja atvaizduotą turinį. Tačiau tai vyksta po nuskaitymo, kartais su vėlavimu, ir tik jei scenarijai veikia be klaidų. Todėl svarbiausią turinį saugiau pateikti jau pradiniame HTML.

Ar dinaminis atvaizdavimas pakenkia SEO?

Google jo nebaudžia, bet nebelaiko rekomenduojamu sprendimu ir vadina jį apėjimo būdu. Jis prideda sudėtingumo, nes tenka palaikyti dvi puslapio versijas. Ilgalaikiam sprendimui rinkitės SSR, SSG arba hidrataciją.

Kurį atvaizdavimo būdą rinktis fintech produkto svetainei?

Viešiems puslapiams, kurie turi būti randami paieškoje, tinka SSG arba SSR, o dažnai kintančioms kainoms ir kursams ISR arba SSR. Kliento paskyra ir interneto bankas gali likti CSR, nes jų indeksuoti nereikia. Dauguma šiuolaikinių karkasų leidžia derinti šiuos būdus vienoje svetainėje.

Kaip greitai pamatysiu rezultatus pataisęs JavaScript SEO klaidas?

Pirmuosius pokyčius dažniausiai matote Search Console: daugėja indeksuotų puslapių, keičiasi parodymai. Mes rezultatus fiksuojame per aiškius 30–90 dienų terminus ir vertiname pagal verslo rodiklius, ne tik pozicijas.

Šaltiniai

Rekomendacijos