Tehniskais SEO kontrolsaraksts: galīgais saraksts, lai uzlabotu jūsu vietni

Tehniskais SEO kontrolsaraksts

Pārmeklēšana un indeksēšana

Pirmā lieta, kas jāaplūko tehniskās revīzijas 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ārskata pārskatīšana pakalpojumā Google Search Console

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

Apskatiet indeksēto lappušu atskaiti 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 parasti ir 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 gala 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 vēl nav to pārmeklējis. Norāda problēmas ar budžeta pārmeklēšanu.	Pārliecinieties, ka lapa ir 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, ka lapā nav dublikātu. Pievienojiet tam iekšējās saites.
Dublēt bez lietotāja atlasītas kanoniskās	Google uzskata, ka lapa ir dublikāts, bet jūs neesat norādījis kanonisku.	Pārbaudiet lapu pārus un norādiet nepieciešamo kanonisko vai pārskatiet vietnes struktūru.
Dublikāts, Google izvēlējās atšķirīgu kanonisko nekā lietotājs	Google ignorēja jūsu norādīto kanonisko.	Var būt daudz iemeslu; Jums rūpīgi jāpārbauda lapas dati un jāizvēlas vispiemērotākā stratēģija (noindex, redirect, removal, robots.txt, izmaiņas mājas lapas struktūrā un iekšējās saites).
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 indeksēšanu.

Pārējie statusi, iespējams, nesignalizē par problēmām. Tomēr ir vērts pārskatīt arī šos ziņojumus, 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 tagu	Google pareizi atzina jūsu norādīto kanonisko saturu.	Viss darbojas, kā paredzēts. Nav nepieciešama nekāda darbība. Pārliecinieties, ka esat norādījis vēlamo kanonisko.
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, ka noindex tags ir iestatīts apzināti. Ja lapa ir svarīga, noņemiet šo atzīmi.
Nav atrasts (404)	Lapa neeksistē.	Ja tas ir svarīgi, atjaunojiet lapu. Ja lapa ir neatgriezeniski izdzēsta, pārliecinieties, ka uz to nav iekšējo 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.).	Pārbaudiet HTTP statusa kodu manuāli. Piekļuves iestatījumu labošana. 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.

Screaming Frog 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 ar Google un izpildiet norādījumus.

Kad ir izveidots savienojums, iespējojiet URL pārbaudi, kā arī varat iespējot opciju ignorēt indeksēšanas pārbaudi vietrāžiem URL, kurus nevar indeksēt.

Pēc tam varēsiet skatīt un salīdzināt katras lapas statusu atbilstoši Search Console (kā to redz Google) 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 meklētājprogrammu rāpuļprogrammām nodrošina 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 lielu multivides saturu;
• Ziņu vietnes, kas tiek bieži atjauninātas.

Sitemap.xml jābūt visām lapām, kuras vēlaties indeksēt.

Varat izmantot to pašu Screaming Frog vai citas rāpuļprogrammas, lai analizētu Sitemap.xml iekļautās lapas. 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 pārmeklējamo vietnes karšu absolūtos URL.

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 rakstīt pielāgotu skriptu, kas ģenerē vietnes karti saskaņā ar norādītajiem 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 tagus <loc> un <lastmod>. Pārliecinieties, ka datums tagā <lastmod> ir precīzs. Ja tiek mēģināts ar to manipulēt, 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 meklētājprogrammas indeksēs lapas. Tam vienmēr jāatrodas 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āsniedz 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 (/produkts/)
• Emuārs vai raksti (/blogs/, /raksti/)

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 faili ir jāatver skenēšanai. Tas bieži notiek WordPress vietnēs, kad mape ar visu lietotāja saturu, Neatļaut: /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 apstiprinā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=”robots” content=”noindex”>
• Kanonisko

Piemēram, ja lapa ir atvērta robots.txt versijā, 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ē robots.txt bloķētās lapas. Viņi neredz kodā norādītos tagus, piemēram, kanonizāciju. Tas nozīmē, ka šāds kanonisks vienkārši netiks ņemts vērā.

Iekšējās saites pārbaude

Viens no galvenajiem tehniskā audita uzdevumiem ir nodrošināt, lai vietnes iekšējā saite darbotos pareizi. Tas nozīmē, ka visām iekšējām saitēm ir jāved uz reālām, esošām lapām, kas ir atvērtas indeksēšanai, jāatgriež 200 OK statusa kods, nedrīkst saturēt novirzījumus un, pats galvenais, nenorādīt 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 visas iekšējās saites kļūdām. Īpaši svarīgi ir identificēt bojātās 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 veids	Ko tas nozīmē	Kā rīkoties
404	Lapa nav atrasta	Noņemiet saiti vai aizstājiet to ar strādājošu saiti
403	Piekļuve aizliegta	Piekļuves iestatījumu pārbaude
301/302	Novirzīt	Saites atjaunināšana uz gala URL
5xx	Servera kļūda	Pārbaudiet serveri vai CMS

 

Ir svarīgi arī analizēt lapas hierarhijas dziļumu, proti, noteikt, kādā 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šējo saišu, kas uz tām norāda. 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 izprast saites kontekstu.

Pārmeklēšanas statistikas analīze

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

Problēma	Ko meklēt ziņojumā	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 vietrāžos URL	Izdzēstas lapas, bojātas saites, servera problēmas
Palielināts reakcijas laiks	>1 sekunde – brīdinājuma zīme	Hostinga problēmas, servera pārslodze
Daudzi 3xx novirzījumi	Novirzīšana tiešo URL vietā	Nepareizas novirzīšanas, novirzīšanas ķēdes, liels skaits iekšējo saišu ar novirzījumiem
CSS/JS nav pārmeklēts	Tie nav iekļauti 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 uzlabota, “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.

Strukturēto datu ieviešana

Strukturētie dati ir īpašs iezīmēšanas formāts tīmekļa lapā, 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 ranžēšanas signāls, tas netieši ietekmē rangu, uzlabojot to, kā meklētājprogrammas izprot lapu.

Galvenais standarts vai protokols, ko izmanto strukturētiem datiem tīmekļa 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 veidu, no kuriem visbiežāk izmantotie ir norādīti tālāk esošajā tabulā.

Kategorija	Vienība (@type)	Mērķis
Saturs un lapas	Raksts	Raksts vai ziņu saturs
	Bloga publicēšana	Emuāra ieraksts
	Ziņu raksts	Ziņu raksts pakalpojumā Google ziņas
	Biežāk 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	Cenu piedāvājums
	Apkopotais 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 pārskatā)
	Apkopotais 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 ar rīvmaizi
	Vietnes navigācijas elements	Galvenie izvēlnes punkti
Multivides	Videoobjekts	Videoklips ar metadatiem (videoklipu 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 (Google for Jobs)

Strukturētus datus ieteicams ieviest 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”,

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

“autors”: {

“@type”: “Persona”,

“name”: “Džons Smits”

},

“datePublished”: “2025-12-01”

}

< / skripts>

Ieviešot strukturētus datus, ievērojiet Schema.org protokolu un izmantojiet validatoru, lai pārbaudītu ieviesto mikrodatu tipu pareizību. Dažu veidu strukturētie dati no Schema.org protokola var arī palīdzēt parādīt bagātīgus 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ā prasa Schema.org protokols. 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ātīgo 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, lai mikrodatos esošā informācija atbilstu lietotājiem lapā redzamajai informācijai, 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 var tikt piemērotas manuālas sankcijas. Tāpēc pārliecinieties, ka jūsu mikrodati ir automātiski ģenerēti un automātiski atjaunināti.

Saturu

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

Pārbaudiet, vai vietnē nav pilnu dublikātu

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

• Pieejamība, izmantojot gan HTTP, gan HTTPS
• Pieejamība ar un bez WWW
• Pieejamība ar beigu slīpsvītru vai bez tās
• URL pieejamība ar lielajiem un mazajiem burtiem
• Lapa ir pieejama ar failu paplašinājumiem, piemēram, .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, kurām var piekļūt, izmantojot divus dažādus URL. Vai 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, pārbaudiet URL manuāli un pārbaudiet šo URL variantu servera atbildes kodu. Servera atbilžu kodu pārbaudei var 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, ar/bez slīpsvītras, lielajiem/mazajiem burtiem un to lapu pieejamību ar paplašinājumiem, piemēram, .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), vislabāk ir 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 kanonisko tagu uzskata par ieteikumu, un galīgais lēmums par to, kuru URL izvēlēties, paliek Google ziņā.

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

Daļēju lappušu dublikātu atrisināšana

Daļēji lapu dublikāti rodas, ja divās vai vairākās vietnes lapās 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
• Filtrēt lapas
• 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 vietnes angļu valodā ASV, Apvienotajā Karalistē un Austrālijā).

Protams, katra vietne ir unikāla, un tehniskās revīzijas laikā jūs varat identificēt citus dublēta satura 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. Tām būs atkārtoti parametri, un tām var būt tāds pats nosaukums un H1 kā galvenajām kategoriju lapām.
Lai novērstu daļējus dublikātus, jūs nevarat 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.

Lapu kārtošana un filtrēšana

Šo lapu pārmeklēšana robots.txt failā var tikt bloķēta, 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ī bloķēt tos, izmantojot direktīvu <meta name=”robots” content=”noindex, nofollow” />, kas neļaus šīm lapām indeksēt, 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 filtrēšanas vai kārtošanas lapām.

Produktu varianti, kas pieejami dažādos URL

Ideālā gadījumā visi preces 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 kanoniskā 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 uzskata kategorijas pirmo lapu par galveno, veiciet tālāk norādītās darbības.

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

Lapas pieejamas vienā valodā, bet dažādiem reģioniem

Šajā gadījumā jāizmanto Hreflang atribūti. Tās tiek izmantotas, lai meklētājprogrammām norādītu, kurā valodā un reģionālajā tīmekļa lapas versijā 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šākā metode, ko īstenot, ir tagi sadaļā <galva>.

Ir noteikumi, kas jāievēro hreflang atribūtiem, kas ieviesti, izmantojot tagus sadaļā <galva>:

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

• Katrai valodas versijai ir jānorāda sevi, 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 hreflang atribūtu skaitam

• 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=”en-us” />

<link rel=”alternate” href=”https://example.com/en-gb/page” hreflang=”lv-gb” />

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

Pārbaudiet, vai dublikātos ir nosaukumi, h1, h2 un apraksti

Lai gan virsraksti, 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.

Ja 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ēka kļūdu, kad šie tagi tika nepareizi aizpildīti.

Alt atribūtu optimizēšana attēliem

Alt atribūti ir HTML atribūts, kas tiek izmantots tagā <img> šādi: <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ēlu neizdodas ielādēt, 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 balstās 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šajiem alt atribūtiem.

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

Vietnes ātrums, mobilums un lietotājdraudzī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 – vajadzētu parādīties piekaramās slēdzenes ikonai.
Lai veiktu detalizētu analīzi, varat izmantot SSL Labs pakalpojumu, kas sniegs pilnu ziņojumu par SSL sertifikāta statusu un identificēs 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 gan ar HTTP, gan HTTPS.

Avots: mūsu klienta Search Console

Uzlabojiet pamata tīmekļa vitāli svarīgus elementus

Core Web Vitals ir Google ierosināts metriku kopums, lai novērtētu lietotāja pieredzes kvalitāti vietnē. Šie rādītāji koncentrējas 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 lapas lielākā redzamā elementa (piemēram, attēla vai teksta) ielādes laiku.	Mazāk nekā 2,5 sekundes
Pirmās ievades aizkave (FID)	Mēra 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., cik daudz elementu pārvietojas lapas ielādes laikā.	Mazāk nekā 0,1

 

No reāliem lietotājiem apkopotos datus 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 augstu LCP rezultātu.

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 ielādes aizkavēšanos un pēc tam renderēšanas aizkavēšanos.

Avots: https://pagespeed.web.dev/ – nike.com vietnes tests (tikai piemēram). Domēns ir neskaidrs

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

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

Google Search Console varat pārbaudīt savas lapas, URL pārbaudes rīkā noklikšķinot uz “Test Live 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 tīmekļa vietnēm

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

CDN (satura piegādes tīkls) izplata vietnes saturu serveros, 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āja rīkos (cilnē Tīkls), kur var parādīties atsauces uz CDN nodrošinātā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 nākamajos 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ņa beigu un ETag galvenes. Google PageSpeed Insights sniedz arī ieteikumus kešatmiņai. 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šajiem 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 tīmekļa vietne ir unikāla, pārbaužu īpatsvars un biežums atšķirsies. Šis tehniskā SEO audita kontrolsaraksts palīdzēs jums pārliecināties, ka neesat aizmirsis neko svarīgu.