자바스크립트 SEO
자바스크립트 SEO는 자바스크립트로 렌더링되는 웹 콘텐츠를 검색엔진이 크롤링·렌더링·색인할 수 있도록 최적화하는 작업입니다. 구글은 HTML을 먼저 크롤링한 뒤 헤드리스 크로미움으로 자바스크립트를 실행해 렌더링한 결과를 색인하므로, 렌더링 단계에서 콘텐츠가 노출되도록 설계하는 것이 핵심입니다.
- 자바스크립트 SEO는 JS로 만들어지는 콘텐츠를 검색엔진이 크롤·렌더·색인할 수 있게 최적화하는 영역입니다.
- 구글봇은 크롤링 → 렌더링 → 색인의 단계를 거치며, 렌더링 단계에서 헤드리스 크로미움으로 자바스크립트를 실행합니다.
- 렌더링은 큐를 거치므로 지연될 수 있고, 측정상 중앙값 약 10초·90백분위수 약 3시간 수준입니다.
- 구글은 신규 사이트에 동적 렌더링을 더 이상 권장하지 않으며 SSR·정적 렌더링·하이드레이션을 권장합니다.
- 핵심 콘텐츠와 noindex·canonical 같은 신호는 클라이언트 측 자바스크립트에만 의존하지 않도록 설계하는 편이 안전합니다.
자바스크립트 SEO 개요
자바스크립트 SEO는 자바스크립트로 렌더링되는 콘텐츠를 검색엔진이 정확히 크롤링하고 렌더링하며 색인할 수 있도록 최적화하는 작업을 가리킵니다. 서버가 완성된 HTML을 내려주는 전통적 페이지와 달리, 앱 셸(app shell) 방식의 자바스크립트 사이트는 초기 HTML에 실제 콘텐츠가 비어 있고 브라우저에서 자바스크립트가 실행된 뒤에야 콘텐츠가 채워지는 경우가 많습니다. 따라서 검색엔진이 자바스크립트 실행 결과까지 도달하도록 보장하는 것이 자바스크립트 SEO의 출발점입니다.
구글은 자바스크립트를 크롤링·렌더링·색인의 두 단계 처리 흐름으로 다룹니다. 먼저 구글봇이 URL을 가져와 robots.txt 권한을 확인하고 HTML 안의 링크를 파싱해 크롤 큐에 추가합니다. 이후 200 상태 코드를 반환한 페이지는 렌더링 큐로 보내지고, 자원이 확보되면 헤드리스 크로미움이 페이지를 열어 자바스크립트를 실행한 뒤 렌더링된 HTML을 생성합니다. 구글은 이 렌더링된 HTML에서 추가 링크를 다시 파싱하고 동일한 결과를 색인에 사용합니다. 즉 크롤 시점의 원본 HTML이 아니라 렌더링 이후의 결과가 색인 대상이 되는 구조입니다.
렌더링은 즉시 일어나지 않고 큐를 통과하므로 지연이 발생할 수 있습니다. 구글 문서는 페이지가 큐에 몇 초 머물 수도 있으나 그보다 길어질 수 있다고 설명합니다. 버셀(Vercel)과 MERJ의 10만여 건 구글봇 분석에서는 모든 200 상태 HTML 페이지가 풀 렌더링되었고, 렌더링 지연 중앙값은 약 10초, 90백분위수는 약 3시간으로 측정되었습니다. 또한 클라이언트 측에서 noindex 태그를 제거하는 방식은 SEO 목적상 동작하지 않는다는 점도 확인되었습니다.
렌더링 방식 비교
자바스크립트 사이트의 렌더링 방식은 콘텐츠가 어디서·언제 HTML로 완성되는지에 따라 나뉘며, 각 방식의 색인 안정성과 운영 부담이 다릅니다.
| 방식 | 렌더링 위치·시점 | 검색 색인 관점 | 유의점 |
|---|---|---|---|
| CSR (클라이언트 측 렌더링) | 사용자·봇의 브라우저에서 자바스크립트 실행 시점 | 구글봇 렌더링 단계에 의존하므로 큐 지연·실행 실패에 취약합니다 | 초기 HTML이 비어 있어 콘텐츠 노출이 렌더링 성공 여부에 좌우됩니다 |
| SSR (서버 측 렌더링) | 요청 시 서버에서 HTML 생성 | 완성된 HTML을 바로 받으므로 크롤·색인 안정성이 높습니다 | 서버 부하·응답 속도 관리가 필요하며 하이드레이션 설계가 동반됩니다 |
| SSG (정적 렌더링) | 빌드 시점에 HTML 사전 생성 | 가장 단순하고 안정적으로 색인되며 속도 이점이 큽니다 | 콘텐츠 변경 시 재빌드가 필요해 실시간성이 약합니다 |
| 동적 렌더링 | 크롤러에게만 서버 렌더링 버전을 별도 제공 | 임시 우회책이며 구글이 신규 사이트에 권장하지 않습니다 | 유저 에이전트 감지·봇 목록을 수동 유지해야 하고 복잡도가 증가합니다 |
동적 렌더링에 대한 구글 입장
구글은 동적 렌더링을 장기적 해법이 아닌 우회책으로 규정하며, 추가 복잡성과 자원 부담을 이유로 권장 목록에서 제외했습니다. 대신 서버 측 렌더링, 정적 렌더링, 하이드레이션을 권장합니다. 다만 사용자와 크롤러에게 동등한 콘텐츠를 제공한다면 동적 렌더링 자체가 클로킹으로 간주되지는 않으며, 이미 적용 중인 사이트가 곧바로 문제를 겪는 것도 아닙니다. 신규 구축 시 채택하지 말 것을 권하는 성격에 가깝습니다.
근거
위 처리 흐름과 권장 사항은 구글 검색 센터의 공식 문서를 근거로 합니다. 자바스크립트 SEO 기본 사항 문서는 크롤·렌더·색인 단계와 헤드리스 크로미움 렌더링, 200 상태 페이지의 렌더링 큐 처리를 명시합니다. 동적 렌더링 문서는 해당 방식이 우회책이며 권장 해법이 아니라는 점과 SSR·정적 렌더링·하이드레이션 대안을 제시합니다. 렌더링 실제 동작과 지연 수치는 버셀·MERJ의 대규모 구글봇 로그 분석 자료를 참고했습니다.
실행 체크리스트
- 핵심 콘텐츠가 렌더링된 HTML에 포함되는지 URL 검사 도구의 렌더링 결과로 확인합니다.
- 제목·메타 설명·canonical·구조화 데이터(JSON-LD)가 렌더링 후 정상 출력되는지 점검합니다.
- noindex·canonical 같은 색인 신호를 클라이언트 측 자바스크립트에만 의존시키지 않습니다.
- 단일 페이지 앱(SPA)에서 라우팅은 프래그먼트 대신 History API를 사용하고, 존재하지 않는 경로는 소프트 404 대신 적절한 상태 코드나 noindex로 처리합니다.
- 오류 페이지가 200을 반환해 색인되지 않도록 의미 있는 HTTP 상태 코드를 반환합니다.
- 자바스크립트 번들과 API 응답을 차단하지 않도록 robots.txt에서 렌더링 필요 리소스를 허용합니다.
- 신규 구축은 SSR 또는 정적 렌더링을 기본으로 삼고, 동적 렌더링은 마이그레이션 한시 우회책으로만 검토합니다.
- 콘텐츠 핑거프린팅 기반의 장기 캐싱과 페이지 속도 최적화를 병행합니다.