Tehniskais SEO kontrolsaraksts: galīgais saraksts, lai uzlabotu savu vietni

Tehniskais SEO kontrolsaraksts

Rāpošana un indeksēšana

Pirmā lieta, kas jāaplūko tehniskā audita laikā, ir tas, kā meklētājprogrammas indeksē un pārmeklē jūsu vietni. Galu galā, ja jūsu vietnes lapas nevar pārmeklēt, tās netiks indeksētas (ar dažiem izņēmumiem). Līdz ar to lapas, kas nav pārstāvētas indeksā, nepiedalīsies rangā.

Lapu indeksēšanas pārskats pakalpojumā Google Search Console

Visprecīzākais un uzticamākais veids, kā analizēt vietnes indeksēšanu, ir analizēt lapu indeksēšanas pārskatu pakalpojumā Google Search Console.

Apskatiet indeksēto lapu pārskatu un pārbaudiet, kuras lapas ir indeksā. Pārbaudiet, vai ir lapas ar filtrēšanas vai kārtošanas opcijām, vai ir testa lapas vai citas lapas, kuras nevēlaties indeksēt.

Apskatiet arī lapas, kas ir izslēgtas.

Ne visi statusi pārskatā Izslēgtās lapas ir problēma. Jums nevajadzētu pievērst uzmanību visām izslēgtajām lapām, bet tikai tām, kurās Google uzvedība neatbilst jūsu nodomiem.

Zemāk esošajā tabulā varat redzēt statusus, kuriem mēdz būt nepieciešama uzmanība un dziļāka analīze:

Statuss	Ko tas nozīmē	Kas jums jādara
Novirzīšanas kļūda	Google nevarēja sekot URL novirzīšanas problēmu dēļ.	Samaziniet novirzījumu skaitu (līdz 1-2). Izvairieties no bezgalīgiem un apļveida novirzījumiem.- Pārliecinieties, ka galīgais URL atgriež 200 OK un nav bloķēts robots.txt/noindex.
Servera kļūda	Serveris atgrieza 5xx kļūdu.	Pārbaudiet servera žurnālus. Pārliecinieties, ka vietne nav pārslogota.- Labojiet iekšējās kļūdas, it īpaši, ja tās atkārtojas.
Atklāts – nav indeksēts	Google zina par lapu, bet to vēl nav pārmeklējis. Norāda problēmas ar pārmeklēšanas budžetu.	Pārliecinieties, ka lapa atrodas vietnes kartē. Pievienojiet tam iekšējās saites. Optimizējiet pārmeklēšanas budžetu.
Pārmeklēts — nav indeksēts	Google apmeklēja lapu, bet izvēlējās to neindeksēt. Parasti norāda uz zemu lapas kvalitāti.	Uzlabojiet satura kvalitāti un unikalitāti. Pārliecinieties, vai lapā nav dublikātu. Pievienojiet tam iekšējās saites.
Dublikāts bez lietotāja izvēlētā kanoniskā	Google uzskata, ka lapa ir dublikāts, bet jūs nenorādījāt kanonisku.	Pārbaudiet lappušu pārus un norādiet nepieciešamo kanonisko vai pārskatiet vietnes struktūru.
Dublikāts, Google izvēlējās citu kanonisko nekā lietotājs	Google ignorēja jūsu norādīto kanonisko daļu.	Var būt daudz iemeslu; Jums rūpīgi jāpārbauda lapas dati un jāizvēlas vispiemērotākā stratēģija (noindex, novirzīšana, noņemšana, robots.txt, izmaiņas vietnes struktūrā un iekšējā saite).
Mīksts 404	Lapa izskatās “tukša” vai “nav atrasta”, bet atgriež statusu 200 OK.	Atgrieziet 404 vai 410. Veiciet novirzīšanu. Uzlabojiet saturu. Bloķēt no indeksēšanas.

Pārējie statusi, iespējams, neliecina par problēmām. Tomēr šos ziņojumus ir vērts arī pārskatīt, lai pārliecinātos, ka lapas nav noņemtas, novirzītas, kanonizētas vai bloķētas no indeksēšanas kļūdas dēļ.

Statuss	Ko tas nozīmē	Kas jums jāzina
Alternatīva lapa ar atbilstošu kanonisko atzīmi	Google pareizi atzina jūsu norādīto kanonisko kanonikā.	Viss darbojas, kā gaidīts. Nav nepieciešama nekāda darbība. Pārliecinieties, ka esat norādījis vēlamo kanonisko kanonikā.
URL bloķēja robots.txt	Google nevar pārmeklēt lapu.	Pārbaudiet robots.txt failu. Atļaut piekļuvi, ja vēlaties, lai tā tiktu indeksēta.
URL atzīmēts ar “noindex”	Lapai ir noindex direktīva.	Pārliecinieties, vai noindex tags ir iestatīts apzināti. Ja lapa ir svarīga, noņemiet šo tagu.
Nav atrasts (404)	Lapa nepastāv.	Ja tas ir svarīgi, atjaunojiet lapu. Ja lapa ir neatgriezeniski izdzēsta, pārliecinieties, vai uz to nav iekšēju saišu.
Bloķēts nesankcionēta pieprasījuma dēļ (401)/ Bloķēts piekļuves aizlieguma dēļ (403)	Lapa ir bloķēta ar autorizāciju vai aizliegta.	Atļaut piekļuvi, ja lapa ir jāindeksē.
Lapa ar novirzīšanu	Lapa novirza uz citu.	Pārbaudiet, vai novirzīšana ir paredzēta un pareiza.
URL bloķēts citas 4xx problēmas dēļ	Lapa nav pieejama 4xx kļūdas dēļ, kas nav 404 (piemēram, 403, 401, 410 utt.).	Manuāli pārbaudiet HTTP statusa kodu. Labojiet piekļuves iestatījumus. Iestatiet pareizus statusa kodus vai novirzījumus. Ja nepieciešams, atļaujiet piekļuvi Googlebot.

Google palīdzības centrā varat atrast visaptverošu lapas pārskata aprakstu, tostarp problēmu piemērus un detalizētu katra statusa skaidrojumu.

Kliedzošs varde var arī palīdzēt analizēt lapas, kas ir indeksētas vai izslēgtas no indeksa. Lai to izdarītu, pirms vietnes pārmeklēšanas sākšanas ir jāpievieno Google Search Console API.
Lai izveidotu savienojumu, atveriet sadaļu Konfigurācija > API piekļuve > Google Search Console. Noklikšķiniet uz Pierakstīties, izmantojot Google un izpildiet norādījumus.

Pēc savienojuma izveides iespējojiet URL pārbaudi, kā arī varat iespējot opciju ignorēt indeksēšanas pārbaudi vietrāžu URL, kurus nevar indeksēt.

Pēc tam varēsiet skatīt un salīdzināt katras lapas statusu atbilstoši Search Console (Google to redzēt) un tās faktisko statusu, kas noteikts pārmeklēšanas procesā.

Lūdzu, ņemiet vērā, ka katrai vietnei ir pieejami tikai 2000 URL dienā, tāpēc šī metode ir vairāk piemērota mazām vietnēm.

Pārbaudiet, kas ir jūsu sitemap.xml

Sitemap.xml ir XML fails, kas nodrošina meklētājprogrammu rāpuļprogrammām vietnes lapu sarakstu, kā arī (pēc izvēles) informāciju par to pēdējās modifikācijas datumu, atjaunināšanas biežumu un ieteicamo pārmeklēšanas prioritāti.

To parasti novieto vietnes saknē, piemēram: https://example.com/sitemap.xml. Sitemap.xml palīdz meklētājprogrammām ātrāk atrast jaunas vai atjauninātas lapas. Turklāt lapas iekļaušana šajā failā ir viens no signāliem , lai noteiktu lapas kanonisko versiju, kaut arī vāja.

sitemap.xml fails ir īpaši noderīgs:

• jaunas vietnes ar maz ārējo saišu;
• lielas vietnes ar daudzām lapām;
• vietnes ar daudz mediju satura;
• ziņu vietnes, kas tiek bieži atjauninātas.

Sitemap.xml jāsatur visas lapas, kuras vēlaties indeksēt.

Varat izmantot to pašu Screaming Frog vai citus rāpotājus, lai analizētu Sitemap.xml iekļautās lapas. Programmā Screaming Frog sitemap.xml var skenēt atsevišķi saraksta režīmā vai iekļaut parastā vietnes skenēšanā. Lai to izdarītu, sadaļā Konfigurācija -> Spider -> Crawl aktivizējiet XML vietnes kartes skenēšanu un pievienojiet vietnes kartes absolūtos URL, kurus vēlaties pārmeklēt.

Vietnes kartes ģenerēšanai nav ieteicams izmantot dažādus tiešsaistes pakalpojumus, jo tie var ģenerēt tikai statisku vietnes karti, kas netiks automātiski atjaunināta. Optimālais variants ir ģenerēt sitemap.xml, izmantojot spraudņus CMS, kurā darbojas vietne, vai uzrakstīt pielāgotu skriptu, kas ģenerē vietnes karti saskaņā ar noteiktiem nosacījumiem un automātiski atjaunina to, kad tiek veiktas izmaiņas vietnē.

Ģenerējot sitemap.xml, pārliecinieties, vai fails atbilst sitemap.xml protokolam. Šim nolūkam varat izmantot dažādus tiešsaistes validatorus, piemēram, https://www.xml-sitemaps.com/validate-xml-sitemap.html.

Vai ir nepieciešams iekļaut visus protokolā uzskaitītos tagus? Ne vienmēr. Piemēram, Google ņem vērā tikai <loc> un <lastmod> tagus. Pārliecinieties, ka datums tagā <lastmod> ir precīzs. Ja tiek mēģināts manipulēt ar to, Google var ignorēt šo tagu.

Pārliecinieties, ka robots.txt nav kļūdu

robots.txt fails ir pirmā vieta, kur meklēšanas robots meklē pirms vietnes pārmeklēšanas. Tas nosaka, kuras vietnes sadaļas var vai nevar pārmeklēt, un līdz ar to kuras lapas indeksēs meklētājprogrammas. Tam vienmēr jābūt izvietotam https://example.com/robots.txt.

Šis fails ir rīks vietnes pārmeklēšanas (nevis indeksēšanas!) pārvaldībai. Dažas lapas, pat ja tās ir bloķētas robots.txt, joprojām var indeksēt (parasti, ja uz tām ir iekšējas vai ārējas saites). Šādas lapas (indeksētas, neskatoties uz to, ka tās ir bloķētas robots.txt) ir redzamas Google Search Console pārskatā “Indeksēts, lai gan bloķēts robots.txt”.

Lūk, kas noteikti jāpārbauda attiecībā uz robots.txt failu tehniskā SEO audita ietvaros:

1. Faila pieejamība

Failam jābūt pieejamam https://example.com/robots.txt un jāpiešķir atbildes statuss 200 OK. Tās neesamība, lejupielādes kļūdas vai novirzīšana (301, 302, 403, 404) var neļaut meklētājprogrammām pareizi izprast vietnes pārmeklēšanas noteikumus.

1. Sintakse un pareizība

Pārbaudiet, vai faila struktūra atbilst standartam. Pamata veidnes piemērs:

• Lietotāja aģents: *
• Neatļaut: /admin/
• Atļaut: /public/
• Vietnes karte: https://example.com/sitemap.xml

1. Aizliegt un atļaut direktīvas

Pārbaudiet, vai svarīgas lapas nav nejauši aizliegtas, piemēram:

• Sākums (/)
• Produktu kartes (/product/)
• Emuārs vai raksti (/blog/, /articles/)

Bieži sastopama kļūda ir attēlu, stilu un skriptu bloķēšana, bloķējot administratīvās mapes. Šādā gadījumā jānorāda, ka, lai gan administratīvā mape ir bloķēta, dažu veidu failiem jābūt atvērtiem skenēšanai. Tas bieži notiek WordPress vietnēs, kad mape ar visu lietotāja saturu, Disallow: /wp-content ir bloķēta.

Šajā gadījumā skenēšanai var atvērt tikai noteikta formāta failus:

• Atļaut: /wp-content/uploads/*.css
• Atļaut: /wp-content/uploads/*.js
• Atļaut: /wp-content/uploads/*.jpeg

Lai validētu savu robots.txt un pārbaudītu pievienotās direktīvas, varat izmantot šo rīku.

1. Pārbaudiet saderību ar citām direktīvām

Kļūdas bieži rodas, ja robots.txt ir pretrunā ar:

• meta tags <meta name=”roboti” content=”noindex”>
• Kanonisko

Piemēram, ja lapa ir atvērta robots.txt, bet bloķēta, izmantojot noindex, tā tiks pārmeklēta, bet nenonāks indeksā. Tas ir pieņemami, bet ir svarīgi, lai tas tiktu darīts apzināti.

Arī izplatīta problēma ir tad, ja avota kodā ir citi norādījumi robotiem un vienlaicīga lapas bloķēšana robots.txt. Meklētājprogrammu roboti neskenē lapas, kas bloķētas robots.txt. Viņi neredz kodā norādītos tagus, piemēram, kanonizāciju. Tas nozīmē, ka šāds kanonisks būs vienkārši neizskaidrots.

Iekšējās saites pārbaude

Viens no galvenajiem tehniskā audita uzdevumiem ir nodrošināt, ka vietnes iekšējā saite darbojas pareizi. Tas nozīmē, ka visām iekšējām saitēm ir jāved uz reālām, esošajām lapām , kas ir atvērtas indeksēšanai, jāatgriež 200 OK statusa kods, nesatur novirzījumus un, pats galvenais, nenorāda uz lapām ar 4xx/5xx kļūdām. No pirmā acu uzmetiena tas var šķist neliela detaļa, bet praksē pat nepareizas iekšējās saites var negatīvi ietekmēt:

• Meklētājprogrammu tīmekļa vietņu pārmeklēšanas efektivitāte,
• Iekšējā SEO svara sadalījums (PageRank),
• Lietotāja pieredze.

Pirmais analīzes solis ir pārbaudīt, vai nav kļūdu visās iekšējās saites. Īpaši svarīgi ir identificēt bojātas saites, kas ved uz lapām ar 404, 410 vai citām kļūdām (piemēram, 403, 500).
Zemāk ir tabula ar galvenajiem kļūdu veidiem, kas var rasties iekšējās saitēs, to nozīmi un ieteicamās darbības to novēršanai.

Kļūdas tips	Ko tas nozīmē	Ko darīt
404	Lapa nav atrasta	Noņemiet saiti vai aizstājiet to ar darba saiti
403	Piekļuve aizliegta	Piekļuves iestatījumu pārbaude
301/302	Novirzīt	Atjauniniet saiti uz galīgo URL
5xx	Servera kļūda	Pārbaudiet serveri vai CMS

 

Ir svarīgi arī analizēt lapas hierarhijas dziļumu, tas nozīmē, ka noteikt, kurā līmenī un cik klikšķu attālumā no mājaslapas atrodas galvenais saturs. Vēlams, lai svarīgas lapas nebūtu dziļākas par trešo līmeni – tas palielina to pieejamību gan meklētājprogrammām, gan lietotājiem.
Viens no galvenajiem analīzes elementiem ir “bāreņu” lapu identificēšana – tās, kurām nav iekšēju saišu, kas norāda uz tām. Pat ja šīs lapas ir iekļautas vietnes kartē, iekšējo saišu trūkums padara tās mazāk pieejamas.
Turklāt ir svarīgi analizēt enkura tekstus – vārdus un frāzes, kas satur saites. Tiem jābūt atbilstošiem un jēgpilniem, jo enkura teksti palīdz meklētājprogrammām saprast saites kontekstu.

Pārmeklēšanas statistikas analīze

Pārmeklēšanas statistikas analīze ir veids, kā saprast, kā Googlebot mijiedarbojas ar vietni: kuras lapas tiek pārmeklētas, cik bieži un kā tas ietekmē SEO. Šie dati ir pieejami pakalpojumā Google Search Console → Iestatījumi → pārmeklēšanas statistika. Zemāk esošajā tabulā varat redzēt visbiežāk sastopamās problēmas, kuras varat uzzināt šajā pārskatā:

Problēma	Ko meklēt atskaitē	Iespējamie cēloņi
Straujš rāpošanas samazinājums	Mazāk pārmeklējumu dienā	Pieejamības problēmas, nepareizi iestatījumi robots.txt, bloki, 5xx kļūdas
Daudzas 4xx un 5xx kļūdas	Kļūdas URL	Izdzēstas lapas, bojātas saites, servera problēmas
Reakcijas laiks palielināts	>1 sekunde — brīdinājuma zīme	Hostinga problēmas, servera pārslodze
Daudzi 3xx novirzījumi	Novirzīšana tiešo URL vietā	Nepareizi novirzījumi, novirzīšanas ķēdes, liels skaits iekšējo saišu ar novirzījumiem
CSS/JS nav pārmeklēts	To trūkst statistikā	Bloķēja robots.txt

 

Turklāt var analizēt servera žurnālus. Tie ļauj redzēt faktiskos pieprasījumus no meklēšanas robotiem (ne tikai Googlebot, bet arī Bingbot, YandexBot un citiem), nevis tikai apkopotos datus no Google Search Console.
Šī ir progresīva, “neapstrādāta” diagnostikas metode, kas prasa ievērojamu laiku. Lai vizualizētu datus, varat izmantot atvērtā koda rīkus, piemēram, GoAccess vai Screaming Frog Log File Analyzer.

Ieviest strukturētus datus

Strukturētie dati ir īpašs tīmekļa lapas marķējuma formāts, kas palīdz meklētājprogrammām precīzāk un dziļāk izprast lapas saturu. Tas kalpo kā “mājiens” Google un citām meklētājprogrammām par to, kas tieši ir lapā – raksts, produkts, recepte, pārskats, video utt. Lai gan tas nav oficiāls ranga signāls, tas netieši ietekmē reitingus, uzlabojot to, kā meklētājprogrammas izprot lapu.

Galvenais standarts vai protokols, ko izmanto strukturētiem datiem vietnēs, ir Schema.org. Ir arī citi protokoli, piemēram, OpenGraph, bet to izmanto sociālajiem tīkliem.
Schema.org ir Google, Microsoft, Yahoo un Yandex sadarbības projekts, kas izveidots, lai izstrādātu un uzturētu vienotu standartu strukturētiem datiem tīmeklī.
Schema.org ietver simtiem entītiju tipu, un visbiežāk izmantotie ir uzskaitīti tabulā:

Kategorija	Vienība (@type)	Mērķis
Saturs un lapas	Raksts	Raksts vai ziņu saturs
	Emuāra publicēšana	Emuāra ieraksts
	ZiņasRaksts	Ziņu raksts Google ziņām
	Bieži uzdotie jautājumi	Bieži uzdoto jautājumu (FAQ) lapa
	Padomi	Detalizēts ceļvedis
	Mājas lapa	Vispārīga informācija par tīmekļa lapu
Produkti un piedāvājumi	Produkts	Produkta apraksts
	Piedāvājums	Cenas piedāvājums
	Kopējais piedāvājums	Cenu diapazons produktam no dažādiem pārdevējiem
Atsauksmes un vērtējumi	Pārskats	Produkta vai pakalpojuma pārskats
	Vērtējums	Skaitlisks vērtējums (bieži vien recenzijā)
	Kopējais vērtējums	Vidējais vērtējums, pamatojoties uz vairākām atsauksmēm
Organizācijas un cilvēki	Organizācija	Uzņēmuma vai zīmola apraksts
	Vietējais bizness	Vietējais uzņēmums ar kontaktinformāciju un grafiku
	Persona	Persona (piemēram, raksta autors, runātājs utt.)
Notikumiem	Notikums	Tiešsaistes vai bezsaistes pasākums
Navigācija un struktūra	Rīvmaizes saraksts	Navigācija
	SiteNavigationElement	Galvenās izvēlnes vienumi
Multivides	Videoobjekts	Video ar metadatiem (video fragmentiem)
	Attēla objekts	Attēls ar aprakstu
Izglītība un darbs	Kurss	Tiešsaistes kurss vai apmācības programma
	Darba sludināšana	Vakance (pakalpojumam Google darbiem)

Ieteicams ieviest strukturētus datus JSON-LD formātā. Šis bloks tiek ievietots HTML dokumenta <galvā> vai <ķermenī>, bet tas netiek parādīts lietotājam – to lasa meklēšanas roboti. Visas galvenās meklētājprogrammas, piemēram, Google, Bing un Yahoo, atbalsta šo formātu. JSON-LD koda piemērs ir parādīts zemāk:

<script type=”application/ld+json”>

{

“@context”: “https://schema.org”,

“@type”: “Raksts”,

“virsraksts”: “Kas ir JSON-LD?”,

“autors”: {

“@type”: “Persona”,

“vārds”: “Džons Smits”

},

“datumsPublicēts”: “2025-12-01”

}

</scenārijs>

Ieviešot strukturētus datus, ievērojiet Schema.org protokolu un izmantojiet validatoru, lai pārbaudītu ieviesto mikrodatu tipu pareizību. Daži strukturēti dati no Schema.org protokola var arī palīdzēt parādīt bagātinātus fragmentus Google meklēšanas rezultātos.

Ņemiet vērā, ka Google prasības attiecībā uz strukturētiem datiem bagātinātiem fragmentiem nedaudz atšķiras no Schema.org standarta. Bieži vien ir jānorāda vairāk lauku, nekā Schema.org protokols prasa. Tātad, ja vēlaties iegūt bagātīgu fragmentu, ievērojiet Google vadlīnijas par strukturētiem datiem. Mikrodatu ieviešanas pareizību var pārbaudīt, izmantojot bagātināto fragmentu validatoru.

Ir arī daudz mikrodatu ģeneratoru, taču tie var izveidot tikai statisku kodu, kas netiks atjaunināts ar satura izmaiņām lapā. Nodrošināt, ka mikrodatos esošā informācija atbilst lietotājiem redzamajiem lapas lietotājiem, ir daļa no Google prasībām attiecībā uz strukturētiem datiem. Ja tiek pārkāpta politika attiecībā uz strukturētiem datiem, lapa var zaudēt visus bagātinātos fragmentus un dažos gadījumos tikt piemērotas manuālas sankcijas. Tāpēc pārliecinieties, vai jūsu mikrodati tiek automātiski ģenerēti un automātiski atjaunināti.

Saturu

Tehniskā SEO audita ietvaros ir svarīgi novērtēt satura pamatīpašības: no virsrakstu un meta tagu struktūras līdz attēlu un potenciālo lapu dublikātu alt atribūtu klātbūtnei. Šie elementi tieši ietekmē gan indeksēšanu, gan to, kā meklētājprogrammas uztver vietni.

Pārbaudiet vietni, lai iegūtu pilnus dublikātus

Pilni dublikāti rodas, ja identisks saturs ir pieejams, izmantojot dažādus vietnes URL. Dublikāti var pilnībā kaitēt jūsu vietnes reitingam.
Visbiežāk sastopamie pilnu dublikātu veidi ir:

• Pieejamība, izmantojot HTTP un HTTPS
• Pieejamība ar un bez WWW
• Pieejamība ar vai bez aizmugures slīpsvītras
• URL pieejamība ar lielajiem un mazajiem burtiem
• Lapa ir pieejama ar tādiem failu paplašinājumiem kā .html, .htm, .php, .aspx un bez tiem
• Parametri, kas nemaina lapas saturu, piemēram, UTM tagi
• Identisks saturs ar dažādiem URL. Piemēram, produkts ir uzskaitīts divās kategorijās, kas pieejamas, izmantojot divus dažādus URL. Vai arī produkta lapa, kas pieejama ar un bez kategorijas URL.
• Vietnes testa versijas (izstrādei izmantotais DEV domēns).

Lai atrastu lapu dublikātus, kas saistīti ar URL variantiem, manuāli pārbaudiet URL un pārbaudiet, vai servera atbildes kodā nav šo URL variantu. Lai pārbaudītu servera atbildes kodus, varat izmantot jebkuru rīku, piemēram, https://httpstatus.io/. Ievadiet URL variantus un pārbaudiet to pieejamību.

Lai novērstu problēmas ar HTTP/HTTPS, www/without-www variācijām, ar/bez slīpsvītras, lielajiem/mazajiem burtiem un lapu pieejamību ar tādiem paplašinājumiem kā .html, .htm, .php, .aspx, un bez tiem, ir nepieciešams iestatīt 301 novirzīšanu uz vēlamo versiju.

Ja dublikāti tiek atrasti identiska satura pieejamības dēļ, pievienojot vai noņemot URL daļas (piemēram, produkts ir pieejams divās kategorijās), ieteicams pārskatīt URL struktūru un vietnes struktūru. UTM un citiem parametriem kanonizācija var būt arī risinājums. Tomēr ir svarīgi atzīmēt, ka Google uzskata, ka kanonisko tagu uzskata par ieteikumu, un galīgais lēmums par to, kuru URL izvēlēties, paliek Google.

Ja Google indeksā ir atrodama vietnes testa versija, tās indeksēšana ir jābloķē un jānosūta pieprasījums par tās noņemšanu, izmantojot Google Search Console.

Daļēju lappušu dublikātu novēršana

Daļēji lappušu dublikāti rodas, ja divās vai vairākās lapās vietnē ir ļoti līdzīgs, bet ne pilnīgi identisks saturs. Visbiežāk sastopamie daļējo dublikātu veidi ir:

• Lappušu kārtošana
• Lapu filtrēšana
• Lapu lapas
• Lapas ar līdzīgiem produktiem (piemēram, produkti atšķiras tikai pēc krāsas)
• Vairākas vietnes versijas vienā valodā, bet dažādiem reģioniem (piemēram, trīs angļu valodas vietnes ASV, Lielbritānijai un Austrālijai).

Protams, katra vietne ir unikāla, un tehniskā audita laikā jūs varat identificēt citus satura dublēšanas gadījumus, kuriem nepieciešami īpaši risinājumi. Tomēr iepriekš minētie piemēri ir visizplatītākie.

Daļējus dublikātus vietnes pārmeklēšanas procesā parasti atrod dažādas rāpuļprogrammas. Tiem būs atkārtoti parametri, un tiem var būt tāds pats nosaukums un H1 kā galvenajām kategoriju lapām.
Lai novērstu daļējus dublikātus, nevar iestatīt novirzīšanu, jo šīs lapas ir nepieciešamas vietnes funkcionalitātei. Zemāk mēs apspriedīsim metodes, kā rīkoties ar daļējiem dublikātiem.

Lappušu kārtošana un filtrēšana

Šo lapu pārmeklēšana robots.txt failā var bloķēt, lai gan Google to var ignorēt, it īpaši, ja saites norāda uz šīm lapām. Tas palīdzēs saglabāt rāpošanas budžetu.
Varat arī tos bloķēt, izmantojot <meta name=”robots” content=”noindex, nofollow” /> direktīvu, kas novērsīs šo lapu indeksēšanu, bet nepateiks Google, ka tās nedrīkst pārmeklēt.
Labākā pieeja šajā gadījumā ir izmantot JavaScript, lai atjauninātu lapas saturu, kad lietotājs lieto kārtošanu vai filtrus, neģenerējot papildu URL un saites uz lapu filtrēšanu vai kārtošanu.

Produktu varianti, kas pieejami dažādos URL

Ideālā gadījumā visi produktu varianti būtu jāapvieno vienā lapā, kur lietotājs var izvēlēties vēlamo krāsu vai izmēru, nemainot URL, izmantojot JavaScript. Tomēr, ja katram variantam tiek izmantota atsevišķa lapa, jānorāda kanoniska saite uz galveno produkta lapu. Tomēr, kā minēts iepriekš, Google var ignorēt lietotāja kanonisko iestatījumu.

Lapu lapas

Lapu lapas nedrīkst bloķēt no indeksēšanas. Lai nodrošinātu, ka Google kategorijas pirmo lapu uzskata par galveno, veiciet tālāk norādītās darbības.

• Iekļaujiet tikai pirmo lappusi sitemap.xml failā.
• Pievienojiet saiti uz galveno kategoriju lapu visās lapu lapās.
• Pievienojiet lappušu numurus lapu virsrakstam un H1. Piemēram, “Balti krekli – 2. lpp.”

Lapas pieejamas vienā valodā, bet dažādos reģionos

Šajā gadījumā ir jāizmanto Hreflang atribūti. Tie tiek izmantoti, lai meklētājprogrammām pateiktu, kura tīmekļa lapas valoda un reģionālā versija tām jāparāda lietotājiem, pamatojoties uz viņu valodas izvēli un atrašanās vietu.
Ir vairāki veidi, kā ieviest Hreflang atribūtus:

• HTTP galvenēs
• Izmantojot atzīmes sadaļā <galva>
• Izmantojot atzīmes sitemap.xml

Vienkāršākais veids, ko īstenot, ir caur tagiem sadaļā <galva>.

Ir noteikumi, kas jāievēro hreflang atribūtiem, kas ieviesti, izmantojot atzīmes <head> sadaļā:

• • Atribūtam jābūt šādam formātam: <link rel=”alternate” hreflang=”lang_code_country_code” href=”url-of-page” />
  • Valodu un valstu kodiem jābūt derīgiem. Lai izvēlētos derīgo kodu katrai valodas mutācijai, lūdzu, skatiet šo lapu.

• Katrā valodas versijā ir jānorāda pati pati, kā arī visas pārējās valodu versijas savā hreflang atribūtos. Tas nozīmē, ka katrai lapai ir jābūt vienādam skaitam hreflang atribūtu

• Saitēm hreflang atribūtos jābūt absolūtām un indeksējamām.

Koda piemērs:

<link rel=”alternate” href=”https://example.com/en-us/page” hreflang=”lv-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” />

Pārbaudiet nosaukumus, h1, h2 un aprakstus, vai nav dublikātu

Lai gan nosaukumi, apraksti un H1-H6 galvenes ir saistītas ar lapas SEO, to analīze tehniskajā auditā var būt noderīga, lai atklātu dublikātus.

Lai tos analizētu, varat izmantot jebkuru rāpuļprogrammu, kas apkopo šos tagus.

Kad tiek atrasti dublikāti virsraksti, H1-H6 tagi un apraksti, analizējiet lapas datus un identificējiet dublēšanas cēloni. Tas var būt saistīts ar vietnes pieejamību, izmantojot gan HTTP, gan HTTPS, galveno kategoriju tagu dublēšanu filtru lapās vai vienkārši cilvēcisku kļūdu, kad šie tagi tika nepareizi aizpildīti.

Attēlu alt atribūtu optimizēšana

Alt atribūti ir HTML atribūts, ko izmanto <img> tagā, piemēram: <img src=”image.jpg” alt=” Attēla apraksts”>. Tās galvenais mērķis ir sniegt attēla satura teksta aprakstu. Šis teksts tiek parādīts, ja attēls netiek ielādēts, un ekrāna lasītāji to nolasa skaļi, lai palīdzētu lietotājiem ar redzes traucējumiem. Pareizs, aprakstošs alternatīvais teksts var palīdzēt jūsu attēliem ierindoties attēlu meklēšanā un uzlabot lapas vispārējo atbilstību.

Ja jums ir vietne ar daudz vizuālā satura, tad alt atribūtu optimizācija ir svarīgāks solis nekā klasiskajām vietnēm, kas paļaujas uz teksta saturu.

Daudzi rāpuļprogrammas, piemēram, Screaming Frog, Ahrefs, SemRush utt., analizē alt atribūtus, un tur jūs varat iegūt datus par trūkstošajiem vai tukšiem alt atribūtiem.

Vairāk par aprakstošu alt atribūtu izveidi varat uzzināt oficiālajos Google dokumentos.

Tīmekļa vietnes ātrums, mobilās ierīces un lietotājam draudzīgums

HTTP protokola izmantošana

Droša HTTPS protokola izmantošana ir būtiska, lai nodrošinātu datu pārraides drošību starp lietotāju un serveri. Tas ne tikai palielina lietotāju uzticēšanos, bet arī pozitīvi ietekmē SEO. Lai pārbaudītu HTTPS, vienkārši apskatiet pārlūkprogrammas adreses joslu – jāparādās slēdzenes ikona.
Lai veiktu detalizētu analīzi, varat izmantot SSL Labs pakalpojumu, kas sniegs pilnu ziņojumu par SSL sertifikāta statusu un identificēs visas iespējamās problēmas.

Ir svarīgi arī nodrošināt, ka HTTPS lapās nav jaukta satura — HTTP resursu. Lai veiktu šo analīzi, varat izmantot HTTPS pārskatu pakalpojumā Google Search Console, kurā tiks rādīti URL ar HTTP un HTTPS.

Avots: Mūsu klienta Search Console

Uzlabojiet Core Web Vitals

Core Web Vitals ir Google piedāvāts rādītāju kopums, lai novērtētu lietotāja pieredzes kvalitāti vietnē. Šie rādītāji ir vērsti uz lapas satura ielādes ātrumu, interaktivitāti un vizuālo stabilitāti. Tie ietver trīs galvenos rādītājus:

Metrikas	apraksts	Optimālā vērtība
Lielākā satura krāsa (LCP)	Mēra lapā lielākā redzamā elementa (piemēram, attēla vai teksta) ielādes laiku.	Mazāk nekā 2,5 sekundes
Pirmās ievades aizkave (FID)	Novērtē laiku, kas nepieciešams, lai lapa reaģētu uz pirmo lietotāja mijiedarbību (piemēram, noklikšķinot uz pogas vai saites).	Mazāk nekā 100 milisekundes
Kumulatīvais izkārtojuma nobīde (CLS)	Novērtē lapas vizuālo stabilitāti, t.i., to, cik daudz elementu pārvietojas lapas ielādes laikā.	Mazāk nekā 0,1

 

Datus, kas tika apkopoti no reāliem lietotājiem, var skatīt Search Console pārskatā “Core web vitals” (apkopotie dati) vai PageSpeed Insights (atsevišķiem testiem). Strādājot pie Core Web Vitals, paturiet prātā, ka jums ir jādefinē problēmas, kurām ir liela ietekme uz CWV metriku. Piemēram, optimizējot LCP, jums ir jādefinē, kurš no 4 aspektiem (TTFB, ielādes aizkave, ielādes laiks vai renderēšanas aizkave) visvairāk veicina augsto LCP rādītāju.

Tālāk redzamajā piemērā ir redzams, ka mums nav jākoncentrējas uz TTFB vai ielādes laika optimizāciju. Tā vietā mēs varam ieguldīt visu savu enerģiju, lai uzlabotu slodzes aizkavēšanos un pēc tam renderēšanas aizkavēšanos.

Avots: https://pagespeed.web.dev/ – nike.com tīmekļa vietnes pārbaude (tikai piemēram). Domēns ir izplūdis

Pārliecinieties, ka jūsu vietne ir piemērota mobilajām ierīcēm

Mobilajām ierīcēm draudzīgums ir kļuvis par izšķirošu faktoru kopš 2018. gada, kad Google pārgāja uz mobilo ierīču indeksēšanas pieeju. Tas nozīmē, ka Google tagad galvenokārt izmanto vietnes mobilo versiju ranžēšanai un indeksēšanai, nevis datora versiju.

Pakalpojumā Google Search Console varat pārbaudīt savas lapas, URL pārbaudes rīkā noklikšķinot uz “Pārbaudīt tiešo URL” un redzēt, kā to redz Googlebot-Mobile.

Attēlu saspiešana

Attēlu optimizācija, kuras mērķis ir tos saspiest, nezaudējot kvalitāti, palīdz paātrināt vietnes ielādi, it īpaši, ja lapās ir daudz grafiskā satura.

Attēlu saspiešanai var izmantot tiešsaistes rīkus, piemēram, TinyPNG vai Squoosh. Ir arī vērts pārbaudīt, vai tiek izmantoti mūsdienīgi attēlu formāti, piemēram, WebP, jo tie var ievērojami samazināt faila lielumu.

CDN izmantošana starptautiskām vietnēm

CDN izmantošana ir lietderīga, ja jūsu vietne apkalpo plašu ģeogrāfiski attālu reģionu klāstu.

CDN (Content Delivery Network) izplata vietnes saturu pa serveriem, kas atrodas tuvāk lietotājiem, samazinot latentumu ielādes laikā. CDN lietojumu var pārbaudīt, pārbaudot HTTP pieprasījuma galvenes pārlūkprogrammas izstrādātāju rīkos (cilne Tīkls), kur var tikt parādītas atsauces uz CDN pakalpojumu sniedzēju, piemēram, Cloudflare vai Akamai. Ir arī tiešsaistes rīki CDN testēšanai. CDN konfigurācija parasti tiek veikta, izmantojot hostinga paneli vai CMS.

Kešatmiņas izmantošana
Kešatmiņa ļauj pārlūkprogrammām un starpniekserveriem saglabāt resursu kopijas, samazinot servera slodzi un paātrinot ielādi turpmākajos apmeklējumos. Kešatmiņas pareizību varat pārbaudīt pārlūkprogrammas izstrādātāju rīkos — sadaļā Tīkls apskatiet kešatmiņas kontroles, derīguma termiņus un ETag galvenes. Google PageSpeed Insights sniedz arī kešatmiņas ieteikumus. Ir svarīgi, lai statiskajiem resursiem (attēliem, skriptiem, stiliem) būtu pareizi kešatmiņas iestatījumi, un serverim jābūt konfigurētiem atbilstošiem noteikumiem (piemēram, .htaccess vai nginx konfigurācijā). Lai pārbaudītu kešatmiņu, varat izmantot tiešsaistes pakalpojumus, piemēram, GiftOfSpeed.

Secinājums

Tīmekļa vietnes tehniskais audits nav vienreizēja procedūra, bet gan nepārtraukts process, kas prasa regulāru uzmanību tehniskajiem faktoriem, kas var ietekmēt tās veiktspēju un redzamību. Tā kā katra vietne ir unikāla, konkrētais fokuss un pārbaužu biežums atšķirsies. Šis tehniskā SEO audita kontrolsaraksts palīdzēs jums nodrošināt, ka neesat aizmirsis neko svarīgu.