SEO

다이내믹 렌더링

다이내믹 렌더링(Dynamic Rendering)은 같은 페이지를 두 가지 버전으로 서빙하는 기법입니다: 검색 크롤러에는 사전 렌더링된 정적 HTML 스냅샷, 사람 사용자에게는 전체 JavaScript SPA 경험. 구글은 2018년 무거운 JS 사이트의 우회책으로 공개 권장했으나, 2024년에는 "레거시 우회책"으로 조용히 위상을 낮췄습니다 — Googlebot의 JS 렌더링이 성숙해졌기 때문입니다.

다이내믹 렌더링(Dynamic Rendering)은 같은 페이지를 두 가지 버전으로 서빙하는 기법입니다: 검색 크롤러에는 사전 렌더링된 정적 HTML 스냅샷, 사람 사용자에게는 전체 JavaScript SPA 경험. 구글은 2018년 무거운 JS 사이트의 우회책으로 공개 권장했으나, 2024년에는 "레거시 우회책"으로 조용히 위상을 낮췄습니다 — Googlebot의 JS 렌더링이 성숙해졌기 때문입니다.

왜 중요한가

JS 중심 사이트는 빈 HTML 셸을 내보내고 크롤러가 JS를 실행해 실제 콘텐츠를 보기를 기다렸습니다. Googlebot은 결국 그렇게 했지만 느렸고 — 보통 최초 HTML 가져오기 후 며칠 뒤 — 다른 크롤러(Bing·AI 봇·Facebook 언퍼)는 더 나빴습니다. 다이내믹 렌더링은 앱을 다시 쓰지 않고도 크롤러가 즉시 완전히 렌더링된 HTML을 보도록 보장했습니다. 이커머스 카탈로그·JS 대시보드·SEO가 중요한 SPA에 실용적인 다리였습니다. 지금도 많은 사이트가 다이내믹 렌더링 위에 돌아가며 마이그레이션이 필요하므로, 이 개념을 이해해야 합니다.

작동 원리

1. 요청 도착: 엣지 또는 서버가 user-agent를 검사합니다.

2. 크롤러 감지: user-agent가 알려진 검색 봇(Googlebot·Bingbot·Twitterbot·LinkedInBot·AI 크롤러)과 일치하면, 요청이 사전 렌더링 서비스로 라우팅. 아니면 일반 SPA로.

3. 사전 렌더링 서비스: 헤드리스 Chrome(prerender.io·Rendertron·Puppeteer·Playwright 등)이 페이지를 가져오고, JS 완료를 기다리고, DOM을 캡처해 정적 HTML을 반환.

4. 캐시: 렌더링된 HTML을 캐시해 이후 크롤러 요청 시 재렌더링 방지.

5. 봇은 HTML, 사용자는 SPA: 같은 URL, 두 가지 경험.

왜 지금은 '레거시 우회책'인가

구글의 2024년 가이드는 다이내믹 렌더링을 "권장"에서 "우회책이며 장기 해결책이 아님"으로 옮겼습니다. 이유:

Googlebot의 JS 렌더링이 잘 작동: 최신 헤드리스 Chrome으로 대부분 페이지의 JS를 빠르게 처리합니다. 구글 입장에서 다이내믹 렌더링의 원래 이유는 대부분 사라졌습니다.

유지보수 부담: 두 번째 렌더 파이프라인을 병렬로 운영하는 운영 복잡도가 보통 이득을 초과합니다.

괴리 위험: 사전 렌더링 서비스가 깨지거나 낡으면 봇은 옛 콘텐츠, 사용자는 새 콘텐츠를 봅니다 — 전형적 클로킹 신호.

클로킹 페널티는 아니지만 근접: 구글은 다이내믹 렌더링이 클로킹이 아니라고 명시하지만, 봇·사용자 뷰가 크게 벌어지면 수동 리뷰로 이어질 수 있습니다.

현대 SSR/SSG가 더 나음: Next.js·Nuxt·SvelteKit·Astro·Remix는 서버 렌더링·정적 생성이 기본입니다. 다이내믹 렌더링 불필요.

여전히 유효할 수 있는 경우

다시 쓸 수 없는 레거시 SPA: SSR 마이그레이션 예산이 없는 성숙한 JS 중심 앱. 임시 수단으로 여전히 유효.

비-Googlebot 크롤러: AI 크롤러·Bing·Baidu·니치 봇은 여전히 Google보다 JS 렌더링이 나쁩니다. 그쪽 트래픽이 중요하면 도움이 됩니다.

위젯·임베드: 초기 HTML 이후 JS로 로드되는 콘텐츠 — 때로 크롤러에 노출할 유일한 방법.

엣지 렌더 우회: CDN 엣지에서 SPA를 HTML로 변환하는 가벼운 다이내믹 렌더 — 별도 사전 렌더 서비스 없이.

마이그레이션 방법

1. JS에서 실제로 실패하는 것 감사: Search Console URL 검사와 렌더링 비교. 많은 "JS SEO 문제"가 단지 핵심 페이지의 SSR 누락입니다.

2. 핵심 페이지를 SSR·SSG로: 홈·랜딩·제품·아티클 먼저. 대시보드와 로그인 영역은 SPA 유지.

3. 현대 프레임워크 사용: Next.js·Nuxt·SvelteKit는 하이브리드 렌더링을 기본 제공.

4. 패리티 검증: 마이그레이션 후 Screaming Frog로 새 사이트 크롤링, HTML이 옛 사전 렌더와 일치하는지 확인.

5. 사전 렌더 서비스 종료: 몇 주간 깨끗한 Search Console 커버리지 리포트를 확인한 뒤에만.

흔한 실수

의도적으로 다른 콘텐츠 서빙: 다이내믹 렌더링은 '같은 콘텐츠, 다른 형식'입니다. 다른 콘텐츠는 클로킹이며 페널티 대상.

사전 렌더 캐시 미갱신: 낡은 사전 렌더가 봇에 옛 콘텐츠를 먹여 어제 제품의 순위를 유지.

모든 것을 사전 렌더에 의존: SSR 전략 없이 사전 렌더만 앞단에 두면 한 번의 장애가 크롤러 실명을 의미.

비-Googlebot UA 리스트 무시: Bing·Yandex·Baidu·AI 크롤러의 UA가 다릅니다. 하나를 놓치면 그 봇에 클로킹된 것.

신규 빌드에 사용: 금물. 현대 프레임워크의 SSR/SSG를 쓰세요.

Sources:

관련 인블로그 게시물

inblog에서 활용하기

inblog는 모든 블로그 페이지를 Next.js 기반 SSR로 서빙하므로, 다이내믹 렌더링이 필요하지 않습니다. 크롤러와 사용자 모두 동일한 완전히 렌더링된 HTML을 받아보며, Googlebot은 물론 PerplexityBot·GPTBot·ClaudeBot 같은 AI 크롤러(JS 렌더링이 약한 봇들)까지 콘텐츠를 정확히 수집할 수 있습니다. 별도 사전 렌더링 파이프라인을 운영할 필요가 없습니다.