Core Web Vitals és késleltetés: Kapnak-e több mesterséges intelligencia hivatkozást a gyorsabb oldalak?

Core Web Vitals és késleltetés: Kapnak-e több mesterséges intelligencia hivatkozást a gyorsabb oldalak?

Bevezetés

Egy gyors weboldal könnyebben használható az emberek számára. Emellett a keresőmotorok és a mesterséges intelligencia rendszerek számára is könnyebb lehet lekérdezni, megjeleníteni és értelmezni.

Azonban egy fontos különbség gyakran elvész:

Egy gyorsabb oldal javíthatja a feltérképezést és a tartalom elérhetőségét. Ez azonban nem jelenti azt, hogy önmagában a sebesség okozza, hogy egy mesterséges intelligencia rendszer hivatkozzon az oldalra.

2026. augusztus 2-án a Google kijelentette, hogy a stabil szerverválaszidők és az alacsonyabb késleltetés növelhetik egy webhely feltérképezési kapacitását. A Google azt is kijelenti, hogy mesterséges intelligencia alapú keresési funkciói ugyanazokat az alapvető keresési és indexelési rendszereket használják, mint a hagyományos keresés, és nem igényelnek speciális mesterséges intelligencia jelöléseket vagy sebességoptimalizálásokat. (developers.google.com)

Ez a cikk egy bizonyítékokon alapuló tesztelési tervet mutat be, ahelyett, hogy azt állítaná, egy befejezett kísérlet már lezajlott. Nem állt rendelkezésre webhely, oldalkészlet, szerverlog vagy hivatkozási adatkészlet. A cél egy ellenőrzött tanulmány meghatározása, amely mérni tudja:

1. Növeli-e az alacsonyabb első bájtig eltelt idő a feltérképezési gyakoriságot.
2. Javítja-e az alacsonyabb Largest Contentful Paint a felfedezést vagy az indexelést.
3. Befolyásolja-e az alacsonyabb Cumulative Layout Shift a feltérképezést vagy a mesterséges intelligencia általi lekérdezést.
4. Növelik-e a teljesítményjavítások az oldalak mesterséges intelligencia keresőrendszerek általi látható hivatkozásának arányát.

A rövid válasz

Az alacsonyabb első bájtig eltelt idő javíthatja a feltérképezést megfelelő körülmények között

A Google jelenlegi feltérképezési dokumentációja szerint a feltérképezési kapacitás korlátja növelhető, ha egy webhely stabil vagy javuló válaszidőkkel rendelkezik, beleértve az első bájtig eltelt időt is. Ha a válaszidők növekednek, vagy ha egy webhely túl sok szerverhibát vagy sebességkorlát-választ ad vissza, a Google csökkentheti a feltérképezést. (developers.google.com)

Azonban a gyorsabb válaszidő nem garantál több feltérképezést. A feltérképezési igény olyan tényezőktől is függ, mint például:

• Milyen gyakran változik a webhely.
• Mennyire népszerű a webhely és az oldalai.
• Hasznos és egyedi-e a tartalom.
• Hány duplikált vagy alacsony értékű URL létezik.
• A frissített URL-ek szerepelnek-e a webhelytérképekben.

Ez azt jelenti, hogy az alacsonyabb késleltetésnek a legerősebb hatása a nagy, gyakran frissülő vagy szerverkorlátos webhelyeken kell, hogy legyen, nem feltétlenül egy kis, korlátozott új tartalommal rendelkező oldalon.

Az alacsonyabb Largest Contentful Paint közvetetten segíthet

A Largest Contentful Paint azt méri, hogy mikor jelenik meg a fő látható tartalom egy felhasználó számára. A Google azt is kijelenti, hogy mind a szerver válaszideje, mind az oldalak és a beágyazott erőforrások megjelenítéséhez szükséges idő befolyásolhatja a feltérképezés hatékonyságát. (developers.google.com)

A valószínű összefüggés közvetett:

Alacsonyabb késleltetés → gyorsabb erőforrás-szállítás → hatékonyabb megjelenítés vagy lekérés → kevesebb feltérképezési időtúllépés vagy hiányos lekérés.

A hatás a legerősebb lehet, ha a fontos tartalom a következőktől függ:

• Lassú JavaScript.
• Nagyméretű képek.
• Renderelést blokkoló stíluslapok.
• Kliensoldali renderelés.
• Nehéz beágyazott erőforrások.

Egy önmagában gyors Largest Contentful Paint pontszám valószínűleg nem közvetlen mesterséges intelligencia hivatkozási jel.

Az alacsonyabb Cumulative Layout Shift valószínűleg kevés közvetlen feltérképezési hatással jár

A Cumulative Layout Shift a látható tartalom váratlan elmozdulását méri. Ez főként felhasználói élmény metrika. Gyakori okai a méretek nélküli képek, dinamikusan beillesztett hirdetések, beágyazott tartalom és webes betűtípusok. (web.dev)

Egy feltérképező nem tapasztalja a layout shiftet ugyanúgy, mint egy emberi látogató. Ezért az alacsonyabb Cumulative Layout Shift és a több feltérképezés közötti közvetlen kapcsolat valószínűtlen.

Közvetett kapcsolat lehetséges, ha magas layout shiftet okoz:

• JavaScript által későn beszúrt tartalom.
• Fontos szöveg elrejtve a szkriptek futásáig.
• Képek vagy beágyazások, amelyek késleltetik az oldal felépítését.
• Instabil sablonok, amelyek különböző tartalmat hoznak létre különböző lekérések során.

Ezekben az esetekben a valódi probléma nem a layout shift pontszám. A valódi probléma az, hogy az oldal nehezen feldolgozható, vagy túl későn tárja fel a fontos tartalmat.

A gyorsabb oldalak nincsenek automatikusan gyakrabban idézve

A Google szerint a mesterséges intelligencia funkciókban megjelenő oldalaknak először indexelve kell lenniük, és alkalmasnak kell lenniük arra, hogy normál keresési eredményekben snippet-tel jelenjenek meg. A Google azt is kijelenti, hogy nincsenek további technikai követelmények vagy speciális mesterséges intelligencia optimalizálások a mesterséges intelligencia áttekintések és a mesterséges intelligencia mód számára. (developers.google.com)

Az OpenAI hasonlóan kijelenti, hogy a ChatGPT keresési rangsorai több tényezőtől függenek, és a kereső feltérképezőjének, az OAI-SearchBotnak az engedélyezése fontos a bekerüléshez. Nem állítja, hogy az alacsonyabb Core Web Vitals közvetlenül növelné a hivatkozás valószínűségét. (help.openai.com)

Ez egy négyfokozatú modellt sugall:

1. Felfedezés — Tudomást szerez-e a rendszer az URL létezéséről?
2. Lekérés és feldolgozás — Képes-e a rendszer lekérdezni és megérteni az oldalt?
3. Indexelés és lekérdezés — Ki van-e választva az oldal egy adott lekérdezéshez?
4. Hivatkozás kiválasztása — Megjelenik-e az oldal látható forrásként a válaszban?

Az oldal sebessége befolyásolhatja az első két szakaszt. Azonban nem bizonyított, hogy közvetlen oka lenne a negyedik szakasznak.

Újabb kutatások is azt mutatják, hogy a mesterséges intelligencia rendszerek sok releváns oldalt elolvashatnak, de csak némelyikre hivatkoznak. Más szóval, a lekérdezés és a hivatkozás külön események. (cambridge.org)

Mit kell tesztelni?

A tanulmánynak két különböző kérdést kellene tesztelnie, ahelyett, hogy a „mesterséges intelligencia láthatóságot” egyetlen metrikaként kezelné.

1. kérdés: Befolyásolja-e a teljesítmény a feltérképezést?

Elsődleges kimenetek:

• Publikálástól az első feltérképező kérésig eltelt idő.
• Feltérképező kérések száma oldalanként naponta.
• Sikeres újra feltérképezések közötti idő.
• Feltérképezett oldalak száma 1000 publikált oldalra vetítve.
• Sikeres lekérések százalékos aránya.
• Szerverhibák és sebességkorlát-válaszok aránya.
• Publikálástól az indexelésig eltelt idő.

2. kérdés: Befolyásolja-e a teljesítmény a hivatkozás kiválasztását?

Elsődleges kimenetek:

• Tesztelt lekérdezések azon százaléka, amelyek látható hivatkozást eredményeznek.
• Hivatkozási arány jogosult oldalanként.
• Hivatkozási részesedés egy lekérdezésen belül.
• Lekért oldalak azon százaléka, amelyek látható hivatkozásokká válnak.
• Hivatkozás tartóssága az idő múlásával.
• Hivatkozási arány mesterséges intelligencia rendszerenként.

Ezeket az eredményeket szolgáltatónként külön kell választani. Egy Google mesterséges intelligencia áttekintés, ChatGPT keresési eredmény, Microsoft Copilot válasz, Perplexity válasz és Claude keresési válasz eltérő indexeket, feltérképezőket, rangsorolási rendszereket és frissítési ütemezéseket használhat.

Kísérleti tervezés

1. Hozzon létre egy ellenőrzött oldalkészletet

Használjon elegendően nagy oldalkészletet értelmes feltérképezési és hivatkozási adatok előállításához.

Egy praktikus kiindulási terv a következőket foglalná magában:

• 240-800 oldal.
• Legalább 20 oldal sablononként.
• Három-öt tartalomkategória.
• Örökzöld és rendszeresen frissített oldalak keveréke.
• Egyenlő számú oldal minden kezelési csoportban.

Minden oldalnak rendelkeznie kell:

• Hasonló HTML szerkezet.
• Hasonló tartalmi hossz.
• Ugyanaz a publikálási rendszer.
• Ugyanaz a belső linkelési minta.
• Ugyanazok a kanonikus szabályok.
• Ugyanaz a webhelytérkép kezelés.
• Ugyanazok a robots.txt engedélyek.
• Egyedi, hasznos téma.

Ne hozzon létre több száz vékony vagy majdnem duplikált oldalt csak a kísérlethez. A Google útmutatója figyelmeztet, hogy a duplikált és alacsony értékű URL-ek feltérképezési erőforrásokat pazarolhatnak és csökkenthetik egy webhely hatékonyságát. (developers.google.com)

A párosított-páros tervezés hasznos. Például, párosítson hasonló oldalakat:

• Tartalomhossz.
• Téma iránti igény.
• Frissítési gyakoriság.
• Belső linkek száma.
• Külső linkek száma.
• Történelmi forgalom.
• Keresési rangsor pozíciója.

Ezután helyezze az egyik oldalt minden párból a kontrollcsoportba, a másikat pedig egy kezelési csoportba.

2. Használjon faktoriális kezelési tervet

A fő teljesítménykezeléseket függetlenül és együtt kell tesztelni.

Ez egy ellenőrzött kísérletet hoz létre a három kért optimalizáláshoz:

• HTTP/3.
• Tartalomszolgáltató hálózat élmenti gyorsítótárazása.
• Képtömörítés.

Az elrendezés stabilitásának kezelése szükséges, mert az első három optimalizálás nem izolálja megbízhatóan a Cumulative Layout Shiftet. A képtömörítés csökkentheti a Largest Contentful Paint értékét anélkül, hogy az elrendezés stabilitása változna.

Miért van szüksége az HTTP/3-nak saját mérésre?

Az HTTP/3 a QUIC átviteli protokollt használja, és független adatfolyamokat biztosít, amelyek elkerülhetik az HTTP/2-ben TCP felett előforduló szállítási szintű sor eleji blokkolást. Előnyei attól függnek, hogy a kliens vagy a feltérképező ténylegesen HTTP/3-at tárgyal-e. (rfc-editor.org)

Ezért rögzítse a tárgyalt protokollt minden kéréshez:

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

Ne feltételezze, hogy az HTTP/3 engedélyezése azt jelenti, hogy minden feltérképező használja. Ha a Googlebot, az OAI-SearchBot vagy más feltérképező továbbra is HTTP/2-t használ, az HTTP/3 nem befolyásolhatja annak a feltérképezőnek a kéréseit.

Miért kell az élmenti gyorsítótárazást gondosan tesztelni?

Egy tartalomszolgáltató hálózat csökkentheti az első bájtig eltelt időt azáltal, hogy közelebb szolgálja ki a tartalmat a kérőhöz. Csökkentheti az eredeti szerverhez érkező kérések számát is. (web.dev)

Teszteljen legalább három gyorsítótár-állapotot:

1. Hideg gyorsítótár — Az élnek kapcsolatba kell lépnie az eredeti szerverrel.
2. Meleg gyorsítótár — Az él az eredeti szerverrel való kapcsolatfelvétel nélkül szolgálja ki az oldalt.
3. Újra érvényesített gyorsítótár — Az él vagy a feltérképező ETag vagy Last-Modified értéket használ, és 304 Not Modified választ kap.

A Google kifejezetten hatékony HTTP gyorsítótárazást ajánl, és támogatja a 304 Not Modified válaszok használatát a felesleges feldolgozás és sávszélesség csökkentése érdekében. (developers.google.com)

Ne engedje, hogy a gyorsítótárazás elavult vagy helytelen tartalmat szolgáljon ki a feltérképezőknek. Rögzítse:

• Gyorsítótár találat vagy hiány.
• Gyorsítótár kora.
• Élmenti helyszín.
• Eredeti szerver válaszideje.
• Tartalom verziója.
• Állapotkód.
• Érvényesítési fejlécek.

Miért kell a képtömörítést a Largest Contentful Paint-hez kötni?

A WebP és az AVIF általában jobb tömörítést biztosít, mint a régebbi képformátumok. Kisebb képek csökkenthetik az átviteli időt, és javíthatják a Largest Contentful Paint-et, ha a kép a Largest Contentful Paint elem. (web.dev)

A tesztnek a következőket kell használnia:

• Ugyanazok a képdimenziók.
• Ugyanaz a vizuális minőségi cél.
• Reszponzív srcset képek.
• Modern formátum megfelelő visszavonással.
• Explicit width és height értékek.
• Nincs lusta betöltés a Largest Contentful Paint képhez.
• Egy kép URL, amely látható a kezdeti HTML-ben.

A képtömörítés önmagában nem javíthatja a Largest Contentful Paint-et, ha a valódi késleltetés JavaScriptből vagy késői erőforrás-felfedezésből származik. A Google teljesítményre vonatkozó útmutatója megjegyzi, hogy a kép letöltési idejének csökkentése egyszerűen áthelyezheti a késleltetést az oldal egy másik részére, ha a Largest Contentful Paint elem későn derül ki. (web.dev)

3. Futtassa a tesztet elég hosszú ideig

Egy rövid teszt kihagyhatja a feltérképezési ütemezés és az index frissítésének hatásait.

Egy praktikus tervezés a következő:

• Két hét alapszintű mérés.
• Hat-tizenkét hét kezelési mérés.
• Egy végső megfordítási vagy keresztezési időszak, ha lehetséges.

Keresztezési teszt esetén váltsa a kezeléseket a párosított oldalkészletek között. Ha a teljesítményhatás eltűnik a kezelés eltávolításakor, az eredmény erősebb, mint egy egyszerű előtte-utána összehasonlítás.

A Core Web Vitals terepi adatokat megfelelő időtartam alatt kell értékelni. A Chrome felhasználói élmény jelentése (Chrome User Experience Report) gördülő 28 napos aggregációt használ, így nem arra tervezték, hogy azonnali változásokat mutasson egy bevezetés után. (developer.chrome.com)

4. Mérje meg a teljes feltérképező populációt

Ne kezeljen minden automatizált forgalmat egy csoportként.

Legalább különítse el:

Kereső feltérképezők

• Googlebot.
• Bingbot.

Mesterséges intelligencia kereső feltérképezők

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

Felhasználó által kért lekérdezők

• Perplexity-User.
• Claude-User.
• ChatGPT felhasználói lekérdezők, ahol azonosíthatók.

Képző feltérképezők

• GPTBot.
• ClaudeBot.
• Google-Extended vezérlők.

A képző feltérképezőket nem szabad proxyként használni a mesterséges intelligencia keresési hivatkozásokhoz. Az Anthropic, az OpenAI és a Google különbséget tesz a képzésre, keresésre vagy felhasználó által kért lekérdezésre használt feltérképezők között. A Google azt is kijelenti, hogy a Google-Extended nem befolyásolja a Google Keresőbe való felvételt vagy a rangsorolást. (help.openai.com)

A Perplexity hasonlóan különbséget tesz a PerplexityBot, amely támogatja a keresési indexelést, és a Perplexity-User között, amely egy felhasználói kérésre válaszul lekérhet egy oldalt. (docs.perplexity.ai)

Ellenőrizze a feltérképező azonosságát közzétett IP-tartományok vagy fordított DNS segítségével, ahol a szolgáltató támogatja. A felhasználói ügynök sztringeket másolhatják nem kapcsolódó feltérképezők. A Google kifejezetten figyelmeztet, hogy a Googlebot felhasználói ügynök sztringek hamisíthatók. (developers.google.com)

Gyűjtendő metrikák

Teljesítmény metrikák

Gyűjtsön laboratóriumi és valós felhasználói adatokat is:

• Első bájtig eltelt idő.
• First Contentful Paint.
• Largest Contentful Paint.
• Cumulative Layout Shift.
• Interaction to Next Paint.
• Teljes oldalméret.
• Kezdeti HTML méret.
• Képátviteli méret.
• Kérések száma.
• Szerver feldolgozásban töltött idő.
• Largest Contentful Paint erőforrásra való várakozással töltött idő.
• HTTP protokoll.
• Gyorsítótár állapot.

A Google az első bájtig eltelt időre vonatkozóan körülbelül 800 milliszekundumot vagy kevesebbet javasol, de az első bájtig eltelt idő önmagában nem Core Web Vital. (web.dev)

A jelenlegi Core Web Vitals „jó” küszöbértékek a 75. percentilisen a következők:

• Largest Contentful Paint: 2,5 másodperc vagy kevesebb.
• Cumulative Layout Shift: 0,1 vagy kevesebb.
• Interaction to Next Paint: 200 milliszekundum vagy kevesebb. (web.dev)

Feltérképezési metrikák

Minden ellenőrzött feltérképező kéréshez rögzítse:

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

Számítsa ki:

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

Mesterséges intelligencia hivatkozási metrikák

Használjon rögzített lekérdezési készletet minden platformon. A lekérdezési készletnek tartalmaznia kell:

• Közvetlen tényalapú kérdések.
• Összehasonlító kérdések.
• „Legjobb” vagy ajánlási kérdések.
• Frissesség-érzékeny kérdések.
• Olyan kérdések, ahol a tesztelt oldal a legerősebb válasz.
• Olyan kérdések, ahol a tesztelt oldal releváns, de nem domináns.

Minden lekérdezéshez rögzítse:

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

Ismételje meg a lekérdezéseket, mert a mesterséges intelligencia válaszok változhatnak. Használjon rögzített ütemezést, például heti három alkalommal, és rögzítse a motor vagy modell változásait.

A Microsoft Bing Webmaster Tools most már biztosít egy Mesterséges Intelligencia Teljesítmény jelentést, amely megmutatja az idézett oldalakat, az alapozó lekérdezéseket és a hivatkozási trendeket a támogatott Microsoft mesterséges intelligencia élményekben. A Microsoft figyelmeztet, hogy az adatok aggregáltak, mintavételezettek és megfigyelésen alapulnak; nem tudja bizonyítani, hogy egy adott oldalváltozás hivatkozásváltozást okozott. (bing.com)

A Google 2026 júniusában a Search Console-ban dedikált generatív mesterséges intelligencia teljesítményjelentéseket is bevezetett. A jelentések kezdetben csak a webhelyek egy részhalmaza számára voltak elérhetők, így a hozzáférés változhat. (developers.google.com)

Statisztikai elemzés

Feltérképezési gyakoriság

Használjon vegyes hatású számláló modellt, például negatív binomiális modellt:

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

Az oldal- és feltérképező hatások számítanak, mert egyes oldalak természetesen több figyelmet kapnak, mint mások, és a különböző feltérképezők eltérő ütemezéssel rendelkeznek.

Felfedezés és indexelés

Használjon túlélési analízist a következőkhöz:

• Publikálástól az első lekérésig eltelt idő.
• Publikálástól az első indexelésig eltelt idő.
• Frissítéstől az újra feltérképezésig eltelt idő.

A kulcsfontosságú eredmény nem egyszerűen az, hogy egy oldalt végül feltérképeztek-e. Hanem az, hogy a kezelés csökkentette-e az oldal megtalálásához és feldolgozásához szükséges időt.

Mesterséges intelligencia hivatkozás kiválasztása

Használjon hierarchikus logisztikai modellt:

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)

Futtasson két külön modellt:

1. Lekérdezési modell — Az oldalt lekérdezték vagy jelöltként mutatták be?
2. Hivatkozási modell — Ha lekérdezték, láthatóan hivatkoztak-e az oldalra?

Ez a megkülönböztetés alapvető. Egy olyan teljesítményjavulás, amely növeli a feltérképezést, de nem a lekérdezést, nem mesterséges intelligencia hivatkozási hatás. Egy olyan teljesítményjavulás, amely növeli a lekérdezést, de nem a hivatkozásokat, azt sugallja, hogy az oldalt figyelembe veszik, de a forrásválasztás során alulmarad.

Várható eredmények

Ezek munkafeltételezések, nem állított kísérleti eredmények.

1. hipotézis: Az első bájtig eltelt időnek lesz a legvilágosabb feltérképezési hatása

Pozitív összefüggést várjon az alacsonyabb első bájtig eltelt idő és a feltérképezési kapacitás között, ha:

• A webhely sok oldalt tartalmaz.
• Az oldalak gyakran változnak.
• Az eredeti szerver lassú vagy túlterhelt.
• A webhely 5xx vagy 429 válaszokat ad vissza.
• A feltérképező jelentős időt tölt a válaszokra várva.

Kevés mérhető hatásra számítson egy kis webhelyen, alacsony feltérképezési igénnyel.

2. hipotézis: A Largest Contentful Paint a renderelésen és az erőforrás-szállításon keresztül fog számítani

Várhatóan az alacsonyabb Largest Contentful Paint segít, ha:

• Az oldal böngésző renderelésétől függ.
• Fontos tartalom JavaScript mögött van.
• Nagyméretű képek vagy stíluslapok szükségesek az indexeléshez.
• A feltérképező sok oldal erőforrást kér le.
• A lassabb kezelés időtúllépéseket vagy hiányos renderelést eredményez.

Gyenge kapcsolatra számítson, ha az oldal fontos szövege már jelen van a kezdeti HTML-ben.

3. hipotézis: A Cumulative Layout Shiftnek kevés közvetlen hatása lesz

Ne számítson jelentős közvetlen kapcsolatra a Cumulative Layout Shift és a feltérképezési gyakoriság vagy hivatkozási arány között, az oldal szerkezetének és a JavaScript viselkedésének ellenőrzése után.

Ha a Cumulative Layout Shift előre jelzi a hivatkozásokat, vizsgálja meg, hogy proxyként működik-e a következőkre:

• Kliensoldali renderelés.
• Késői tartalombeillesztés.
• Instabil hirdetések.
• Rejtett vagy késleltetett szöveg.
• Rosszul strukturált HTML.

4. hipotézis: Önmagában a sebesség nem fog több mesterséges intelligencia hivatkozást eredményezni

A hivatkozás kiválasztásának legerősebb előrejelzői valószínűleg a következők maradnak:

• Relevancia a lekérdezéshez.
• Tartalom minősége.
• Világos válaszok.
• Frissesség.
• Tekintély és bizalom.
• Keresőindexbe való jogosultság.
• Lekérdezési rangsor.
• Támogatja-e az oldal közvetlenül a felvetett állítást.

A Google útmutatója a hasznos, megbízható, emberközpontú tartalmat hangsúlyozza, és azt állítja, hogy a mesterséges intelligencia keresési funkciók a meglévő keresési és indexelési rendszerekben gyökereznek. (developers.google.com)

Mesterséges intelligencia lekérdezéshez hangolt teljesítményköltségvetés

Az alábbiakban egy javasolt működési költségvetés látható. Ez nem egy publikált mesterséges intelligencia rangsorolási képlet.

A Google jelenlegi dokumentációja szerint a Googlebot egy támogatott fájl első 2 megabájtját kéri le, és külön kéri le a külső szkripteket és stíluslapokat. Azt is javasolja, hogy a fontos metaadatokat és strukturált adatokat korán helyezzék el a HTML-ben. (developers.google.com)

Implementációs javaslatok

HTTP/3

Használjon HTTP/3-at, ha azt a tárhelyszolgáltató és a tartalomszolgáltató hálózat támogatja.

Mérje meg:

• HTTP/3 tárgyalási arány.
• HTTP/2 visszavonási arány.
• Kapcsolatfelépítési idő.
• Első bájtig eltelt idő.
• Teljesítmény földrajzi régiónként.
• Teljesítmény feltérképezőnként.

Ne kezelje az HTTP/3-at garantált keresési vagy mesterséges intelligencia optimalizálásként. Ez egy átviteli javulás, amely csak az azt használó klienseknek segíthet.

Tartalomszolgáltató Hálózat Élmenti Gyorsítótárazása

Nyilvános, nem személyre szabott oldalakhoz:

• Állítson be tiszta Cache-Control szabályokat.
• Használjon hosszú élettartamú gyorsítótárazást verziózott statikus eszközökhöz.
• Használjon rövid, de hasznos gyorsítótárazást gyakran frissülő HTML-hez.
• Kerülje a gyorsítótár fragmentációt a felesleges lekérdezési paraméterekből.
• Őrizze meg a kanonikus URL-eket.
• Támogassa az ETag és Last-Modified mezőket.
• Tesztelje a hideg, meleg és újra érvényesített gyorsítótár-állapotokat.
• Győződjön meg arról, hogy a feltérképező kérések ugyanazt a fontos tartalmat kapják, mint az emberi kérések.

Egy tartalomszolgáltató hálózatnak csökkentenie kell a késleltetést anélkül, hogy elavult, inkonzisztens vagy bot-specifikus oldalverziókat hozna létre.

Képtömörítés

Képekhez:

• Használjon AVIF vagy WebP formátumot, ha a vizuális minőség elfogadható.
• Biztosítson reszponzív képméreteket.
• Ne szolgáljon ki asztali méretű képet kis mobil képernyőre.
• Ne töltsön be lustán (lazy-load) Largest Contentful Paint képet.
• Adja meg a képdimenziókat.
• Helyezze a Largest Contentful Paint képet a kezdeti HTML-be.
• Csak akkor használja a fetchpriority="high"-t, ha megfelelő.
• Tartsa a fontos magyarázatokat szövegben ahelyett, hogy csak képekbe ágyazná azokat.

A képtömörítés a legértékesebb, ha a kép a Largest Contentful Paint elem. Nem fogja kijavítani az olyan oldalt, amelynek fő késleltetése szerver renderelésből vagy JavaScript végrehajtásból származik. (web.dev)

Elrendezés Stabilitása

A Cumulative Layout Shift csökkentéséhez:

• Állítson be szélességi és magassági attribútumokat a képeken.
• Foglaljon le helyet a hirdetéseknek.
• Foglaljon le helyet a beágyazott videó- és közösségi tartalomnak.
• Kerülje a bannerek beszúrását a meglévő szöveg fölé.
• Használjon stabil betűtípus-betöltési stratégiákat.
• Kerülje a szerver által renderelt tartalom nagy blokkjainak cseréjét az oldal betöltése után.

Ezek a változtatások javítják a felhasználói élményt, még akkor is, ha nincs mérhető hatásuk a feltérképezésre vagy a hivatkozásokra. (web.dev)

Eszközök és Felügyelet

Teljesítményeszközök

Használja:

• Chrome felhasználói élmény jelentés (Chrome User Experience Report) a valós felhasználói Core Web Vitals-hoz.
• Chrome felhasználói élmény jelentés alkalmazásprogramozási felület (Chrome User Experience Report application programming interface) az automatizált terepi adatgyűjtéshez.
• PageSpeed Insights laboratóriumi auditokhoz és terepi adatokhoz.
• Lighthouse megismételhető laboratóriumi tesztekhez.
• Lighthouse Continuous Integration a pull-request teljesítményköltségvetésekhez.
• WebPageTest több helyszínes tesztekhez, gyorsítótár-állapotokhoz és protokoll-összehasonlításokhoz.
• Chrome DevTools a Largest Contentful Paint és a layout shift hibakereséséhez.
• A web-vitals JavaScript könyvtár a valós felhasználói monitorozáshoz.

A Chrome felhasználói élmény jelentés alkalmazásprogramozási felület oldal- és forrásszintű aggregált terepi adatokat biztosít, beleértve a Largest Contentful Paint, Cumulative Layout Shift, Interaction to Next Paint, és kísérleti első bájtig eltelt idő értékeket. (developer.chrome.com)

A Lighthouse Continuous Integration teljesítményellenőrzéseket futtathat minden kódváltoztatáson, és leállíthatja a buildeket, ha a költségvetések túllépésre kerülnek. (github.com)

Feltérképező monitorozás

Használjon szerver naplókat, élmenti naplókat és egy kis halmaz szintetikus szondát.

Példa szonda:

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

Futtassa ugyanazt a tesztet a következőkkel:

• Googlebot.
• Bingbot.
• OAI-SearchBot.
• PerplexityBot.
• Claude-SearchBot.
• Normál böngésző felhasználói ügynökkel.

A tesztnek ellenőriznie kell:

• Állapotkód.
• Robots engedély.
• Válasz fejlécek.
• HTML tartalom.
• HTTP verzió.
• Gyorsítótár állapot.
• Válaszidő.
• Jelen van-e fontos szöveg JavaScript nélkül.

Keresési és indexelési monitorozás

Használja:

• Google Search Console feltérképezési statisztikák.
• Google Search Console oldalindexelési jelentések.
• Google Search Console URL ellenőrzés.
• Google Search Console webhelytérkép adatok.
• Google Search Console generatív mesterséges intelligencia jelentések, ha elérhetők.
• Bing Webmaster Tools feltérképezési kérések és indexelt oldalak.
• Bing Webmaster Tools mesterséges intelligencia teljesítmény.
• Napi webhelytérkép és lastmod ellenőrzések.

A Search Console alkalmazásprogramozási felület oldal, lekérdezés, dátum, eszköz és keresési megjelenés szerinti teljesítményadatokat tud lekérni, az adatkorlátai figyelembevételével. (developers.google.com)

Hivatkozás monitorozás

Hozzon létre egy hivatkozási panelt, amely témánként 50-200 stabil lekérdezést tartalmaz. Futtassa a panelt rögzített ütemezés szerint, és rögzítse:

• Kereste-e a platform.
• Mely források jelentek meg.
• Hivatkoztak-e a tesztelt URL-re.
• Hivatkozási sorrend.
• A válasz dátuma és ideje.
• Változott-e az oldal.
• Változott-e a modell vagy a keresési élmény.

Ne hasonlítsa össze a különböző rendszerek hivatkozási számát, mintha azok egyenértékűek lennének. A Microsoft kijelenti, hogy a hivatkozási tevékenység nem rangsorolási pontszám, tekintélyi pontszám, forgalmi mérőszám vagy minőségi pontszám. (bing.com)

Riasztási szabályok

Hozzon létre riasztásokat a következőkhöz:

• Az első bájtig eltelt idő 25 százaléknál nagyobb mértékű növekedésére.
• A Largest Contentful Paint 2,5 másodperc fölé mozdul a 75. percentilisen.
• A Cumulative Layout Shift 0,1 fölé mozdul.
• Tartós növekedés az 5xx vagy 429 válaszokban.
• Csökkenés a feltérképező sikerességi arányában.
• Robots.txt változás.
• Webhelytérkép hiba.
• Hirtelen csökkenés az indexelt oldalak számában.
• Hirtelen csökkenés a mesterséges intelligencia hivatkozásokban több platformon.
• Olyan hivatkozási volumen változás, amely csak egy platformot érint.

Egy platformot érintő hivatkozás csökkenést okozhat modell, index, lekérdezés vagy termékváltozás, nem pedig oldal teljesítményprobléma. A Microsoft kifejezetten figyelmeztet, hogy a hivatkozási trendek megfigyelésen alapulnak, és változhatnak a tartalomfrissítések, a felhasználói igények, valamint a rendszer vagy modell változásai miatt. (bing.com)

Végső következtetés

A legmegalapozottabb következtetés a következő:

A gyorsabb oldalak javíthatják a feltérképezési hatékonyságot, különösen akkor, ha a szerver késleltetése, az erőforrás mérete, a hibák vagy a renderelési késedelmek korlátozó tényezők. Jelenleg azonban nincs erős bizonyíték arra, hogy az alacsonyabb Core Web Vitals közvetlenül okozná, hogy a mesterséges intelligencia rendszerek egy oldalt hivatkozásként válasszanak ki.

A várható ok-okozati lánc a következő:

text Alacsonyabb késleltetés → jobb szerverkapacitás → kevesebb sikertelen vagy késleltetett lekérés → gyorsabb felfedezés és feldolgozás → jobb esély az indexelésre és lekérésre → lehetséges hivatkozások növekedése

Az utolsó lépés továbbra is bizonytalan, mivel a hivatkozás kiválasztása a relevanciától, a minőségtől, a frissességtől, a tekintélytől, a lekérdezés szándékától, a lekérdezési rangsortól és az egyes mesterséges intelligencia rendszerek viselkedésétől függ.

A legtöbb webhely számára a helyes teljesítménystratégia tehát nem az „optimalizálás mesterséges intelligencia hivatkozásokra” elszigetelten. Hanem:

1. Tartsa a fontos tartalmat elérhetővé a kezdeti HTML-ben.
2. Tartsa stabilan az első bájtig eltelt időt.
3. Használjon élmenti gyorsítótárazást nyilvános tartalomhoz.
4. Tömörítse és priorizálja a fontos képeket.
5. Akadályozza meg az elrendezés eltolódásokat.
6. Adjon vissza megbízható állapotkódokat.
7. Tartsa naprakészen a webhelytérképeket és a belső linkeket.
8. Engedélyezze a megfelelő kereső feltérképezőket.
9. Mérje a feltérképezést, indexelést, lekérdezést és hivatkozást külön szakaszokként.

Ez a megközelítés gyorsabb webhelyet eredményez az emberek számára, egészségesebb oldalt a kereső feltérképezők számára, és egy tesztelhető alapot a mesterséges intelligencia láthatóságának megértéséhez.