Sprawdź dokładny adres URL za pomocą narzędzia pokazującego każdy krok HTTP. Ustal, która warstwa zwraca błąd 404 lub nagłówek Location. Przy routingu WordPressa sprawdź istnienie sluga, konflikt typów i reguły rewrite; w przypadku pętli ujednolić HTTPS, hosta i ukośnik końcowy między proxy, serwerem a ustawieniami WordPressa.
Błąd 404 w WordPressie może oznaczać brakującą treść, nieodświeżone reguły rewrite, konflikt sluga, błąd serwera lub żądanie, które w ogóle nie dotarło do WordPressa. Pętla przekierowań powstaje z kolei wtedy, gdy dwie warstwy wymuszają różny host, protokół, ukośnik lub język. Przeglądarka pokazuje ten sam ogólny błąd, choć poprawkę trzeba wprowadzić w zupełnie innym miejscu.
Diagnostyka śledzi pojedyncze żądanie krok po kroku: DNS i proxy, HTTPS, serwer WWW, reguły `.htaccess` lub Nginx, canonical redirect WordPressa i wtyczki. Celem jest jeden preferowany adres URL i co najwyżej jedno bezpośrednie przekierowanie ze starego wariantu. Przypadkowe zapisywanie permalinków czy dodawanie kolejnej wtyczki do przekierowań może chwilowo zmienić objaw, ale zwiększa niepewność.
Proszę uchwycić dokładną ścieżkę HTTP
Proszę użyć curl lub panelu sieci i zapisać pierwotny URL, status, nagłówek Location na każdym etapie oraz odpowiedź końcową. Należy testować anonimowo bez cache, a następnie w zwykłej przeglądarce. Trzeba odróżnić serwerowy błąd 404 od szablonu WordPressa, miękkiego 404 z kodem 200 oraz blokady bezpieczeństwa. Czas i request ID pomogą odnaleźć wpis w logu.
Sprawdźcie HTTP i HTTPS, wariant z www, ukośnik, małe litery oraz URL bez parametrów kampanii, ale nie twórzcie z każdego wariantu osobnej reguły. Jeśli CDN zwraca inną odpowiedź niż bezpośrednie połączenie z originem, problem leży przed aplikacją lub w cache. Test bezpośredniego originu wykonujcie wyłącznie, mając do tego uprawnienia, i z prawidłowym nagłówkiem Host.
Zweryfikuj istnienie i konflikt trasy WordPress
W panelu administracyjnym znajdź opublikowany wpis, jego slug, status, typ i element nadrzędny. Tej samej bazy może używać strona, typ treści lub taksonomia. Szkic lub wpis prywatny zachowuje się inaczej wobec anonimowego użytkownika. Sprawdź także wersję językową oraz to, czy wtyczka nie dodaje endpointu o tej samej nazwie.
Reguły rewrite można w kontrolowany sposób odświeżyć przez zapisanie permalinków lub CLI, ale nie należy robić tego jako regularnego maskowania problemu. Własna wtyczka powinna wykonywać flush wyłącznie przy aktywacji lub zmianie reguły, a nie przy każdym żądaniu. Jeśli odświeżenie pomogło, proszę znaleźć komponent, który nie zarejestrował reguł we właściwym momencie lub wielokrotnie je nadpisuje.
- Status i typ rekordu
- Konflikt sluga lub bazy
- Ścieżka językowa i nadrzędna
- Rejestracja reguły rewrite
Rozdziel odpowiedzialność warstw przekierowań
Kanoniczny host i HTTPS najlepiej obsłużyć w jednej warstwie brzegowej lub serwerowej, z uwzględnieniem nagłówków proxy. WordPress musi znać właściwy publiczny schemat i adres. Jeśli CDN terminuje HTTPS, ale serwer źródłowy nadal traktuje ruch jako HTTP, aplikacja może przekierowywać z powrotem. Zaufany nagłówek proxy należy przyjmować wyłącznie od znanego pośrednika.
Wtyczka SEO, wtyczka przekierowań, wtyczka wielojęzyczna i własny kod mogą wszystkie zmieniać nagłówek Location. Przeprowadź inwentaryzację i każdej kategorii przypisz właściciela: host/protokół – serwerowi, stare adresy URL treści – mapie migracji, język – systemowi tłumaczeń. Jedna reguła ma jeden cel. Łańcuchy skracaj, aktualizując pierwszy krok tak, by prowadził do docelowego adresu.
Obsługuj stare i nieprawidłowe adresy URL zgodnie z ich znaczeniem
Jeśli treść została przeniesiona, należy zastosować trwałe, bezpośrednie przekierowanie do najbliższego odpowiednika. Jeśli nigdy nie istniała lub nie ma zamiennika, właściwa jest poprawna odpowiedź 404. Masowe przekierowywanie wszystkiego na stronę główną wprowadza użytkownika w błąd i ukrywa uszkodzone linki. Przekierowania tymczasowego należy używać tylko w faktycznie tymczasowej sytuacji z planem jej zakończenia.
Własna strona 404 powinna zwracać kod 404, wyjaśniać sytuację i oferować nawigację lub wyszukiwarkę. Nie powinna zawierać automatycznego przekierowania po kilku sekundach. Należy monitorować najczęstsze błędne ścieżki i poprawiać wewnętrzne źródło linku. W przypadku złośliwego lub przypadkowego skanowania nie trzeba tworzyć reguły dla każdej próby.
- 301 dla trwałego, adekwatnego zamiennika
- 302 tylko dla stanu tymczasowego
- Prawdziwy kod 404 bez fałszywego przekierowania
- Poprawa linku wewnętrznego u źródła
Testuj reguły przed wdrożeniem i po nim
Na podstawie mapy migracji należy utworzyć automatyczny test: stary URL, oczekiwany status i ostateczny cel. Należy uwzględnić ukośnik, query string, zakodowane znaki i kilka nieistniejących adresów. Na stagingu może być inny host, dlatego reguły nie mogą na sztywno kierować odwiedzającego na produkcję. Konfigurację serwera należy zwalidować przed przeładowaniem.
Po wdrożeniu należy sprawdzić priorytetowe adresy, monitorować pętle, błędy 5xx i wzrost liczby błędów 404 w logach. Należy wyczyścić wyłącznie odpowiedni cache CDN. Zmiany należy udokumentować wraz z uzasadnieniem i datą, aby stara reguła nie powróciła przy kolejnej migracji. W razie incydentu należy zachować pierwotny łańcuch jako dowód i dopiero potem modyfikować warstwy.
Najczęstsze pytania
Czy przy błędzie 404 w WordPressie pomoże zapisanie permalinków?
Może odświeżyć reguły rewrite i potwierdzić tę warstwę, ale nie jest uniwersalną poprawką. Jeśli problem się powtarza, trzeba znaleźć konflikt slugów, nieprawidłową rejestrację lub regułę serwera, która powoduje ten stan.
Dlaczego pojawia się ERR_TOO_MANY_REDIRECTS?
Najczęściej dwie warstwy nie zgadzają się co do HTTPS, hosta, ukośnika, języka lub logowania i odsyłają żądanie tam i z powrotem. Należy przechwycić cały łańcuch i poprawić pierwszą konfliktową warstwę, zamiast na ślepo zmieniać cookies.
Czy każdy błąd 404 przekierowywać na stronę główną?
Nie. Należy przekierowywać tylko stary URL, który ma odpowiedni zamiennik. Nieistniejący adres powinien zwracać rzeczywisty błąd 404 z przydatną nawigacją. Masowe przekierowanie wprowadza ludzi w błąd i utrudnia wykrywanie uszkodzonych linków.
Źródła i dalsza lektura
Adam Antoni vyvíja weby, aplikácie a softvér na mieru. Prepája firemné systémy, automatizuje procesy a vytvára AI agentov. Pôsobí v Spišskej Novej Vsi a spolupracuje s firmami na celom Slovensku.
