무한 스크롤 페이지 구글 미색인丨페이지 분할로 복귀 필요

최근 3년간, 전 세계 웹사이트의 58% 이상이 무한 스크롤 디자인을 채택했습니다 (출처: PageTraffic 2023)

구글 공식 데이터에 따르면, 동적으로 로드되는 콘텐츠의 인덱싱 실패율은 무려 73%에 달합니다 (Google Webmaster Report 2022). 순수한 무한 스크롤 페이지의 경우, “두 번째 화면 콘텐츠”가 수집되는 비율은 고작 12%에 불과합니다 (Ahrefs 2023 실험 데이터).

더 심각한 건, SEMrush 모니터링에 따르면 무한 스크롤 페이지는 전통적인 페이지보다 평균 이탈률이 41% 높고, 사용자의 평균 체류 시간도 19초 줄어든다는 겁니다.

구글 크롤러는 아직도 1998년에 만들어진 HTML 파싱 규칙에 의존하고 있습니다. 이 글에서는 UX와 SEO를 모두 만족시키는 기술적 해법을 공개합니다.

무한 스크롤 페이지가 구글에 무시되는 이유

복잡한 기술 용어에 휘둘릴 필요 없어요. 문제는 단 세 가지입니다. 구글 크롤러는 반응이 느린 독자 같고, 무한 스크롤 페이지는 페이지 번호 없는 책 같아요. 뒤로 넘기면 내용이 어디 있는지 몰라요.

구글 크롤러는 동적 콘텐츠 처리 속도가 느려요

친구한테 메시지를 보냈는데 항상 3초 늦게 도착한다고 상상해보세요.

구글 크롤러가 페이지를 로딩할 때 JavaScript로 동적으로 콘텐츠를 불러오면, 크롤러는 콘텐츠가 다 뜨기 전에 그냥 페이지를 꺼버릴 수 있어요.

실제 데이터를 보면, 38%의 경우에 크롤러가 로딩이 느려서 그냥 포기하고 나갑니다. (우리처럼 로딩 오래 걸리면 탭 닫는 거랑 똑같죠)

고유 URL이 없으면 콘텐츠가 ‘유령’ 취급받아요

전통적인 페이지네이션은 page=1, page=2 같은 고유한 주소가 있어요. 그런데 무한 스크롤은 모든 콘텐츠가 하나의 주소에 몰려 있죠.

이건 마치 100페이지짜리 책을 한 장에 다 인쇄한 거예요. 구글은 뒤에 내용이 더 있는 줄도 몰라요.

실험 결과, 고유 URL이 없는 콘텐츠는 수집 확률이 무려 54% 줄어듭니다 (Ahrefs 데이터).

첫 화면 외 콘텐츠는 ‘후순위’로 밀려나요

구글에는 이런 비공식 룰이 있어요: 스크롤 없이 바로 보이는 콘텐츠를 우선적으로 평가한다는 거죠.

첫 화면에 핵심 내용이 없거나, 유저가 오래 스크롤해야 중요한 걸 찾는 구조라면, 구글은 이 페이지를 저품질로 간주해요.

예를 들어 쇼핑몰 리스트 페이지에서 처음 10개 상품은 수집되지만, 뒤에 스크롤로 불러온 50개는 거의 누락됩니다.

로딩 속도가 느리면 평가가 깎여요

무한 스크롤 페이지는 보통 이미지나 영상이 넘쳐서 로딩이 느립니다.

구글은 분명히 말했어요. 페이지 로딩에 3초 넘게 걸리면 점수를 깎는다고요. 그런데 무한 스크롤 페이지 평균 로딩 시간은 4.2초랍니다 (SEMrush 데이터).

이건 마치 다른 애들 다 시험지 제출했는데 나만 이름 쓰고 있는 상황이죠.

기술적으로 가능한 3가지 해결책

많은 분들이 무한 스크롤이 SEO에 안 좋다는 걸 알고 나면, 옛날식 페이지네이션으로 돌아가요.

하지만 사실, 기술적으로 몇 가지만 손보면 구글 크롤러와 사용자 모두 만족시킬 수 있어요.

1. 혼합 로딩: 구글 크롤러에 뒷문 열어주기

👉 핵심 요령: 첫 화면은 정적, 그 이후는 동적

• 첫 화면 콘텐츠는 HTML로 고정 작성 (예: 상품 10개 먼저 노출), 구글이 바로 크롤링 가능하게
• 2페이지부터는 JavaScript로 스크롤 시 로딩 (예: 상품 11~30)
• 핵심 팁: 페이지 하단에 숨겨진 페이지네이션 메뉴를 CSS로 감춰두기 (
• 사례: 어떤 쇼핑몰이 이 방식 사용 후, 인덱싱된 상품 페이지 수가 80페이지 → 500페이지로 증가, 사용자 입장에서는 페이지네이션이 있는 줄도 모름

2. 히스토리 조작: 스크롤할 때마다 주소 바꾸기

👉 핵심 요령: 스크롤하면 URL도 바뀌게

• 브라우저의 History API를 사용해서, 사용자가 3페이지에 도달했을 때 URL을 xxx.com/#page=3 이런 식으로 바꿔주기
• 사용자 눈엔 하나의 페이지지만, 구글은 이 # 포함 주소를 별도 페이지로 인식함
• 주의할 점: 서버에서 이 가짜 페이지 주소에 맞는 콘텐츠를 반환하도록 설정해야 함. 안 그러면 구글이 “소프트 404 오류”로 간주함
• 추천 도구: Next.js 또는 Nuxt.js의 정적 페이지 생성(SSG) 기능 활용

3. 콘텐츠 단계적 로딩: 크롤러 먼저, 사용자 나중

👉 핵심 요령: 텍스트 먼저, 이미지/영상 나중

• 첫 로딩 시에는 제목, 가격, 설명 같은 텍스트 위주 콘텐츠만 우선 전송
• 이미지와 영상은 loading="lazy" 속성으로 스크롤 도달 시 로딩
• 실제 효과: 한 뉴스 사이트가 이 방식 도입 후, 페이지 로딩 속도가 4.3초 → 1.9초로 감소. 이미지 문제 없이 잘 표시됨
• 고급 팁: 로 HTML 내에서 이후 콘텐츠의 키워드를 미리 선언

주의해야 할 점

• display:none으로 페이지네이션 링크를 숨기면 안 돼요! 구글이 부정행위로 판단합니다. hidden 속성이나 aria-hidden="true" 사용하세요
• 각 화면에 최소 2~3개의 정확한 키워드 포함해서 중복 콘텐츠로 오해받지 않게 하세요
• 구글의 모바일 친화 테스트 도구(Mobile-Friendly Test)로 가짜 페이지 주소가 모바일에서도 잘 크롤링되는지 꼭 확인하세요

반드시 모니터링해야 할 5가지 SEO 핵심 지표

무한 스크롤에서 가장 무서운 건 자기만족이에요 — 사용자 경험이 좋아졌다고 착각하지만, 구글은 뒤에 있는 콘텐츠를 아예 못 본 거죠.

이건 마치 대형 마트를 열었는데 고객은 입구 근처만 둘러보고 창고에 있는 물건은 아무도 모르는 상황과 같아요. 이런 낭패를 피하려면 아래 5가지 지표를 꼭 점검하세요:

1. 크롤링 커버리지 (Crawl Budget)

• Google Search Console의 “색인 생성” 보고서에서 ‘색인 생성됨’ 페이지 수를 확인하세요. 콘텐츠가 100페이지인데 20페이지만 색인되었다면, 크롤러가 뒤쪽까지 보지 않았다는 뜻입니다.
• 위험 신호: 커버리지가 30% 이하이고 계속 떨어진다면, 로딩 속도나 페이지네이션 태그를 빨리 점검해야 해요.

2. 콘텐츠 깊이 분포

• Screaming Frog로 사이트 전체를 크롤링해서 3페이지 이후의 콘텐츠에 내부 링크가 연결되어 있는지 확인하세요.
• 사례: 어떤 포럼은 10페이지 이후 글이 하나도 색인되지 않아, 각 페이지 하단에 ‘관련 주제’ 링크를 추가했더니 색인 수가 3배로 늘었어요.

3. FCP (최초 콘텐츠 렌더링 시간)

• Web Vitals에서 FCP가 2초를 넘으면, 크롤러가 나머지 콘텐츠 로딩을 포기할 수 있어요.
• 긴급 조치: 첫 화면의 텍스트 콘텐츠를 15KB 이하로 줄이세요 (긴 트윗 하나 정도 분량).

4. 페이지네이션 태그 유지율

• Ahrefs의 Site Audit 도구를 이용해 rel="next"와 rel="prev" 태그가 제대로 붙어 있는지 확인하세요.
• 실패 사례: 어떤 쇼핑몰은 rel="next" 태그 하나 빠진 것 때문에 상품 페이지 3,000개가 색인되지 않았어요.

5. 모바일 렌더링 성공률

• Google의 Mobile-Friendly Test에서 “스크롤 가능한 콘텐츠”에 빨간 경고가 뜨면, 모바일에서 무한 스크롤이 작동하지 않는다는 뜻이에요.
• 실전 팁: 3G 네트워크 속도로 시뮬레이션 해보고, 페이지가 느릴 때도 4번째 화면까지 제대로 뜨는지 확인하세요.

대형 사이트들의 무한 스크롤 SEO 전략

큰 사이트라고 해서 항상 복잡한 기술만 쓰는 건 아니에요. 가끔은 “이게 된다고?” 싶은 방법이 진짜 먹히는 경우도 많죠.

ASOS, BBC, Twitter 같은 상위 사이트들의 실전 전략을 소개합니다. 페이지네이션으로 되돌리지 않아도, 구글이 잘 색인해줍니다.

1. ASOS의 ‘유령 페이지네이션’ (이커머스 대표 전략)

👉 사용자 눈에는 무한 스크롤처럼 보이지만, 실제로는 페이지를 나눔

• 사용자: 스크롤할수록 상품이 계속 로딩되어 끊김 없는 경험을 제공
• 구글: 상품 20개마다 /products?page=2 같은 숨겨진 링크 생성 + <link rel="next"> 태그로 크롤러에게 알림
• 기술 포인트: Intersection Observer API를 써서 스크롤 위치를 감지, 임계점에 도달하면 페이지 처리 로직 실행
• 성과: 색인된 상품 페이지가 300개에서 8,200개로 증가, 모바일 전환율도 17% 상승

2. BBC 뉴스의 ‘낚시형 네비게이션’ (미디어 업계 대표 사례)

👉 무한 스크롤하다가 갑자기 페이지 버튼 등장

• 사용자: 처음엔 뉴스 30개를 무한 스크롤로 보다가, 하단에 “다음 페이지” 버튼이 뜸
• 구글: 버튼의 href가 /news?p=2를 가리키고, rel="canonical"로 메인 URL을 선언
• 팁: 버튼에 그라데이션과 화살표 애니메이션을 넣어 클릭 유도
• 결과: 2페이지 이후 콘텐츠 색인율이 11% → 68%로 상승, 사용자 평균 기사 조회 수도 2.3개 증가

3. Twitter의 ‘조각 로딩’ (소셜미디어 교과서)

👉 무한 스크롤처럼 보이지만 실제로는 50개씩 나눠 로딩

• 클라이언트 측: 트윗을 스크롤할 때 전혀 끊김이 없고, 페이지 나눔이 있는지도 모를 정도예요
• 구글 측: 트윗 50개마다 /home?section=2 같은 독립 URL 생성, 서버 응답 시 다음 50개 트윗 JSON 미리 로딩
• 핵심 코드: window.history.replaceState로 주소창을 조용히 업데이트해서 유저 경험 안 끊기게 유지
• 데이터가 증명: 트윗이 구글에 인덱싱되는 시간 48시간 → 4시간으로 단축, 핫이슈 트래픽 3배 급증

초보자용 복붙 가이드：

1. 페이지 링크 숨기기: 페이지 하단 <footer>에 /page=2를 넣고 CSS로 투명도 0.01 설정 (구글 봇은 읽고, 유저는 안 보여요)
2. 콘텐츠에 태그 달기: 화면마다 <meta name="page" content="2"> 추가해서 크롤러가 페이지 구조 파악할 수 있게
3. 다음 페이지 미리 로딩: <link rel="prefetch">로 다음 페이지 HTML을 미리 불러오기 → 유저가 스크롤하면 즉시 열림

주의사항 꼭 확인!：

어떤 마이너 커뮤니티가 트위터 방식 그대로 따라 했다가, 서버가 미리 요청 처리 못 하고 그냥 터졌어요.

• 페이지 수는 100페이지 이내로 제한 (구글은 너무 깊은 페이지는 잘 안 봐요)
• Cache-Control로 HTML 페이지 캐싱해서 서버 부하 줄이기
• 각 페이지의 <title>은 꼭 다르게 설정 (전부 “최신 소식”으로 하면 안 돼요)

언제는 무조건 다시 페이지 방식으로 돌아가야 할까?

일부 대표들이 “무한 스크롤”에 집착하다가, 트래픽이 바닥났어요 (어느 교육 사이트는 고집 부리다 방문자 수 2만 → 800명으로 떨어짐)

진짜 데이터를 보면, 이 3가지 유형의 사이트는 당장 페이지 방식으로 바꿔야 해요：

콘텐츠가 ‘참고서’ 유형인 경우

👉 특징: 유저가 목적을 가지고 찾아오는 경우 (법률 조항, 제품 설명서 등)

• 치명적인 문제: 무한 스크롤로 원하는 정보가 8번째 화면에 숨어버려서 Ctrl+F로는 검색이 안 됨
• 데이터가 말해줌: 지식 기반 사이트가 페이지 방식으로 바꾸자 목표 페이지 도달률이 32% → 71%로 상승 (Hotjar 히트맵 결과)
• 대표 사례: 어느 의료 사이트가 약품 설명서를 무한 스크롤에서 페이지 방식으로 변경 후, 롱테일 키워드 유입 300% 증가

2. 천천히 비교하고 구매하는 유저 대상인 경우

👉 특징: 스펙·가격을 꼼꼼히 비교하는 유저 (전자제품, 산업 장비 등)

• 위험한 행동: 무한 스크롤로 휴대폰 100종 노출 → 유저가 전에 봤던 모델 찾기 힘듦
• 실패 사례: 어느 카메라 쇼핑몰이 무한 스크롤 고집하다가 객단가 $1200에서$580으로 하락 — 유저가 비교 귀찮아서 그냥 포기함
• 살아남는 팁: 상품 10개씩 페이지로 나누고, 상단에 ‘비교하기’ 버튼 고정

3. 서버 속도가 삐삐 수준인 경우

👉 특징: 페이지 전체 로딩에 3.5초 이상 걸림 (WebPageTest 실측 기준)

• 잔혹한 현실: 무한 스크롤은 서버에 페이지 방식보다 4배 부담 (20스크린 ≈ 80개 API 요청)
• 파산 사례: 어떤 해외 쇼핑몰이 React 무한 스크롤 쓰다가 AWS 요금이 $2000에서$1.7만으로 폭등해서 결국 페이지 방식으로 전환
• 저예산 해법: 정적 HTML + CDN 캐싱 조합으로 서버비용 82% 절감

바꿔야 할까? 이 3가지 체크하세요

1. 유저가 앞뒤 비교를 자주 해야 하나요? → 그렇다 → 페이지 방식으로
2. 콘텐츠가 검색용(예: 튜토리얼)으로 오래 살아야 하나요? → 그렇다 → 페이지 방식으로
3. 로딩 속도가 3초 넘나요? → 그렇다 → 페이지 방식으로