Viimastel aastatel oleme näinud, kuidas turundusspetsialistid asetavad laadimiskiiruse iga optimeerimisprotsessi tippu. 2017. aastal hakkas Google rõhutama laadimiskiiruse tähtsust ja selle tulevast mõju edetabelis paigutusele, kuid alles 2018. aasta suvel tegi Google selle avalduse ametlikuks.
Selle artikliga soovime aidata sul iseseisvalt alustada oma veebisaidi laadimiskiiruse optimeerimist ja parandamist. Nagu igal optimeerimisprotsessil, on ka sellel tehniline pool, mis võib muutuda keeruliseks. Kui me "SEO Alive" meeskonnas sellist artiklit kirjutame, soovime, et sa suudaksid selle ise ellu viia, kuigi mõned tegevused nõuavad kõrgemat tehnilist teadmiste taset. Ausalt öeldes ei tasu aga hulluks minna, jälitades tulemuspunkte tööriistades, mida oma saidi WPO auditeerimiseks kasutame.
Optimeerimine sõltub suuresti sellest, kuidas mall on kujundatud, ja mitte iga mall ei võimalda saavutada ühesugust jõudlust. Seda on oluline meeles pidada.
Alustame!
Mis on WPO?
Veebisaidi jõudluse optimeerimine (ingl Web Performance Optimization), mida nimetame WPO-ks, on lihtsalt erinevate protsesside optimeerimine, mis mõjutavad veebisaidi laadimist.
Kuidas mõõta veebisaidi laadimiskiirust?
Laadimiskiiruse mõõtmiseks on palju tööriistu. Populaarsemad neist on:
Enne auditi alustamist on oluline meeles pidada, et laadimiskiirus erineb iga kasutaja puhul. Erinevad muutujad võivad mõjutada, kuidas kiirus tundub kasutajale Cuencas võrreldes kasutajaga Ottawas.
Seepärast soovitame selle asemel, et töötada laadimisaegadega sekundites, keskenduda järgmiste asjade optimeerimisele:
›
Veebisaidi maht (MB)
›
Päringud
›
Serveri vastuseaeg
Kui parandame neid 3 valdkonda, paraneb laadimiskiirus sõltumata sellest, kus kasutaja asub.
Süveneme igasse valdkonda ja näeme erinevate tööriistade abil, kuidas nendega töötada, et parandada iga URL-i jõudlust. Miks ütlen "iga URL-i"? Sest, kuigi see võib tunduda ilmselge, olen kokku puutunud paljude juhtumitega, kus hinnati vaid avalehe andmeid, ja loomulikult ei laadi iga saidi leht samu ressursse.
Google'i arendajatööriistad
Enne alustamist tahan selgitada mõningaid võimalusi, mida Google oma arendajatööriistade kaudu pakub. See tööriist on üks olulisemaid, et analüüsida, kuidas veebisait töötab. Klõpsa parema hiirenupuga brauseris avatud lehel ja ilmub paneel erinevate valikutega. Läheme "Inspect" (Ctrl + Shift + I) juurde.
Kui see tööriist on avatud, liigume NETWORK valiku juurde, mille leiad ülalt. Kui vajutame brauseris uuesti ENTER, näitab tööriist erinevate ressursside laadimist.
laadimisaeg Google'i arendajatööriistades
Pildi allservas näeme andmeid, mis meid huvitavad, et saada üldpilt sellest, kuidas sait laadib.
Süvenedes sellesse paneeli ülalt ja vaadates veergude struktuuri, on meil:
Kui klõpsame ülal parema hiirenupuga, saame selle teabega veerge lisada ja eemaldada.
informatiivsete elementide lisamine ja eemaldamine sektsioonis "network"
Täiendavate informatiivsete elementide, nagu Domain, Scheme või Cookies, lubamine võib teatud juhtudel aidata leida ressursse, mis võivad meile mingit probleemi tekitada, kuid praeguseks jääme nende juurde, mis on eelnevalt määratletud.
On üks aspekt, mis, kuigi väga huvitav, puudutan siin vaid põgusalt, et seda meeles pidada. Ühenduse kiirus, eriti mobiilis, on veebisaidi laadimise oluline osa. Sellest tööriistast saame simuleerida aeglasemat kiirust, näiteks 3G mobiilis.
aeglase edastuskiiruse simuleerimine
Kuidas teada saada URL-i mahtu ja kuidas seda vähendada?
Maht, olgu see megabaitides või kilobaitides, on üks peamisi põhjuseid, miks URL-i laadimine võtab aega. Seepärast alustame süvenemisest sellesse aspekti, kuna see sillutab teed meie saidi hea optimeerimise saavutamiseks.
Järgnevad andmed pärinevad ülalmainitud tööriistast GTMETRIX ja vastavad veebisaidile, mida hakkan peagi optimeerima.
veebisaidi mahu näitajad
Keskendume parema veeru andmetele, nendele, mis viitavad (Page Details), täpsemalt Total Page Size.
Esmapilgul on selle saidi maht tublisti üle keskmise, kuid pea meeles, et oluline pole mitte saidi kogumaht, vaid see, kui kaua selle mahu laadimine aega võtab, sest on olemas midagi nimega Lazy Load – funktsioon, mis lükkab laadimise edasi, kuni kasutaja ressurssi vajab. Sellest räägime hiljem.
Selle teabe leiame ka arendajatööriistadest, sellest paneelist, mida ülal vaatasime ja mida sulle veel kord meelde tuletan.
laadimisaeg Google'i arendajatööriistades
Kui vaatad allservasse, on nii 7,5 MB kui ka 215 päringut väga lähedal GTMETRIX-i esitatud arvudele. Sulle on oluline teada, kust GTMETRIX oma teabe saab, juhuks kui tahad kunagi kasutada mõnda muud tööriista.
Nüüd vaatame, mis nii palju kaalub ja kuidas saame seda parandada.
Waterfall valik pakub visuaalset pilku sellele, kuidas ressursid laadivad, näidates ressursi URL-i, staatust, domeeni ja Size veergu. Kui klõpsame sel viimasel veerul, sorteerib see mahud suurimast väikseimani ja väikseimast suurimani.
laadimise analüüs "waterfalli" kaudu
Mahtusid vaadates näeme, nagu juhtub enamikul juhtudel, et pildid on suuresti vastutavad URL-i liigse mahu eest.
Puudub ametlik spetsifikatsioon selle kohta, milline peaks olema pildi maksimaalne maht, kuid soovitame mitte üle 100 KB ja, kui sul on selleks võimalus (kui kasutad Photoshopi, siis on), seada pildid laadima progressiivselt JPG-na ning vältida PNG-d alati, kui sa ei vaja Alfa-kanalit (läbipaistvust).
Piltide mahtu vähendades parandame oluliselt saidi laadimist, ja selleks saad kasutada mitmeid tööriistu. Mina isiklikult optimeerin Photoshopiga, kuid on huvitavaid veebipõhiseid variante:
Nii GTMetrix kui ka Google'i tööriist võimaldavad vaadata ressursse tüübi järgi, see tähendab ainult pilte, skripte, CSS-i...
See on kasulik laiema perspektiivi saamiseks selle kohta, kus töötada. Sellel URL-il moodustavad pildid 4 MB 7,2 MB-st, seega on suur osa mahuprobleemist seal. Sellegipoolest on ka teisi ressursse, mis oma tüübi kohta paistavad silma äärmiselt rasketena, näiteks üle 700 KB suurune CSS-fail ja üle 300 KB suurune skript.
Selles kohas tahaksin täpsustada, et laadimiskiiruse optimeerimist (WPO) läbi viies peame silmitsi seisma teatud probleemidega, mis, kuigi neil on lahendused, ei ole meie võimuses muuta.
Sel juhul näeme väga suurt CSS-faili. Kui disainer lõi üle 700 KB suuruse CSS-i, on selle konkreetse faili optimeerimine keeruline.
Mida saame teha, et vähendada nende failide mahtu?
Minimeerimine (CSS, JS ja HTML)
Minimeerimine (ingl minification) on protsess, mis püüab vähendada faili mahtu, eemaldades tarbetud andmed, nagu kommentaarid, tühikud, korduv kood ja kasutamata kood. Selle protsessi läbiviimiseks on palju tööriistu, välja arvatud kasutamata koodi osa, mida on raskem optimeerida ja mis nõuaks käsitsi faili sisenemist (mida ma ei soovita).
Õnneks räägime WordPressist ja, nagu me kõik teame, on WordPressis väga harv juhus, et me ei leiaks pluginat, mis selle toimingu ära teeb.
Isiklikult meeldib mulle kasutada täiesti tasuta Autoptimize'i ja tasulist WP Rocketit.
Selles artiklis ei taha ma niivõrd selgitada, kuidas need pluginad töötavad, kuivõrd seda, kuidas optimeerimisülesandeid läbi viia. Sest kui kasutame teisi pluginaid, on ka neil need valikud, ja parim on mõista, mida teeme.
Minimeerimine WP Rocketiga
See osa pole keeruline. Läheme lihtsalt failide optimeerimise vahekaardile ja märgime "minify HTML" kastikese. WP Rocketis kordub see valik allpool CSS- ja JS-failide jaoks. Sellegipoolest soovitan see kastike lubada ja testida. Korda seda valikut ükshaaval, sest kui midagi ebaõnnestub, on probleemi lihtsam tuvastada.
HTML-i minimeerimine WP Rocketiga
Enne minimeerimise mõju kontrollimist peame vahemälu tühjendama, muidu ei näe me ajakohastatud HTML-i tulemust.
Kuidas tühjendada brauseri vahemälu?
Seda tüüpi pluginatel on vahemälu tühjendamiseks valikud, mida näeme ülal.
vahemälu tühjendamine WP Rocketiga
Teine viis on brauseri kaudu, kui Google'i arendajatööriistad on lubatud (Ctrl + Shift + I).
Klõpsa parema hiirenupuga "reload page" noolel ja vali "empty cache and hard reload".
vahemälu tühjendamine "Chrome" brauserist
Minimeerimine Autoptimize'iga
Autoptimize'iga teeb minimeerimist optimeerimistoiming, selle eripäraga, et pakutakse valikut HTML-kommentaaride säilitamiseks. Neid kommentaare lisavad tavaliselt arendajad, et säilitada teavet, mis võib tulevikus kasulik olla.
HTML-i minimeerimine Autoptimize'iga
Et kontrollida, kas see optimeerimine on jõustunud, läheksime URL-i lähtekoodi juurde ja peaksime nägema midagi sellist:
minimeeritud HTML-i näide
Kood muutub loetamatuks, kuid selle funktsionaalsus jääb samaks.
Need valikud korduvad WP Rocketis ja Autoptimize'is samamoodi CSS- ja JS-failide jaoks. Nagu varem mainisin, ei soovita ma optimeerida kõike korraga, vaid ükshaaval. Need pluginad hoiavad minimeeritud failide koopiaid, seega on originaali juurde naasmine võimalik, eemaldades märke vastavalt kastikeselt.
Et lehe mahtu edasi vähendada, on meil veel 2 valikut:
›
Eemaldada või vähendada pluginaid, mis lisavad laadimisele CSS-i või JS-i.
›
Eemaldada või kärpida kasutamata koodi CSS-failist.
Need 2 valikut on keerukamad ja nõuavad rohkem teadmisi, kuna tuleb olla ettevaatlik ja veenduda, et teistelt lehtedelt ei tehta väljakutseid osale, mida eemaldad.
Kuigi pluginate eemaldamine pole alati võimalik nende pakutava ressursi tõttu, on pluginaid, mis on paremini optimeeritud kui teised, see tähendab vähem päringuid ja kergem JS. Nii et imelises WordPressi ökosüsteemis on peaaegu alati alternatiiv.
Laadimisaeg vs vastuseaeg
Nüüd on aeg rääkida päringutest, vastuseajast ja laadimisajast. Selles kohas peame mainima protsessi olulist osa – serverit. Serveri optimeerimine ei ole tavaliselt meie kätes, seega on oluline valida tõhus lahendus.
Aga võtame samm-sammult.
Mis on päring?
Päring ehk HTTP Request on väljakutse, mille klient serverile teeb, et küsida teatud ressurssi. Päringud võivad tabada erinevaid servereid.
Päringud võivad olla kas HTTP või HTTPS. Kui vaatame päringu struktuuri, saame analüüsida, kus ajaline viivitus tekib.
HTTP-päringu aja analüüs
HTTP-päringu struktuur
Jagame lahti selle, mida sellel ajadiagrammil näeme.
›
Päring on käivitatud, kuid blokeeritud või järjekorras: kui blokeerimine kestab kaua, võib see olla mitmel põhjusel: kõrgema prioriteediga päringud või palju päringuid sellesse allikasse.
›
DNS Lookup: brauser lahendab (resolve) päringu IP-aadressi.
›
Connecting: aeg, mis kulub serveriga ühenduse loomiseks, et päring lahendada. Kui see aeg on suur, võib see viidata võrguprobleemidele, ühendusvigadele või ülekoormatud serverile.
›
Sending: saadetakse ressursipäring.
›
Waiting: see on aeg, mille server kulutab päringu lahendamiseks ja vastuse saatmiseks; kui see on pikk, on serveris probleem.
›
Receiving: ressursi vastuvõtmine.
HTTPS-päring lisab veel ühe sammu, mis on siin näidatud.
HTTPS-päringu analüüs
Need kaks ekraanipilti kuuluvad kahele erinevale saidile – ühele optimeerimata (HTTP Request) ja teisele optimeeritud (HTTPS Request).
Kui vaatad tähelepanelikult ja võrdled, on suurim erinevus ooteajas. Sellistel juhtudel tuleks serverit üksikasjalikumalt analüüsida.
Serveripäringud: kuidas saame neid vähendada?
Nagu nägime, on päringute arv tihedalt seotud laadimisajaga, seega vähendaks päringute arvu vähendamine URL-i laadimisaegu. Terve mõistus mängib optimeerimisprotsessis rolli, samuti teadmine, kas ressurss on tõesti kasutajale või meie ärile kasulik. See on hetk, mil jätta hüvasti teatud ressurssidega, mis ei lisa midagi, aga mitte mina ei ole see, kes seda otsustab.
Sellegipoolest on meil võimalusi päringute parandamiseks, isegi kui need tegevused ei too saidi laadimisse suurt muutust. Kordan: parim on eemaldada ressursid, mis ei lisa midagi.
CSS-i ja JS-i ühendamine
Veel üks populaarne tegevus veebilehe optimeerimisel on CSS- ja JS-ressursside ühendamine, aga mida see tähendab?
Ühendamise eesmärk on vähendada päringuid faili mahu suurenemise arvelt. Ühendamine tähendab erinevate CSS- või JS-ressursside koondamist üheks.
Kui vastuseajad on pikad, võib ühendamine olla kasulik. Kui saatmisajad on väga aeglased, sobib võib-olla paremini mõni muu tehnika.
Ideaalne on ühendada, omades head serverit, nii võidame mõlemal poolel.
Ressursside ühendamine WP Rocketi ja Autoptimize'iga
Ühendamistoiming nende pluginatega on sama lihtne kui varem. Märgime lihtsalt vastava kastikese.
CSS-i ühendamine WP Rocketiga
WP Rocketis on CSS-i ja JS-i ühendamise valikud samad; paneelid on praktiliselt identsed. Nagu näeme pildil, on kastike, kuhu lisada nende failide tee, mida me ei taha ühendada.
Autoptimize pakub rohkem võimalusi CSS-iga töötamiseks ja päringute vähendamiseks. Valikus, mille ma märgin, ta ühendab ja annab sulle hoiatuse mõju kohta, mis sel võib olla, kuid lõppkokkuvõttes on see alati suhteline.
Selles artikli esimeses osas tahtsin selgitada, mida hõlmavad teatud põhitegevused, need, mida tavaliselt näeme praktiliselt kõigis WPO optimeerimise pluginates, kuid on veel palju, mida saame teha, et parandada nii päringuid kui ka laadimisaegu.
Vahemälu seadistamine
Kahtlemata on vahemälu optimeerimine üks tegevusi, kus märkame saidi laadimises suurimat paranemist. Selles artiklis SEO WordPressi jaoks selgitasin, kuidas vahemälu töötab. Julgustan sind pilku heitma, et mõista, kuidas see toimib.
Autoptimize ja WP Rocket teostavad vahemälu toiminguid, kuid WP Rocket annab paar lisavõimalust. Väärib märkimist, et pluginad on muutnud selle optimeerimise millekski lihtsamaks: sul on vaevu paar valikut ja protsess on kiire ja valutu.
WP Rocketi seadistamine
Nagu näed, võimaldab WP Rocket töötada 4 asjaga:
›
Lubada vahemälu mobiilseadmetele.
›
Salvestada failid eraldi mobiilseadmete jaoks.
›
Lubada vahemälu sisselogitud kasutajatele.
›
Määrata aeg vahemälu tühjendamiseks.
Sõltub igast projektist, milline valik valida, kuid seda kõike arvestades on minu nõuanne:
›
Mobiilne vahemälu alati, sest kuigi enamik saite on kohanduvad (responsive), on sisu, mis võib sul olla mobiilis, kuid mitte lauaarvutis.
›
Failid eraldi.
›
Sisselogitud kasutajatele mingit vahemälu, eelkõige seetõttu, et kui teen muudatusi, ei taha ma vahemälu.
›
Vahemälu aeg, mis sõltub sellest, kui palju muudatusi sa oma saidil teed. Kui tegu on igapäevase uudistesaidiga – lühike; kui sisu, mis ei uuene sageli – pikem.
Lazyload
Lazyload funktsioon aitab kuvada ressursse (pilte ja Iframe'e), kui kasutaja neid vajab; see tähendab, et brauser ei laadi neid ressursse enne, kui kasutaja nendeni kerib (scroll). See funktsioon on rakendatud paljudes pluginates ja on isegi mõnes WordPressi teemas eelseadistatud. Alates "Chrome" versioonist 76 tuleb see isegi brauseris natiivselt kaasa.
See tähendab, et lisades atribuudi loading="lazy", tõlgendab brauser juba pildi hilistatud laadimist, kuid loomulikult ei tõlgenda seda mitte iga brauser, seega soovitan pluginat edasi kasutada. Siin on video lehelt web.dev, mis näitab näidet sellest, mida pildi hilistatud laadimine endast kujutab.
Iframe'ide optimeerimine
Kui kasutame iframe'e, et manustada sisu teistelt saitidelt, on meil kaks tegevust, mida saame kasutada oma laadimise parandamiseks.
›
Hilistatud laadimine lazyload funktsiooni kaudu
›
Või iframe'i asendamine pildiga, kuni kasutaja sellel klõpsab.
Nii esimest kui ka teist valikut saab lubada, taas kord, meie lemmikplugina WP Rocketi kaudu.
JS-failide hilistatud laadimine Deferi või Asynciga
JS-failid on üks süüdlasi selles, mida kiiruse auditid nimetavad lehe renderdamise blokeerimiseks (ingl render blocking). See juhtub siis, kui brauser renderdamise ajal peatub, et JS-fail alla laadida ja seda käivitada. WPO optimeerimise eesmärk on esitada kasutajale teave võimalikult kiiresti, mistõttu peetakse seda blokeerivaks, sest midagi ei renderdata enne, kui allalaaditud JS käivitub.
Seepärast märgitakse seda tüüpi tegevusi auditis tavaliselt ära. Kolmandate osapoolte pluginate või teemade kasutamisel, mis pole hästi optimeeritud, võib meil olla JS, mis blokeerib renderdamist, sest see on näiteks päises (header).
Sellistel juhtudel peaksime kasutama kahte atribuuti, mis lisatakse JS-i väljakutse koodi – Defer ja Async. Et need atribuudid töötaksid, peavad skriptid olema välised.
"SEO Alive" meeskonnas kasutame pluginat Pre Party Resource Hints, mis võimaldab valida, milliseid faile ja millist laadimismeetodit soovid rakendada. Imeline!
Mis vahe on Deferil ja Asyncil?
Kuigi mõlemal atribuudil on sarnane eesmärk – takistada JS-il DOM HTML-i tõlgendamise peatamist – on nende vahel märkimisväärne erinevus.
Async atribuudiga laaditakse ressurss alla HTML-i laadimist peatamata, kuid pärast allalaadimist peatatakse HTML-i laadimine, et JS käivitada; defer-atribuudiga laaditakse ressurss samuti alla paralleelselt HTML-i laadimisega, kuid see käivitub, kui laadimine lõpeb, seega skript blokeerimist ei tekita.
Selles osas on WP Rocketi ja Autoptimize'i vahel erinevused. WP Rocket teeb otsused sinu eest palju lihtsamaks ja tegutseb pooleldi automaatselt, et JS ei blokeeriks renderdamist; Autoptimize'is saad seevastu lülitada vaid Async valikut.
Autoptimize'is, extra vahekaardi all, on meil see valik lisada JS-failid, mida soovime laadida Asynciga, kuid suurema paindlikkuse jaoks soovitatakse teist täiendavat pluginat "Async Javascript".
async laadimine Autoptimize'iga
Selle pluginaga saame töötada nii Deferi kui ka Asynciga, ja see pakub isegi ühe klõpsu valikuid, et asju lihtsamaks teha. Selle plugina hea külg on see, et saame töötada skriptidega ja välja jätta need, mida peame vajalikuks. WP Rocketi puhul peame seevastu usaldama seda, mida plugin teeb, kuigi ta teeb seda hästi.
See valik on samas failide optimeerimise vahekaardis.
defer-atribuut WP Rocketiga
Mis on CDN ja kuidas see saab meid aidata?
CDN on see, mida tuntakse sisuedastusvõrgu nime all (ingl content delivery network). CDN vastutab osa teabe ja ressursside salvestamise eest, et kergendada serveri koormust nende ressursside osas ja koormusele paremini reageerida. CDN-idel on ka geograafilise koopia funktsioon, et hoida ressurss saadaval erinevates punktides ja edastada see kasutajale sõltumata sellest, kust ta ühendust loob. Tavaliselt kasutatakse seda tüüpi teenust raskete failide, näiteks piltide ja videote jaoks.
Selle teenuse tellimine on oluline, kui meil on suure liiklusega saite, kuigi seda ei tohiks välistada ka väikese liiklusega saitide puhul.
Muud tegevused, mis annavad meile veidi rohkem paranemist
Artikli lõpetuseks on meil veel 3 parandust, mis, kuigi need ei too laadimisaegades suuri muutusi, aitavad meil vähendada päringuid, ja lõppkokkuvõttes on just see see, mida me tahame.
Fontide optimeerimine
Fontide optimeerimist saab teha pluginate kaudu või käsitsi, redigeerides ja optimeerides CSS-i. Ideaalne oleks kutsuda välja ainult see font, mida kavatsed kasutada, mitte, nagu juhtub paljudel juhtudel, laadida alla fail kõigi Google Fontsidega.
Autoptimize'il on fontidega töötamiseks valik.
fontide optimeerimine Autoptimize'iga
Raske on öelda, millist valikut valida projekti nägemata, sest ma ei tea, millist fonti su mall kasutab ja millal see laadib, seega parim on testida ja tulemust vaadata.
Nagu näed, on kohe Google Fontsi valikute järel "Remove Emoji", mis säästab meile ühe päringu serverile. Selle funktsioon on lihtsalt teisendada emotikone (emoji) esindavad sümbolid ikooniks.
emotikonid WP Rocketiga
WP Rocket võimaldab meil samuti need emotikonid keelata ja pakub ka valikut takistada sisu manustamist kolmandate osapoolte saitidele.
Lõppkokkuvõttes on saidi laadimiskiiruse parandamiseks palju tegevusi. Alati pole võimalik töötada põhjalikult, et iga ressurssi optimeerida, sest see sõltub ärivaldkonnast ja sellest, mida see vajab.
Loodan, et see WPO optimeerimise juhend on abiks ja et saad seda oma projektides või oma klientide jaoks rakendada.
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.
