무한 스크롤 목록의 검색엔진최적화, 페이지 주소와 다음 링크가 답입니다
무한 스크롤 목록의 검색엔진최적화는 불러오는 묶음마다 고정된 페이지 주소를 주는 데서 시작합니다. 다음 페이지 주소는 a 요소의 href 링크로 HTML에 넣습니다. Google 문서는 크롤러가 버튼을 누르지 않고, 사용자 동작이 필요한 자바스크립트도 대개 실행하지 않는다고 설명합니다. 스크롤 없이 주소와 링크만 따라가도 마지막 항목까지 닿게 만드는 것이 핵심입니다.
무한 스크롤 목록은 왜 뒤쪽 항목이 수집되지 않나요?
무한 스크롤(화면을 내리면 다음 항목을 자동으로 붙여 보여 주는 방식)과 더 보기 버튼은 대개 자바스크립트로 만듭니다. 페이지 나누기 문서는 Google 크롤러가 버튼을 「클릭」하지 않는다고 설명합니다. 사용자 동작이 필요한 자바스크립트 함수도 대개 실행하지 않는다고 덧붙입니다.
지연 로딩 문서 역시 Google 검색은 페이지와 상호작용하지 않는다고 적습니다. 그래서 첫 화면에 그려진 항목은 수집되어도, 스크롤해야 나타나는 항목은 크롤러에게 보이지 않을 수 있습니다.
2014년 Google 검색 블로그의 무한 스크롤 권장 글(현행 문서보다 이전 안내)도 같은 문제를 다뤘습니다. 크롤러가 스크롤이나 더 보기 클릭 같은 사용자 행동을 항상 흉내 낼 수는 없다는 내용입니다. 실무에서는 사용자 화면은 무한 스크롤로 두고, 번호가 매겨진 페이지 구조를 함께 갖추는 방법을 권합니다.
작업 전에 현재 수집 범위는 어떻게 확인하나요?
먼저 Search Console의 URL 검사 도구에서 목록 첫 페이지 주소를 실시간 테스트합니다. 결과의 테스트된 페이지 보기에서 렌더링된 HTML(자바스크립트 실행 뒤의 HTML)과 스크린샷을 엽니다.
URL 검사 도움말에 따르면 기본 검사 결과는 실시간 테스트가 아니라 가장 최근에 색인된 버전입니다. 스크린샷도 실시간 테스트에서만 볼 수 있습니다. 그래서 수정 전후 비교는 실시간 테스트 결과로 합니다.
렌더링된 HTML에서 다음 세 가지를 찾습니다.
- 첫 화면 이후에 붙는 항목의 이름이 HTML에 있는지
- 다음 페이지로 가는 a 요소와 href 주소가 있는지
- 목록 뒤쪽 상품·글의 상세 페이지가 색인되어 있는지
브라우저에서 자바스크립트를 끄고 목록을 여는 점검도 함께 합니다. 2014년 권장 글은 목록을 자바스크립트 없이도 열리는 구성 페이지로 나누라고 안내했습니다.
완료 확인: 목록 뒤쪽 상품·글의 상세 주소 3~5개를 골라 URL 검사의 색인 상태를 기록합니다. 이 기록이 수정 뒤 비교 기준이 되므로, 기록을 마친 뒤 다음 단계로 넘어갑니다.
목록은 어떤 주소 단위로 나눠야 하나요?
지연 로딩 문서는 스크롤로 불러오는 묶음마다 지속적이고 고유한 주소를 주라고 설명합니다. 같은 주소는 브라우저에서 열 때마다 같은 내용을 보여야 합니다. 이를 위해 ?page=12 같은 절대 페이지 번호를 쓰고, ?date=yesterday 같은 상대 값은 피하라고 안내합니다.
페이지 나누기 문서는 페이지 번호에 조각 식별자(주소의 # 뒤 부분)를 쓰지 말라고 설명합니다. Google이 # 뒤 부분을 무시하기 때문입니다.
| 구분 | 권장 형식 | 피할 형식 | 근거 |
|---|---|---|---|
| 페이지 번호 | ?page=3 | #page3 | 페이지 나누기 문서: Google은 # 뒤 부분을 무시합니다 |
| 기준 값 | ?page=12 같은 절대 번호 | ?date=yesterday 같은 상대 값 | 지연 로딩 문서: 같은 주소는 늘 같은 내용이어야 합니다 |
| 페이지 경계 | 한 항목은 한 페이지에만 표시 | 앞 페이지 마지막 항목을 반복 표시 | 2014년 글: 구성 페이지끼리 겹치지 않게 나눕니다 |
| 직접 접근 | 쿠키·방문 이력 없이 단독으로 열림 | 앞 페이지를 거쳐야 열림 | 2014년 글: 같은 쿠키·이력 없이 열려야 합니다 |
| 범위 밖 번호 | 마지막 쪽보다 큰 번호는 404 응답 | 빈 목록을 정상 페이지로 응답 | 2014년 글: 범위를 벗어난 페이지는 404를 돌려줍니다 |
페이지당 항목 수에 대해 2014년 글은 적절한 로딩 시간을 유지하라고만 안내합니다. 실무에서는 해당 페이지로 바로 들어온 사용자가 오래 스크롤하지 않고 항목을 찾을 수 있는 수준으로 정하는 방법을 권합니다.
완료 확인: 쿠키가 없는 시크릿 창에서 ?page=3 주소를 직접 여러 번 엽니다. 매번 같은 항목이 나오는지, 2쪽과 3쪽에 겹치는 항목이 없는지, 범위 밖 번호가 404를 돌려주는지 결과를 기록합니다.
다음 페이지 링크와 주소창 갱신은 어떻게 연결하나요?
지연 로딩 문서는 묶음별 주소를 순서대로 링크해 검색엔진이 찾을 수 있게 하라고 설명합니다. 링크 형식은 링크 문서가 정합니다. Google은 href 속성이 있는 a 요소일 때 링크를 수집할 수 있습니다.
같은 문서는 href가 없는 a 요소에서는 주소를 안정적으로 추출할 수 없다고 적습니다. span 요소에 붙인 href, onclick만 있는 a 요소, 자바스크립트 함수를 호출하는 href 값은 권장하지 않는 예로 듭니다. 자바스크립트로 나중에 넣은 링크도 같은 형식의 HTML이면 수집할 수 있다고 덧붙입니다.
예를 들어 가상의 ○○ 쇼핑몰 신발 목록이라면 다음과 같이 구성할 수 있습니다.
- HTML: 목록 아래에 「다음 목록」 링크를 a 요소로 두고 href 값에 ?page=2를 넣습니다.
- 자바스크립트: 사용자가 스크롤하면 이 링크의 주소로 다음 묶음을 불러와 목록에 붙입니다.
- 주소창: 다음 묶음을 불러오면 표시 주소를 ?page=2로 바꿉니다.
- 각 페이지: 1페이지로 돌아가는 링크도 함께 둡니다.
주소창 갱신은 History API(새로고침 없이 주소를 바꾸는 브라우저 기능)로 합니다. 지연 로딩 문서는 스크롤에 따라 새 묶음을 불러올 때 History API로 표시 주소를 갱신하라고 설명합니다. 2014년 권장 글은 클릭이나 페이지 넘김에 가까운 사용자 동작에는 pushState 함수를 쓰라고 안내했습니다. 이렇게 하면 사용자가 새로고침하거나 주소를 공유해도 같은 묶음이 열립니다.
페이지 나누기 문서는 모든 페이지에서 첫 페이지로 링크하는 방법을 제안합니다. 예전에 쓰던 rel next·prev 속성은 Google이 더 이상 사용하지 않으며, 다른 검색엔진은 쓸 수 있다고 설명합니다.
완료 확인: 렌더링된 HTML에서 다음 목록 링크가 마지막 페이지까지 이어지는지 확인합니다. 스크롤할 때 주소창 번호가 바뀌고, 그 상태에서 새로고침해 같은 묶음이 열리면 다음 단계로 넘어갑니다.
표준 주소·필터·이미지 지연 로딩은 무엇을 맞춰야 하나요?
주소와 링크를 갖춰도 아래 설정이 어긋나면 일부 페이지가 수집·색인 대상에서 빠질 수 있습니다.
| 항목 | Google 문서의 설명 | 확인 방법 |
|---|---|---|
| 표준 주소(canonical, 대표로 색인할 주소 지정) | 첫 페이지를 순번 페이지 전체의 표준 주소로 쓰지 않고, 페이지마다 자기 표준 주소를 둡니다 | ?page=3의 표준 주소가 ?page=3을 가리키는지 봅니다 |
| 제목·설명 | 순번 페이지끼리 같은 제목과 설명을 써도 됩니다 | 같은 제목이면 그대로 둡니다. 구분하려면 끝에 「2페이지」처럼 번호를 붙입니다 |
| 필터·정렬 주소 | 원치 않는 변형 주소는 noindex로 색인을 막거나, robots.txt로 수집을 줄입니다 | 둘 중 하나만 고릅니다. ?sort= 주소에 noindex를 넣었다면 robots.txt에서 막지 않았는지 봅니다 |
| 이미지 지연 로딩 | 브라우저 기본 지연 로딩이나 IntersectionObserver로 화면에 들어올 때 불러옵니다 | 렌더링된 HTML의 img 요소 src에 실제 이미지 주소가 있는지 봅니다 |
두 방법 중 하나만 고르는 이유는 noindex 문서에 있습니다. robots.txt로 막은 페이지는 크롤러가 noindex 규칙을 보지 못해, 검색결과에 그대로 나타날 수 있다고 설명합니다.
지연 로딩 문서는 페이지를 열자마자 보일 가능성이 큰 내용에는 지연 로딩을 쓰지 말라고 안내합니다. 1페이지, 중간 페이지, 마지막 페이지에서 표의 네 항목이 모두 맞으면 다음 단계로 넘어갑니다.
수정 뒤 끝까지 수집되는지 어떻게 검증하나요?
페이지 나누기 문서는 모든 상품을 찾을 수 있도록 사이트맵이나 Merchant Center 피드 사용을 검토하라고 권합니다. 목록 구조와 별개로 상세 페이지 주소를 알리는 경로를 하나 더 만드는 셈입니다.
사이트맵 문서에 따르면 사이트맵 하나에는 압축 전 50MB 또는 URL 50,000개까지 담을 수 있습니다. 넘으면 여러 파일로 나누고 사이트맵 색인 파일로 묶습니다. 주소는 프로토콜과 도메인까지 쓴 절대 주소로 적고, 대표 버전만 넣습니다.
제출은 Search Console의 사이트맵 보고서나 robots.txt의 Sitemap 줄로 합니다. 같은 문서는 사이트맵이 힌트일 뿐이라고 설명합니다. 그래서 제출 뒤에도 실제 수집 여부를 다음 순서로 따로 확인합니다.
- URL 검사 도구로 1페이지, 중간 페이지, 마지막 페이지 주소를 실시간 테스트합니다.
- 각 렌더링된 HTML에서 해당 페이지 항목과 다음 목록 링크를 찾습니다.
- 처음에 기록한 뒤쪽 항목 상세 주소의 색인 상태를 다시 검사합니다.
- 바뀐 주요 페이지만 색인 생성을 요청하고, 나머지는 사이트맵에 맡깁니다.
- 1~2주 뒤 같은 주소를 다시 검사해 처음 기록과 비교합니다.
URL 검사 도움말은 색인 생성이 최대 1~2주 걸릴 수 있고, 하루 요청 수에 제한이 있다고 안내합니다. 요청해도 색인에 표시되지 않을 수 있습니다. URL이 Google에 등록되어 있다고 나와도 검색결과 노출까지 보장되는 것은 아닙니다.
점검 결과는 다음 양식으로 기록합니다. 아래 행은 가상의 예입니다.
| 확인일 | 검사한 주소 | 렌더링 HTML의 항목 | 다음 목록 링크 | 색인 상태 | 다음 조치 |
|---|---|---|---|---|---|
| 2026-11-02 | 신발 목록 ?page=1 | 24개 모두 있음 | 있음(?page=2) | 등록됨 | 없음 |
| 2026-11-02 | 신발 목록 ?page=9 | 앞쪽 8개만 있음 | 없음 | 미등록 | 지연 로딩 방식과 링크 출력 점검 |
완료 확인: 마지막 페이지까지 렌더링된 HTML과 다음 목록 링크를 확인합니다. 뒤쪽 항목의 색인 상태는 처음 기록 옆에 적어 비교합니다.
정리
무한 스크롤은 사용자 화면의 표시 방식입니다. 크롤러가 따라갈 주소와 링크가 HTML에 있어야 목록 끝까지 수집될 수 있습니다.
- URL 검사 도구로 목록 첫 페이지와 뒤쪽 항목의 현재 상태를 기록합니다.
- 목록을 ?page=n 형식의 고정 주소로 나누고, 항목이 페이지끼리 겹치지 않게 합니다.
- 다음 페이지 a href 링크를 넣고, 새 묶음을 불러올 때 History API로 주소를 바꿉니다.
- 페이지별 표준 주소, 필터·정렬 주소의 noindex 또는 robots.txt 중 한 가지, 이미지 src를 확인합니다.
- 상세 페이지 사이트맵을 제출하고, 1~2주 뒤 같은 주소를 다시 검사해 기록과 비교합니다.
참고 자료
- Pagination, incremental page loading, and their impact on Google Search (Google Search Central, 확인일 2026-10-22)
- Fix lazy-loaded content (Google Search Central, 확인일 2026-10-22)
- Link best practices for Google (Google Search Central, 확인일 2026-10-22)
- Block Search indexing with noindex (Google Search Central, 확인일 2026-10-22)
- Infinite scroll search-friendly recommendations (Google Search Central 블로그, 2014, 확인일 2026-10-22)
- URL 검사 도구 (Search Console 고객센터, 확인일 2026-10-22)
- Build and submit a sitemap (Google Search Central, 확인일 2026-10-22)