Przyjazne URL SEO — architektura adresów dla całej witryny
Struktura URL witryny to fundament architektury informacji i ważny czynnik SEO. Dobrze zaprojektowana hierarchia URL pomaga robotom wyszukiwarek zrozumieć organizację treści, ułatwia budowanie tematycznych silosów i pozytywnie wpływa na user experience. Generator Slug WikiPlus generuje optymalne slugi dla każdej strony, ale równie ważna jest przemyślana struktura całości — jak slugi się łączą w spójną architekturę URL.
Hierarchia URL — flat vs. deep structure
Architektura URL może być płaska (flat) lub głęboka (deep). Płaska: example.com/artykul-1, example.com/artykul-2 — wszystkie strony na tym samym poziomie. Głęboka: example.com/kategoria/podkategoria/artykul — wiele poziomów hierarchii. Rekomendacja dla SEO: unikaj nadmiernej głębokości. Google może crawlować i indeksować strony zagnieżdżone głęboko, ale preferuje płaską strukturę gdzie ważne strony są bliżej domeny głównej. Generalnie nie więcej niż 3-4 poziomy: example.com/blog/seo/przyjazne-url — to akceptowalne. example.com/sklep/elektronika/laptopy/lenovo/2025/1234-nazwa — za głęboko. Dla blogów: example.com/blog/slug lub example.com/slug. Dla e-commerce: example.com/kategoria/produkt lub example.com/produkt. Dla Wikipedia-style: example.com/wiki/slug. Breadcrumb Schema pomaga Google zrozumieć hierarchię nawet przy płaskiej strukturze URL.
Schematy URL dla różnych typów witryn
Różne typy witryn wymagają różnych podejść do struktury URL. Blog: `/blog/slug` lub dla dużych serwisów `/kategoria/slug`. Rok w URL (`/2026/05/slug`) jest dyskusyjny — pomaga przy unikalności slugów, ale datuje treść (evergreen content wygląda starze). E-commerce: `/kategoria/podkategoria/produkt` lub `/p/slug`. Unikaj zbędnych parametrów w URL produktu. SaaS/Aplikacja: `/features/nazwa-funkcji`, `/pricing`, `/blog/slug`. Wielojęzyczna: subdirectory (`/pl/slug`) vs subdomain (`pl.example.com`) vs ccTLD (`example.pl/slug`). Google traktuje wszystkie podobnie, ale subdirectory jest najprostsze w implementacji. Dokumentacja: `/docs/kategoria/slug` lub `/docs/wersja/slug`. Platforma kursów: `/courses/slug`, `/courses/slug/lesson/slug`. Newsy: `/news/YYYY/MM/DD/slug` lub `/news/slug` (daty pomagają odróżnić artykuły o tej samej nazwie tygodniami).
Paginacja URL — /page/2 czy ?page=2?
Paginacja list artykułów i produktów generuje wiele URL dla tej samej kategorii/sekcji — co wymaga przemyślanej strategii. Opcje URL paginacji: `/kategoria/page/2/` — czytelny, przyjazny dla SEO. `/kategoria/?page=2` — czytelny, ale parametr. `/kategoria/2` — krótszy, ale może mylić z rokiem lub ID. Rekomendacja Google: brak jednoznacznej preferencji dla formatu. Ważniejsze: każda strona paginacji powinna mieć `rel="canonical"` wskazujący na siebie samą (nie na stronę 1). Opcjonalnie: `<link rel="prev">` i `<link rel="next">` (Google oficjalnie je ignoruje od 2019, ale Bing je respektuje). Treść stron 2, 3... nie powinna być noindex — tracisz indeksowanie produktów/artykułów na tych stronach. Alternatywa: infinite scroll z canonicalized URL lub load more button.
Migracja URL — redirecty 301 i zachowanie SEO
Zmiana struktury URL istniejącej witryny to poważna operacja wymagająca starannego planowania. Redirect 301 (Permanent Redirect) to sposób na poinformowanie wyszukiwarek, że strona przeniosła się na stały URL. Google przenosi 'link juice' (autorytet) przez 301 — nie tracisz rankingów (choć może być kilkutygodniowe wahnięcie). Workflow bezpiecznej migracji URL: 1. Zmapuj stare URL na nowe (arkusz Excel: stary URL → nowy URL). 2. Skonfiguruj wszystkie 301 redirecty na serwerze (nginx: `rewrite`, Apache: .htaccess RewriteRule, Cloudflare: Redirect Rules). 3. Aktualizuj wewnętrzne linki do nowych URL — nie polegaj wyłącznie na redirectach. 4. Prześlij nową sitemapę XML do Google Search Console. 5. Użyj Google Search Console URL Inspection dla kluczowych URL. 6. Monitoruj Coverage Errors przez 4-8 tygodni. Błąd: redirect chain — stary1 → stary2 → nowy. Google podąża za łańcuchem, ale z obniżonym link juice. Napraw: stary1 → nowy bezpośrednio.
Często zadawane pytania
- Czy data w URL (np. /2026/05/) wpływa na SEO?
- Technicznie nie — Google nie używa daty w URL jako czynnika rankingowego. Praktycznie: data w URL sprawia, że treści evergreen wyglądają na stare (użytkownik może pomyśleć, że 2019/05 to przestarzałe informacje). Dla news i aktualności daty w URL są naturalne. Dla poradników i evergreen content — lepiej bez dat.
- Czy www.example.com i example.com to różne URL?
- Tak, technicznie to różne domeny. Powinieneś skonfigurować redirect 301 z jednej wersji na drugą (preferuj wybraną) i skonfigurować canonical rel='canonical' na właściwą wersję. Dodaj obie wersje do Google Search Console i ustaw preferowaną domenę.
- Jak długo Google pamięta stary URL po redirect 301?
- Google oficjalnie twierdzi, że przestaje serwować stary URL po kilku miesiącach przy prawidłowym redirectzie. Jednak stare URL mogą pozostawać w indeksie przez rok lub dłużej jeśli mają silne backlinki. Utrzymuj redirect 301 przez minimum rok po migracji URL.