Permalinks WordPress - struktura URL

Permalink to stały, publiczny adres URL pojedynczego wpisu, strony, kategorii czy tagu. Słowo bierze się od *permanent link* - i to słowo *permanent* warto traktować poważnie, bo struktura URL należy do tych ustawień, które ustawia się raz, na starcie, i których potem nie rusza się bez powodu.

Dla Google adres URL jest jednym z pierwszych sygnałów o tym, czego dotyczy strona. URL z czytelnym slugiem (np. `/jak-przyspieszyc-wordpress/`) komunikuje temat zanim robot przeczyta treść. URL techniczny (`/?p=123`) nie mówi nic - ani robotowi, ani człowiekowi, który widzi link w wynikach wyszukiwania lub kopiuje go do wiadomości.

WordPress rozróżnia trzy pojęcia, które często są mylone: permalink (cały adres), slug (ostatni, opisowy fragment URL) oraz strukturę permalinków (szablon, według którego WordPress buduje wszystkie adresy). Slug zmienisz w pojedynczym wpisie, strukturę - globalnie w ustawieniach. To rozróżnienie ma znaczenie praktyczne, bo zmiana struktury dotyka całej witryny naraz, a zmiana sluga - tylko jednego adresu.

Warto rozumieć jeszcze jeden mechanizm: przy strukturze z nazwą wpisu WordPress nie odwzorowuje fizycznego katalogu na dysku - tak jak robił to klasyczny serwis statyczny. Adres `/jak-przyspieszyc-wordpress/` nie wskazuje na plik w folderze, lecz jest tłumaczony przez reguły przepisywania URL na zapytanie do bazy danych (klasa WP_Query pobiera właściwy wpis po slugu). Dlatego permalinki w ogóle wymagają działającego modułu rewrite po stronie serwera - i dlatego ich konfiguracja bywa źródłem błędów 404, do których wrócimy niżej.

WordPress udostępnia kilka gotowych wzorców plus opcję własnej struktury budowanej ze znaczników (*structure tags*). Każdy wariant ustawisz w Ustawienia → Bezpośrednie odnośniki. Poniżej zestawienie tego, co znajdziesz w panelu, wraz z oceną pod kątem SEO i czytelności.

WordPress używa też nazewnictwa technicznego: URL-e typu `/?p=123` to *Plain Permalinks* (zwane też brzydkimi), a wszystkie warianty słowne to *Pretty Permalinks*. Istnieje jeszcze trzeci typ, *Almost Pretty*, z prefiksem `/index.php/` w adresie - spotkasz go na serwerach, gdzie nie da się włączyć modułu przepisywania URL. W praktyce na poprawnie skonfigurowanym hostingu nie powinien być potrzebny.

Własną strukturę składasz ze znaczników. Najczęściej używane to `%postname%` (slug wpisu), `%category%` (kategoria), `%year%`, `%monthnum%`, `%day%` oraz `%post_id%`. Łączysz je w dowolny wzór - np. `/%category%/%postname%/` da adres z kategorią przed nazwą wpisu.

Struktura `/%postname%/` wygrywa, bo realizuje trzy cele naraz: jest krótka, opisowa i ponadczasowa. Krótki URL łatwiej zmieścić w całości w wynikach Google, łatwiej go skopiować, udostępnić i zapamiętać. To przekłada się na CTR i na to, jak link wygląda po wklejeniu do maila czy mediów społecznościowych.

Brak daty w adresie to argument biznesowy, nie tylko techniczny. Treść poradnikowa (evergreen) z URL-em `/jak-skonfigurowac-woocommerce/` nie starzeje się w oczach użytkownika. Ten sam artykuł pod adresem `/2023/04/jak-skonfigurowac-woocommerce/` natychmiast sygnalizuje wiek - i obniża chęć kliknięcia, nawet jeśli treść została wczoraj zaktualizowana.

Kiedy data ma sens? Wyłącznie dla serwisów newsowych i czysto blogowych, gdzie aktualność jest częścią wartości, a archiwum buduje się rocznikami. Dla firmowej strony, sklepu, bazy wiedzy czy bloga eksperckiego - data w URL to obciążenie, nie atut.

Konfiguracja zajmuje chwilę: wchodzisz w Ustawienia → Bezpośrednie odnośniki, zaznaczasz Nazwa wpisu, klikasz Zapisz zmiany. WordPress automatycznie zaktualizuje plik `.htaccess` (na Apache) lub reguły rewrite (na Nginx). I to tyle - od tego momentu wszystkie nowe wpisy dostają czyste adresy.

Jest też niuans techniczny, o którym rzadko się mówi: przy `/%postname%/` slug musi być unikalny w obrębie całej witryny, bo to on identyfikuje treść. Gdy opublikujesz dwa wpisy o tym samym tytule, WordPress automatycznie doklei do drugiego sluga końcówkę `-2` (np. `/cennik-2/`). Takie adresy warto wyłapywać i poprawiać ręcznie, bo `-2` w URL wygląda nieprofesjonalnie i sugeruje duplikat. Przy strukturach z datą problem nie występuje, bo data sama różnicuje adresy - to jeden z nielicznych argumentów technicznych za datą, ale w praktyce łatwiej pilnować unikalnych tytułów.

W skrócie: jeśli zakładasz nową stronę i nie masz powodu twierdzić inaczej, ustaw Nazwa wpisu od razu, jeszcze przed publikacją pierwszych treści. Najtańsza decyzja to ta, której nie trzeba potem cofać przekierowaniami.

To najczęstsze pytanie po wyborze samego `%postname%` - i odpowiedź brzmi: zazwyczaj nie, ale są wyjątki. Kategoria w adresie buduje wizualną hierarchię (`/wordpress/permalinki/`), co bywa pomocne w dużych, mocno usystematyzowanych serwisach. Problem zaczyna się przy edycji.

Gdy zmienisz kategorię wpisu lub przeniesiesz go między działami, jego URL się zmieni - a wtedy potrzebujesz przekierowania 301, żeby nie stracić pozycji i nie wygenerować błędów 404. Przy dziesiątkach przenosin robi się z tego dług techniczny. Drugi haczyk: jeśli wpis ma kilka kategorii, WordPress wstawi do URL tylko jedną z nich, wybraną alfabetycznie - co bywa nieintuicyjne.

Nasza rekomendacja domyślna to `/%postname%/`. Po kategorię sięgaj świadomie - gdy struktura działów jest przemyślana, stała i naprawdę pomaga użytkownikowi zrozumieć, gdzie się znajduje.

Niezależnie od głównej struktury WordPress dokleja do adresów archiwów prefiks kategorii i tagu - domyślnie `/category/` i `/tag/` (np. `example.pl/category/wordpress/`). Te prefiksy zmienisz w tej samej sekcji ustawień, w polach Baza kategorii i Baza tagów. Część redakcji skraca `category` do czegoś krótszego lub usuwa go wtyczką, ale to znów oznacza zmianę URL-i archiwów i konieczność przekierowań - więc traktuj to jak każdą inną zmianę struktury, nie jak kosmetykę.

Najważniejsza zasada: zmiana struktury permalinków na żywej, zaindeksowanej witrynie zmienia URL-e wszystkich treści naraz - a każdy stary adres, który Google zna i ma w rankingu, staje się błędem 404, jeśli nie zadbasz o przekierowanie. To jest moment, w którym najłatwiej stracić pozycje, więc warto go przejść metodycznie.

Perspektywa KC Mobile. W naszych wdrożeniach najczęstszy problem nie leży w samym wyborze struktury - tu prawie zawsze ustawiamy `/%postname%/` - tylko w nieprzemyślanej zmianie URL-i po starcie strony. Gdy klient zmienia strukturę permalinków po miesiącach indeksacji i pomija przekierowania 301, efektem są setki błędów 404 i widoczny spadek ruchu organicznego. Dlatego przy każdej przebudowie najpierw eksportujemy listę starych adresów, a dopiero potem ruszamy ustawienia.

Kolejność, którą stosujemy przy migracjach:

1. Backup - pełna kopia plików i bazy danych przed jakąkolwiek zmianą. To Twoja siatka bezpieczeństwa.
2. Eksport listy starych URL-i - z mapy witryny, z Google Search Console lub crawlerem (np. Screaming Frog). Potrzebujesz wiedzieć, co przekierowujesz.
3. Zmiana struktury w Ustawienia → Bezpośrednie odnośniki.
4. Mapowanie 301 - każdy stary adres kierujesz na nowy odpowiednik, najlepiej wtyczką Redirection lub regułami w `.htaccess`.
5. Weryfikacja - przeklikaj kluczowe URL-e, sprawdź odpowiedzi serwera (mają zwracać 301, potem 200), zgłoś nową mapę witryny w Google Search Console.

Przekierowanie 301 (stałe) przekazuje do nowego adresu prawie cały zgromadzony autorytet linkowy, dlatego przy zmianie URL-i to jedyny poprawny typ - nigdy 302 (tymczasowe), które Google traktuje inaczej. Po dobrze wykonanej migracji spadki pozycji są zwykle przejściowe i wracają w ciągu kilku tygodni, gdy Google przemapuje adresy. Po źle wykonanej - zostają na stałe. Jeśli zależy Ci na stabilnej widoczności, ten etap warto skonsultować z kimś, kto robił to wcześniej; my omawiamy go zawsze, gdy klient zleca nam pozycjonowanie SEO po przebudowie strony.

Gdy zmiana jest poważna (przebudowa całej witryny, przejście ze starego CMS), wykonujemy ją najpierw na kopii roboczej (staging), tam testujemy mapę przekierowań i dopiero zweryfikowany zestaw 301 wgrywamy na produkcję. Dzięki temu na żywej stronie nie ma okna, w którym adresy zwracają 404. To różnica między migracją kontrolowaną a gaszeniem pożaru po fakcie.

Slug to ostatni, opisowy fragment URL i element, który masz pod pełną kontrolą przy każdym wpisie. Dobry slug jest krótki (zwykle 3-5 słów), zawiera główne słowo kluczowe i nie powtarza tytułu w pełnej, rozwlekłej formie. WordPress generuje slug automatycznie z tytułu, ale długie tytuły dają długie, słabe slugi - dlatego warto je skracać ręcznie.

Zasady, które stosujemy:

• Tylko małe litery i myślniki jako separatory (nie podkreślenia).
• Bez polskich znaków w slugu - `ą`, `ć`, `ę`, `ł` itd. są w URL kodowane procentowo (np. `%C4%85`), co psuje wygląd linku w wynikach, w narzędziach SEO i przy udostępnianiu. Treść strony zachowuje pełne diakrytyki, ale sam slug zostawiamy w ASCII.
• Bez słów wypełniających typu *jak*, *oraz*, *i* tam, gdzie nie są potrzebne dla sensu.
• Bez dat i parametrów w ręcznie ustawianym slugu.

Przykład różnicy: dobry slug to `/optymalizacja-obrazow-wordpress/`, słaby - `/2026/06/jak-mozna-w-prosty-sposob-zoptymalizowac-wszystkie-obrazy-na-stronie-wordpress/`. Pierwszy jest czytelny dla człowieka i robota, drugi rozmywa słowa kluczowe i wygląda jak spam.

Osobny temat to sklepy na WooCommerce. WooCommerce ma własne, niezależne ustawienia permalinków produktów i kategorii produktów (WooCommerce → Ustawienia → Produkty → lub w samej sekcji Bezpośrednie odnośniki). Domyślnie produkty trafiają pod `/product/`, a kategorie pod `/product-category/`. Wiele sklepów spolszcza te bazy (np. `/sklep/`, `/kategoria-produktu/`) - i tu obowiązuje ta sama reguła co wszędzie: jeśli sklep już działa i jest zaindeksowany, każda zmiana baz produktowych wymaga przekierowań 301, inaczej tracisz pozycje kart produktów, które zwykle generują sprzedaż.

Dobrze ustawiony slug pracuje też na dopasowanie do zapytań - jeśli ktoś szuka frazy zbieżnej ze słowami w adresie, Google potrafi pogrubić je w wynikach, co dodatkowo podnosi klikalność. To nie jest czynnik rankingowy najwyższej wagi, ale przy minimalnym koszcie wdrożenia po prostu się opłaca.

Najczęstszy objaw problemu z permalinkami to działająca strona główna przy błędach 404 na podstronach. Przyczyna prawie zawsze leży w regułach przepisywania URL, które wypadły z synchronizacji - typowo po migracji, zmianie serwera albo aktualizacji konfiguracji.

Pierwszy ruch, który rozwiązuje większość przypadków, to *flush* reguł przepisywania: wejdź w Ustawienia → Bezpośrednie odnośniki i kliknij Zapisz zmiany, nawet niczego nie zmieniając. WordPress wygeneruje od nowa reguły rewrite i (na Apache) przepisze sekcję w `.htaccess`. Jeśli to nie pomaga, problem jest niżej - po stronie serwera.

Na Apache kluczowy jest aktywny `mod_rewrite` i zapisywalny `.htaccess`. Na Nginx nie ma `.htaccess` - przepisywanie URL obsługuje blok `location` w konfiguracji serwera, więc reguły dla WordPress muszą być wpisane bezpośrednio w pliku konfiguracyjnym. To częsta pułapka przy przenosinach z hostingu Apache na Nginx.

Drobny, ale częsty przypadek: po włączeniu lub przebudowie pamięci podręcznej (cache strony, CDN) stare URL-e mogą być serwowane mimo zmiany struktury. Jeśli flush rewrite nie pomaga, a strona korzysta z cache, wyczyść go w pierwszej kolejności - zanim zaczniesz grzebać w konfiguracji serwera. Kolejność diagnozy oszczędza godziny: najpierw flush permalinków, potem cache, dopiero na końcu serwer i moduł rewrite.

Pomagamy w tym na co dzień – strony internetowe.