Hosting a SEO: ako rýchlosť servera ovplyvňuje prehľadávanie a návštevníkov
Pri výbere hostingu sa väčšinou porovnáva cena a veľkosť disku, no pre vyhľadávanie rozhoduje skôr to, ako rýchlo a spoľahlivo server odpovedá. Pomalá odpoveď predlžuje načítanie stránky a chyby servera nútia Google prehľadávať web pomalšie, v krajnom prípade dokonca stránky z indexu vyradiť. Článok vychádza z dokumentácie Google Search Central a z web.dev a ukazuje, čo je čas do prvého bajtu, aké hodnoty sa považujú za dobré, ako sa správa Googlebot pri chybách a ako zistiť, či problém spôsobuje hosting.
1. Čo hosting znamená pre SEO a čo nie
Hosting je služba, na ktorej server beží váš web, a pre vyhľadávanie je dôležitý z jedného dôvodu: každú stránku musí najprv doručiť, až potom ju Google môže prečítať a zaradiť. Dokumentácia Google Search Central ani web.dev netvrdia, že by značka hostingu alebo cena balíka priamo ovplyvňovali poradie vo výsledkoch. Skutočný vplyv ide cez dve konkrétne veličiny, a to rýchlosť, s akou server odpovedá, a stabilitu, s akou odpovedá vždy.
Rozdiel medzi tvrdením „rýchly hosting zlepší pozície“ a tým, čo dokumentácia naozaj hovorí, je podstatný. Spoľahlivo doložiteľné je len to, že pomalý server predlžuje načítanie pre návštevníkov a že chyby servera spomaľujú prehľadávanie. Či a ako veľmi sa to prejaví na pozíciách, závisí od konkrétneho webu, a preto ho tento článok netvrdí.
Prehľadnejšie to ukazuje porovnanie toho, čo je podložené zdrojmi, a toho, čo sa v diskusiách často opakuje bez dôkazu.
| Tvrdenie | Stav podľa dokumentácie |
|---|---|
| Chyby 5xx a 429 spomaľujú prehľadávanie | Doložené: Google ich berie ako signál dočasného spomalenia |
| Dlho trvajúce chyby servera vedú k vyradeniu adries z indexu | Doložené: indexačný proces takéto adresy odstraňuje |
| Dobrý TTFB je do 0,8 sekundy | Doložené ako orientačná hodnota web.dev |
| TTFB je jednou z metrík Core Web Vitals | Nie je, web.dev to výslovne uvádza |
| Drahší hosting zvyšuje pozície | Bez dôkazu, preto sa v texte nepoužíva |
Ak riešite celkové načítanie stránky, nadväzuje na to článok o Core Web Vitals a rýchlosti webu. Tento text sa sústreďuje na vrstvu pod ním, teda na server.
2. Čas do prvého bajtu (TTFB): čo meria a aké hodnoty sú dobré
Metrika TTFB, po anglicky Time to First Byte, teda čas do prvého bajtu, meria čas od začiatku navigácie na stránku po okamih, keď príde prvý bajt odpovede. Podľa web.dev je to súčet niekoľkých fáz: času presmerovaní, spustenia service workera (ak sa používa), vyhľadania v DNS, nadviazania spojenia vrátane TLS a samotnej požiadavky až do chvíle, keď dorazí prvý bajt odpovede (web.dev: Time to First Byte).
Pre bežného majiteľa webu z toho plynie užitočná vec: vysoký TTFB nemusí znamenať pomalý hosting. Môžu ho zdvihnúť aj reťazce presmerovaní, pomalé DNS alebo vzdialenosť návštevníka od servera. Pred každým rozhodnutím o zmene hostingu preto treba zistiť, ktorá z fáz je problém.
Hodnoty, ktoré web.dev uvádza, sú orientačné. Za dobrý sa považuje TTFB do 0,8 sekundy a za zlý nad 1,8 sekundy, pričom 0,8 sekundy je podľa článku len hrubé vodidlo pre väčšinu webov. TTFB sa navyše nepočíta medzi Core Web Vitals, takže nejde o hodnotenie, ktoré by Google zverejňoval ako samostatné kritérium. Pomáha však vysvetliť, prečo sa môže zhoršiť metrika najväčšieho obsahu, ktorá už medzi Core Web Vitals patrí, lebo prvý bajt je východiskom pre všetko ostatné.
| Fáza TTFB | Čo sa v nej deje | Typický vinník |
|---|---|---|
| Presmerovania | Prechod z jednej adresy na druhú pred cieľovou stránkou | Reťazec http, bez www, s www |
| DNS | Preklad názvu domény na adresu servera | Pomalý poskytovateľ DNS |
| Spojenie a TLS | Nadviazanie šifrovaného spojenia | Vzdialený server, zastaraná konfigurácia |
| Požiadavka a odpoveď | Server pripraví stránku a pošle prvý bajt | Pomalá aplikácia, databáza, preťažený server |
3. Ako Googlebot reaguje na pomalý a chybový server
Dokumentácia Google o prehľadávaní popisuje, že Googlebot sa snaží prehľadávať web tak, aby nepreťažil server. Podľa príručky o rozpočte prehľadávania sa limit kapacity zvyšuje, keď server odpovedá rýchlo, a klesá, keď sa web spomalí alebo začne vracať chyby 5xx (Google Search Central: Crawl budget). Pre malé weby to nie je zásadný problém, lebo príručka je určená hlavne väčším webom, no princíp platí rovnako.
Presnejšie to rozpisuje dokumentácia o stavových kódoch HTTP a sieťových chybách. Chyby 5xx a 429 podľa nej vedú k tomu, že Google dočasne spomalí prehľadávanie, a toto spomalenie je úmerné počtu adries, ktoré vracajú chybu servera. Keď server začne znova odpovedať kódom 2xx, rýchlosť prehľadávania sa postupne zvyšuje (Google Search Central: HTTP status codes, network and DNS errors).
Nepríjemnejší je dlhodobý stav. Ak adresa trvalo vracia chybu servera, indexačný proces ju z indexu odstráni, zatiaľ čo už zaindexované adresy sa spočiatku zachovajú a až neskôr vypadnú. Dokumentácia nestanovuje presnú lehotu, takže bezpečné je nepredpokladať žiadnu lehotu a výpadky riešiť hneď.
- Jednorazový výpadok na hodiny: Google prehľadávanie dočasne spomalí a po obnovení servera ho postupne zrýchli.
- Opakované chyby 5xx na viacerých adresách: spomalenie je úmerné počtu zasiahnutých adries.
- Trvalá chyba na konkrétnej adrese: adresa môže z indexu vypadnúť.
- Plánovaná údržba: správny postup s kódom 503 popisuje článok o dočasnom vypnutí webu a údržbe.
4. Kde zistiť, či problém spôsobuje hosting
Najpriamejší údaj poskytuje samotný Google v Search Console. Správa Štatistiky prehľadávania ukazuje celkový počet požiadaviek na prehľadanie, objem stiahnutých dát a priemerný čas odpovede pre všetky načítané zdroje. Súčasťou je aj stav hostiteľa, ktorý hovorí, či Google pri prehľadávaní narazil na problémy s dostupnosťou: s načítaním súboru robots.txt, s vyhľadaním v DNS alebo s pripojením k serveru (Search Console: Crawl Stats report). Správa je dostupná len pre vlastnosti na úrovni koreňovej domény, takže pri vlastnosti zriadenej na podpriečinok ju nenájdete.
Druhým zdrojom sú dáta od skutočných návštevníkov. Web.dev odporúča sledovať TTFB primárne podľa poľných dát, teda meraní z reálnych zariadení, lebo laboratórne nástroje merajú zvyčajne len konečnú adresu a presmerovania vynechajú. Ak je poľný TTFB výrazne vyšší než laboratórny, ide podľa článku o problém, ktorý v laboratóriu nie je vidieť (web.dev: Optimize Time to First Byte). Pre verejné weby s dostatkom návštevnosti zobrazí obe dátové sady nástroj PageSpeed Insights.
Na doplnenie slúžia záznamy servera. Kto si chce overiť, ktoré adresy Googlebot žiada a aké kódy dostáva, nájde postup v článku o analýze log súborov.
- Otvorte v Search Console správu Štatistiky prehľadávania a sledujte priemerný čas odpovede za posledné obdobie.
- Skontrolujte stav hostiteľa: pri problémoch s robots.txt, DNS alebo pripojením ide o dostupnosť, nie o obsah.
- Vložte adresu do PageSpeed Insights a porovnajte poľný a laboratórny TTFB.
- Ak je rozdiel veľký, hľadajte presmerovania a vzdialenosť návštevníkov od servera skôr než výmenu hostingu.
5. Čo zlepšuje odpoveď servera a čo ju zhoršuje
Web.dev v príručke o optimalizácii TTFB uvádza niekoľko konkrétnych oblastí. Prvou je samotný hosting, pre ktorý platí všeobecné pravidlo, že hostiteľ musí zvládnuť návštevnosť, ktorú mu posielate. Ak aj na vyhradenom hostingu zostáva TTFB trvalo vysoký, článok odporúča prehodnotiť možnosti poskytovateľa.
Druhou oblasťou je sieť na doručovanie obsahu, po anglicky CDN. Návštevníci ďaleko od pôvodného servera môžu mať podľa článku vysoký TTFB aj vtedy, keď je samotný server rýchly, a ak web CDN nepoužíva, mala by to byť vysoká priorita. Tretia oblasť sú presmerovania, ktoré článok označuje za častú príčinu vysokého TTFB, a odporúča odstraňovať najmä tie v rámci vlastnej domény, lebo tie máte pod kontrolou.
K tomu patrí jedno upozornenie, ktoré sa v bežných návodoch vynecháva: vyrovnávacia pamäť môže pomalý backend zamaskovať. Preto web.dev radí mať spôsob, ako pri testovaní vyrovnávaciu pamäť a CDN obísť, napríklad cez parameter v adrese. Inak sa môže stať, že meranie vyzerá dobre len preto, že sa pozeráte na uloženú kópiu.
| Oblasť | Čo odporúča web.dev | Čo to znamená v praxi |
|---|---|---|
| Hosting | Hostiteľ musí zvládnuť návštevnosť, ktorú mu posielate | Pri raste návštevnosti sledovať odpoveď servera |
| CDN | Pomáha návštevníkom ďaleko od pôvodného servera | Dôležité pri zahraničnej alebo rozptýlenej návštevnosti |
| Vyrovnávacia pamäť | Môže zamaskovať pomalý backend | Pri meraní mať možnosť ju obísť |
| Presmerovania | Odstrániť presmerovania v rámci vlastnej domény | Skrátiť reťazce na jeden krok |
Presmerovania sa často nahromadia po zmene adries alebo prechode z http na https. Ako ich riešiť správne, popisuje článok o presmerovaniach 301.
6. Kedy sa oplatí hosting vymeniť
Výmena hostingu je zásah s rizikom, nie opatrenie na každý pomalší deň. Rozumné je ju zvažovať vtedy, keď merania opakovane ukazujú, že príčinou je server, a nie aplikácia, presmerovania alebo vzdialenosť. Typické signály sú trvalo vysoký TTFB aj bez presmerovaní, opakované chyby 5xx v štatistikách prehľadávania a stav hostiteľa, ktorý hlási problémy s pripojením k serveru.
Keď sa pre výmenu rozhodnete, platia pravidlá sťahovania webu. Adresy majú ostať rovnaké, DNS sa mení postupne a starý server sa vypína až po overení, že ten nový odpovedá správne. Podrobný postup nájdete v článku o migrácii webu bez straty SEO. Pri samotnom prechode sa oplatí sledovať Štatistiky prehľadávania, pretože prípadné chyby sa v nich ukážu skôr než v pozíciách.
Na záver stručná kontrolná postupnosť pred akýmkoľvek rozhodnutím: zmerať odpoveď servera v poľných dátach, rozložiť ju na fázy, odstrániť presmerovania a overiť stav hostiteľa v Search Console. Až keď problém zostane, hľadá sa ďalší hosting, a nie naopak.
Časté otázky
Ovplyvňuje hosting SEO?
Nepriamo. Dokumentácia Google ani web.dev netvrdia, že by hosting sám o sebe určoval pozície, no pomalá odpoveď servera predlžuje načítanie stránky a chyby 5xx a 429 podľa Google dočasne spomaľujú prehľadávanie webu.
Aký TTFB je dobrý?
Web.dev uvádza ako dobrú hodnotu 0,8 sekundy alebo menej a ako zlú hodnotu nad 1,8 sekundy. Ide o orientačné vodidlo a TTFB nie je súčasťou Core Web Vitals.
Čo urobí Googlebot, keď server vracia chyby 5xx?
Google dočasne spomalí prehľadávanie a spomalenie je úmerné počtu adries s chybou. Po obnovení odpovedí s kódom 2xx sa rýchlosť prehľadávania postupne zvyšuje. Adresy, ktoré chybu vracajú trvalo, môže indexačný proces z indexu odstrániť.
Kde v Search Console vidím, či je problém na strane servera?
V správe Štatistiky prehľadávania, ktorá ukazuje priemerný čas odpovede a stav hostiteľa vrátane problémov s robots.txt, DNS a pripojením k serveru. Správa je dostupná len pre vlastnosti na úrovni koreňovej domény.
Pomôže sieť CDN pri pomalom TTFB?
Môže, ak sú návštevníci ďaleko od pôvodného servera. Web.dev uvádza, že aj pri rýchlom serveri môžu mať takí návštevníci vysoký TTFB, a pri webe bez CDN to považuje za vysokú prioritu. Treba však merať aj bez vyrovnávacej pamäte, lebo tá môže pomalý backend zamaskovať.