Hosting a SEO: jak serwer wpływa na szybkość, dostępność i indeksowanie strony

Jak hosting wpływa na SEO

Hosting wpływa na SEO pośrednio: Google nie ocenia nazwy ani ceny usługi, tylko to, jak strona zachowuje się wobec użytkowników i robotów. Liczą się trzy rzeczy, czyli szybkość odpowiedzi, dostępność oraz możliwość sprawnego pobierania podstron przez robota.

Pierwsza droga to szybkość. Google podaje w dokumentacji poświęconej jakości strony, że jego systemy rankingowe korzystają z podstawowych wskaźników internetowych (Core Web Vitals), czyli pomiarów wczytywania, reakcji na działania i stabilności układu. Serwer nie jest jedynym składnikiem tych wyników, ale jest pierwszym: zanim przeglądarka zacznie cokolwiek rysować, musi dostać odpowiedź. Szerzej opisujemy to we wpisie o tym, ile szybkość strony znaczy w rankingu.

Druga droga to dostępność. Strona, która w chwili wizyty robota zwraca błąd serwera, nie zostanie pobrana, a przy powtarzających się błędach wyszukiwarka ogranicza liczbę odwiedzin. Trzecia droga to wydajność indeksowania: Google dopasowuje liczbę żądań do tego, ile serwer jest w stanie znieść, więc słaba maszyna oznacza wolniejsze odświeżanie treści w wynikach.

Trzeba przy tym zachować proporcje. Ta sama dokumentacja zaznacza, że dobre wyniki podstawowych wskaźników nie gwarantują wysokich pozycji, a wyszukiwarka stara się pokazać najtrafniejszą treść nawet wtedy, gdy jakość strony jest poniżej normy. Jakość strony ma największe znaczenie wtedy, gdy o to samo zapytanie konkuruje wiele przydatnych stron. Dobry serwer jest więc warunkiem, żeby praca nad treścią i SEO techniczne mogły przynieść skutek, a nie skrótem do pierwszej pozycji.

Rodzaje hostingu i ich wpływ na czas odpowiedzi oraz stabilność

Rodzaje hostingu różnią się przede wszystkim tym, z kim strona dzieli zasoby maszyny i kto odpowiada za jej konfigurację. Od tego zależy, czy czas odpowiedzi jest przewidywalny, czy zmienia się wraz z ruchem na cudzych stronach.

Hosting współdzielony

Na hostingu współdzielonym wiele kont korzysta z tego samego serwera, tych samych procesorów i tej samej pamięci. Usługodawca nakłada na każde konto limity, żeby jedna strona nie zabrała mocy pozostałym. Serwis web.dev w tekście o skracaniu czasu do pierwszego bajtu stwierdza wprost, że hosting współdzielony jest zwykle wolniejszy, ale zastrzega, że dla małej witryny złożonej głównie z plików statycznych może to nie mieć znaczenia. Wizytówka kancelarii z Krakowa z kilkunastoma podstronami zwykle działa na takim koncie poprawnie.

Serwer VPS

VPS, czyli wirtualny serwer prywatny, to wydzielona część fizycznej maszyny z przypisaną liczbą rdzeni procesora, pamięcią i dyskiem. Zasoby są zarezerwowane dla jednego klienta, więc ruch na sąsiednich serwerach wpływa na stronę w znacznie mniejszym stopniu. W zamian pojawia się obowiązek administracji: aktualizacje systemu, konfiguracja serwera WWW i bazy danych, zabezpieczenia. Usługodawcy oferują wersje zarządzane, w których te prace wykonuje ich zespół.

Serwer dedykowany

Serwer dedykowany to cała fizyczna maszyna do dyspozycji jednego klienta. Daje pełną kontrolę nad konfiguracją i najwięcej mocy, ale wymaga administratora, a rozbudowa oznacza wymianę podzespołów lub przenosiny na inną maszynę. Sama nazwa nie przesądza o wyniku: web.dev zwraca uwagę, że jeśli długi czas odpowiedzi utrzymuje się także u dostawcy serwerów dedykowanych, warto ponownie ocenić jego możliwości.

Chmura

W chmurze strona korzysta z zasobów rozłożonych na wiele maszyn, a ich ilość można zwiększać i zmniejszać wraz z ruchem. To rozwiązanie dla serwisów o zmiennym obciążeniu, na przykład sklepu z Poznania, który przez większość miesięcy ma spokojny ruch, a przed świętami kilkukrotnie większy. Ceną jest bardziej złożona konfiguracja i rozliczenie zależne od zużycia.

Wybór nie powinien wynikać z samej nazwy pakietu. Dobrze utrzymane konto współdzielone bywa szybsze od źle skonfigurowanego serwera wirtualnego, dlatego ważniejsze od etykiety są konkretne parametry opisane w dalszej części oraz pomiary na własnej stronie.

Serwer a szybkość strony: czas do pierwszego bajtu

Wpływ serwera na szybkość mierzy się przede wszystkim wskaźnikiem TTFB (Time to First Byte), czyli czasem do pierwszego bajtu. Według opisu w serwisie web.dev jest to czas od wysłania żądania do chwili, gdy do przeglądarki zaczynają napływać pierwsze bajty odpowiedzi.

Web.dev podaje orientacyjne progi: wynik 0,8 sekundy lub mniej uznaje się za dobry, przedział od 0,8 do 1,8 sekundy wymaga poprawy, a wynik powyżej 1,8 sekundy jest słaby. Ten sam tekst zaznacza, że TTFB nie należy do podstawowych wskaźników internetowych. Jest wskaźnikiem pomocniczym: długie oczekiwanie na odpowiedź przesuwa w czasie wszystko, co następuje później, w tym wyświetlenie największego elementu strony, czyli LCP. Osobno omawiamy przyczyny długiego TTFB i sposoby jego skrócenia.

Na czas odpowiedzi składa się kilka rzeczy zależnych od hostingu. Pierwsza to moc obliczeniowa i pamięć: strona oparta na systemie zarządzania treścią przy każdym wejściu uruchamia kod i pyta bazę danych, a im mniej zasobów dostaje konto, tym dłużej to trwa. Dokumentacja narzędzia Lighthouse w części o skróceniu czasu odpowiedzi serwera wymienia trzy kierunki poprawy: usprawnienie logiki aplikacji, lepsze zapytania do bazy danych oraz rozbudowę sprzętu o dodatkową pamięć lub procesory. Audyt w Lighthouse kończy się niepowodzeniem, gdy przeglądarka czeka na odpowiedź na żądanie głównego dokumentu dłużej niż 600 ms.

Druga rzecz to oprogramowanie serwera. Web.dev przypomina, że nowsze wersje języków programowania, obsługi protokołu HTTP i baz danych przynoszą z czasem poprawę wydajności, dlatego warto pytać usługodawcę, jak dba o aktualność tego zaplecza i czy pozwala zmieniać konfigurację. W przypadku WordPressa znaczenie ma też sama strona: liczba i jakość wtyczek oraz motyw.

Trzecia rzecz to odległość. Nawet dobrze przygotowany serwer odpowiada wolniej osobom, które łączą się z daleka. Rozwiązaniem jest sieć dostarczania treści, w skrócie CDN (Content Delivery Network), która przechowuje kopie zasobów na serwerach położonych bliżej odbiorców. Według web.dev takie sieci zwykle zapewniają także nowsze protokoły HTTP/2 i HTTP/3, aktualne wersje szyfrowania TLS oraz kompresję.

Serwer a dostępność i indeksowanie strony przez Google

Niestabilny serwer ogranicza indeksowanie: roboty Google odwiedzają stronę rzadziej, gdy odpowiada ona wolno lub zwraca błędy, a adresy, które stale zwracają błąd, z czasem znikają z wyników. Wynika to z kilku opisanych przez Google mechanizmów.

Błędy serwera i kod 429

Dokumentacja o tym, jak kody stanu HTTP wpływają na roboty Google, podaje, że błędy serwera z grupy 5xx oraz kod 429 informują roboty, że na jakiś czas należy zwolnić indeksowanie. Kod 429 jest traktowany jako sygnał przeciążenia serwera. Spadek szybkości indeksowania jest proporcjonalny do liczby adresów, które zwracają błąd. Adresy już zindeksowane początkowo pozostają w indeksie, ale te, które stale odpowiadają błędem serwera, są z niego usuwane. Gdy serwer znów zaczyna odpowiadać poprawnie, Google stopniowo zwiększa szybkość indeksowania.

Największym problemem są więc błędy powtarzające się, na przykład codziennie w godzinach szczytu, gdy konto wyczerpuje przydzielone zasoby.

Limit wydajności indeksowania

W tekście o zarządzaniu budżetem indeksowania Google opisuje limit wydajności indeksowania, nazywany też obciążeniem hosta. Robot oblicza go po to, żeby nie przeciążać serwerów. Jeżeli witryna przez pewien czas odpowiada szybko, limit rośnie, a gdy czas reakcji się wydłuża lub pojawiają się błędy serwera, limit maleje i Google pobiera mniej stron. Dokument wspomina też o komunikacie o przekroczeniu limitu obciążenia hosta w narzędziu do sprawdzania adresów URL i zaleca wtedy rozważenie zwiększenia zasobów serwera.

Google zastrzega, że ten dokument jest przeznaczony głównie dla dużych witryn, mających ponad milion unikalnych stron ze zmianami raz w tygodniu, oraz średnich i większych, mających ponad 10 tys. stron zmienianych codziennie, a podane liczby są szacunkowe. Mała strona usługowa nie musi zajmować się budżetem indeksowania. Dla dużego sklepu z tysiącami produktów wydajność serwera decyduje jednak o tym, jak szybko zmiany cen i dostępności trafią do wyników.

Plik robots.txt podczas awarii

Szczególne znaczenie ma dostępność pliku robots.txt. Z pomocy Search Console wynika, że jeśli Google nie dostaje prawidłowej odpowiedzi na żądanie tego pliku, zwalnia lub wstrzymuje indeksowanie witryny. Za prawidłowe uznaje odpowiedzi 200, 403, 404 i 410, a za nieprawidłowe kod 429 oraz błędy 5xx. Przy niepowodzeniu przez pierwsze 12 godzin indeksowanie jest wstrzymane, a robot ponawia próby pobrania pliku; później, do 30 dni, korzysta z ostatniej zapisanej wersji. Awaria serwera dotyka więc całej witryny, a nie pojedynczych podstron. O samym pliku piszemy we wpisie o tym, jak napisać robots.txt bez blokowania ważnych podstron.

Jeśli chcą Państwo zamówić SEO techniczne, zachęcamy do kontaktu: tel. 222 500 844 lub mailowo: biuro@pozycjonowaniestron.pl

Na co patrzeć w ofercie hostingu

W ofercie hostingu warto patrzeć na pięć obszarów: moc obliczeniową i pamięć, limity nałożone na konto, wersje oprogramowania, miejsce serwerowni oraz kopie zapasowe. Pojemność dysku i liczba skrzynek pocztowych, zwykle eksponowane na pierwszym miejscu, mają dla widoczności strony najmniejsze znaczenie.

Procesory i pamięć

Od procesora i pamięci zależy, jak szybko serwer przygotuje stronę i ile wejść obsłuży jednocześnie. Web.dev radzi zwrócić uwagę na ilość pamięci przydzielonej usłudze, ponieważ zbyt mała powoduje niestabilność. W ofercie warto szukać informacji, czy rdzenie i pamięć są gwarantowane dla konta, czy współdzielone z innymi klientami. Zapis o nielimitowanych zasobach wymaga lektury regulaminu, bo ograniczenia zwykle są opisane właśnie tam.

Limity konta

Limity decydują o tym, co stanie się w chwili większego ruchu. Z naszej praktyki wynika, że na kontach współdzielonych najczęściej spotyka się ograniczenia czasu procesora, pamięci dla jednego procesu, liczby procesów działających jednocześnie, liczby plików oraz miesięcznego transferu. Po przekroczeniu limitu serwer odpowiada wolniej albo zwraca błąd, a właśnie takie odpowiedzi skłaniają roboty Google do ograniczenia indeksowania. Przed zakupem dobrze jest ustalić, czy panel pokazuje bieżące zużycie zasobów.

Wersja PHP i bazy danych

Hosting powinien oferować aktualne wersje PHP i bazy danych oraz pozwalać na ich samodzielną zmianę. Na stronie z wymaganiami WordPressa zalecane są PHP w wersji 8.3 lub nowszej, MySQL 8.0 lub nowszy albo MariaDB 10.11 lub nowsza oraz obsługa HTTPS. WordPress uruchomi się także na starszych wersjach, ale twórcy zaznaczają, że zakończono już ich oficjalne wsparcie i mogą one narażać stronę na luki bezpieczeństwa.

Lokalizacja serwerowni

Serwerownia powinna znajdować się możliwie blisko odbiorców strony, przede wszystkim ze względu na czas odpowiedzi. Web.dev wskazuje, że osoby znajdujące się daleko od serwera mogą doświadczać długiego TTFB mimo dobrze przygotowanego zaplecza. Dla firmy obsługującej klientów w Polsce naturalnym wyborem jest serwerownia w kraju lub w sąsiednich państwach.

Miejsce serwera ma też niewielkie znaczenie dla rozpoznawania, do kogo strona jest skierowana. W dokumentacji o witrynach multiregionalnych i wielojęzycznych Google wymienia lokalizację serwera, ustalaną na podstawie adresu IP, wśród sygnałów kierowania geograficznego, ale zastrzega, że nie jest to sygnał rozstrzygający, ponieważ wiele witryn korzysta z sieci CDN albo z serwerów w krajach o lepszej infrastrukturze. Większą wagę mają domena krajowa, oznaczenia hreflang, lokalny adres i telefon oraz język. Firmom wychodzącym za granicę więcej daje więc dobrze zaplanowane pozycjonowanie zagraniczne niż sama zmiana serwerowni.

Kopie zapasowe

Kopie zapasowe decydują o tym, jak długo strona będzie niedostępna po awarii, błędnej aktualizacji lub włamaniu. W ofercie warto ustalić, jak często kopie są wykonywane, przez ile dni są przechowywane, czy leżą na innej maszynie niż strona, czy obejmują pliki i bazę danych oraz czy przywrócenie można wykonać samodzielnie z panelu. Im szybciej strona wraca do działania, tym krócej roboty i klienci trafiają na błąd.

• Rdzenie procesora i pamięć gwarantowane dla konta, a nie tylko deklarowane jako maksimum.
• Jasno opisane limity procesów, pamięci, plików i transferu oraz podgląd zużycia w panelu.
• Aktualne wersje PHP i bazy danych z możliwością samodzielnej zmiany.
• Certyfikat SSL i obsługa HTTPS w każdym pakiecie.
• Serwerownia blisko odbiorców strony.
• Codzienne kopie zapasowe przechowywane poza serwerem, z samodzielnym przywracaniem.
• Dostęp do dzienników serwera i możliwość przejścia na wyższy pakiet bez przenoszenia strony.

Na tej liście celowo nie ma ceny. Oferty warto porównywać parametrami, a nie kwotą, bo jeden dzień bez zamówień w sklepie bywa droższy niż różnica między pakietami.

Gdzie sprawdzić, jak radzi sobie obecny serwer

Pracę serwera najłatwiej ocenić w dwóch narzędziach Google dostępnych bez opłat: w PageSpeed Insights, które pokazuje czas odpowiedzi widziany przez użytkowników, oraz w raporcie Statystyki indeksowania w Search Console, który pokazuje serwer oczami robota.

PageSpeed Insights

Na stronie pagespeed.web.dev wystarczy wpisać adres podstrony w jedyne pole formularza i uruchomić analizę. Narzędzie pokazuje między innymi czas do pierwszego bajtu oraz informację o czasie odpowiedzi serwera na żądanie dokumentu. Warto zbadać kilka typów podstron: stronę główną, kategorię, produkt lub usługę oraz wpis na blogu, ponieważ każda z nich inaczej obciąża bazę danych. Sposób czytania wyników wyjaśniamy we wpisie o tym, jak czytać raport PageSpeed Insights.

Raport Statystyki indeksowania w Search Console

Raport znajduje się w Search Console pod ścieżką: Ustawienia, a następnie Statystyki indeksowania. Jest dostępny dla usług najwyższego poziomu, czyli całej domeny lub adresu głównego. Pomoc Google zaznacza, że to raport dla zaawansowanych użytkowników i że witryny mające mniej niż 1000 stron zwykle nie potrzebują tak szczegółowych danych, ale przy podejrzeniu kłopotów z hostingiem warto do niego zajrzeć niezależnie od wielkości serwisu.

Na górze widać trzy wykresy: Łączna liczba żądań robota indeksującego, Całkowity rozmiar pobierania oraz Średni czas odpowiedzi. Rosnący średni czas odpowiedzi przy malejącej liczbie żądań to typowy obraz serwera, który przestaje nadążać. Poniżej znajduje się sekcja Stan hosta z trzema kategoriami: Pobieranie pliku robots.txt, Rozpoznawanie nazw DNS oraz Połączenie z serwerem. Każda ma wykres z czerwoną przerywaną linią; jej przekroczenie oznacza problem w danej kategorii. Stan obejmuje ostatnie 90 dni.

Trzecim miejscem jest tabela odpowiedzi na żądania. Odpowiedzi 200, przekierowania i kod 304 są uznawane za prawidłowe, natomiast błędy 5xx, błędy DNS i przekroczenia czasu oczekiwania należą do grupy wymagającej naprawy.

Jak rozpoznać, że strona wyrosła ze swojego serwera

Strona wyrosła ze swojego serwera, gdy mimo uporządkowanej witryny czas odpowiedzi rośnie wraz z ruchem, a błędy pojawiają się w powtarzalnych porach. Pojedynczy słaby pomiar o niczym nie świadczy; znaczenie ma wzór, który wraca.

Pierwszym objawem jest zależność szybkości od pory dnia. Strona hydraulika z Łodzi rano otwiera się sprawnie, a wieczorem, gdy rośnie ruch na całej maszynie, na odpowiedź czeka się wyraźnie dłużej. Drugim objawem są błędy 5xx w tabeli odpowiedzi w Search Console lub w dziennikach serwera, pojawiające się podczas kampanii reklamowej, wysyłki newslettera albo wyprzedaży. Trzecim jest powolny panel administracyjny: zapisanie produktu lub wpisu trwa długo, ponieważ te operacje omijają pamięć podręczną i pokazują rzeczywistą wydajność zaplecza.

Kolejne sygnały przychodzą od usługodawcy i z wyszukiwarki. Powiadomienia o przekroczeniu limitów konta oznaczają, że pakiet jest za mały. Po stronie Google widać to jako spadek liczby żądań robota przy rosnącym średnim czasie odpowiedzi, a w dużych serwisach także jako wolniejsze pojawianie się nowych podstron w indeksie. Inne przyczyny tego objawu opisujemy we wpisie o tym, dlaczego Google nie indeksuje strony.

Zmiana hostingu bez szkody dla widoczności

Zmiana hostingu przy zachowaniu tych samych adresów jest dla wyszukiwarki operacją bezpieczną, o ile nowy serwer jest sprawdzony przed przełączeniem, a robot ma do niego dostęp. Google opisuje kolejność prac w dokumentacji o zmianie hostingu internetowego.

1. Przygotowanie i test nowego serwera

   Kopię witryny umieszcza się na nowym serwerze i sprawdza w środowisku testowym, na przykład pod tymczasową nazwą hosta. Strony testowe powinny mieć regułę noindex, żeby nie trafiły do indeksu.

2. Sprawdzenie dostępu robota

   Narzędzie do sprawdzania adresów URL w Search Console pozwala potwierdzić, że Googlebot pobiera strony z nowej infrastruktury. Zapora i ochrona przed atakami nie mogą blokować robota.

3. Skrócenie czasu TTL w DNS

   Google zaleca obniżenie wartości TTL rekordów DNS do kilku godzin co najmniej tydzień przed przeniesieniem, dzięki czemu zmiana adresu rozejdzie się szybciej.

4. Usunięcie tymczasowych blokad i przełączenie

   Przed przełączeniem usuwa się reguły w robots.txt i znaczniki noindex założone na czas testów, po czym rekordy DNS kieruje się na nowy serwer.

5. Obserwacja ruchu i wyłączenie starego serwera

   Dzienniki obu serwerów pokazują, jak ruch przenosi się na nową maszynę. Stary serwer wyłącza się dopiero wtedy, gdy przestają do niego trafiać żądania.

Po przełączeniu szybkość indeksowania może się wahać. Google uprzedza, że chwilowy spadek tuż po uruchomieniu nowej infrastruktury jest zjawiskiem normalnym, a po nim zwykle następuje kilkudniowy wzrost, nawet powyżej poziomu sprzed zmiany.

Przenosiny warto planować na okres najmniejszego ruchu i nie łączyć ich ze zmianą adresów, szablonu ani struktury serwisu. Gdy zmienia się wszystko naraz, trudno ustalić przyczynę ewentualnego spadku. Szerszy plan takich prac zawiera wpis o migracji strony bez utraty pozycji, a samą operację można powierzyć nam w ramach usługi migracji domeny i hostingu.

Typowe pomyłki przy wyborze serwera i kiedy potrzebna jest pomoc

Najczęstsza pomyłka polega na wyborze hostingu według ceny i pojemności dysku, bez sprawdzenia zasobów, limitów i wersji oprogramowania. Pozostałe błędy są do niej podobne: dotyczą oceniania serwera po jednym parametrze albo po jednym pomiarze.

Częstym nieporozumieniem jest przekonanie, że zmiana serwera sama podniesie pozycje. Szybszy hosting usuwa przeszkodę, ale nie zastąpi trafnej treści. Odwrotna pomyłka to tłumaczenie każdego spadku widoczności winą hostingu, mimo że raport Statystyki indeksowania nie pokazuje ani błędów, ani wydłużonego czasu odpowiedzi.

Kolejny błąd to ocenianie serwera po stronie głównej. Ta podstrona zwykle jest w pamięci podręcznej, więc odpowiada szybko, podczas gdy kategorie z filtrami czy koszyk czekają na pełne przetworzenie.

Zdarza się też blokowanie robotów na poziomie serwera. Zbyt ostro ustawiona zapora potrafi odpowiadać Googlebotowi kodem 429 lub błędem 5xx, czego właściciel strony nie widzi w przeglądarce. Pomoc Search Console dopuszcza zwracanie kodu 503 lub 429 jako doraźny sposób na przeciążenie, ale ostrzega, że nie należy robić tego dłużej niż dwa lub trzy dni, ponieważ może to trwale ograniczyć indeksowanie.

Ostatnia grupa pomyłek dotyczy przenosin: wyłączenie starego serwera zaraz po zmianie rekordów DNS, pozostawienie znacznika noindex z wersji testowej albo brak certyfikatu SSL na nowej maszynie. Kwestie szyfrowania omawiamy przy okazji przejścia z HTTP na HTTPS.

Pomoc z zewnątrz jest potrzebna wtedy, gdy nie udaje się ustalić, czy winny jest serwer, czy sama strona, gdy błędy 5xx wracają mimo zmiany pakietu albo gdy planowana jest przeprowadzka dużego serwisu. Punktem wyjścia jest wtedy audyt SEO z analizą dzienników serwera i raportów Search Console, który pokazuje, co należy poprawić na stronie, a co po stronie hostingu.

Jeśli chcą Państwo zamówić SEO techniczne, zachęcamy do kontaktu: tel. 222 500 844 lub mailowo: biuro@pozycjonowaniestron.pl