크롤러가 무한 스크롤을 읽지 못하는 이유
크롤러는 사람처럼 화면을 아래로 내리지 않습니다. 구글은 페이지를 렌더링할 때 스크롤이나 클릭 같은 조작을 하지 않으므로, 스크롤해야 불러오는 항목은 발견되지 않을 수 있습니다. 목록 아래쪽 상품이나 글이 색인되지 않는 원인이 되기도 합니다.
화면에 보일 때 이미지를 불러오는 지연 로딩과 혼동하기 쉬운데, 무한 스크롤은 항목 자체가 나중에 추가된다는 점에서 색인에 주는 영향이 더 큽니다.
검색엔진 친화적인 무한 스크롤 구현법
구글이 권장하는 방식은 무한 스크롤과 페이지네이션을 함께 쓰는 것입니다.
- 목록을 일정 개수씩 나눈 묶음마다 ?page=2 같은 고유 URL을 둡니다.
- 스크롤로 다음 묶음이 로드되면 History API로 주소창의 URL을 해당 묶음의 URL로 바꿉니다.
- 각 묶음의 URL로 직접 접속해도 그 묶음의 항목이 표시되게 합니다.
- "더 보기" 버튼이나 페이지 번호 같은 일반 링크를 함께 두어 크롤러가 다음 묶음으로 이동할 수 있게 합니다.
구현한 뒤에는 서치콘솔 URL 검사 도구로 2페이지 이후의 URL을 직접 검사해, 그 묶음의 항목이 구글이 읽은 HTML에 들어 있는지 확인합니다.
마크업 · 사이트 구조목록을 1, 2, 3… 페이지로 나누는 방식입니다. 페이지마다 고유 URL을 주고 일반 <a> 링크로 연결해야 크롤러가 뒤쪽 페이지의 항목까지 발견할 수 있습니다.
성능 · 사용성화면 밖의 이미지·동영상을 사용자가 스크롤해 가까워질 때 불러오는 기법입니다. 초기 로딩을 빠르게 하지만, 퍼스트뷰의 주요 이미지에 적용하면 LCP가 늦어지므로 화면 아래 요소에만 씁니다. HTML의 loading="lazy" 속성으로 구현할 수 있습니다.
크롤링 · 색인웹 페이지를 자동으로 방문해 수집하는 프로그램(봇·스파이더)입니다. 구글의 Googlebot, 네이버의 Yeti가 대표적이며, 최근에는 GPTBot처럼 AI 학습·검색용 크롤러도 늘었습니다.
웹 기초HTML·CSS·자바스크립트를 해석해 실제 화면을 그려내는 과정입니다. 구글은 크롤링한 페이지의 자바스크립트를 실행해 렌더링한 뒤 그 결과를 색인하므로, 자바스크립트로만 만들어지는 콘텐츠는 반영이 늦거나 누락될 수 있습니다.
웹 기초웹 페이지의 고유 주소(Uniform Resource Locator)입니다. 프로토콜·도메인·경로·파라미터로 구성됩니다. SEO에서는 짧고 의미가 드러나며, 한 페이지에 하나의 URL만 대응하도록 설계하는 것이 기본입니다.
