Core Web Vitals ja viive: Saavatko nopeammat sivut enemmän tekoälyviittauksia?

Core Web Vitals ja viive: Saavatko nopeammat sivut enemmän tekoälyviittauksia?

Johdanto

Nopea verkkosivusto on ihmisten helpompi käyttää. Se voi myös olla helpompi hakukoneiden ja tekoälyjärjestelmien noutaa, renderöidä ja ymmärtää.

Mutta tärkeä ero jää kuitenkin huomaamatta:

Nopeampi sivu voi parantaa indeksointia ja sisällön saatavuutta. Se ei tarkoita, että pelkkä nopeus saisi tekoälyjärjestelmän viittaamaan sivulle.

2. elokuuta 2026 alkaen Google toteaa, että vakaat palvelimen vasteajat ja lyhyempi viive voivat lisätä sivuston indeksointikapasiteettia. Google toteaa myös, että sen tekoälypohjaiset hakutoiminnot käyttävät samoja perushaku- ja indeksointijärjestelmiä kuin perinteinen haku eivätkä vaadi erityistä tekoälymerkintää tai nopeusoptimointeja. (developers.google.com)

Tämä artikkeli esittelee näyttöön perustuvan testisuunnitelman sen sijaan, että väitettäisiin valmiin kokeen jo suoritettu. Sivustoa, sivustokokonaisuutta, palvelinlokia tai viittausaineistoa ei toimitettu. Tavoitteena on määritellä kontrolloitu tutkimus, joka voi mitata:

1. Lisääkö alhaisempi ensimmäisen tavun aika (time to first byte) indeksointitiheyttä.
2. Parantaako alhaisempi Largest Contentful Paint löydettävyyttä tai indeksointia.
3. Vaikuttaako alhaisempi Cumulative Layout Shift indeksointiin tai tekoälyn noutamiseen.
4. Lisäävätkö suorituskykyparannukset sitä nopeutta, jolla tekoälypohjaiset hakujärjestelmät viittaavat sivuihin näkyvästi.

Lyhyt vastaus

Lyhyempi ensimmäisen tavun aika voi parantaa indeksointia oikeissa olosuhteissa

Googlen nykyinen indeksointidokumentaatio sanoo, että sen indeksointikapasiteetin raja voi kasvaa, kun sivustolla on vakaat tai paranevat vasteajat, mukaan lukien ensimmäisen tavun aika. Jos vasteajat nousevat tai jos sivusto palauttaa liian monta palvelinvirhettä tai nopeusrajoitusvastetta, Google voi vähentää indeksointia. (developers.google.com)

Nopeampi vasteaika ei kuitenkaan takaa enemmän indeksointia. Indeksointitarve riippuu myös seuraavista tekijöistä:

• Kuinka usein sivusto muuttuu.
• Kuinka suosittu sivusto ja sen sivut ovat.
• Onko sisältö hyödyllistä ja ainutlaatuista.
• Kuinka monta päällekkäistä tai vähäarvoista URL-osoitetta on olemassa.
• Onko päivitetyt URL-osoitteet sisällytetty sivukarttoihin.

Tämä tarkoittaa, että lyhyemmällä viiveellä pitäisi olla vahvin vaikutus suuriin, usein päivitettäviin tai palvelinrajoitteisiin verkkosivustoihin, ei välttämättä pieneen sivustoon, jolla on rajoitetusti uutta sisältöä.

Alhaisempi Largest Contentful Paint voi auttaa epäsuorasti

Largest Contentful Paint mittaa, milloin tärkein näkyvä sisältö ilmestyy käyttäjälle. Google toteaa myös, että sekä palvelimen vasteaika että sivujen ja upotettujen resurssien renderöintiin kuluva aika voivat vaikuttaa indeksoinnin tehokkuuteen. (developers.google.com)

Todennäköinen suhde on epäsuora:

Lyhyempi viive → nopeampi resurssien toimitus → tehokkaampi renderöinti tai nouto → vähemmän indeksoinnin aikakatkaisuja tai epätäydellisiä noutoja.

Vaikutus pitäisi olla vahvin, kun tärkeä sisältö riippuu:

• Hitaasta JavaScriptistä.
• Suurista kuvista.
• Renderöintiä estävistä tyylisivuista.
• Asiakaspuolen renderöinnistä.
• Raskaista upotetuista resursseista.

Nopea Largest Contentful Paint -tulos itsessään ei todennäköisesti ole suora tekoälyviittauksen signaali.

Alhaisemmalla Cumulative Layout Shiftillä on luultavasti vähän suoraa indeksointivaikutusta

Cumulative Layout Shift mittaa näkyvän sisällön odottamatonta liikettä. Se on pääasiassa käyttökokemusmittari. Yleisiä syitä ovat kuvat ilman mittoja, dynaamisesti lisätyt mainokset, upotettu sisältö ja verkkofontit. (web.dev)

Indeksointirobotti ei koe asettelun muutosta samalla tavalla kuin ihminen kävijä. Siksi suora suhde alhaisemman Cumulative Layout Shiftin ja lisääntyneen indeksoinnin välillä on epätodennäköinen.

Epäsuora suhde voi olla olemassa, kun suuri asettelun muutos johtuu:

• JavaScriptin myöhään lisäämästä sisällöstä.
• Tärkeästä tekstistä, joka on piilotettu, kunnes skriptit käynnistyvät.
• Kuvista tai upotuksista, jotka viivästyttävät sivun rakentamista.
• Epävakaista malleista, jotka tuottavat erilaista sisältöä eri noutojen aikana.

Näissä tapauksissa todellinen ongelma ei ole asettelun muutoksen pisteet. Todellinen ongelma on, että sivu voi olla vaikea käsitellä tai se voi paljastaa tärkeän sisällön liian myöhään.

Nopeampia sivuja ei automaattisesti viitata useammin

Google sanoo, että tekoälyominaisuuksissa näkyvien sivujen on ensin oltava indeksoituja ja kelvollisia ilmestymään normaaleissa hakutuloksissa katkelman kanssa. Google sanoo myös, ettei sen tekoäly-yleiskatsauksiin ja tekoälytilaan liity ylimääräisiä teknisiä vaatimuksia tai erityisiä tekoälyoptimointeja. (developers.google.com)

OpenAI toteaa vastaavasti, että ChatGPT:n hakusijoitukset riippuvat useista tekijöistä ja että sen hakurobotin, OAI-SearchBotin, salliminen on tärkeää sisällyttämisen kannalta. Se ei totea, että alhaisemmat Core Web Vitals -arvot suoraan lisäävät viittaus todennäköisyyttä. (help.openai.com)

Tämä viittaa nelivaiheiseen malliin:

1. Löytäminen — Saako järjestelmä tietää, että URL-osoite on olemassa?
2. Noutaminen ja käsittely — Voiko järjestelmä noutaa ja ymmärtää sivun?
3. Indeksointi ja nouto — Valitaanko sivu tiettyyn kyselyyn?
4. Viittauksen valinta — Näytetäänkö sivu näkyvänä lähteenä vastauksessa?

Sivun nopeus voi vaikuttaa kahteen ensimmäiseen vaiheeseen. Sitä ei ole vahvistettu neljännen vaiheen suoraksi syyksi.

Tuore tutkimus osoittaa myös, että tekoälyjärjestelmät voivat lukea monia asiaankuuluvia sivuja, mutta viitata vain osaan niistä. Toisin sanoen nouto ja viittaus ovat erillisiä tapahtumia. (cambridge.org)

Mitä tulisi testata?

Tutkimuksen tulisi testata kahta eri kysymystä sen sijaan, että ”tekoälyn näkyvyyttä” käsiteltäisiin yhtenä mittarina.

Kysymys 1: Vaikuttaako suorituskyky indeksointiin?

Ensisijaiset tulokset:

• Aika julkaisusta ensimmäiseen indeksointirobotin pyyntöön.
• Indeksointirobotin pyyntöjen määrä sivua kohti päivässä.
• Aika onnistuneiden uudelleenindeksointien välillä.
• Indeksoitujen sivujen määrä 1 000 julkaistua sivua kohti.
• Onnistuneiden noutojen prosenttiosuus.
• Palvelinvirheiden ja nopeusrajoitusvastauksien määrä.
• Aika julkaisusta indeksointiin.

Kysymys 2: Vaikuttaako suorituskyky viittauksen valintaan?

Ensisijaiset tulokset:

• Testattujen kyselyjen prosenttiosuus, jotka tuottavat näkyvän viittauksen.
• Viittausaste kelvollista sivua kohti.
• Viittauksen osuus kyselyn sisällä.
• Noudettujen sivujen prosenttiosuus, jotka muuttuvat näkyviksi viittauksiksi.
• Viittauksen pysyvyys ajan mittaan.
• Tekoälyjärjestelmän viittausaste.

Nämä tulokset on eroteltava palveluntarjoajan mukaan. Googlen tekoäly-yleiskatsaus, ChatGPT-hakutulos, Microsoft Copilot -vastaus, Perplexity-vastaus ja Claude-hakuvastaus voivat käyttää erilaisia indeksejä, indeksointirobotteja, sijoitusjärjestelmiä ja päivitysaikatauluja.

Koesuunnittelu

1. Rakenna kontrolloitu sivustokokonaisuus

Käytä riittävän suurta sivustokokonaisuutta mielekkäiden indeksointi- ja viittaustietojen tuottamiseksi.

Käytännöllinen aloitusrakenne sisältäisi:

• 240–800 sivua.
• Vähintään 20 sivua sivumallia kohti.
• Kolmesta viiteen sisältökategoriaa.
• Sekoitus aina ajankohtaisia ja säännöllisesti päivitettäviä sivuja.
• Yhtä suuri määrä sivuja kussakin hoitoryhmässä.

Jokaisella sivulla tulisi olla:

• Samankaltainen HTML-rakenne.
• Samankaltainen sisällön pituus.
• Sama julkaisujärjestelmä.
• Sama sisäisen linkityksen malli.
• Samat kanoniset säännöt.
• Sama sivukarttakäsittely.
• Samat robots.txt-oikeudet.
• Ainutlaatuinen, hyödyllinen aihe.

Älä luo satoja ohukaisia tai lähes päällekkäisiä sivuja vain kokeilua varten. Googlen ohjeistus varoittaa, että päällekkäiset ja vähäarvoiset URL-osoitteet voivat tuhlata indeksointiresursseja ja heikentää sivuston tehokkuutta. (developers.google.com)

Parikohtainen suunnittelu on hyödyllinen. Esimerkiksi parita sivuja, joilla on samankaltainen:

• Sisällön pituus.
• Aiheen kysyntä.
• Päivitystiheys.
• Sisäisten linkkien määrä.
• Ulkoisten linkkien määrä.
• Historiallinen liikenne.
• Hakusijoitus.

Aseta sitten yksi sivu kustakin parista kontrolliryhmään ja toinen hoitoryhmään.

2. Käytä faktoriaalista käsittelysuunnittelua

Tärkeimmät suorituskyvyn käsittelyt tulisi testata itsenäisesti ja yhdessä.

Tämä luo kontrolloidun kokeen kolmelle pyydetylle optimoinnille:

• HTTP/3.
• Sisällönjakeluverkon reunamuistiin tallennus.
• Kuvien pakkaus.

Asettelun vakauden käsittely on tarpeen, koska kolme ensimmäistä optimointia eivät luotettavasti eristä Cumulative Layout Shiftiä. Kuvien pakkaus voi alentaa Largest Contentful Paintia muuttamatta asettelun vakautta lainkaan.

Miksi HTTP/3 tarvitsee oman mittauksensa

HTTP/3 käyttää QUIC-siirtoprotokollaa ja tarjoaa itsenäisiä striimejä, jotka voivat välttää HTTP/2:ssa TCP:n yli esiintyvän siirtotason head-of-line-estämisen. Sen edut riippuvat siitä, neuvotteleeko asiakas tai indeksointirobotti todella HTTP/3:n. (rfc-editor.org)

Tämän vuoksi kirjaa jokaisen pyynnön neuvoteltu protokolla:

• HTTP/1.1.
• HTTP/2.
• HTTP/3.

Älä oleta, että HTTP/3:n käyttöönotto tarkoittaa, että jokainen indeksointirobotti käyttää sitä. Jos Googlebot, OAI-SearchBot tai muu indeksointirobotti jatkaa HTTP/2:n käyttöä, HTTP/3 ei voi vaikuttaa kyseisen indeksointirobotin pyyntöihin.

Miksi reunamuistiin tallennus tulisi testata huolellisesti

Sisällönjakeluverkko voi lyhentää ensimmäisen tavun aikaa tarjoamalla sisältöä lähempänä pyytäjää. Se voi myös vähentää alkuperäiselle palvelimelle saapuvien pyyntöjen määrää. (web.dev)

Testaa vähintään kolmea välimuistitilaa:

1. Kylmä välimuisti — Reunapalvelimen on otettava yhteys alkuperäiseen palvelimeen.
2. Lämmin välimuisti — Reunapalvelin tarjoaa sivun ottamatta yhteyttä alkuperäiseen palvelimeen.
3. Uudelleen validoitu välimuisti — Reunapalvelin tai indeksointirobotti käyttää ETag- tai Last-Modified-arvoa ja saa 304 Not Modified -vastauksen.

Google suosittelee erityisesti tehokasta HTTP-välimuistiin tallennusta ja tukee 304 Not Modified -vastausten käyttöä tarpeettoman käsittelyn ja kaistanleveyden vähentämiseksi. (developers.google.com)

Älä anna välimuistin tarjoilla vanhentunutta tai virheellistä sisältöä indeksointiroboteille. Kirjaa:

• Välimuistiosuma tai -ohitus.
• Välimuistin ikä.
• Reunapalvelimen sijainti.
• Alkuperäisen palvelimen vasteaika.
• Sisällön versio.
• Tilakoodi.
• Validointiotsakkeet.

Miksi kuvien pakkaus tulisi sitoa Largest Contentful Paintiin

WebP ja AVIF tarjoavat yleensä paremman pakkauksen kuin vanhemmat kuvamuodot. Pienemmät kuvat voivat lyhentää siirtoaikaa ja parantaa Largest Contentful Paintia, kun kuva on Largest Contentful Paint -elementti. (web.dev)

Testissä tulisi käyttää:

• Samat kuvan mitat.
• Sama visuaalisen laadun tavoite.
• Responsiivisia srcset-kuvia.
• Modernia formaattia sopivalla vararatkaisulla.
• Nimenomaisia width- ja height-arvoja.
• Ei laiskaa latausta Largest Contentful Paint -kuvalle.
• Kuvan URL-osoite, joka näkyy alkuperäisessä HTML:ssä.

Pelkkä kuvien pakkaus ei välttämättä paranna Largest Contentful Paintia, jos todellinen viive johtuu JavaScriptistä tai resurssien myöhäisestä löytymisestä. Googlen suorituskykyohjeistus toteaa, että kuvan latausajan lyhentäminen voi vain siirtää viiveen toiseen osaan sivua, jos Largest Contentful Paint -elementti paljastuu myöhään. (web.dev)

3. Suorita testi riittävän pitkään

Lyhyt testi voi jättää huomiotta indeksointiaikataulutuksen ja indeksin päivityksen vaikutukset.

Käytännöllinen suunnittelu on:

• Kahden viikon perusmittaus.
• Kuudesta kahteentoista viikkoa käsittelyn mittausta.
• Lopullinen peruutus- tai ristiinkytkentäjakso, jos mahdollista.

Ristiinkytkentätestissä vaihda käsittelyjä vastaavien sivuryhmien välillä. Jos suorituskykyvaikutus katoaa, kun käsittely poistetaan, tulos on vahvempi kuin yksinkertainen ennen ja jälkeen -vertailu.

Core Web Vitals -kenttätiedot tulisi arvioida sopivan ajanjakson aikana. Chrome User Experience Report käyttää liukuvaa 28 päivän aggregaatiota, joten sitä ei ole suunniteltu näyttämään välittömiä muutoksia käyttöönoton jälkeen. (developer.chrome.com)

4. Mittaa koko indeksointirobottipopulaatio

Älä käsittele kaikkea automatisoitua liikennettä yhtenä ryhmänä.

Erota vähintään:

Hakurobotit

• Googlebot.
• Bingbot.

Tekoälyhakurobotit

• OAI-SearchBot.
• PerplexityBot.
• Claude-SearchBot.

Käyttäjän pyytämät noutajat

• Perplexity-User.
• Claude-User.
• ChatGPT:n käyttäjä-noutajat, jos tunnistettavissa.

Harjoitusindeksointirobotit

• GPTBot.
• ClaudeBot.
• Google-Extended-hallinta.

Harjoitusindeksointirobotteja ei tulisi käyttää tekoälyhakujen viittausten korvikkeena. Anthropic, OpenAI ja Google erottavat koulutukseen, hakuun tai käyttäjän pyytämään noutoon käytetyt indeksointirobotit toisistaan. Google toteaa myös, että Google-Extended ei vaikuta Google Haun sisällyttämiseen tai sijoitukseen. (help.openai.com)

Perplexity erottaa vastaavasti PerplexityBotin, joka tukee hakuindeksointia, ja Perplexity-Userin, joka voi noutaa sivun käyttäjän pyynnön seurauksena. (docs.perplexity.ai)

Varmista indeksointirobotin identiteetti julkaistujen IP-alueiden tai käänteisen DNS:n avulla, jos palveluntarjoaja sitä tukee. Käyttäjäagenttimerkkijonot voivat olla muiden indeksointirobottien kopioimia. Google varoittaa erityisesti, että Googlebotin käyttäjäagenttimerkkijonoja voidaan väärentää. (developers.google.com)

Kerättävät mittarit

Suorituskykymittarit

Kerää sekä laboratorio- että todellisten käyttäjien dataa:

• Ensimmäisen tavun aika (Time to first byte).
• Ensimmäinen sisältömaalaus (First Contentful Paint).
• Suurin sisältömaalaus (Largest Contentful Paint).
• Kumulatiivinen asettelun muutos (Cumulative Layout Shift).
• Seuraavaan maalaamiseen kuluva aika (Interaction to Next Paint).
• Sivun kokonaispaino.
• Alkuperäisen HTML:n koko.
• Kuvan siirtokoko.
• Pyyntöjen määrä.
• Palvelimen käsittelyyn käytetty aika.
• Suurimman sisältömaalauksen resurssin odottamiseen käytetty aika.
• HTTP-protokolla.
• Välimuistin tila.

Google suosittelee ensimmäisen tavun ajaksi karkeaa tavoitetta, 800 millisekuntia tai vähemmän, mutta ensimmäisen tavun aika ei itsessään ole Core Web Vital. (web.dev)

Nykyiset Core Web Vitals -hyvät kynnykset 75. persentiilissä ovat:

• Largest Contentful Paint: 2,5 sekuntia tai vähemmän.
• Cumulative Layout Shift: 0,1 tai vähemmän.
• Interaction to Next Paint: 200 millisekuntia tai vähemmän. (web.dev)

Indeksointimittarit

Jokaisesta vahvistetusta indeksointirobotin pyynnöstä kirjataan:

text timestamp url user_agent verified_bot source_ip http_protocol status_code response_time time_to_first_byte bytes_sent cache_status edge_location etag last_modified referrer

Laske:

text crawl_requests_per_url_day successful_fetch_rate 5xx_rate 429_rate median_recrawl_interval p75_recrawl_interval publication_to_first_fetch publication_to_first_index

Tekoälyviittausten mittarit

Käytä kiinteää joukkoa kyselyjä kullakin alustalla. Kyselyjoukon tulisi sisältää:

• Suoria faktaan perustuvia kysymyksiä.
• Vertailukysymyksiä.
• ”Paras” tai suosituskysymyksiä.
• Tuoreuteen herkkiä kysymyksiä.
• Kysymyksiä, joissa testattu sivu on vahvin vastaus.
• Kysymyksiä, joissa testattu sivu on relevantti, mutta ei hallitseva.

Kirjaa jokaisesta kyselystä:

text engine model or experience timestamp location device query pages shown as sources page citation order whether the tested page was cited whether the tested page was retrieved but not cited answer text hash

Toista kyselyt, koska tekoälyvastaukset voivat vaihdella. Käytä kiinteää aikataulua, esimerkiksi kolme kertaa viikossa, ja kirjaa muutokset moottorissa tai mallissa.

Microsoft Bing Webmaster Tools tarjoaa nyt tekoälyn suorituskykyraportin, joka näyttää viitatut sivut, peruskyselyt ja viittaustrendit tuetuissa Microsoftin tekoälykokemuksissa. Microsoft varoittaa, että tiedot ovat aggregoituja, otannallisia ja havainnollisia; se ei voi todistaa, että tietty sivumuutos aiheutti viittausmuutoksen. (bing.com)

Google alkoi myös julkaista omia generatiivisen tekoälyn suorituskykyraportteja Search Consolessa kesäkuussa 2026. Raportit olivat aluksi saatavilla vain osalle verkkosivustoista, joten pääsy voi vaihdella. (developers.google.com)

Tilastollinen analyysi

Indeksointitiheys

Käytä sekoitettujen vaikutusten laskentamallia, kuten negatiivista binomimallia:

text crawl_count ~ treatment + time_to_first_byte + page_age + update_frequency + sitemap_status + internal_links + server_errors + (1 | page) + (1 | crawler)

Sivun ja indeksointirobotin vaikutukset ovat tärkeitä, koska jotkut sivut saavat luonnostaan enemmän huomiota kuin toiset, ja eri indeksointiroboteilla on erilaiset aikataulut.

Löytäminen ja indeksointi

Käytä selviytymisanalyysiä seuraaviin:

• Aika julkaisusta ensimmäiseen noutoon.
• Aika julkaisusta ensimmäiseen indeksointiin.
• Aika päivityksestä uudelleenindeksointiin.

Avaintulos ei ole pelkästään se, indeksoitiinko sivu lopulta. Se on se, vähensikö käsittely aikaa, joka tarvittiin sivun löytämiseen ja käsittelyyn.

Tekoälyviittauksen valinta

Käytä hierarkkista logistista mallia:

text citation_present ~ treatment + time_to_first_byte + largest_contentful_paint + cumulative_layout_shift + indexed_status + search_visibility + content_freshness + page_authority + (1 | query) + (1 | engine) + (1 | page)

Suorita kaksi erillistä mallia:

1. Noutomalli — Noudettiinko sivu vai näytettiinkö se ehdokkaana?
2. Viittausmalli — Jos sivu noudettiin, viitattiinko siihen näkyvästi?

Tämä ero on olennainen. Suorituskykyparannus, joka lisää indeksointia mutta ei noutoa, ei ole tekoälyviittausvaikutus. Suorituskykyparannus, joka lisää noutoa mutta ei viittauksia, viittaa siihen, että sivua harkitaan, mutta se häviää lähdevalinnan aikana.

Odotetut tulokset

Nämä ovat työhypoteeseja, eivät väitettyjä kokeellisia tuloksia.

Hypoteesi 1: Ensimmäisen tavun ajalla on selkein indeksointivaikutus

Odota positiivista suhdetta lyhyemmän ensimmäisen tavun ajan ja indeksointikapasiteetin välillä, kun:

• Sivustolla on monia sivuja.
• Sivut muuttuvat usein.
• Alkuperäinen palvelin on hidas tai ylikuormitettu.
• Sivusto palauttaa 5xx tai 429 vastauksia.
• Indeksointirobotti viettää merkittävän osan ajasta odottaen vastauksia.

Odota vähän mitattavissa olevaa vaikutusta pienellä sivustolla, jolla on vähäinen indeksointitarve.

Hypoteesi 2: Largest Contentful Paintilla on merkitystä renderöinnin ja resurssien toimituksen kautta

Odota, että alhaisempi Largest Contentful Paint auttaa, kun:

• Sivu riippuu selaimen renderöinnistä.
• Tärkeä sisältö on JavaScriptin takana.
• Suuret kuvat tai tyylisivut vaaditaan indeksointiin.
• Indeksointirobotti noutaa monia sivun resursseja.
• Hitaampi käsittely tuottaa aikakatkaisuja tai epätäydellisen renderöinnin.

Odota heikkoa suhdetta, kun sivun tärkeä teksti on jo läsnä alkuperäisessä HTML:ssä.

Hypoteesi 3: Cumulative Layout Shiftillä on vähän suoraa vaikutusta

Älä odota merkittävää suoraa suhdetta Cumulative Layout Shiftin ja indeksointitiheyden tai viittausasteen välillä, kun sivun rakenne ja JavaScript-käyttäytyminen on huomioitu.

Jos Cumulative Layout Shift näyttää ennustavan viittauksia, tutki, toimiiko se välittäjänä seuraaville:

• Asiakaspuolen renderöinti.
• Sisällön myöhäinen lisäys.
• Epävakaat mainokset.
• Piilotettu tai viivästynyt teksti.
• Huonosti jäsennelty HTML.

Hypoteesi 4: Pelkkä nopeus ei tuota lisää tekoälyviittauksia

Viittauksen valinnan vahvimmat ennustajat pysyvät todennäköisesti seuraavina:

• Merkityksellisyys kyselyyn.
• Sisällön laatu.
• Selkeät vastaukset.
• Tuoreus.
• Auktoriteetti ja luottamus.
• Hakuindeksin kelpoisuus.
• Noutosijoitus.
• Tukeeko sivu suoraan esitettyä väitettä.

Googlen ohjeistus korostaa hyödyllistä, luotettavaa, ihmislähtöistä sisältöä ja sanoo, että tekoälypohjaiset hakutoiminnot perustuvat olemassa oleviin haku- ja indeksointijärjestelmiin. (developers.google.com)

Tekoälyn hakuun viritetty suorituskykybudjetti

Seuraava on ehdotettu käyttökustannusbudjetti. Se ei ole julkaistu tekoälyn sijoituskaava.

Googlen nykyinen dokumentaatio sanoo, että Googlebot noutaa tuetun tiedoston ensimmäiset 2 megatavua ja noutaa ulkoiset skriptit ja tyylisivut erikseen. Se suosittelee myös tärkeiden metatietojen ja strukturoidun datan sijoittamista aikaisin HTML:ään. (developers.google.com)

Toteutussuositukset

HTTP/3

Käytä HTTP/3:a, kun isännöintipalvelun tarjoaja ja sisällönjakeluverkko tukevat sitä.

Mittaa:

• HTTP/3 neuvottelunopeus.
• HTTP/2 varajärjestelmän nopeus.
• Yhteyden muodostusaika.
• Ensimmäisen tavun aika.
• Suorituskyky maantieteellisen alueen mukaan.
• Suorituskyky indeksointirobotin mukaan.

Älä käsittele HTTP/3:a taattuna haku- tai tekoälyoptimointina. Se on kuljetusparannus, joka voi auttaa vain asiakkaita, jotka sitä käyttävät.

Sisällönjakeluverkon reunamuistiin tallennus

Julkisille, ei-personoiduille sivuille:

• Aseta selkeät Cache-Control-säännöt.
• Käytä pitkäikäistä välimuistiin tallennusta versioituja staattisia resursseja varten.
• Käytä lyhyttä, mutta hyödyllistä välimuistiin tallennusta usein päivitettävälle HTML:lle.
• Vältä välimuistin fragmentoitumista tarpeettomista kyselyparametreista.
• Säilytä kanoniset URL-osoitteet.
• Tukee ETag ja Last-Modified.
• Testaa kylmät, lämpimät ja uudelleen validoidut välimuistitilat.
• Vahvista, että indeksointirobotin pyynnöt saavat saman tärkeän sisällön kuin ihmisten pyynnöt.

Sisällönjakeluverkon tulisi vähentää viivettä luomatta vanhentuneita, epäjohdonmukaisia tai bot-kohtaisia sivuversioita.

Kuvien pakkaus

Kuvien osalta:

• Käytä AVIF- tai WebP-muotoa, kun visuaalinen laatu on hyväksyttävä.
• Tarjoa responsiivisia kuvakokoja.
• Älä tarjoile työpöytäkokoisia kuvia pienille mobiilinäytöille.
• Älä lataa Largest Contentful Paint -kuvaa viivästetysti.
• Sisällytä kuvan mitat.
• Sijoita Largest Contentful Paint -kuva alkuperäiseen HTML:ään.
• Käytä fetchpriority="high" vain tarvittaessa.
• Pidä tärkeät selitykset tekstinä sen sijaan, että upottaisit ne vain kuvien sisään.

Kuvien pakkaus on arvokkainta, kun kuva on Largest Contentful Paint -elementti. Se ei korjaa sivua, jonka pääasiallinen viive johtuu palvelimen renderöinnistä tai JavaScriptin suorituksesta. (web.dev)

Asettelun vakaus

Cumulative Layout Shiftin alentamiseksi:

• Aseta kuvien leveys- ja korkeusattribuutit.
• Varaa tilaa mainoksille.
• Varaa tilaa upotetulle videolle ja sosiaalisisällölle.
• Vältä bannerien lisäämistä olemassa olevan tekstin yläpuolelle.
• Käytä vakaita fonttien latausstrategioita.
• Vältä suurten palvelinrenderöityjen sisältölohkojen korvaamista sivun latauksen jälkeen.

Nämä muutokset parantavat käyttökokemusta, vaikka niillä ei olisi mitattavissa olevaa vaikutusta indeksointiin tai viittauksiin. (web.dev)

Työkalut ja valvonta

Suorituskykytyökalut

Käytä:

• Chrome User Experience Reportia todellisten käyttäjien Core Web Vitals -tietojen saamiseksi.
• Chrome User Experience Reportin sovellusohjelmointirajapintaa automatisoituun kenttätiedon keräämiseen.
• PageSpeed Insightsia laboratorioauditointeihin ja kenttätietoihin.
• Lighthousea toistettaviin laboratoriotesteihin.
• Lighthouse Continuous Integrationia pull-request-suorituskykybudjetteihin.
• WebPageTestiä monipaikkaisten testien, välimuistitilojen ja protokollavertailujen tekemiseen.
• Chrome DevToolsia Largest Contentful Paintin ja asettelun muutosten virheenkorjaukseen.
• web-vitals JavaScript-kirjastoa todellisten käyttäjien seurantaan.

Chrome User Experience Reportin sovellusohjelmointirajapinta tarjoaa sivu- ja alkuperätason aggregoituja kenttätietoja, mukaan lukien Largest Contentful Paint, Cumulative Layout Shift, Interaction to Next Paint ja kokeellinen ensimmäisen tavun aika. (developer.chrome.com)

Lighthouse Continuous Integration voi suorittaa suorituskyky tarkistuksia jokaiselle koodimuutokselle ja epäonnistua käännöksissä, kun budjetit ylittyvät. (github.com)

Indeksointirobottien valvonta

Käytä palvelinlokkeja, reunalokkeja ja pientä joukkoa synteettisiä mittapisteitä.

Esimerkkimittapiste:

bash curl --http3 -sS -o /dev/null -D -
-w 'status=%{http_code}\nhttp_version=%{http_version}\nnamelookup=%{time_namelookup}\nconnect=%{time_connect}\nstarttransfer=%{time_starttransfer}\ntotal=%{time_total}\nsize=%{size_download}\n'
-A 'Mozilla/5.0 (compatible; OAI-SearchBot/1.0)'
https://example.com/page

Suorita sama testi seuraavilla:

• Googlebot.
• Bingbot.
• OAI-SearchBot.
• PerplexityBot.
• Claude-SearchBot.
• Normaali selaimen käyttäjäagentti.

Testin tulisi varmistaa:

• Tilakoodi.
• Robots-lupa.
• Vastausotsakkeet.
• HTML-sisältö.
• HTTP-versio.
• Välimuistin tila.
• Vasteaika.
• Onko tärkeä teksti läsnä ilman JavaScriptiä.

Haku- ja indeksoinnin valvonta

Käytä:

• Google Search Consolen indeksointitilastoja.
• Google Search Consolen sivujen indeksointiraportteja.
• Google Search Consolen URL-tarkistusta.
• Google Search Consolen sivukarttatietoja.
• Google Search Consolen generatiivisen tekoälyn raportteja, kun ne ovat saatavilla.
• Bing Webmaster Toolsin indeksointipyyntöjä ja indeksoituja sivuja.
• Bing Webmaster Toolsin tekoälyn suorituskykyä.
• Päivittäisiä sivukartta- ja lastmod-tarkistuksia.

Search Consolen sovellusohjelmointirajapinta voi noutaa suorituskykytietoja sivun, kyselyn, päivämäärän, laitteen ja hakuilmeen mukaan, sen tietorajoitusten puitteissa. (developers.google.com)

Viittausten valvonta

Luo viittauspaneeli, joka sisältää 50–200 vakaata kyselyä aihetta kohti. Suorita paneeli kiinteällä aikataululla ja kirjaa:

• Hakiko alusta.
• Mitkä lähteet ilmestyivät.
• Viitattiinko testattuun URL-osoitteeseen.
• Viittausjärjestys.
• Vastauspäivämäärä ja -aika.
• Muuttuiko sivu.
• Muuttuiko malli tai hakukokemus.

Älä vertaa eri järjestelmien viittausten määriä ikään kuin ne olisivat vastaavia. Microsoft toteaa, että viittaustoiminta ei ole sijoituspisteet, auktoriteettipisteet, liikennemittari tai laatupisteet. (bing.com)

Hälytyssäännöt

Luo hälytykset seuraaville:

• Ensimmäisen tavun ajan nousu yli 25 prosentilla.
• Largest Contentful Paintin siirtyminen yli 2,5 sekunnin 75. persentiilissä.
• Cumulative Layout Shiftin siirtyminen yli 0,1.
• Jatkuva 5xx tai 429 vastausten kasvu.
• Indeksointirobotin onnistumisasteen lasku.
• Robots.txt-muutos.
• Sivukarttavirhe.
• Indeksoitujen sivujen äkillinen lasku.
• Äkillinen tekoälyviittausten lasku useilla alustoilla.
• Viittausten määrän muutos, joka vaikuttaa vain yhteen alustaan.

Yhtä alustaa koskeva viittausten lasku voi johtua malli-, indeksi-, kysely- tai tuotemuutoksesta pikemminkin kuin sivun suorituskykyongelmasta. Microsoft varoittaa nimenomaisesti, että viittaustrendit ovat havainnollisia ja voivat muuttua sisältöpäivitysten, käyttäjien kysynnän sekä järjestelmä- tai mallimuutosten vuoksi. (bing.com)

Lopullinen johtopäätös

Puolustettavin johtopäätös on:

Nopeammat sivut voivat parantaa indeksoinnin tehokkuutta, erityisesti kun palvelimen viive, resurssien koko, virheet tai renderöintiviiveet ovat rajoittavia tekijöitä. Mutta tällä hetkellä ei ole vahvaa näyttöä siitä, että alhaisemmat Core Web Vitals -arvot suoraan saisivat tekoälyjärjestelmät valitsemaan sivun viittaukseksi.

Odotettu syy-seuraussuhde on:

text Lower latency → better server capacity → fewer failed or delayed fetches → faster discovery and processing → improved chance of being indexed and retrieved → possible increase in citations

Viimeinen vaihe pysyy epävarmana, koska viittauksen valinta riippuu relevanssista, laadusta, tuoreudesta, auktoriteetista, kyselyn tarkoituksesta, noutosijoituksesta ja kunkin tekoälyjärjestelmän käyttäytymisestä.

Useimpien verkkosivustojen kohdalla oikea suorituskykystrategia ei siksi ole ”optimoi tekoälyviittauksia varten” erillään. Se on:

1. Pidä tärkeä sisältö saatavilla alkuperäisessä HTML:ssä.
2. Pidä ensimmäisen tavun aika vakaana.
3. Käytä reunamuistiin tallennusta julkiselle sisällölle.
4. Pakkaa ja priorisoi tärkeät kuvat.
5. Estä asettelun muutokset.
6. Palauta luotettavat tilakoodit.
7. Pidä sivukartat ja sisäiset linkit ajan tasalla.
8. Salli oikeat hakurobotit.
9. Mittaa indeksointi, indeksointi, nouto ja viittaus erillisinä vaiheina.

Tämä lähestymistapa tuottaa nopeamman verkkosivuston ihmisille, terveemmän sivuston hakuroboteille ja testattavan perustan tekoälyn näkyvyyden ymmärtämiselle.