Server-Side Rendering(SSR)이란? | SEO 용어집

서버 사이드 렌더링(Server-Side Rendering, SSR)은 페이지가 요청될 때 서버에서 HTML을 완성한 뒤 그 결과를 브라우저로 전송하는 방식입니다. 클라이언트가 받는 첫 응답에 이미 콘텐츠가 들어 있어, 자바스크립트가 실행되기 전에도 텍스트·링크·메타 태그가 완전히 채워진 상태입니다.

왜 중요한가

검색엔진과 LLM 크롤러는 자바스크립트 실행에 비용을 씁니다. Googlebot은 두 단계로 작동(첫 패스 HTML 파싱 → 두 번째 패스 JS 렌더)하는데, 클라이언트 렌더링(CSR)으로 빈 HTML만 보내면 콘텐츠 인덱싱이 수일~수주 지연되거나 누락될 수 있습니다. AI 크롤러(GPTBot·PerplexityBot·ClaudeBot)는 대부분 JS를 실행하지 않으므로, CSR은 앤서 엔진에서 사실상 보이지 않습니다. SSR은 이 문제를 한 번에 해결하면서 LCP·FCP 같은 Core Web Vitals 지표도 동시에 끌어올립니다 — SEO와 GEO에서 가장 비용 대비 효과 큰 기술 결정 중 하나입니다.

CSR vs SSR vs SSG vs ISR

방식	렌더 위치	첫 HTML	SEO 적합도	용도
CSR (Client-Side Rendering)	브라우저	빈 셸	약함	인증 후 대시보드
SSR (Server-Side Rendering)	서버, 요청마다	완성	강함	동적 콘텐츠, 개인화
SSG (Static Site Generation)	빌드 타임	완성	가장 강함	블로그·문서·마케팅
ISR (Incremental Static Regeneration)	빌드 + 주기적 재생성	완성	가장 강함	자주 갱신되는 정적 페이지

SEO 우선순위는 SSG ≈ ISR > SSR > CSR 순. Next.js·Nuxt·Remix·SvelteKit 같은 프레임워크가 한 코드베이스에서 이 모드들을 혼합해 쓸 수 있게 해줍니다.

SEO·GEO에 미치는 영향

즉각적 인덱싱: Googlebot 첫 패스에서 콘텐츠가 보이므로 두 번째 렌더 패스를 기다릴 필요 없음. 새 페이지 인덱스 시간이 수일에서 수시간으로 단축.

AI 크롤러 호환: GPTBot 등은 JS를 실행하지 않음. SSR이 아니면 LLM 학습·검색에 콘텐츠가 사실상 부재.

Core Web Vitals 개선: LCP가 자바스크립트 번들 다운로드·실행 후가 아니라 첫 HTML 도착 시점에 발생. FCP·LCP·TTI 모두 개선.

메타 태그 신뢰성: 소셜 공유(Open Graph)·검색 스니펫·구조화 데이터가 첫 응답에 포함돼야 신뢰 가능. CSR은 트위터·페이스북 봇이 빈 메타 태그를 가져감.

점진적 향상: 자바스크립트 비활성화·느린 네트워크·구형 디바이스에서도 콘텐츠 접근 가능.

SSR의 트레이드오프

서버 비용 증가: 매 요청마다 HTML 생성 → CPU·메모리·인프라 비용 증가. CDN 캐싱과 ISR로 완화.

TTFB 증가 가능: 서버 로직이 무거우면 첫 바이트 도달 시간이 늘어남. 데이터베이스 쿼리·외부 API가 병목.

복잡도: hydration 불일치, 서버/클라이언트 환경 차이, 캐시 무효화 등 디버깅 비용.

개인화의 한계: 사용자별 페이지를 SSR로 매번 렌더하면 캐싱이 어려움. 공통 셸 + 클라이언트 개인화 패턴 권장.

Hydration과 그 함정

SSR로 보낸 HTML 위에 클라이언트가 자바스크립트를 "재구동(hydrate)"해 인터랙티브하게 만듭니다. 이 과정에서:

Hydration mismatch: 서버에서 생성한 HTML과 클라이언트가 첫 렌더하는 HTML이 다르면 React/Vue 경고 발생. 종종 시각적 깜빡임·기능 오작동.

Hydration 비용: 큰 페이지의 hydration이 메인 스레드를 막아 INP(상호작용 응답성) 악화. Partial hydration·React Server Components·Astro의 islands가 대안.

SSR ≠ 작은 번들: SSR을 써도 클라이언트 번들이 작아지진 않음. 둘 다 최적화 필요.

SSR을 선택해야 하는 경우

콘텐츠가 SEO·GEO 트래픽에 의존(블로그·뉴스·이커머스·문서)
사용자별 데이터가 첫 화면에 필요(개인화 대시보드)
소셜 공유에서 동적 OG 태그가 중요
AI 검색 인용을 노림

SSR이 과한 경우

인증 뒤 사용자 전용 대시보드(SEO 무관)
정적 콘텐츠 → SSG가 더 빠르고 저렴
매우 작은 사이트 → 정적 HTML 한 페이지로 충분

흔한 실수

모든 페이지를 SSR로: 정적 콘텐츠는 SSG/ISR이 더 빠르고 저렴. 페이지별 적절 모드 선택.

API 응답을 SSR에서 직접 호출: 데이터 페치를 캐싱 없이 매 요청마다 하면 TTFB 폭발. SWR·캐시 헤더 사용.

Hydration mismatch 무시: 콘솔 경고를 방치하면 SEO 위험(구글이 본 HTML과 사용자 HTML이 다름).

메타 태그를 클라이언트 사이드에서만 설정: SSR 단계에서 head에 포함돼야 봇이 읽음.

프레임워크 기본값 검증 안 함: Next.js·Nuxt가 자동으로 적절 모드를 고르지 않을 수 있음. 라우트별 명시적 설정 필요.

Sources:

inblog에서 활용하기

inblog는 모든 블로그 페이지를 SSR/ISR로 제공해 첫 응답에 본문·메타 태그·구조화 데이터가 완전히 포함되도록 합니다. Googlebot의 두 번째 렌더 패스를 기다리지 않고, AI 크롤러도 본문을 그대로 가져갈 수 있어 검색과 앤서 엔진 양쪽에서 인덱싱·인용이 빠르게 일어나는 구조입니다.

서버 사이드 렌더링