Naprawa błędów WordPress – jak szybko znaleźć przyczynę i bezpiecznie przywrócić stronę?

1. Pierwsza zasada jest prosta: najpierw backup, potem diagnoza. Nie odwrotnie. Jeśli masz dostęp do hostingu, zrób kopię plików i bazy danych. Jeżeli hosting oferuje punkt przywracania, sprawdź jego datę, ale nie klikaj od razu „restore”, bo możesz cofnąć też zamówienia, formularze i inne świeże dane.
2. Druga rzecz to ustalenie skali awarii. Inaczej podchodzi się do sytuacji, gdy nie działa cała witryna, a inaczej, gdy problem dotyczy tylko produktów, jednego typu podstron albo samego panelu. Jeśli masz WooCommerce, sprawdź osobno stronę główną, kartę produktu, koszyk i finalizację zamówienia. Czasem „strona działa” tylko pozornie. Znasz ten ból?
3. Trzeci krok to odróżnienie problemu aplikacji od problemu warstwy pośredniej. WordPress może być sprawny, a Ty nadal widzisz stary błąd przez cache wtyczki, cache serwera albo CDN. Dlatego po każdej zmianie czyść pamięć podręczną w WordPressie, hostingu i CDN, jeśli go używasz. Przy Cloudflare lub podobnych usługach to szczególnie ważne.

Jeśli problem pojawił się po większej zmianie, jak migracja, aktualizacja PHP albo przebudowa motywu, nie testuj wszystkiego na produkcji, jeśli tylko masz staging. W serwisach sprzedażowych nawet dobra poprawka wdrożona na żywo może chwilowo rozwalić koszyk, nagłówki cache albo reguły indeksacji. Gdy potrzebujesz później spokojnie uporządkować techniczne podstawy strony, a nie tylko gasić pożar, to często łączy się to z szerszym zakresem prac, jak tworzenie stron internetowych z sensowną architekturą i środowiskiem testowym.

Zamiast zgadywać, potraktuj awarię jak triage: objaw, najbardziej prawdopodobna przyczyna, pierwszy bezpieczny test. Ten sam objaw może wynikać z WordPressa, PHP, hostingu, cache albo CDN.

Jak włączyć WP_DEBUG i gdzie szukać logów błędów?

Jeśli nie masz logów, działasz po omacku. W pliku wp-config.php ustaw:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

To ważny układ: błędy zapisują się do logu, ale nie pokazują użytkownikom na stronie. Plik debug.log najczęściej znajdziesz w wp-content/debug.log. Równolegle sprawdź logi błędów PHP po stronie hostingu. Często są dokładniejsze niż sam WordPress i szybciej pokazują, czy problem leży w pamięci, timeoutach albo konkretnej wtyczce. Warto sprawdzić zwłaszcza memory_limit i max_execution_time — zbyt niski limit pamięci lub zbyt krótki czas wykonywania skryptu mogą prowadzić do błędów 500, białego ekranu, przerwanych aktualizacji i problemów z WooCommerce.

Czy winna jest wtyczka, motyw, PHP czy środowisko hostingu?

Objaw → diagnoza → konkretna naprawa:

• Po aktualizacji strona padła
  • Rozpoznanie: awaria pojawiła się od razu po update.
  • Potwierdzenie: log wskazuje konkretną wtyczkę, motyw albo funkcję PHP.
  • Naprawa bez kodu: jeśli działa panel, wyłącz ostatnio aktualizowaną wtyczkę.
  • Naprawa przez FTP/SSH: zmień nazwę katalogu wtyczki w wp-content/plugins.
  • Weryfikacja: sprawdź frontend, panel i czy nie pojawiły się nowe 404 lub problemy z cache.
• Biały ekran albo 500 po zmianie PHP
  • Rozpoznanie: strona przestaje działać po przełączeniu wersji PHP.
  • Potwierdzenie: log pokazuje nieobsługiwane funkcje, ostrzeżenia lub fatal error.
  • Naprawa bez kodu: wróć tymczasowo do poprzedniej wersji PHP w hostingu.
  • Naprawa techniczna: zaktualizuj motyw lub wtyczkę, która nie wspiera obecnej wersji.
  • Weryfikacja: sprawdź nie tylko stronę główną, ale też formularze, wyszukiwarkę i panel.

Tu warto trzymać jeden schemat: objaw, potwierdzenie przyczyny, konkretna naprawa, kontrola skutków ubocznych. Dzięki temu nie kończysz z „naprawionym” błędem 404 i przypadkowo zablokowaną indeksacją.

Jak naprawić 404 w WordPressie i WooCommerce: permalinki oraz .htaccess?

Objaw: podstrony, produkty lub kategorie zwracają 404, mimo że istnieją w panelu.

Diagnoza: jeśli problem dotyczy wielu adresów naraz, najpierw podejrzewaj permalinki albo .htaccess, nie pojedyncze wpisy.

Naprawa bez kodu: wejdź w Ustawienia → Bezpośrednie odnośniki i kliknij „Zapisz zmiany”, nawet bez edycji struktury. To odświeża reguły przepisywania adresów. Można odszukać za pomocą wtyczki Broken Link Checker.

Naprawa przez FTP: jeśli to nie pomaga, sprawdź plik .htaccess. Bywa uszkodzony po migracji, zmianie konfiguracji hostingu albo ręcznych modyfikacjach. Możesz tymczasowo odtworzyć domyślną wersję dla WordPressa, a potem ponownie zapisać permalinki.

Jak sprawdzić efekt: przetestuj kilka typów adresów, nie tylko jeden. W WooCommerce koniecznie: produkt, kategoria, koszyk, konto. Na koniec sprawdź w Google Search Console, czy nie rośnie liczba błędów indeksacji. Długie utrzymywanie 404 na ważnych adresach to nie „kosmetyka”, tylko realny problem SEO i sprzedażowy.

Jeśli linki są uszkodzone wewnętrznie po większych zmianach, zamiast instalować kolejną ciężką wtyczkę tylko do diagnozy, często szybciej przeskanować serwis Screaming Frog i poprawić źródło problemu, a nie objawy.

Dlaczego obrazy nie wyświetlają się po migracji: uploads, biblioteka mediów i uprawnienia 644/755?

Objaw: obrazy zniknęły po migracji, miniatury są puste albo biblioteka mediów pokazuje rekordy bez plików.

Diagnoza: sprawdź, czy wpisy mediów istnieją w bazie, a pliki faktycznie są w wp-content/uploads. To częsty rozdźwięk po niepełnej migracji: baza „pamięta” obraz, ale plik nie został przeniesiony.

Naprawa bez kodu: wyczyść cache i CDN, a następnie otwórz bezpośredni adres do pliku obrazu. Jeśli URL działa, ale miniatura nie, użyj regeneracji miniaturek. Jeśli URL nie działa, problem leży niżej.

Naprawa przez FTP/SSH: sprawdź strukturę katalogów i uprawnienia. Zwykle katalogi powinny mieć 755, a pliki 644. Jeśli uploads ma złe prawa albo właściciela, WordPress może nie odczytywać lub nie zapisywać mediów poprawnie.

Jak sprawdzić efekt: przetestuj kilka starych i nowych obrazów, także w wersji mobilnej i po odświeżeniu CDN. Dodatkowo rzuć okiem na mapę witryny obrazów i renderowanie kart produktowych. Brak obrazów to nie tylko UX, ale też spadek jakości stron kategorii i produktów.

Po migracji problem rzadko jest jeden. Często nakładają się na siebie trzy warstwy: błędne URL w bazie, brakujące pliki na serwerze i nieodświeżony cache. Dlatego nie zaczynałbym od przypadkowych zamian w bazie bez potwierdzenia, co naprawdę jest zepsute.

Objaw → diagnoza → konkretna naprawa:

• Po zmianie domeny część linków i obrazów prowadzi na stary adres
  • Potwierdzenie: w kodzie strony, bazie lub mediach nadal występuje stary URL.
  • Naprawa bezpieczniejsza: użyj Better Search Replace najpierw w trybie podglądu.
  • Uwaga: przy danych serializowanych zła zamiana potrafi uszkodzić ustawienia i widżety.
  • Weryfikacja: sprawdź kilka szablonów, menu, obrazy, canonicale i mapę witryny.
• Panel działa, ale zapis ustawień, logowanie albo koszyk nie
  • Potwierdzenie: logi wskazują błędy zapisu do bazy albo problem z tabelami.
  • Naprawa podstawowa: włącz WP_ALLOW_REPAIR w wp-config.php, uruchom naprawę, potem usuń tę stałą.
  • Naprawa ostrożna: jeśli trzeba wejść do phpMyAdmin, najpierw eksport bazy, dopiero potem ręczne działania.
  • Weryfikacja: przetestuj zapis ustawień, logowanie i proces zakupowy, bo to najszybciej ujawnia skutki uboczne.

W praktyce po migracji najbardziej mylące są awarie „częściowe”. Strona główna działa, kilka podstron też, więc właściciel uznaje, że temat jest zamknięty. Tymczasem produkty mają stare ścieżki obrazów, formularze wysyłają na zły adres, a CDN serwuje stare zasoby. Prawda?

Najprostszy model decyzji wygląda tak:

Zrób sam, jeśli:

• masz aktualną kopię zapasową strony internetowej,
• problem dotyczy pojedynczej funkcji lub grupy podstron,
• masz dostęp do panelu i rozumiesz, co zmieniasz,
• awaria nie dotyczy bazy, logowania, zamówień ani bezpieczeństwa.

Przerwij i zleć naprawę, jeśli:

• nie działa sklep, formularze leadowe albo logowanie,
• nie masz dostępu do panelu lub FTP/SSH,
• widzisz błędy bazy danych MySQL,
• problem pojawił się po migracji lub zmianie domeny i objawy są mieszane,
• podejrzewasz malware, przekierowania spamowe albo podmienione pliki,
• kolejne próby „na żywo” mogą nadpisać dane lub pogorszyć SEO.

Przy stronach firmowych i e-commerce koszt zwłoki bywa większy niż koszt szybkiej diagnozy. Jeśli potrzebujesz wsparcia przy awarii albo chcesz uporządkować stronę lub sklep po naprawie, naturalnym krokiem jest wsparcie techniczne powiązane z tworzeniem sklepów internetowych, gdzie da się od razu poprawić nie tylko błąd, ale też podstawy wydajności, cache i architektury.

Do zgłoszenia przygotuj:

• dokładny objaw,
• moment wystąpienia błędu,
• ostatnie zmiany: aktualizacja, migracja, zmiana PHP, nowa wtyczka,
• informację o backupie,
• dostępne logi lub zrzuty błędów,
• dane o tym, czy problem dotyczy wszystkich użytkowników, czy tylko części.

Masz już te informacje? Prześlij mi opis problemu, adres strony i najważniejsze objawy. Sprawdzę, czy wystarczy szybka poprawka w panelu WordPressa, czy potrzebna będzie głębsza diagnostyka przez FTP/SSH, logi serwera albo bazę danych.

A jeśli chcesz uniknąć podobnych awarii w przyszłości, mogę też przejąć stałą opiekę nad stroną: aktualizacje, kopie zapasowe, monitoring działania i bieżące poprawki techniczne.

Od czego zacząć, jeśli po aktualizacji WordPress działa tylko panel albo tylko frontend?

Najpierw sprawdź logi i włącz WP_DEBUG_LOG, bo taki podział często wskazuje na konflikt wtyczki, motywu albo problem z PHP. Potem wyłącz ostatnio aktualizowane rozszerzenia, najlepiej zaczynając od tych, które ingerują w frontend, cache lub edytor.

Co zrobić, jeśli błąd pojawia się tylko u części użytkowników, a u mnie strona działa?

Najczęściej winny jest cache, CDN albo cookies, nie sam WordPress. Sprawdź stronę w trybie incognito, na innej sieci i po wyczyszczeniu cache na wszystkich warstwach, łącznie z Cloudflare, jeśli go używasz.

Czy warto wdrażać poprawki bezpośrednio na produkcji, jeśli to mały serwis usługowy?

Tylko przy drobnych, odwracalnych zmianach i pod warunkiem, że masz świeży backup. Jeśli poprawka dotyczy motywu, bazy, przekierowań albo integracji formularzy, staging nadal jest bezpieczniejszym wyborem.

Jak sprawdzić, czy 404 szkodzi już SEO, a nie tylko pojedynczym użytkownikom?

Sprawdź raporty w Google Search Console i przeskanuj serwis Screaming Frog, żeby zobaczyć skalę problemu oraz źródła linkowania do błędnych adresów. Jeśli 404 dotyczy ważnych podstron, produktów albo stron z ruchem z Google, temat wymaga szybkiej reakcji.