Tehniline SEO kontrollnimekiri: Veebisaidi parandamise lõplik nimekiri: Ülim nimekiri oma veebisaidi parandamiseks

.

Tehnilise SEO kontrollnimekiri

Crawling ja indekseerimine

Esimene asi, mida tehnilise auditi käigus vaadata, on see, kuidas otsingumootorid teie veebilehte indekseerivad ja roomavad. Lõppude lõpuks, kui teie saidi lehekülgi ei saa roomata, ei indekseerita neid ka (mõne erandiga). Sellest tulenevalt ei osale indekseerimata leheküljed ka edetabelis.

Vaadake Google Search Console’i lehe indekseerimise aruannet

Kõige täpsem ja usaldusväärsem viis oma veebisaidi indekseerimise analüüsimiseks on analüüsida Google Search Console’i lehekülgede indekseerimise aruannet. Vaadake indekseeritud lehekülgede aruannet ja kontrollige, millised leheküljed on indekseeritud. Vaadake, kas on lehekülgi, millel on filtreerimis- või sorteerimisvõimalused, kas on testlehekülgi või muid lehekülgi, mida te ei soovi indekseerida. Vaadake ka lehekülgi, mis on välja jäetud. Mitte kõik staatused aruandes “Väljajäetud leheküljed” ei ole probleemiks. Te ei peaks keskenduma kõikidele välistatud lehekülgedele, vaid ainult nendele, mille puhul Google’i käitumine ei vasta teie kavatsustele. Alljärgnevas tabelis näete staatusi, mis kipuvad tähelepanu ja põhjalikumat analüüsi nõudma:

Staatus	Mida see tähendab	Mida peaksite tegema
Ümbersuunamisviga	Google ei suutnud URL-i jälgida ümbersuunamisprobleemide tõttu.	Vähendage ümbersuunamiste arvu (1-2-le). Vältige lõpmatuid ja ringikujulisi ümbersuunamisi. – Veenduge, et lõplik URL tagastab 200 OK ja ei ole blokeeritud robots.txt/noindexis.
Serveri viga	Server tagastas 5xx vea.	Kontrollige serveri logisid. Veenduge, et sait ei ole ülekoormatud.- Parandage sisemised vead, eriti kui need korduvad.
Avastatud – ei ole indekseeritud	Google teab lehest, kuid ei ole seda veel indekseerinud. Näitab probleeme roomamise eelarvega.	Veenduge, et lehekülg on istutuskaardis. Lisage sellele siselinkid. Optimeerige roomamise eelarvet.
Kraanitud – ei indekseeritud	Google külastas lehte, kuid otsustas seda mitte indekseerida. Tavaliselt näitab lehe madalat kvaliteeti.	Parandage sisu kvaliteeti ja unikaalsust. Veenduge, et lehel ei ole duplikaate. Lisage sellele siselinkid.
Duplikaat ilma kasutaja poolt valitud kanoonilise leheküljeta	Google loeb lehte duplikaadiks, kuid te ei ole määranud kanoonilist.	Kontrollige lehepaare ja määrake vajalik kanooniline või vaadake saidi struktuur uuesti üle.
Duplikaat, Google valis kasutaja poolt valitud kanoonilisest erineva kanoonilise	Google ignoreeris teie määratud kanoonilist.	Põhjuseid võib olla palju; peate hoolikalt uurima lehe andmeid ja valima sobivaima strateegia (noindex, ümbersuunamine, eemaldamine, robots.txt, muudatused veebisaidi struktuuris ja sisemine linkimine).
Pehme 404	Lehekülg näeb välja “tühi” või “ei leitud”, kuid tagastab staatuse 200 OK.	Tagastage 404 või 410. Tehke ümbersuunamine. Parandage sisu. Blokeerige indekseerimisest.

Teised olekud ei anna tõenäoliselt märku probleemidest. Siiski tasub ka need aruanded üle vaadata, et veenduda, et lehti ei ole kogemata eemaldatud, ümber suunatud, kanoniseeritud või indekseerimisest blokeeritud.

Staatus	Mida see tähendab	Mida on vaja teada
Alternatiivne lehekülg nõuetekohase kanoonilise sildiga	Google tunnustas õigesti teie poolt määratud kanoonilist tagi.	Kõik töötab ootuspäraselt. Tegevust ei ole vaja teha. Veenduge, et olete määranud soovitud kanoonilise tagi.
URL on blokeeritud robots.txt poolt	Google ei saa lehte krawlida.	Kontrollige robots.txt faili. Lubage juurdepääs, kui soovite, et seda indekseeritaks.
URL märgitud “noindex	Leheküljel on noindex-direktiiv.	Veenduge, et noindex silt on seatud tahtlikult. Kui leht on oluline, eemaldage see tag.
Ei leitud (404)	Lehekülge ei ole olemas.	Kui see on oluline, taastage leht. Kui lehekülg on lõplikult kustutatud, veenduge, et sellele ei ole siselinkke.
Blokeeritud volitamata päringu tõttu (401)/ Blokeeritud keelatud juurdepääsu tõttu (403)	Leht on blokeeritud autoriseerimise tõttu või keelatud.	Lubage juurdepääs, kui leht peaks olema indekseeritud.
Lehekülg ümbersuunamisega	Lehekülg suunab ümber teisele.	Kontrollige, kas ümbersuunamine on ette nähtud ja korrektne.
URL on blokeeritud muu 4xx-probleemi tõttu	Lehekülg on ligipääsmatu muu 4xx-vea kui 404 tõttu (nt 403, 401, 410 jne).	Kontrollige HTTP olekukoodi käsitsi. Parandage juurdepääsu seaded. Seadistage õiged staatuskoodid või ümbersuunamised. Vajaduse korral lubage juurdepääs Googlebotile.

Google’i abikeskusest leiate leheküljearuande põhjaliku kirjelduse, sealhulgas näiteid probleemide kohta ja iga staatuse üksikasjaliku selgituse. Screaming Frog aitab ka indekseeritud või indeksist välja jäetud lehekülgede analüüsimisel. Selleks peate enne saidi sõelumise alustamist ühendama Google Search Console’i API-d. Ühendamiseks valige Configuration -> API Access -> Google Search Console. Klõpsake nupule Logi sisse Google’iga ja järgige juhiseid.

Kui olete ühendatud, lubage URL-ide kontrollimine ja saate ka lubada võimalust ignoreerida indekseerimise kontrolli URL-ide puhul, mida ei saa indekseerida.

Seejärel saate näha ja võrrelda iga lehe staatust Search Console’i järgi (nii, nagu Google seda näeb) ja selle tegelikku staatust, nagu see on määratud indekseerimisprotsessi käigus.

Pange tähele, et iga saidi jaoks on saadaval ainult 2000 URL-i päevas, seega on see meetod sobivam väikeste saitide jaoks.

Kontrollige, mis on teie sitemap.xml-is.

Sitemap.xml on XML-fail, mis annab otsingumootori otsingumootori roomikutele nimekirja saidi lehekülgedest, samuti (valikuliselt) teavet nende viimase muutmise kuupäeva, uuendamise sageduse ja soovitusliku roomamise prioriteedi kohta. See asub tavaliselt saidi juurest, näiteks: https://example.com/sitemap.xml. Sitemap.xml aitab otsingumootoritel kiiremini leida uusi või uuendatud lehekülgi. Lisaks on lehe lisamine sellesse faili üks, kuigi nõrk signaal lehe kanoonilise versiooni määramiseks.

Sitemap.xml fail on eriti kasulik:

• uute, väheste väliste linkidega saitide puhul;
• suurte, paljude lehekülgedega saitide puhul;
• palju meediasisu sisaldavate saitide puhul;
• uudistesaidid, mida uuendatakse sageli.

Sitemap.xml peaks sisaldama kõiki lehekülgi, mida soovite indekseerida. Võite kasutada sama Screaming Frog’i või teisi roomikuid, et analüüsida Sitemap.xml-i lisatud lehekülgi. Screaming Frogis saab sitemap.xml-i skaneerida eraldi nimekirjarežiimis või lisada selle tavalisse saidi skaneerimisse. Selleks aktiveerige jaotises Configuration -> Spider -> Crawl XML sitemap skaneerimine ja lisage nende sitemapide absoluutsed URL-d, mida soovite skaneerida. Ei ole soovitatav kasutada erinevaid veebiteenuseid Sitemapi genereerimiseks, kuna need võivad genereerida ainult staatilise sitemapi, mida ei uuendata automaatselt. Optimaalne võimalus on genereerida sitemap.xml, kasutades selle CMS-i pluginat, millel sait töötab, või kirjutada kohandatud skript, mis genereerib sitemap’i vastavalt kindlaksmääratud tingimustele ja uuendab seda automaatselt, kui saidil tehakse muudatusi. Sitemap.xml-i genereerimisel veenduge, et teie fail vastab sitemap.xml-protokollile. Selleks saate kasutada mitmesuguseid veebipõhiseid valideerijaid, näiteks https://www.xml-sitemaps.com/validate-xml-sitemap.html. Kas on vaja lisada kõik protokollis loetletud sildid? Mitte alati. Näiteks Google võtab arvesse ainult <loc> ja <lastmod> sildid. Veenduge, et <lastmod>-tagis olev kuupäev on täpne. Kui sellega püütakse manipuleerida, võib Google seda tagi ignoreerida.

Veenduge, et failis robots.txt ei ole vigu

Robots.txt-fail on esimene koht, kuhu otsingrobot vaatab enne saidi roomamist. See määrab kindlaks, milliseid veebisaidi osi saab või ei saa indekseerida ja milliseid lehekülgi otsingumootorid selle tulemusena indekseerivad. See peaks alati asuma aadressil https://example.com/robots.txt. See fail on vahend saidi roomamise (mitte indekseerimise!) haldamiseks. Mõned leheküljed, isegi kui need on robots.txt-s blokeeritud, võivad siiski indekseeritud olla (tavaliselt siis, kui neile on sisemised või välised lingid). Selliseid lehekülgi (mis on indekseeritud, kuigi robots.txt-s on blokeeritud) saab Google Search Console’is näha aruandes “Indekseeritud, kuigi robots.txt-s blokeeritud”.

Siin on, mida kindlasti kontrollida seoses robots.txt failiga tehnilise SEO-auditi raames:

1. Faili kättesaadavus

Fail peaks olema kättesaadav aadressil https://example.com/robots.txt ja andma vastuse staatuse 200 OK. Selle puudumine, allalaadimisvead või ümbersuunamised (301, 302, 403, 404) võivad takistada otsingumootoritel saidi roomamisreeglitest õigesti aru saada.

1. Süntaks ja korrektsus

Kontrollige, et faili struktuur vastab standardile. Näide põhilise malli kohta:

• User-agent: *
• Keelata: /admin/
• Allow: /public/
• Sisukaart: https://example.com/sitemap.xml

1. Keelata ja lubada direktiivid

Kontrollige, et tähtsad leheküljed ei oleks kogemata keelatud, nt:

• Avaleht (/)
• Tootekaardid (/product/)
• Blogi või artiklid (/blog/, /articles/)

Levinud viga on piltide, stiilide ja skriptide blokeerimine halduskaustade blokeerimisel. Sellisel juhul tuleks täpsustada, et kuigi halduskaust on blokeeritud, peaksid teatud tüüpi failid olema skaneerimiseks avatud. See juhtub sageli WordPressi saitidel, kui kogu kasutaja sisu sisaldav kaust Disallow: /wp-content on blokeeritud. Sellisel juhul saab skaneerimiseks avada ainult teatud formaadis faile:

• Allow: /wp-content/uploads/*.css: /wp-content/uploads/*.css
• Allow: /wp-content/uploads/*.js
• Allow: /wp-content/uploads/*.jpeg

Robots.txt kinnitamiseks ja lisatavate direktiivide testimiseks saate kasutada seda tööriista.

1. Kontrollige ühilduvust teiste direktiividega

Sageli tekivad vead, kui robots.txt on vastuolus:

• meta tag <meta name=”robots” content=”noindex”>
• canonical

Näiteks kui lehekülg on robots.txt-s avatud, kuid noindexi kaudu blokeeritud, siis see küll roomatakse, kuid indeksisse ei jõua. See on aktsepteeritav, kuid oluline on, et seda tehakse tahtlikult. Samuti on tavaline probleem, kui lähtekoodis on muid juhiseid botidele ja samaaegselt blokeeritakse leht robots.txt-s. Otsingumootorite robotid ei skaneeri robots.txt-s blokeeritud lehekülgi. Nad ei näe koodis määratud silte, näiteks kanoniseerimist. See tähendab, et selline canonical jääb lihtsalt arvestamata.

Kontrollige oma sisemist linkimist

Üks tehnilise auditi peamisi ülesandeid on tagada, et saidi sisemine linkimine toimiks õigesti. See tähendab, et kõik siselinkid peavad viima reaalsetele, olemasolevatele lehekülgedele, mis on indekseerimiseks avatud, tagastavad staatuskoodi 200 OK, ei sisalda ümbersuunamisi ja, mis kõige tähtsam, ei viita lehekülgedele, millel on 4xx/5xx vead. Esmapilgul võib see tunduda tühine detail, kuid praktikas võivad isegi valed siselinkid mõjutada negatiivselt:

• Veebisaidi otsingumootorite poolse roomamise tõhusust,
• sisemise SEO kaalu (PageRank) jagunemist,
• kasutajakogemust.

Esimene samm analüüsis on kõigi siselinkide kontrollimine vigade suhtes. Eriti oluline on tuvastada katkised lingid, mis viivad 404, 410 või muude vigadega (nt 403, 500) lehekülgedele. Allpool on esitatud tabel, kus on esitatud peamised siselinkides esinevad veatüübid, nende tähendus ja soovitatavad tegevused nende parandamiseks.

Vea tüüp	Mida see tähendab	Mida teha
404	Lehekülge ei leitud	Eemaldage link või asendage see toimiva lingiga.
403	Juurdepääs keelatud	Kontrollige juurdepääsu seadeid
301/302	Suunake ümber	Uuendage link lõplikule URL-le
5xx	Serveri viga	Kontrollige serverit või CMS-i.

Samuti on oluline analüüsida lehekülje hierarhia sügavust, st määrata, millisel tasandil ja mitu kliki kaugusel kodulehelt asub peamine sisu. On soovitav, et olulised leheküljed ei asuksid sügavamal kui kolmandal tasandil – see suurendab nende kättesaadavust nii otsingumootorite kui ka kasutajate jaoks. Üks analüüsi võtmeelementidest on “orbude” lehekülgede tuvastamine – need, millele ei viita ükski sisemine link. Isegi kui need leheküljed on lisatud istungikaardile, muudab siselinkide puudumine need vähem kättesaadavaks. Lisaks on oluline analüüsida ankrutekste – sõnu ja fraase, mis sisaldavad linke. Need peaksid olema asjakohased ja tähenduslikud, sest ankrutekstid aitavad otsingumootoritel mõista lingi konteksti.

Analüüsige roomamisstatistikat

Crawli statistika analüüs on viis mõista, kuidas Googlebot suhtleb saidiga: milliseid lehekülgi krabitakse, kui sageli ja kuidas see mõjutab SEO-d. Need andmed on saadaval Google Search Console → Settings → Crawl Statistics. Alljärgnevas tabelis näete kõige levinumaid probleeme, mida saate sellest aruandest teada:

Probleem	Mida aruandes otsida	Võimalikud põhjused
Crawlingi järsk vähenemine	Vähem roomamisi päevas	Kättesaadavusega seotud probleemid, valed seaded robots.txt-s, blokeeringud, 5xx vead.
Palju 4xx ja 5xx vigu	Vead URL-ides	Kustutatud leheküljed, katkised lingid, serveriprobleemid
Vastamisaeg on suurenenud	>1 sekund – hoiatusmärk	Hostinguprobleemid, serveri ülekoormus
Palju 3xx ümbersuunamisi	Ümbersuunamised otseste URL-ide asemel	Väärad ümbersuunamised, ümbersuunamisahelad, suur hulk siselinkide ümbersuunamisi
CSS/JS ei ole krabitud	Need puuduvad statistikast	Blokeeritud robots.txt poolt

Lisaks saab analüüsida serverilogisid. Need võimaldavad näha otsingubootide (mitte ainult Googlebot, vaid ka Bingbot, YandexBot ja teised ) tegelikke päringuid, mitte ainult Google Search Console’i agregeeritud andmeid. See on arenenud, “toores” diagnostikameetod, mis nõuab märkimisväärselt palju aega. Andmete visualiseerimiseks saate kasutada avatud lähtekoodiga tööriistu nagu GoAccess või Screaming Frog Log File Analyser.

Struktureeritud andmete rakendamine

Struktureeritud andmed on veebilehe eriline märgistusformaat, mis aitab otsingumootoritel lehe sisu täpsemalt ja sügavamalt mõista. See on Google’ile ja teistele otsingumootoritele “vihje” selle kohta, mis täpselt lehel on – artikkel, toode, retsept, ülevaade, video jne. Kuigi see ei ole ametlik edetabelisignaal, mõjutab see kaudselt edetabelit, parandades seda, kuidas otsingumootorid lehest aru saavad. Peamine standard või protokoll, mida kasutatakse veebisaitide struktureeritud andmete jaoks, on Schema.org. On ka teisi protokolle, näiteks OpenGraph, kuid seda kasutatakse sotsiaalsete võrgustike puhul. Schema.org on Google’i, Microsofti, Yahoo ja Yandexi ühisprojekt, mis on loodud veebis struktureeritud andmete ühtse standardi väljatöötamiseks ja haldamiseks. Schema.org sisaldab sadu entiteeditüüpe, millest kõige sagedamini kasutatavad on loetletud allpool olevas tabelis:

Kategooria	Entiteet (@tüüp)	Eesmärk
Sisu ja leheküljed	Artikkel	Artikkel või uudiste sisu
	Blogipostitus	Blogipostitus
	UudisedArtikkel	Uudisartikkel Google News’i jaoks
	KKK lehekülg	Korduma kippuvate küsimuste (KKK) lehekülg
	HowTo	Samm-sammuline juhend
	Veebileht	Üldine teave veebilehe kohta
Tooted ja pakkumised	Toode	Toote kirjeldus
	Pakkumine	Hinnapakkumine
	AggregateOffer	Erinevate müüjate toote hinnavahemik
Arvamused ja hinnangud	Ülevaade	Ülevaade toote või teenuse kohta
	Hindamine	Numbriline hinnang (sageli arvustuse sees)
	AggregateRating	Keskmine hinnang, mis põhineb mitmel hinnangul
Organisatsioonid ja inimesed	Organisatsioon	Ettevõtte või kaubamärgi kirjeldus
	LocalBusiness	Kohalik ettevõte koos kontaktandmete ja ajakavaga
	Isik	Isik (nt artikli autor, kõneleja jne)
Sündmused	Sündmus	Online- või offline-sündmus
Navigatsioon ja struktuur	BreadcrumbList	Breadcrumbs navigeerimine
	SiteNavigationElement	Peamised menüüelemendid
Multimeedia	VideoObjekt	Video koos metaandmetega (videolõikude jaoks)
	ImageObject	Pilt koos kirjeldusega
Haridus ja töökohad	Kursus	Veebikursus või koolitusprogramm
	JobPosting	Vaba töökoht (Google for Jobs jaoks)

Struktureeritud andmeid on soovitatav rakendada JSON-LD-vormingus. See plokk paigutatakse HTML-dokumendi <head> või <body>, kuid seda ei kuvata kasutajale – seda loevad otsingurobotid. Kõik suuremad otsingumootorid, nagu Google, Bing ja Yahoo, toetavad seda formaati. Allpool on toodud näide JSON-LD koodist: <script type=”application/ld+json”> { “@context”: “https://schema.org”, “@type”: “artikkel”, “pealkiri”: “Mis on JSON-LD?”, “author”: { “@type”: “Person”, “name”: “John Smith” }, “datePublished”: “</script> Struktureeritud andmete rakendamisel järgige Schema.org protokolli ja kasutage valideerijat, et kontrollida rakendatud mikroandmete tüüpide õigsust. mõned Schema.org protokolli struktureeritud andmete tüübid võivad aidata ka rikkalike snippettide kuvamisel Google’i otsingutulemustes. Pange tähele, et Google’i nõuded rikkalike snippettide struktureeritud andmetele erinevad veidi Schema.org standardist. Sageli tuleb täpsustada rohkem välju, kui Schema.org protokoll nõuab. seega, kui soovite saavutada Rich Snippet’i, järgige Google’i juhiseid struktureeritud andmete kohta. Mikroandmete rakendamise õigsust saate kontrollida rich snippet validatoriga. On olemas ka palju mikroandmete generaatoreid, kuid need suudavad luua ainult staatilist koodi, mis ei uuene lehe sisu muutudes. Selle tagamine, et mikroandmetes sisalduv teave vastab sellele, mis on kasutajatele lehel nähtav, on osa Google’i nõuetest struktureeritud andmetele. Kui struktureeritud andmeid käsitlevat poliitikat rikutakse, võib leht kaotada kõik rich snippet’id ja mõnel juhul võib teda oodata manuaalne karistus. Seetõttu veenduge, et teie mikroandmed on automaatselt genereeritud ja automaatselt ajakohastatud.

Sisu

Tehnilise SEO-auditi osana on oluline hinnata põhilisi sisuomadusi: alates pealkirjade ja metatagide struktuurist kuni piltide alt-atribuutide ja võimalike dubleeritud lehekülgede olemasoluni. Need elemendid mõjutavad otseselt nii indekseerimist kui ka seda, kuidas otsingumootorid saiti tajuvad.

Testige oma veebisaiti täielike duplikaatide suhtes

Täielikud duplikaadid tekivad siis, kui identne sisu on veebisaidil kättesaadav erinevate URL-aadresside kaudu. Duplikaadid võivad täielikult kahjustada teie saidi järjestust. Kõige levinumad täielikud duplikaadid on järgmised:

• Kättesaadavus nii HTTP kui ka HTTPS kaudu
• Kättesaadavus nii WWW-ga kui ka ilma selleta
• Kättesaadavus koos või ilma kaldkriipsuta
• URL-ide juurdepääsetavus suur- ja väiketähtedega
• Lehe juurdepääsetavus faililaienditega nagu .html, .htm, .php, .aspx ja ilma nendeta
• Parameetrid, mis ei muuda lehe sisu, näiteks UTM-tähed
• Identne sisu erinevate URL-ide all. Näiteks toode on loetletud kahes kategoorias, mis on kättesaadavad kahe erineva URL-i kaudu. Või toote lehekülg, mis on juurdepääsetav kategooria URL-is ja ilma selleta.
• Saidi testversioonid (DEV-domeen, mida kasutatakse arendamiseks).

URL-variantidega seotud lehe duplikaatide leidmiseks testige URL-id käsitsi ja kontrollige nende URL-variantide puhul serveri vastusekoodi. Serveri vastusekoodide kontrollimiseks võite kasutada mis tahes vahendit, näiteks https://httpstatus.io/. Sisestage URL-variandid ja kontrollige nende juurdepääsetavust.

HTTP/HTTPS, www/without-www, kaldkriipsuga/mittekriipsuga, suur-/väike-kirjutusega ning selliste laiendustega nagu .html, .htm, .php, .aspx ja ilma nendeta lehekülgede juurdepääsetavusega seotud probleemide lahendamiseks on vaja luua 301 ümbersuunamine eelistatud versioonile. Kui duplikaadid on leitud identse sisu kättesaadavuse tõttu, lisades või eemaldades URLi osasid (näiteks toode on saadaval kahes kategoorias), on kõige parem üle vaadata URLi struktuur ja saidi struktuur. UTM-i ja muude parameetrite puhul võib lahenduseks olla ka kanoniseerimine. Oluline on siiski märkida, et Google käsitleb kanoonilist sildi kui soovitust ja lõplik otsus, milline URL valida, jääb Google’ile. Kui saidi testversioon leitakse Google’i indeksist, tuleks see indekseerimisest blokeerida ja selle eemaldamise taotlus saata Google Search Console’i kaudu.

Lahendage lehe osalised duplikaadid

Lehekülje osalised duplikaadid tekivad siis, kui kaks või enam lehekülge saidil sisaldavad väga sarnast, kuid mitte täiesti identset sisu. Kõige tavalisemad osalised duplikaadid on järgmised:

• Lehekülgede sorteerimine
• Lehekülgede filtreerimine
• lehekülgede liigendamine
• Sarnaste toodetega leheküljed (nt tooted erinevad ainult värvi poolest).
• Saidi mitu versiooni samas keeles, kuid eri piirkondade jaoks (nt kolm ingliskeelset lehekülge USA, Ühendkuningriigi ja Austraalia jaoks).

Loomulikult on iga veebisait ainulaadne ja tehnilise auditi käigus võite tuvastada muid dubleeriva sisu juhtumeid, mis nõuavad konkreetseid lahendusi. Ülaltoodud näited on siiski kõige levinumad. Osalised dubleeringud leitakse tavaliselt saidi roomikute poolt teostatava saidi roomamise käigus. Neil on korduvad parameetrid ja neil võib olla sama pealkiri ja H1 nagu põhikategooria lehekülgedel. Osaliste duplikaatide kõrvaldamiseks ei saa luua ümbersuunamist, sest need leheküljed on saidi funktsionaalsuse jaoks vajalikud. Järgnevalt arutame meetodeid osaliste duplikaatide käsitlemiseks.

Lehekülgede sorteerimine ja filtreerimine

Neid lehekülgi saab robots.txt-failis roomamise eest blokeerida, kuigi Google võib seda ignoreerida, eriti kui nendele lehekülgedele viitavad lingid. See aitab säilitada indekseerimise eelarvet. Neid saab blokeerida ka direktiivi <meta name=”robots” content=”noindex, nofollow” /> abil, mis takistab nende lehekülgede indekseerimist, kuid ei ütle Google’ile, et neid ei tohiks indekseerida. Parim lähenemisviis sellisel juhul on kasutada JavaScripti, et uuendada lehe sisu, kui kasutaja rakendab sorteerimist või filtreerimist, ilma et tekiksid täiendavad URL-d ja lingid filtreerimis- või sorteerimislehtedele.

Erinevatel URL-idel saadaval olevad tootevariandid

Ideaalis tuleks kõik tootevariandid koondada ühele lehele, kus kasutaja saab soovitud värvi või suuruse valida ilma URL-i muutmata, kasutades selleks JavaScripti. Kui aga iga variandi jaoks kasutatakse eraldi lehekülge, tuleks määrata kanooniline link põhitooteleheküljele. Kuid nagu eespool mainitud, võib Google kasutaja poolt määratud kanoonilist linki ignoreerida.

Lehekülgede küljendamine

Lehekülgede indekseerimist ei tohiks blokeerida. Selleks, et Google loeks kategooria esimest lehekülge peamiseks leheküljeks:

• Lisage sitemap.xml-faili ainult esimene lehekülg.
• Lisage link kategooria pealehele kõigile lehekülgede paginatsioonilehtedele.
• Lisage leheküljenumbrid lehekülgede pealkirjale ja H1-lehekülgedele. Näiteks “Valged särgid – 2. lehekülg”.

Ühes keeles, kuid eri piirkondade jaoks kättesaadavad leheküljed

Sellisel juhul tuleb kasutada Hreflangi atribuute. Neid kasutatakse selleks, et öelda otsingumootoritele, millist keelt ja piirkondlikku versiooni veebilehest nad peaksid kasutajatele nende keele-eelistuste ja asukoha põhjal näitama. Hreflang-atribuutide rakendamiseks on mitu võimalust:

• HTTP-pealkirjades
• <head>-sektsiooni siltide kaudu
• Sitemap.xml’i siltide kaudu

Kõige lihtsam meetod on rakendada <head> sektsioonis olevate siltide kaudu. Seal on reeglid, millele <head> sektsioonis olevate siltide kaudu rakendatud hreflang atribuudid peaksid vastama:

• • Atribuut peaks olema järgmises formaadis: <link rel=”alternate” hreflang=”lang_code_country_code” href=”url-of-page” />
  • Keele- ja riigikoodid peaksid olema kehtivad. Iga keelemutatsiooni jaoks kehtiva koodi valimiseks vaadake seda lehekülge.

• Iga keeleversioon peab oma hreflang-atribuutides loetlema nii enda kui ka kõik teised keeleversioonid. See tähendab, et igal lehel peab olema sama arv hreflang-atribuute

• Lingid hreflang-atribuutides peavad olema absoluutsed ja indekseeritavad.

Näide koodist: <link rel=”alternate” href=”https://example.com/en-us/page” hreflang=”en-us” /> <link rel=”alternate” href=”https://example.com/en-gb/page” hreflang=”en-gb” /> <link rel=”alternate” href=”https://example.com/en-us/page” hreflang=”x-default” />

Kontrollida pealkirju, h1, h2 ja kirjeldusi dubleeringute suhtes.

Kuigi pealkirjad, kirjeldused ja H1-H6-pealkirjad on seotud lehekülje SEO-ga, võib nende analüüs tehnilise auditi raames olla kasulik duplikaatide tuvastamiseks. Nende analüüsimiseks võite kasutada mis tahes roomikut, mis kogub neid silte. Kui leiate topeltpealkirju, H1-H6-tippe ja kirjeldusi, analüüsige lehe andmeid ja tuvastage duplikaadi põhjus. Selle põhjuseks võib olla saidi kättesaadavus nii HTTP kui ka HTTPS kaudu, põhikategooria siltide dubleerimine filtreerimislehtedel või lihtsalt inimlik viga, kus need sildid on valesti täidetud.

Optimeerige piltide alt-atribuute

Alt atribuut on HTML atribuut, mida kasutatakse <img> sildi sees, näiteks nii: <img src=”image.jpg” alt=” Pildi kirjeldus”>. Selle peamine eesmärk on anda pildi sisu tekstiline kirjeldus. See tekst kuvatakse, kui pilt ei lae ja seda loevad ette ekraanilugejad, et aidata nägemispuudega kasutajaid. Õige, kirjeldav alt-tekst võib aidata teie piltidel pildiotsingus paremale kohale jõuda ja parandada lehe üldist asjakohasust. Kui teil on palju visuaalset sisu sisaldav veebisait, siis on alt-atribuutide optimeerimine olulisem samm kui klassikaliste veebisaitide puhul, mis tuginevad tekstisisule. Paljud roomajad nagu Screaming Frog, Ahrefs, SemRush jne analüüsivad alt-atribuute ja sealt saate andmeid puuduvate või tühjade alt-atribuutide kohta. Kirjeldavate alt-atribuutide loomisest saate lugeda rohkem Google’i ametlikest dokumentidest.

Veebisaidi kiirus, mobiilsus ja kasutajasõbralikkus

Kasutage HTTPs protokolli

Turvalise HTTPS-protokolli kasutamine on oluline, et tagada kasutaja ja serveri vahelise andmeedastuse turvalisus. See mitte ainult ei suurenda kasutajate usaldust, vaid avaldab ka positiivset mõju SEO-le. HTTPS-i kontrollimiseks vaadake lihtsalt brauseri aadressiribale – seal peaks ilmuma luku ikoon. Üksikasjalikuks analüüsiks võite kasutada SSL Labs teenust, mis annab täieliku aruande SSL-sertifikaadi staatuse kohta ja tuvastab võimalikud probleemid. Samuti on oluline tagada, et ei oleks segatud sisu – HTTP-ressursid HTTPS-lehekülgedel. Selle analüüsi jaoks saate kasutada Google Search Console’i HTTPS-aruannet, mis näitab nii HTTP- kui ka HTTPS-iga URL-aadressid.

Allikas: Search Console meie klient

Parandage Core Web Vitals

Core Web Vitals on Google’i pakutud mõõdikud, mille abil saab hinnata veebisaidi kasutajakogemuse kvaliteeti. Need mõõdikud keskenduvad laadimiskiirusele, interaktiivsusele ja lehekülje sisu visuaalsele stabiilsusele. Need hõlmavad kolme põhinäitajat:

Mõõdik	Kirjeldus	Optimaalne väärtus
Suurim sisuline värv (LCP)	Mõõdab lehe suurima nähtava elemendi (nt pilt või tekst) laadimisaega.	Alla 2,5 sekundi
Esimese sisendi viivitus (FID)	Mõõdab aega, mis kulub lehe reageerimiseks esimesele kasutaja interaktsioonile (nt nupule või lingile klõpsamine).	Vähem kui 100 millisekundit
Kumulatiivne paigutusnihe (CLS)	Hindab lehe visuaalset stabiilsust, st kui palju elemendid lehekülje laadimise ajal liiguvad.	Vähem kui 0,1

Reaalsetelt kasutajatelt kogutud andmeid saab vaadata Search Console’i aruandes “Core web vitals” (koondandmed) või PageSpeed Insights ’is (üksikute testide puhul). Core Web Vitals’iga töötades pidage meeles, et peate määratlema probleemid, millel on suur mõju CWV-meetritele. Näiteks LCP optimeerimisel peate määratlema, milline 4 aspektist (TTFB, Load Delay, Load Time või Render delay) aitab kõige rohkem kaasa kõrgele LCP skoorile. Allpool toodud näites on näha, et me ei pea keskenduma TTFB või Load Time optimeerimisele. Selle asemel võime suunata kogu oma energia Load Delay ja seejärel Render Delay parandamisse.

Allikas: https://pagespeed.web.dev/ – nike.com veebisaidi test (lihtsalt näide). Domeen on hägune

Veenduge, et teie veebisait on mobiilisõbralik

Mobiilisõbralikkus on muutunud ülioluliseks teguriks alates 2018. aastast, kui Google läks üle mobiilsidepõhisele indekseerimisele (mobile-first indexing ). See tähendab, et Google kasutab nüüd eelkõige veebisaidi mobiiliversiooni järjestamiseks ja indekseerimiseks, mitte töölauaversiooni. Google Search Console’is saate oma lehekülgi testida, klõpsates URL-i kontrollimise tööriista “Test Live URL” ja näha, kuidas Googlebot-Mobile seda näeb.

Piltide tihendamine

Piltide optimeerimine, mille eesmärk on nende tihendamine ilma kvaliteeti kaotamata, aitab kiirendada veebilehe laadimist, eriti kui lehekülgedel on palju graafilist sisu. Piltide tihendamiseks saab kasutada selliseid veebipõhiseid vahendeid nagu TinyPNG või Squoosh. Samuti tasub kontrollida, kas kasutatakse kaasaegseid pildiformaate, näiteks WebP, sest need võivad faili suurust märkimisväärselt vähendada.

Kasutage CDNi rahvusvaheliste veebisaitide jaoks

CDNi kasutamine on mõistlik, kui teie veebisait teenindab geograafiliselt kaugel asuvaid piirkondi. CDN (Content Delivery Network) jaotab saidi sisu kasutajatele lähemal asuvatele serveritele, vähendades laadimise ajal latentsust. CDNi kasutamist saate kontrollida, uurides HTTP-päringu päiseid brauseri arendajatööriistades (vahekaart Network), kus võivad olla viited CDNi pakkujale, näiteks Cloudflare’ile või Akamai’le. CDNi testimiseks on olemas ka veebipõhised tööriistad. CDNi konfigureerimine toimub tavaliselt veebimajutuse paneeli või CMSi kaudu. Vahemälu kasutamine Vahemälu võimaldab brauseritel ja proxy-serveritel salvestada ressursside koopiaid, vähendades serveri koormust ja kiirendades laadimist järgmistel külastustel. Puhverdamise korrektsust saate kontrollida brauseri arendajatööriistades – vaadake jaotises Network päiseid Cache-Control, Expires ja ETag. Google PageSpeed Insights annab ka soovitusi vahemälu salvestamiseks. Oluline on, et staatilistel ressurssidel (pildid, skriptid, stiilid) oleksid õiged vahemälu seaded ja serveril peaksid olema vastavad reeglid konfigureeritud (nt .htaccessi või nginxi konfiguratsioonis). Puhverdamise kontrollimiseks saate kasutada selliseid veebiteenuseid nagu GiftOfSpeed.

Kokkuvõte

Veebisaidi tehniline audit ei ole ühekordne protseduur, vaid pidev protsess, mis nõuab regulaarset tähelepanu tehnilistele teguritele, mis võivad mõjutada selle jõudlust ja nähtavust. Kuna iga veebisait on ainulaadne, on kontrollide konkreetne rõhuasetus ja sagedus erinev. See tehnilise SEO-auditi kontrollnimekiri aitab teil tagada, et te ei ole midagi olulist unustanud.