Olet optimoinut sisältösi. Sivustollasi on asiantuntemusta, auktoriteettia ja luottamussignaaleja. Mutta kun tekoälyrobotti saapuu sivullesi ja kohtaa aikakatkaisun, eli palvelimesi vastaa 6 sekunnissa tai LCP ei ole piirtynyt valmiiksi 5 sekunnin kuluessa, robotti jatkaa matkaansa. Sisältöäsi ei koskaan indeksoida. Viittauksia ei synny.
Nopeus tappaa näkyvyyden. Ei hitaasti. Vaan heti ja kovaa.
Tekoälyroboteilla on rajoitteita, joita perinteisillä hakukoneilla ei ole. Niillä on tiukat aikakatkaisuikkunat, rajalliset laskentabudjetit ja vähän kärsivällisyyttä. Sivu, joka sijoittuu täydellisesti Googlessa, voi olla täysin näkymätön ChatGPT:lle, Perplexitylle tai Claudelle, koska se ei lataudu robotin määräajassa. Tämä luku käsittelee, miten Core Web Vitals toimivat tekoälylle, mitkä mittarit ovat tärkeimpiä ja mitä muutoksia sinun täytyy tehdä.
Mitä Core Web Vitals mittaavat ja miksi ne ovat olemassa
Core Web Vitals ovat kolme mittaria, jotka Google loi mittaamaan todellista käyttökokemusta. Ne kuvaavat hetken, jolloin selain alkaa näyttää sisältöä, hetken, jolloin käyttäjät voivat olla vuorovaikutuksessa sivun kanssa, ja sen, kuinka vakaana ulkoasu pysyy latauksen aikana. Google pitää niitä sijoitustekijöinä. Mutta tekoälyroboteille ne ovat selviytymistekijöitä.
Kolme mittaria ovat:
Largest Contentful Paint (LCP): Kuinka kauan kestää, ennen kuin suurin visuaalinen elementti latautuu. Tavoite on alle 2,5 sekuntia. Tämän käyttäjät näkevät ensin: jos pääkuvasi, otsikkosi tai pääsisältöosiosi ilmestyy 4 sekunnissa, sekä ihmisten että robottien täytyy odottaa.
Interaction to Next Paint (INP): Kuinka kauan kestää, ennen kuin selain reagoi sen jälkeen, kun käyttäjä klikkaa jotain. Tavoite on alle 200 millisekuntia. Tämä mittari testaa, onko JavaScriptisi paisunutta tai jäätyykö sivusi, kun robotit simuloivat vuorovaikutusta.
Cumulative Layout Shift (CLS): Kuinka paljon sivu pomppii ympäriinsä latautuessaan. Tavoite on alle 0,1. Kun elementit siirtyvät odottamattomasti, robotit poimivat sekavaa tai puutteellista sisältöä. Huolellisesti kirjoitetut kappaleesi muuttuvat sotkuisiksi robotin jäsennyksessä.
Perinteisessä haussa nämä ovat vihjeitä. Tekoälyroboteille ne ovat kovia rajoja.
Miksi tekoälyroboteilla on erilaiset nopeusvaatimukset kuin Googlella
Googlen robotti jakaa työn. Se indeksoi miljoonia URL-osoitteita tuhansilla palvelimilla. Sillä on varaa odottaa 10 sekuntia sivun latautumista, koska odotus jakautuu valtavalle infrastruktuurille.
Tekoälyrobotit toimivat kyselykohtaisella päättelyllä. Kun käyttäjä kysyy ChatGPT:ltä kysymyksen, Perplexityllä on 3-5 sekuntia löytää, noutaa ja jäsentää sisältösi, ennen kuin vastauksen täytyy alkaa muodostua. Jokainen sekunti on tärkeä. Jokainen millisekunti lasketaan indeksointibudjetista.
Tekoälyrobottien käyttäytymistä koskevat tutkimukset osoittavat, että sivustot, joiden First Contentful Paint on alle 0,4 sekuntia, saavat keskimäärin 6,7 viittausta, kun taas yli 1,13 sekunnissa latautuvat sivustot saavat keskimäärin 2,1 viittausta. Tämä ei ole korrelaatiota. Tämä on kausaliteettia. Hitaat sivut ohitetaan.
ChatGPT:n noutorobotilla on dokumentoitu aikakatkaisun raja. Sivut, jotka eivät vastaa tämän ikkunan sisällä, merkitään tavoittamattomiksi ja ne asetetaan alemmas tulevissa indeksointiyrityksissä. Perplexityn robotti tekee samoin. Sivusto, joka vastaa 6 sekunnissa, ei saa toista mahdollisuutta.
Time to First Byte (TTFB): mittari, josta tekoälyrobotit välittävät eniten
TTFB mittaa hetken, joka kuluu pyynnön lähettämisestä ensimmäisen tavun saapumiseen palvelimelta. Se on puhtain palvelimen vasteen mittari.
Tekoälyroboteille TTFB ratkaisee, yrittävätkö ne edes piirtää sivua. Jos palvelimesi vastaa 700 millisekunnissa, robotti on tuhlannut 700 millisekuntia 3-5 sekunnin ikkunastaan. Robotti hylkää piirtämisen kokonaan ja turvautuu pelkkään HTML:n jäsentämiseen, mikä tarkoittaa, että JavaScriptillä piirretty sisältösi muuttuu näkymättömäksi.
Vertailuarvot ovat selvät. TTFB alle 200 millisekuntia on poikkeuksellinen. 200-500 millisekuntia on hyväksyttävä mutta ei ihanteellinen. Yli 600 millisekunnin kohdalla sinulla on palvelininfrastruktuuriongelma.
Useimmat suorituskykyartikkelit pitävät TTFB:tä visuaalisia mittareita vähäisempänä. Tekoälyroboteille se on portinvartija. Jos TTFB epäonnistuu, mikään muu ei ole tärkeää.
Hitaan TTFB:n yleisiä syitä ovat hitaat tietokantakyselyt jokaisen sivulatauksen takana, ylikuormitettu web-hotelli, jossa on liikaa sivustoja palvelinta kohden, pyyntöjen huono maantieteellinen reititys ja sisällönjakeluverkon (CDN) välimuistin puute. Nämä eivät ole suunnitteluongelmia. Nämä ovat infrastruktuuriongelmia.
Largest Contentful Paint (LCP): odottaminen suurta elementtiä
LCP mittaa ajan, kunnes suurin visuaalinen elementti on latautunut kokonaan. Se on yleensä pääkuva, taustakuva tai suuri tekstilohko. Sisältörunsailla sivuilla se on pääsisältöalue.
LCP alle 2,5 sekuntia on ”hyvä” raja. Tekoälyrobotit viittaavat tässä haarukassa oleviin sivuihin 2,8 kertaa useammin kuin sivuihin, joilla on hitaampi LCP. Ero ei ole hienovarainen.
Robotti ei odota, että jokainen elementti on latautunut. Mutta se odottaa, että pääsisältö ilmestyy. Jos pääkuvasi on 4 megatavua etkä ole optimoinut sitä verkkoon, robotti odottaa joutilaana kuvan latautumista. Kun kuva on latautunut, olet jo robotin aikakatkaisun yli.
Hitaan LCP:n yleisiä syitä ovat pakkaamattomat liian suuret kuvat, optimoimattomat videoupotukset, jotka estävät piirtämisen, verkkofontit, joita ei ole rajattu ja jotka eivät lataudu nopeasti, sekä kolmannen osapuolen skriptit, jotka piirtyvät näkyvälle alueelle. Jokainen näistä lisää LCP:hen sekunteja.
Ratkaisu ei ole odottaa pidempään. Ratkaisu on saada LCP tapahtumaan nopeammin. Se tarkoittaa kuvien optimointia, sivun alaosan sisällön laiskaa latausta, asynkronista skriptien latausta ja mahdollisesti raskaiden kolmannen osapuolen upotusten vaihtamista staattisiin HTML-vaihtoehtoihin.
Interaction to Next Paint (INP): JavaScriptin suoritussuorituskyky
INP mittaa vasteaikaa. Kun käyttäjä (tai käyttäjää simuloiva robotti) on vuorovaikutuksessa sivun kanssa, kuinka kauan kestää, ennen kuin jokin muuttuu näytöllä? Tavoite on alle 200 millisekuntia.
Tekoälyroboteille INP paljastaa, onko JavaScriptisi optimoitua vai paisunutta. Huono INP-pistemäärä viittaa siihen, että sivullasi on liikaa koodia pääsäikeessä tai että koodia ei ole jaettu ja lykätty asianmukaisesti.
Robotit, jotka simuloivat vuorovaikutusta, tekevät niin dynaamisen sisällön poimimiseksi. Jos sivusi lataa staattista HTML:ää mutta nojaa JavaScriptiin lomakkeiden, ehdollisen sisällön tai interaktiivisten elementtien piirtämisessä, robotin täytyy suorittaa tuo JavaScript. Jos JavaScript on hidasta, robotti saa huonon INP-pistemäärän ja merkitsee sivusi tehottomaksi.
Asiakaspuolen piirtämisen piilotettu ongelma on, että useimmat tekoälyrobotit eivät piirrä JavaScriptiä lainkaan. Tutkimusten mukaan staattinen HTML schema-merkinnällä saavuttaa 94% jäsennysonnistumisen, kun taas JavaScriptillä piirretty sisältö jää 23%:iin. Tämä tarkoittaa, että jos sisältösi on piilotettu JavaScriptin taakse, tekoälyrobotit eivät välttämättä koskaan näe sitä.
Jos sivustosi käyttää asiakaspuolen piirtämistä, INP-ongelmasta tulee näkyvyysongelma. Robotti ei voi odottaa JavaScriptin suorittamista, joten se ohittaa JavaScriptistä riippuvaisen sisällön.
Cumulative Layout Shift (CLS): vakaus poimimisen aikana
CLS mittaa visuaalista epävakautta. Kun sivun elementit liikkuvat latauksen aikana, Cumulative Layout Shift kasvaa. Tavoite on alle 0,1.
Roboteille CLS ei ole kysymys käyttökokemuksesta. Kyse on jäsennyksen tarkkuudesta. Kun DOM siirtyy robotin poimiessa sisältöä, se voi napata vääriä elementtejä. Otsikko voi siirtyä toisen otsikon tilalle. Sivupalkki voi työntää pääsisällön pois paikaltaan. Robotti poimii sen tekstin, joka on tietyssä kohdassa, ei sitä tekstiä, joka loogisesti kuuluu siihen.
Korkean CLS:n yleisiä syitä ovat mainostilat, jotka latautuvat myöhään ja työntävät sisältöä alas, kuvat ilman määritettyjä mittoja, jotka latautuvat ja siirtävät ulkoasua, verkkofontit, jotka vaihtuvat ja muuttavat välistystä, sekä automaattisesti pyörivät karusellit, jotka siirtävät sisältöä. Jokainen saa ulkoasun liikkumaan.
Ratkaisu on varata tila kaikelle, mikä latautuu. Määritä kuvien mitat HTML:ssä. Määritä font-display arvoon swap, jotta fontit eivät estä piirtämistä. Lataa mainokset ja dynaaminen sisältö varatuissa säiliöissä, jotka eivät aiheuta ulkoasun siirtymiä.
Näin optimoit tekoälyrobottien nopeutta varten
Nopeuden optimointi tekoälyrobotteja varten eroaa nopeuden optimoinnista ihmisille. Käyttäjät välittävät siitä, milloin he näkevät sivun ja milloin voivat olla sen kanssa vuorovaikutuksessa. Robotit välittävät siitä, milloin palvelin vastaa ja valmistuuko kaiken sisällön piirtäminen.
Aloita TTFB:stä. Jos palvelimesi vastaa yli 500 millisekunnissa, mikään muu ei ole tärkeää. Käy läpi tietokantakyselysi, siirry nopeampaan web-hotelliin, ota käyttöön välimuisti sovellustasolla tai käytä CDN:ää. Panostus TTFB:hen maksaa itsensä heti takaisin robottien kattavuudessa.
Optimoi kuvat. Jokainen sivusi kuva pitäisi pakata, muuttaa kokoa näyttömittoihinsa sopivaksi ja tarjota nykyaikaisissa muodoissa, kuten WebP PNG-varamuodoilla. Käytä kuvanoptimointityökalua. Hero-kuvissa käytä CDN:ää, jossa on automaattinen optimointi.
Lykkää ei-kriittistä JavaScriptiä. Lataa vain JavaScript, joka on ehdottoman välttämätöntä, jotta robotti näkee sisällön. Skriptit, jotka seuraavat analytiikkaa, lataavat mainoksia tai pyörittävät interaktiivisia ominaisuuksia, pitäisi lykätä tai ladata asynkronisesti. Näin pääsäie pysyy vapaana ja suoritus nopeana.
Piirrä kriittinen sisältö palvelinpuolella. Jos sivustosi käyttää asiakaspuolen kehystä, piirrä kriittinen polku palvelimella ja täydennä se asiakkaalla. Näin robotit näkevät sisällön heti. Staattinen sivugenerointi (SSG) on vielä parempi: rakenna sivusi HTML:ksi julkaisun yhteydessä.
Vältä isoja kolmannen osapuolen upotuksia. Jos upotat videosoittimia, musiikkisoittimia tai suuria ulkoisia widgettejä, ne estävät piirtämisen. Korvaa ne paikkamerkeillä, jotka latautuvat laiskasti klikattaessa, tai vie olennainen tieto staattiseen HTML:ään.
Varaa tila dynaamiselle sisällölle. Määritä kuville, mainoksille ja dynaamisille osioille selkeät mitat. Se estää ulkoasun siirtymät ja varmistaa, että robotti poimii oikean sisällön.
Käytä CDN:ää. Sisällönjakeluverkko reitittää pyynnöt maantieteellisesti lähimmälle palvelimelle, mikä vähentää viivettä ja TTFB:tä. Useimmat CDN:t tarjoavat myös automaattisen kuvien optimoinnin ja pakkauksen.
Mitä WEMASY sisältää nopeuteen ja robottioptimointiin
WEMASYn Sivustonrakentaja sisältää web-hotellin automaattisella CDN-välimuistilla, kuvien optimoinnin latauksen yhteydessä ja kaiken sivustosisällön palvelinpuolen piirtämisen. WEMASYlla tehdyt sivut täyttävät Core Web Vitals -standardit oletuksena.
Kun julkaiset sivuston WEMASYlla, TTFB optimoidaan CDN:n kautta, kuvasi muutetaan automaattisesti sopivan kokoisiksi ja pakataan, ja HTML tarjoillaan staattisina sivuina, ei tarpeen mukaan generoituna. Tämä tarkoittaa, että tekoälyrobotit näkevät sisältösi heti, ilman odotusta piirtämiseen tai käsittelyyn.
Katso, mitä WEMASY-paketit sisältävät.
Usein kysytyt kysymykset
Vaikuttaako sivun nopeus tekoälyviittauksiin enemmän kuin perinteiseen SEO:hon?
Tekoälyrobotit ovat herkempiä nopeudelle, koska ne toimivat tiukemmilla aikarajoilla. Perinteiset Google-robotit voivat odottaa sivun latautumista 10 sekuntia. Tekoälyrobotit keskeyttävät tyypillisesti 3-5 sekunnin jälkeen. Perinteisessä SEO:ssa nopeus on sijoitussignaali. GEO:ssa nopeus on kynnys. Jos et läpäise sitä, viittauksia ei synny lainkaan. WEMASYn Sivustonrakentajalla voit tehdä tämän suoraan verkkosivustollesi.
Mistä tiedän, onko TTFB riittävän nopea tekoälyroboteille?
Käytä Google PageSpeed Insightsia (aja se ikään kuin se olisi robotti tarkistamalla työpöytäversio). Etsi TTFB alle 500 ms. Jos se on korkeampi, sinun täytyy tutkia web-hotellisi, tietokantasi tai sovelluskoodisi. Myös muut ilmaiset nopeustestityökalut näyttävät TTFB:n. Jos TTFB on jatkuvasti yli 600 ms, ota yhteyttä web-hotellin tarjoajaan tai harkitse siirtymistä nopeampaan.
Pitäisikö Core Web Vitalsia optimoida, vaikka en seuraa perinteisiä Google-sijoituksia?
Kyllä. Core Web Vitals vaikuttavat suoraan tekoälynäkyvyyteen. Tutkimusten mukaan 85% tekoälyalustojen viittaamista sivustoista läpäisee kaikki kolme Core Web Vitals -kynnystä. Vaikka Google-sijoituksilla ei olisi merkitystä liiketoiminnallesi, tekoälynäkyvyydellä on. Optimointi on sama.
Kannattaako siirtyä nopeampaan web-hotelliin pelkästään Core Web Vitalsin takia?
Jos nykyinen TTFB on yli 600 ms, kyllä. Hintaero perus- ja nopean web-hotellin välillä on yleensä $5-15 kuukaudessa. Parantuneiden tekoälyviittausten ja robottikattavuuden tuotto on selvästi suurempi. Nopea web-hotelli parantaa myös käyttökokemusta ja konversioasteita, ei vain indeksoitavuutta.
Parantaako välimuisti Core Web Vitalsia?
Välimuisti on välttämätön. Selaimen välimuisti käskee kävijöiden selaimia tallentamaan kuvat ja staattiset tiedostot paikallisesti, jotta niitä ei tarvitse ladata uudelleen. Palvelimen välimuisti tallentaa täysin piirretyt sivut muistiin, jotta niitä ei tarvitse rakentaa alusta. Molemmat vähentävät TTFB:tä ja LCP:tä merkittävästi. Ota välimuistiotsikot käyttöön rohkeasti ja käytä CDN:ää automaattisella välimuistilla.
Haittaako tekoälyrobottinopeuden optimointi käyttökokemusta?
Ei. Robottinopeuden optimoinnit, kuten nopeammat palvelimet, kuvien pakkaus ja JavaScriptin lykkäys, parantavat käyttökokemusta kaikilla tasoilla. Sivut, jotka latautuvat nopeammin roboteille, latautuvat nopeammin myös ihmisille. Ainoa poikkeus on, jos yrität optimoida pelkästään robotteja varten poistamalla kuvia tai riisumalla sisältöä, mikä haittaisi käyttäjiä. Älä tee niin. Optimoi nopeutta poistamatta arvoa.