Wyjaśniam, jak hosting wpływa na SEO według dokumentacji Google i co sprawdzić u siebie. Hosting wpływa na SEO pośrednio: Google nie ocenia rodzaju ani marki hostingu, tylko odpowiedzi serwera. Działa to przez 5 mechanizmów: czas odpowiedzi, błędy 5xx, dostępność robots.txt, Core Web Vitals i blokady botów. Hosting a SEO to zależność między serwerem strony a crawlowaniem, indeksowaniem i szybkością wczytywania.
Tekst jest dla właściciela strony, który wybiera hosting albo zastanawia się, czy przenosiny na droższy serwer coś zmienią w Google. Dokumentacja, progi i nazwy raportów są aktualne na październik 2026.
Hosting a SEO w skrócie: definicja i zakres wpływu
Hosting to usługa udostępniania miejsca i mocy serwera, na którym działa strona, razem z siecią, DNS-em i certyfikatem TLS. Rodzaj hostingu (współdzielony, VPS, dedykowany, chmura) nie jest czynnikiem rankingowym. Czynnikiem dla Google jest to, jak serwer odpowiada: jak szybko, jak często z błędem i czy w ogóle wpuszcza roboty.
Google nie ocenia nazwy firmy hostingowej ani ceny pakietu. Googlebot widzi kody HTTP, czas odpowiedzi, dostępność pliku robots.txt i rozpoznawanie DNS. Użytkownik i dane Chrome UX Report widzą czas wczytania strony. Z tych dwóch perspektyw wynika cały wpływ hostingu na SEO.
Wpływ hostingu na SEO ma też górną granicę. Według dokumentacji Google o page experience (aktualizacja 22.09.2026) dobre wyniki Core Web Vitals „nie gwarantują” pierwszych pozycji, a Google pokazuje najbardziej trafne treści nawet przy słabym page experience. Szybki serwer nie nadrobi braku treści odpowiadającej na zapytanie.
Jak hosting wpływa na SEO: 5 mechanizmów
Każdy z 5 mechanizmów ma źródło w dokumentacji Google Search Central albo web.dev:
- Czas odpowiedzi serwera ustala tempo crawlowania. Google wylicza crawl capacity limit, czyli limit czasu, przez który serwer trzyma otwarte połączenia dla Googlebota. Szybkie i stabilne odpowiedzi podnoszą limit, a wolniejsze go obniżają.
- Błędy 5xx i 429 spowalniają crawlowanie i z czasem usuwają URL-e z indeksu. Googlebot traktuje kod 429 jako sygnał przeciążenia serwera, a powtarzające się 5xx jako powód do zwolnienia.
- Niedostępny robots.txt zatrzymuje crawlowanie całej witryny. Błąd 5xx na pliku robots.txt działa na całą domenę, a nie na jeden URL.
- TTFB wpływa na LCP, a LCP jest metryką Core Web Vitals. Czas do pierwszego bajtu nie jest oceniany osobno, ale każda milisekunda serwera przesuwa wczytanie największego elementu strony.
- Firewall, WAF i CDN mogą zablokować Googlebota albo boty AI. Strona z blokadą na poziomie infrastruktury jest niewidoczna dla robota, mimo poprawnego robots.txt.
Mechanizm 1: czas odpowiedzi serwera a crawl budget
Według przewodnika Google o crawl budgecie (aktualizacja 22.07.2026) crawl capacity limit rośnie, gdy strona odpowiada szybko, a spada, gdy rosną opóźnienia albo pojawiają się błędy serwera. Google wprost zaleca optymalizację czasu odpowiedzi serwera i dodanie zasobów serwera, „jeśli ma to sens dla biznesu”.
Przewodnik o crawl budgecie Google adresuje do stron z ponad milionem odrębnych URL-i zmienianych co tydzień albo z ponad 10 000 URL-i zmienianych codziennie. Blog z kilkuset wpisami rzadko odczuwa limit crawlowania, nawet na tanim hostingu. Szerzej opisałem limity i sposoby ich sprawdzania we wpisie o crawl budgecie.
Czas odpowiedzi serwera widać w raporcie Statystyki indeksowania w Google Search Console (Ustawienia → Statystyki indeksowania). Według pomocy Google do raportu Statystyki indeksowania „średni czas odpowiedzi” to średnia ze wszystkich zasobów pobranych przez Google, a każdy zasób, np. plik CSS czy obrazek, liczy się jako osobna odpowiedź. Raport działa tylko dla usługi domenowej albo usługi z prefiksem URL na poziomie głównym.
Mechanizm 2: błędy 5xx, 429 i przerwy techniczne
Według dokumentacji Google o kodach HTTP i błędach sieci kody 5xx i 429 sprawiają, że roboty Google tymczasowo zwalniają crawlowanie. Zaindeksowane URL-e zostają w indeksie, ale przy dłużej trwających błędach „ostatecznie są usuwane”. Google nie podaje liczby dni. Po powrocie odpowiedzi 2xx tempo crawlowania rośnie stopniowo, a nie od razu.
Spadek tempa crawlowania przy kodzie 500 zależy według Google od liczby URL-i, które zwracają błąd serwera. Pojedynczy błąd 500 na jednym adresie nie zmienia wiele. Przeciążony hosting współdzielony, który w godzinach szczytu zwraca 503 na połowie żądań, obniża tempo crawlowania całej domeny.
Planowaną przerwę techniczną Google każe oznaczać kodem 503. Według dokumentacji Google o wstrzymaniu działalności online stronę informacyjną z kodem 503 można pokazać na 1–2 dni, a pełne wyłączenie strony powinno trwać najwyżej kilka dni. Zamknięcie witryny nawet na kilka tygodni może zaszkodzić indeksowaniu i nie ma mechanizmu, który przyspiesza powrót.
Mechanizm 3: dostępność robots.txt i DNS
Plik robots.txt niedostępny przez błąd serwera to najpoważniejszy skutek złego hostingu. Według specyfikacji robots.txt w Google Search Central Google przy 5xx na robots.txt:
- przez pierwsze 12 godzin przestaje crawlować witrynę i ponawia próbę pobrania pliku robots.txt;
- przez kolejne dni, do 30 dni, używa ostatniej poprawnej wersji robots.txt z pamięci podręcznej;
- po 30 dniach, jeśli cała witryna ma problemy z dostępnością, przestaje ją crawlować i tylko co jakiś czas sprawdza robots.txt.
Błędy DNS, przekroczenia czasu i błędy sieci specyfikacja robots.txt traktuje tak samo jak błędy serwera 5xx. Słaby DNS u dostawcy hostingu albo domeny ma więc ten sam skutek co awaria serwera.
Raport Statystyki indeksowania w Google Search Console pokazuje stan hosta w 3 kategoriach: pobieranie pliku robots.txt, rozpoznawanie DNS i łączność z serwerem. Na wykresie każdej kategorii jest czerwona przerywana linia progu. Przykładowy próg z pomocy Google to błędy DNS w ponad 5% żądań w ciągu dnia. Zielony stan hosta oznacza brak istotnych problemów przez ostatnie 90 dni. Raport Statystyki indeksowania i pozostałe raporty opisałem we wpisie jak korzystać z Google Search Console.
Mechanizm 4: TTFB, LCP i Core Web Vitals
TTFB (Time to First Byte) to czas od żądania do otrzymania pierwszego bajtu odpowiedzi. Według artykułu web.dev o TTFB metryka obejmuje przekierowania, uruchomienie service workera, zapytanie DNS, nawiązanie połączenia i TLS oraz przetworzenie żądania przez serwer. Dobry TTFB to 0,8 s lub mniej, słaby to ponad 1,8 s.
TTFB nie jest metryką Core Web Vitals, co web.dev zaznacza wprost. Hosting wpływa na Core Web Vitals pośrednio, głównie przez LCP, bo przeglądarka nie zacznie rysować największego elementu, zanim serwer nie odda HTML. INP i CLS zależą przede wszystkim od JavaScriptu i układu strony, a nie od serwera.
| Metryka | Próg „dobry” | Wpływ hostingu | Źródło progu |
|---|---|---|---|
| TTFB | ≤ 0,8 s | bezpośredni: serwer, cache, DNS, TLS | web.dev |
| LCP (Largest Contentful Paint) | ≤ 2,5 s | duży: TTFB jest częścią LCP | Google Search Central |
| INP (Interaction to Next Paint) | < 200 ms | mały: zależy od JavaScriptu w przeglądarce | Google Search Central |
| CLS (Cumulative Layout Shift) | < 0,1 | brak: zależy od układu strony | Google Search Central |
Progi LCP, INP i CLS w tabeli pochodzą z dokumentacji Google o Core Web Vitals. INP zastąpił FID jako metrykę Core Web Vitals 12 marca 2024 roku, więc poradniki o hostingu, które w październiku 2026 roku nadal piszą o FID, opisują nieaktualny stan.
Hosting bynajmniej.pl sprawdziłem 14.10.2026 przy audycie bloga. Tester ai-cite-check zmierzył TTFB około 190 ms (mediana 3 prób, z Polski) przy HTML-u 116 KB. W tym samym dniu crawl Screaming Frog pokazał 10 URL-i z czasem odpowiedzi powyżej 1000 ms, wszystkie to archiwa tagów i kategorii. Wniosek z tego audytu: TTFB zmierzony na jednym adresie nie mówi wszystkiego, bo wolne bywają konkretne typy podstron, generowane przez CMS przy każdym żądaniu.
Mechanizm 5: firewall, CDN i boty AI
Ochrona przed botami na serwerze albo w CDN potrafi zablokować prawdziwego Googlebota, zwykle przez limit żądań na IP albo regułę WAF. Google opisuje w dokumentacji o weryfikacji Googlebota 2 metody rozpoznania prawdziwego robota: odwrotne zapytanie DNS poleceniem host 66.249.66.1 z kontrolą, czy nazwa kończy się na googlebot.com, google.com lub googleusercontent.com, albo porównanie IP z plikami JSON, np. common-crawlers.json i special-crawlers.json. Reguły firewalla polecam opierać na tych listach, a nie na samym user agencie.
Blokady infrastruktury dotyczą też botów AI. Cloudflare 1 lipca 2025 roku ogłosił (stan według tego ogłoszenia, domyślne ustawienia mogły się od tego czasu zmienić) domyślne blokowanie crawlerów AI bez zgody właściciela strony, a przy dodawaniu nowej domeny pyta, czy wpuścić crawlery AI. Strona za Cloudflare może więc mieć otwarty robots.txt i jednocześnie być zamknięta dla GPTBota czy ClaudeBota na poziomie CDN. Przy audycie widoczności w AI search polecam najpierw sprawdzić ustawienia CDN, a dopiero potem robots.txt.
Na bynajmniej.pl 14.10.2026 robots.txt z Yoast niczego nie blokował, a GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, PerplexityBot, Googlebot i Bingbot dostawały pełną treść. Test był robiony z podszytym user agentem, więc wynik jest orientacyjny: prawdziwy bot przychodzi z innego IP, a reguły WAF często patrzą właśnie na IP.
Rodzaj hostingu a SEO: współdzielony, VPS, dedykowany, chmura
Rodzaj hostingu nie ma znaczenia dla Google sam w sobie, ma znaczenie przez zasoby i konfigurację. John Mueller z Google powiedział w lipcu 2021 roku, że hosting współdzielony „jest w porządku i nie wpływa negatywnie na stronę w wyszukiwarce Google”, a serwer dedykowany „nie zawsze jest szybki”, tak jak współdzielony „nie jest automatycznie wolny”.
| Rodzaj hostingu | Główne ryzyko dla SEO | Kiedy wystarcza |
|---|---|---|
| Hosting współdzielony | 503 i wolne odpowiedzi przy przeciążeniu przez inne strony na serwerze, limity procesów PHP | blog, strona firmowa, mały sklep |
| VPS | konfiguracja po stronie właściciela: aktualizacje, cache, firewall, monitoring | średni sklep, kilka stron, strony z ruchem sezonowym |
| Serwer dedykowany | awaria jednej maszyny bez zapasu, koszt administracji | duże serwisy z przewidywalnym, wysokim ruchem |
| Chmura i CDN | domyślne reguły WAF i blokady botów, w tym botów AI | serwisy z ruchem z wielu krajów i skokami ruchu |
Moim zdaniem przy wyborze hostingu pod SEO lepiej niż porównywać rodzaje usług jest sprawdzić 3 rzeczy. Pierwsza to TTFB podstron generowanych dynamicznie, np. wyszukiwarki i archiwów tagów. Druga to zachowanie serwera pod obciążeniem, czyli czy zwraca 503. Trzecia to możliwość wyłączenia albo dostrojenia blokad botów w panelu.
Mity o hostingu i SEO
Mit o „złym sąsiedztwie” na wspólnym IP wraca w poradnikach co kilka lat. John Mueller w 2020 roku, w odpowiedzi na badanie Reboot Online, powiedział, że nie zna algorytmu rankingowego, który brałby pod uwagę adresy IP innych stron na tym samym serwerze. Jako przykład podał Bloggera, gdzie mocne i słabe strony stoją na tej samej infrastrukturze.
Mit o serwerze w Polsce jako warunku pozycji w Polsce też się nie broni. Według dokumentacji Google o witrynach wieloregionalnych lokalizacja serwera ustalana przez IP to jeden z sygnałów geotargetowania, ale „nie jest sygnałem rozstrzygającym”, bo wiele stron korzysta z CDN i hostingu za granicą. Silniejszymi sygnałami są domena krajowa (ccTLD) i hreflang. Serwer blisko użytkowników ma sens z innego powodu: krótszej drogi pakietów i niższego TTFB.
Mit „hostingu SEO” z wieloma adresami IP z różnych klas C to usługa pod zaplecza linkowe, czyli pod ukrywanie, że kilkadziesiąt stron ma jednego właściciela. Hosting z setką IP nie poprawia pozycji strony, która na nim stoi, a zasady Google dotyczące spamu wymieniają tworzenie treści niskiej wartości głównie do manipulowania linkami jako link spam. Kupowanie osobnego IP dla każdego bloga, żeby Google „nie skojarzył”, to trochę jak zakładanie wąsów przed wizytą u własnej matki.
Mit o HTTPS jako dużym czynniku rankingowym wymaga korekty skali. Google w sierpniu 2014 roku ogłosił HTTPS jako lekki sygnał, który dotyczył mniej niż 1% zapytań na świecie. Darmowy certyfikat TLS ma dziś każdy hosting, więc HTTPS nie odróżnia jednego dostawcy od drugiego, a brak HTTPS odróżnia stronę od reszty internetu, i to na gorsze.
Zmiana hostingu bez utraty pozycji
Przeniesienie strony na nowy hosting bez zmiany adresów URL Google opisuje w przewodniku o przenoszeniu witryny bez zmian URL-i. Kolejność kroków:
- Skopiuj stronę na nowy hosting i przetestuj ją pod tymczasową nazwą hosta z noindex, a dostęp Googlebota sprawdź Narzędziem do sprawdzania adresów URL.
- Obniż TTL rekordów DNS do kilku godzin co najmniej tydzień przed przeniesieniem.
- Sprawdź, czy na nowym serwerze jest plik albo meta tag weryfikacji Google Search Console, i usuń tymczasowe blokady w robots.txt oraz noindex.
- Zmień rekordy DNS na nowy serwer.
- Obserwuj logi obu serwerów: tymczasowy spadek tempa crawlowania zaraz po przeniesieniu Google uznaje za normalny, a w kolejnych dniach tempo powinno rosnąć.
- Wyłącz stary hosting dopiero wtedy, gdy ruch na starym serwerze spadnie do zera.
Po przenosinach warto zrobić crawl i sprawdzić kody HTTP, bo nowy serwer często ma inną konfigurację przekierowań i stron błędów. Pełną listę kontroli technicznej opisałem w poradniku jak zrobić audyt SEO.
FAQ: hosting a SEO
Czy hosting ma wpływ na SEO?
Hosting ma wpływ na SEO przez czas odpowiedzi serwera, błędy 5xx, dostępność robots.txt i DNS oraz LCP. Sam rodzaj ani marka hostingu nie są czynnikiem rankingowym Google.
Czy hosting współdzielony szkodzi pozycjonowaniu?
Hosting współdzielony nie szkodzi pozycjonowaniu, co John Mueller z Google potwierdził w 2021 roku. Hosting współdzielony szkodzi dopiero wtedy, gdy przeciążony serwer odpowiada wolno albo zwraca błędy 503.
Czy serwer musi stać w Polsce, żeby strona rankowała w Polsce?
Serwer nie musi stać w Polsce. Według Google lokalizacja serwera nie jest rozstrzygającym sygnałem geotargetowania, a silniejsze sygnały to domena .pl i hreflang.
Jaki czas odpowiedzi serwera jest dobry dla SEO?
Według web.dev dobry TTFB to 0,8 s lub mniej, a słaby to ponad 1,8 s. Google nie podaje progu średniego czasu odpowiedzi w raporcie Statystyki indeksowania, przy którym zwalnia crawlowanie.
Co się dzieje z pozycjami, gdy strona leży?
Przy błędach 5xx Google zwalnia crawlowanie, a zaindeksowane URL-e po dłuższym czasie usuwa z indeksu. Krótka przerwa oznaczona kodem 503 (1–2 dni) nie powinna zaszkodzić, ale zamknięcie strony na kilka tygodni według Google może.
Gdzie sprawdzić, czy hosting przeszkadza Googlebotowi?
Problemy hostingu z Googlebotem pokazuje raport Statystyki indeksowania w Google Search Console (Ustawienia → Statystyki indeksowania): stan hosta, średni czas odpowiedzi i odsetek odpowiedzi 5xx. Drugim źródłem są logi serwera z żądaniami zweryfikowanego Googlebota.
Członek zarządu i współwłaściciel agencji IF.PL, w SEO od ponad 20 lat (m.in. Gazeta.pl, Wirtualna Polska, Polska Press). Na bynajmniej.pl piszę z pomocą AI: temat, dane i testy są moje, AI pomaga ubrać to w słowa.
Dodaj komentarz