Paginacja czy infinite scroll – co wybrać dla SEO i UX?

Trzy rozwiązania w praktyce

Paginacja dzieli listę na numerowane podstrony z własnymi adresami, np. /kategoria/page/2/. Użytkownik wie, gdzie jest, może wrócić do konkretnej strony i wysłać komuś link. Robot wyszukiwarki dostaje zwykłe linki, po których przechodzi bez problemu. Wadą jest dodatkowe kliknięcie i przeładowanie strony przy każdej zmianie.

Infinite scroll dokłada kolejne elementy, gdy użytkownik zbliża się do końca listy. Przeglądanie jest płynne i nie wymaga klikania, ale użytkownik traci orientację, ile treści już widział, nie dociera do stopki, a po wejściu w produkt i powrocie często ląduje z powrotem na początku listy.

Przycisk „Pokaż więcej” to rozwiązanie pośrednie: kolejne elementy doładowują się na tej samej stronie, ale dopiero po świadomym kliknięciu. Użytkownik zachowuje kontrolę i dostęp do stopki, a przy poprawnym wdrożeniu każda porcja treści ma też swój adres.

Jak każde z nich widzi Google

Z perspektywy SEO kluczowe jest jedno pytanie: czy robot może dotrzeć do elementów z dalszej części listy. Googlebot nie przewija strony jak człowiek i nie klika przycisków. Podąża za linkami <a href> obecnymi w kodzie. Wynikają z tego proste wnioski:

• Paginacja działa, jeśli numery stron są prawdziwymi linkami w HTML-u, a nie elementami obsługiwanymi wyłącznie przez JavaScript.
• Infinite scroll bez dodatkowych adresów to dla robota tylko pierwsza porcja wyników. Produkty z dalszych pozycji mogą być dla niego niewidoczne, jeśli nie prowadzą do nich inne linki.
• „Pokaż więcej” jest bezpieczne, gdy przycisk jest w rzeczywistości linkiem do kolejnej strony, np. ?page=2, a JavaScript jedynie przechwytuje kliknięcie i doładowuje treść bez przeładowania.

W praktyce oznacza to, że niezależnie od tego, co widzi użytkownik, pod spodem zawsze powinna istnieć paginacja z adresami, po których da się przejść bez JavaScriptu. W dużych sklepach ma to bezpośredni wpływ na to, czy robot w ogóle znajdzie głębiej położone produkty, dlatego ten element sprawdzam zawsze przy optymalizacji crawl budgetu.

Jak konfiguruję paginację pod SEO

• Canonical na samą siebie. Strona 2 ma canonical wskazujący stronę 2, a nie pierwszą stronę kategorii. Wskazanie strony 1 na wszystkich podstronach mówi Google, że dalsze strony są duplikatami, a wtedy linki do produktów z nich mogą zostać pominięte.
• Opis kategorii tylko na pierwszej stronie. Jeśli system powtarza ten sam tekst na każdej podstronie, wyłączam go w szablonie od strony 2. To lepsze rozwiązanie niż kombinowanie z canonical.
• Numer strony w tytule. Tytuł typu „Buty do biegania – strona 2” eliminuje zduplikowane tytuły w raportach i pomaga użytkownikowi zorientować się w kartach przeglądarki.
• Bez noindex i bez blokady w robots.txt. Strony paginacji z noindex z czasem przestają przekazywać robotom linki, co odcina drogę do starszych wpisów i produktów. Z tego samego powodu nie blokuję ich w pliku robots.txt.
• Czytelne adresy. Stosuję jeden format, np. /page/2/ albo ?page=2, i pilnuję, żeby strona 1 nie istniała pod dwoma adresami (z parametrem i bez).

Znaczniki rel="next" i rel="prev" mogą zostać w kodzie, ale Google od 2019 roku nie wykorzystuje ich przy indeksowaniu. O powiązaniu stron decydują zwykłe linki w nawigacji, które przy okazji wzmacniają linkowanie wewnętrzne całej kategorii.

Wydajność i dostępność

Infinite scroll ma koszt, którego nie widać na pierwszy rzut oka. Każda doładowana porcja zostaje w pamięci, więc po kilku minutach przewijania strona ma setki, a czasem tysiące elementów. Rosnące drzewo DOM spowalnia przewijanie i reakcję na kliknięcia, co odbija się na wskaźniku INP, a treść wstawiana nad aktualnie oglądanym miejscem powoduje przesunięcia układu. Przy długich listach stosuję wtedy wirtualizację, czyli renderowanie tylko widocznych elementów.

Druga sprawa to dostępność. Użytkownik poruszający się klawiaturą lub korzystający z czytnika ekranu w infinite scrollu łatwo gubi pozycję, a stopka z kontaktem czy regulaminem staje się praktycznie nieosiągalna. Przy paginacji i przycisku „Pokaż więcej” po doładowaniu przenoszę fokus na pierwszy nowy element i ogłaszam liczbę dodanych pozycji, żeby osoba korzystająca z czytnika wiedziała, co się zmieniło.

Jak wdrażam „Pokaż więcej” z zachowaniem adresów

W sklepach najczęściej wybieram rozwiązanie hybrydowe, które łączy wygodę doładowywania z bezpieczeństwem paginacji:

1. Serwer generuje zwykłe strony ?page=1, ?page=2 itd., każdą z pełną listą produktów dla danej porcji.
2. Przycisk „Pokaż więcej” jest linkiem <a href="?page=2">. Bez JavaScriptu działa jak zwykła paginacja.
3. JavaScript przechwytuje kliknięcie, pobiera kolejną porcję i dołącza ją do listy.
4. Adres w pasku przeglądarki aktualizuję przez History API, aby odświeżenie strony lub udostępniony link prowadziły do tego samego miejsca.
5. Po powrocie z karty produktu przywracam liczbę doładowanych porcji i pozycję przewinięcia, żeby użytkownik nie zaczynał od początku.

Ostatni punkt jest najczęściej pomijany, a to on decyduje o tym, czy użytkownicy chętnie przeglądają długie listy, czy porzucają je po pierwszym kliknięciu w produkt.

Co wybieram w zależności od serwisu

• Kategorie w sklepie internetowym: „Pokaż więcej” z adresami lub klasyczna paginacja. Użytkownik porównuje produkty i wraca do listy, więc potrzebuje stabilnej pozycji i dostępu do filtrów.
• Wyniki wyszukiwania w sklepie: paginacja lub „Pokaż więcej”, z liczbą wszystkich wyników widoczną od razu.
• Archiwum bloga: klasyczna paginacja. Czytelnik szuka konkretnego wpisu, a robot potrzebuje prostych ścieżek do starszych treści.
• Galerie i serwisy inspiracji: infinite scroll ma sens, bo celem jest przeglądanie, a nie znalezienie konkretnej pozycji. Nawet tu zostawiam pod spodem adresy kolejnych porcji dla robotów.

Decyzję zawsze opieram na tym, czy użytkownik przychodzi coś znaleźć, czy tylko przeglądać. Wtedy wybór rozwiązania przestaje być kwestią mody, a staje się elementem projektowania UX, który można sprawdzić w testach i analityce.