Jak naprawić błąd 404 w WordPress

Błąd 404 w serwisie opartym na WordPress potrafi zaskoczyć nawet doświadczonych administratorów. Strony znikają z wyników, linki do wpisów przestają działać, a użytkownicy trafiają na pustkę zamiast treści. Dobra wiadomość: większość przyczyn da się usunąć w kilkanaście minut, jeśli podejdziesz do sprawy metodycznie. Poniżej znajdziesz praktyczną instrukcję krok po kroku, która przeprowadzi Cię przez diagnostykę, naprawę ustawień, konfigurację serwera oraz utrwalenie efektu, by problem nie wracał.

Diagnoza: co tak naprawdę oznacza 404 i jak zacząć

Co oznacza kod 404 i gdzie go szukać

Kod 404 to odpowiedź serwera informująca, że żądany adres URL nie istnieje. W praktyce może to oznaczać usuniętą podstronę, błędny slug, niewłaściwe reguły przepisywania adresów lub problem po stronie serwera pośredniczącego. Zawsze odróżniaj 404 od 500 czy 403, bo każdy z tych błędów ma inne przyczyny i wymaga innego podejścia.

Szybka lista kontrolna na start

• Sprawdź pojedynczy wpis, stronę, kategorię i media. Zwróć uwagę, czy problem dotyczy wszystkich, czy wybranych typów treści.
• Otwórz adres z kończącym ukośnikiem i bez niego. Zapis slugów ma znaczenie dla reguł przepisywania.
• Wyłącz przechowywanie w pamięci podręcznej przeglądarki i wtyczek. Później wrócisz do optymalizacji cache, teraz potrzebujesz czystego testu.
• Sprawdź logi serwera: /var/log/apache2/error.log, /var/log/nginx/error.log lub panel hostingowy.
• Porównaj wynik po zalogowaniu i bez logowania. Niektóre mechanizmy ochronne różnicują odpowiedzi.

Narzędzia, które pomagają wykryć źródło

• Konsola deweloperska przeglądarki, zakładka Network, statusy żądań i nagłówki odpowiedzi.
• cURL w wierszu poleceń, aby obejrzeć surową odpowiedź i przekierowania.
• WP-CLI do sprawdzenia reguł, struktury linków i przepisanego routingu.
• Usługi monitorujące, które pokazują historię zmian i awarie w czasie.

Rozróżnij rodzaj 404

• 404 na wszystkich wpisach: prawdopodobne uszkodzenie reguł przepisywania adresów lub pliku .htaccess albo konfiguracji Nginx.
• 404 na wybranych typach treści: błędna rejestracja CPT lub taksonomii, brak flush rewrite.
• 404 tylko na zasobach statycznych: złe ścieżki, zmieniona domena, CDN, uprawnienia plików.
• 404 po migracji: niezmienione adresy w ustawieniach, mieszana treść, brak właściwych przekierowań.

Ustawienia odnośników i serwer: naprawa reguł przepisywania

Przebudowa struktury odnośników w panelu

Najczęstsza i najszybsza naprawa to zresetowanie struktury linków. W panelu przejdź do Ustawienia > Bezpośrednie odnośniki, zapamiętaj bieżącą strukturę, przełącz na domyślną, zapisz, a następnie wróć do preferowanej i ponownie zapisz. Ten krok odświeża reguły i zapisuje je w pliku .htaccess lub w pamięci serwera. Jeśli masz multisite, wykonaj to per witryna.

.htaccess dla Apache: prawidłowe reguły

Jeśli serwer to Apache, upewnij się, że katalog główny posiada plik .htaccess z sekcją WordPress. Typowa zawartość:

# BEGIN WordPress
RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ – [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress

Po edycji wymuś przeładowanie ustawień i sprawdź, czy moduł rewrite jest włączony. Jeżeli hosting nie pozwala na nadpisywanie reguł, poproś o włączenie AllowOverride w konfiguracji vhosta lub przenieś reguły do pliku konfiguracyjnego serwera.

Konfiguracja Nginx: odpowiednik try_files

Dla serwerów Nginx kluczowe jest właściwe przekierowanie do index.php, gdy żądany plik lub folder nie istnieje. Przykład sekcji location:

location / {
try_files $uri $uri/ /index.php?$args;
}

W przypadku instalacji w podkatalogu zmień ścieżki odpowiednio. Po modyfikacji zrestartuj usługę i monitoruj logi błędów oraz dostępu, aby potwierdzić, że żądania trafiają do PHP-FPM, a nie kończą się 404 na poziomie serwera www.

Multisite i subdomeny lub podkatalogi

W instalacjach multisite reguły różnią się zależnie od trybu. Dla subdomen wymagana jest prawidłowa konfiguracja DNS i wildcard, a dla podkatalogów – dodatkowe reguły przepisywania. Sprawdź plik wp-config.php pod kątem stałych definiujących sieć i upewnij się, że adresy stron podrzędnych działają indywidualnie, a nie tylko w panelu.

WP-CLI i wymuszenie flush

Jeżeli masz dostęp do konsoli, użyj WP-CLI do wymuszenia przebudowy reguł: wp rewrite flush —hard. Przy okazji sprawdź instalację: wp core verify-checksums, a także listę zarejestrowanych typów treści: wp post-type list. Dzięki temu łatwiej wykryjesz, które reguły są niepełne lub nadpisane.

Wtyczki, motyw i rejestracje typów treści: eliminacja konfliktów

Test konfliktów: wyłączanie rozszerzeń i zmiana motywu

Konflikty często powodują wtyczki lub aktywny motyw. Włącz tryb awaryjny: tymczasowo przełącz na motyw Twenty Twenty-Three i dezaktywuj wszystkie rozszerzenia. Jeśli 404 zniknie, włączaj elementy pojedynczo, aż wskażesz winowajcę. W przypadku witryn produkcyjnych rób to na kopii staging lub w oknie konserwacji, informując użytkowników.

Custom Post Types i taksonomie: poprawne rewrite

Błędna rejestracja CPT powoduje 404 na pojedynczych wpisach lub archiwach. Upewnij się, że register_post_type zawiera poprawne argumenty rewrite i has_archive. Po zmianach wykonaj flush reguł. Gdy chcesz zmienić slug, zaplanuj przekierowania 301, aby nie tracić ruchu i mocy SEO.

Funkcje motywu i przepisywanie tras

Fragmenty w functions.php mogą dodawać własne reguły rewrite. Każda modyfikacja struktury adresów powinna być zgodna z resztą witryny. Pamiętaj, że kolejność dodawania reguł ma znaczenie. Niepoprawnie ustawione filtry parse_request potrafią przejąć wszystkie żądania i generować 404 na oryginalnych trasach.

Sklepy i strony wielojęzyczne

WooCommerce tworzy własne strony systemowe (sklep, koszyk, zamówienie). Uszkodzenie ich przypisań skutkuje 404. Sprawdź w ustawieniach adresy końcowe endpointów konta i płatności. W rozwiązaniach wielojęzycznych sprawdź mapowanie URL i duplikaty tłumaczeń. Konflikty między wtyczkami do i18n a regułami sklepu to częsta przyczyna 404.

Hooki na zapleczu i uprawnienia

Niektóre rozszerzenia rejestrują trasy tylko po stronie administracyjnej lub warunkowo. Sprawdź, czy istotne elementy nie są włączone wyłącznie dla roli administratora. Dodatkowo zweryfikuj, czy reguły nie są filtrowane przez zabezpieczenia serwera, WAF lub mechanizmy typu ModSecurity.

Pliki, pamięć podręczna, CDN i bezpieczeństwo

Cache aplikacyjny, serwerowy i przeglądarkowy

Warstw jest wiele: wtyczka optymalizacyjna, cache serwera, reverse proxy oraz CDN. Niespójność między nimi bywa przyczyną 404 na działających wcześniej adresach, zwłaszcza po migracji lub czyszczeniu miniatur. Po zmianach w strukturze odnośników opróżnij każdą warstwę i wyłącz agresywne reguły do czasu zakończenia testów. Po weryfikacji włączaj ponownie, monitorując odpowiedzi.

CDN, ścieżki i domeny

Usługi CDN potrafią zwracać 404 z własnej pamięci. Zweryfikuj źródło pochodzenia, mapowanie domen i reguły ignorowania. Upewnij się, że origin zwraca 200, a CDN nie próbuje pobierać z błędnego hosta lub ścieżki. Po zmianie domeny zaktualizuj adresy zasobów, a następnie zainwaliduj całą sieć brzegową. W rozwiązaniach hybrydowych sprawdź, czy mix subdomen nie blokuje ciastek sesyjnych.

404 na obrazach, stylach i skryptach

Gdy brakuje miniatur lub styli, sprawdź faktyczną obecność plików w wp-content/uploads oraz poprawność ścieżek generowanych przez motyw. Regeneracja miniatur przydaje się po zmianie motywu lub wymiarów obrazów. Jeżeli link prowadzi do nieistniejącej wersji rozmiaru, włącz narzędzie do ponownego wygenerowania i napraw źródła w szablonach.

Uprawnienia i właściciel plików

Złe prawa dostępu powodują, że serwer nie może odczytać plików i zgłasza 404 zamiast 403. Sprawdź, czy katalogi mają 755, a pliki 644, oraz czy właściciel jest zgodny z użytkownikiem usługi. Upewnij się, że reguły Deny nie blokują katalogów z mediami lub plikiem index.php w miejscach, gdzie jest on wymagany do routingu aplikacji.

Bezpieczeństwo, firewall i blokady

Zapory sieciowe, WAF, a nawet reguły antyspamowe mogą zmieniać odpowiedzi na poziomie brzegowym. Jeśli widzisz 404 tylko dla części regionów lub tylko dla ruchu botów, sprawdź reguły blokujące. Z kolei po incydencie bezpieczeństwa niektóre pliki mogą zostać usunięte lub zmienione. W razie wątpliwości porównaj sumy kontrolne, odtwórz czysty rdzeń i upewnij się, że rozszerzenia są zaufane.

Przekierowania, porządkowanie adresów i naprawa linków

301, 302, 410 i porządek reguł

Nie każdy 404 trzeba naprawiać. Jeśli adres został usunięty bez odpowiednika, rozważ 410. Jeśli masz nowy adres docelowy, zastosuj 301. Dbaj o kolejność reguł, ponieważ pierwsze dopasowanie decyduje o wyniku. Unikaj pętli i łańcuchów. Sprawdzaj, czy reguły nie kolidują z głównymi ustawieniami rewrite.

Wtyczki do przekierowania i ich konfiguracja

Rozszerzenia do redirectów ułatwiają import map adresów i kontrolę błędów. Skonfiguruj rejestrowanie 404, limity logów oraz automatyczne propozycje dopasowań. Włącz testy dopasowania po stronie serwera, aby uniknąć przetwarzania w PHP tam, gdzie reguły mogą zostać wykonane wcześniej i wydajniej.

Mapowanie starych URL-i po migracji

Po zmianie domeny lub struktury katalogów przygotuj mapę wszystkich ruchliwych adresów. Wykorzystaj dane z analityki oraz narzędzi webmastera. Wprowadź przekierowania hurtowo, najlepiej na poziomie serwera. Po wdrożeniu uruchom crawl całej witryny, aby wyłapać luki, i popraw linkowanie wewnętrzne, by nie polegać długoterminowo na redirectach.

Linkowanie wewnętrzne i naprawa treści

404 często pojawiają się wewnątrz treści po przenosinach. Użyj wyszukiwarki w bazie danych, aby znaleźć stare ścieżki. Jeśli strona jest rozbudowana, wykonaj skan linków i zautomatyzuj poprawki. Pamiętaj o aktualizacji odnośników w widgetach, menu, polach ACF i blokach w edytorze. Konsystencja adresów skraca czasy odpowiedzi i poprawia wykorzystanie budżetu indeksowania.

Przypadki szczególne i trwałe zabezpieczenie przed nawrotami

REST API, headless i aplikacje SPA

W rozwiązaniach headless i SPA front obsługuje trasy, a backend służy do danych. 404 może pochodzić z części frontendowej mimo prawidłowej odpowiedzi serwera aplikacyjnego. Skonfiguruj fallbacki dla ścieżek, które powinny renderować aplikację. Sprawdź CORS i tokeny, bo błędy autoryzacji często maskowane są jako 404.

SSL, mieszana zawartość i domeny kanoniczne

Zmiana na HTTPS bez aktualizacji odnośników potrafi powodować 404 na zasobach pobieranych przez blokowaną mieszankę protokołów. Włącz https w ustawieniach witryny, popraw adresy w treściach i zadbaj o prawidłową domenę kanoniczną. Ustal jednoznacznie preferowaną wersję z www lub bez, a pozostałe przekieruj.

Monitoring błędów i automatyczne powiadomienia

Skonfiguruj stały monitoring. Raporty 404 w narzędziach wyszukiwarki, logi serwera i powiadomienia z wtyczki do redirectów pozwalają szybko reagować. Dodaj testy dymne uruchamiane po deployu, aby wykrywać uszkodzenia tras jeszcze przed skierowaniem ruchu produkcyjnego.

Kopia zapasowa i plan przywracania

Miej świeżą kopię plików i baza danych. Testuj odtwarzanie na środowisku tymczasowym. Jeśli zmiana reguł spowoduje lawinę 404, szybki rollback skraca przestoje. Wdróż kontrolę wersji plików konfiguracyjnych, aby móc bezpiecznie porównywać i cofać zmiany.

Standard pracy po zmianach adresów

• Planowanie: zidentyfikuj strony kluczowe i przygotuj mapę przekierowań.
• Wdrożenie: najpierw reguły serwera, potem aktualizacje w aplikacji.
• Weryfikacja: crawl, testy ręczne, sprawdzenie logów i szybkości.
• Utrwalenie: porządki w linkach wewnętrznych, wygaszenie starych ścieżek.

Stosując powyższy schemat krok po kroku, usuniesz 404 wynikające z błędnych permalinki, niewłaściwej konfiguracji Nginx lub pliku .htaccess, konfliktów powodowanych przez wtyczki i motyw, problemów z warstwą cache, a także zaniedbanych przekierowania po migracjach. Dodatkowo wypracujesz proces, który pozwoli utrzymać porządek adresów, stabilność i spójność treści bez strat ruchu i wizerunku.