Lõplik WordPressi SEO juhend

Oleme hiljaks jäänud, kui tahame rääkida SEO tähtsusest sellises digitaalse kommunikatsiooni ökosüsteemis. Suurettevõtted, väikesed ja keskmise suurusega ettevõtted, vabakutselised ja üksiktarbijad – kõigil võib olla juurdepääs veebisaidile, ja just siin tuleb mängu WordPress: maailma enim kasutajaid omav CMS (seda kasutab 27+ miljonit veebisaiti, mis moodustab üle 50% internetis olevatest CMS-idest).
Järgnevas artiklis räägime WordPressi SEO-st – alustame kõige põhilisematest mõistetest ja liigume järk-järgult edasijõudnud tasemele.
Alamdomeeni ümbersuunamised – www-ga või ilma?
Alustame soovitusega neile, kes kavatsevad WordPressi installida: enne installimist otsusta, millist domeeni versiooni eelistad – www-ga või ilma selleta, sest WordPressi installirakenduse käivitamisel – näiteks CPANEL-i keskkonnas – antakse sulle võimalus teha kogu installimine sinu eelistatud valiku järgi, nii et versioon, mida sa ei valinud, suunatakse hiljem ümber.
Kui jätsid selle sammu vahele, tuleb sul htaccess-failiga töötada. On olemas pluginaid nagu WP HTACCESS EDITOR, mis muudavad faili redigeerimise lihtsamaks, kuid soovitan: kui sa pole kindel, mida teed, palu abi, sest see fail on veebisaidi töötamiseks ülioluline.
Kui otsustad siiski selle valiku kasuks, on siin kood, mille peaksid lisama.
Domeeni ilma www-ta ümbersuunamine www-ga versioonile
RewriteEngine On
RewriteCond %{HTTP_HOST} ^yourdomain.com [NC]
RewriteRule ^(.)$ http://www.yourdomain.com/$1 [L,R=301]*
Domeeni www-ga ümbersuunamine www-ta versioonile
RewriteEngine on RewriteCond %{HTTP_HOST} ^www.yourdomain.com RewriteRule ^(.*)$ http://yourdomain.com/$1 [R=301,L] Sellegipoolest tahan veel kord rõhutada, et htaccess-faili redigeerimine on midagi, mida pead väga hästi mõistma, seega kui kavatsed seda redigeerida, tee kõigepealt varukoopia.
WordPressi installimine: esimesed sammud optimeerimisel
Kõigepealt pead mõistma, kuidas Google töötab, ja et iga sinu tegevus peaks – nii palju kui võimalik – muutma Googleboti töö lihtsamaks, kui see meie saiti külastab.
Miks ma seda ütlen?
Sest see punkt on üks levinumaid vigu, mida kasutajad teevad – mitte ainult WordPressi kasutajad, vaid iga veebidisainer või veebihaldur.
Kui sinu sisu pole valmis, ära luba Googlebotil sellele juurde pääseda, sest nii aeglustad oma URL-ide reastamise protsessi.
Seega kui pean enne alustamist midagi soovitama, siis on see „veenda otsingumootoreid loobuma minu sisu indekseerimisest.“
WordPressi indekseerimine: millal peaksin oma saiti indekseerima?
Installimise ajal on meil seadistusekraanil võimalus blokeerida otsingumootorite juurdepääs. Kuid kui jätsime selle sammu vahele, saame seda teha menüüs Seaded > Lugemine.

Robotite juurdepääsu blokeerimise valik
Selle „keelu“ saab seada ka populaarses Robots.txt failis. Kui oled kogenumam veebiarenduse kasutaja, saad FTP-konto kaudu, mille on loonud või pakkunud sinu majutusteenuse pakkuja, lisada selle faili põhikataloogi, kus sinu sait majutatakse.
Robots.txt faili saab lihtsalt luua rakendusega Notepad (Windows) või TextEdit (Mac), kuid pea meeles, et see peab olema tekstifail; sinna lisame need kaks rida:
*User-agent: **
Disallow: / Selles loendis näeme populaarsemaid Google roomajaid (User-Agents)

Erinevad Google kasutajaagendid
Meie koodis, kui märgime User-agent: *, ütleme, et peame silmas kõiki roboteid – ükski neist ei pääse meie veebisaidile. Võime viidata ka ühele konkreetsele robotile (Googlebot, Googlebot-Video jne), kuid selles etapis ma seda ei soovita. Seega – kõik blokeeritud.
URL-i struktuur ja sõbralikud URL-id
Kui oleme selgeks teinud, milline on meie eelistatud domeen, ja blokeerinud robotite juurdepääsu, liigume edasi URL-i struktuuri juurde.
See samm tuleb teha enne roomamist ja indekseerimist, sest muidu peaksime sukelduma ümbersuunamiste maailma, mis pole ideaalne.
WordPress pakub sulle vaikimisi valikuid, et saaksid valida selle, mis su saidi sisu kõige paremini struktureerib. See valik sõltub projektist ja igast inimesest; kõik valikud on teostatavad, kui projekt seda nõuab.
Selgitan:
WordPressi juhtpaneelile jõudes läheme menüüsse Seaded > Püsilingid
Ja näeme seda ekraani:

URL-i struktuur püsilinkidega
Nagu eespool ütlesin, sõltub valik igast inimesest, kuid kui räägime SEO-st, on eelistatav töötada sõbralikuma URL-i vorminguga.
Mis on sõbralikud URL-id?
Sõbralikeks URL-ideks nimetame neid URL-e, mis on kasutajale arusaadavad ja pakuvad esmapilgul URL-i sisu semantilist tõlgendust.
- Sõbralik URL: /blog/
- Mittesõbralik ehk dünaamiline URL:* https://seocrawl.com/?ref=13535?sfas*
Esimene URL annab teavet sisu kohta, mille leiad, teine mitte, kuid see ei tähenda, et Amazon teeks midagi valesti – pigem kasutab see erinevaid kontrolliparameetreid, et oma URL-e sisemiselt tuvastada.
Pea meeles, et miljonite toodete ja kategooriatega muudavad numbrid nende jaoks kontrolli lihtsamaks.
Kui see selgitus on tehtud ja valikuid vaadates, on meil 3 tüüpi URL-e:
- Kuupäevaga
- Sissekande või postituse nimega
- Kohandatav muutujate abil.
Püsilingid WordPressis
URL-id kuupäevaga

Paljud SEO konsultandid lükkavad need URL-id tagasi, eriti seetõttu, et need paljastavad sissekande loomise kuupäeva, kuid seda tüüpi URL on väga kasulik, kui sul on suur sisumaht.
Näiteks uudistemeedia juhtum. Kui vaatad kõiki nende URL-e, on neis kuupäev. Uudisteväljaandele on hädavajalik loogiline struktuur, et saaks oma URL-e arhiivi salvestada, ning see on ka identifikaator, mis kulub ära, et teada, millal lugu avaldati.
El País kasutab segatüüpi URL-i, kuna selles on semantiline teave, näiteks kategooria nimi, kuupäev ja alamkategooria, ning see lõpeb uudise identifikaatoriga.
Teised ajalehed lisavad lisaks uudise identifikaatorile URL-i ka termineid uudise pealkirjast.
URL-i süntaksiga töötades on üks väga huvitav valik, mida sageli filtreeritakse: stoppsõnad.
Stoppsõnad on terminid, mida tahame uue URL-i loomisel vältida. See toiming tehakse programmeerimise teel – meie WordPressi puhul PHP kaudu.
Stoppsõnade näited oleksid: artiklid, asesõnad, numbrid jne.
Rank Math pakub valikut, mis võimaldab seda tüüpi termineid vältida.

Stoppsõnade eemaldamine URL-ide loomisel
URL sissekande või lehe nimega

Lihtne ja laialdaselt kasutatav valik. Meie URL-id moodustatakse sissekande nimest või muudetud slug-ist.
Slug-i ehk püsilinki saab sissekannetes redigeerida, seega kui me ei taha WordPressi pakutavat automaatset valikut, muudame URL-i käsitsi (ainult sissekannet, mitte domeeni).

Kohandatud URL muutujate abil

Nagu näed, tulevad siin mängu erinevad muutujad, et luua meile meelepärane URL.
Muutujad annavad kasutajale rohkem teavet. Kui soovid struktureerida oma sisu viisil, mis nõuab mõne muutuja lisamist, vali see valik.
Toon näite: tahame oma URL-is märkida kategooria, aasta, postituse nime ja identifikaatori.
https://seocrawl.com/%category%/%year%/%postname%/%post_id%/
Informatsiooniarhitektuur: kategooriad, vanemlehed ja sildid
Enne informatsiooniarhitektuuriga alustamist peame mõistma kõiki võimalusi, mida WordPress meile sisuga töötamiseks pakub.
Nagu sa ilmselt juba tead, on WordPressil oma eripärad, ja kuigi postitus ja leht võivad pealtnäha tunduda ühesugused, eristavad neid siiski funktsionaalsus ja pluginad.
Sisu struktureerimine on SEO oluline osa, et töötada sarnase sisu linkimise ja sidumisega – sellega, mida tuntakse sisuklastritena (content clusters).
Selleks saame kasutada:
- Kategooriad
- Sildid
- Sissekanded (Posts)
- Lehed
- Alamlehed
Kategooriad, sildid ja sissekanded (Posts)
WordPressis on kaks viisi sissekannete automaatseks rühmitamiseks: kategooriate ja siltidega.
Millal kasutame kategooriaid ja millal silte?
Mõistes, et kategooriad ja sildid aitavad meil sisu rühmitada, peab otsus neid kasutada alati sõltuma sisu hulgast, mida kavatseme luua, sest muidu võime sisu dubleerida.
Nii kategooriad kui ka sildid aitavad meil sisemise linkimisega ja sellega, kuidas Google meie kogu sisu roomab, kuid nagu ütlesime, tuleb osata neid kasutada.
Minu soovitus on kasutada kategooriaid, kui kavatseme oma saidi teema raames sageli sisu luua.
Kasutame silte, kui konkreetsete teemade raames on suur hulk sisu, millel on midagi ühist.
Toon näite:
Sport oleks kategooria, kuid Cristiano Ronaldo võiks olla silt – sellegipoolest peaksid endalt küsima: mitu lugu ma Cristiano Ronaldost kirjutan?
Kui me ei loo piisavalt sisu, et meie lehtede rühmitused üksteisest tegelikult erineksid, on meil kaks võimalust: kas mitte luua kategooriat/silti või neid mitte indekseerida.
Kategooriate ja siltidega töötades on ka teisi lisandmooduleid, mis aitavad meie sisul sarnase sisuga siduda.
Navigeerimistee (Breadcrumb)
WordPress ehitab navigeerimistee struktureeritud kategooria ja postituse sisu põhjal, seega kui tahame kasutada navigeerimisteed (breadcrumbs), et tagada meie sisu hea linkimine, peaksime valima seda tüüpi arhitektuuri.
Seega meie postitus näeks välja selline:
- URL : sitename.com/category/category-name/post-name
- Navigeerimistee: Avaleht > Kategooria nimi > Postituse nimi
Navigeerimistee lisamiseks on pluginaid, kuid kõik need tuginevad meie WordPressi andmebaasi struktuurile; tänase päevani ei tea ma ühtegi pluginat, mis annaks paindlikkust selle määratlemisel.
Nagu sa juba märkasid, lisab kategooriaga postituse URL termini CATEGORY.
See on WordPressiga standardvarustuses, see tähendab, et leiad selle igast WordPressist, ja püsilinkide valik võimaldab sul vaid asendada ühe nime teisega (category mõne teise terminiga).
Meil on selle lahendamiseks mitu võimalust – taas pakub Rank Math valikut:

On ka pluginaid, mis aitavad selle termini eemaldada ja jätta puhtama URL-i.

Pluginad Category eemaldamiseks WordPressi URL-ist
Vanemleht ja alamleht
Tagasi sisu struktuuri juurde: on üks töömeetod, mis mulle meeldib – lehtede ja alamlehtedega. Tavaliselt kasutan sellist struktuuri teenuste maandumislehtede (Landing) või keskuslehtede (Hub) jaoks.
Peamine erinevus on disainipaindlikkuses, mida leht pakub, kuid kategooria mitte. Nii kategooriaid kui ka postitusi dikteerib WordPressi teema või mall, kuid lehti saab kujundada oma maitse järgi Page Builderite abil (plugin või lisandmoodul saidi kohandamiseks plokke kasutades).
Millal peaksime kasutama lehte ja alamlehte?
Selgeim näide, mis meelde tuleb, on siis, kui meil on üldine teenus ja mitu konkreetsemat teenust. Üldise teenuse jaoks loome lehe ja konkreetsete teenuste jaoks alamlehed.
- Üldine maandumisleht: Disain
- Konkreetne maandumisleht: Veebidisain, Graafiline disain, Tootedisain, Tööstusdisain...
URL-i näide:
sitename.com/design/web/
sitename.com/design/graphic/
sitename.com/design/product/
Navigeerimistee: *Avaleht > Disain > Veebidisain *
Selleks peame artiklitoimetajas (postitus või sissekanne) lubama lehe atribuutide (Page Attributes) paneeli, mis asub ülaosas.

Nüüd on meie lehe paremal küljel lisatud moodul lehe atribuutidega.

Valides ühe olemasolevatest lehtedest, sõltub praegune leht valitust ja muutub selle alamleheks.
SEO plugin WordPressile: Rank Math, Yoast...
Kui meil on URL-i struktuur ja osa informatsiooniarhitektuurist selge, tahtsin selles etapis lisada SEO plugina installimise (Rank Math, Yoast, All In One SEO...). Praegu muudavad need pluginad SEO osas elu lihtsamaks, kuna neil on olulised tööriistad SEO-ga töötamiseks sinu sisus.
Kui see plugin on installitud, on aeg lisada selle veebisaidi jälgimis- ja kinnituskood, mida tahame jälgida. Analüütikatööriistadena pole paremaid tööriistu kui Google Analytics ja Search Console.
Jälgimiskood ehk Google Analyticsi kood
Nagu WordPressis näed – kui veel ei näinud – on alati mitu viisi mingi protsessi tegemiseks.
Analyticsi jälgimiskoodi ehk jälgimis-ID sisestada saame koodiga lehe enda HTML-is, malli kaudu, mis tavaliselt pakub kohta koodi sisestamiseks päisesse (Header), või pluginaga.
Kui sa ei tea, kuidas Analyticsi jälgimis-ID-d hankida, näitab Google tugileht sulle teed https://support.google.com/sites/answer/97459?hl=en
Google'il on WordPressile oma plugin (Site Kit Google), kus saame kogu analüütikaosa.

Meil on ka lihtsaid valikuid Google Analyticsi jälgimiskoodi lisamiseks.

Tänapäeval võtavad disainerid neid veebihaldurite vajadusi juba arvesse ja pakuvad malli konfiguratsioonis lahtrit koodi sisestamiseks päisesse.

Meie WordPressi kinnitamine Search Console'is
Domeeni kinnitamiseks Search Console'is on erinevaid viise; räägin 2-st: ühe Google kinnitusfailiga ja teise SEO pluginaga, millega töötame.
- Google Search Console'i kinnitusfail.
- Atribuudi kinnituskoodiga
Lihtsaks kinnitamiseks saame taas kasutada Rank Mathi.

Esimesse välja saame otse sisestada ID, mille leiame Search Console'i kinnitusosast (kui klõpsame lahtris oleval tekstil, viib see meid otse URL-ile, mis annab selle teabe).
Seejärel peame vaid lisama allpool punasega märgitud ID.
<meta name="google-site-verification" content="example code" />
Kuidas luua WordPressis saidikaarti (Sitemap)
Veel üks punkt, mis SEO-sektoris vaidlusi tekitab, on saidikaardid (sitemaps). See fail oli varem oluline, et Google saaks pääseda ligi kõigile meie URL-idele.
On tõsi, et asjad on muutunud ja Google ei vaja faili, et sinu saiti täielikult roomata. Kuid sama tõsi on ka see, et Search Console'i ja saidikaartidega on sul lisateavet, mis võib aidata lahendada tulevasi URL-i probleeme.
Saidikaardi loomiseks on palju viise, kuid ideaalne on, et see oleks dünaamiline fail, mis uueneb uute sissekannete või lehtedega.
Olgu me kasutame Yoasti, Rank Mathi või mõnda muud SEO pluginat, selle funktsionaalsuse juurde pääsemiseks peame lihtsalt selle märkima.
Selle selgitamiseks kasutan Rank Mathi pakutavat tööriista ja läheme valikusse Sitemap Settings.

Saidikaardi seadistamise näide Rank Mathis
Nagu pildil näeme, saame kohandada erinevaid valikuid URL-i tüübi kohta, millega töötame.
- Lingid saidikaardi kohta: 1000 (jätame vaikevaliku; see viitab URL-ide arvule, mida tahame oma failis)
- Pildid saidikaartidel: soovitan selle valiku aktiveerida, kui su pildid on originaalsed ja annavad artiklile teavet.
Igal juhul, kui kasutad oma sisus pilte, roomab Google need hõlpsalt.

Selle konfiguratsiooniosa esimesed kaks lahtrit on mõeldud sissekannete või lehtede välistamiseks, mida sa ei taha saidikaardile lisada.
Seda tehakse identifikaatori kaudu, mille leiame järgmiselt.
Kui läheme sissekannete või lehtede sektsiooni ja viime kursori sissekande kohale ilma klõpsamata, ilmub alaossa URL.

Kui vaatame alla, punases lahtris näeme post=5745 – number on identifikaator, mida peame kasutama, et see leht saidikaardil ei ilmuks.
Järgmine valik on taksonoomiatega, see tähendab teha sama SILTIDE ja kategooriatega.
Rank Mathi valik on piiratud ja loob vaikimisi 5 tüüpi saidikaarti (sissekanded, lehed, meedia, kategooria ja sildid)

Sinu otsustada on, millist saidikaarti sa ei taha – minu soovitus on, et sa ei loo saidikaarti URL-idest, mida sa ei taha Google'ile näidata (noindex või robotitega blokeeritud).
Kui see esialgne osa on tehtud, liigume edasi sisuosa juurde ja selgitame, milliseid tegureid peaksid arvestama ja kuidas WordPress sisu optimeerimiseks töötab.
Sisu optimeerimine WordPressile
Kui hakkame lehte või sissekannet optimeerima, peame teadma, mida arvestada.
Kõige olulisemad sildid sisu optimeerimisel on:
- Title <title> HTML-is
- Description <meta name="description" content=" kirjeldav tekst" >
- Pealkirjade hierarhia <h1, h2, h3, h4… >
- ALT-silt <img src="image url" alt="pildi kirjeldus">
WordPressi lehe kiiruse optimeerimine (WPO)
Nüüd tõsiselt – see on osa, mis tekitab igale veebihaldurile tõesti peavalu, sest laadimist mõjutab palju muutujaid. Meil on laadimiskiiruse mõõtmiseks erinevaid tööriistu – räägin nendest, mida kasutan, ja kuidas ma neid kasutan.
Põhimõisted
WPO (Web Performance Optimization) analüüs tehakse selleks, et parandada su saidi laadimist. Kasutatavad tööriistad pole 100% täpsed ja iga kasutaja võib saada saidile erinevaid laadimisaegu.
Just seetõttu ei ole meie eesmärk saidi optimeerimisel saada kasutatavates auditeerimistööriistades maksimaalset võimalikku hinnet, vaid parandada teatud aspekte, et kasutajast sõltumata näeksid nad meie saidi laadimises paranemist.
WPO-ga töötades püüame optimeerida seda, mis on meie käeulatuses:
- Request: ressursside tehtud päringud lähtekohta (meie server või mõni muu väline server)
- Total Page Size: lehe laaditud ressursside suurus.
- Fully Loaded Time: lehe kogulaadimisaeg.
Muud aspektid, näiteks serveri vastus, kuigi saame selle parandamiseks tööd teha, pole meile nii kättesaadavad.
Gtmetrix ja Lighthouse
Läheneme kahe kättesaadava ja tasuta tööriistaga – noh, Gtmetrixil on tasuline versioon, kuid tasuta versiooni funktsioonid on meile piisavad.
Selgituseks kasutan endale kuuluvat saiti, millel olen deaktiveerinud pluginad, mis mind optimeerimisel aitavad.

Pidin kasutama uut vahemälu versiooni, sest tööriist luges vana vahemällu salvestatud versiooni (aktiveeritud pluginatega) ja andis mulle häid optimeerimistulemusi, mis minu näite jaoks polnud soovitud.
Pea meeles: kui tahad uut vahemälu versiooni, lisa oma URL-ile ? ja selle järele mis tahes märk, näiteks url?version1
Nagu varem ütlesime, on päringud üks põhiteguritest, millega peame töötama. Selleks analüüsime seda, mida tuntakse kui Waterfall ehk täitmisaegade kaskaad.
Waterfall

Nagu selles kaskaadis näeme, on tehtud 87 päringut. Igal neist päringutest on nimi, olek, asukoht ja suurus.
Kuidas tööd alustame?
Pildid
Kui vaatame mis tahes WPO analüüsi tööriista optimeerimata saidil, näeme, et need soovitavad pildiressurssidega teha 4 tüüpi toiminguid.
Vähenda nende resolutsiooni
On miljoneid kasutatavaid tööriistu, nii veebis kui ka PC või MAC jaoks. Mulle meeldib kõike teha Photoshopiga, kuid muidugi sõltub kõik optimeeritavate piltide arvust. Veebitööriistana võid kasutada Kraken.io, kuid nagu varem ütlesin, jään Photoshopi juurde, sest sellega saab teha täpsemat optimeerimist.
Esita pildid maksimaalse lugemissuurusega
See on väga levinud viga. Kasutada fotopanga saiti, laadida alla 2800 x 1600 pilt ja kasutada seda meie saidil resolutsioonis 900 x 400.
Minu soovitus on kasutada inspektorit lehe maksimaalse suurusega ja vaadata, millist suurust kasutatakse.

Näeme, kuidas inspektor näitab meile meie ajaveebi piltides kasutatavat maksimaalset suurust – selline peakski olema meie pildi suurus.
Kasuta uue põlvkonna formaate või hea tihendusega formaate
Kui sa ei taha oma elu liialt keerulisemaks teha selliste formaatidega nagu webp (mille on välja töötanud Google, kuid mida veel 100% brauseritest ei toeta), kasuta JPEG-i ja väldi PNG-d, välja arvatud juhul, kui vajad läbipaistvat kanalit.
Kasuta laisa laadimise (lazy loading) funktsiooni
Lazy load ehk edasilükatud laadimine on üks huvitavamaid funktsioone, mis takistab selliste elementide nagu pildid või videod kohest laadimist. See lükkab piltide laadimise esimesel hetkel edasi.
Mõtle piltidele, mis on meie lehe allosas – miks tahame neid laadida, kui kasutaja pole neid veel jõudnud?
Pluginad piltide optimeerimiseks
Kuigi ma isiklikult pole seda tüüpi pluginate suur fänn, soovitan mõnda, mis võivad lahendada optimeerimisprobleeme, kui puutud kokku saitidega, kus on palju pilte.
- Imagify
- EWWW Image Optimizer
- WP Smush
CSS-i, HTML-i ja JavaScripti minimeerimine ja ühendamine
Minimeerimise eesmärk on vähendada nende ressursside kaalu – mida väiksema kaaluga leht peab laadima, seda kiirem on see laadimine.
Kuigi see tundub põhitoiminguna (kuna kõik seda soovitavad), pole see toiming, millest saame suurepäraseid tulemusi.
Teisalt on ühendamise toiming kasulikum, kuid see on delikaatsem.
Mis oleks ideaalne?
Ideaalne on omada väikeseid faile JS-funktsioonide või CSS-stiilidega, mida selles HTML-is tegelikult kasutatakse, kuid iga disainer ja iga programmeerija otsustab ise, mida oma CSS-i ja JS-i panna. Vaata minu saidi näidet enne optimeerimist. Noh, ma valetan, sest kuigi olen pluginad deaktiveerinud, on mul ikkagi minimeeritud failid.

29 päringut ainuüksi JavaScripti jaoks. See on jube, kuid pea meeles, et kui teed midagi sellist nagu Youtube'i video manustamine, laadid JS (Javascript) ressurssi, seega kui sul on mitu videot, kõik kordistub.
Ja nüüd näitan sulle ressursside laadimist pärast optimeerimist.

Nüüd on meil ainult 4 JS. See on tänu ühendamise (combine) funktsioonile.
CSS-iga juhtus sama – näeme „enne“:

Ja „pärast“:

Päringute vähenemine ei tulenenud ainult CSS-i ja JS-i ühendamisest – lõpetasime ka teatud mittevajalike ressursside laadimise, näiteks tüüpilise Wp-emoji-release.js (emojid WordPressis).
Mis meil veel teha jääb?
Noh, optimeerimise jätkamiseks peaksime tegelema JS-iga ükshaaval ja vaatama, kas saab teha edasilükatud või asünkroonse laadimise.
- JS Async: ressurss laaditakse alla HTML-i laadimist peatamata, kuid pärast allalaadimist peatab see siiski laadimise, et JS-i täita.
- JS defer: ressurss laaditakse samuti alla paralleelselt HTML-i laadimisega, kuid see täidetakse laadimise lõpus – skript ei blokeeri midagi.
Peab olema selge, et see atribuut on mõeldud välisele JS-ile, mitte sellele, mis täidetakse INLINE (samas HTML-is).
Vahemälu optimeerimine
Kahtlemata üks olulisemaid laadimiskiiruse optimeerimise osi, kuid peame arvestama, et selleks, et sellest kasu oleks, peab kasutaja olema varem meie saidile sisenenud ja alla laadinud brauserile vajalikud ressursid.
See tähendab, et vahemälu optimeerimine on oluline, kuid see ei pruugi olla nii määrav, kui „see kasutaja“ meie saiti uuesti ei külasta.
Vahemälu optimeerimine on üks osadest, mida kõik laadimisauditi tööriistad kõige enam hindavad. Allpool selgitan, milliseid osi arvestada.
Mida teeb vahemälu plugin?
Vahemälu plugin teeb koopiaid saidi erinevatest töödeldud osadest (leht, objektid, andmebaasi päringud), et neid seejärel esitada ja säästa ooteaega serverile päringute tegemisel.
- Kasulik eluiga ehk vahemälu maksimaalne vanus, enne kui see uuesti vahemällu salvestatakse: see tegur sõltub suuresti su saidi tüübist – kui su sisu ei muutu sageli, võid kasutada pikemat kestust; kui su saiti uuendatakse sageli või mitu korda päevas, lühenda seda kestust.
Kui oleme selle toimingu teinud mõne turul oleva vahemälu pluginaga, mida peagi vaatame, saame Chrome'i arendajatööriistadest kontrollida, kuidas oleme selle funktsiooniga töötanud:
Meil on mitu vahemällu salvestamise meetodit:
- Last-Modified
- ETag (Entity Tag)
- Expires
- Max-age
Laadime oma saidi avatud Chrome'i arendajatööriistadega ja valime valiku Network – nüüd näeme kõiki ressursipäringuid, mida meie brauser teeb. Klõpsates mis tahes neist ressurssidest ja valides valiku Headers, saame näha nende failide päiste vastust ja seda, kas meil on vahemällu salvestamine aktiveeritud ja millist meetodit kasutatakse.
SEO Alive'i puhul näeme, et see toimub MAX-AGE kaudu. Selles osas näeme ka, kas serveris tehakse GZIP-tihendamist.

- Vahemälu sisselogitud kasutajatele: see funktsioon on oluline, et sisselogitud kasutajatele ei esitataks vahemällu salvestatud lehti, kui nad kavatsevad WordPressi uuendada, sest muidu ei näe nad tehtavaid muudatusi.
- Mobiilne vahemälu: paljud pluginad pakuvad võimalust genereerida erinevaid „vahemälusid“ erinevatele seadmetele – soovitan seda, kui su mobiiliversioon on kohandatud, mitte kohanduv (responsive) versioon.
Pluginad laadimiskiiruse optimeerimiseks WordPressis
Tahtsin selgitada optimeerimise kõige olulisemaid osi enne, kui asume pluginate teema juurde, sest peaaegu kõigis pluginates on eespool selgitatu aktiveerimisvalikud ja just sina pead kaaluma, kas need aktiveerida või mitte.
Just seetõttu eelistasin seda selgitada, et sa sellest aru saaksid, enne kui räägin, milliste pluginatega need toimingud teha tuleb. Need on WordPressi populaarseimad pluginad.
- WP Rocket
- W3 Total Cache
- WP Fastest Cache
- Autooptimize
Kõigis neist on sul eespool arutatud valikud, kuigi võib olla, et JS-iga töötamiseks on need laadimistüübi osas piiratumad.
Tööriistad laadimiskiiruse mõõtmiseks
Nagu võid ette kujutada, on hulganisti tööriistu, mis aitavad meil saidi laadimiskiirust teada saada.
Pea meeles, et WordPress koosneb erinevat tüüpi lehtedest ja igaüks neist reageerib erinevalt, seega kui pead tegema WPO-auditi, tee seda:
- Avalehele
- Kategooriatele
- Lehtedele
- Sissekannetele
Sul on oluline teada ka seda, et Google Analyticsil on mõõdik, mis mõõdab saidi kiirust, ja kui tõmbad mõõdiku nädalapäeva või kuu kaupa, võib see olla kasulik järelduste tegemisel.

Need on populaarseimad tööriistad WPO-auditi tegemiseks:
- Google PageSpeed Insights
- GTmetrix
- Pingdom Tools
Struktureeritud andmed WordPressis
Kui alles alustad SEO-ga, ei tunne sa ilmselt ära semantilise veebi mõistet, kuid tänapäeval on raske SEO-ga tegeleda, seda mõistet mõistmata.
Google töötab päevast päeva, et parandada veebisaitide lugemist ja tõlgendamist, ning andmete märgistamine semantiliste metaandmete rakendamise kaudu muudab selle töö lihtsamaks.
Selleks on meil erinevaid pluginaid, mis aitavad märgistada meie saidi lehtede erinevat sisu.
Kui oled installinud Rank Mathi, on sul plugina kaudu oma sisu metaandmete loend, mis on nähtav Rich Snippet vahekaardil.

Selle valiku puudus on see, et sageli võib sisuühikul olla rohkem kui üks andmemärgistus, näiteks:
Võid märgistada sisu kui Blog Posting ja sisus omada 3 märgistamata videot.
Kui oled struktureeritud andmetega tuttav, saad lisada HTML-plokke Gutenbergiga (WordPressi plokitoimetaja) ja lisada need käsitsi.
Google teeb sulle kättesaadavaks tööriista, et valideerida, kas su struktureeritud andmed on õigesti rakendatud.
Soovitatavad pluginad SEO parandamiseks WordPressis
Selle artikli lõpetuseks tahaksin soovitada mõnda SEO pluginat WordPressile, mis võivad aidata su saiti parandada.
Sisukord (Table of contents)
Kuigi selle plugina saab hõlpsalt luua HTML-iga, muudavad selle pakutavad stiili- ja disainivalikud selle põhitööriistaks kasutaja lehel navigeerimise parandamiseks.

Seotud postitused
Tänapäeval on paljudel pluginatel seotud sissekannete valik, kuid pea meeles, et kui sinu omal seda pole, on see valik väga oluline, et su sisu oleks alati üksteisega seotud.
Jätan sulle selle plugina, mis on mind teatud mallidega palju aidanud.

AMP
Lehe arendamine AMP-is võib olla hea valik erinevatel põhjustel: kiirus, kasutatavus... või positsioneerimisega töötamiseks karussellides, näiteks uudiste karussellis mobiiliversioonis, kus seda tüüpi tehnoloogia on eelistatud.
Seega jätan sulle plugina, kui tahad, et su lehed oleksid AMP-vormingus, kuigi saadaval on palju valikuid.

Video saidikaart ja Google News
Kuigi paljud SEO-spetsialistid ei kasuta enam saidikaarte, pöördun ma alati nende poole, et paremini kontrollida oma sisu indekseerimist. Siin jätan sulle plugina video saidikaardi loomiseks ja teise Google Newsi jaoks.


Loodan, et see artikkel on mõnes oma osas sulle kasulik ja huvitav, ja loomulikult, kui sul on küsimusi, millele saan vastata, saad minuga kommentaarides ühendust võtta.
Autor: David Kaufmann

Olen viimased 10+ aastat olnud täielikult SEO-sse haaratud — ja ausalt öeldes ei tahaks ma seda teisiti.
Minu karjäär jõudis uuele tasemele, kui töötasin vanem-SEO-spetsialistina Chess.com-is — ühel 100 külastatuimast veebisaidist kogu internetis. Sellises mahus töötamine, hõlmates miljoneid lehti, kümneid keeli ja üht konkurentsitihedaimat SERPs, õpetas mulle asju, mida ükski kursus ega sertifikaat kunagi ei suudaks. See kogemus muutis minu arusaama sellest, milline suurepärane SEO tegelikult välja näeb — ja sai aluseks kõigele, mille olen sellest ajast peale üles ehitanud.
Sellest kogemusest lähtudes asutasin SEO Alive — agentuuri brändidele, kes suhtuvad orgaanilisse kasvu tõsiselt. Me ei ole siin selleks, et müüa dashboards ja igakuiseid aruandeid. Me oleme siin selleks, et luua strateegiaid, mis päriselt tulemusi liigutavad, ühendades klassikalise SEO parima osa põneva uue Generative Engine Optimization (GEO) maailmaga — tagades, et teie bränd ilmub mitte ainult Google'i sinistes linkides, vaid ka AI genereeritud vastustes, mida ChatGPT, Perplexity ja Google AI Overviews iga päev miljonitele inimestele edastavad.
Ja kuna ma ei leidnud tööriista, mis mõlemat neist maailmadest korralikult hallanuks, ehitasin selle ise — SEOcrawl, enterprise SEO intelligence platvormi, mis toob kokku rankings, tehnilised auditid, backlinks jälgimise, crawl tervise ja AI brändi nähtavuse jälgimise ühte kohta. See on platvorm, mille olemasolu ma alati soovisin.
Avastage rohkem selle autori sisu

