Arutame projekti

Kuidas ehitada veebilehe struktuur semantilisest tuumast

Kuidas muuta märksõnaklastrid teenusesaidi struktuuriks: millised lehed luua, mitu taset teha, mida panna aadressidesse ja menüüsse ilma hilisema kolimiseta.

Vladislav Krivorutsko4. august 20267 min lugemist
Sisukord

TL;DR — lühidalt peamisest

  • Struktuur ehitatakse klastritest: üks päringuklaster = üks leht, ja jaotised tekivad lehtedest, mitte vastupidi
  • Menüü ülemine tase peab kordama seda, kuidas klient valikut kitsendab, mitte seda, kuidas ettevõtte osakonnad on jaotatud
  • Kaks kuni kolm taset piisab peaaegu igale teenusesaidile: mida sügavamal leht on, seda vähem sisemist kaalu ja tähelepanu ta saab
  • Aadressid pannakse paika üks kord — uutele URL-idele kolimine maksab alati rohkem kui kohe õigesti tehtud struktuur
  • Mitmekeelsel saidil langeb jaotiste puu tavaliselt kokku, aga slug'id ja osa lehti mitte: neid määrab konkreetse keele nõudlus

Lühike vastus

Veebilehe struktuur semantilisest tuumast ehitatakse nii: iga päringuklaster saab ühe lehe, lehed rühmitatakse jaotisteks selle loogika järgi, kuidas klient valikut kitsendab, ja selle rühmituse ülemine tase saab menüüks. Tuum vastab küsimusele «millised lehed on üldse vaja», struktuur küsimusele «kuidas need omavahel seotud on».

Töökäik on alati üks: klastrid → lehtede nimekiri → rühmitamine jaotisteks → aadressid ja menüü → sisemine linkimine. Jaotisi enne klasterdamist välja mõelda on mõttetu — tulemuseks on puu, mis on ehitatud ettevõtte sisemise loogika, mitte tegeliku nõudluse alla.


Miks struktuur sünnib nõudlusest, mitte organisatsioonist

Kõige sagedasem põhjus, miks sait «tundub korralik, aga liiklust pole», on see, et jaotised on nimetatud ja jaotatud nii, nagu ettevõtte sees mugav. Paigaldusosakonnast sai jaotis «Paigaldus», kuigi kliendid otsivad «konditsioneeri paigaldus hind». Teenus, mis toob poole käibest, on peidetud üldise lehe kolmandaks punktiks, sest ajalooliselt vedas seda üks töötaja.

Semantiline tuum korrigeerib selle vaate. See näitab, et nõudlus jaguneb teisiti kui ettevõte: kohati on kaks «erinevat» teenust kliendi jaoks üks ja sama, kohati laguneb üks teie teenus kolmeks iseseisvaks päringuks erinevate ootustega.

Seepärast ehitatakse struktuur alt üles. Kõigepealt on klastrid — tulevase saidi aatomid. Siis tekivad neist lehed. Ja alles siis kerkib küsimus, kuidas need lehed jaotisteks rühmitada. Vastupidine järjekord — mõelda välja menüü ja jaotada päringud selle järgi — annab peaaegu alati jaotised, kuhu midagi ei mahu, ja päringud, millel pole kohta.


Kuidas klastritest saavad lehed

Samm-sammult näeb see välja nii. Lähtekoht on valmis märksõnade klasterdamine, kus igal rühmal on üks kavatsus.

SammMida teemeTulemus
1. Lehe tüüpMäärame klastri kavatsuse järgi: äriline sihtleht, kategooria, artikkel, teatmematerjalSelge, mis leht see on ja kuidas ta välja näeb
2. KõrvutamineVaatame, kas selle klastri alla on juba lehtNimekiri «on / pole / on kaks»
3. VanemOtsustame, millisesse jaotisse leht kuulubPuu mustand
4. AadressPaneme slug'i klastri põhifraasistURL, mida ei pea hiljem muutma
5. PrioriteetMärgime, mida teeme esimesenaTööplaan, mitte ideede nimekiri

Kolm kohta, kus tavaliselt komistatakse.

Lehe tüüp on olulisem kui tema koht menüüs. Äriline klaster nõuab sihtlehte hinna, tingimuste ja vormiga. Informatiivne nõuab artiklit. Kui panna informatiivne klaster ärilisele lehele, muutub see korraga pikaks ja reklaamlikuks ning kaotab mõlemas kavatsuses.

«On kaks lehte» pole pisiasi. Kaks lehte ühe klastri all võistlevad omavahel ja Google valib nende hulgast mitte selle, mille valiksite teie. Seda tuleb lahendada struktuuri etapis, mitte pärast seda, kui mõlemad on lingid saanud.

Klastrita leht on samuti signaal. Vahel on sellised lehed vajalikud (kontaktid, ettevõttest, juriidilised), aga kui ärilise lehe alla ei ole ühtki päringut, tasub ausalt küsida, milleks ta on.


Mitu taset on teenusesaidil vaja

Vastus on lühike: kahest piisab peaaegu alati, kolmest varuga.

  1. Avaleht — lehtri ülemine osa, kõige üldisemad päringud ja navigatsioon.
  2. Teenuse leht — peamine äriline tase, kus on raha.
  3. Alateenus või segment — ainult siis, kui sellel on oma klaster oma nõudlusega.

Neljas tase on teenusesaidil peaaegu alati projekteerimisviga. Sellised lehed saavad vähe sisemisi linke, robot külastab neid harvemini ja positsioone koguvad nad aeglasemalt, kusjuures ükski kasutaja nendeni ei kliki. Kui lehte ei saa avalehelt kahe klikiga avada, tasub ta kas kõrgemale tõsta või tunnistada, et teda pole vaja.

Sügavus ei ole puu ilu küsimus, vaid sisemise kaalu jaotamise küsimus. Iga tase allapoole tähendab vähem linke, vähem roboti tähelepanu ja suuremat tõenäosust, et leht ripub aastaid ilma positsioonideta.

Eraldi e-poodidest: seal ehitatakse struktuur teisiti, sest lisanduvad kategooriad, filtrid ja parameetritega aadressid. See on omaette ülesanne oma reeglitega ja teenusesaidi joonlauaga seda mõõta ei tasu.


Aadressid: mis tuleb kohe paika panna

Aadress on struktuuri kõige kallim osa, sest selle muutmine on valus. Reeglid, mida ma järgin:

  • Slug klastri põhifraasist, väiketähtedega, sidekriipsudega. Mitte hinnakirja teenusenime translitereering, vaid see, kuidas seda otsitakse.
  • Ilma liigse pesastuseta URL-is. Kui leht loogiliselt kuulub jaotisse, ei ole see veel põhjus tirida kogu teed aadressi. Lühike aadress on vastupidavam.
  • Ilma kuupäevade, ID-de ja tehniliste parameetriteta sisulehtede aadressides.
  • Üks keel — üks slug. Eestikeelne leht ei ela venekeelsel aadressil ja vastupidi.
  • Otsustage enne käivitamist. Parim hetk struktuur paika panna on veebiarenduse etapp, kui lehti veel pole ja muuta pole midagi.

Kui struktuur juba töötab, aga aadressid on ebaõnnestunud, ei ole see põhjus kohe kõike ümber kolida. Kolimine maksab liiklust: isegi korrektsete lehekaupa 301-ümbersuunamistega on paarinädalane langus normaalne. Aadresse tasub muuta seal, kus praegune URL tegelikult segab (duplikaadid, tehnilised parameetrid, vale keel), mitte esteetika pärast.


Millised lehed puuduvad peaaegu igal teenusesaidil

Kui ma asetan tuuma olemasoleva saidi peale, korduvad augud projektist projekti:

  1. Eraldi lehed iga teenuse kohta. Nende asemel on üks leht «Teenused» nimekirjaga. See ei saa ranguda kümne eri kavatsuse peale korraga — ei pealkiri, aadress ega sisu vasta ühelegi neist täpselt.
  2. Lehed seose «teenus + linn või piirkond» alla. Eestis see töötab: Tallinn, Tartu ja Pärnu annavad märgatavalt erineva otsingutulemuse. Aga teha neid tasub ainult seal, kus nõudlus tõesti on, muidu tekib hulk ühesuguseid tühje lehti.
  3. Lehed hinnakavatsuse alla. Päringud sõnadega «hind», «kui palju maksab», «hinnakiri» moodustavad sageli eraldi klastri, aga saidil hindu üldse pole.
  4. Informatiivne lehtri ülaosa. Artiklid, mis püüavad inimese kinni enne, kui ta hakkab töövõtjat valima. Need ei too otseselt päringuid, kuid just nende kaudu kogub sait temaatilist sügavust.
  5. Tõendid. Juhtumid, tagasiside, tehtud tööde näited — neid projekteeritakse harva struktuuri osana, kuigi just neid loetakse enne ühendust võtmist.

Esimene punkt on kõige kallim. Minu tähelepanekute järgi annab teenuste väljatoomine üldisest nimekirjast eraldi sihtlehtedeks peaaegu alati rohkem kui ükskõik milline tekstiparandus olemasolevatel lehtedel.


Mitmekeelse saidi struktuur Eestis

Siin kehtib reegel, mis kõlab vastuoluliselt: keeleversioonide jaotiste puu on tavaliselt ühesugune, lehtede komplekt aga mitte tingimata.

Ühesugune puu — sest äri on üks: samad teenused, sama valikuloogika. Erinev lehtede komplekt — sest nõudlus eesti-, vene- ja ingliskeelses otsingus ei kattu. Juhtub klaster, mis eksisteerib ainult eesti keeles, ja peegellehe loomine vene keeles pole kellegi jaoks. Vastupidine olukord tuleb samuti ette.

Praktilised järeldused:

  • Slug'id oma keeles. Eestikeelne leht elab eestikeelsel aadressil, mitte venekeelse translitereeringul.
  • Keeleversioonid seotakse hreflang'iga. Ilma selleta käsitleb Google neid eraldi konkureerivate lehtedena, mitte ühe lehe tõlgetena.
  • Keele prioriteedi määrab nõudlus ja konkurents, mitte mugavus: millisest keelest alustada, kirjutasin lahti artiklis sellest, mis keeles veebilehte Eestis turundada.
  • Ärge tõlkige struktuuri mehaaniliselt. Puu ülekandmine ühest keelest teise ilma nõudlust kontrollimata annab lehed olematute päringute alla.

Mis on projektidel näha

Ütlen kohe piiri välja: universaalset arvu «õige struktuur annab +N%» ei ole olemas — liiga palju sõltub nišist ja saidi seisust. Aga seaduspärasused korduvad.

Esiteks: tuumast ehitatud struktuur pigem vähendab lehtede arvu kui suurendab. Pool jaotistest osutub tehtuks sisemiste terminite alla, mida keegi ei otsi, ja nende liitmine üheks tugevaks leheks töötab paremini kui kolme nõrga ülalpidamine.

Teiseks: kõige kallimad vead elavad ülemisel tasandil, mitte pisiasjades. Kaks suurt sihtlehte ühe kavatsuse all on probleem, mis tuleb välja kuude pärast, sest mõlemad kuidagi ranguvad ja näevad elusad välja.

Kolmandaks: struktuur iseenesest liiklust ei too. Kui lehed indeksisse ei jõua, ei päästa jaotiste puu — seepärast kontrollin kohe pärast projekteerimist, miks Google lehti ei indekseeri, ja alles siis asun sisu kallale.

Neljandaks, ootuste kohta: struktuuri ümberehitamine töötaval saidil on alati ajutine langus. See tasub end ära, aga mitte kahe nädalaga. Kui sait alles käivitub, saate sama tulemuse tasuta.


Kontrollnimekiri: struktuur ühe korraga kokku

  1. Võtke klastrid, mitte toorpäringute nimekiri.
  2. Andke igale klastrile lehe tüüp — sihtleht, kategooria, artikkel, teatmematerjal.
  3. Kõrvutage olemasolevate lehtedega: on / pole / on kaks.
  4. Ehitage puu alt üles — lehtedest jaotisteks, mitte vastupidi.
  5. Kontrollige sügavust: kõik oluline on avalehest kahe kliki kaugusel.
  6. Kirjutage aadressid klastri põhifraasist, ilma liigse pesastuseta.
  7. Märkige augud — klastrid ilma lehtedeta. See on teie plaan lähikuudeks.
  8. Lahendage kannibaliseerimine — kaks lehte ühe klastri all kas liitke või viige tähenduse järgi lahku.
  9. Korrake puud keelte kaupa ja kontrollige nõudlust igas keeles eraldi.

Pärast seda on teil käes mitte märksõnade tabel, vaid prioriteetidega saidikaart. Kui kahtlustate, et olemasolev struktuur pole nõudluse alla ehitatud, on mõistlik alustada SEO-optimeerimisest semantika ja struktuuri ülevaatamisega — vale puu peal tekste ümber kirjutada on mõttetu.

Korduma kippuvad küsimused

Millest alustada saidi struktuuri — menüüst või semantilisest tuumast?
Tuumast. Menüü on struktuuri tagajärg ja struktuur on nõudluse tagajärg. Kui alustada menüüst, fikseerite jaotised, mis on välja mõeldud ettevõtte seest, ja hakkate päringuid nende alla sobitama. Õige järjekord on vastupidine: kogusite päringud, rühmitasite klastriteks, klastritest saite lehtede nimekirja ja alles siis otsustasite, millised neist lähevad ülemisse menüüsse.
Mitu taset peaks teenusesaidil olema?
Enamasti piisab kahest: avaleht → teenus. Kolmas tase on õigustatud siis, kui teenusel on iseseisvad alateenused oma nõudlusega. Kolmandast tasemest sügavamal olevad lehed on teenusesaidil peaaegu alati üleliigsed: nad saavad vähe sisemisi linke, robot külastab neid harvemini ja nad ranguvad halvemini, kusjuures ükski kasutaja nii sügavale ei otsi.
Kas iga teenuse jaoks on vaja eraldi lehte või piisab ühest lehest «Teenused»?
Eraldi leht on vaja igale teenusele, millel on oma päringuklaster. Üks üldine leht «Teenused» ei saa füüsiliselt ranguda kümne eri kavatsuse peale: pealkiri, aadress ja sisu vastavad ainult ühele neist. Üldine leht jääb alles, kuid navigatsioonisõlmena, kust viivad lingid konkreetsetele teenustele, mitte sihtlehena kõigi päringute alla korraga.
Mida teha, kui struktuur on juba olemas ja tuum koguti hiljem?
Asetage klastrid olemasolevate lehtede peale ja vaadake, kus tekivad lahknevused. Tavaliselt tuleb välja kolm asja: lehed, mille alla nõudlust pole; klastrid, mille alla lehti pole; ja lehepaarid, mis vastavad ühele klastrile. Esimese võib alles jätta või liita, teise luua, kolmanda ümbersuunamisega kokku panna. Aadresse ei ole vaja massiliselt muuta: kolimine on õigustatud ainult seal, kus praegune URL tegelikult segab.
Kas saidi struktuuri saab pärast käivitamist muuta ilma liiklust kaotamata?
Saab, kuid kaotused on peaaegu alati olemas — küsimus on nende suuruses ja kestuses. Kohustuslikud tingimused: lehekaupa 301-ümbersuunamised vanadelt aadressidelt uutele (mitte kõik avalehele), sisemiste linkide ja sitemap'i uuendamine, indekseerimisraporti jälgimine pärast kolimist. Minu tähelepanekute järgi on paarinädalane langus normaalne stsenaarium isegi korraliku ülekolimise puhul, seepärast on parim hetk struktuuri muuta enne seda, kui sait on positsioonid kogunud.
Kas eesti- ja venekeelse versiooni struktuur peab kokku langema?
Jaotiste puu reeglina jah, sest äri on üks. Aga lehtede komplekt võib erineda: osa nõudlusest eksisteerib ainult ühes keeles ja peegellehe loomine ilma päringuteta on mõttetu. Slug'id on seejuures alati oma keeles ja keeleversioonid seotakse hreflang'iga — muidu peab Google neid konkureerivateks, mitte tõlgeteks.

Järeldused

Struktuur on hetk, kus SEO lakkab olemast tabel ja muutub saidiks. Viga siin veneb aastaid: ebaõnnestunud jaotiste puud tuleb kas taluda või ümbersuunamistega kolida, kaotades osa liiklusest. Seepärast panen struktuuri paika enne tekste ja enne disaini — selles etapis maksab see paar tundi tööd, aasta pärast maksaks nädalaid.

Artikli autor

Vladislav Krivorutsko — ADLABi asutaja
Vladislav Krivorutsko

ADLAB OÜ asutaja · SEO ja Google Ads

Üle 20 aasta otsiliikluse ja monetiseerimisega, Eesti turul alates 2017. aastast. Töötan üksi: teen auditi, koostan strateegia ja viin projekti ise lõpuni — ilma alltöövõtjate ja šabloonideta. Kirjutan ainult sellest, mida olen oma ja klientide saitidel järele proovinud.

  • 20+ aastat otsiliikluses
  • 50+ projekti võtmed kätte
  • Oma saidid konkurentsitihedates nišides
  • SEO ru/et/en ühes otsingutulemuses
Loe minust lähemalt

Loe edasi