Galīgā WordPress SEO rokasgrāmata

Ja vēlamies runāt par SEO nozīmi šādā digitālās komunikācijas ekosistēmā, esam nokavējuši. Lielie uzņēmumi, mazie un vidējie uzņēmumi, ārštata speciālisti un individuālie lietotāji – visi var piekļūt tīmekļa vietnei, un tieši šeit talkā nāk WordPress: pasaulē visvairāk lietotāju CMS (to izmanto 27+ miljoni vietņu, kas veido vairāk nekā 50 % no visām internetā esošajām CMS).
Šajā rakstā runāsim par WordPress SEO – sāksim ar pašiem pamata jēdzieniem un pakāpeniski pacelsimies līdz pieredzējušam līmenim.
Apakšdomēnu novirzīšana – ar www vai bez tā?
Sāksim ar ieteikumu tiem, kuri gatavojas instalēt WordPress: pirms instalēšanas izlemiet, kuru domēna versiju izvēlaties – ar www vai bez tā, jo, palaižot WordPress instalēšanas lietotni – piemēram, CPANEL vidē – tā piedāvā iespēju veikt visu instalēšanu atbilstoši jūsu izvēlētajai opcijai, lai versija, kuru neizvēlējāties, vēlāk tiktu novirzīta.
Ja šo soli izlaidāt, jums būs jāstrādā ar htaccess failu. Ir tādi spraudņi kā WP HTACCESS EDITOR, kas atvieglo faila rediģēšanu, taču iesaku: ja neesat pārliecināts par to, ko darāt, lūdziet palīdzību, jo šis fails ir būtisks, lai vietne darbotos.
Ja tomēr izlemjat izmantot šo iespēju, šis ir kods, kas jums jāpievieno.
Domēna bez www novirzīšana uz versiju ar www
RewriteEngine On
RewriteCond %{HTTP_HOST} ^yourdomain.com [NC]
RewriteRule ^(.)$ http://www.yourdomain.com/$1 [L,R=301]*
Domēna ar www novirzīšana uz versiju bez www
RewriteEngine on RewriteCond %{HTTP_HOST} ^www.yourdomain.com RewriteRule ^(.*)$ http://yourdomain.com/$1 [R=301,L] Tomēr vēlos vēlreiz uzsvērt, ka htaccess faila rediģēšana ir kaut kas, kas jums ļoti labi jāpārzina, tāpēc, ja gatavojaties to rediģēt, vispirms izveidojiet rezerves kopiju.
WordPress instalēšana: pirmie optimizācijas soļi
Pirmām kārtām jums jāsaprot, kā darbojas Google, un ka katrai jūsu darbībai – cik vien iespējams – vajadzētu atvieglot Googlebot darbu, kad tas apmeklē mūsu vietni.
Kāpēc es to saku?
Tāpēc ka šis punkts ir viena no visbiežāk pieļautajām kļūdām, ko pieļauj lietotāji – ne tikai WordPress lietotāji, bet ikviens tīmekļa dizainers vai tīmekļa pārzinis.
Ja jūsu saturs nav pabeigts, neļaujiet Googlebot tam piekļūt, jo tādējādi jūs palēnināsiet savu URL adrešu ranžēšanas procesu.
Tāpēc, ja pirms sākuma man kaut kas jāiesaka, tas ir „atturēt meklētājprogrammas no mana satura indeksēšanas.“
WordPress indeksēšana: kad man vajadzētu indeksēt savu vietni?
Veicot instalēšanu, iestatīšanas ekrānā mums ir iespēja bloķēt meklētājprogrammu piekļuvi. Bet, ja šo soli izlaidām, to varam izdarīt sadaļā Iestatījumi > Lasīšana.

Robotu piekļuves bloķēšanas opcija
Šo „aizliegumu“ var iestatīt arī populārajā Robots.txt failā. Ja esat pieredzējušāks tīmekļa izstrādes lietotājs, izmantojot FTP kontu, ko izveidojis vai nodrošinājis jūsu mitināšanas pakalpojumu sniedzējs, varēsiet pievienot šo failu galvenajā ceļā, kur tiek mitināta jūsu vietne.
Robots.txt failu var vienkārši izveidot ar Notepad (Windows) vai TextEdit (Mac), taču atcerieties, ka tam jābūt teksta failam; tajā pievienosim šīs divas rindas:
*User-agent: **
Disallow: / Šajā sarakstā varam redzēt populārākos Google rāpuļus (User-Agents)

Dažādi Google lietotāju aģenti
Mūsu kodā, ja norādām User-agent: *, mēs sakām, ka domājam visus botus – neviens no tiem nevarēs piekļūt mūsu vietnei. Varam arī atsaukties uz vienu konkrētu botu (Googlebot, Googlebot-Video utt.), taču šajā posmā es to neiesaku. Tātad – visi bloķēti.
URL struktūra un draudzīgas URL adreses
Kad esam noskaidrojuši, kāds ir mūsu vēlamais domēns, un bloķējuši robotu piekļuvi, pārejam pie URL struktūras.
Šis solis jāveic pirms rāpošanas un indeksēšanas, jo pretējā gadījumā mums nāktos ienirt novirzījumu pasaulē, un tas nav ideāli.
WordPress pēc noklusējuma piedāvā opcijas, lai jūs varētu izvēlēties to, kura vislabāk strukturēs jūsu vietnes saturu. Šī izvēle ir atkarīga no projekta un no katra cilvēka; visas opcijas ir piemērotas, ja projektam tas nepieciešams.
Paskaidrošu:
Nokļuvuši WordPress vadības panelī, dosimies uz Iestatījumi > Pastāvīgās saites
Un ieraudzīsim šo ekrānu:

URL struktūra ar pastāvīgajām saitēm
Kā minēju iepriekš, izvēle ir atkarīga no katra cilvēka, taču, ja runājam par SEO, labāk ir strādāt ar draudzīgāku URL formātu.
Kas ir draudzīgas URL adreses?
Par draudzīgām URL adresēm saucam tās URL, kas ir saprotamas lietotājam un jau no pirmā acu uzmetiena sniedz URL satura semantisku interpretāciju.
- Draudzīga URL: /blog/
- Nedraudzīga vai dinamiska URL:* https://seocrawl.com/?ref=13535?sfas*
Pirmā URL sniedz informāciju par saturu, ko atradīsiet, otrā – nē, taču tas nenozīmē, ka Amazon dara kaut ko nepareizi – drīzāk tas izmanto dažādus kontroles parametrus, lai iekšēji identificētu savas URL adreses.
Ņemiet vērā, ka ar miljoniem produktu un kategoriju skaitļi tiem atvieglo kontroli.
Kad šis precizējums izdarīts un aplūkojot opcijas, mums ir 3 URL veidi:
- Ar datumu
- Ar ieraksta vai raksta nosaukumu
- Pielāgojama, izmantojot mainīgos.
Pastāvīgās saites WordPress sistēmā
URL adreses ar datumu

Daudzi SEO konsultanti noraida šīs URL, jo īpaši tāpēc, ka tās atklāj ieraksta izveides datumu, taču šāda veida URL ir ļoti noderīga, kad jums ir liels satura apjoms.
Piemēram, ziņu mediju gadījums. Ja aplūkojat visas to URL, tajās ir datums. Ziņu portālam ir būtiski, lai būtu loģiska struktūra, kas ļauj glabāt tā URL arhīvā, turklāt tas ir arī identifikators, kas noder, lai zinātu, kad ziņa tika publicēta.
El País izmanto jaukta veida URL, jo tajā ir semantiska informācija, piemēram, kategorijas nosaukums, datums un apakškategorija, un tā beidzas ar ziņas identifikatoru.
Citi laikraksti papildus ziņas identifikatoram URL iekļauj arī terminus no ziņas virsraksta.
Strādājot ar URL sintaksi, ir ļoti interesanta opcija, kas bieži tiek filtrēta: pieturvārdi.
Pieturvārdi ir termini, no kuriem vēlamies izvairīties, veidojot jaunu URL. Šī darbība tiek veikta, programmējot – mūsu WordPress gadījumā ar PHP palīdzību.
Pieturvārdu piemēri būtu: artikuli, vietniekvārdi, skaitļi utt.
Rank Math piedāvā opciju, kas ļauj izvairīties no šāda veida terminiem.

Pieturvārdu noņemšana, veidojot URL adreses
URL ar ieraksta vai lapas nosaukumu

Vienkārša un plaši izmantota opcija. Mūsu URL tiks veidotas no ieraksta nosaukuma vai no modificētā slug.
Slug jeb pastāvīgo saiti var rediģēt ierakstos, tāpēc, ja nevēlamies WordPress piedāvāto automātisko opciju, URL modificēsim manuāli (tikai ierakstu, ne domēnu).

Pielāgota URL, izmantojot mainīgos

Kā redzat, šeit tiek iesaistīti dažādi mainīgie, lai izveidotu mums tīkamu URL.
Mainīgie sniegs vairāk informācijas lietotājam. Ja vēlaties strukturēt saturu tā, ka nepieciešams pievienot kādu mainīgo, izvēlieties šo opciju.
Sniegšu piemēru: mēs vēlamies savā URL norādīt kategoriju, gadu, ieraksta nosaukumu un identifikatoru.
https://seocrawl.com/%category%/%year%/%postname%/%post_id%/
Informācijas arhitektūra: kategorijas, vecāklapas un tagi
Pirms sākam darbu ar informācijas arhitektūru, mums jāsaprot visas iespējas, ko WordPress mums sniedz darbam ar saturu.
Kā jūs droši vien jau zināt, WordPress ir savas īpatnības, un, lai gan ieraksts un lapa no pirmā acu uzmetiena var šķist vienādi, funkcionalitāte un spraudņi tos tomēr atšķir.
Satura strukturēšana ir būtiska SEO daļa, lai strādātu ar līdzīga satura sasaisti un saistīšanu – to, ko dēvē par satura kopām (content clusters).
Šim nolūkam varam izmantot:
- Kategorijas
- Tagus
- Ierakstus (Posts)
- Lapas
- Apakšlapas
Kategorijas, tagi un ieraksti (Posts)
Ir divi veidi, kā automātiski grupēt ierakstus WordPress sistēmā: ar kategorijām un ar tagiem.
Kad izmantot kategorijas un kad tagus?
Saprotot, ka kategorijas un tagi mums palīdz grupēt saturu, lēmumam tos izmantot vienmēr jābūt atkarīgam no satura apjoma, ko gatavojamies radīt, jo pretējā gadījumā varam dublēt saturu.
Gan kategorijas, gan tagi mums palīdzēs ar iekšējo sasaisti un ar to, kā Google rāpo pa visu mūsu saturu, taču, kā jau teicām, jāprot tos izmantot.
Mans padoms ir izmantot kategorijas, kad gatavojamies bieži veidot saturu mūsu vietnes tēmas ietvaros.
Izmantosim tagus, ja konkrētu tēmu ietvaros ir liels satura apjoms, kam ir kaut kas kopīgs.
Sniegšu piemēru:
Sports būtu kategorija, bet Cristiano Ronaldo varētu būt tags – tomēr jums vajadzētu sev pajautāt: cik rakstu par Cristiano Ronaldo es radīšu?
Ja neradīsim pietiekami daudz satura, lai mūsu lapu grupējumi patiešām atšķirtos cits no cita, mums ir divas iespējas: vai nu neveidot kategoriju/tagu, vai arī tos neindeksēt.
Strādājot ar kategorijām un tagiem, ir arī citi papildinājumi, kas palīdzēs mūsu saturam sasaistīties ar līdzīgu saturu.
Navigācijas ceļš (Breadcrumb)
WordPress veido navigācijas ceļu, balstoties uz strukturēto kategorijas un ieraksta saturu, tāpēc, ja vēlamies izmantot navigācijas ceļu (breadcrumbs), lai nodrošinātu labu satura sasaisti, mums vajadzētu izvēlēties šāda veida arhitektūru.
Tātad mūsu ieraksts izskatītos šādi:
- URL : sitename.com/category/category-name/post-name
- Navigācijas ceļš: Sākums > Kategorijas nosaukums > Ieraksta nosaukums
Ir spraudņi navigācijas ceļa pievienošanai, taču tie visi balstās uz mūsu WordPress DB struktūru; līdz šai dienai nezinu nevienu spraudni, kas sniegtu elastību tā definēšanā.
Kā jūs droši vien jau pamanījāt, ieraksta ar kategoriju URL ievieš terminu CATEGORY.
Tas ir iekļauts WordPress standartā, proti, jūs to atradīsiet ikvienā WordPress vietnē, un pastāvīgo saišu opcija ļauj vien nomainīt vienu nosaukumu ar citu (category ar citu terminu).
Mums ir vairākas iespējas to atrisināt – atkal Rank Math sniedz opciju:

Ir arī spraudņi, kas palīdz noņemt šo terminu un atstāt tīrāku URL.

Spraudņi Category noņemšanai no WordPress URL
Vecāklapa un apakšlapa
Atgriežoties pie satura struktūras, ir viens darba veids, kas man patīk, – ar lapām un apakšlapām. Parasti šādu struktūru izmantoju pakalpojumu galvenajām (Landing) vai centrālajām (Hub) lapām.
Galvenā atšķirība ir dizaina elastībā, ko sniedz lapa, bet kategorija – nē. Gan kategorijas, gan ierakstus nosaka WordPress tēma vai veidne, taču lapas var noformēt pēc sava prāta ar Page Builder rīku palīdzību (spraudnis vai papildinājums vietnes pielāgošanai, izmantojot blokus).
Kad izmantot lapu un apakšlapu?
Skaidrākais piemērs, kas nāk prātā, ir tad, kad mums ir vispārīgs pakalpojums un vairāki konkrētāki pakalpojumi. Vispārīgajam pakalpojumam izveidosim lapu, bet konkrētajiem pakalpojumiem – apakšlapas.
- Vispārīga galvenā lapa: Dizains
- Konkrēta galvenā lapa: Tīmekļa dizains, Grafiskais dizains, Produkta dizains, Rūpnieciskais dizains...
URL piemērs:
sitename.com/design/web/
sitename.com/design/graphic/
sitename.com/design/product/
Navigācijas ceļš: *Sākums > Dizains > Tīmekļa dizains *
Lai to izdarītu, raksta redaktorā (post jeb ierakstā) mums jāiespējo lapas atribūtu (Page Attributes) panelis, kas atrodas augšpusē.

Tagad mūsu lapas labajā pusē būs pievienots modulis ar lapas atribūtiem.

Izvēloties vienu no esošajām lapām, pašreizējā lapa būs atkarīga no izvēlētās un kļūs par tās apakšlapu.
SEO spraudnis WordPress sistēmai: Rank Math, Yoast...
Kad mums ir skaidra URL struktūra un daļa informācijas arhitektūras, šajā posmā vēlējos iekļaut SEO spraudņa instalēšanu (Rank Math, Yoast, All In One SEO...). Pašlaik šie spraudņi atvieglo dzīvi SEO jomā, jo tiem ir būtiskie rīki darbam ar SEO jūsu saturā.
Kad šis spraudnis ir instalēts, ir pienācis laiks pievienot tās vietnes izsekošanas un verifikācijas kodu, kuru vēlamies izsekot. Kā analītikas rīki nav labāku par Google Analytics un Search Console.
Izsekošanas kods jeb Google Analytics kods
Kā redzēsiet WordPress sistēmā – ja vēl neesat – vienmēr ir vairāki veidi, kā veikt kādu procesu.
Analytics izsekošanas kodu jeb izsekošanas ID ievietot varam ar kodu pašā lapas HTML, ar veidni, kas parasti nodrošina vietu koda ievietošanai galvenē (Header), vai ar spraudni.
Ja nezināt, kā iegūt Analytics izsekošanas ID, Google atbalsta lapā jums parāda ceļu https://support.google.com/sites/answer/97459?hl=en
Google ir savs spraudnis WordPress sistēmai (Site Kit Google), kurā varam iegūt visu analītikas daļu.

Mums ir arī vienkāršas opcijas Google Analytics izsekošanas koda pievienošanai.

Mūsdienās dizaineri jau ņem vērā šīs tīmekļa pārziņu vajadzības un veidnes konfigurācijā piedāvā lodziņu koda ievietošanai galvenē.

Mūsu WordPress verifikācija Search Console sistēmā
Ir dažādi veidi, kā verificēt domēnu Search Console sistēmā; pastāstīšu par 2: vienu ar Google verifikācijas failu un otru ar SEO spraudni, ar kuru strādāsim.
- Google Search Console verifikācijas fails.
- Ar īpašuma verifikācijas kodu
Vienkāršai verifikācijai atkal varam izmantot Rank Math.

Pirmajā laukā varam tieši ievadīt ID, ko atrodam Search Console verifikācijas daļā (noklikšķinot uz teksta lodziņā, tas mūs aizved tieši uz URL, kas sniedz šo informāciju).
Pēc tam vien jāpievieno ID, kas zemāk atzīmēts sarkanā krāsā.
<meta name="google-site-verification" content="example code" />
Kā izveidot vietnes karti (Sitemap) WordPress sistēmā
Vēl viens jautājums, kas SEO nozarē raisa diskusijas, ir vietnes kartes (sitemaps). Agrāk šis fails bija svarīgs, lai Google varētu piekļūt visām mūsu URL.
Tā ir taisnība, ka viss ir mainījies un Google nav vajadzīgs fails, lai pilnībā izrāpotu jūsu vietni. Taču tikpat taisnība ir tas, ka ar Search Console un vietnes kartēm jums būs papildu informācija, kas var palīdzēt atrisināt nākotnes URL problēmas.
Ir daudz veidu, kā izveidot vietnes karti, taču ideāli, ja tas ir dinamisks fails, kas atjaunojas līdz ar jauniem ierakstiem vai lapām.
Neatkarīgi no tā, vai izmantojam Yoast, Rank Math vai jebkuru citu SEO spraudni, lai piekļūtu šai funkcionalitātei, mums vienkārši tas jānorāda.
Lai to paskaidrotu, izmantošu Rank Math piedāvāto rīku, un dosimies uz opciju Sitemap Settings.

Vietnes kartes konfigurēšanas piemērs Rank Math sistēmā
Kā redzam attēlā, varam pielāgot dažādas opcijas par URL veidu, ar kuru strādāsim.
- Saites vienā vietnes kartē: 1000 (atstājam noklusējuma opciju; tas norāda URL skaitu, ko vēlamies savā failā)
- Attēli vietnes kartēs: iesaku aktivizēt šo opciju, ja jūsu attēli ir oriģināli un sniedz informāciju rakstam.
Jebkurā gadījumā, ja savā saturā izmantojat attēlus, Google tos viegli izrāpos.

Pirmie divi šīs konfigurācijas daļas lodziņi paredzēti, lai izslēgtu ierakstus vai lapas, ko nevēlaties pievienot vietnes kartei.
Tas tiek darīts, izmantojot identifikatoru, kuru varam atrast šādi.
Kad dodamies uz ierakstu vai lapu sadaļu un novietojam kursoru virs ieraksta, nenoklikšķinot, apakšējā daļā parādīsies URL.

Ja paskatāmies apakšā, sarkanajā lodziņā redzam post=5745 – skaitlis ir identifikators, kas mums jāizmanto, lai šī lapa neparādītos vietnes kartē.
Nākamā opcija ir ar taksonomijām, tas ir, izdarīt to pašu ar TAGIEM un kategorijām.
Rank Math opcija ir ierobežota un pēc noklusējuma izveido 5 veidu vietnes kartes (ieraksti, lapas, mediji, kategorija un tagi)

Jūs paši izlemjat, kuru vietnes karti nevēlaties – mans padoms ir neveidot vietnes karti no URL, ko nevēlaties rādīt Google (noindex vai bloķēti ar robotiem).
Kad šī sākotnējā daļa ir paveikta, pārejam pie satura daļas un paskaidrosim, kādi faktori jums jāņem vērā un kā WordPress darbojas satura optimizācijai.
Satura optimizācija WordPress sistēmai
Kad sākam optimizēt lapu vai ierakstu, mums jāzina, kas jāņem vērā.
Svarīgākie tagi satura optimizācijā ir:
- Title <title> HTML kodā
- Description <meta name="description" content=" aprakstošs teksts" >
- Virsrakstu hierarhija <h1, h2, h3, h4… >
- ALT tags <img src="image url" alt="attēla apraksts">
WordPress lapas ātruma optimizācija (WPO)
Tagad nopietni – šī ir daļa, kas patiešām rada galvassāpes ikvienam tīmekļa pārzinim, jo ielādi ietekmē daudzi mainīgie. Mums ir dažādi rīki ielādes ātruma mērīšanai – pastāstīšu par tiem, kurus izmantoju, un kā es tos izmantoju.
Pamatjēdzieni
WPO (Web Performance Optimization) analīze tiek veikta, lai uzlabotu jūsu vietnes ielādi. Izmantotie rīki nav 100 % precīzi, un katrs lietotājs var iegūt atšķirīgus vietnes ielādes laikus.
Tāpēc, optimizējot vietni, mūsu mērķis nav iegūt maksimāli iespējamo vērtējumu izmantotajos audita rīkos, bet gan uzlabot noteiktus aspektus, lai neatkarīgi no lietotāja viņi pamanītu mūsu vietnes ielādes uzlabojumu.
Strādājot ar WPO, mēģinām optimizēt to, kas ir mūsu iespēju robežās:
- Request: resursu veiktie pieprasījumi uz izcelsmes vietu (mūsu serveri vai citu ārēju serveri)
- Total Page Size: lapas ielādēto resursu izmērs.
- Fully Loaded Time: kopējais lapas ielādes laiks.
Citi aspekti, piemēram, servera atbilde, lai gan mēs varam strādāt pie tā uzlabošanas, mums nav tik pieejami.
Gtmetrix un Lighthouse
Izmantosim divus pieejamus un bezmaksas rīkus – nu, Gtmetrix ir maksas versija, taču bezmaksas versijas funkcijas mums ir pietiekamas.
Skaidrojumam izmantošu man piederošu vietni, kurā esmu atspējojis spraudņus, kas man palīdz ar optimizāciju.

Man nācās izmantot jaunu kešatmiņas versiju, jo rīks nolasīja veco kešoto versiju (ar aktivizētajiem spraudņiem) un rādīja labus optimizācijas rezultātus, kas manam piemēram nebija vēlams.
Atcerieties: ja vēlaties jaunu kešatmiņas versiju, pievienojiet savai URL ? un aiz tā jebkādu simbolu, piemēram, url?version1
Kā jau iepriekš teicām, pieprasījumi ir viens no pamatfaktoriem, ar ko mums jāstrādā. Šim nolūkam analizēsim to, ko dēvē par Waterfall jeb izpildes laiku kaskādi.
Waterfall

Kā redzam šajā kaskādē, ir veikti 87 pieprasījumi. Katram no šiem pieprasījumiem ir nosaukums, statuss, atrašanās vieta un izmērs.
Ar ko sākam darbu?
Attēli
Ja aplūkojam jebkuru WPO analīzes rīku neoptimizētā vietnē, redzēsim, ka tie iesaka 4 veidu darbības, kas jāveic ar attēlu resursiem.
Samaziniet to izšķirtspēju
Ir miljoniem izmantojamu rīku – gan tiešsaistē, gan PC vai MAC. Man patīk visu darīt ar Photoshop, taču, protams, viss ir atkarīgs no optimizējamo attēlu skaita. Kā tiešsaistes rīku varat izmantot Kraken.io, taču, kā jau iepriekš teicu, es palieku pie Photoshop, jo ar to var veikt precīzāku optimizāciju.
Piegādājiet attēlus maksimālajā nolasīšanas izmērā
Tā ir ļoti izplatīta kļūda. Izmantot fotoattēlu krātuves vietni, lejupielādēt 2800 x 1600 attēlu un izmantot to mūsu vietnē 900 x 400 izšķirtspējā.
Iesaku izmantot inspektoru ar maksimālo lapas izmēru un aplūkot, kāds izmērs tiek izmantots.

Redzam, kā inspektors mums parāda maksimālo izmēru, kas tiek izmantots mūsu emuāra attēlos – tādam vajadzētu būt mūsu attēla izmēram.
Izmantojiet jaunās paaudzes formātus vai formātus ar labu saspiešanu
Ja nevēlaties pārāk sarežģīt dzīvi ar tādiem formātiem kā webp (ko izstrādājis Google, bet vēl neatbalsta 100 % pārlūku), izmantojiet JPEG un izvairieties no PNG, ja vien jums nav nepieciešams caurspīdīgs kanāls.
Izmantojiet atliktās ielādes (lazy loading) funkciju
Lazy load jeb atliktā ielāde ir viena no interesantākajām funkcijām, kas neļauj tādiem elementiem kā attēli vai video ielādēties uzreiz. Tā atliek attēlu ielādi pirmajā mirklī.
Padomājiet par attēliem, kas atrodas mūsu lapas apakšā – kāpēc mēs vēlamies tos ielādēt, ja lietotājs tos vēl nav sasniedzis?
Spraudņi attēlu optimizācijai
Lai gan personīgi es neesmu liels šāda veida spraudņu cienītājs, iesakīšu dažus, kas var atrisināt optimizācijas problēmas, ja saskaraties ar vietnēm, kurās ir daudz attēlu.
- Imagify
- EWWW Image Optimizer
- WP Smush
CSS, HTML un JavaScript minificēšana un apvienošana
Minificēšanas mērķis ir samazināt šo resursu svaru – jo mazāks svars lapai jāielādē, jo ātrāka būs šī ielāde.
Lai gan šķiet, ka tā ir pamata darbība (jo visi to iesaka), tā nav darbība, no kuras iegūsim izcilus rezultātus.
No otras puses, apvienošanas darbība būs noderīgāka, taču tā ir smalkāka.
Kas būtu ideāli?
Ideāli būtu, ja būtu mazi faili ar JS funkcijām vai CSS stiliem, kas patiešām tiek izmantoti tajā HTML, tomēr katrs dizainers un katrs programmētājs pats izlemj, ko iekļaut savā CSS un JS. Apskatiet manas vietnes piemēru pirms optimizācijas. Nu, es meloju, jo, lai gan esmu atspējojis spraudņus, man joprojām ir minificēti faili.

29 pieprasījumi tikai JavaScript vien. Tas ir šausmīgi, taču ņemiet vērā, ka, kad veicat kaut ko līdzīgu Youtube video iegulšanai, jūs ielādējat JS (Javascript) resursu, tāpēc, ja jums ir vairāki video, viss reizinās.
Un tagad parādīšu resursu ielādi pēc optimizācijas.

Tagad mums ir tikai 4 JS. Tas ir apvienošanas (combine) funkcijas dēļ.
Ar CSS notika tas pats – redzam „pirms“:

Un „pēc“:

Pieprasījumu samazinājumu izraisīja ne tikai CSS un JS apvienošana – mēs arī pārstājām ielādēt noteiktus nevajadzīgus resursus, piemēram, tipisko Wp-emoji-release.js (emocijzīmes WordPress sistēmā).
Kas mums vēl atliek darāms?
Nu, lai turpinātu optimizāciju, mums nāktos ķerties pie JS pa vienam un aplūkot, vai var veikt atliktu vai asinhronu ielādi.
- JS Async: resurss tiek lejupielādēts, neapturot HTML ielādi, taču pēc lejupielādes tas tomēr aptur ielādi, lai izpildītu JS.
- JS defer: resurss arī tiek lejupielādēts paralēli HTML ielādei, bet tiek izpildīts ielādes beigās – skripts neko nebloķē.
Jābūt skaidram, ka šis atribūts ir paredzēts ārējam JS, nevis tam, kas tiek izpildīts INLINE (tajā pašā HTML).
Kešatmiņas optimizācija
Neapšaubāmi viena no svarīgākajām ielādes ātruma optimizācijas daļām, taču mums jāņem vērā, ka, lai tas būtu noderīgi, lietotājam iepriekš jābūt apmeklējušam mūsu vietni un lejupielādējušam pārlūkam nepieciešamos resursus.
Proti, kešatmiņas optimizācija ir svarīga, taču tā var nebūt tik nozīmīga, ja „tas lietotājs“ mūsu vietni vairs neapmeklēs.
Kešatmiņas optimizācija ir viena no daļām, ko visvairāk novērtē visi ielādes audita rīki. Tālāk paskaidrošu, kuras daļas jāņem vērā.
Ko dara kešatmiņas spraudnis?
Kešatmiņas spraudnis veido dažādu apstrādāto vietnes daļu (lapas, objektu, DB vaicājumu) kopijas, lai pēc tam tās piegādātu un ietaupītu gaidīšanas laiku, veicot pieprasījumus serverim.
- Derīguma termiņš jeb maksimālais kešatmiņas vecums, pirms tā tiek kešota atkārtoti: šis faktors ļoti atkarīgs no jūsu vietnes veida – ja jūsu saturs nemainās bieži, varat izmantot ilgāku ilgumu; ja jūsu vietne tiek atjaunināta bieži vai vairākas reizes dienā, saīsiniet šo ilgumu.
Ja esam veikuši šo darbību ar kādu no tirgū esošajiem kešatmiņas spraudņiem, kurus drīz aplūkosim, varam Chrome izstrādātāja rīkos pārbaudīt, kā esam strādājuši ar šo funkciju:
Mums ir vairākas kešošanas metodes:
- Last-Modified
- ETag (Entity Tag)
- Expires
- Max-age
Ielādēsim savu vietni ar atvērtiem Chrome izstrādātāja rīkiem un izvēlēsimies opciju Network – tagad varam redzēt visus resursu pieprasījumus, ko veic mūsu pārlūks. Noklikšķinot uz jebkura no šiem resursiem un izvēloties opciju Headers, varēsim redzēt šo failu galveņu atbildi un to, vai mums ir aktivizēta kešošana un kura metode tiek izmantota.
SEO Alive gadījumā redzam, ka tas notiek ar MAX-AGE. Šajā daļā arī redzam, vai serverī tiek veikta GZIP saspiešana.

- Kešatmiņa pieteikušamies lietotājiem: šī funkcija ir svarīga, lai pieteikušamies lietotājiem netiktu piegādātas kešotās lapas, ja viņi gatavojas atjaunināt WordPress, jo pretējā gadījumā viņi neredzēs veiktās izmaiņas.
- Mobilā kešatmiņa: daudzi spraudņi piedāvā iespēju ģenerēt dažādas „kešatmiņas“ dažādām ierīcēm – iesaku to, ja jūsu mobilā versija ir pielāgota, nevis atsaucīga (responsive) versija.
Spraudņi ielādes ātruma optimizācijai WordPress sistēmā
Vēlējos paskaidrot svarīgākās optimizācijas daļas pirms pārejas pie spraudņu tēmas, jo gandrīz visos spraudņos iepriekš aprakstītais ir aktivizēšanas opcijas, un tieši jums jāapsver, vai tās aktivizēt, vai ne.
Tāpēc labprātāk to paskaidroju, lai jūs to saprastu, pirms pastāstu, ar kuriem spraudņiem jāveic šīs darbības. Šie ir populārākie WordPress spraudņi.
- WP Rocket
- W3 Total Cache
- WP Fastest Cache
- Autooptimize
Visos no tiem jums būs iepriekš apspriestās opcijas, lai gan var būt, ka darbam ar JS tie ir ierobežotāki ielādes veida ziņā.
Rīki ielādes ātruma mērīšanai
Kā jūs varat iedomāties, ir milzum daudz rīku, kas palīdz uzzināt vietnes ielādes ātrumu.
Ņemiet vērā, ka WordPress veido dažāda veida lapas, un katra no tām reaģēs atšķirīgi, tāpēc, ja jums jāveic WPO audits, veiciet to:
- Sākumlapai
- Kategorijām
- Lapām
- Ierakstiem
Svarīgi zināt arī to, ka Google Analytics ir metrika, kas mēra vietnes ātrumu, un, ja izgūsiet metriku pēc nedēļas dienas vai mēneša, tā var noderēt secinājumu izdarīšanai.

Šie ir populārākie rīki WPO audita veikšanai:
- Google PageSpeed Insights
- GTmetrix
- Pingdom Tools
Strukturētie dati WordPress sistēmā
Ja tikai sākat darbu ar SEO, jūs droši vien neatpazīstat semantiskā tīmekļa jēdzienu, taču mūsdienās ir grūti nodarboties ar SEO, nesaprotot šo jēdzienu.
Google dienu no dienas strādā, lai uzlabotu tīmekļa vietņu lasīšanu un interpretāciju, un datu iezīmēšana, ieviešot semantiskos metadatus, atvieglo šo darbu.
Šim nolūkam mums ir dažādi spraudņi, kas palīdz iezīmēt dažādo mūsu vietnes lapu saturu.
Ja esat instalējis Rank Math, ar spraudņa palīdzību jums ir sava satura metadatu saraksts, kas redzams Rich Snippet cilnē.

Šīs opcijas trūkums ir tas, ka bieži satura vienībai var būt vairāk nekā viena datu iezīme, piemēram:
Saturu varat iezīmēt kā Blog Posting, bet saturā ietvert 3 neiezīmētus video.
Ja esat pazīstams ar strukturētajiem datiem, varat pievienot HTML blokus ar Gutenberg (WordPress bloku redaktoru) un pievienot tos manuāli.
Google nodrošina rīku, kas ļauj pārbaudīt, vai jūsu strukturētie dati ir pareizi ieviesti.
Ieteicamie spraudņi SEO uzlabošanai WordPress sistēmā
Noslēdzot šo rakstu, vēlētos ieteikt dažus SEO spraudņus WordPress sistēmai, kas var palīdzēt uzlabot jūsu vietni.
Satura rādītājs (Table of contents)
Lai gan šo spraudni viegli var izveidot ar HTML, tā piedāvātās stila un dizaina opcijas padara to par pamatu lietotāju navigācijas uzlabošanai lapā.

Saistītie ieraksti
Mūsdienās daudziem spraudņiem ir saistīto ierakstu opcija, taču atcerieties: ja jūsējam tās nav, šī opcija ir ļoti svarīga, lai jūsu saturs vienmēr būtu savstarpēji sasaistīts.
Atstāju jums šo spraudni, kas man ļoti palīdzēja ar dažām veidnēm.

AMP
Lapas izstrāde AMP tehnoloģijā var būt laba izvēle dažādu iemeslu dēļ: ātruma, lietojamības... vai lai strādātu pie pozicionēšanas karuseļos, piemēram, ziņu karuselī mobilajā versijā, kur šāda veida tehnoloģijai tiek dota priekšroka.
Tātad atstāju jums spraudni, ja vēlaties, lai jūsu lapas būtu AMP formātā, lai gan ir daudz pieejamu opciju.

Video vietnes karte un Google News
Lai gan daudzi SEO speciālisti vairs neizmanto vietnes kartes, es vienmēr pie tām vēršos, lai labāk kontrolētu sava satura indeksēšanu. Šeit atstāju jums spraudni video vietnes kartes izveidei un citu – Google News.


Ceru, ka šis raksts kādās savās daļās jums būs noderīgs un interesants, un, protams, ja jums ir kādi jautājumi, uz kuriem varu atbildēt, varat sazināties ar mani komentāros.
Autors: David Kaufmann

Pēdējos 10+ gadus esmu pavadījis, pilnībā aizrāvies ar SEO — un, godīgi sakot, es to nevēlētos citādi.
Mana karjera sasniedza jaunu līmeni, kad strādāju par vecāko SEO speciālistu Chess.com — vienā no 100 visapmeklētākajām vietnēm visā internetā. Darbs šādā mērogā, aptverot miljoniem lapu, desmitiem valodu un vienu no konkurētspējīgākajām SERPs, iemācīja man to, ko neviens kurss vai sertifikāts nekad nespētu. Šī pieredze mainīja manu skatījumu uz to, kā patiesībā izskatās izcils SEO — un kļuva par pamatu visam, ko esmu izveidojis kopš tā laika.
No šīs pieredzes es nodibināju SEO Alive — aģentūru zīmoliem, kas nopietni domā par organisko izaugsmi. Mēs neesam šeit, lai pārdotu dashboards un ikmēneša atskaites. Mēs esam šeit, lai veidotu stratēģijas, kas patiešām rada rezultātus, apvienojot labāko no klasiskā SEO ar aizraujošo jauno Generative Engine Optimization (GEO) pasauli — nodrošinot, ka jūsu zīmols parādās ne tikai Google zilajās saitēs, bet arī AI ģenerētajās atbildēs, ko ChatGPT, Perplexity un Google AI Overviews katru dienu piegādā miljoniem cilvēku.
Un tā kā es nevarēju atrast rīku, kas pareizi apstrādātu abas šīs pasaules, es izveidoju to pats — SEOcrawl, enterprise SEO intelligence platformu, kas vienuviet apvieno rankings, tehniskos auditus, backlinks uzraudzību, crawl veselību un AI zīmola redzamības izsekošanu. Tā ir platforma, par kuras esamību es vienmēr biju vēlējies.
Atklājiet vairāk šī autora satura

