Elérhetőség és válaszidő

SEO-hatás. A Google a szerver terhelhetőségéhez igazítja a feltérképezés ütemét. Lassú válaszoknál kevesebb URL-t kér le naponta. Ismétlődő 5xx vagy időtúllépés után az érintett oldalak kieshetnek az indexből.

AI-értelmezhetőség. Az AI-crawlerek egy próbálkozásból dolgoznak. Ha az a lekérés hibára fut, a modellhez nulla információ jut el rólad. Nem rossz adatot kapnak, hanem semmilyet.

Üzleti hatás. A szerver-oldali késleltetés minden látogatónál jelentkezik, mobilon és asztali gépen is. Egy 3 másodperces TTFB mellett a betöltési idő már eleve behozhatatlan. Webshopnál a kosár- és pénztár-lépések a legérzékenyebbek: ott a kiesés közvetlen bevételkiesés.

Mérés-torzítás. Az instabil szerver a többi audit eredményét is elrontja. Hiányzó sémák, üres tartalom, félbeszakadt vizsgálat: sokszor csak a kiesés tünetei.

Minden nyilvános oldalra vonatkozik, típustól függetlenül. Nincs olyan oldal, amelynél elfogadható, hogy időnként nem válaszol.

Különösen kritikus:

• webshopok, ahol a kosár és a pénztár szerver-oldali logikát futtat,
• olcsó megosztott tárhelyen futó WordPress-oldalak, sok pluginnal,
• kampányidőszakban terhelt oldalak, ahol a forgalom órák alatt sokszorozódik,
• nagy katalógusú oldalak, ahol a szűrő-URL-ek terhelik az adatbázist.

Kevésbé releváns, vagy máshogy értelmezendő:

• jelszóval védett staging- és fejlesztői környezetek, ahol a lassulás nem ügyfél-élmény kérdése,
• belső hálózatról elérhető admin-felületek,
• szándékosan blokkolt bot-forgalom, ahol a 403 nem hiba, hanem döntés.

Ha a hoszting SaaS (Unas, Shoprenter, Shopify), a szerver-kapacitáson nem te döntesz. A saját sablonodon, a beépülő szkripteken és a hívott API-kon viszont igen.

1. Mérd meg curl-lel. Egy parancs megmutatja a státuszkódot és a TTFB-t. Futtasd 10-20 alkalommal, változó időpontokban, ne egyszer.
2. Nézd meg a Search Console feltérképezési statisztikáit. Beállítások menü, Feltérképezési statisztikák. Az átlagos válaszidő grafikonja és a gazdagép állapota árulkodó.
3. Futtass PageSpeed Insights-ot. A "Kezdeti szerverválasz ideje" audit külön kiírja az ezredmásodperceket.
4. Nyisd meg a böngésző devtools Network fülét. A dokumentum-kérésnél a Waiting (TTFB) sor a szerver ideje.
5. Tegyél fel uptime-monitort. 1-5 perces lekérési gyakoriság mellett a rövid kiesések is láthatók lesznek.
6. Olvasd a szerver hibanaplóját. A PHP-FPM és a webszerver naplója megmondja, mi futott ki: memória, worker, adatbázis.

Jó jel:

• a lekérések 100 százaléka 200-as kódot ad,
• a TTFB stabilan 800 ms alatt marad,
• a szórás kicsi, nincsenek kiugró értékek,
• a Search Console-ban lapos a válaszidő-görbe.

Rossz jel:

• ismétlődő 502, 503 vagy 504 kód,
• szabálytalan időtúllépések, napszaktól függően,
• 2 másodperc feletti átlagos TTFB,
• a robotok kódja eltér a böngészőétől (tűzfal vagy rate limit),
• a Search Console-ban emelkedő válaszidő-trend.

WordPress

1. Kapcsolj be teljes oldal-cache-t (LiteSpeed Cache, WP Rocket, W3 Total Cache). Ez szinte mindig a legnagyobb ugrás.
2. Állíts be objektum-cache-t Redis vagy Memcached mögé, ha sok a dinamikus lekérdezés.
3. Telepítsd a Query Monitort, és nézd meg a leglassabb SQL-eket. A magyar KKV-oldalak többségén egy-két plugin viszi el a futásidő felét.
4. Váltsd ki a wp-cron.php-t valódi rendszer-cronra, 5 perces ütemezéssel.
5. Frissíts PHP 8.x-re, OPcache-sel.
6. Nézd át a tűzfal és a rate limit szabályait. A keresőrobotokat és az AI-crawlereket ne dobja ki a WAF.
7. Ha a tárhely folyamatosan a limiten van, csomagot vagy szolgáltatót kell váltani.

Shopify

1. A szerver-kapacitás adott, a hibát a saját rétegedben keresd.
2. Csökkentsd az aktív appok számát, a felmondott appok maradék szkriptjeit töröld a témából.
3. Nézd át a Liquid-ciklusokat, különösen a nagy kollekciókon futó beágyazott ciklusokat.
4. A külső szkripteket töltsd aszinkron módon.
5. Kiesésnél ellenőrizd a Shopify hivatalos státuszoldalát, mielőtt a témát bántod.

Unas

1. A szerver-oldali válaszidőt a rendszer adja, ezért a saját terhelésedet vizsgáld.
2. Csökkentsd a sablonba illesztett külső szkriptek számát.
3. Az API- és feed-hívásokat ütemezd forgalmon kívüli időre.
4. Ismétlődő időtúllépésnél nyiss hibajegyet, és mellékeld a mérési időpontokat és a lekért URL-eket.

Shoprenter

1. Nézd át a sablon egyedi módosításait, főleg a nagy terméklistákat megjelenítő blokkokat.
2. Kerüld a több száz elemet betöltő kategória-oldalakat, lapozz.
3. A külső marketing-szkripteket tedd aszinkronná.
4. Tartós lassulásnál kérj szerver-oldali ellenőrzést az ügyfélszolgálattól, konkrét mérésekkel.

Egyedi fejlesztés

1. Tegyél fel APM-et vagy legalább slow query logot, és keresd a leglassabb végpontokat.
2. Vezess be HTTP-szintű gyorsítótárazást a jól cache-elhető oldalakra.
3. Tedd a statikus tartalmat CDN (tartalomszolgáltató hálózat) mögé, hogy az origin csak a HTML-t szolgálja ki.
4. Karbantartáskor 503-at adj vissza Retry-After fejléccel, ne 200-as hibaoldalt.
5. Állíts be automatikus skálázást vagy legalább riasztást a worker-kimerülésre.
6. Indexeld a gyakran szűrt adatbázis-oszlopokat.

• A frontend optimalizálása lassú szerver mellett: hiába tömöríted a képeket, ha a HTML-re 3 másodpercet vársz.
• Egyetlen mérésből levont következtetés: az időszakos kiesés pont a mérés közti percekben történik.
• A robotokat kizáró tűzfal vagy rate limit: a látogatónak megy az oldal, a keresőnek 403 vagy 429 jön vissza.
• Hibaoldal 200-as kóddal: a rendszer sikerként könyveli el a hibát, lásd a HTTP-státuszkódok logikáját.
• Karbantartás 200-as "hamarosan visszatérünk" oldallal: a kereső üres oldalként indexeli a szöveget.
• Cache csak a látogatóknak: sok beállításnál a bot-forgalom megkerüli a gyorsítótárat, és minden kérés az adatbázisra megy.
• Nincs monitorozás: a kiesésről az ügyfél telefonjából értesülsz, nem a rendszerből.

Egyetlen curl-parancs megmutatja a státuszkódot és a szakaszos időket. A time_starttransfer a TTFB.

curl -o /dev/null -s -w "kod=%{http_code} dns=%{time_namelookup} tls=%{time_appconnect} ttfb=%{time_starttransfer} teljes=%{time_total}\n" https://pelda.hu/

Tíz ismétléssel a szórás is látszik, és kiderül, időszakos-e a hiba:

for i in $(seq 1 10); do
  curl -o /dev/null -s -w "%{http_code} %{time_starttransfer}\n" https://pelda.hu/
  sleep 5
done

Tipikus kimenet instabil szervernél. A nyolcadik kérés kifutott, ez az "időszakos kiesés" mintázata:

200 0.412
200 0.388
200 0.401
200 2.914
200 0.395
200 0.420
200 0.399
000 10.001
200 0.407
200 0.394

Tervezett karbantartásnál ez a helyes válasz. A robot tudni fogja, hogy vissza kell jönnie:

HTTP/1.1 503 Service Unavailable
Retry-After: 3600
Cache-Control: no-store
Content-Type: text/html; charset=utf-8