Paginacja dzieli długą listę produktów, artykułów lub wyników na kolejne części dostępne pod osobnymi adresami. Dla użytkownika ma utrzymać orientację i szybkość, a dla wyszukiwarki zapewnić drogę do elementów leżących poza pierwszą stroną. Błędny canonical, `noindex` albo doładowanie wyłącznie w JavaScript mogą odciąć znaczną część katalogu.
Każda część paginacji powinna mieć stabilny URL, self-canonical, normalne linki do stron sąsiednich i dostęp do produktów lub wpisów w HTML. Nie ustawiaj wszystkich stron kanonicznie do pierwszej i nie stosuj `noindex` jako automatycznej recepty. „Załaduj więcej” oraz infinite scroll potrzebują równoległej struktury adresów dostępnej bez gestu przewijania.
Dobierz sposób dzielenia listy do zadania i wielkości zbioru
Numerowana paginacja sprawdza się, gdy użytkownik chce ocenić zakres listy, wrócić do konkretnego miejsca lub przechodzić między częściami. Przycisk „Załaduj więcej” daje płynniejsze przeglądanie i zachowuje poprzednie elementy na ekranie. Infinite scroll może wspierać odkrywanie, ale utrudnia dotarcie do stopki, zapamiętanie miejsca i kontrolę liczby załadowanych pozycji.
Nie dziel listy tylko dlatego, że szablon ma domyślną wartość dwunastu elementów. Uwzględnij wagę kart, szybkość zapytania, rozmiar zdjęć, urządzenia i sposób porównywania. Katalog z krótkimi wierszami może pokazać więcej pozycji niż galeria dużych realizacji. Ustal wartość na podstawie testu wydajności i czytelności.
| Model | Mocna strona | Ryzyko |
|---|---|---|
| Numerowana paginacja | Orientacja, stabilny adres, łatwy powrót | Dodatkowe przejścia między częściami |
| Załaduj więcej | Płynne przeglądanie przy kontroli użytkownika | Stan i URL mogą nie odzwierciedlać zakresu |
| Infinite scroll | Szybka eksploracja strumienia | Brak końca, utrata miejsca, problem ze stopką |
| Jedna pełna lista | Prostota i wyszukiwanie w dokumencie | Duży transfer i wolny interfejs |
| Wirtualizacja | Wydajność bardzo długiej listy w aplikacji | Złożoność dostępności i indeksowania |
Stronicowanie może dotyczyć kategorii sklepu, archiwum bloga, wyników wyszukiwania, komentarzy lub długiej tabeli. Każdy przypadek wymaga innych reguł indeksacji. Kategoria produktów jest często stroną docelową SEO, natomiast wewnętrzne wyniki wyszukiwania mogą pozostawać poza indeksem. Nie kopiuj jednej konfiguracji globalnie.
W szerokim katalogu materiałów i akcesoriów, takim jak oferta poliwęglanu, płyt i rozwiązań do zadaszeń, użytkownik potrzebuje dostępu do dalszych rodzin produktów bez ładowania całego asortymentu jednocześnie. Paginacja lub kontrolowane doładowanie powinny zachować kontekst kategorii i prowadzić do każdej karty.
Przed wyborem modelu uporządkuj filtry i sortowanie. Jeżeli użytkownik musi przejrzeć dwadzieścia stron, bo kategoria łączy nieporównywalne produkty, problemem może być architektura, nie sam komponent. Pomaga w tym poradnik o filtrach w sklepie internetowym.
Każda część potrzebuje adresu, linków HTML i własnego canonicala
Druga i kolejna strona listy powinny mieć stabilny adres, na przykład `/kategoria/page/2/` albo kontrolowany parametr. Po jego otwarciu serwer musi zwrócić właściwy zakres elementów. Nie polegaj wyłącznie na stanie zapisanym w JavaScript, który znika po odświeżeniu lub udostępnieniu linku.
Każda część zazwyczaj wskazuje canonical do siebie, ponieważ zawiera inny zestaw produktów lub wpisów. Canonical wszystkich stron do pierwszej sugeruje, że pozostałe są duplikatami, choć prowadzą do unikalnych elementów. Nie używaj tego jako sposobu na „przekazanie mocy” stronie pierwszej.
Linki do kolejnych części powinny być zwykłymi elementami a z adresem. Przycisk wywołujący skrypt nie daje tej samej ścieżki odkrywania. Użytkownik i robot powinni móc przejść przynajmniej do stron sąsiednich, a duży zbiór potrzebuje logicznego skrótu do początku, końca lub wybranego zakresu.
- Każda część zwraca 200 i właściwy zestaw elementów.
- Canonical wskazuje bieżący, czysty adres strony listy.
- Linki poprzednia/następna działają bez JavaScript.
- Strona poza zakresem zwraca odpowiedni brak, a nie pusty ekran z 200.
- Filtry i sortowanie mają osobną, udokumentowaną logikę URL.
- Linki do produktów prowadzą bezpośrednio do canonicalnych kart.
Nie ustawiaj automatycznie `noindex` na stronach od drugiej. Taka decyzja może ograniczyć obecność list w indeksie, ale nadal potrzebują one skanowania, aby robot odkrył produkty. Najpierw ustal cel, strukturę linków i pokrycie kart. Indeksacja i odkrywanie są powiązane, lecz nie identyczne.
Adresy z sortowaniem zwykle nie tworzą nowej wartości. Parametr „od najtańszych” zmienia kolejność tego samego zbioru. Filtry mogą tworzyć wartościowe podzbiory tylko wtedy, gdy są trwałe, mają zapotrzebowanie i własną treść. Zasady wyboru preferowanego adresu rozwija poradnik o canonicalu.
Mapa XML nie musi zawierać wszystkich stron paginacji, jeśli zawiera canonicalne produkty i główne kategorie, ale linkowanie musi umożliwiać przejście przez listę. Obecność URL-a w sitemapie nie zastępuje prawidłowej nawigacji.
Załaduj więcej i infinite scroll muszą mieć równoległe adresy
Przycisk „Załaduj więcej” może zachować elementy z poprzednich części, co ułatwia porównanie. Po doładowaniu warto zaktualizować adres lub stan historii tak, aby odświeżenie i przycisk Wstecz przywracały podobny zakres. Nie przewijaj użytkownika bez ostrzeżenia i nie usuwaj już obejrzanych kart z DOM-u bez zachowania pozycji.
Infinite scroll uruchamia kolejne pobranie po zbliżeniu się do końca. Dla treści o charakterze strumienia może być wygodny, ale w sklepie użytkownik często chce dotrzeć do stopki, porównać liczbę wyników lub wrócić do konkretnego miejsca. Warto zapewnić pauzę, przycisk ręczny albo wyraźny koniec listy.
Progressive enhancement pozwala zacząć od działających stron i linków, a następnie dodać płynne doładowanie. Gdy skrypt zawiedzie, użytkownik nadal przejdzie dalej. Ten model jest łatwiejszy do testowania i ogranicza ryzyko, że elementy będą dostępne tylko po wykonaniu gestu, którego robot nie odtworzy.
Jeżeli dalsze produkty pojawiają się wyłącznie po zdarzeniu scroll bez odpowiadających adresów i linków, mogą być trudne do odkrycia, udostępnienia i ponownego znalezienia. Interfejs może być dynamiczny, ale struktura informacji musi pozostać trwała.
Doładowanie powinno informować o stanie. Dodaj komunikat dostępny dla czytnika ekranu, nie przenoś fokusu bez potrzeby i zachowaj kolejność DOM. Nowe elementy pojawiają się po istniejących, a użytkownik sam decyduje, czy przejść dalej.
Wydajność oceniaj dla długiej sesji. Pierwsze doładowanie może działać dobrze, a dziesiąte powodować setki elementów, rosnące zużycie pamięci i opóźnienie interakcji. Przy wirtualizacji szczególnie dokładnie testuj fokus, powrót i czytniki ekranu.
Kontrolki mają pokazywać położenie i działać na telefonie
Numer bieżącej strony powinien być wizualnie i programowo oznaczony. Linki „Poprzednia” i „Następna” potrzebują jasnych nazw. Same strzałki są niejednoznaczne, szczególnie przy zmianie kierunku języka. Nie pokazuj wszystkich numerów przy setkach części; zastosuj logiczny zakres wokół bieżącej pozycji.
Na telefonie cele dotykowe muszą mieć odstęp, a paginacja nie może wychodzić poza ekran. W wielu przypadkach wystarczą poprzednia, bieżąca informacja i następna, z możliwością wyboru strony w dodatkowym kontrolowanym widoku. Użytkownik nie potrzebuje dwudziestu małych cyfr ustawionych w jednym wierszu.
Po przejściu na nową część fokus i scroll powinny zachowywać się przewidywalnie. Pełne przejście może ustawić początek głównej treści, a doładowanie powinno pozostawić użytkownika przy kontrolce lub pierwszym nowym elemencie bez nagłego skoku. Komunikat „wyświetlono 25 z 120” pomaga ocenić postęp.
- Bieżąca część jest oznaczona także poza kolorem.
- Kontrolki mają dostępne nazwy i logiczną kolejność tabulatora.
- Mobile nie wymaga precyzyjnego trafiania w małe cyfry.
- Zmiana strony nie gubi wybranych filtrów i sortowania.
- Powrót z produktu odtwarza część listy i miejsce.
- Stan ładowania oraz koniec wyników są czytelne.
Paginację umieść pod listą, a przy bardzo długich stronach można dodać skrót również nad nią. Nie dubluj dwóch komponentów o różnych stanach. Liczba wyników, aktywne filtry i sposób sortowania powinny pozostać widoczne przed listą.
Sprawdź działanie przy powiększeniu tekstu, klawiaturą, czytnikiem ekranu i przy wolnym połączeniu. Szersze zasady opisuje poradnik o dostępności strony według WCAG.
Nie powielaj pełnego opisu kategorii na każdej części
Główny opis kategorii powinien być związany z pierwszą stroną albo prezentowany w sposób, który nie tworzy dziesiątek identycznych bloków. Na dalszych częściach najważniejsza jest lista i orientacja. Krótkie wprowadzenie może pozostać, jeśli pomaga użytkownikowi, lecz długi tekst SEO powtarzany w całości utrudnia korzystanie.
Tytuł dokumentu i meta opis mogą odzwierciedlać numer części, aby odróżnić adresy. H1 zwykle zachowuje nazwę kategorii, a informacja „strona 2” może być widoczna obok lub w tytule. Nie udawaj, że każda część jest osobną kategorią o unikalnym znaczeniu.
Sortowanie powinno zachować wybrane kryterium przy przechodzeniu dalej, ale adresy sortowania wymagają decyzji SEO. Nie pozwalaj, aby crawler odkrywał nieskończone kombinacje kolejności, limitu elementów i parametrów sesji. Linki dostępne dla robota powinny prowadzić do kontrolowanego zestawu wariantów.
Karty na kolejnych stronach potrzebują tych samych danych i jakości co na pierwszej. Nie obniżaj rozdzielczości do poziomu uniemożliwiającego ocenę ani nie usuwaj kluczowych parametrów. Lazy loading obrazów pomaga, ale pierwsze widoczne elementy nowej części powinny pojawić się szybko i bez przeskoków. Proces optymalizacji rozwija poradnik o optymalizacji zdjęć.
Produkty mogą zmieniać kolejność wraz z dostępnością. Nie opieraj stabilnego linku do karty na numerze strony. Wszystkie odnośniki prowadzą do własnego URL-a produktu, a paginacja jest jedynie bieżącym widokiem listy. Przy powrocie można odtworzyć poprzedni stan z historii.
Jeżeli kategoria ma stale tylko kilka elementów, paginacja jest zbędna. Usuń nieaktywne kontrolki i nie generuj pustej strony drugiej. Liczba części powinna wynikać z rzeczywistych wyników po zastosowaniu filtra.
Skanuj pełny ciąg i sprawdzaj dostęp do najgłębszych elementów
Audyt techniczny powinien otworzyć stronę pierwszą, przejść po linkach do ostatniej oraz zebrać wszystkie karty. Sprawdź statusy, canonical, robots, tytuły, H1, liczbę elementów i duplikaty. Osobno zweryfikuj adres poza zakresem, na przykład stronę 99 przy trzech dostępnych częściach.
Porównaj liczbę produktów w systemie z liczbą unikalnych kart odkrytych przez crawl. Różnica może wynikać z brakujących linków, filtrów, produktów ukrytych lub błędu aplikacji. Nie zakładaj od razu, że każdy rekord ma być indeksowany, ale każdy publiczny produkt powinien mieć uzasadnioną ścieżkę.
W Search Console obserwuj wzorce adresów, nie pojedynczy przykład. Logi serwera mogą pokazać, czy robot odwiedza dalsze części, ale brak wizyty w krótkim okresie nie jest dowodem blokady. Po zmianie sposobu ładowania porównaj crawl, indeksację i odkrywanie nowych kart.
Testy regresji powinny obejmować zmianę liczby produktów, usunięcie ostatniej części, dodanie filtra, sortowanie, powrót z karty, wyłączenie JavaScript i wersję mobilną. Każda aktualizacja platformy może zmienić generowanie linków lub canonicali. Automatyzacja sprawdza strukturę, a screenshoty potwierdzają użyteczność kontrolek.
Jeśli stary model adresów został zastąpiony, przygotuj przekierowania tylko między odpowiadającymi sobie widokami. Nie kieruj wszystkich stron paginacji na stronę pierwszą bez analizy. Zaktualizuj wewnętrzne linki, a stare mapowanie przetestuj zgodnie z poradnikiem o sprawdzaniu przekierowań.
Paginacja działa, gdy każda część ma stabilny adres i self-canonical, kolejne zakresy są dostępne przez linki HTML, powrót zachowuje kontekst, kontrolki są czytelne na mobile, a crawl potrafi dotrzeć do wszystkich publicznych elementów bez wykonywania nieskończonych kombinacji parametrów.