Core Web Vitals ir vėlavimas: ar greitesni puslapiai gauna daugiau dirbtinio intelekto citatų?

Core Web Vitals ir vėlavimas: ar greitesni puslapiai gauna daugiau dirbtinio intelekto citatų?

Įvadas

Greita svetainė yra patogesnė žmonėms. Ji taip pat gali būti lengviau pasiekiama, atvaizduojama ir suprantama paieškos sistemoms ir dirbtinio intelekto sistemoms.

Tačiau dažnai praleidžiamas svarbus skirtumas:

Greitesnis puslapis gali pagerinti nuskaitymą ir turinio prieinamumą. Tai nereiškia, kad vien greitis priverčia dirbtinio intelekto sistemą cituoti puslapį.

2026 m. rugpjūčio 2 d. duomenimis, „Google“ teigia, kad stabilus serverio atsako laikas ir mažesnis vėlavimas gali padidinti svetainės nuskaitymo pajėgumą. „Google“ taip pat teigia, kad jos dirbtinio intelekto paieškos funkcijos naudoja tas pačias pagrindines paieškos ir indeksavimo sistemas kaip ir tradicinė paieška, ir joms nereikia specialaus dirbtinio intelekto žymėjimo ar greičio optimizavimo. (developers.google.com)

Šiame straipsnyje pristatomas įrodymais pagrįstas testavimo planas, o ne teigiama, kad eksperimentas jau atliktas. Nepateikta jokių svetainių, puslapių rinkinių, serverio žurnalų ar citavimo duomenų rinkinių. Tikslas yra apibrėžti kontroliuojamą tyrimą, kuris gali įvertinti:

1. Ar mažesnis pirmojo baito laikas padidina nuskaitymo dažnumą.
2. Ar mažesnis Didžiausio turinio atvaizdavimas (Largest Contentful Paint) pagerina aptikimą ar indeksavimą.
3. Ar mažesnis Kaupiamasis išdėstymo poslinkis (Cumulative Layout Shift) paveikia nuskaitymą ar dirbtinio intelekto duomenų paiešką.
4. Ar našumo pagerinimas padidina greitį, kuriuo puslapiai yra matomai cituojami dirbtinio intelekto paieškos sistemose.

Trumpas atsakymas

Mažesnis pirmojo baito laikas gali pagerinti nuskaitymą tinkamomis sąlygomis

„Google“ dabartinė nuskaitymo dokumentacija teigia, kad jos nuskaitymo pajėgumo riba gali padidėti, kai svetainė turi stabilų arba gerėjantį atsako laiką, įskaitant pirmojo baito laiką. Jei atsako laikas pailgėja arba jei svetainė grąžina per daug serverio klaidų ar perdidelio užklausų skaičiaus atsakymų, „Google“ gali sumažinti nuskaitymą. (developers.google.com)

Tačiau greitesnis atsako laikas negarantuoja daugiau nuskaitymo. Nuskaitymo paklausa taip pat priklauso nuo tokių veiksnių kaip:

• Kaip dažnai svetainė keičiasi.
• Kiek populiari svetainė ir jos puslapiai.
• Ar turinys yra naudingas ir unikalus.
• Kiek yra pasikartojančių ar mažos vertės URL.
• Ar atnaujinti URL yra įtraukti į svetainės žemėlapius.

Tai reiškia, kad mažesnis vėlavimas turėtų turėti didžiausią poveikį didelėms, dažnai atnaujinamoms ar serverio apribojimų turinčioms svetainėms, o nebūtinai mažai svetainei su ribotu nauju turiniu.

Mažesnis Didžiausio turinio atvaizdavimas (Largest Contentful Paint) gali padėti netiesiogiai

Didžiausio turinio atvaizdavimas (Largest Contentful Paint) matuoja, kada vartotojui pasirodo pagrindinis matomas turinys. „Google“ taip pat teigia, kad tiek serverio atsako laikas, tiek puslapių ir įterptų resursų atvaizdavimo laikas gali paveikti nuskaitymo efektyvumą. (developers.google.com)

Tikėtinas ryšys yra netiesioginis:

Mažesnis vėlavimas → greitesnis resursų pristatymas → efektyvesnis atvaizdavimas ar gavimas → mažiau nuskaitymo laiko viršijimų arba nebaigtų gavimų.

Efektas turėtų būti stipriausias, kai svarbus turinys priklauso nuo:

• Lėto „JavaScript“.
• Didelių vaizdų.
• Atvaizdavimą blokuojančių stilių lentelių.
• Kliento pusės atvaizdavimo.
• Sunkiai įterptų resursų.

Vien greitas Didžiausio turinio atvaizdavimo (Largest Contentful Paint) balas greičiausiai nebus tiesioginis dirbtinio intelekto citavimo signalas.

Mažesnis Kaupiamasis išdėstymo poslinkis (Cumulative Layout Shift) tikriausiai turi mažą tiesioginį nuskaitymo poveikį

Kaupiamasis išdėstymo poslinkis (Cumulative Layout Shift) matuoja netikėtą matomo turinio judėjimą. Tai daugiausia yra vartotojo patirties metrika. Dažnos priežastys yra vaizdai be matmenų, dinamiškai įterpti skelbimai, įterptasis turinys ir internetiniai šriftai. (web.dev)

Nuskaitymo robotas nepatiria išdėstymo poslinkio taip, kaip žmogus lankytojas. Todėl tiesioginis ryšys tarp mažesnio Kaupiamojo išdėstymo poslinkio (Cumulative Layout Shift) ir didesnio nuskaitymo yra mažai tikėtinas.

Netiesioginis ryšys gali egzistuoti, kai didelį išdėstymo poslinkį sukelia:

• Turinio įterpimas vėlai per „JavaScript“.
• Svarbaus teksto paslėpimas, kol neįsijungs scenarijai.
• Vaizdai ar įterptiniai elementai, kurie atidėlioja puslapio konstravimą.
• Nestabilūs šablonai, kurie generuoja skirtingą turinį skirtingų gavimų metu.

Tokiais atvejais tikroji problema yra ne išdėstymo poslinkio balas. Tikroji problema yra ta, kad puslapį gali būti sunku apdoroti arba jis gali per vėlai parodyti svarbų turinį.

Greitesni puslapiai nėra automatiškai cituojami dažniau

„Google“ teigia, kad puslapiai, pasirodantys dirbtinio intelekto funkcijose, pirmiausia turi būti indeksuoti ir tinkami pasirodyti įprastuose paieškos rezultatuose su ištrauka. „Google“ taip pat teigia, kad nėra jokių papildomų techninių reikalavimų ar specialių dirbtinio intelekto optimizavimo priemonių, skirtų jos dirbtinio intelekto apžvalgoms ir dirbtinio intelekto režimui. (developers.google.com)

„OpenAI“ panašiai teigia, kad „ChatGPT“ paieškos reitingavimas priklauso nuo daugelio veiksnių ir kad jos paieškos roboto, OAI-SearchBot, leidimas yra svarbus įtraukimui. Ji neteigia, kad mažesnis Core Web Vitals balas tiesiogiai padidina citavimo tikimybę. (help.openai.com)

Tai rodo keturių etapų modelį:

1. Aptikimas – Ar sistema sužino, kad URL egzistuoja?
2. Gavimas ir apdorojimas – Ar sistema gali gauti ir suprasti puslapį?
3. Indeksavimas ir paieška – Ar puslapis pasirenkamas konkrečiai užklausai?
4. Citatos pasirinkimas – Ar puslapis rodomas kaip matomas šaltinis atsakyme?

Puslapio greitis gali paveikti pirmuosius du etapus. Jis nėra nustatytas kaip tiesioginė ketvirtojo etapo priežastis.

Naujausi tyrimai taip pat rodo, kad dirbtinio intelekto sistemos gali perskaityti daug atitinkamų puslapių, tačiau cituoti tik kai kuriuos iš jų. Kitaip tariant, gavimas ir citavimas yra atskiri įvykiai. (cambridge.org)

Ką reikėtų testuoti?

Tyrimas turėtų tikrinti du skirtingus klausimus, o ne vertinti „dirbtinio intelekto matomumą“ kaip vieną metriką.

1 klausimas: ar našumas veikia nuskaitymą?

Pagrindiniai rezultatai:

• Laikas nuo publikavimo iki pirmosios nuskaitymo roboto užklausos.
• Nuskaitymo roboto užklausų skaičius vienam puslapiui per dieną.
• Laikas tarp sėkmingų pakartotinių nuskaitymų.
• Nuskaitytų puslapių skaičius 1 000 publikuotų puslapių.
• Sėkmingų gavimų procentas.
• Serverio klaidų ir perdidelio užklausų skaičiaus atsakymų dažnis.
• Laikas nuo publikavimo iki indeksavimo.

2 klausimas: ar našumas veikia citatos pasirinkimą?

Pagrindiniai rezultatai:

• Išbandytų užklausų, kurios sukuria matomą citatą, procentas.
• Citavimo dažnis vienam tinkamam puslapiui.
• Citatos dalis užklausoje.
• Gautų puslapių, kurie tampa matomomis citatomis, procentas.
• Citatos išlaikymas laikui bėgant.
• Citavimo dažnis pagal dirbtinio intelekto sistemą.

Šie rezultatai turi būti atskirti pagal teikėją. „Google“ dirbtinio intelekto apžvalga, „ChatGPT“ paieškos rezultatas, „Microsoft Copilot“ atsakymas, „Perplexity“ atsakymas ir „Claude“ paieškos atsakymas gali naudoti skirtingus indeksus, nuskaitymo robotus, reitingavimo sistemas ir atnaujinimo grafikus.

Eksperimentinis dizainas

1. Sukurkite kontroliuojamą puslapių rinkinį

Naudokite pakankamai didelį puslapių rinkinį, kad gautumėte prasmingus nuskaitymo roboto ir citavimo duomenis.

Praktinis pradinio dizaino pavyzdys apimtų:

• 240–800 puslapių.
• Mažiausiai 20 puslapių vienam puslapio šablonui.
• Trys–penkios turinio kategorijos.
• Ilgaamžių ir reguliariai atnaujinamų puslapių mišinys.
• Vienodas puslapių skaičius kiekvienoje gydymo grupėje.

Kiekvienas puslapis turėtų turėti:

• Panašią HTML struktūrą.
• Panašų turinio ilgį.
• Tą pačią publikavimo sistemą.
• Tą patį vidinių nuorodų modelį.
• Tas pačias kanonines taisykles.
• Tą patį svetainės žemėlapio apdorojimą.
• Tas pačias robots.txt teises.
• Unikalią, naudingą temą.

Nekurkite šimtų plonų ar beveik identiškų puslapių tik eksperimentui. „Google“ rekomendacijos perspėja, kad pasikartojantys ir mažos vertės URL gali švaistyti nuskaitymo resursus ir sumažinti svetainės efektyvumą. (developers.google.com)

Naudingas yra suderintų porų dizainas. Pavyzdžiui, suporuokite puslapius su panašiais:

• Turinio ilgiu.
• Temos paklausa.
• Atnaujinimo dažnumu.
• Vidinio nuorodų skaičiumi.
• Išorinių nuorodų skaičiumi.
• Istoriniu srautu.
• Paieškos reitingavimo pozicija.

Tada vieną puslapį iš kiekvienos poros įdėkite į kontrolinę grupę, o kitą – į gydymo grupę.

2. Naudokite faktorinį gydymo dizainą

Pagrindiniai našumo apdorojimo būdai turėtų būti testuojami nepriklausomai ir kartu.

Tai sukuria kontroliuojamą eksperimentą trims prašomoms optimizacijoms:

• HTTP/3.
• Turinio pristatymo tinklo kraštinis talpinimas.
• Vaizdų glaudinimas.

Išdėstymo stabilumo apdorojimas yra būtinas, nes pirmosios trys optimizacijos patikimai neizoliuoja Kaupiamojo išdėstymo poslinkio (Cumulative Layout Shift). Vaizdų glaudinimas gali sumažinti Didžiausio turinio atvaizdavimą (Largest Contentful Paint) visiškai nekeičiant išdėstymo stabilumo.

Kodėl HTTP/3 reikia atskiro matavimo

HTTP/3 naudoja QUIC transporto protokolą ir suteikia nepriklausomus srautus, kurie gali išvengti transporto lygio užblokavimo eilės pradžioje, randamo HTTP/2 per TCP. Jo privalumai priklauso nuo to, ar klientas arba nuskaitymo robotas iš tiesų derasi dėl HTTP/3. (rfc-editor.org)

Todėl kiekvienai užklausai užregistruokite suderintą protokolą:

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

Neprisiimkite, kad HTTP/3 įjungimas reiškia, jog kiekvienas nuskaitymo robotas jį naudoja. Jei „Googlebot“, OAI-SearchBot ar kitas nuskaitymo robotas toliau naudoja HTTP/2, HTTP/3 negali paveikti to nuskaitymo roboto užklausų.

Kodėl kraštinis talpinimas turėtų būti testuojamas atsargiai

Turinio pristatymo tinklas (CDN) gali sumažinti pirmojo baito laiką, pateikdamas turinį arčiau užklausančiojo. Jis taip pat gali sumažinti užklausų skaičių, pasiekiančių pradinį serverį. (web.dev)

Išbandykite bent tris talpyklos būsenas:

1. Šalta talpykla – Kraštinis serveris turi susisiekti su pradiniu serveriu.
2. Šilta talpykla – Kraštinis serveris patiekia puslapį nesusisiekdamas su pradiniu serveriu.
3. Pakartotinai patvirtinta talpykla – Kraštinis serveris arba nuskaitymo robotas naudoja ETag arba Last-Modified reikšmę ir gauna 304 Not Modified atsakymą.

„Google“ specialiai rekomenduoja efektyvų HTTP talpinimą ir palaiko 304 Not Modified atsakymų naudojimą, siekiant sumažinti nereikalingą apdorojimą ir pralaidumą. (developers.google.com)

Neleiskite talpinimui pateikti pasenusio ar neteisingo turinio nuskaitymo robotams. Užregistruokite:

• Talpyklos pataikymas ar praleidimas.
• Talpyklos amžius.
• Kraštinė vieta.
• Pradinio serverio atsako laikas.
• Turinys versija.
• Būsenos kodas.
• Patvirtinimo antraštės.

Kodėl vaizdų glaudinimas turėtų būti susietas su Didžiausio turinio atvaizdavimu (Largest Contentful Paint)

WebP ir AVIF paprastai užtikrina geresnį glaudinimą nei senesni vaizdų formatai. Mažesni vaizdai gali sumažinti perdavimo laiką ir gali pagerinti Didžiausio turinio atvaizdavimą (Largest Contentful Paint), kai vaizdas yra Didžiausio turinio atvaizdavimo elementas. (web.dev)

Teste turėtų būti naudojama:

• Tie patys vaizdų matmenys.
• Tas pats vizualinės kokybės tikslas.
• Reaguojantys srcset vaizdai.
• Šiuolaikinis formatas su tinkamu atsarginiu variantu.
• Aiškios width ir height reikšmės.
• Joks tingus Didžiausio turinio atvaizdavimo vaizdo įkėlimas.
• Vaizdo URL, matomas pradiniame HTML.

Vien vaizdų glaudinimas gali nepagerinti Didžiausio turinio atvaizdavimo (Largest Contentful Paint), jei tikrasis vėlavimas atsiranda dėl „JavaScript“ ar vėlyvo resursų aptikimo. „Google“ našumo gairėse pažymima, kad sumažinus vaizdo atsisiuntimo laiką, vėlavimas gali tiesiog persikelti į kitą puslapio dalį, jei Didžiausio turinio atvaizdavimo elementas atskleidžiamas vėlai. (web.dev)

3. Paleiskite testą pakankamai ilgai

Trumpas testas gali praleisti nuskaitymo planavimo ir indekso atnaujinimo efektus.

Praktinis dizainas yra:

• Dvi savaitės bazinio matavimo.
• Šešios–dvylika savaičių gydymo matavimo.
• Galutinis apvertimo arba kryžminimo laikotarpis, jei įmanoma.

Kryžminiam testui perkelkite gydymo metodus tarp suderintų puslapių grupių. Jei našumo efektas išnyksta pašalinus gydymą, rezultatas yra stipresnis nei paprastas palyginimas „prieš ir po“.

„Core Web Vitals“ lauko duomenys turėtų būti vertinami per tinkamą laikotarpį. „Chrome“ naudotojo patirties ataskaita (Chrome User Experience Report) naudoja 28 dienų apibendrinimą, todėl ji nėra skirta parodyti momentinius pokyčius po diegimo. (developer.chrome.com)

4. Išmatuokite visą nuskaitymo robotų populiaciją

Neapdorokite viso automatizuoto srauto kaip vienos grupės.

Mažiausiai atskirkite:

Paieškos nuskaitymo robotai

• Googlebot.
• Bingbot.

Dirbtinio intelekto paieškos nuskaitymo robotai

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

Vartotojo prašymu atliekantys nuskaitymai

• Perplexity-User.
• Claude-User.
• „ChatGPT“ vartotojo užklausos, jei atpažįstamos.

Mokymo nuskaitymo robotai

• GPTBot.
• ClaudeBot.
• „Google-Extended“ valdikliai.

Mokymo nuskaitymo robotai neturėtų būti naudojami kaip dirbtinio intelekto paieškos citatų tarpininkai. „Anthropic“, „OpenAI“ ir „Google“ skiria nuskaitymo robotus, naudojamus mokymui, paieškai ar vartotojo prašymu atliekamam duomenų gavimui. „Google“ taip pat teigia, kad „Google-Extended“ neturi įtakos „Google“ paieškos įtraukimui ar reitingavimui. (help.openai.com)

„Perplexity“ panašiai skiria „PerplexityBot“, kuris palaiko paieškos indeksavimą, ir „Perplexity-User“, kuris gali gauti puslapį atsakant į vartotojo užklausą. (docs.perplexity.ai)

Patvirtinkite nuskaitymo roboto tapatybę naudodami viešai paskelbtus IP diapazonus arba atvirkštinę DNS, jei teikėjas tai palaiko. „User-agent“ eilutes gali nukopijuoti nesusiję nuskaitymo robotai. „Google“ konkrečiai perspėja, kad „Googlebot“ „user-agent“ eilutės gali būti klastojamos. (developers.google.com)

Renkamos metrikos

Našumo metrikos

Rinkite tiek laboratorinius, tiek realaus vartotojo duomenis:

• Pirmojo baito laikas.
• Pirmojo turinio atvaizdavimas (First Contentful Paint).
• Didžiausio turinio atvaizdavimas (Largest Contentful Paint).
• Kaupiamasis išdėstymo poslinkis (Cumulative Layout Shift).
• Sąveika iki kito atvaizdavimo (Interaction to Next Paint).
• Bendras puslapio svoris.
• Pradinio HTML dydis.
• Vaizdo perdavimo dydis.
• Užklausų skaičius.
• Serverio apdorojimui sugaištas laikas.
• Laukiant didžiausio turinio atvaizdavimo resurso sugaištas laikas.
• HTTP protokolas.
• Talpyklos būsena.

„Google“ rekomenduoja apytikslį pirmojo baito laiko tikslą – 800 milisekundžių ar mažiau, tačiau pirmojo baito laikas pats savaime nėra „Core Web Vital“ rodiklis. (web.dev)

Dabartinės „Core Web Vitals“ „geros“ ribos 75-ajame percentile yra:

• Didžiausio turinio atvaizdavimas (Largest Contentful Paint): 2,5 sekundės ar mažiau.
• Kaupiamasis išdėstymo poslinkis (Cumulative Layout Shift): 0,1 ar mažiau.
• Sąveika iki kito atvaizdavimo (Interaction to Next Paint): 200 milisekundžių ar mažiau. (web.dev)

Nuskaitymo metrikos

Kiekvienai patvirtintai nuskaitymo roboto užklausai įrašykite:

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

Apskaičiuokite:

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

Dirbtinio intelekto citavimo metrikos

Naudokite fiksuotą užklausų rinkinį kiekvienoje platformoje. Užklausų rinkinį turėtų sudaryti:

• Tiesioginiai faktiniai klausimai.
• Palyginimo klausimai.
• „Geriausi“ arba rekomendaciniai klausimai.
• Jautrūs šviežumui klausimai.
• Klausimai, kuriems išbandytas puslapis yra stipriausias atsakymas.
• Klausimai, kuriems išbandytas puslapis yra aktualus, bet ne dominuojantis.

Kiekvienai užklausai įrašykite:

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

Pakartokite užklausas, nes dirbtinio intelekto atsakymai gali skirtis. Naudokite fiksuotą grafiką, pvz., tris kartus per savaitę, ir registruokite variklio ar modelio pokyčius.

„Microsoft Bing Webmaster Tools“ dabar teikia dirbtinio intelekto našumo ataskaitą, rodančią cituojamus puslapius, pagrindines užklausas ir citavimo tendencijas palaikomose „Microsoft“ dirbtinio intelekto patirtyse. „Microsoft“ perspėja, kad duomenys yra apibendrinti, atrinkti ir stebėjimo pobūdžio; jie negali įrodyti, kad konkretus puslapio pakeitimas sukėlė citavimo pokytį. (bing.com)

„Google“ taip pat pradėjo diegti specialias generatyvinio dirbtinio intelekto našumo ataskaitas „Search Console“ 2026 m. birželio mėnesį. Ataskaitos iš pradžių buvo prieinamos tik daliai svetainių, todėl prieiga gali skirtis. (developers.google.com)

Statistinė analizė

Nuskaitymo dažnumas

Naudokite mišrių efektų skaičiavimo modelį, pvz., neigiamą binominį modelį:

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

Puslapio ir nuskaitymo roboto efektai yra svarbūs, nes kai kurie puslapiai natūraliai sulaukia daugiau dėmesio nei kiti, o skirtingi nuskaitymo robotai turi skirtingus grafikus.

Aptikimas ir indeksavimas

Naudokite išgyvenamumo analizę už:

• Laikas nuo publikavimo iki pirmojo gavimo.
• Laikas nuo publikavimo iki pirmojo indeksavimo.
• Laikas nuo atnaujinimo iki pakartotinio nuskaitymo.

Pagrindinis rezultatas yra ne tik tai, ar puslapis galiausiai buvo nuskaitytas. Tai yra, ar apdorojimas sumažino laiką, reikalingą puslapiui rasti ir apdoroti.

Dirbtinio intelekto citatos pasirinkimas

Naudokite hierarchinį logistinį modelį:

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)

Paleiskite du atskirus modelius:

1. Paieškos modelis – Ar puslapis buvo gautas ar parodytas kaip kandidatas?
2. Citatos modelis – Jei gautas, ar puslapis buvo matomai cituotas?

Šis skirtumas yra esminis. Našumo pagerėjimas, kuris padidina nuskaitymą, bet ne paiešką, nėra dirbtinio intelekto citavimo efektas. Našumo pagerėjimas, kuris padidina paiešką, bet ne citavimą, rodo, kad puslapis yra svarstomas, bet pralaimi šaltinio pasirinkimo metu.

Tikėtinos išvados

Tai yra darbinės hipotezės, o ne teigiami eksperimentiniai rezultatai.

1 hipotezė: pirmojo baito laikas turės aiškiausią nuskaitymo efektą

Tikėtinas teigiamas ryšys tarp trumpesnio pirmojo baito laiko ir nuskaitymo pajėgumo, kai:

• Svetainėje yra daug puslapių.
• Puslapiai dažnai keičiasi.
• Pradinis serveris yra lėtas arba perkrautas.
• Svetainė grąžina 5xx arba 429 atsakymus.
• Nuskaitymo robotas daug laiko praleidžia laukdamas atsakymų.

Tikėtinas mažas matomas poveikis mažai svetainei su maža nuskaitymo paklausa.

2 hipotezė: Didžiausias turinio atvaizdavimas (Largest Contentful Paint) bus svarbus per atvaizdavimą ir resursų pristatymą

Tikėtinas mažesnis Didžiausio turinio atvaizdavimas (Largest Contentful Paint), kai:

• Puslapis priklauso nuo naršyklės atvaizdavimo.
• Svarbus turinys yra paslėptas už „JavaScript“.
• Dideli vaizdai ar stilių lentelės yra būtinos indeksavimui.
• Nuskaitymo robotas gauna daug puslapio resursų.
• Lėtesnis apdorojimas sukelia laiko viršijimus arba nepilną atvaizdavimą.

Tikėtinas silpnas ryšys, kai svarbus puslapio tekstas jau yra pradiniame HTML.

3 hipotezė: Kaupiamasis išdėstymo poslinkis (Cumulative Layout Shift) turės mažą tiesioginį poveikį

Nesitikima reikšmingo tiesioginio ryšio tarp Kaupiamojo išdėstymo poslinkio (Cumulative Layout Shift) ir nuskaitymo dažnumo ar citavimo dažnio, kontroliuojant puslapio struktūrą ir „JavaScript“ elgesį.

Jei Kaupiamasis išdėstymo poslinkis (Cumulative Layout Shift) atrodo, kad prognozuoja citatas, ištirkite, ar jis veikia kaip tarpininkas:

• Kliento pusės atvaizdavimui.
• Vėlyvam turinio įterpimui.
• Nestabiliems skelbimams.
• Paslėptam ar atidėliotam tekstui.
• Prastai struktūrizuotam HTML.

4 hipotezė: vien greitis nesukurs daugiau dirbtinio intelekto citatų

Stipriausi citatos pasirinkimo prognozavimo veiksniai greičiausiai išliks:

• Aktualumas užklausai.
• Turinio kokybė.
• Aiškūs atsakymai.
• Šviežumas.
• Autoritetas ir pasitikėjimas.
• Tinkamumas paieškos indeksui.
• Paieškos reitingas.
• Ar puslapis tiesiogiai palaiko pateikiamą teiginį.

„Google“ rekomendacijos pabrėžia naudingą, patikimą, į žmones orientuotą turinį ir teigia, kad dirbtinio intelekto paieškos funkcijos yra pagrįstos esamomis paieškos ir indeksavimo sistemomis. (developers.google.com)

Našumo biudžetas, pritaikytas dirbtinio intelekto paieškai

Žemiau pateikiamas siūlomas veiklos biudžetas. Tai nėra paskelbta dirbtinio intelekto reitingavimo formulė.

„Google“ dabartinė dokumentacija teigia, kad „Googlebot“ nuskaito pirmuosius 2 megabaitus palaikomo failo ir atskirai nuskaito išorinius scenarijus bei stilių lenteles. Ji taip pat rekomenduoja svarbius metaduomenis ir struktūrizuotus duomenis pateikti ankstyvoje HTML dalyje. (developers.google.com)

Įgyvendinimo rekomendacijos

HTTP/3

Naudokite HTTP/3, kai jį palaiko hostingo teikėjas ir turinio pristatymo tinklas.

Išmatuokite:

• HTTP/3 derėjimosi dažnumą.
• HTTP/2 atsarginės parinkties dažnumą.
• Ryšio nustatymo laiką.
• Pirmojo baito laiką.
• Našumą pagal geografinį regioną.
• Našumą pagal nuskaitymo robotą.

Nelaikykite HTTP/3 garantuota paieškos ar dirbtinio intelekto optimizacija. Tai yra transporto patobulinimas, kuris gali padėti tik jį naudojantiems klientams.

Turinio pristatymo tinklo kraštinis talpinimas

Viešiesiems, nepersonalizuotiems puslapiams:

• Nustatykite aiškias Cache-Control taisykles.
• Naudokite ilgalaikį talpinimą versijuotiems statiniams ištekliams.
• Naudokite trumpalaikį, bet naudingą talpinimą dažnai atnaujinamam HTML.
• Venkite talpyklos fragmentacijos dėl nereikalingų užklausos parametrų.
• Išsaugokite kanoninius URL.
• Palaikykite ETag ir Last-Modified.
• Išbandykite šaltos, šiltos ir pakartotinai patvirtintos talpyklos būsenas.
• Patvirtinkite, kad nuskaitymo roboto užklausos gauna tą patį svarbų turinį kaip ir žmogaus užklausos.

Turinio pristatymo tinklas (CDN) turėtų sumažinti vėlavimą, nesukuriant pasenusių, nenuoseklių ar botams skirtų puslapių versijų.

Vaizdų glaudinimas

Vaizdams:

• Naudokite AVIF arba WebP, kai vaizdo kokybė yra priimtina.
• Pateikite reaguojančius vaizdų dydžius.
• Nepateikite darbalaukio dydžio vaizdo mažam mobiliajam ekranui.
• Neįkelkite tingiai Didžiausio turinio atvaizdavimo (Largest Contentful Paint) vaizdo.
• Įtraukite vaizdo matmenis.
• Įdėkite Didžiausio turinio atvaizdavimo (Largest Contentful Paint) vaizdą į pradinį HTML.
• Naudokite fetchpriority="high" tik tada, kai tinka.
• Svarbius paaiškinimus laikykite tekste, o ne įterpkite juos tik į vaizdus.

Vaizdų glaudinimas yra vertingiausias, kai vaizdas yra Didžiausio turinio atvaizdavimo (Largest Contentful Paint) elementas. Jis neištaisys puslapio, kurio pagrindinis vėlavimas atsiranda dėl serverio atvaizdavimo ar „JavaScript“ vykdymo. (web.dev)

Išdėstymo stabilumas

Norėdami sumažinti Kaupiamąjį išdėstymo poslinkį (Cumulative Layout Shift):

• Nustatykite vaizdų plotį ir aukštį (width ir height atributus).
• Rezervuokite vietą skelbimams.
• Rezervuokite vietą įterptiems vaizdo ir socialiniams turiniams.
• Venkite įterpti reklamjuostes virš esamo teksto.
• Naudokite stabilias šriftų įkėlimo strategijas.
• Venkite keisti didelių serverio atvaizduoto turinio blokų po puslapio įkėlimo.

Šie pakeitimai pagerina vartotojo patirtį, net jei jie neturi matomo poveikio nuskaitymui ar citatoms. (web.dev)

Įrankiai ir stebėjimas

Našumo įrankiai

Naudokite:

• Chrome User Experience Report (Chrome naudotojo patirties ataskaita), skirtą realaus vartotojo „Core Web Vitals“.
• Chrome User Experience Report application programming interface (Chrome naudotojo patirties ataskaitos programavimo sąsaja), skirta automatizuotam lauko duomenų rinkimui.
• PageSpeed Insights, skirtą laboratoriniams auditams ir lauko duomenims.
• Lighthouse, skirtą pasikartojantiems laboratoriniams testams.
• Lighthouse Continuous Integration, skirtą „pull-request“ našumo biudžetams.
• WebPageTest, skirtą kelių vietų testams, talpyklos būsenoms ir protokolų palyginimams.
• Chrome DevTools, skirtą Didžiausio turinio atvaizdavimo (Largest Contentful Paint) ir išdėstymo poslinkio derinimui.
• web-vitals JavaScript biblioteką, skirtai realaus vartotojo stebėjimui.

„Chrome User Experience Report“ programavimo sąsaja teikia apibendrintus lauko duomenis puslapių ir šaltinių lygiu, įskaitant Didžiausio turinio atvaizdavimą (Largest Contentful Paint), Kaupiamąjį išdėstymo poslinkį (Cumulative Layout Shift), Sąveiką iki kito atvaizdavimo (Interaction to Next Paint) ir eksperimentinį pirmojo baito laiką. (developer.chrome.com)

„Lighthouse Continuous Integration“ gali vykdyti našumo patikrinimus kiekvienam kodo pakeitimui ir nutraukti kūrimą, kai viršijami biudžetai. (github.com)

Nuskaitymo roboto stebėjimas

Naudokite serverio žurnalus, kraštinius žurnalus ir nedidelį sintetinio tyrimo zondų rinkinį.

Pavyzdys zondo:

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

Vykdykite tą patį testą su:

• Googlebot.
• Bingbot.
• OAI-SearchBot.
• PerplexityBot.
• Claude-SearchBot.
• Normaliu naršyklės „user-agent“.

Testas turėtų patikrinti:

• Būsenos kodą.
• Robots leidimą.
• Atsakymo antraštes.
• HTML turinį.
• HTTP versiją.
• Talpyklos būseną.
• Atsako laiką.
• Ar svarbus tekstas yra be „JavaScript“.

Paieškos ir indeksavimo stebėjimas

Naudokite:

• „Google Search Console“ nuskaitymo statistiką.
• „Google Search Console“ puslapių indeksavimo ataskaitas.
• „Google Search Console“ URL tikrinimą.
• „Google Search Console“ svetainės žemėlapio duomenis.
• „Google Search Console“ generatyvinio dirbtinio intelekto ataskaitas (kai prieinamos).
• „Bing Webmaster Tools“ nuskaitymo užklausas ir indeksuotus puslapius.
• „Bing Webmaster Tools“ dirbtinio intelekto našumo ataskaitą.
• Kasdienius svetainės žemėlapio ir lastmod patikrinimus.

„Search Console“ programavimo sąsaja gali gauti našumo duomenis pagal puslapį, užklausą, datą, įrenginį ir paieškos išvaizdą, atsižvelgiant į jos duomenų apribojimus. (developers.google.com)

Citavimo stebėjimas

Sukurkite citavimo panelį, kuriame būtų 50–200 stabilių užklausų kiekvienai temai. Paleiskite panelį pagal fiksuotą grafiką ir įrašykite:

• Ar platforma ieškojo.
• Kokie šaltiniai pasirodė.
• Ar buvo cituojamas išbandytas URL.
• Citavimo tvarką.
• Atsakymo datą ir laiką.
• Ar puslapis pasikeitė.
• Ar pasikeitė modelis ar paieškos patirtis.

Nelyginkite skirtingų sistemų citavimo skaičių taip, tarsi jie būtų lygiaverčiai. „Microsoft“ teigia, kad citavimo veikla nėra reitingavimo balas, autoriteto balas, srauto matas ar kokybės balas. (bing.com)

Įspėjimo taisyklės

Sukurkite įspėjimus, skirtus:

• Pirmojo baito laikui, padidėjusiam daugiau nei 25 procentais.
• Didžiausio turinio atvaizdavimui (Largest Contentful Paint), viršijančiam 2,5 sekundės 75-ame percentile.
• Kaupiamajam išdėstymo poslinkiui (Cumulative Layout Shift), viršijančiam 0,1.
• Nuolatiniam 5xx arba 429 atsakymų padidėjimui.
• Nuskaitymo roboto sėkmės rodiklio sumažėjimui.
• robots.txt pakeitimui.
• Svetainės žemėlapio klaidai.
• Staigiam indeksuotų puslapių kritimui.
• Staigiam dirbtinio intelekto citatų kritimui keliose platformose.
• Citavimo apimties pokyčiui, kuris paveikia tik vieną platformą.

Citavimo sumažėjimą, paveikiantį vieną platformą, gali sukelti modelio, indekso, užklausos ar produkto pakeitimas, o ne puslapio našumo problema. „Microsoft“ aiškiai perspėja, kad citavimo tendencijos yra stebimos ir gali keistis dėl turinio atnaujinimų, vartotojų paklausos ir sistemos ar modelio pokyčių. (bing.com)

Galutinė išvada

Labiausiai pagrįsta išvada yra:

Greitesni puslapiai gali pagerinti nuskaitymo efektyvumą, ypač kai serverio vėlavimas, resursų dydis, klaidos ar atvaizdavimo vėlavimai yra ribojantys veiksniai. Tačiau šiuo metu nėra tvirtų įrodymų, kad mažesnis „Core Web Vitals“ balas tiesiogiai verčia dirbtinio intelekto sistemas pasirinkti puslapį kaip citatą.

Tikėtina priežasties grandinė yra:

Mažesnis vėlavimas → geresnis serverio pajėgumas → mažiau nepavykusių ar atidėtų gavimų → greitesnis aptikimas ir apdorojimas → padidėjusi tikimybė būti indeksuotam ir gautam → galimas citatų padidėjimas

Paskutinis žingsnis išlieka neaiškus, nes citatos pasirinkimas priklauso nuo aktualumo, kokybės, šviežumo, autoriteto, užklausos ketinimo, paieškos reitingo ir kiekvienos dirbtinio intelekto sistemos elgesio.

Daugumai svetainių teisinga našumo strategija todėl nėra „optimizuoti dirbtinio intelekto citatoms“ atskirai. Ji yra:

1. Svarbų turinį laikyti prieinamą pradiniame HTML.
2. Palaikyti stabilų pirmojo baito laiką.
3. Naudoti kraštinį talpinimą viešajam turiniui.
4. Glaudinti ir teikti pirmenybę svarbiems vaizdams.
5. Užkirsti kelią išdėstymo poslinkiams.
6. Grąžinti patikimus būsenos kodus.
7. Nuolat atnaujinti svetainės žemėlapius ir vidines nuorodas.
8. Leisti teisingiems paieškos nuskaitymo robotams.
9. Nuskaitymą, indeksavimą, paiešką ir citavimą matuoti kaip atskirus etapus.

Toks požiūris sukuria greitesnę svetainę žmonėms, sveikesnę svetainę paieškos nuskaitymo robotams ir testuojamą pagrindą dirbtinio intelekto matomumui suprasti.