Googlebot 내부 동작 공식 공개 — 2MB 제한, WRS 무상태 렌더링, 바이트 처리의 모든 것

• Google이 Googlebot의 크롤링과 바이트 처리 메커니즘을 공식적으로 상세 공개함 — 지금까지 모호했던 부분들이 명확해짐

Googlebot은 단일 프로그램이 아님

• 2000년대 초에는 크롤러가 하나였지만, 지금은 Googlebot이 "중앙 크롤링 플랫폼"의 한 클라이언트에 불과
  • Google Shopping, AdSense 등 수십 개 클라이언트가 같은 인프라를 공유하되 다른 크롤러 이름을 사용
  • 서버 로그에 보이는 Googlebot은 Google Search만 해당

2MB 제한의 실체

• Googlebot은 개별 URL당 최대 2MB만 가져감 (PDF는 64MB)
  • HTTP 헤더도 포함한 2MB임
  • 2MB를 넘으면 거부하는 게 아니라 정확히 2MB에서 끊음 — 나머지는 아예 fetch하지 않고, 렌더링하지 않고, 인덱싱하지 않음
  • 이미지/비디오 크롤러는 제품별로 다른 임계값 사용, 별도 지정 없으면 기본 15MB

• 대부분의 웹에서 HTML 2MB는 거대한 크기이므로 보통은 문제없음
  • 하지만 인라인 base64 이미지, 거대한 인라인 CSS/JS, 메가바이트급 메뉴가 앞에 있으면 실제 텍스트 콘텐츠가 2MB 뒤로 밀릴 수 있음
  • 밀린 바이트는 Googlebot에겐 "존재하지 않는 것"

Web Rendering Service (WRS)

• 크롤러가 가져온 바이트를 WRS가 처리 — 모던 브라우저처럼 JS 실행, CSS 처리, XHR 요청
  • 이미지/비디오는 요청하지 않음
  • WRS는 무상태(stateless) — 요청 간 로컬 스토리지, 세션 데이터 초기화
  • JS 의존적인 동적 요소에 영향을 줄 수 있음

실무 권장사항

• 무거운 CSS/JS를 외부 파일로 분리 — 외부 리소스는 별도 fetch
• <meta>, <title>, <link>, canonical, 구조화 데이터 같은 핵심 요소를 HTML 상단에 배치
• 서버 응답 시간 모니터링 — 느리면 Googlebot이 자동으로 크롤 빈도를 줄임
• 이 2MB 제한은 고정이 아니며 웹 진화에 따라 변경될 수 있음

---

기술 맥락

• 2MB 제한이 HTTP 헤더를 포함한다는 건 실무적으로 꽤 중요한 포인트예요. 큰 쿠키나 커스텀 헤더가 많은 사이트에서는 실제 HTML에 쓸 수 있는 바이트가 줄어드니까요
• WRS가 stateless라는 건 SPA(Single Page Application)에 직접적인 영향이 있어요. 로컬 스토리지에 인증 토큰을 저장하고 그걸 기반으로 콘텐츠를 로드하는 패턴이라면, WRS에서는 빈 페이지로 보일 수 있거든요
• 참조 리소스가 별도 카운터를 갖는다는 건, JS 번들이 크더라도 HTML 자체의 2MB에는 영향을 주지 않는다는 뜻이에요. 다만 JS 번들 자체도 2MB 제한이 적용되니 코드 스플리팅이 SEO 관점에서도 의미가 있음