Problemy z hostingiem WordPress – diagnoza, naprawa i migracja 2026

Zacznijmy od twardych faktów. Jeśli rozpoznajesz u siebie 3 lub więcej z poniższych punktów, hosting jest najpewniej wąskim gardłem Twojej strony.

• Czas ładowania powyżej 3 sekund na szybkim łączu, nawet po wyczyszczeniu cache
• TTFB (Time to First Byte) powyżej 600–800 ms mierzony w GTmetrix lub WebPageTest
• Częste błędy 500, 502, 503, 504 pojawiające się bez aktualizacji wtyczek
• Limit PHP workers osiągany w godzinach szczytu (np. 2–5 równoczesnych użytkowników i strona pada)
• Brak dostępu SSH albo dostęp tylko przez powolny panel z lat 2010
• Memory limit zablokowany na 128 MB bez możliwości podniesienia
• PHP w wersji 7.4 lub 8.0 bez opcji przełączenia na 8.2/8.3
• Brak Redis, Memcached i OPcache – albo są, ale nie działają
• Support odpowiada po 24 godzinach standardową regułką "prosimy wyczyścić cache"
• Brak codziennych backupów albo backup jest płatny ekstra 30 zł/mies

W WordPressie wolne ładowanie rzadko wynika z jednej przyczyny – zwykle to kumulacja. Ale hosting to fundament, a fundamentu nie da się naprawić wtyczką. Więcej objawów opisałem w artykule WordPress wolno się ładuje – jak naprawić oraz w przewodniku po typowych problemach z WordPress.

Jeśli rozpoznajesz 5+ z tych sygnałów, nie pytaj już "czy", tylko "gdzie się przenieść". Tracisz pieniądze codziennie.

Nie wierz na słowo hostingowi, który pisze w ofercie "bardzo szybki". Zmierz sam. Oto zestaw, którego używam przy każdym audycie:

1. GTmetrix (gtmetrix.com) – ustaw lokalizację London lub Frankfurt, przeglądarkę Chrome. Kluczowa metryka: TTFB. Poniżej 200 ms = świetnie, 200–500 ms = OK, 500–800 ms = średnio, powyżej 800 ms = problem hostingu
2. PageSpeed Insights (pagespeed.web.dev) – patrz na Server Response Time w sekcji Opportunities. Google uznaje powyżej 600 ms za problem
3. WebPageTest (webpagetest.org) – test z wielu lokalizacji, pokaże czy TTFB jest stabilny czy skacze
4. Query Monitor (wtyczka WP) – pokazuje dokładnie które zapytania SQL są wolne, ile PHP zużywa pamięci, które wtyczki obciążają najbardziej
5. New Relic / Blackfire – jeśli hosting je udostępnia, zobaczysz flame graph PHP

Benchmark TTFB dla WordPress w 2026:

Zrób pomiar 3 razy w różnych porach dnia (rano, w południe, wieczorem). Jeśli wyniki skaczą o 300%, masz do czynienia z przeciążonym serwerem współdzielonym. Więcej o diagnostyce prędkości znajdziesz w artykule jak przyspieszyć WordPress.

Hosting współdzielony (shared) to Uber Pool w świecie serwerów – dzielisz CPU, RAM i łącze z setkami innych stron. Dopóki wszystko idzie gładko, jest tanio i miło. Problem zaczyna się, gdy któryś sąsiad ma ruch z kampanii Facebook Ads albo pada ofiarą scrapera.

Najczęstsze problemy shared hostingu, z którymi się zderzysz:

• Throttling CPU – hosting ogranicza zużycie procesora po przekroczeniu limitu, strona nagle zwalnia o 500%
• Noisy neighbors – sąsiedni sklep robi wyprzedaż, Twój blog ledwo dycha
• Shared IP ban – ktoś na tym samym IP wysłał spam, Twoje maile trafiają do SPAM-u
• PHP timeout krótszy niż 30 sekund – importy WooCommerce i backupy padają w połowie
• Limit max_execution_time 30s bez możliwości zmiany – WP-CLI i długie skrypty nie działają
• Brak dostępu do php.ini – nie możesz zwiększyć upload_max_filesize ponad 8 MB
• I/O throttling – hosting tnie operacje dyskowe, co boli przy WooCommerce z tysiącami zamówień
• Inode limit – niektóre hostingi ograniczają liczbę plików do 250 000 (WordPress z dużą galerią to przebije)

Shared hosting ma sens dla bloga z 50 postami i 500 wizytami dziennie. Przy sklepie z 500 produktami albo przy wpisach, które wpadają na Wykop – shared pada. Jeśli widzisz "504 Gateway Timeout" przy imporcie produktów WooCommerce, przeczytaj 504 Gateway Timeout w WooCommerce.

Te cztery kody błędów to codzienność WordPressa na słabym hostingu. Każdy z nich oznacza coś innego i wymaga innej reakcji.

500 Internal Server Error – błąd PHP po stronie serwera. Najczęściej wtyczka, motyw albo uszkodzony .htaccess. Zacznij od zajrzenia w logi błędów PHP (`/home/user/logs/error.log` albo w panelu hostingu). Pełny przewodnik: błąd 500 w WordPress.

502 Bad Gateway – serwer PHP-FPM nie odpowiada serwerowi web (Nginx/Apache). Zwykle PHP-FPM padł przez out of memory albo za małą pulę workers. Rozwiązanie po stronie hostingu.

503 Service Unavailable – serwer celowo odrzuca połączenia. Może oznaczać:
- Tryb maintenance (plik `.maintenance` w katalogu WP)
- Osiągnięty limit PHP workers
- Fail2ban zablokował IP za zbyt wiele prób
- Hosting ręcznie zablokował Cię za naruszenie TOS

504 Gateway Timeout – skrypt PHP wykonuje się dłużej niż max_execution_time. Typowe przy imporcie, eksporcie, generowaniu PDF. Zwiększ limit w `wp-config.php` lub `.htaccess`.

Jak je rozróżnić w praktyce:

Jeśli po aktualizacji nagle pojawił się biały ekran śmierci albo WordPress padł po aktualizacji, przyczyna jest zwykle inna niż hosting, ale warto wykluczyć.

Domyślne 128 MB memory limit wystarczy prostemu blogowi, ale WooCommerce z WPML, Elementor Pro i zestawem 20 wtyczek potrzebuje 512 MB–1 GB. Objawy niedoboru: biały ekran, komunikat "Allowed memory size of X bytes exhausted", sporadyczne 500-tki pod obciążeniem.

Jak sprawdzić ile masz:
1. W wp-admin → Narzędzia → Stan witryny → Informacje → Serwer. Znajdź "Limit pamięci PHP"
2. Albo stwórz plik `info.php` z `` i otwórz w przeglądarce (usuń go po sprawdzeniu!)

Jak zwiększyć memory limit:

Dodaj do `wp-config.php` (przed linijką "That's all, stop editing"):

define('WP_MEMORY_LIMIT', '512M');
define('WP_MAX_MEMORY_LIMIT', '1024M');

Jeśli hosting na to nie pozwala, edytuj `.htaccess`:

php_value memory_limit 512M
php_value max_execution_time 300
php_value upload_max_filesize 64M
php_value post_max_size 64M

Na niektórych hostingach `.htaccess` jest ignorowany – wtedy zmiana musi być w panelu albo w `php.ini` w katalogu strony.

PHP timeout (max_execution_time): domyślnie 30 s. Dla importów WooCommerce, aktualizacji tłumaczeń WPML, wsadowej optymalizacji obrazów potrzeba 300–600 s. Szczegóły w artykule PHP memory limit w WordPress.

Jeśli hosting nie pozwala zwiększyć memory limitu powyżej 256 MB ani PHP timeout powyżej 60 s – to jasny sygnał, że wyrosłeś z tej oferty.

Wybór typu hostingu to nie kwestia ceny, tylko skali i kompetencji. Jeden typ nie pasuje do każdego sklepu.

Kiedy shared wystarczy:
- Blog do 10 000 wizyt/mies
- Wizytówka firmowa, portfolio
- Landing page, strona jednorazowa
- Budżet poniżej 30 zł/mies

Kiedy potrzebujesz VPS:
- Sklep WooCommerce z 500+ produktami albo 100+ zamówieniami/dzień
- Strona z regularnym ruchem 50 000+ wizyt/mies
- Aplikacja WordPress z customowymi rozwiązaniami (REST API, headless)
- Potrzebujesz Redis, Elasticsearch, własnego SSL, dedykowanego IP

Kiedy managed WordPress:
- Nie masz czasu/kompetencji administracyjnych
- Potrzebujesz staging environment jednym klikiem
- Wartość Twojego czasu >300 zł/h – oszczędzaj go na biznesie

Case study: klient ze sklepem 5000 produktów na shared za 25 zł/mies – checkout odrzucał karty w 20% przypadków przez 503. Migracja na VPS za 120 zł/mies dała TTFB 180 ms (poprzednio 1400 ms) i 0 odrzuconych transakcji. ROI: 2 tygodnie.

Testowałem w tym roku osiem polskich hostingów pod kątem WordPressa i trzy zagraniczne. Unikaj niektórych najpopularniejszych – wolne, drogie, z oporem w supporcie. Poniżej moja prywatna krótka lista.

Moja rekomendacja #1: CyberFolks – najlepszy stosunek ceny do wydajności na polskim rynku w 2026. LiteSpeed + LSCache + Redis w cenie już od 15 zł/mies, polski support odpowiada w 15 minut, codzienne backupy gratis, PHP 8.3. Przeniosłem tam ponad 60 klientów, żaden nie wrócił.

LH.pl – solidna alternatywa jeśli potrzebujesz konsoli WHM, dobrego cPanela i obsługi e-commerce od strony księgowej (VAT, faktury proforma).

Zenbox – OK dla blogów, ale brak LiteSpeed jest czuć przy WooCommerce.

Kinsta / WP Engine – klasa premium. Jeśli masz sklep z obrotem powyżej 100 tys. zł/mies i nie chcesz myśleć o adminie, warto. Dla małych biznesów przesada.

Czego unikać: popularne polskie hostingi z marketingiem "numer 1 w Polsce" kosztują 40–80 zł/mies za plan, który u CyberFolks dostaniesz za 15 zł. Gorszy support, gorsza wydajność, gorsze backupy. Nie polecam – klienci wracają do mnie po roku na migrację.

Pełna analiza w artykule najlepszy hosting WordPress 2026. Jeśli prowadzisz sklep, zobacz też hosting WooCommerce – co wybrać.

Dobrze zaplanowana migracja to 0 sekund downtime dla użytkownika i 0 utraconych zamówień. Oto sprawdzona procedura, którą stosuję przy migracjach sklepów.

Krok 1: Przygotowanie (1–2 dni przed)
- Obniż TTL DNS dla domeny do 300 s (normalnie 3600–86400)
- Zrób pełny backup: pliki + baza danych (narzędzie w panelu starego hostingu)
- Wyłącz cache WordPress i CDN na czas migracji

Krok 2: Kopia na nowy hosting

Trzy metody do wyboru:
1. Duplicator Pro (69 USD/rok) – pakuje całą stronę w jeden plik, deploy w 10 minut. Najprościej.
2. All-in-One WP Migration (Unlimited Extension 59 USD) – darmowa wersja ma limit 512 MB, płatna zdejmuje limit
3. Ręczna migracja – rsync plików + mysqldump bazy. Najbardziej kontrolowana, wymaga SSH

Krok 3: Test na nowym hostingu
- Dodaj wpis w pliku `hosts` na swoim komputerze (mapowanie domeny na nowy IP)
- Sprawdź czy strona działa, formularz kontaktowy wysyła maile, checkout WooCommerce przechodzi
- Przetestuj logowanie do wp-admin, zapis wpisu, upload obrazka

Krok 4: Przełączenie DNS
- W panelu DNS zmień A record na nowy IP
- Dzięki niskiemu TTL zmiana zajmie 5–15 minut
- Monitoruj ruch w GA4 – jeśli spada, coś poszło nie tak

Krok 5: Po migracji
- Wyczyść cache Cloudflare i WP
- Zainstaluj Cloudflare w WordPress jeśli jeszcze nie masz
- Skonfiguruj LiteSpeed Cache lub WP Rocket
- Po 48 h od migracji wyłącz stary hosting, ale nie kasuj plików przez 7 dni

Czas całkowity: 2–4 godziny dla średniej strony, 6–10 godzin dla sklepu z 1000+ produktami. Bez utraty ruchu, bez spadku pozycji w Google, bez utraconych zamówień – jeśli zrobisz to według tej checklisty.

Jeśli wolisz, żebym zmigrował stronę za Ciebie – zadzwoń +48 604 939 140 lub napisz przez /kontakt/. Migracja standardowej strony: 300 zł, sklepu: 600–1200 zł.

Zanim zdecydujesz się na migrację, wyciśnij z obecnego hostingu wszystko co się da. Czasem 30 minut optymalizacji załatwia problem na rok.

Quick wins (w kolejności skuteczności):

1. Włącz OPcache – wbudowany cache bytecode PHP. Skraca TTFB o 30–50%. Sprawdź w phpinfo, ustaw w panelu hostingu jeśli wyłączony
2. Redis Object Cache – zamiast trzymać opcje WordPressa w bazie, trzymaj w RAM. Wymaga wsparcia hostingu + wtyczki Redis Object Cache. Zmniejsza liczbę zapytań SQL o 60–90%
3. LiteSpeed Cache (jeśli masz LiteSpeed Web Server) – pełny page cache na poziomie serwera, nie PHP. Najszybsze rozwiązanie cache dla WordPress. Zobacz konfigurację LiteSpeed Cache
4. WP Rocket (jeśli Apache/Nginx bez LiteSpeed) – płatny (59 USD/rok), ale najłatwiejszy w konfiguracji
5. Cloudflare CDN + Cache Everything – darmowa warstwa CDN, obsługuje 80% ruchu bez trafiania do hostingu
6. PHP 8.3 – jeśli hosting oferuje, przełącz z PHP 7.4 lub 8.0. Zysk 20–40% wydajności za darmo
7. Wyłącz Heartbeat API w wp-admin (Heartbeat Control plugin) – zmniejsza zużycie CPU przy otwartym panelu
8. Limit Post Revisions – `define('WP_POST_REVISIONS', 5);` w wp-config.php. Redukuje rozmiar bazy
9. Optymalizacja obrazów – konwersja do WebP (ShortPixel, Imagify), lazy loading. Mniej transferu, mniej obciążenia hostingu
10. Czyszczenie bazy – WP-Optimize albo ręczne `DELETE FROM wp_options WHERE option_name LIKE '\_transient\_%'`

Jeśli po wprowadzeniu wszystkich tych zmian TTFB nadal jest powyżej 800 ms – hosting jest winny. Migruj.

Zanim wydasz pieniądze na migrację, upewnij się, że nie strzelasz do złego celu. W 30% przypadków "wolny hosting" to tak naprawdę jedna z poniższych przyczyn.

1. Zbyt wiele wtyczek (zwłaszcza ciężkich)
40+ aktywnych wtyczek to norma, którą widzę przy audytach. Każda dokłada ms do ładowania. Użyj Query Monitor, zobacz które są najcięższe, wyłącz te używane raz w miesiącu.

2. Motyw z Theme Forest
Avada, BeTheme, Bridge i podobne ładują 2–5 MB CSS/JS na każdej stronie. Zastąp lżejszym motywem (GeneratePress, Astra, Blocksy) albo rozważ migrację z Avady.

3. Nieoptymalizowane obrazy
Zdjęcie produktowe 4000x3000 px ważące 3 MB serwowane bez kompresji – to nie hosting, to Ty. Konwertuj do WebP, kompresuj przez ShortPixel.

4. Brak cache
WordPress bez cache generuje HTML od nowa przy każdym odwiedzeniu. To jak gotowanie nowego obiadu dla każdego klienta restauracji. Włącz WP Rocket albo LiteSpeed Cache.

5. Malware lub nieproszone skrypty
Czasem strona jest wolna, bo złośliwy skrypt wysyła spam w tle. Przeskanuj Wordfence lub Sucuri. Objaw: zużycie CPU skacze w nocy, gdy nikt nie odwiedza strony.

Jak to sprawdzić w 10 minut:
- Zainstaluj Query Monitor i zobacz co zabiera czas ładowania
- Uruchom wp-admin w trybie incognito – jeśli tam jest szybko, problem w motywie/wtyczkach front-endu
- Wyłącz wszystkie wtyczki, włączaj po kolei, obserwuj TTFB

Jeśli po wszystkich optymalizacjach TTFB nadal powyżej 800 ms – dopiero wtedy migruj. Dobry hosting to fundament, ale nie magiczny eliksir. Napisz przez /kontakt/ albo zadzwoń +48 604 939 140 – zrobię Ci audyt wydajności za darmo, powiem co naprawdę spowalnia stronę.