Co to jest paginacja i jak poprawnie stosować ją na stronach i w sklepach?

Paginacja to mechanizm dzielenia większego zbioru treści na kilka kolejnych stron. Zamiast wyświetlać setki produktów, artykułów lub wyników jednocześnie, serwis pokazuje określoną liczbę elementów i umożliwia przechodzenie do następnych części listy.

Najprostszy przykład paginacji wygląda tak:

1 2 3 4 5 Następna

Każdy numer prowadzi do kolejnego fragmentu tej samej listy.

Paginację można spotkać między innymi w sklepach internetowych, blogach, katalogach produktów, wynikach wyszukiwania, archiwach oraz rozbudowanych bazach danych.

Choć dla użytkownika jest to zwykle niewielki element znajdujący się na dole strony, technicznie może mieć duże znaczenie dla architektury serwisu, SEO i sposobu indeksowania treści.

Co oznacza paginacja?

Słowo paginacja pochodzi od pojęcia strony. W kontekście internetu oznacza podzielenie jednej większej kolekcji danych na mniejsze części prezentowane na osobnych widokach.

Przykładowo kategoria sklepu posiada 240 produktów.

Zamiast umieszczać wszystkie produkty na jednej stronie, system może wyświetlać po 24 elementy.

Powstaje wtedy dziesięć stron:

• strona 1: produkty 1–24,
• strona 2: produkty 25–48,
• strona 3: produkty 49–72,
• i tak dalej.

Każda kolejna strona stanowi następny fragment tego samego zbioru.

Gdzie najczęściej stosuje się paginację?

Paginacja jest szczególnie przydatna wszędzie tam, gdzie liczba elementów może być duża.

Typowe zastosowania to:

• kategorie produktów w sklepie internetowym,
• listy wpisów blogowych,
• archiwa artykułów,
• wyniki wyszukiwania,
• listy użytkowników,
• katalogi firm,
• galerie,
• fora internetowe,
• komentarze,
• systemy administracyjne.

Mechanizm pozwala ograniczyć liczbę elementów ładowanych jednocześnie i zachować czytelność interfejsu.

Dlaczego nie wyświetlać wszystkiego na jednej stronie?

Przy niewielkiej liczbie elementów może to mieć sens.

Jeżeli kategoria posiada osiem produktów, dzielenie jej na kilka stron byłoby zbędne.

Problem pojawia się przy setkach lub tysiącach elementów.

Jedna ogromna strona może powodować:

• długi czas ładowania,
• dużą liczbę zapytań do bazy danych,
• duży dokument HTML,
• większe zużycie pamięci przeglądarki,
• problemy na urządzeniach mobilnych,
• trudności w odnalezieniu konkretnego elementu.

Paginacja pozwala rozłożyć ten zbiór na mniejsze części.

Jak wygląda klasyczna paginacja?

Najbardziej tradycyjny model wykorzystuje numery kolejnych stron.

Przykład:

Poprzednia 1 2 3 4 5 Następna

Użytkownik może przejść bezpośrednio do wybranej strony albo poruszać się kolejno do przodu i do tyłu.

W zależności od projektu mogą pojawić się również:

• pierwsza strona,
• ostatnia strona,
• skok o kilka stron,
• informacja o aktualnym numerze,
• liczba wszystkich stron.

Adresy URL paginacji

Kolejne strony paginacji zazwyczaj posiadają własne adresy URL.

Mogą wyglądać na przykład tak:

/sklep/

/sklep/page/2/

/sklep/page/3/

albo:

/sklep/?page=2

Oba modele mogą działać poprawnie.

Najważniejsze jest, aby kolejne strony posiadały stabilne adresy i były dostępne również bez wykonywania JavaScriptu, jeżeli ich zawartość ma być odkrywana przez wyszukiwarki.

Paginacja w sklepie internetowym

E-commerce jest jednym z miejsc, gdzie paginacja ma szczególnie duże znaczenie.

Kategoria może zawierać setki produktów, a jednoczesne wyświetlenie ich wszystkich zwykle nie jest dobrym rozwiązaniem.

Przykładowo sklep posiada 600 produktów w kategorii Kosmetyki.

Jeżeli wyświetla po 30 produktów, powstaje 20 stron paginacji.

Robot wyszukiwarki i użytkownik muszą mieć możliwość dotarcia również do produktów znajdujących się na końcowych stronach.

Dlatego paginacja jest częścią architektury sklepu, a nie tylko elementem wizualnym.

Paginacja w WooCommerce

WooCommerce standardowo potrafi dzielić listy produktów na kolejne strony.

Sposób wyświetlania paginacji zależy jednak od motywu, liczby produktów na stronie oraz dodatkowych rozszerzeń.

Problemy pojawiają się szczególnie wtedy, gdy klasyczna paginacja zostaje zastąpiona przez:

• infinite scroll,
• automatyczne doładowywanie produktów,
• przycisk Pokaż więcej,
• niestandardowy system AJAX.

Takie rozwiązania mogą być wygodne dla użytkownika, ale trzeba sprawdzić, czy robot wyszukiwarki nadal posiada normalną drogę do wszystkich produktów.

Przy tworzeniu sklepów internetowych WooCommerce analizuję dlatego nie tylko wygląd list produktów, ale również sposób ich ładowania, adresy URL i dostępność kolejnych stron dla wyszukiwarek.

Paginacja a SEO

Z punktu widzenia SEO najważniejsze pytanie brzmi:

czy robot wyszukiwarki może dotrzeć do elementów znajdujących się na kolejnych stronach?

Jeżeli produkt znajduje się na stronie 14 kategorii, ale do tej strony nie prowadzi żaden zwykły link, jego odkrycie może być utrudnione.

Paginacja wpływa więc na:

• crawlability,
• linkowanie wewnętrzne,
• głębokość produktów,
• odkrywanie nowych adresów,
• strukturę kategorii.

Nie oznacza to, że każda strona paginacji musi rankować w Google jako osobny wynik.

Jej podstawową rolą jest umożliwienie dostępu do dalszej części zbioru.

Crawlability a paginacja

Crawlability oznacza możliwość odkrywania i odwiedzania adresów przez roboty wyszukiwarek.

Jeżeli kolejne strony paginacji są połączone normalnymi linkami HTML, crawler może przechodzić dalej.

Przykład:

Strona 1 linkuje do strony 2.

Strona 2 linkuje do strony 3.

Strona 3 linkuje do strony 4.

Robot może więc stopniowo odkrywać kolejne produkty.

Problem pojawia się, gdy następne elementy są dostępne wyłącznie po kliknięciu przycisku obsługiwanego przez JavaScript bez odpowiadającego mu adresu URL.

Paginacja a indeksowanie

Crawl i indeksowanie to dwa różne procesy.

Robot może odwiedzić stronę paginacji, ale wyszukiwarka nie musi później przechowywać jej jako osobnego wyniku.

Nie należy więc blokować crawlera tylko dlatego, że nie zależy nam na rankowaniu adresu:

/kategoria/page/7/

Jeżeli znajdują się tam linki do produktów, strona nadal może być użytecznym elementem ścieżki crawl.

Czy strony paginacji powinny mieć noindex?

Nie istnieje jedna reguła pasująca do każdego serwisu.

Automatyczne ustawianie noindex na wszystkich kolejnych stronach może być stosowane w niektórych konfiguracjach, ale nie powinno być decyzją podejmowaną bez analizy.

Trzeba sprawdzić między innymi:

• jak duży jest katalog,
• jak Google dociera do produktów,
• czy istnieją dodatkowe ścieżki linkowania,
• czy kategorie mają wiele stron,
• jak działa filtrowanie.

Samo noindex nie blokuje automatycznie crawlowania linków znajdujących się na stronie, ale może zmienić sposób, w jaki wyszukiwarka traktuje ją w dłuższej perspektywie.

Czy strony paginacji blokować w robots.txt?

Zwykle nie powinno się robić tego bez bardzo konkretnego powodu.

Jeżeli robots.txt uniemożliwia crawlerowi wejście na stronę 2, robot może nie zobaczyć linków do produktów znajdujących się właśnie na tej stronie.

Blokada typu:

Disallow: /page/

może więc spowodować znacznie więcej szkody niż pożytku.

Robots.txt służy do sterowania crawlowaniem, a nie do prostego usuwania stron z wyników wyszukiwania.

Paginacja a canonical

Canonical to jeden z najczęściej źle używanych elementów przy paginacji.

Można spotkać konfigurację, w której wszystkie kolejne strony wskazują canonical na stronę pierwszą.

Przykład:

/kategoria/page/2/ → canonical → /kategoria/

/kategoria/page/3/ → canonical → /kategoria/

Problem polega na tym, że kolejne strony nie są dokładnymi duplikatami strony pierwszej.

Zawierają inne produkty.

Dlatego automatyczne kanonizowanie całej paginacji do pierwszej strony może przekazywać wyszukiwarce błędny sygnał.

W wielu przypadkach poprawniejszym rozwiązaniem jest canonical wskazujący na samą siebie.

Self-canonical na stronach paginacji

Self-canonical oznacza, że strona wskazuje jako wersję kanoniczną własny adres.

Przykład:

/kategoria/page/2/ → canonical → /kategoria/page/2/

Taki model informuje wyszukiwarkę, że strona 2 jest prawidłowym, odrębnym fragmentem kolekcji.

Nie oznacza to, że Google musi pokazywać ją w wynikach wyszukiwania.

Po prostu nie sugerujemy, że jest kopią strony 1.

rel next i rel prev

W starszych poradnikach SEO często można znaleźć zalecenie stosowania oznaczeń rel next i rel prev.

Miały one informować wyszukiwarkę, że konkretne dokumenty tworzą serię kolejnych stron.

Nie należy jednak obecnie projektować całej strategii paginacji wyłącznie wokół tych oznaczeń.

Znacznie ważniejsza jest prawidłowa struktura linków, stabilne adresy URL i logiczna architektura.

Paginacja a linkowanie wewnętrzne

Każda kolejna strona kategorii stanowi dodatkowy poziom pomiędzy stroną główną kategorii a produktem.

Jeżeli produkt znajduje się na stronie 35, droga do niego może być bardzo długa.

To właśnie dlatego w dużych sklepach warto analizować nie tylko paginację, ale również:

• podkategorie,
• filtry indeksowalne,
• linkowanie produktowe,
• bestsellery,
• powiązane produkty,
• wewnętrzną wyszukiwarkę,
• strukturę menu.

Paginacja nie powinna być jedynym sposobem dotarcia do każdego produktu.

Głębokość produktu w serwisie

Głębokość można rozumieć jako liczbę przejść potrzebnych do dotarcia do danej strony.

Jeżeli schemat wygląda tak:

Strona główna → Sklep → Kategoria → Strona 2 → Strona 3 → Strona 4 → Produkt

produkt znajduje się stosunkowo głęboko.

W dużym katalogu może to dotyczyć tysięcy pozycji.

Dlatego struktura e-commerce powinna zapewniać również inne logiczne ścieżki do ważnych produktów.

Paginacja a kolejność produktów

To często pomijany problem.

Jeżeli kolejność produktów zmienia się bardzo często, zawartość kolejnych stron również może się przesuwać.

Produkt znajdujący się dziś na stronie 2 jutro może trafić na stronę 5.

Może się tak dziać przy sortowaniu według:

• popularności,
• sprzedaży,
• dostępności,
• daty dodania,
• algorytmu personalizacji.

Domyślna kolejność kategorii powinna być możliwie stabilna i przewidywalna, szczególnie jeśli wpływa na sposób crawlowania katalogu.

Paginacja a sortowanie

Sortowanie i paginacja to dwa różne mechanizmy, które często działają jednocześnie.

Użytkownik może wybrać:

• od najtańszych,
• od najdroższych,
• najpopularniejsze,
• najnowsze.

Każdy wariant może następnie posiadać własne kolejne strony.

Jeżeli system generuje osobne adresy URL dla wszystkich kombinacji, liczba adresów może szybko rosnąć.

Przykładowo:

/buty/?orderby=price&page=4

/buty/?orderby=date&page=4

/buty/?orderby=rating&page=4

Mimo że wszystkie prezentują elementy z tej samej kategorii.

Paginacja a faceted navigation

Faceted navigation to system filtrowania produktów według wielu cech.

Przy rozbudowanym sklepie filtrowanie połączone z paginacją może wygenerować ogromną liczbę adresów.

Przykładowo użytkownik wybiera:

• markę A,
• kolor czarny,
• rozmiar 42,
• cenę 200–400 zł.

Jeżeli wynik ma pięć stron, każda kombinacja filtrów może utworzyć kolejne adresy paginacji.

Przy dziesiątkach filtrów liczba możliwych kombinacji może sięgać tysięcy albo milionów.

To już nie jest problem samej paginacji, ale całej architektury crawl.

Crawl budget i paginacja

Crawl budget to uproszczone określenie zasobów, jakie wyszukiwarka przeznacza na crawlowanie danego serwisu.

W niewielkiej stronie zwykle nie jest to istotny problem.

W sklepie posiadającym setki tysięcy adresów sytuacja wygląda inaczej.

Jeżeli crawler zużywa dużo czasu na:

• sortowanie,
• filtry,
• duplikaty,
• techniczne parametry,
• niepotrzebne warianty paginacji,

może mniej efektywnie odwiedzać ważne produkty i kategorie.

Dlatego przy SEO technicznym sprawdzam paginację razem z filtrami, canonicalami, robots.txt i strukturą linkowania, a nie jako odizolowany element.

Paginacja a infinite scroll

Infinite scroll to mechanizm automatycznie doładowujący kolejne elementy podczas przewijania strony.

Użytkownik nie klika numeru 2 ani przycisku Następna.

Po zbliżeniu się do końca listy system ładuje następne produkty.

Takie rozwiązanie może być wygodne w serwisach nastawionych na ciągłe przeglądanie treści.

Ma jednak również wady.

Problemy infinite scroll

Użytkownik może mieć trudność z:

• powrotem do konkretnego miejsca,
• zapamiętaniem pozycji na liście,
• dotarciem do stopki,
• udostępnieniem konkretnego fragmentu listy,
• orientacją, ile elementów jeszcze zostało.

Technicznie trzeba również zadbać o to, aby kolejne partie treści posiadały normalne adresy URL i były dostępne dla crawlera.

Infinite scroll z paginacją w tle

Jednym z dobrych modeli jest połączenie obu rozwiązań.

Użytkownik może korzystać z płynnego doładowywania produktów, natomiast pod spodem istnieją prawidłowe strony:

/kategoria/page/2/

/kategoria/page/3/

/kategoria/page/4/

JavaScript poprawia wtedy doświadczenie użytkownika, ale nie usuwa klasycznej struktury adresów.

To ważna zasada przy projektowaniu nowoczesnych interfejsów: warstwa UX nie powinna niszczyć podstawowej dostępności treści.

Paginacja a przycisk Pokaż więcej

Pośrednim rozwiązaniem pomiędzy paginacją a infinite scroll jest przycisk Pokaż więcej.

Użytkownik sam decyduje, kiedy pobrać kolejną partię produktów.

Ma to kilka zalet:

• brak automatycznego doładowywania,
• większa kontrola użytkownika,
• prostsze przewijanie niż przy klasycznej zmianie strony.

Z punktu widzenia SEO nadal trzeba jednak zapewnić crawlerowi normalną drogę do kolejnych elementów.

Paginacja czy Pokaż więcej?

Nie ma jednego rozwiązania najlepszego dla wszystkich serwisów.

Klasyczna paginacja dobrze sprawdza się wtedy, gdy użytkownik:

• porównuje wyniki,
• chce wrócić do konkretnego miejsca,
• przegląda uporządkowany katalog.

Pokaż więcej może być wygodniejsze przy bardziej swobodnym przeglądaniu.

Najważniejsze jest, aby mechanizm odpowiadał zachowaniu użytkownika i nie pogarszał dostępności technicznej.

Paginacja a mobile

Na telefonie klasyczna lista kilkunastu numerów stron może zajmować dużo miejsca.

Nie ma potrzeby pokazywać wszystkich numerów.

Można zastosować prostszy układ:

Poprzednia 4 5 6 Następna

albo:

Strona 5 z 24

Najważniejsze jest zachowanie wygodnych obszarów kliknięcia.

Numery znajdujące się bardzo blisko siebie mogą powodować przypadkowe przejścia na niewłaściwą stronę.

Paginacja a dostępność

Mechanizm powinien być zrozumiały również dla użytkowników korzystających z klawiatury i technologii wspomagających.

Aktualna strona powinna być możliwa do rozpoznania, a linki powinny posiadać jasne znaczenie.

Same numery 1, 2 i 3 są wizualnie oczywiste, ale odpowiednia struktura semantyczna może dodatkowo pomóc technologiom asystującym zrozumieć ich funkcję.

Czy aktualny numer strony powinien być linkiem?

Zazwyczaj nie ma takiej potrzeby.

Jeżeli użytkownik znajduje się na stronie 4, kliknięcie liczby 4 prowadzącej ponownie do strony 4 niczego nie zmienia.

Lepiej wyraźnie zaznaczyć aktualny numer jako aktywny element paginacji.

Ile numerów stron pokazywać?

Przy pięciu stronach można wyświetlić wszystkie.

Przy pięciuset byłoby to absurdalne.

Dlatego często stosuje się skrócony model:

1 2 3 4 5 … 100

albo:

1 … 18 19 20 21 22 … 100

Użytkownik otrzymuje kontekst bez konieczności wyświetlania setek linków.

Czy potrzebny jest link do ostatniej strony?

Zależy od rodzaju serwisu.

W archiwum chronologicznym użytkownik może chcieć szybko przejść do najstarszych treści.

W kategorii sklepu przejście od razu do strony 187 może mieć znacznie mniejsze znaczenie.

Interfejs powinien wynikać z realnych potrzeb użytkowników.

Ile produktów wyświetlać na jednej stronie?

Nie istnieje uniwersalna liczba.

Można spotkać 12, 24, 36, 48 lub więcej produktów.

Wybór powinien uwzględniać:

• rodzaj produktu,
• wielkość kafla,
• wydajność strony,
• urządzenia mobilne,
• sposób filtrowania,
• zachowanie użytkowników.

Wyświetlenie bardzo małej liczby elementów generuje wiele stron paginacji.

Zbyt duża liczba może natomiast spowolnić stronę.

Paginacja a wydajność

Prawidłowo zaprojektowana paginacja może zmniejszać obciążenie.

Zamiast pobierać 2000 rekordów, aplikacja pobiera na przykład 30.

Ma to znaczenie zarówno dla bazy danych, jak i przeglądarki użytkownika.

Jednocześnie źle napisana paginacja może sama generować kosztowne zapytania, szczególnie przy bardzo dużych zbiorach danych.

OFFSET w bazie danych

W wielu systemach klasyczna paginacja jest technicznie realizowana za pomocą parametrów LIMIT i OFFSET.

Przykładowo system pobiera:

30 rekordów od pozycji 3000.

Przy ogromnej bazie wysokie wartości OFFSET mogą powodować coraz bardziej kosztowne operacje.

Dlatego w bardzo dużych systemach stosuje się czasami inne modele paginacji.

Cursor pagination

Cursor pagination nie opiera się na numerze strony, ale na określonym punkcie w zbiorze danych.

System może poprosić:

pokaż kolejne 30 rekordów po identyfikatorze 12540.

Takie rozwiązanie jest często wydajniejsze przy bardzo dużych i dynamicznych zbiorach.

Można je spotkać w API, aplikacjach i serwisach społecznościowych.

Nie zawsze jest jednak odpowiednie dla klasycznego sklepu, ponieważ użytkownik nie może łatwo przejść bezpośrednio na stronę 27.

Paginacja po stronie serwera

W klasycznym modelu serwer generuje każdą kolejną stronę na podstawie parametru adresu URL.

Użytkownik otwiera:

/page/3/

a serwer od razu zwraca odpowiedni fragment listy.

Takie rozwiązanie jest przewidywalne i łatwe do obsługi przez wyszukiwarki.

Paginacja po stronie klienta

W aplikacjach JavaScript wszystkie dane albo kolejne partie mogą być pobierane dynamicznie.

Samo w sobie nie jest to błędem.

Trzeba jednak sprawdzić:

• czy kolejne widoki posiadają adresy URL,
• czy odświeżenie strony zachowuje pozycję,
• czy robot może odkryć treść,
• czy przycisk Wstecz działa prawidłowo.

Paginacja a przycisk Wstecz

To bardzo praktyczny element UX.

Użytkownik przechodzi z kategorii na produkt, ogląda go i wraca.

Powinien wrócić dokładnie do miejsca, z którego wyszedł.

Jeżeli był na stronie 8 kategorii, powrót na stronę 1 i początek listy jest frustrujący.

Problem występuje szczególnie przy źle wdrożonym infinite scroll.

Paginacja a zapamiętywanie pozycji

Przeglądarka zwykle potrafi odtworzyć pozycję przewijania klasycznej strony.

W dynamicznych interfejsach trzeba czasami zadbać o to dodatkowo.

Jeżeli użytkownik przewinął 150 produktów, wszedł na kartę jednego z nich i po powrocie musi przewijać wszystko od początku, doświadczenie szybko staje się irytujące.

Paginacja wyników wyszukiwania

Wewnętrzna wyszukiwarka również często wymaga paginacji.

Jeżeli zapytanie zwróci 1200 wyników, nie ma sensu prezentować wszystkich naraz.

W tym przypadku znaczenie SEO może być jednak inne niż w przypadku kategorii produktowych.

Wewnętrzne wyniki wyszukiwania często nie powinny tworzyć tysięcy indeksowanych stron.

Dlatego nie należy automatycznie stosować tej samej strategii do paginacji kategorii i wyszukiwarki.

Paginacja komentarzy

Mechanizm można stosować również do komentarzy.

Przy artykule posiadającym kilka tysięcy odpowiedzi załadowanie wszystkiego jednocześnie może być niepraktyczne.

Trzeba jednak uważać, czy podział komentarzy nie powoduje tworzenia wielu wersji tej samej treści z problematycznymi canonicalami lub tytułami.

Paginacja wpisów blogowych

Klasyczne archiwum bloga często prezentuje na przykład dziesięć wpisów na stronę.

Starsze artykuły trafiają na kolejne strony wraz z publikowaniem nowych.

Oznacza to, że ich położenie w paginacji stale się zmienia.

Dlatego ważne artykuły nie powinny być dostępne wyłącznie poprzez przeklikiwanie kilkudziesięciu stron archiwum.

Pomagają tu między innymi:

• kategorie,
• linkowanie kontekstowe,
• sekcje powiązanych treści,
• spis treści serwisu.

Paginacja a sitemap XML

Mapa XML powinna przede wszystkim zawierać adresy właściwych treści, które mają być indeksowane.

Produkty znajdujące się na stronie 20 kategorii mogą być umieszczone bezpośrednio w sitemapie.

Nie oznacza to jednak, że można wtedy całkowicie zignorować linkowanie wewnętrzne.

Sitemap pomaga wyszukiwarce odkrywać adresy, ale nie zastępuje poprawnej architektury serwisu.

Paginacja a breadcrumb

Breadcrumb i paginacja rozwiązują różne problemy.

Breadcrumb pokazuje miejsce w hierarchii:

Sklep → Obuwie → Buty trekkingowe

Paginacja pokazuje położenie w obrębie listy:

Strona 4 z 12

Nie należy więc dodawać kolejnych numerów stron jako następnych poziomów breadcrumb.

Strona 4 nie jest podkategorią strony 3.

Najczęstszy błąd: wszystkie strony canonical do strony pierwszej

To konfiguracja, którą szczególnie warto sprawdzać.

Kolejne strony posiadają różną zawartość.

Jeżeli wszystkie zostaną oznaczone jako kopia strony pierwszej, wyszukiwarka otrzymuje sprzeczną informację.

Z jednej strony znajdują się tam inne produkty, a z drugiej canonical mówi, że właściwa wersja jest gdzie indziej.

Najczęstszy błąd: nofollow na linkach paginacji

Jeżeli link Następna posiada nofollow, utrudniamy crawlerowi naturalne przechodzenie do kolejnych części listy.

Nie ma sensu stosować nofollow tylko po to, aby rzekomo oszczędzać moc SEO.

Paginacja jest częścią wewnętrznej architektury serwisu.

Najczęstszy błąd: blokowanie w robots.txt

Zablokowanie wszystkich adresów /page/ może wyglądać jak prosty sposób na ograniczenie indeksacji.

W rzeczywistości uniemożliwia crawlerowi pobranie tych stron i zobaczenie znajdujących się na nich linków.

To szczególnie niebezpieczne w dużym sklepie.

Najczęstszy błąd: paginacja tylko w JavaScript

Użytkownik widzi kolejne produkty po kliknięciu Pokaż więcej, ale w kodzie nie istnieje link prowadzący do strony 2.

Jeżeli robot nie wykonuje konkretnej interakcji w ten sam sposób, część katalogu może być trudniejsza do odkrycia.

Najczęstszy błąd: nieskończona liczba pustych stron

Niektóre systemy pozwalają otworzyć:

/page/999999/

i zwracają poprawny kod HTTP 200 mimo braku jakichkolwiek produktów.

Może to generować ogromną liczbę bezwartościowych adresów.

Adres poza rzeczywistym zakresem paginacji powinien być obsłużony w sposób świadomy.

Najczęstszy błąd: zmiana liczby produktów bez kontroli URL

Niektóre sklepy pozwalają użytkownikowi wybrać:

• 24 produkty,
• 48 produktów,
• 96 produktów.

Jeżeli każda opcja generuje osobne indeksowalne adresy, powstają kolejne warianty tej samej kategorii.

Trzeba zdecydować, jak takie parametry powinny być traktowane przez wyszukiwarkę.

Najczęstszy błąd: paginacja po filtrowaniu bez kontroli

Filtry potrafią zwielokrotnić problem.

Jeżeli każda kombinacja filtrów posiada 20 stron, liczba adresów rośnie wykładniczo.

W dużym sklepie analiza paginacji musi więc zawsze obejmować również faceted navigation.

Jak sprawdzić paginację ręcznie?

Można rozpocząć od kilku prostych testów.

1. Otwórz pierwszą stronę kategorii.
2. Przejdź na stronę 2.
3. Sprawdź, czy adres URL się zmienił.
4. Odśwież stronę.
5. Sprawdź, czy nadal widzisz stronę 2.
6. Wyłącz JavaScript i sprawdź podstawową nawigację, jeśli architektura serwisu tego wymaga.
7. Sprawdź link Następna w kodzie strony.
8. Otwórz bardzo daleką stronę paginacji.

W sklepie warto również sprawdzić, czy produkty znajdujące się na dalszych stronach posiadają inne ścieżki linkowania.

Jak testować paginację pod kątem SEO?

Przy analizie technicznej sprawdzam między innymi:

• statusy HTTP kolejnych stron,
• canonical,
• meta robots,
• robots.txt,
• linki do następnych stron,
• adresy generowane przez sortowanie,
• adresy filtrów,
• duplikację tytułów i opisów,
• sposób odkrywania produktów.

Nie oceniam więc paginacji wyłącznie na podstawie tego, czy przyciski 1, 2 i 3 działają po kliknięciu.

Tytuły stron paginacji

Kolejne strony mogą posiadać podobne tytuły.

Można spotkać rozwiązania typu:

Buty trekkingowe – strona 2

Buty trekkingowe – strona 3

Numer strony pomaga rozróżnić dokumenty, ale nie oznacza to, że trzeba tworzyć dla każdej strony osobny rozbudowany tekst SEO.

Treść kategorii powinna przede wszystkim znajdować się tam, gdzie ma sens dla użytkownika.

Opis kategorii na każdej stronie paginacji

Jeżeli długi opis kategorii jest powtarzany na wszystkich 30 stronach, użytkownik za każdym razem musi przewijać tę samą treść, zanim zobaczy produkty.

Nie zawsze ma to sens.

W niektórych projektach opis można wyświetlać tylko na pierwszej stronie kategorii albo odpowiednio zmienić jego prezentację na kolejnych stronach.

Decyzja powinna uwzględniać UX i techniczną strukturę strony.

Nagłówek H1 na stronach paginacji

Kolejne strony nadal dotyczą tej samej kategorii.

Nie trzeba tworzyć sztucznie nowych tematów tylko dlatego, że użytkownik znajduje się na stronie 4.

Możliwe jest zachowanie tego samego głównego nagłówka kategorii oraz dodatkowej informacji o numerze strony.

Paginacja a duplicate content

Kolejne strony paginacji posiadają wiele wspólnych elementów:

• header,
• menu,
• breadcrumb,
• nazwę kategorii,
• część opisów.

Różnią się jednak główną listą produktów lub artykułów.

Nie są więc automatycznie pełnymi duplikatami.

Problemy pojawiają się raczej wtedy, gdy system generuje kilka różnych adresów prowadzących do dokładnie tego samego zestawu elementów.

Paginacja a filtry indeksowalne

Niektóre filtry mogą być wartościowymi landing pages SEO.

Przykładowo:

Buty trekkingowe męskie

mogą stanowić logiczną kategorię lub indeksowalny filtr.

Jeżeli taka strona posiada 200 produktów, również będzie wymagać paginacji.

Trzeba wtedy traktować ją podobnie jak inną wartościową kategorię, a nie jak przypadkowy parametr techniczny.

Kiedy nie potrzebujemy paginacji?

Jeżeli lista jest krótka, paginacja może tylko utrudniać korzystanie ze strony.

Przykładowo podział 18 produktów na trzy strony po sześć sztuk zwykle nie daje użytkownikowi żadnej korzyści.

Może wręcz wymagać dodatkowych kliknięć.

Mechanizm powinien być stosowany wtedy, gdy rzeczywiście rozwiązuje problem skali.

Paginacja w panelach administracyjnych

SEO nie ma znaczenia w prywatnym panelu administracyjnym, ale wydajność i UX nadal są istotne.

Lista 200 tysięcy zamówień nie powinna być pobierana jednocześnie.

Paginacja pozwala wyświetlać na przykład po 50 rekordów.

W takich systemach można również stosować cursor pagination, szczególnie gdy dane szybko się zmieniają.

Paginacja w API

API bardzo często ogranicza liczbę rekordów zwracanych w jednym żądaniu.

Przykładowo odpowiedź może zawierać 100 produktów i informację o możliwości pobrania kolejnej strony.

Chroni to serwer przed przesyłaniem ogromnych zbiorów danych w jednym zapytaniu.

API może wykorzystywać:

• numer strony,
• offset,
• cursor,
• token następnej strony.

Paginacja a integracje

Przy integracjach paginacja API ma bardzo praktyczne znaczenie.

Jeżeli API zwraca maksymalnie 100 produktów, a sklep posiada 25 tysięcy pozycji, integracja musi poprawnie pobrać wszystkie strony.

Błąd polegający na pobraniu tylko pierwszej strony może spowodować, że system przetworzy zaledwie pierwszych 100 produktów.

Dlatego podczas tworzenia integracji sprawdzam zawsze, czy API stosuje paginację i jaki jest warunek zakończenia pobierania danych.

Zmiany danych podczas paginacji API

Jeżeli dane zmieniają się podczas pobierania kolejnych stron, klasyczny offset może powodować problemy.

Wyobraźmy sobie, że podczas pobierania strony 2 do bazy zostaje dodanych kilkadziesiąt nowych rekordów.

Pozycje mogą się przesunąć, przez co część danych zostanie pobrana dwukrotnie albo całkowicie pominięta.

W takich zastosowaniach cursor pagination może być bardziej niezawodna.

Paginacja a cache

Kolejne strony kategorii mogą być cachowane podobnie jak inne dokumenty.

Trzeba jednak pamiętać, że ich zawartość może zależeć od aktualnych stanów produktów i sortowania.

Nieprawidłowa konfiguracja cache może sprawić, że użytkownik zobaczy nieaktualną listę.

Paginacja a produkty niedostępne

Jeżeli sklep automatycznie ukrywa produkty po wyprzedaniu, liczba elementów na kolejnych stronach może często się zmieniać.

Produkty przesuwają się wtedy pomiędzy stronami.

Przy bardzo dynamicznym katalogu warto sprawdzić wpływ takiej konfiguracji na crawlowanie i doświadczenie użytkownika.

Paginacja a nowe produkty

Jeżeli domyślne sortowanie pokazuje najnowsze produkty jako pierwsze, dodanie nowego towaru przesuwa wszystkie wcześniejsze pozycje.

To naturalne zachowanie.

Problem pojawia się dopiero wtedy, gdy produkty mają bardzo mało innych linków i są zależne wyłącznie od swojego chwilowego położenia w paginacji.

Co z produktami na ostatniej stronie?

Ostatnia strona często zawiera mniej elementów niż pozostałe.

Nie jest to problem.

Nie trzeba sztucznie uzupełniać jej produktami z wcześniejszych stron.

Ważne jest natomiast, aby po zmniejszeniu liczby produktów nie pozostawały puste strony dostępne pod starymi numerami.

Co zrobić po usunięciu części produktów?

Załóżmy, że kategoria miała 20 stron, ale po zmianach posiada tylko 12.

Adres:

/kategoria/page/20/

nie powinien nadal udawać prawidłowej strony kategorii bez produktów.

Sposób obsługi zależy od systemu, ale warto sprawdzić, jaki status HTTP zwraca taki adres i czy nie generuje soft 404.

Soft 404 a paginacja

Soft 404 występuje wtedy, gdy strona wygląda jak nieistniejąca lub pusta, ale serwer nadal zwraca kod 200.

Przykładem może być:

Strona 999 z komunikatem „Brak produktów” i statusem HTTP 200.

W dużym serwisie takie adresy mogą niepotrzebnie zwiększać liczbę crawlable URL.

Czy numer strony powinien być w adresie?

Tak, jeżeli użytkownik ma możliwość bezpośredniego wejścia na konkretny fragment listy.

Adres pozwala:

• odświeżyć stronę,
• zapisać ją w zakładkach,
• udostępnić link,
• wrócić do konkretnego miejsca.

To szczególnie ważne przy klasycznej paginacji.

Paginacja a historia przeglądarki

Przejście na kolejną stronę powinno zachowywać się przewidywalnie.

Jeżeli użytkownik przejdzie:

1 → 2 → 3

a następnie użyje przycisku Wstecz, powinien wrócić na stronę 2.

Dynamiczne mechanizmy oparte na JavaScript powinny odpowiednio aktualizować historię przeglądarki.

Paginacja a analityka

Warto sprawdzać, jak użytkownicy rzeczywiście korzystają z kolejnych stron.

Można analizować między innymi:

• ile osób przechodzi na stronę 2,
• jak daleko użytkownicy przeglądają katalog,
• czy korzystają z sortowania,
• czy częściej używają filtrów niż paginacji,
• na których stronach przechodzą do produktów.

Takie dane mogą pomóc zdecydować, czy obecny sposób prezentacji katalogu jest rzeczywiście wygodny.

Czy głęboka paginacja oznacza problem UX?

Jeżeli użytkownik regularnie musi przechodzić do strony 40, problemem może nie być sama paginacja.

Może brakować lepszych narzędzi do zawężania wyników.

W dużym katalogu użytkownik powinien mieć dostęp do:

• wyszukiwarki,
• kategorii,
• filtrów,
• sortowania.

Paginacja jest sposobem przemieszczania się po wynikach, a nie substytutem dobrej architektury katalogu.

Jak projektować paginację w dużym sklepie?

W dużym e-commerce warto patrzeć na nią razem z całym systemem odkrywania produktów.

1. Ustalić sensowną liczbę produktów na stronie.
2. Zapewnić stabilne adresy URL.
3. Stosować zwykłe linki do kolejnych stron.
4. Sprawdzić canonical.
5. Nie blokować przypadkowo paginacji w robots.txt.
6. Przeanalizować filtry i sortowanie.
7. Zapewnić inne linki do ważnych produktów.
8. Przetestować zachowanie na mobile.

Klasyczna paginacja nadal ma sens

Infinite scroll i nowoczesne interfejsy mogą wyglądać atrakcyjniej, ale klasyczna paginacja nadal posiada bardzo ważną zaletę: jest przewidywalna.

Użytkownik wie:

• gdzie się znajduje,
• ile stron istnieje,
• jak wrócić,
• jak przejść dalej.

Również technicznie łatwo zapewnić wyszukiwarkom dostęp do kolejnych fragmentów listy.

Najważniejsza zasada: paginacja musi być prawdziwą nawigacją

Największy problem pojawia się wtedy, gdy paginacja istnieje wyłącznie wizualnie.

Użytkownik widzi przycisk Następna, ale pod spodem nie ma trwałej struktury adresów i linków.

Dobra paginacja powinna pozwalać dotrzeć do kolejnych elementów zarówno użytkownikowi, jak i systemom, które analizują strukturę strony.

Co warto zapamiętać o paginacji?

Paginacja służy do dzielenia dużych zbiorów treści na mniejsze, łatwiejsze do obsługi części.

W sklepach internetowych jest bardzo często niezbędnym elementem architektury kategorii i sposobu odkrywania produktów.

Nie powinna być traktowana wyłącznie jako kilka numerów umieszczonych na dole strony.

Wpływa na linkowanie wewnętrzne, głębokość treści, crawlability, wygodę użytkownika oraz sposób działania filtrów i sortowania.

Najczęstsze problemy wynikają z blokowania kolejnych stron, nieprawidłowych canonicali, paginacji dostępnej wyłącznie przez JavaScript oraz ogromnej liczby kombinacji generowanych przez filtry.

Infinite scroll i przycisk Pokaż więcej mogą poprawić UX, ale najlepiej, gdy pod warstwą interfejsu nadal istnieje logiczna, trwała struktura stron dostępna pod normalnymi adresami URL.

Przy większych serwisach paginację warto analizować jako część całej architektury informacji. Jeżeli użytkownik lub robot musi przejść przez kilkadziesiąt kolejnych stron, aby dotrzeć do ważnego produktu, samo poprawienie wyglądu numerków na dole kategorii nie rozwiąże problemu.