Kas yra techninis SEO ir kodėl jis prasideda prieš dizainą
Dažnai matau tą pačią klaidą – apie techninį SEO pradedama galvoti tada, kai svetainė jau sukurta arba net paleista. Praktikoje jis prasideda gerokai anksčiau: kai sprendžiama, kokie bus puslapiai, kaip jie bus susieti tarpusavyje, kaip greitai krausis svetainė telefone ir kokie techniniai sprendimai neapsunkins sistemos po metų.
Čia nekalbu apie tekstų optimizavimą ar raktinių žodžių dėliojimą, nes tai kita tema. Ir nekalbu apie pažadus dėl pozicijų, nes jų niekas rimtai nedalina. Kalba eina apie pamatą: aiškią struktūrą, tvarkingą indeksavimą, normalų veikimą mobiliajame ir sprendimus, kurie netrukdo nei žmogui, nei paieškos sistemai suprasti, kas svetainėje svarbu. Jei šitas etapas praleidžiamas, gražus dizainas dažnai tik paslepia technines skolas.
Techninis SEO nėra įskiepis ar paskutinis patikrinimas
Tai sprendžiama ne vienu mygtuku pabaigoje, o nuo pirmų svetainės planavimo žingsnių
Praktikoje tai apima ne vien nustatymus administracijoje, bet visą svetainės pagrindą: puslapių struktūrą, kaip jie susiję tarpusavyje, ką paieškos sistemos gali rasti ir ko neturėtų indeksuoti, kaip greitai viskas veikia telefone ir ar sistema neturi bereikalingų techninių kliūčių.
Kur dažniausiai atsiranda klaidingas lūkestis
Dažnas verslas mano, kad techninis SEO sutvarkomas įdiegus vieną įskiepį ir užpildžius kelis laukus. Įskiepis gali padėti su dalimi bazinių dalykų, bet jis nesutvarko netvarkingos puslapių hierarchijos, lėto šablono, dubliuojamų techninių puslapių ar blogai sugalvotos vidinės navigacijos.
Svarbu atskirti tai nuo turinio SEO. Raktažodžių planavimas, tekstų rašymas, antraščių formuluotės ir turinio plėtra yra kita darbo dalis, o techninis SEO rūpinasi tuo, kad pati svetainė būtų tvarkinga, suprantama ir pasiekiama paieškos sistemoms be papildomų trikdžių.
Dizainas čia gali padėti, nes aiški vizuali struktūra dažnai veda prie aiškesnės navigacijos ir geresnio naudojimo, bet gražus vaizdas neišsprendžia problemos, jei puslapiai sumaišyti, filtrai kuria nereikalingus adresus, o svetainė telefone kraunasi per lėtai.
Kodėl sprendimai prieš dizainą lemia daugiau nei spalvos ar animacijos
Pirmiausia verta susitarti, kaip svetainė bus suplanuota ir kam ji iš tikrųjų skirta, nes vėliau vien vaizdu šitų dalykų nepataisysi.
Prieš piešiant pirmą ekraną verta nuspręsti, kokie puslapiai apskritai reikalingi verslui, o kurie atsiranda tik todėl, kad „taip daro visi“. Ne vienam smulkiam verslui užtenka aiškaus paslaugų medžio, kontaktų, kelių stiprių nukreipimo puslapių ir tvarkingo DUK, vietoje dešimčių silpnų puslapių, kurie tik apkrauna projektą ir vėliau reikalauja priežiūros.
Struktūra prasideda nuo adresų ir meniu
URL struktūra, puslapių hierarchija ir navigacija turi būti suplanuotos prieš dizainą, nes jos lemia, kaip žmogus ir paieškos sistema supras svetainės logiką. Jei paslaugos, kategorijos ar miestai sudėti be aiškios tvarkos, vėliau tenka pervadinti adresus, perdaryti meniu, tvarkyti vidines nuorodas ir taisyti tai, kas galėjo būti normaliai apgalvota iš pradžių.
Iš dizaino pusės dažnai matau norą pridėti daugiau blokų, daugiau judesio ir sudėtingesnių maketų, nes makete tai atrodo įspūdingai. Praktikoje dalis tokių sprendimų sulėtina svetainę telefone, apsunkina WordPress įgyvendinimą, padidina klaidų riziką ir paverčia administravimą nepatogiu klientui, kuris po paleidimo nori paprastai atnaujinti turinį.
Ne kiekvienas vizualinis sprendimas vertas savo kainos
Efektai savaime nėra problema, jei jie tarnauja turiniui ir nekenkia veikimui, bet dalis jų duoda labai mažai naudos palyginti su technine kaina. Kai iš anksto aišku, kas svarbiausia verslui, lengviau pasirinkti paprastesnį maketą, greitesnį užkrovimą ir tvarkingą puslapių logiką, vietoje gražaus, bet sunkaus sprendimo.
Svetainės struktūra: kaip paieška ir žmogus supranta jūsų puslapius
Kai puslapiai sudėti logiškai, lankytojui lengviau rasti kelią, o svetainei paprasčiau veikti be bereikalingos painiavos
Tvarkinga hierarchija reiškia, kad kiekvienas puslapis turi aiškią vietą, aiškų pavadinimą ir aiškų ryšį su kitais puslapiais.
Chaotiškoje svetainėje dažnai matau tą pačią paslaugą pateiktą keliose vietose skirtingais pavadinimais, meniu punktus be logikos ir adresus, kurie nieko nepasako nei žmogui, nei paieškos sistemai. Tokiu atveju klientas blaškosi tarp panašių puslapių, o vėliau atsiranda techninių dubliavimo, peradresavimų ir navigacijos taisymų.
Vidinės nuorodos turi vesti, o ne klaidinti
Vidinės nuorodos nėra tik mygtukai meniu viršuje. Jei turite paslaugų svetainę, pagrindinis paslaugos puslapis turi nuvesti į konkretesnius sprendimus, o šie – atgal į susijusią pagrindinę temą, kontaktus ar užklausos žingsnį. Taip žmogus juda natūraliai, o sistema mato, kurie puslapiai svarbūs ir kaip jie susiję tarpusavyje.
Kur tai matosi praktikoje
Lietuvos paslaugų verslui dažnai pakanka vieno aiškaus skyriaus „Paslaugos“, po kuriuo yra atskiri puslapiai, pavyzdžiui, interneto svetainių kūrimas, e. parduotuvių kūrimas ir svetainių priežiūra, vietoje padrikų nuorodų per visą svetainę. E. parduotuvėje logika panaši: pirmiausia tvarkingos kategorijos, tada subkategorijos, o miestų ar rinkų skyriai reikalingi tik tada, kai tikrai skiriasi pasiūla, pristatymas, kalba ar aptarnavimas, o ne vien todėl, kad norisi daugiau puslapių.
Greitis nėra vien PageSpeed balas
Verslui svarbu, kaip greitai žmogus realiai pamato turinį, gali spausti mygtukus ir be trukdžių judėti per svetainę.
Jei puslapis kraunasi lėtai, lankytojas tai pajunta dar prieš perskaitydamas pirmą sakinį. Dėl to nukenčia užklausos, krepšelio veiksmai ir bendras pasitikėjimas svetaine, o paieškos sistemoms techniškai tvarkingą ir greitai veikiantį puslapį paprasčiau nuskaityti bei įvertinti.
Skaičiai yra orientyras, ne tikslas pats savaime
Google PageSpeed ir Core Web Vitals padeda pamatyti, kur svetainė stringa, bet jie nerodo viso paveikslo. Praktikoje svarbu ne ekrano nuotrauka su aukštu balu, o tai, ar puslapis telefone greitai parodo svarbiausią informaciją, ar meniu reaguoja iš karto ir ar niekas nešokinėja kraunantis.
Kas dažniausiai lėtina svetainę
Dažniausios problemos yra sunkūs vaizdai, pertekliniai skriptai, per daug įskiepių, neapgalvotas šablonas ir prastas techninis įgyvendinimas. Kiekvienas iš šių dalykų atskirai gali atrodyti menkas, bet kartu jie apkrauna puslapį, didina užklausų skaičių, stabdo atvaizdavimą ir apsunkina WordPress priežiūrą po paleidimo.
Todėl greitis sprendžiamas ne vien optimizuojant po fakto, o priimant teisingus techninius sprendimus dar prieš dizainą ir programavimą. Kai iš anksto aišku, kokio turinio reikia, kokie elementai tikrai būtini ir kaip puslapis bus naudojamas telefone, galima išvengti daugumos lėtumo priežasčių dar jų nesukūrus.
WordPress gali būti tvarkingas arba problemiškas
Verslui svarbi ne vien platforma, o tai, kaip nuo pradžių suplanuojama struktūra, funkcijos ir techninis įgyvendinimas
WordPress visiškai tinka verslo svetainei ar e. parduotuvei, jei projektas statomas tvarkingai ir be nereikalingų sluoksnių.
Problemos dažniausiai prasideda tada, kai svetainė surenkama iš sunkaus šablono, puslapių kūrimo įrankio ir atsitiktinai parinktų įskiepių, kurie dubliuoja vieni kitų funkcijas. Iš pradžių tai atrodo patogu, nes daug kas veikia greitai, bet vėliau lėtėja puslapiai, komplikuojasi atnaujinimai ir darosi sunkiau palaikyti aiškią URL, antraščių, indeksavimo bei vidinės struktūros logiką.
Kur ilgalaikės problemos atsiranda greičiausiai
Praktikoje daugiausia bėdų matau tada, kai dizainas bandomas išspausti iš universalaus šablono, kuris prikrautas efektų, animacijų ir nenaudojamų modulių. Toks sprendimas dažnai apkrauna telefonus, apsunkina Core Web Vitals rodiklius ir verčia vėliau taisyti techninius dalykus, kurie turėjo būti numatyti dar prieš piešiant pirmą ekraną.
Kodėl tai svarbu techniniam SEO
Techninis SEO dažnai nukenčia ne dėl pačios platformos, o dėl skubotų sprendimų projekto pradžioje, kai neapsibrėžiama, kokių puslapių iš tikro reikia, kaip jie bus susieti ir kokios funkcijos verslui būtinos dabar. Jei architektūra aiški, įskiepiai parinkti pagal realų poreikį, o įgyvendinimas daromas disciplinuotai, WordPress išlieka tvarkingas ir po paleidimo, kai atsiranda naujas turinys, papildomos kalbos ar e. prekybos plėtra.
Indeksavimas, dubliavimas ir techninės klaidos, kurios atsiranda tyliai
Tai dalykai, kurių lankytojas dažnai nepastebi, bet pagal juos paieškos sistemos supranta, kurie puslapiai svarbūs, o kurie neturi būti rodomi.
Indeksavimo kontrolė paprastai reiškia labai žemišką sprendimą – kuriuos svetainės puslapius leidžiame matyti paieškai, o kuriuos paliekame tik vidiniam naudojimui, testavimui ar techninėms funkcijoms.
Kur tvarka dažniausiai pradeda byrėti
Praktikoje problemos dažnai atsiranda ne iš karto, o po kelių pakeitimų, kai susidubliuoja puslapiai, sena nuoroda nukreipiama į ne tą vietą, o dalis klaidų puslapių lieka be aiškaus sprendimo. Prie to dar prisideda filtrų, žymų ar archyvų perteklius, kuris sukuria daug panašių adresų be realios vertės verslui.
Kita dažna situacija – svarbus puslapis netyčia uždaromas paieškai, o menkavertis techninis ar laikinas puslapis paliekamas atviras indeksavimui.
Kodėl tai verta numatyti kūrimo metu
Kai svetainės struktūra, URL logika ir puslapių paskirtis apgalvojama dar kuriant, daug šių vietų galima sutvarkyti iš anksto be papildomų apeinamųjų sprendimų. Po paleidimo taisymas dažnai kainuoja daugiau, nes tenka peržiūrėti jau veikiančius adresus, peradresavimus, meniu ryšius ir tai, kas jau buvo suindeksuota.
Ką verta aptarti su kūrėju dar prieš pirmą dizaino variantą
Trumpas pokalbio sąrašas padeda iš karto matyti, kas verslui bus patogu, o kas vėliau kainuos laiką ir papildomus darbus.
Pirmiausia verta susitarti dėl puslapių medžio, navigacijos ir kalbų versijų, nes nuo to priklauso ne tik meniu, bet ir visa svetainės logika. Jei iš anksto aišku, kokie puslapiai bus pagrindiniai, kaip jie susiję tarpusavyje ir ar svetainė bus viena ar keliomis kalbomis, tada lengviau nuspręsti ir URL struktūrą be vėlesnio chaoso.
Kas turi veikti telefone be kompromisų
Didelė dalis lankytojų ateina iš mobilaus telefono, todėl verta tiesiai paklausti, kaip bus sprendžiamas mobilus veikimas, kokie greičio prioritetai numatyti ir ko bus atsisakyta, jei efektai pradės trukdyti naudoti svetainę. Čia pat verta aptarti ir vaizdų paruošimą – kas mažins failus, kokie formatai bus naudojami ir kas nutiks, jei vėliau įkelsite dideles nuotraukas iš telefono ar fotografo.
Kas valdoma patiems, o kas ne
Labai praktinis klausimas yra toks: ką po paleidimo galėsite lengvai valdyti patys, o kas reikalaus programuotojo. Pavyzdžiui, naujo puslapio sukūrimas, tekstų keitimas, nuotraukų atnaujinimas ar banerio pakeitimas turėtų būti paprasti darbai, o nestandartinės funkcijos, sudėtingi filtrai ar specifiniai integracijų pakeitimai dažnai jau turi techninius ribojimus.
Jei siūlomas sprendimas skamba miglotai, atrodo perteklinis arba remiasi vien madingu pavadinimu, prašykite aiškaus paaiškinimo be žargono. Geras kūrėjas gali paprastai pasakyti, kam to reikia jūsų verslui, kokią problemą tai sprendžia ir kada paprastesnis variantas būtų protingesnis.
Kada techninis SEO duoda daugiausia naudos
Ankstyvas techninis planavimas labiausiai atsiperka ten, kur vėliau klaidų taisymas paliestų daug puslapių, adresų ar kalbų versijų.
Daugiausia naudos jis duoda kuriant naują svetainę nuo nulio, nes tada galima ramiai susitarti dėl puslapių struktūros, URL logikos, indeksavimo taisyklių ir techninių prioritetų dar prieš maketus. Tokiu etapu lengviau priimti paprastus sprendimus, kurie vėliau netrukdo nei dizainui, nei turinio pildymui, nei plėtrai.
Perkėlimai ir perkurimai reikalauja daugiau drausmės
Esamos svetainės perkėlimas, perkurimas ar domeno struktūros keitimas yra jautrus etapas, nes čia jau būna seni adresai, vidinės nuorodos, PDF failai, meniu ryšiai ir kartais keli metai sukaupto turinio. Jei tai neįvertinama iš anksto, po paleidimo atsiranda neveikiančių puslapių, neteisingų peradresavimų ar situacijų, kai Google mato seną ir naują versiją be aiškaus ryšio.
Sudėtingesni projektai klaidas padaugina
E. parduotuvėse techninis planavimas ypač svarbus dėl kategorijų, filtrų, produktų variantų ir pasikartojančių puslapių rizikos. Kelių kalbų projektuose prisideda kalbinių versijų ryšiai, atskiri adresai ir aiški navigacija, o paslaugų svetainėse su aiškiomis kategorijomis ar tarptautiniu taikymu reikia tiksliai nuspręsti, kaip suskaidyti paslaugas, miestus, rinkas ar kalbas, kad svetainė neišsiplėstų į chaotišką puslapių rinkinį.
Mažai vizitinei svetainei su keliais puslapiais tai ne visada bus toks kritinis klausimas, bet kai projektas turi augti, keisti kalbas, plėsti paslaugas ar perimti senos svetainės turinį, techniniai sprendimai labai greitai tampa ne smulkmena, o pagrindu.
Klausimai – atsakymai
Ką sako svetainių kūrimo ekspertai
Dažnai matome tą pačią problemą – pirmiausia piešiamas vaizdas, o tik po to aiškinamasi, ką svetainė iš tikro turi daryti ir kaip tie puslapiai bus randami bei suprantami. Praktikoje daug ką išsprendžia vienas ankstyvas žingsnis: prieš dizainą susidėliojama puslapių struktūra ir jų tarpusavio ryšiai.
Jei techninis SEO paliekamas pabaigai, jis dažniausiai tampa taisymų sąrašu, o ne tvarkingo projekto dalimi. Dėl to ramesnis ir dažnai protingesnis sprendimas yra pradėti nuo architektūros, nes tada dizainas remiasi aiškiu pagrindu, o ne spėlionėmis.
Panašūs straipsniai
Peržiūrėkite kitus mūsų ekspertų sukurtus straipsnius apie svetainių kūrimą. Galbūt rasite Jums įdomias temas.