Czym w praktyce jest architektura informacji

Architektura informacji to odpowiedź na pytanie, gdzie w tej witrynie leży dana treść i jak się do niej dochodzi. W sklepie składa się z trzech warstw, które łatwo pomylić.

Pierwsza to taksonomia — sposób, w jaki dzielimy asortyment na grupy i podgrupy. Druga to nawigacja — menu, filtry, okruszki, linki w treści, czyli to, czym użytkownik i robot faktycznie się poruszają. Trzecia to struktura adresów URL, która jest zapisem dwóch pierwszych warstw i najczęściej jedynym śladem, jaki po nich zostaje w logach serwera.

Problem pojawia się wtedy, gdy te warstwy przestają do siebie pasować. Widzę sklepy, w których taksonomia jest sensowna, ale nawigacja jej nie odwzorowuje, bo menu powstało osobno i pokazuje tylko część kategorii. Widzę też odwrotne sytuacje: menu ładne, a adresy generowane przez system w sposób, którego nie da się zinterpretować.

Warto tu zaznaczyć jedną rzecz, o której często się zapomina: Google nie widzi Twojego menu jako menu. Widzi zbiór linków na stronie. Jeśli wyliczysz w rozwijanym menu trzysta pozycji na każdej podstronie, robot zobaczy trzysta linków wychodzących z każdej podstrony i nie będzie miał z czego wywnioskować, które z nich są ważniejsze.

Zacznij od inwentaryzacji, nie od rysowania drzewa

Pierwszy odruch przy porządkowaniu struktury bywa taki, żeby usiąść i zaprojektować idealne drzewo kategorii od zera. Odradzam. Bez wiedzy o tym, co obecnie istnieje i co obecnie zarabia, projekt będzie oderwany od stanu faktycznego.

Zaczynam od trzech list. Pierwsza to pełny crawl witryny — u mnie zwykle Screaming Frogiem — z podziałem na typy adresów: kategorie, podkategorie, produkty, adresy z parametrami, adresy przekierowane, adresy zwracające błędy. Druga to eksport z Search Console: które adresy dostają wyświetlenia i kliknięcia, a które nie dostają nic. Trzecia to lista z systemu sklepowego: ile produktów siedzi w każdej kategorii i ile z nich jest dostępnych.

Zestawienie tych trzech list prawie zawsze pokazuje to samo. Że istnieją kategorie z jednym produktem albo bez żadnego. Że część kategorii dubluje się znaczeniowo z inną, tylko nazwaną odwrotnie. Że pewna grupa adresów nigdy nie dostała ani jednego wyświetlenia, choć robot regularnie po nich chodzi.

Dopiero mając to na papierze, mogę podejmować decyzje. Kategorie puste albo skrajnie ubogie łączę z nadrzędnymi. Duplikaty znaczeniowe scalam i przekierowuję. Kategorie, które mają realny popyt, ale są schowane trzy poziomy niżej, wyciągam wyżej. To praca na tygodnie, nie na jedno popołudnie, i lepiej zrobić ją raz porządnie niż trzy razy po łebkach.

Głębokość struktury i długość ścieżki do produktu

Przy tysiącach produktów pojawia się napięcie między dwiema rzeczami: chcemy mieć wąskie, precyzyjne kategorie, a jednocześnie nie chcemy, żeby produkt leżał sześć kliknięć od strony głównej.

Nie ma progu, po przekroczeniu którego Google przestaje indeksować — to nie działa jak wyłącznik. Działa jak gradient: im dalej od strony głównej, tym rzadziej robot zagląda i tym mniej wartości przepływa linkami. Przy małym serwisie różnica jest nieistotna. Przy dużym katalogu to ona decyduje o tym, czy nowy produkt zostanie zauważony w ciągu dwóch dni czy dwóch miesięcy.

Sam pilnuję, żeby do dowolnego produktu dało się dojść w trzech, maksymalnie czterech krokach z poziomu strony głównej. Jeśli taksonomia wymaga więcej poziomów, dokładam ścieżki skrótowe: listy popularnych podkategorii na stronach kategorii nadrzędnych, bloki polecanych produktów, linki z artykułów blogowych do konkretnych list.

Osobno warto przemyśleć, czy produkt powinien mieć jeden adres, czy wiele. Moja odpowiedź jest zawsze taka sama: jeden produkt, jeden adres kanoniczny, niezależnie od tego, przez ile kategorii da się do niego dojść. Systemy sklepowe potrafią generować adres produktu z prefiksem każdej kategorii, w której go umieszczono. To najprostszy znany mi sposób na to, żeby zamiast trzech tysięcy produktów mieć w indeksie dwanaście tysięcy niemal identycznych stron.

Nawigacja filtrowana — główne źródło śmieci w indeksie

Filtry to element, który przy dużym katalogu robi największy bałagan, i jednocześnie ten, którego nie da się po prostu wyłączyć, bo bez niego nikt nic nie znajdzie.

Mechanika problemu jest prosta. Każda kombinacja filtrów to nowy adres. Trzy filtry po pięć wartości każdy dają liczbę kombinacji, której nikt nie planował mieć w serwisie, a system chętnie ją wygeneruje i podlinkuje. Robot podąża za tymi linkami, bo są zwykłymi linkami, i zamiast poświęcić czas na nowe produkty, chodzi po wariantach tej samej listy.

Dzielę więc filtry na dwie grupy i traktuję je zupełnie inaczej.

• Filtry o wartości wyszukiwawczej — takie, na które ludzie faktycznie szukają jako na osobne frazy: marka w kategorii, rozmiar w odzieży, moc w narzędziach. Dla nich robię pełnoprawne strony: własny adres, własny tytuł, własny nagłówek, opis, link w nawigacji. Te strony mają być indeksowane i mają zarabiać.

• Filtry pomocnicze — sortowanie, widok siatki, zakres cenowy, liczba pozycji na stronie, kombinacje wielu wartości naraz. Te nie mają żadnej wartości w wyszukiwarce. Nie chcę ich w indeksie i nie chcę, żeby robot tracił na nie czas.

Do obsługi drugiej grupy najpewniej działa kombinacja trzech rzeczy: adresy generowane po znaku zapytania z parametrem, blokada tych parametrów w robots.txt, a tam gdzie blokada jest zbyt szeroka — kanoniczny odnośnik do wersji bez filtra. Trzeba przy tym pamiętać, że reguła w robots.txt zatrzymuje odwiedziny, ale nie usuwa adresu, który już jest w indeksie; do usunięcia potrzebny jest dostęp robota i znacznik noindex.

Jedna uwaga natury praktycznej: narzędzie do obsługi parametrów URL w Search Console zostało wyłączone w kwietniu tego roku. Jeśli ktoś kiedyś na Twoim koncie ustawił tam reguły i od tego czasu nikt nie ruszał sklepu, te reguły już nie działają. Warto sprawdzić, czy w międzyczasie coś nie wpadło do indeksu.

Paginacja i strony listingowe

Listy produktów w dużym sklepie są długie, więc paginacja jest nieunikniona. Google od dawna nie korzysta z odnośników rel=”next” i rel=”prev” jako sygnału do sklejania serii — potwierdziło to publicznie w 2019 roku. Można je zostawić ze względu na inne narzędzia, ale nie należy oczekiwać, że coś z nimi zrobi wyszukiwarka.

Co robię zamiast tego. Kolejne strony listingu mają być indeksowalne i mają zawierać zwykłe linki do następnej i poprzedniej strony — po to, żeby robot miał czym dojść do produktów leżących na dalszych stronach. Kanoniczny odnośnik na każdej stronie serii wskazuje na nią samą, nie na pierwszą stronę. Wskazanie wszystkich stron na pierwszą to sposób na to, żeby produkty ze strony siódmej nie zostały odwiedzone nigdy.

Nie robię natomiast strony „pokaż wszystko” przy katalogu liczonym w tysiącach — waga takiej strony i czas jej generowania są nie do obrony.

Osobno pilnuję, żeby unikalna treść kategorii nie znikała po pierwszej stronie i nie powtarzała się na każdej. Opis kategorii zostaje na stronie pierwszej. Na kolejnych zostają tytuł i nagłówek z numerem strony, żeby stronę dwie dało się odróżnić od strony trzy.

Linkowanie wewnętrzne jako narzędzie priorytetów

Linkowanie wewnętrzne to jedyny sposób, w jaki mogę powiedzieć wyszukiwarce, co w tym sklepie uważam za ważne. Przy dużym katalogu przestaje to być kwestia estetyki i staje się kwestią sterowania.

Zasada, którą się kieruję: ważne strony dostają dużo linków z sensownych miejsc, mało ważne dostają tyle, żeby dały się odnaleźć. W praktyce oznacza to, że kategorie z realnym popytem mają wejścia ze strony głównej, ze stron nadrzędnych, z artykułów i z bloków „powiązane”. Warianty filtrów pomocniczych nie mają żadnych.

Do tego dochodzą okruszki. W sklepie z rozbudowaną taksonomią są nie tylko pomocą nawigacyjną, ale też najtańszym sposobem, żeby każda podstrona linkowała w górę do swoich rodziców w spójny sposób.

Osobna sprawa to mapy witryny. Przy tysiącach adresów nie robię jednego pliku, a kilka, podzielonych po typie: kategorie, produkty, treści. Podział ma konkretny sens diagnostyczny — w raporcie stanu indeksowania w Search Console mogę filtrować dane po pojedynczej mapie i widzieć, że problem dotyczy produktów, a nie kategorii. Z jednego wielkiego pliku takiej informacji nie wyciągnę. W mapach zostawiam wyłącznie adresy kanoniczne, ze statusem 200 i przeznaczone do indeksowania — mapa z przekierowaniami i błędami jest sygnałem, że sklep nie jest pilnowany.

Jak wprowadzać zmiany i co potem kontrolować

Przebudowa struktury w dużym sklepie to operacja, przy której najłatwiej stracić widoczność, więc obowiązuje ostrożność.

Nie zmieniam wszystkiego w jednym wdrożeniu. Robię to partiami, dział po działe, i po każdej partii czekam, aż dane się ustabilizują. Każdy zmieniany adres dostaje przekierowanie 301 na nowy, jeden do jednego, bez łańcuchów i bez zbiorczego kierowania wszystkiego na stronę główną. Stare adresy trzymam w przekierowaniach na stałe, nie na miesiąc.

Po wdrożeniu patrzę na cztery rzeczy. Na statystyki indeksowania w Search Console — czy robot faktycznie przesunął uwagę na nowe adresy i czy nie chodzi dalej po starych. Na liczbę adresów zaindeksowanych i wykluczonych w podziale na mapy witryny. Na wyświetlenia i kliknięcia w rozbiciu na typy stron, a nie na całą domenę, bo suma potrafi ukryć to, że kategorie zyskały, a produkty straciły. I na logi serwera, jeśli mam do nich dostęp — to jedyne miejsce, gdzie widać prawdę o tym, co robot robi z witryną.

Zmian nie oceniam po tygodniu. Przy dużym serwisie sam przecrawlowanie nowej struktury zajmuje wyszukiwarce sporo czasu, a listopad i grudzień dodatkowo zaburzają obraz sezonowością. Jeśli mam wybór, poważne przebudowy planuję na styczeń albo luty — nie dlatego, że wtedy jest bezpieczniej technicznie, ale dlatego, że wtedy da się w ogóle odczytać wynik.