JavaScript 렌더링과 SEO: Googlebot의 렌더링 파이프라인을 이해해야 하는 이유

JavaScript에 의존하는 웹 애플리케이션의 SEO 문제는 "Googlebot이 JavaScript를 실행할 수 있는가"라는 질문이 아니다. 실행할 수 있다. 문제는 "언제, 얼마나 빠르게 렌더링되는가"에 있다. Google의 Martin Splitt는 2019년 Google I/O에서 Googlebot의 크롤링-렌더링 파이프라인을 '두 단계 프로세스(Two-Phase Indexing)'로 설명했다. 첫 번째 단계에서 HTML을 파싱하고, 두 번째 단계에서 JavaScript를 실행하여 동적으로 생성된 콘텐츠를 인덱싱한다. 이 두 번째 단계에는 수 시간에서 수일의 지연이 발생할 수 있다.

이 지연이 SEO에 미치는 영향은 명확하다. 새로운 콘텐츠를 발행했지만 해당 콘텐츠가 JavaScript 렌더링에 의존하는 경우, Google의 인덱스에 반영되기까지 최대 2주가 소요될 수 있다. 속보성 콘텐츠나 시즈널(Seasonal) 키워드를 타겟으로 하는 페이지에서 이 지연은 치명적이다. 반면 서버 사이드 렌더링(SSR) 또는 정적 사이트 생성(SSG)으로 제공된 페이지는 첫 번째 단계에서 즉시 인덱싱된다.

SPA(Single Page Application) 프레임워크별 대응 전략을 정리하면 다음과 같다. Next.js는 getServerSideProps 또는 App Router의 서버 컴포넌트(Server Components)를 활용하여 SSR을 기본으로 제공한다. Nuxt.js는 useFetch와 서버 사이드 모드를 통해 동일한 결과를 달성한다. 순수 React SPA의 경우, 검색엔진 대응을 위해 Prerendering 서비스(Prerender.io, Rendertron)를 도입하거나, 프레임워크 마이그레이션을 검토해야 한다.

# robots.txt에서 JS 리소스 차단 확인 (절대 차단하면 안 됨)
User-agent: Googlebot
Allow: /*.js$
Allow: /*.css$

실무에서 가장 치명적인 실수는 robots.txt에서 JavaScript 파일의 크롤링을 차단하는 것이다. Googlebot이 JS 파일에 접근하지 못하면 렌더링 자체가 불가능해지며, 해당 페이지는 빈 HTML로 인덱싱된다. Google Search Console의 "URL 검사" 도구에서 "렌더링된 HTML 보기"를 확인하면 Googlebot이 실제로 어떤 콘텐츠를 인식하고 있는지 검증할 수 있다.

대응 체크리스트를 정리한다. 첫째, 핵심 콘텐츠(제목, 본문, 메타데이터)는 반드시 초기 HTML 응답에 포함시킨다. 둘째, 클라이언트 사이드에서만 렌더링되는 콘텐츠가 있다면 Search Console의 URL 검사로 렌더링 결과를 확인한다. 셋째, robots.txt에서 JS/CSS 파일의 크롤링이 차단되어 있지 않은지 정기적으로 점검한다. 넷째, 대규모 SPA 사이트는 Dynamic Rendering이 아닌 SSR 또는 SSG로의 전환을 우선적으로 검토한다. Dynamic Rendering은 Google이 "장기적 솔루션이 아님"이라고 공식 입장을 밝힌 임시 방편이다.