Zmiana struktury permalinków może ujawnić dwa różne problemy. Pierwszy jest techniczny: serwer nie przekazuje nowych ścieżek do WordPressa i podstrony zwracają 404. Drugi jest SEO: nowe URL-e działają, ale stare adresy, które Google i użytkownicy znali, nie mają przekierowań. Oba wymagają innego działania.
Szybka odpowiedź
Jeśli po zapisaniu permalinków nagle wszystkie podstrony dają 404, sprawdź reguły rewrite na Apache lub konfigurację try_files na Nginx. Jeżeli tylko stare URL-e przestały działać po świadomej zmianie slugów, przygotuj 301 do nowych odpowiedników. Nie generuj dodatkowych zmian w strukturze, dopóki nie uporządkujesz pierwszej.
Flush rewrite nie naprawi serwera bez obsługi rewrite
Ponowne zapisanie ustawień permalinków każe WordPressowi odświeżyć reguły, ale Apache musi pozwalać na ich użycie, a Nginx musi mieć własną konfigurację. Jeśli środowisko nie przekazuje żądań do index.php, panel może wyglądać poprawnie, lecz publiczne strony nadal zwracają 404.
Zmiana sluga to zmiana adresu
Jeśli artykuł był długo dostępny pod /stary-poradnik/ i zmienisz go na /nowy-poradnik/, stary URL nie powinien po prostu zniknąć. Ustaw 301 do nowego odpowiednika i zaktualizuj linki wewnętrzne. Dzięki temu użytkownicy, backlinki i roboty wyszukiwarki trafią w właściwe miejsce.
Nie wszystko, co wygląda jak 404, pochodzi z WordPressa
CDN, reverse proxy albo serwer może mieć własne reguły i strony błędu. Sprawdź nagłówki oraz access log. Jeśli żądanie nie dochodzi do WordPressa, edycja permalinków niczego nie zmieni. To szczególnie ważne po migracji między Apache i Nginx.
Custom post types i reguły wtyczek
Wtyczki rejestrujące własne typy treści i endpointy mogą dodawać reguły rewrite. Po zmianie konfiguracji czasem potrzebny jest jednorazowy flush. Nie wywołuj jednak kosztownego flush_rewrite_rules() przy każdym żądaniu — to powinno dziać się tylko przy zdarzeniach konfiguracji.
404 po migracji domeny
Jeżeli ścieżki są poprawne, ale stara domena zwraca 404 zamiast 301, problem dotyczy migracji domeny, nie samych permalinków. Sprawdź mapę przekierowań i zachowaj stare URL-e jako wejścia do nowych treści.
Jak potwierdzić, że naprawa naprawdę działa?
Po naprawie wykonaj crawl listy starych i nowych adresów. Nowe powinny zwracać 200, a stare — 301 do odpowiadających treści albo celowe 404/410, jeśli zostały usunięte bez zamiennika. Sprawdź również linki w menu, treści i sitemapie. Jeśli wewnętrzne linkowanie nadal prowadzi przez 301, napraw je w źródle.
Co obserwować po zmianie?
W kolejnych dniach obserwuj 404 w logach i Search Console. Nowe błędy często ujawniają rzadziej odwiedzane wpisy, stare kampanie lub linki zewnętrzne. Nie wszystkie trzeba przekierować, ale te z ruchem, backlinkami lub oczywistym nowym odpowiednikiem warto obsłużyć świadomie.
Kiedy przekazać temat dalej?
Eskaluj, gdy zmiana permalinków objęła tysiące wpisów albo niestandardowe typy treści. Reguły mogą kolidować, a masowe redirecty wymagają przemyślanej konfiguracji serwera lub warstwy aplikacji, aby nie stały się kolejnym źródłem opóźnień.
Praktyczny scenariusz diagnostyczny
Typowy przypadek: strona główna działa, ale wszystkie wpisy zwracają 404 po zmianie struktury permalinków. To wskazuje raczej na rewrite niż brak treści. W panelu zapisz ustawienia bez zmiany wartości, aby WordPress odświeżył reguły, a następnie sprawdź konfigurację Apache/Nginx. Jeżeli zmieniłeś publiczne URL-e, przygotuj 301 ze starej struktury na nową — samo naprawienie 404 nie odzyskuje wartości starych linków. Przetestuj wpis, kategorię, stronę, niestandardowy typ treści i paginację. W logach zobacz, czy request w ogóle trafia do WordPressa. Dzięki temu odróżnisz błąd reguł serwera od sytuacji, w której aplikacja świadomie zwraca 404 dla nieistniejącego obiektu.
Dodatkowa kontrola po naprawie
Po naprawie warto przeskanować sitemapę i najważniejsze linki wewnętrzne. Jeżeli nowe adresy działają tylko dlatego, że serwer wykonuje kilka kolejnych przekierowań, użytkownik może tego nie zauważyć, ale crawl i wydajność będą gorsze. Docelowy link wewnętrzny powinien prowadzić od razu do kanonicznego URL-u. Sprawdź też stare adresy z logów lub Search Console — szczególnie te, które wcześniej miały ruch albo backlinki. Dla nich brak 301 oznacza utratę wartości, nawet jeśli obecna nawigacja strony jest już poprawna.
Bezpieczna kolejność działań
- Sprawdź, czy 404 dotyczy wszystkich podstron czy tylko starych URL-i.
- Zweryfikuj rewrite w Apache/.htaccess lub Nginx.
- Odśwież reguły permalinków po kopii konfiguracji.
- Dla zmienionych slugów przygotuj bezpośrednie 301.
- Zaktualizuj linkowanie wewnętrzne i sitemapę.
- Przejrzyj 404 w logach/Search Console po wdrożeniu.
Czego nie robić
Nie zmieniaj struktury permalinków tylko dlatego, że inny format „wygląda bardziej SEO”. Jeśli obecne URL-e są zaindeksowane i działają, migracja musi mieć konkretny powód i mapę 301.
Powiązane poradniki HeatLogic
Potrzebujesz pomocy?
Jeżeli po zmianie permalinków lub migracji pojawiły się setki 404, możemy rozdzielić błędy techniczne od brakujących redirectów i przygotować mapę naprawczą bez kolejnej zmiany URL-i.
Najczęściej zadawane pytania
Czy zapisanie ustawień permalinków naprawia 404?
Często odświeża reguły WordPressa, ale nie pomoże przy błędnej konfiguracji Nginx lub wyłączonym rewrite na serwerze.
Czy trzeba robić 301 po zmianie sluga?
Tak, jeśli stary URL był publiczny, indeksowany lub linkowany.
Czy 404 szkodzi SEO?
Pojedyncze celowe 404 są normalne. Masowe 404 po migracji lub zmianie struktury mogą tracić ruch i sygnały z linków.
Czy można przekierować wszystkie 404 na stronę główną?
Nie jest to dobry model. Redirect powinien prowadzić do najbardziej odpowiadającej treści, a nie ukrywać wszystkie brakujące adresy.