Optimalizáltad a tartalmadat. Az oldalad szakértelmet, tekintélyt és bizalmi jeleket mutat. De amikor egy AI-crawler eléri az oldaladat, és időtúllépéssel találkozik, mert a szervered 6 másodperc alatt válaszol, vagy az LCP 5 másodpercig nem fejeződik be, a crawler továbbmegy. A tartalmad soha nem kerül indexelésre. A hivatkozásaid soha nem történnek meg.
A sebesség öli a láthatóságot. Nem lassan. Azonnal, kemény megállással.
Az AI-crawlerek olyan korlátok között dolgoznak, amelyek a hagyományos keresőkre nem érvényesek. Szigorú időkorlátjuk, korlátozott számítási keretük és kevés türelmük van. Az az oldal, amely tökéletesen rangsorol a Google-ben, teljesen láthatatlan lehet a ChatGPT, a Perplexity vagy a Claude számára, mert nem tölt be a crawler határidején belül. Ez a fejezet bemutatja, hogyan működnek a Core Web Vitals az AI számára, mely mutatók számítanak a legtöbbet, és milyen változtatásokra van szükséged.
Mit mérnek a Core Web Vitals, és miért léteznek
A Core Web Vitals három mutató, amelyet a Google a valódi felhasználói élmény mérésére hozott létre. Azt rögzítik, mikor kezd a böngésző tartalmat mutatni, mikor tudnak a felhasználók interakcióba lépni az oldallal, és mennyire marad stabil az elrendezés betöltés közben. A Google rangsorolási tényezőként kezeli őket. De az AI-crawlereknek túlélési tényezők.
A három mutató:
Largest Contentful Paint (LCP): mennyi idő múlva tölt be a legnagyobb vizuális elem. A cél 2,5 másodperc alatt van. Ezt látják a felhasználók először: ha a nyitóképed, a címsorod vagy a fő tartalmi szakaszod 4 másodperc alatt jelenik meg, az emberek és a crawlerek is várni kényszerülnek.
Interaction to Next Paint (INP): mennyi idő telik el, amíg a böngésző válaszol, miután a felhasználó rákattint valamire. A cél 200 ezredmásodperc alatt van. Ez a mutató azt teszteli, hogy a JavaScript-ed felfújt-e, vagy lefagy-e az oldalad, amikor a crawlerek interakciót szimulálnak.
Cumulative Layout Shift (CLS): mennyire ugrál az oldal betöltés közben. A cél 0,1 alatt van. Ha az elemek váratlanul elmozdulnak, a crawlerek összekevert vagy hiányos tartalmat nyernek ki. A gondosan megírt bekezdéseid összekuszálódnak a crawler feldolgozásában.
A hagyományos keresésnél ezek útmutatások. Az AI-crawlereknél kemény korlátok.
Miért más a sebességi követelmény az AI-crawlereknél, mint a Google-nél
A Google crawlere elosztja a munkát. Milliónyi URL-t jár be több ezer szerveren. Megengedheti magának, hogy 10 másodpercet várjon egy oldal betöltésére, mert a várakozás egy óriási infrastruktúrán oszlik el.
Az AI-crawlerek lekérdezésenkénti következtetéssel dolgoznak. Amikor egy felhasználó kérdez a ChatGPT-től, a Perplexitynek 3-5 másodperce van az oldalad megtalálására, lekérésére és feldolgozására, mielőtt a válaszgenerálásnak el kell kezdődnie. Minden másodperc számít. Minden ezredmásodperc a bejárási keret terhére esik.
Az AI-crawlerek viselkedését vizsgáló tanulmányok szerint azok az oldalak, amelyek First Contentful Paint értéke 0,4 másodperc alatt van, átlagosan 6,7 hivatkozást kapnak, míg az 1,13 másodpercnél lassabban betöltők átlagosan 2,1-et. Ez nem korreláció. Ez ok-okozat. A lassú oldalakat kihagyják.
A ChatGPT lekérő crawlerének dokumentált időkorlát-küszöbe van. Azokat az oldalakat, amelyek nem válaszolnak ezen az ablakon belül, elérhetetlennek jelölik, és a későbbi bejárási kísérleteknél hátrébb sorolják. A Perplexity botja ugyanezt teszi. Az az oldal, amely 6 másodperc alatt válaszol, nem kap második esélyt.
Time to First Byte (TTFB): az a mutató, amely a legjobban érdekli az AI-crawlereket
A TTFB a kérés elküldése és az első bájt szervertől való megérkezése közötti időt méri. Ez a szerver válaszkészségének legtisztább mértéke.
Az AI-crawlereknél a TTFB dönti el, hogy egyáltalán megkísérlik-e a renderelést. Ha a szervered 700 ezredmásodperc alatt válaszol, a crawler elpazarolt 700 ezredmásodpercet a 3-5 másodperces ablakából. A crawler teljesen felhagy a rendereléssel, és csak a HTML-t dolgozza fel, ami azt jelenti, hogy a JavaScripttel renderelt tartalmad láthatatlanná válik.
A viszonyítási értékek egyértelműek. A 200 ezredmásodperc alatti TTFB kivételesnek számít. A 200-500 ezredmásodperc elfogadható, de nem ideális. 600 ezredmásodperc felett szerverinfrastruktúra-problémád van.
A legtöbb teljesítménycikk a TTFB-t a vizuális mutatók mögé sorolja. Az AI-crawlereknél ez a kapuőr. Ha a TTFB megbukik, semmi más nem számít.
A lassú TTFB gyakori okai: lassú adatbázis-lekérdezések minden oldalbetöltés mögött, túlterhelt tárhely, szerverenként túl sok oldallal, a kérések rossz földrajzi irányítása, és a tartalomkézbesítő hálózat (CDN) gyorsítótárazásának hiánya. Ezek nem tervezési problémák. Ezek infrastruktúra-problémák.
Largest Contentful Paint (LCP): várakozás a nagy elemre
Az LCP azt az időt méri, amíg a legnagyobb vizuális elem teljesen betölt. Ez általában nyitókép, háttérkép vagy nagy szövegblokk. A tartalomgazdag oldalaknál a fő tartalmi terület.
A 2,5 másodperc alatti LCP a „jó” küszöb. Az AI-crawlerek ebben a tartományban 2,8-szor gyakrabban idézik az oldalakat, mint a lassabb LCP-jűeket. A különbség nem csekély.
A crawler nem vár meg minden elemet. De megvárja, hogy a fő tartalom megjelenjen. Ha a nyitóképed 4 megabájtos, és nem optimalizáltad a webre, a crawler tétlenül ül, amíg a kép letöltődik. Mire a kép betölt, már túllépted a crawler időkorlátját.
A lassú LCP gyakori okai: tömörítés nélküli, túlméretezett képek, a renderelést blokkoló, nem optimalizált videóbeágyazások, részhalmazba nem szedett és lassan betöltő webfontok, és a képernyő felső részén renderelő harmadik féltől származó szkriptek. Mindegyik másodperceket ad az LCP-hez.
A megoldás nem az, hogy tovább várj. A megoldás az, hogy az LCP gyorsabban történjen meg. Ez képoptimalizálást, a képernyő alatti tartalom késleltetett betöltését, aszinkron szkriptbetöltést, és adott esetben a nehéz, harmadik féltől származó beágyazások statikus HTML-alternatívákra cserélését jelenti.
Interaction to Next Paint (INP): a JavaScript-végrehajtás teljesítménye
Az INP a válaszkészséget méri. Amikor egy felhasználó (vagy egy felhasználót szimuláló crawler) interakcióba lép az oldallal, mennyi idő alatt változik meg valami a képernyőn? A cél 200 ezredmásodperc alatt van.
Az AI-crawlereknél az INP megmutatja, hogy a JavaScript-ed optimalizált-e vagy felfújt. A rossz INP-pontszám azt jelzi, hogy az oldaladon túl sok kód fut a fő szálon, vagy a kód nincs megfelelően darabolva és késleltetve.
Az interakciót szimuláló crawlerek dinamikus tartalom kinyerésére teszik ezt. Ha az oldalad statikus HTML-t tölt be, de JavaScriptre támaszkodik az űrlapok, feltételes tartalmak vagy interaktív elemek renderelésében, a crawlernek végre kell hajtania azt a JavaScriptet. Ha a JavaScript lassú, a crawler rossz INP-pontszámot kap, és hatástalannak jelöli az oldalad.
A kliensoldali renderelés rejtett problémája, hogy a legtöbb AI-crawler egyáltalán nem renderel JavaScriptet. A kutatások szerint a sémajelöléssel ellátott statikus HTML 94%-os feldolgozási sikert ér el, míg a JavaScripttel renderelt tartalom 23%-ot. Ez azt jelenti, hogy ha a tartalmad JavaScript mögé van rejtve, az AI-crawlerek soha nem látják.
Ha az oldalad kliensoldali renderelést használ, az INP-probléma láthatósági problémává válik. A crawler nem tud megvárni a JavaScript végrehajtását, ezért kihagyja a JavaScript-függő tartalmat.
Cumulative Layout Shift (CLS): stabilitás a kinyerés közben
A CLS a vizuális instabilitást méri. Amikor az oldal elemei betöltés közben mozognak, a Cumulative Layout Shift nő. A cél 0,1 alatt van.
A crawlereknél a CLS nem a felhasználói élményről szól. A feldolgozás pontosságáról. Amikor a DOM elmozdul, miközben a crawler tartalmat nyer ki, rossz elemeket ragadhat meg. Egy címsor átcsúszhat egy másik címsor helyére. Egy oldalsáv kitolhatja a fő tartalmat a helyéről. A crawler azt a szöveget nyeri ki, amely egy pozícióban van, nem azt, amelyik logikailag oda tartozik.
A magas CLS gyakori okai: későn betöltő, a tartalmat lejjebb toló hirdetési helyek, megadott méretek nélküli képek, amelyek betöltés után eltolják az elrendezést, cserélődő webfontok, amelyek megváltoztatják a térközt, és automatikusan lejátszó körhinták, amelyek eltolják a tartalmat. Mindegyik elmozdítja az elrendezést.
A megoldás, hogy helyet foglalsz mindennek, ami be fog töltődni. Add meg a képek méreteit a HTML-ben. Állítsd a font-display értékét swapra, hogy a fontok ne blokkolják a renderelést. Töltsd be a hirdetéseket és a dinamikus tartalmat fenntartott konténerekben, amelyek nem okoznak elrendezésváltozást.
Hogyan optimalizálj az AI-crawlerek sebességére
Az AI-crawlerek sebességének optimalizálása más, mint az emberek számára való optimalizálás. A felhasználók azzal törődnek, mikor látják az oldalt, és mikor tudnak interakcióba lépni vele. A crawlerek azzal, mikor válaszol a szerver, és befejeződik-e az összes tartalom renderelése.
Kezdd a TTFB-vel. Ha a szervered 500 ezredmásodpercnél tovább válaszol, semmi más nem számít. Auditáld az adatbázis-lekérdezéseidet, válts gyorsabb tárhelyszolgáltatóra, vezess be gyorsítótárazást alkalmazásszinten, vagy használj CDN-t. A TTFB-be fektetett munka azonnal megtérül a crawlerlefedettségben.
Optimalizáld a képeket. Az oldalad minden képét tömöríteni kell, a megjelenítési méretére átméretezni, és modern formátumokban, például WebP-ben kiszolgálni PNG tartalékkal. Használj képtömörítő eszközt. A nyitóképekhez használj automatikus optimalizálású CDN-t.
Halaszd el a nem kritikus JavaScriptet. Csak azt a JavaScriptet töltsd be, amely feltétlenül szükséges ahhoz, hogy a crawler lássa a tartalmat. Az analitikát követő, hirdetéseket betöltő vagy interaktív funkciókat működtető szkripteket halaszd el, vagy aszinkron töltsd be. Ez szabadon tartja a fő szálat, és gyorssá teszi a végrehajtást.
Renderelj szerveroldalon kritikus tartalmat. Ha az oldalad kliensoldali keretrendszert használ, renderelj a szerveren a kritikus útvonalon, és hidratálj a kliensen. Ez biztosítja, hogy a crawlerek azonnal lássák a tartalmat. A statikus oldalgenerálás (SSG) még jobb: építsd HTML-lé az oldalaidat telepítéskor.
Kerüld a nagy, harmadik féltől származó beágyazásokat. Ha videólejátszókat, hanglejátszókat vagy nagy külső widgeteket ágyazol be, azok blokkolják a renderelést. Cseréld őket helyőrzőkre, amelyek kattintásra töltődnek be, vagy emeld ki a lényeges információt statikus HTML-be.
Foglalj helyet a dinamikus tartalomnak. Add meg a képek, hirdetések és dinamikus szakaszok pontos méreteit. Ez megakadályozza az elrendezésváltozást, és biztosítja, hogy a crawler a megfelelő tartalmat nyerje ki.
Használj CDN-t. A tartalomkézbesítő hálózat a kéréseket a földrajzilag legközelebbi szerverre irányítja, csökkentve a késleltetést és a TTFB-t. A legtöbb CDN automatikus képoptimalizálást és tömörítést is kínál.
Mit tartalmaz a WEMASY a sebességhez és a crawleroptimalizáláshoz
A WEMASY weboldalépítője tartalmaz tárhelyet automatikus CDN-gyorsítótárazással, képoptimalizálást feltöltéskor, és az oldal teljes tartalmának szerveroldali renderelését. A WEMASY-vel épített oldalak alapértelmezetten megfelelnek a Core Web Vitals szabványainak.
Amikor közzéteszel egy oldalt a WEMASY-vel, a TTFB-d a CDN-ünkön keresztül optimalizált, a képeid automatikusan átméretezve és tömörítve vannak, és a HTML-ed statikus oldalként szolgálódik ki, nem igény szerint generálva. Ez azt jelenti, hogy az AI-crawlerek azonnal látják a tartalmadat, renderelésre vagy feldolgozásra várakozás nélkül.
Nézd meg, mit tartalmaznak a WEMASY árazási csomagjai.
Gyakori kérdések
Jobban befolyásolja az oldalsebesség az AI-hivatkozásokat, mint a hagyományos SEO-t?
Az AI-crawlerek érzékenyebbek a sebességre, mert szűkebb időkorlátok között dolgoznak. A hagyományos Google-crawlerek 10 másodpercet is várhatnak egy oldal betöltésére. Az AI-crawlerek általában 3-5 másodperc után időtúllépést kapnak. A hagyományos SEO-ban a sebesség rangsorolási jel. A GEO-ban a sebesség küszöb. Ha megbuksz rajta, egyáltalán nem történnek hivatkozások. A WEMASY weboldalépítőjével ezt közvetlenül a weboldaladon beállíthatod.
Honnan tudom, hogy a TTFB-m elég gyors-e az AI-crawlereknek?
Használd a Google PageSpeed Insightst (futtasd úgy, mintha crawler lennél, az asztali verzió ellenőrzésével). Keress 500 ezredmásodperc alatti TTFB-t. Ha magasabb, vizsgáld meg a tárhelyedet, az adatbázisodat vagy az alkalmazáskódodat. Más ingyenes sebességtesztelő eszközök is megmutatják a TTFB-t. Ha a TTFB-d következetesen 600 ezredmásodperc felett van, fordulj a tárhelyszolgáltatódhoz, vagy fontold meg a gyorsabb tárhelyre költözést.
Optimalizáljak a Core Web Vitalsra, ha nem követem a hagyományos Google-rangsorokat?
Igen. A Core Web Vitals közvetlenül befolyásolja az AI-láthatóságot. Tanulmányok szerint az AI-platformok által idézett oldalak 85%-a megfelel mindhárom Core Web Vitals küszöbének. Még ha a Google-rangsorok nem is számítanak a vállalkozásodnak, az AI-láthatóság igen. Az optimalizálás ugyanaz.
Megéri gyorsabb tárhelyszolgáltatóra váltani csak a Core Web Vitals miatt?
Ha a jelenlegi TTFB-d 600 ezredmásodperc felett van, igen. Az alap és a gyors tárhely közötti költségkülönbség általában havi 5-15 dollár. A jobb AI-hivatkozásokból és crawlerlefedettségből származó megtérülés jelentősen magasabb. A gyors tárhely a felhasználói élményt és a konverziós arányokat is javítja, nem csak a bejárhatóságot.
Javítja a gyorsítótárazás a Core Web Vitalst?
A gyorsítótárazás elengedhetetlen. A böngésző-gyorsítótárazás megmondja a látogatók böngészőinek, hogy helyben tárolják a képeket és statikus fájlokat, így nem kell újra letölteniük őket. A szerveroldali gyorsítótárazás a teljesen renderelt oldalakat a memóriában tárolja, így nem kell nulláról újraépíteni őket. Mindkettő jelentősen csökkenti a TTFB-t és az LCP-t. Alkalmazz agresszíven gyorsítótár-fejléceket, és használj automatikus gyorsítótárazású CDN-t.
Árt a felhasználói élménynek az AI-crawlerek sebességére optimalizálás?
Nem. A crawlersebességi optimalizálások, a gyorsabb szerverek, a képtömörítés és a JavaScript-halasztás, minden téren javítják a felhasználói élményt. Az oldalak, amelyek gyorsabban töltenek be a crawlereknek, gyorsabban töltenek be az embereknek is. Az egyetlen kivétel, ha kizárólag a crawlerekre próbálsz optimalizálni képek eltávolításával vagy a tartalom lecsupaszításával, ami árt a felhasználóknak. Ezt ne tedd. Optimalizálj sebességre az érték elvétele nélkül.