Po co w ogóle porządkować adresy

Trzy powody, po kolei od najbardziej praktycznego.

Pierwszy jest ludzki. Adres pojawia się przy udostępnianiu linku, w komunikatorze, w mailu, w prezentacji. Adres złożony z identyfikatorów i parametrów nic nie mówi, więc nikt go nie klika w ciemno i nikt go nie zapamiętuje. Czytelny adres jest częścią komunikacji, nawet jeśli w wynikach wyszukiwania Google zwykle wyświetla dziś ścieżkę okruszków, a nie surowy adres.

Drugi jest techniczny. Każdy unikalny adres to dla robota osobna strona do sprawdzenia. Jeśli ta sama karta produktu jest dostępna pod pięcioma wariantami — z parametrem sortowania, z identyfikatorem sesji, z parametrem kampanii, z wielką i małą literą — robot odwiedzi je wszystkie, zanim zorientuje się, że to jedno i to samo. W dużym sklepie to jest różnica między szybkim a wolnym indeksowaniem nowych produktów.

Trzeci jest organizacyjny. Struktura adresów odbija strukturę informacji. Jeśli nie da się jej zaprojektować, to zwykle znaczy, że nikt nie zdecydował, co jest kategorią, a co filtrem — i ten problem wróci przy nawigacji, przy linkowaniu wewnętrznym i przy planowaniu treści.

Zasady, które naprawdę mają znaczenie

Krótka lista. Wszystko poza nią to detale, o które nie warto się bić.

• Słowa zamiast identyfikatorów. Adres oparty na nazwie kategorii i produktu jest czytelny dla człowieka i daje robotowi kontekst. Numer w bazie nie daje żadnego.

• Myślniki jako separator, nie podkreślenia. Google zaleca myślniki od lat i nie ma powodu z tym eksperymentować.

• Tylko małe litery. Ścieżka adresu jest wrażliwa na wielkość znaków, więc dwa zapisy tej samej nazwy to dwa różne adresy dla robota, choć dla serwera bywają tym samym.

• Krótko i bez powtórzeń. Nazwa kategorii powtórzona trzy razy w ścieżce nie pomaga, a utrudnia czytanie. Odcinam też słowa funkcyjne, jeśli nic nie wnoszą.

• Bez dat i numerów wersji w adresach treści, które będą aktualizowane. Data w adresie zamyka drogę do odświeżenia artykułu bez zmiany adresu.

• Jedna konsekwentna decyzja o ukośniku na końcu i przekierowanie z drugiego wariantu. Adres z ukośnikiem i bez to dwa różne adresy.

• Jeden protokół i jedna wersja domeny. Wszystkie pozostałe warianty przekierowane, wersja kanoniczna wskazana jednoznacznie.

Czego na tej liście nie ma: obsesji na punkcie liczby poziomów zagnieżdżenia. Głębokość ścieżki sama w sobie nie jest problemem — problemem jest strona, do której z żadnego miejsca nie prowadzi link.

Polskie znaki i kodowanie

Pytanie o „ł” i „ą” w adresach wraca regularnie, więc krótko: technicznie to działa, przeglądarki i wyszukiwarki radzą sobie ze znakami zakodowanymi procentowo.

Praktycznie unikam tego z dwóch powodów. Po pierwsze, taki adres skopiowany i wklejony w innym systemie zamienia się w ciąg znaków ucieczki, którego nikt nie przeczyta — a w mailu czy poście wygląda jak błąd. Po drugie, część narzędzi, serwerów i wtyczek nadal potrafi się na tym potknąć, więc kupujesz sobie ryzyko bez żadnej korzyści.

Standardowe rozwiązanie to transliteracja bez ogonków przy generowaniu adresu i zostawienie polskich znaków tam, gdzie ich miejsce: w tytule, nagłówku i treści. To one są czytane przy ocenie treści, nie ścieżka adresu.

Parametry, filtry i sortowanie

To najczęstsze źródło rozjazdu w sklepach i serwisach z filtrowaniem.

Warto wiedzieć o zmianie, którą Google wprowadziło tej wiosny: narzędzie do obsługi parametrów URL w Search Console przestało działać. Zostało wycofane w kwietniu, a Google uzasadnił to tym, że znikoma część konfiguracji była w praktyce użyteczna, bo robot sam radzi sobie z rozpoznawaniem nieistotnych parametrów. Konsekwencja jest prosta: nie ma już przełącznika w panelu, którym można było posprzątać po bałaganie w adresach. Zostają narzędzia po naszej stronie.

Co robię zamiast tego, w tej kolejności:

• Kanoniczny adres na każdej wersji z parametrami, wskazujący czystą wersję strony. To podstawa i zwykle wystarcza przy sortowaniu i paginacji parametrycznej.

• Porządek w linkowaniu wewnętrznym. Jeśli witryna nie linkuje do wariantów z parametrami, robot trafia na nie znacznie rzadziej. To działa lepiej niż jakakolwiek dyrektywa.

• Blokada w robots.txt dla parametrów, które generują nieskończone kombinacje — sortowanie po kilku wymiarach naraz, kalendarze, wyniki wyszukiwania wewnętrznego. Z zastrzeżeniem, że blokada w robots.txt nie usuwa strony z indeksu, tylko wstrzymuje jej odwiedzanie.

• Identyfikatory sesji poza adresem. Jeśli sklep nadal je wstawia, to jest zadanie numer jeden, bo każdy użytkownik generuje wtedy własny zestaw adresów.

Osobna decyzja dotyczy filtrów, które mają być stronami docelowymi — na przykład kategorii łączonej z marką. Tam warto mieć czysty, statyczny adres i normalną stronę, a nie parametr. Ale wybieram wtedy kilka kombinacji o realnym popycie, nie wszystkie możliwe.

Hierarchia: katalogi, kategorie, produkty

Dwa pytania wracają najczęściej.

Czy kategoria ma być w adresie produktu? Wersja z kategorią jest czytelniejsza dla człowieka, ale rodzi problem, gdy produkt należy do kilku kategorii albo zmienia przypisanie — wtedy trzeba pilnować, żeby nie powstały dwa adresy tej samej karty, i przekierowywać po każdej zmianie w katalogu. Wersja płaska, gdzie produkt siedzi bezpośrednio pod jednym segmentem, jest odporniejsza w utrzymaniu i w sklepach z ruchliwym asortymentem wybieram ją częściej.

Katalog czy subdomena dla bloga i pomocy? Katalog na tej samej domenie jest prostszy w utrzymaniu i nie wymaga osobnego zarządzania, więc jeśli nie ma twardego powodu technicznego, wybieram katalog.

I rzecz najważniejsza w całej sekcji: struktura adresów ma odpowiadać temu, jak ludzie szukają, a nie temu, jak wygląda schemat bazy danych. Jeśli firma dzieli ofertę inaczej niż klienci o niej myślą, to widać w adresach jako pierwsze.

Zmiana adresów: kiedy warto, a kiedy nie

Domyślna odpowiedź brzmi: nie zmieniaj adresów tylko dlatego, że mogłyby być ładniejsze. Każda migracja to ryzyko utraty części widoczności i praca, którą trzeba wykonać dokładnie, a nie w połowie.

Zmieniam wtedy, gdy adresy zawierają identyfikatory sesji, gdy ta sama treść jest dostępna pod wieloma adresami bez kanonizacji, gdy struktura kompletnie nie odpowiada nawigacji albo gdy i tak trwa przebudowa witryny. W tym ostatnim przypadku porządek w adresach jest tanim dodatkiem, a nie osobnym projektem.

Gdy już decyduję się na zmianę, kolejność jest zawsze taka sama:

• Pełny wykaz starych adresów — z sitemapy, z raportu skuteczności w Search Console i z logów serwera. Trzy źródła, bo żadne pojedyncze nie jest kompletne.

• Mapa jeden do jednego, stary adres na nowy. Przekierowania stałe, nie tymczasowe, i nigdy hurtem na stronę główną — przekierowanie na stronę główną Google traktuje jak błąd i tak też to wygląda dla użytkownika.

• Aktualizacja linków wewnętrznych, menu i sitemapy na nowe adresy. Przekierowanie ma być zabezpieczeniem dla linków z zewnątrz, nie sposobem nawigacji po własnej witrynie.

• Sprawdzenie, czy nie powstały łańcuchy przekierowań, gdy adresy zmieniały się już wcześniej.

Kontrola po wdrożeniu

Pierwsze dwa tygodnie po zmianie to jedyny moment, w którym da się jeszcze tanio naprawić błąd.

Codziennie zaglądam do raportu indeksowania w Search Console i patrzę, czy nie rośnie liczba błędów i czy stare adresy przechodzą do statusu przekierowanych, a nowe do zaindeksowanych. Równolegle sprawdzam statystyki indeksowania — tam widać, czy robot nie utknął na starej strukturze.

Do tego dwie rzeczy poza panelem. Logi serwera pokazują dokładnie, po jakich adresach chodzi robot, i to najuczciwsze źródło informacji o tym, czy porządek faktycznie zadziałał. A po miesiącu wracam do raportu skuteczności i porównuję okres do okresu na poziomie pojedynczych adresów, nie całej witryny — spadek widoczności zawsze zaczyna się w wąskim wycinku i tylko tam da się go zauważyć na czas.