🚀 CSR(Client-Side Rendering)과 SEO 문제
🔍 1. 배경 설명
-
✨ CSR 은 서버에서 최소 HTML과 JS 번들만 내려주고, 브라우저가 실행해(즉, 클라이언트 사이드에서) 콘텐츠를 렌더링하는 방식.
-
🤖 초기 로딩 후 UX는 우수하지만, 검색 엔진 크롤러는 최소한의 HTML만 파싱하기 때문에 콘텐츠 인식에 어려움이 있다.
-
(크롤러는 엄청난 분량의 페이지를 하나하나 검증할 시간이 모자라서 초기 로딩 분량만 보고 가버린다. 그런데 CSR은 페이지를 렌더링 할 시간이 추가로 필요한데, 크롤러는 이를 주지않고 그냥 사라져버린다..)
-
🌐 이 문제에서 자유로는 것이 SSR/ SSG 기법. 서버나 빌드 시점에 HTML을 생성한다. 크롤러가 페이지를 방문하는 시점에서 렌더링이 이미 완료되어있으니 즉시 텍스트와 메타데이터를 수집할 수 있다.
⚠️ 2. CSR 페이지의 주요 SEO 문제점
- 그런데 애초에 크롤러는 왜 CSR의 렌더링을 기다려주지 않는 것인가?
- ⏰ 렌더링 지연으로 인덱싱 대기
- Googlebot은 CSR 페이지를 렌더링 큐에 넣은 뒤 렌더링 자원이 확보될 때 실행하므로 인덱싱이 지연될 수 있습니다.
- 💸 크롤 예산(crawl budget) 소진 우려
- JavaScript 렌더링은 리소스를 많이 소모해, 대규모 SPA에서 크롤 예산을 빠르게 소진할 수 있습니다.
- 🔄 검색 엔진별 지원 수준 차이
- Google은 Headless Chromium으로 CSR을 처리하지만, Bing 등은 성능·신뢰성이 낮아 동적 렌더링을 권장하기도 합니다.
-
3번과 관련해서.. 요새는 잘 보기 힘든데, 예전 홈페이지들은 특정 브라우저에서만 동작한다던지 / 특정 브라우저에 최적화되어있다는 문구가 있곤 했다.
-
주로 해당 페이지 개발에 사용된 특정 기술이 특정 브라우저에서만 호환되거나, 특정 브라우저에서는 동작하지 않기 때문인데..
-
2025년 시점에서 이런 식으로 홈페이지를 개발할 수는 없다. 어떤 브라우저에서도 동일한 사용자 경험을 줄 수 있어야한다.
🛠️ 3. CSR SEO 해결 방안 및 구현 전략
3.1 ⚙️ SSR / SSG 도입
- SSR: 요청 시점에 서버에서 HTML 생성 → 동적 콘텐츠에 적합
- SSG: 빌드 시점에 HTML 생성 → 빠른 로딩, 안정적 인덱싱
예시: Next.js의
getServerSideProps,getStaticProps
-
가장 간단한 방법. Next.js는 사실상 React.js나 다름 없으니.. 그냥 Next를 도입하는게 제일 좋다.
-
검색엔진 크롤러가 개량되면서 CSR 기반이라도 해서 아예 검색에서 깡통이 되는건 아니지만..
-
CSR 기법의 근본적인 한계로 인해서 SSR과 동일한 수준으로 검색 엔진에서 이점을 얻기는 힘들다.
3.2 🏗️ 프리렌더링(Pre-Rendering)
- 주요 경로를 사전에 렌더링해 정적 HTML로 저장
- 장점: 사용성↑, SEO 점수↑
- 단계:
- 빌드 스크립트에 경로 목록 등록
- CI/CD 파이프라인에서 HTML 생성
3.3 🔄 동적 렌더링(Dynamic Rendering)
-
크롤러에게만 SSR 버전, 일반 사용자에겐 CSR 버전 제공
-
구현: Nginx/Express에서
User-Agent확인 → Rendertron 등 활용 -
단점: 인프라 복잡도↑, 유지보수 부담↑
-
이건.. 정말정말 특이한 상황에서 도입할 수 있는 방법. 일반적으로는 복잡도가 너무 높아지고 유지보수성이 너무 떨어진다.
3.4 📝 메타 태그·구조화 데이터 최적화
- React Helmet 또는 Next.js
<Head>로<title>,<meta>, Open Graph, JSON-LD 설정
import Head from 'next/head';
export default function MyPage({ post }) {
return (
<>
<Head>
<title>{post.title}</title>
<meta name="description" content={post.excerpt} />
<script type="application/ld+json">
{JSON.stringify({
"@context": "https://schema.org",
"@type": "Article",
"headline": post.title,
"datePublished": post.date,
"author": { "@type": "Person", "name": post.author }
})}
</script>
</Head>
{/* 페이지 콘텐츠 */}
</>
);
}-
요건 사실 SEO 문제가 아니더라도 HTML 개발시에 습관처럼 사용하면 좋다.
-
HTML에는 얼핏 같은 효과를 지니는 것 처럼 보이는 태그들이 많다.
-
잘 모르고 태그들을 다루다보면 그냥 div만 있어도 개발이 다 되는 것 처럼 보이는데.. (세부적인 스타일은 어차피 CSS에서 다루면 되니까)
-
각각에 부여된 역할에 맞는 태그를 사용해야 크롤러 등지에서 더 빠르게 페이지를 분석해서 페이지 최적화에 도움이 된다. 겉으로는 불필요해보여도 보이지 않는 곳에서 생각보다 많은 차이점이 발생하니 유의해야한다.
⚖️ 4. 각 방안의 한계점
| 방안 | 장점 | 한계점 |
|---|---|---|
| SSR / SSG | 즉시 인덱싱, 빠른 FCP/LCP | 서버 부하↑, 빌드 시간↑ |
| 프리렌더링 | 간단 구현, 안정적 SEO | 경로 많아지면 빌드↑ |
| 동적 렌더링 | 빠른 도입, 크롤러 호환성 보장 | 인프라·비용↑, 비권장 장기책 |
| 메타 태그 관리 | CSR에서도 메타데이터 제공 가능 | 일관 적용 필요 |
