본문으로 이동
ㅇㅈㅁㅆ
테크니컬 SEO

페이지네이션

Pagination

페이지네이션은 긴 목록이나 연속 콘텐츠를 여러 페이지로 나누고 각 묶음에 고유 URL과 이동 링크를 제공해 새로고침·공유·순차 탐색 뒤에도 같은 부분을 다시 찾게 하는 방식입니다. 사용자의 스크롤 동작만으로 다음 내용을 불러오는 무한 스크롤과 구현·발견 방식이 다릅니다.

AI 보조 조사·작성 후 원문과 대조한 설명입니다. 사례·계산은 별도 출처 표기가 없는 한 이해를 위한 가상 예시이며 실제 고객 성과가 아닙니다.

가상 목록의 다음 링크는 어떻게 쓰나요?

가상 상품 목록 1페이지가 다음 묶음으로 연결될 때 <a href="/products?page=2">다음 상품</a>처럼 실제 주소가 있는 링크를 제공합니다. 2페이지는 항상 같은 기준의 두 번째 상품 묶음을 응답하고 자기 URL을 canonical로 지정합니다. 모든 페이지를 1페이지 canonical로 보내면 뒤쪽 상품이 독립된 목록으로 처리되기 어려울 수 있습니다.

검수 항목

  • JavaScript를 끄더라도 다음 URL을 링크로 찾을 수 있는가?
  • 새로고침과 공유 뒤 같은 묶음이 열리는가?
  • 페이지 번호와 정렬 조건이 안정적인가?
  • 필터·정렬 변형의 색인 정책이 별도로 있는가?

무한 스크롤과 페이지네이션은 함께 쓸 수 있나요?

사용자 화면은 무한 스크롤로 만들면서 기계와 공유를 위한 페이지 URL을 함께 제공할 수 있습니다. 새 묶음이 주 화면이 되면 History API로 표시 URL을 갱신하는 방식도 검토합니다. 화면 방식과 URL 구조를 분리해 생각하면 스크롤 편의와 재방문·발견 가능성을 함께 점검할 수 있습니다.

페이지를 나누면 속도와 색인이 보장되나요?

보장되지 않습니다. 한 번에 내려받는 항목은 줄어들 수 있지만 데이터 요청과 스크립트 구현이 비효율적이면 체감 속도가 나빠질 수 있으며 고유 링크가 없으면 뒤쪽 콘텐츠를 발견하지 못할 수 있습니다. 페이지별 응답과 렌더링된 항목과 내부 링크와 색인 상태를 따로 기록해야 화면이 부드럽다는 평가를 검색 접근성 완료로 바꾸지 않을 수 있습니다. 같은 목록을 모바일 앱과 웹이 서로 다른 번호 체계로 제공한다면 공유 URL과 서버 응답 기준을 먼저 통일해야 페이지 순서가 방문할 때마다 달라지는 문제도 줄일 수 있습니다.

자주 묻는 질문

2페이지 이후를 첫 페이지 canonical로 지정해야 하나요?
아닙니다. 각 페이지가 고유 상품 묶음을 제공한다면 자기 URL을 canonical로 두는 것이 일반적인 안내입니다.
무한 스크롤이면 페이지 URL이 필요 없나요?
검색과 공유·새로고침을 위해 각 묶음에 지속적인 URL과 순차 링크를 제공해야 합니다.

출처와 확인 범위

  1. Pagination, incremental page loading, and their impact on Google Search · Google Search Central · 확인 2026-10-27

    페이지네이션은 각 페이지에 고유 URL과 크롤링 가능한 순차 링크를 제공하고 모든 페이지를 첫 페이지 canonical로 지정하지 않아야 합니다.

    확인 범위: 표시한 절의 정의·프로토콜·측정 조건·한계만 사용했습니다. 크롤링·렌더링·색인·검색 노출·속도·순위·처리 기간 보장은 근거로 사용하지 않았습니다.

  2. Fix lazy-loaded content · Google Search Central · 확인 2026-10-27

    무한 스크롤 콘텐츠는 각 묶음에 지속적인 고유 URL과 순차 링크를 제공해야 하며 사용자 스크롤·클릭만으로 핵심 콘텐츠를 불러오지 않아야 합니다.

    확인 범위: 표시한 절의 정의·프로토콜·측정 조건·한계만 사용했습니다. 크롤링·렌더링·색인·검색 노출·속도·순위·처리 기간 보장은 근거로 사용하지 않았습니다.

용어 설명 정정 요청