Lead
Jeśli po migracji WordPress zamiast strony widzisz serię błędów 404, problem zwykle nie leży w jednym miejscu. Najczęściej psują się permalinki, reguły serwera, przekierowania, adresy zapisane w bazie danych albo ścieżki do zasobów. Efekt jest bolesny: użytkownicy nie mogą wejść na podstrony, Google zaczyna rejestrować błędy, a ruch organiczny potrafi spaść jeszcze tego samego dnia.
Dobra wiadomość jest taka, że w większości przypadków 404 po migracji WordPress da się naprawić bez stawiania wszystkiego od zera. Trzeba jednak działać po kolei: najpierw ustalić, czy problem dotyczy całej witryny, czy tylko części adresów, potem sprawdzić konfigurację WordPressa, serwera i bazy danych, a dopiero na końcu szukać mniej oczywistych przyczyn, takich jak cache, CDN, zmiany domeny czy stare reguły przekierowań.
Szybka odpowiedź
Najkrótsza diagnoza brzmi: 404 po migracji WordPress najczęściej oznacza uszkodzone reguły adresowania, a nie faktyczny brak plików. Zacznij od tych trzech kroków:
- Wejdź w Ustawienia > Bezpośrednie odnośniki i zapisz ustawienia ponownie, bez zmiany czegokolwiek.
- Sprawdź, czy domena w WordPressie i w bazie danych wskazuje na właściwy adres oraz czy strona nie działa na starej ścieżce.
- Zweryfikuj plik .htaccess albo konfigurację nginx, a potem wyczyść cache WordPressa, przeglądarki i CDN.
Jeżeli po tych działaniach 404 nadal występują, przyczyna często leży w migracji bazy danych, błędnych przekierowaniach, konflikcie wtyczek albo różnicach między serwerem źródłowym i docelowym.
Diagnoza problemu
Warto od razu rozróżnić dwa scenariusze. Pierwszy: cała strona zwraca 404 po migracji. Drugi: 404 dotyczą tylko wybranych adresów, na przykład wpisów blogowych, kategorii, produktów WooCommerce lub stron mediów. Każdy z nich wskazuje na inny typ błędu.
Jeżeli 404 widzisz wszędzie, winne mogą być reguły serwera, brak właściwego pliku konfiguracyjnego lub źle ustawiona domena, przez co WordPress generuje linki prowadzące do nieistniejącej lokalizacji. Jeśli 404 pojawiają się tylko na części adresów, zwykle problem dotyczy permalinków, struktury linków, błędnych przekierowań, migracji treści albo różnic w slugach po imporcie.
Po migracji często dochodzi też do tzw. rozjazdu warstwy widocznej i warstwy technicznej. Strona główna może działać poprawnie, ale podstrony zwracają 404, bo serwer nie interpretuje reguł WordPressa. Użytkownik widzi więc stronę startową, ale każdy klik w menu prowadzi do błędu. To bardzo częsty objaw po przeniesieniu na inny hosting, zmianie z Apache na nginx albo po odtworzeniu strony z backupu bez pełnej rekonstrukcji konfiguracji.
Warto też pamiętać, że 404 nie zawsze oznacza, że coś rzeczywiście „zniknęło”. Czasem zasób istnieje, ale:
- WordPress nie potrafi zbudować poprawnego adresu,
- stara domena została wciąż wpisana w bazie danych,
- plik .htaccess nie został wygenerowany,
- serwer nie ma aktywnego modułu przepisywania adresów,
- cache pokazuje stare lub błędne odpowiedzi,
- przekierowania tworzą pętlę i finalnie kończą się 404.
Dlatego diagnozę trzeba prowadzić warstwowo: domena, serwer, WordPress, baza danych, wtyczki, cache, CDN i dopiero treść oraz media.
Możliwe przyczyny
Po migracji WordPress najczęściej do 404 prowadzi jedna z poniższych przyczyn. Czasem problem jest pojedynczy, ale często nakłada się kilka usterek jednocześnie.
1. Nieodświeżone permalinki
To absolutny klasyk. WordPress po przenosinach nadal ma tę samą strukturę URL, ale reguły przepisywania nie zostały zapisane ponownie. W praktyce wystarczy wejść w ustawienia bezpośrednich odnośników i zapisać je jeszcze raz, aby WordPress wygenerował odpowiednie reguły.
2. Brak lub uszkodzenie pliku .htaccess
Na serwerach Apache plik .htaccess odpowiada za przekierowanie żądań do WordPressa. Jeśli go brakuje, ma złe uprawnienia albo zawiera nieaktualne reguły z poprzedniego hostingu, podstrony mogą zwracać 404 mimo że treść istnieje. Po migracji często przenosi się samą stronę, ale nie dba o kompatybilność z nowym środowiskiem.
3. Niewłaściwa konfiguracja nginx
Jeśli strona działa na nginx, nie wystarczy przenieść plików i bazy danych. Trzeba jeszcze ustawić reguły try_files lub odpowiedni routing, inaczej serwer nie przekaże zapytania do WordPressa. Wtedy zwykle strona główna działa przypadkiem, a reszta podstron kończy się 404.
4. Zmieniona domena lub adres witryny w bazie danych
Po migracji z domeny testowej na produkcyjną albo po przenosinach między subdomenami często zostają stare wartości siteurl i home. WordPress generuje wtedy adresy, które prowadzą do niewłaściwej lokalizacji. Problem może dotyczyć także wpisów, obrazów i elementów menu zapisanych w treści HTML.
5. Brak aktualizacji przekierowań
Jeżeli po migracji zmieniła się struktura adresów, a przekierowania 301 nie zostały odtworzone, użytkownik trafia na stare adresy i widzi 404. Dotyczy to zwłaszcza rozbudowanych serwisów, sklepów i blogów z dużą historią publikacji.
6. Konflikt wtyczek SEO, cache lub przekierowań
Wtyczki potrafią nadpisywać reguły adresowania, tworzyć własne przekierowania, buforować stare odpowiedzi albo blokować poprawną interpretację adresów. Po migracji konflikt jest szczególnie prawdopodobny, jeśli przenoszono także konfigurację wtyczek bez ich weryfikacji.
7. Zmiana struktury katalogów lub lokalizacji plików
Jeśli WordPress został przeniesiony do innego katalogu, na przykład z głównego katalogu domeny do podfolderu, bez aktualizacji adresów i reguł, część linków może prowadzić do 404. Dotyczy to też przenosin między środowiskiem staging a produkcją.
8. Błędy w migracji bazy danych
Podczas eksportu i importu bazy mogą zostać uszkodzone serializowane dane, ścieżki do mediów lub wpisy ustawień. Czasem import przechodzi „bez błędu”, ale część rekordów jest niekompletna, co skutkuje 404 na wybranych podstronach.
9. Cache przeglądarki, WordPressa, serwera lub CDN
Stary cache potrafi przez jakiś czas pokazywać nieaktualne odpowiedzi. Po migracji użytkownik może nadal dostawać 404, choć po stronie serwera problem został już częściowo naprawiony. To szczególnie częste przy użyciu CDN, zwłaszcza gdy nie wyczyszczono pamięci podręcznej na wszystkich warstwach.
10. Zmiana uprawnień do plików
Jeżeli pliki lub katalogi mają nieprawidłowe uprawnienia, WordPress może nie mieć możliwości odczytu reguł lub plików mediów. Efekt bywa mylący: część strony działa, ale konkretne zasoby lub podstrony wyświetlają 404.
Rozwiązanie krok po kroku
Poniżej znajdziesz praktyczną ścieżkę naprawy. Przechodź po kolei, nie zgaduj na ślepo. Jeśli w którymś punkcie problem zniknie, nie musisz wykonywać dalszych zmian.
Krok 1: Zrób pełny backup
Zanim cokolwiek zmienisz, wykonaj kopię plików i bazy danych. To ważne nie tylko dla bezpieczeństwa, ale też dlatego, że przy naprawie 404 można łatwo nadpisać działającą konfigurację. Backup jest obowiązkowy, jeśli zamierzasz edytować .htaccess, pliki konfiguracyjne, tabele bazy lub wtyczki przekierowań.
Ostrzeżenie bezpieczeństwa: nie pracuj na żywej stronie bez kopii zapasowej. Jedna błędna reguła przekierowania może odciąć dostęp do panelu lub spowodować masowe błędy na całej witrynie.
Krok 2: Sprawdź, czy problem dotyczy całej witryny czy wybranych adresów
Otwórz stronę główną, kilka wpisów, stronę kategorii, pojedynczy produkt i jeden adres mediów. Zapisz, które działają, a które zwracają 404. Taki test pozwala odróżnić problem z routingiem od problemu z konkretnymi treściami.
Jeśli 404 występuje tylko na starych wpisach, przyczyna może leżeć w permalinkach lub redirectach. Jeśli problem dotyczy wszystkich podstron, najpewniej nie działa przepisywanie adresów po stronie serwera.
Krok 3: Odśwież bezpośrednie odnośniki
Wejdź do panelu WordPressa, przejdź do ustawień bezpośrednich odnośników i kliknij zapis bez zmiany wartości. To najprostsza i często najskuteczniejsza operacja. W wielu przypadkach WordPress sam przepisuje reguły i 404 znika natychmiast.
Jeżeli nie masz dostępu do panelu, problem może wymagać naprawy bezpośrednio w bazie lub przez pliki serwera. Jeśli dostęp jest, a zapis nie pomaga, przejdź dalej.
Krok 4: Sprawdź .htaccess lub konfigurację nginx
Na Apache upewnij się, że plik .htaccess istnieje, ma właściwe uprawnienia i zawiera reguły WordPressa. Jeśli po migracji zastąpił go pusty plik albo wersja bez reguł, wpisy i strony będą zwracać 404.
Na nginx trzeba sprawdzić konfigurację lokacji i reguły przekierowania żądań do index.php. W praktyce problemem bywa brak odpowiedniego try_files lub niepoprawny root do katalogu strony. W przypadku nginx nie wystarczy kopiować ustawień z innego serwera bez weryfikacji składni i ścieżek.
Ostrzeżenie bezpieczeństwa: jeśli nie masz pewności, jak działa serwer, nie zapisuj losowych reguł znalezionych w internecie. Niepoprawna konfiguracja może zablokować cały serwis, a nie tylko wybraną podstronę.
Krok 5: Zweryfikuj adres witryny i adres WordPressa
Sprawdź wartości home i siteurl w bazie danych oraz w panelu administracyjnym. Muszą wskazywać dokładnie ten adres, pod którym działa strona po migracji. Jeśli przeniosłeś witrynę z HTTP na HTTPS, z domeny testowej na produkcyjną albo z katalogu głównego do podfolderu, te wartości muszą być zgodne z nową strukturą.
Jeżeli masz wp-config.php z wpisami wymuszającymi adresy, zweryfikuj, czy nie nadpisują ustawień z bazy. Często ktoś zapomina o twardo wpisanych adresach z etapu testowego i po migracji WordPress dalej buduje linki do starej lokalizacji.
Krok 6: Przeskanuj bazę danych pod kątem starych adresów
Jeśli migracja obejmowała zmianę domeny, sprawdź, czy w treści wpisów, ustawieniach motywu i opcjach wtyczek nie zostały stare adresy. Szczególnie ważne są dane serializowane, bo ich ręczna edycja bez narzędzia do poprawnej zamiany może uszkodzić strukturę danych. To jeden z najczęstszych powodów, dla których część linków działa, a część prowadzi do 404.
W praktyce trzeba szukać nie tylko starej domeny, ale też ścieżek do mediów, plików CSS, JS, obrazów i miniatur. Po migracji link może wyglądać dobrze na pierwszy rzut oka, a jednak wskazywać na dawny katalog.
Krok 7: Wyczyść wszystkie warstwy cache
Po zmianach wyczyść cache w WordPressie, na serwerze, w CDN i w przeglądarce. Jeżeli używasz zewnętrznego cache strony lub reverse proxy, sprawdź, czy nie trzyma starego 404 jako odpowiedzi zapisanej w pamięci podręcznej.
Warto przetestować stronę w trybie prywatnym lub z innej sieci. Dzięki temu wykluczysz lokalny cache i szybko zobaczysz, czy naprawa faktycznie zadziałała.
Krok 8: Dezaktywuj na próbę wtyczki odpowiedzialne za SEO, cache i przekierowania
Jeśli nadal masz 404, tymczasowo wyłącz wtyczki, które ingerują w adresy URL. Najczęściej są to wtyczki SEO, cache, redirect i czasem page buildery z własnymi regułami permalinków. Po migracji konflikt wtyczek może ujawnić się dopiero przy generowaniu nowych reguł.
Dezaktywacja na chwilę jest bezpieczniejsza niż długie zgadywanie. Jeżeli po wyłączeniu problem znika, wiesz już, gdzie szukać źródła.
Krok 9: Sprawdź przekierowania 301 i pętle przekierowań
Jeżeli stare adresy mają prowadzić do nowych, upewnij się, że przekierowania są poprawne i nie tworzą pętli. Błędna sekwencja redirectów może skończyć się 404 po kilku skokach lub komunikatem o zbyt wielu przekierowaniach. Przeanalizuj reguły dla najważniejszych podstron, kategorii i produktów.
Dobrym zwyczajem po migracji jest zmapowanie dawnych adresów na nowe i sprawdzenie ich statusów HTTP. Jeśli zmieniła się architektura serwisu, nie zakładaj, że stare adresy „same się odnajdą”.
Krok 10: Zweryfikuj media i katalog uploads
Jeśli 404 dotyczą obrazów, plików PDF lub załączników, sprawdź katalog uploads i ścieżki do plików. Czasem po migracji przenosi się bazę, ale nie wszystkie zasoby multimedialne. Innym razem problemem jest inna wielkość liter w nazwach plików albo niepoprawna ścieżka do katalogu z mediami na serwerze z Linuxem.
Warto pamiętać, że niektóre serwery są bardziej restrykcyjne niż poprzednie środowisko. To, co działało lokalnie lub na tanim hostingu, na nowym serwerze może wymagać dokładniejszej konfiguracji.
Krok 11: Sprawdź uprawnienia plików i właściciela katalogów
Jeżeli masz dostęp do serwera, sprawdź, czy pliki i katalogi mają właściwe uprawnienia oraz czy użytkownik serwera ma do nich dostęp. Złe uprawnienia mogą powodować błędy trudne do odróżnienia od typowego 404, zwłaszcza przy odczycie plików statycznych lub mediach.
Jeśli nie wiesz, jakie uprawnienia są prawidłowe dla Twojej konfiguracji, lepiej poprosić o to administrującego serwerem niż zgadywać. Zbyt szerokie uprawnienia to ryzyko bezpieczeństwa, a zbyt wąskie mogą zablokować stronę.
Krok 12: Porównaj środowisko źródłowe i docelowe
Na końcu porównaj, czym różnił się stary serwer od nowego: wersją PHP, typem serwera, obsługą modułów, konfiguracją cache, CDN, SSL i regułami rewrite. Niejednokrotnie błąd nie leży w WordPressie, tylko w tym, że nowe środowisko interpretuje adresy inaczej niż stare.
Jeśli po przejściu wszystkich kroków 404 nadal się pojawia, problem może być głębszy: uszkodzony import, błędna struktura tabel, konflikt z motywem lub nietypowa konfiguracja hostingu.
Najczęstsze błędy
Podczas naprawy 404 po migracji WordPress łatwo popełnić błędy, które tylko wydłużają problem. Oto najczęstsze z nich:
- zapisywanie permalinków bez sprawdzenia konfiguracji serwera,
- ręczne edytowanie bazy bez kopii zapasowej,
- kopiowanie przypadkowych reguł .htaccess z internetu,
- wyłączanie wszystkich wtyczek bez planu testów,
- zmiana adresu strony tylko w panelu, bez aktualizacji bazy i konfiguracji,
- ignorowanie cache CDN i reverse proxy,
- naprawianie tylko strony głównej, bez testu podstron,
- brak przekierowań ze starych adresów,
- pomijanie mediów i plików załączonych do treści,
- edytowanie danych serializowanych ręcznie, co może uszkodzić ustawienia motywu lub wtyczek.
Największym błędem jest działanie „na skróty”. 404 po migracji to zazwyczaj problem techniczny o kilku potencjalnych źródłach, więc przypadkowe zmiany często pogarszają sytuację.
Kiedy nie robić tego samodzielnie
Nie warto naprawiać wszystkiego samodzielnie, jeśli:
- strona działa na produkcji i generuje ruch lub sprzedaż,
- nie masz aktualnego backupu,
- nie masz dostępu do konfiguracji serwera,
- problem dotyczy dużego sklepu WooCommerce lub serwisu z wieloma podstronami,
- po migracji uszkodziły się dane serializowane,
- masz jednocześnie 404, błędy 500 i problem z logowaniem,
- nie wiesz, czy serwer używa Apache, nginx czy warstwy pośredniej,
- ktoś już wcześniej wprowadził niestandardowe przekierowania lub ręczne poprawki w bazie.
W takich sytuacjach samodzielne eksperymenty mogą spowodować kolejne awarie. Jeśli strona sprzedaje, zbiera leady lub obsługuje klientów, każda minuta błędu ma koszt biznesowy.
Kiedy zgłosić się do specjalisty
Do specjalisty warto zgłosić się wtedy, gdy 404 po migracji utrzymuje się mimo wykonania podstawowych kroków albo gdy problem ma wpływ na SEO, sprzedaż i stabilność serwisu. Pomoc eksperta jest szczególnie wskazana, gdy:
- 404 dotyczą dużej liczby adresów i trzeba przeanalizować mapę przekierowań,
- migracja obejmowała zmianę domeny, hostingu i struktury URL jednocześnie,
- potrzebna jest interwencja w bazie danych z zachowaniem danych serializowanych,
- serwer wymaga korekty konfiguracji Apache lub nginx,
- strona jest po ataku, po awarii albo po nieudanym wdrożeniu,
- pojawiają się błędy mieszane: 404, 403, 500, problemy z SSL i błędne przekierowania.
Specjalista zaoszczędzi czas, a przede wszystkim zmniejszy ryzyko utraty pozycji w wyszukiwarce. Przy problemach po migracji liczy się nie tylko naprawa, ale też zachowanie ciągłości ruchu.
Podsumowanie i CTA do kontaktu
404 po migracji WordPress to jeden z najczęstszych i najbardziej frustrujących problemów po przenosinach strony. W praktyce najczęściej winne są permalinki, .htaccess, konfiguracja nginx, nieaktualne adresy w bazie danych, cache albo brak przekierowań. Dobra diagnoza polega na sprawdzeniu tych elementów po kolei, a nie na losowym klikaniu w ustawienia.
Jeśli chcesz, możesz zacząć od prostych kroków: zapisać permalinki, sprawdzić adres witryny, wyczyścić cache i zweryfikować reguły serwera. Jeśli jednak 404 obejmuje dużą część strony, problem pojawił się po złożonej migracji albo nie masz pewności, gdzie leży błąd, lepiej nie ryzykować dalszych zmian.
Masz 404 po migracji WordPress i chcesz szybko przywrócić stronę bez strat dla SEO? Skontaktuj się ze specjalistą R99.PL, aby zdiagnozować problem, naprawić konfigurację i bezpiecznie przywrócić działanie podstron.
