Błąd 404 WordPress PrestaShop naprawa — to temat, który wraca jak bumerang w codziennej pracy administratorów, marketerów i właścicieli sklepów. Nie ma znaczenia, czy prowadzisz bloga na WordPressie, czy rozbudowany e‑commerce na PrestaShopie — komunikat “Strona nie została znaleziona” potrafi popsuć humor, obniżyć zaufanie użytkowników i zjeść część ruchu z Google. Dobra wiadomość? W większości przypadków 404 da się naprawić szybko i trwale, a po drodze uporządkujesz strukturę adresów, poprawisz SEO i zadbasz o lepsze doświadczenia użytkowników.

Poniżej znajdziesz praktyczny, ludzki przewodnik: jak zdiagnozować przyczyny błędów 404, jak je krok po kroku naprawić w WordPressie i PrestaShopie, oraz jak zapobiegać im w przyszłości. Bez magii — same sprawdzone metody i klarowne działania, które możesz wdrożyć od razu.

Dlaczego błąd 404 jest poważny, choć wygląda niegroźnie

Dla wielu osób 404 to jedynie drobna niedogodność. W praktyce:

– To sygnał dla użytkownika: “Nie mamy tego, czego szukasz”. Jeśli dzieje się to często, rośnie współczynnik odrzuceń, spada czas na stronie i maleje konwersja.

– To sygnał dla Google: link prowadzi donikąd. Jeśli robot indeksujący napotka mnóstwo 404, może ograniczyć crawl budget, uznać witrynę za mniej wiarygodną i obniżyć pozycje na frazy, które mają potencjał sprzedażowy.

– To realne straty przy kampaniach płatnych. Klik w reklamę, który kończy się na 404, to dosłownie wyrzucone pieniądze.

W skrócie: im szybciej uporasz się z 404, tym lepiej dla Twoich użytkowników, SEO i budżetu.

Czym jest 404 i skąd się bierze

Błąd 404 to standardowy kod HTTP oznaczający, że żądany zasób nie istnieje na serwerze. Najczęstsze scenariusze:

– Usunąłeś stronę lub produkt, a linki wewnętrzne pozostały.

– Zmieniłeś strukturę adresów (np. z /kategoria/produkt na /produkt/) bez konfiguracji przekierowań.

– Plik .htaccess (Apache) lub reguły w Nginx przestały działać po migracji czy aktualizacji.

– Wtyczka, motyw lub moduł zmienił routing i część adresów nagle nie pasuje do nowych reguł.

– CDN lub cache serwuje nieaktualne ścieżki.

Co ważne: 404 to nie zawsze błąd. Czasem to świadoma informacja: “tego już nie ma”. Kluczem jest rozróżnienie, kiedy 404 jest prawidłowe (np. niedostępny produkt bez zamiennika), a kiedy należy je zastąpić przekierowaniem 301.

Diagnoza przed naprawą: nie strzelaj na oślep

Naprawę zacznij od zebrania danych. Tylko wtedy wiesz, co i gdzie poprawić.

– Google Search Console: w raporcie Indeksowanie → Strony znajdziesz listę błędów 404 i linków, które do nich prowadzą. Zwróć uwagę na “Strona z błędem 404” i “Miękkie 404” (o nich trochę dalej).

– Google Analytics 4: utwórz filtr/raport na podstawie tytułu strony 404 lub ścieżki, by zobaczyć źródła ruchu i częstotliwość.

– Screaming Frog/ Sitebulb: crawler pozwoli wychwycić wewnętrzne linki prowadzące do 404. Eksport CSV przyspiesza pracę.

– Logi serwera: access.log pokaże dokładnie, które adresy dają 404, z jakich IP i user agentów. Jeśli po migracji jest wysyp 404, logi to złoto.

– Narzędzia do monitoringu linków: np. Broken Link Checker (ostrożnie w WordPressie na produkcji — potrafi obciążać), Link Whisper (do porządkowania linkowania wewnętrznego), lub dedykowane skanery CI/CD w większych projektach.

Z tym pakietem wiesz, co psuje się najczęściej, skąd przychodzi ruch i które 404 bolą Cię najbardziej (np. z kampanii, z wyników organicznych, z wewnętrznej nawigacji).

Najczęstsze przyczyny 404 w WordPressie

– Permalinki i reguły przepisywania. Zmiana ustawień “Bezpośrednich odnośników” bez regeneracji rewrite rules to klasyk.

– .htaccess. Brak lub nadpisanie pliku po migracji/aktualizacji. WordPress potrzebuje w nim standardowego bloku mod_rewrite.

– Konfiguracja Nginx. Gdy zamiast Apacza masz Nginx, brak poprawnych reguł try_files dla index.php skutkuje 404 na podstronach.

– Konflikty wtyczek i motywów. Wtyczka rejestruje niestandardowy typ posta i slug, który nachodzi na inny, lub motyw dostarcza wadliwy plik 404.php.

– Wielojęzyczność (WPML, Polylang). Niespójne slug-i w językach, brak synchronizacji kategorii, błędne przekierowania wersji językowych.

– WooCommerce: zmiana bazy dla produktów (/produkt/) lub stron systemowych (Sklep, Koszyk, Zamówienie) bez aktualizacji linków.

– Cache i CDN: “stare” zasoby (JS, CSS, obrazy) wskazują na ścieżki, których już nie ma lub wersje plików po deployu zmieniły hash.

– Multisite: niepełna konfiguracja domen/poddomen i mapowania, co daje 404 na podwitrynach.

– REST API/Headless: zmiany endpointów lub permalinki typu /wp-json/ po zmianach serwera reverse proxy.

Szybka naprawa 404 w WordPressie — krok po kroku

Poniższe kroki wykonuj kolejno. Po każdym sprawdzaj, czy 404 już zniknęły.

– 1. Odśwież bezpośrednie odnośniki.
Ustawienia → Bezpośrednie odnośniki → wybierz pożądany format (np. Nazwa wpisu) → Zapisz zmiany. To regeneruje reguły rewrite.

– 2. Zweryfikuj .htaccess (Apache).
W katalogu głównym instalacji WordPress powinien być plik .htaccess z domyślnym blokiem:
(jeśli korzystasz z Nginx — pomiń ten krok)
„`
# BEGIN WordPress

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

# END WordPress
„`
Jeśli nie ma .htaccess, utwórz go i nadaj odpowiednie uprawnienia (zwykle 644).

– 3. Sprawdź Nginx (jeśli używasz).
Upewnij się, że w konfiguracji serwera jest blok:
„`
location / {
try_files $uri $uri/ /index.php?$args;
}
„`
Po zmianach zrestartuj Nginx.

– 4. Wyłącz cache/CDN na czas testów.
Wtyczki typu WP Rocket, W3TC czy LiteSpeed Cache oraz Cloudflare potrafią podawać stare ścieżki. Wyczyść cache i na chwilę wyłącz optymalizacje, żeby wykluczyć ich wpływ.

– 5. Szukaj konfliktów wtyczek/motywu.
Dezaktywuj podejrzane wtyczki (szczególnie te, które modyfikują URL-e) i sprawdź, czy 404 ustępują. Skorzystaj z trybu awaryjnego (Health Check & Troubleshooting) — pozwala testować bez wpływu na użytkowników.

– 6. WooCommerce — ustaw strony systemowe.
WooCommerce → Ustawienia → Zaawansowane → Strony. Upewnij się, że Sklep, Koszyk, Zamówienie i Moje konto są przypisane i opublikowane. Następnie odśwież permalinki.

– 7. Zadbaj o przekierowania 301 dla zmienionych adresów.
Użyj wtyczki Redirection lub reguł serwerowych, aby stare adresy kierowały na nowe. W SEO zawsze preferuj 301 (trwałe), a nie 302 (tymczasowe), jeśli zmiana jest docelowa.

– 8. Napraw linkowanie wewnętrzne.
Zaktualizuj menu, breadcrumbs, linki w treści wpisów oraz w elementach dynamicznych (np. widżety). Często 404 po migracji to po prostu stare linki twardo wpisane w treści.

– 9. Media 404 (obrazy, CSS, JS).
Sprawdź, czy katalog wp-content/uploads jest dostępny i poprawnie przeniesiony po migracji. Braki w uprawnieniach lub inne ścieżki CDN powodują 404 na zasobach.

– 10. WP-CLI (dla szybszej pracy).
Jeśli masz dostęp SSH:
– Przepłukanie permalinks: wp rewrite flush –hard
– Wyszukaj i zamień stare domeny w bazie: wp search-replace stara-domena.pl nowa-domena.pl

– 11. Wielojęzyczność.
Przebuduj indeksy językowe w WPML/Polylang, zsynchronizuj menu i slug-i. Czasem jeden brakujący slug w danym języku wywołuje kaskadę 404.

– 12. Sprawdź plik 404.php w motywie.
Jeśli strona 404 nie wyświetla się poprawnie lub zwraca niewłaściwy kod (np. 200), popraw to w motywie potomnym. Miękkie 404 to realny problem SEO.

Po testach w przeglądarkach wyczyść cache, odpal crawler i wygeneruj raport — lista 404 powinna się wyraźnie skrócić.

Najczęstsze przyczyny 404 w PrestaShopie

PrestaShop ma swoją specyfikę routingu i generowania przyjaznych adresów. Najczęstsze źródła problemów:

– Friendly URLs i .htaccess. Wyłączenie i ponowne włączenie przyjaznych linków potrafi wygenerować wadliwy .htaccess, szczególnie po migracji.

– Dispatcher i overrides. Niestandardowe nadpisania (override) lub moduły rejestrujące własne trasy mogą powodować konflikty.

– Multistore. Źle skonfigurowane sklepy w trybie multistore (domeny, ścieżki, ustawienia językowe) prowadzą do 404 na części podstron.

– Usunięte/wyłączone produkty i kategorie. W e‑commerce to norma, ale brak polityki przekierowań po usunięciu asortymentu skutkuje wysypem 404.

– Generowanie miniatur i zasobów. Brakujące obrazy produktów (usunięte, nieprzeniesione) to 404 w kartach produktu i listingach.

– Cache/Smarty. Stary cache może podawać linki, które już nie istnieją po zmianach w strukturze.

– Niekompatybilne moduły SEO. Moduły, które “upiększają” URL-e, potrafią wejść w konflikt z wbudowanym mechanizmem.

– Różnice wersji i aktualizacje. Po update PrestaShop lub PHP czasem znika część tras, jeśli moduł nie jest zgodny.

– Błędna konfiguracja serwera (Nginx/Apache). Brak odpowiednich reguł rewrite skutkuje 404 na podstronach dynamicznych.

PrestaShop — jak krok po kroku naprawić 404

– 1. Włącz/odśwież przyjazne linki i regeneruj .htaccess.
W Panelu: Ustawienia → Ruch (SEO & URLs) → Friendly URL: Włącz. Zapisz. Następnie kliknij “Generuj plik .htaccess” (w starszych wersjach) lub zapisz ustawienia, by wymusić regenerację.

– 2. Wyczyść cache.
Zaawansowane → Wydajność → Wyczyść pamięć podręczną. Jeśli masz aktywny Smarty cache/kompilację, wyczyść i ustaw Tryb siły kompilacji na czas testów.

– 3. Sprawdź reguły URL dla produktów, kategorii i stron CMS.
W SEO & URLs zobacz wzorce (np. {id}-{rewrite}). Zmiana wzorca bez przekierowań = fala 404. Przywróć poprawne szablony lub skonfiguruj przekierowania.

– 4. Produkty/kategorie usunięte lub nieaktywne.
Jeśli produkt został wycofany, wdroż:
– 301 na zamiennik (jeśli jest),
– 301 na kategorię nadrzędną,
– lub pozostaw pełne 410 (GONE), gdy chcesz, by Google szybciej zapomniał adres.
Zarządzaj tym ręcznie lub modułem do przekierowań.

– 5. Multistore i języki.
Sprawdź, czy każdy sklep ma poprawną domenę, ścieżkę, domyślny język i aktywne tłumaczenia. Niespójne konfiguracje rodzą 404 w jednym sklepie, a nie w innych.

– 6. Dispatcher i overrides.
Tymczasowo wyłącz niestandardowe overrides lub podejrzane moduły, które modyfikują routing. Sprawdź, czy 404 ustępują — jeśli tak, zawężasz przyczynę.

– 7. Nginx/Apache.
Dla Apache sprawdź, czy .htaccess zawiera reguły z katalogu /tools/htaccess.txt. Dla Nginx użyj rekomendowanych konfiguracji PrestaShop (try_files do index.php).

– 8. Obrazy i miniatury.
W Katalog → Obrazy wygeneruj miniatury ponownie. Brakujące obrazy = 404 zasobów i słaby UX na listingu.

– 9. Moduł do zarządzania przekierowaniami.
Jeśli masz dużo 404 po zmianach katalogu produktów, zainstaluj moduł do łatwego tworzenia 301/302 (wiele rozwiązań w Addons Marketplace). To przyspiesza pracę i zmniejsza ryzyko błędów.

– 10. Sitemapa.
Wygeneruj aktualną sitemapę i prześlij w GSC. Pomoże szybciej zindeksować nowe adresy i porzucić te nieaktualne.

– 11. Testuj.
Przejdź kluczowe ścieżki: strona główna → kategorie → produkt → koszyk → checkout. Każde 404 w tej ścieżce ma natychmiastowy wpływ na sprzedaż.

błąd 404 WordPress PrestaShop naprawa — plan działania od ręki

– Zmapuj problemy. Zbierz listę adresów 404 z GSC, crawlera i logów. Oznacz, skąd pochodzi ruch (SEO, ads, e‑mail).

– Ustal priorytety. Najpierw strony z ruchem i potencjałem sprzedażowym, potem reszta.

– Szybkie wygrane. Regeneruj permalinki (.htaccess/Nginx), wyczyść cache/CDN, popraw podstawowe reguły.

– Przekierowania 301. Stare → nowe. Twórz hurtowo tam, gdzie to możliwe. 302 tylko gdy zmiana jest tymczasowa.

– Porządki w linkowaniu wewnętrznym. Menu, stopki, breadcrumbs, artykuły blogowe, bannery, automatyczne bloki.

– Wersje językowe i multistore. Zsynchronizuj slug-i i ustawienia dla każdej wersji.

– Monitoring. Włącz alerty na 404 (np. w logach lub przez narzędzie do monitoringu), aby wychwytywać problemy “na świeżo”.

Miękkie 404, 301 vs 302 i inne niuanse SEO

– Miękkie 404 (Soft 404). To sytuacja, w której strona wizualnie wygląda jak 404 (np. “brak produktu”), ale serwer zwraca kod 200. Dla Google to kłopot: traci crawl budget i myli intencję. Rozwiązanie: zwracaj prawdziwy 404 lub 410 dla nieistniejących zasobów, a dla produktów chwilowo niedostępnych — 200 z jasną informacją i sugestiami alternatyw.

– 301 vs 302.
– 301 — trwałe przeniesienie. Przekazuje większość mocy SEO i powinien być standardem przy stałych zmianach adresów.
– 302 — tymczasowe. Używaj tylko wtedy, gdy wiesz, że wrócisz do starego adresu.

– Canonical. Jeśli treść dostępna jest pod kilkoma adresami (np. parametry filtrowania), użyj rel=”canonical” do wersji docelowej.

– Sitemapa i recrawl. Po większych porządkach w URL-ach prześlij aktualną sitemapę do GSC, a ważne adresy poproś o ponowne zindeksowanie.

Dobra strona 404: niech ratuje, a nie zniechęca

Idealna 404:

– Ma prosty komunikat po ludzku: “Ups, ta strona nie istnieje”.

– Proponuje działania: pole wyszukiwania, linki do kategorii, bestsellery, ostatnio oglądane, CTA do kontaktu lub powrotu na stronę główną.

– Zawiera branding i menu — użytkownik czuje, że wciąż jest u Ciebie, a nie “na końcu internetu”.

– Zwraca poprawny kod 404 (lub 410), a nie 200.

– Na mobile działa tak samo dobrze, jak na desktopie.

W WordPressie przygotuj 404.php w motywie potomnym, w PrestaShopie — skoryguj szablon błędu w motywie i dodaj użyteczne linki. Drobiazg, który potrafi uratować sesję.

Typowe scenariusze i szybkie recepty (WordPress)

– Zmieniłeś domenę i masz 404 na obrazach: użyj WP-CLI search-replace na bazie danych i popraw ustawienia URL w WordPress Address i Site Address. Jeśli masz CDN, zaktualizuj origin.

– Wszystkie podstrony 404, a strona główna działa: 99% to problem z rewrite (.htaccess lub Nginx). Odśwież permalinki i reguły.

– Pojedyncze posty 404 po zmianie struktury: włącz wtyczkę Redirection, zaimportuj listę starych→nowych adresów (CSV).

– WooCommerce: 404 na kategoriach produktów po zmianie slug: odśwież permalinki i przebuduj indeksy taksonomii, sprawdź “Podstawa kategorii produktów”.

Typowe scenariusze i szybkie recepty (PrestaShop)

– Po migracji wszystkie adresy CMS 404: wygeneruj .htaccess ponownie, wyczyść cache Smarty, sprawdź ustawienia przyjaznych URL-i.

– Kategorie działają, produkty 404: zweryfikuj wzorzec URL produktu w SEO & URLs, sprawdź czy produkty są aktywne i przypisane do kategorii.

– Multistore: jeden sklep działa, drugi ma 404 na wszystkim: sprawdź przypisanie domeny/poddomeny, katalogu głównego i ustawień języka.

– Obrazy nie ładują się na listingu: wygeneruj miniatury ponownie i sprawdź uprawnienia katalogu /img/.

Monitorowanie 404 po wdrożeniu zmian

– Skonfiguruj alerty logów (np. przez Fail2ban, Logrotate + skrypty, lub SaaS typu Logtail/Datadog), aby wychwytywać nagłe skoki 404.

– W GA4 utwórz widok niestandardowy raportujący ścieżki 404 i źródła.

– Używaj Screaming Frog cyklicznie (np. co miesiąc), aby znaleźć nowe wewnętrzne martwe linki.

– W GSC regularnie kontroluj raport Strony. Oznaczaj naprawione adresy i sprawdzaj, czy Google ogranicza sygnały o 404.

Checklista: szybkie 15 minut na opanowanie sytuacji

– 1. Zbierz listę 404 (GSC + crawler + logi).

– 2. Oceń priorytety (ruch, przychód, kampanie).

– 3. WordPress: odśwież permalinki, sprawdź .htaccess/Nginx.

– 4. PrestaShop: regeneruj .htaccess i wyczyść cache.

– 5. Wyłącz cache/CDN na czas testów.

– 6. Napraw błędy w menu i linkach wewnętrznych.

– 7. Dodaj przekierowania 301 dla najważniejszych starych adresów.

– 8. Wygeneruj sitemapę i prześlij do GSC.

– 9. Zaktualizuj stronę 404, by pomagała użytkownikowi.

– 10. Włącz monitoring i wróć do raportów za 48–72 h.

Najczęstsze pułapki, które wydłużają naprawę

– Przekierowania w pętli (301 → 301 → 301). Dbaj o krótki łańcuch, najlepiej 1 skok.

– Wtyczka i serwer “walczą” o reguły. Lepiej trzymać przekierowania na poziomie serwera (wydajniej), a wtyczek używać do pojedynczych przypadków.

– Miękkie 404 zamaskowane jako 200. Google to znajdzie i obniży ocenę jakości.

– Zmiana wzorca URL bez planu przekierowań. Zawsze rób mapping stary→nowy przed wdrożeniem.

– Brak współpracy zespołowej. Dev zmienił ścieżki, marketing nie wiedział — w efekcie kampanie prowadzą w próżnię. Komunikacja oszczędza pieniądze.

– Zbyt agresywny Broken Link Checker na produkcji WordPressa. Może mocno obciążać serwer — lepiej skanuj staging lub używaj narzędzi desktopowych.

Dobre praktyki na przyszłość: prewencja zamiast gaszenia pożarów

– Mapowanie URL-i przed każdym większym deployem. Ustal, które ścieżki się zmienią, przygotuj przekierowania i testy.

– Staging i checklisty QA. Testuj nowe wersje na środowisku testowym z kopią danych.

– Wersjonowanie zasobów statycznych. Hash w nazwach plików (versioning) i odpowiednia konfiguracja CDN ogranicza 404 na JS/CSS po deployu.

– Audyt linków wewnętrznych co kwartał. W e‑commerce zmiany asortymentu to norma — linki też muszą nadążać.

– Polityka dla produktów wycofanych. Predefiniuj zasady: 301 do zamiennika, 301 do kategorii lub 410 z informacją.

– Edukacja zespołu. Krótka lista zasad dla osób dodających treści i tworzących kampanie: jak linkować, gdzie zgłaszać zmiany URL-i.

Przykład z życia: szybka naprawa, realne efekty

Sklep na PrestaShopie po migracji serwera stracił ok. 20% ruchu organicznego. Raport GSC pokazał setki 404 na kartach produktu. Winny? Błędnie wygenerowany .htaccess oraz moduł SEO zmieniający slug-i. Plan:

– Regeneracja .htaccess, wyłączenie modułu, odtworzenie domyślnych wzorców URL.

– Lista 600 starych adresów → hurtowy import 301 do nowych.

– Wygenerowanie sitemapy i prośba o ponowne indeksowanie.

Po 10 dniach 404 spadły o 92%, a ruch wrócił do poziomów sprzed migracji — z lekkim +5% dzięki czytelniejszym adresom i lepszym internal linking.

Kiedy rozważyć pomoc specjalisty

– Masz setki tysięcy URL-i, skomplikowane filtrowanie i wersje językowe.

– Wdrożenia CI/CD często zmieniają strukturę zasobów.

– Występują jednocześnie problemy na warstwie aplikacji (WP/PS), serwera (Nginx/Apache), CDN i baz danych.

– Potrzebujesz automatyzacji przekierowań (np. generowanych na podstawie reguł) i raportowania.

Dobry specjalista skróci czas naprawy i zminimalizuje ryzyko dodatkowych błędów.

Szybkie ściągi konfiguracyjne

– WordPress + Apache: upewnij się, że mod_rewrite włączony, a .htaccess zawiera domyślne reguły.

– WordPress + Nginx: try_files $uri $uri/ /index.php?$args; w bloku location /.

– PrestaShop + Apache: .htaccess z /tools/htaccess.txt oraz AllowOverride All w konfiguracji katalogu docroot.

– PrestaShop + Nginx: oficjalne rekomendacje Presta (location dla /img, /themes, przekierowania do index.php).

– Cloudflare: Page Rules/Cache Rules nie powinny “zjadać” dynamicznych ścieżek. Wyklucz /wp-admin/ i odpowiednie endpointy.

– HTTP kody: prawidłowe 404/410 dla nieistniejących, 301 dla stałych przeniesień, 302 tylko tymczasowo.

Jak napisać sensowne przekierowanie (pro tip)

– Stare adresy grupuj po wzorcach (np. /blog/2020/ → /poradnik/). Reguła serwerowa (RewriteRule) bywa skuteczniejsza niż setki pojedynczych wpisów.

– Zawsze testuj łańcuch: stary → nowy. Ma być 301 i koniec ścieżki, bez “pętli”.

– Nie przekierowuj wszystkiego na stronę główną. To zły sygnał dla SEO i użytkowników. Kieruj kontekstowo: produkt → podobny produkt lub kategoria.

Podsumowanie: sprawna naprawa i spokój na dłużej

Błędy 404 to codzienność, ale nie muszą boleć. W WordPressie najczęściej wystarczy prawidłowo odświeżyć permalinki, zadbać o .htaccess/Nginx i stworzyć rozsądne 301. W PrestaShopie kluczowe są przyjazne URL-e, poprawny .htaccess, czysty cache i dobra polityka dla asortymentu, który znika lub zmienia adresy. Gdy dodasz do tego monitoring, regularne audyty linków i przemyślaną stronę 404, zobaczysz, że problem przestaje wracać jak bumerang.

Jeśli działasz krok po kroku — diagnoza, szybkie wygrane, przekierowania, porządki w linkach i stabilne reguły serwera — odzyskasz utracony ruch, ochronisz kampanie i dasz użytkownikom wrażenie, że nawet gdy zboczą z drogi, umiesz ich bezpiecznie sprowadzić z powrotem. I o to w tym wszystkim chodzi.