📘개념⭐️ Pillar

JavaScript SEO

최종 업데이트: 2026년 5월 13일

정의

JavaScript SEO는 JavaScript(JS)로 구현된 웹 페이지가 검색엔진 크롤러와 AI 봇에 올바르게 발견·색인·평가될 수 있도록 최적화하는 기술 SEO의 한 영역이다.

2010년대 React, Vue, Angular 같은 JavaScript 프레임워크가 보편화되면서 클라이언트 사이드 렌더링(CSR)이 증가했고, 이로 인해 봇이 콘텐츠를 인식하지 못하는 문제가 심화됐다.

요약

JavaScript SEO 핵심: HTML 소스(Ctrl+U)에 콘텐츠가 있으면 봇에게 보인다. 없으면 CSR이고, 구글은 지연 후 보지만 AI 봇은 거의 보지 못한다. 해결책은 SSR 또는 SSG. Next.js 기반 사이트는 기본적으로 SSR/SSG를 제공해 JavaScript SEO 문제에서 자유롭다.

JavaScript SEO가 문제가 되는 이유

1. 봇의 JavaScript 처리 방식 차이

모든 봇이 JavaScript를 동일하게 처리하지 않는다:

봇	JS 실행	비고
Googlebot	O (지연 가능)	2단계 렌더링 큐
Bing Bot	부분적	제한적 JS 실행
GPTBot	X (대부분)	HTML만 처리
ClaudeBot	X (대부분)	HTML만 처리
PerplexityBot	X (대부분)	HTML만 처리
네이버 Yeti	부분적	제한적 JS 실행

2. Googlebot의 2단계 렌더링

Googlebot은 페이지 크롤 → JS 실행 렌더링의 2단계로 처리한다. 1단계(크롤)는 즉시 이루어지지만, 2단계(JS 렌더링)는 큐에 대기하다 나중에 처리된다. 대형 사이트에서는 수일이 걸릴 수 있다.

즉, CSR 페이지의 JS 콘텐츠는 색인되지만 즉각적이지 않고 지연된다.

3. AI 봇의 JS 미실행 문제

GPTBot, ClaudeBot, PerplexityBot 등 AI 봇은 대부분 JavaScript를 실행하지 않는다. 순수 CSR 사이트는 이들 봇에게 빈 페이지처럼 인식된다. AEO(Answer Engine Optimization) 시대에 AI 인용을 목표로 한다면 JavaScript SEO는 필수 고려사항이다.

자세히는 robots.txt에 AI 봇 허용 항목 참조.

렌더링 방식 4가지와 SEO 영향

[COMPARISON_TABLE: CSR vs SSR vs SSG vs ISR SEO 비교]

1. CSR (Client-Side Rendering)

서버는 빈 HTML + JS 번들을 전송하고, 브라우저에서 JS 실행 후 콘텐츠가 렌더링된다.

<!-- CSR의 HTML 소스 - 봇에게 보이는 것 -->
<html>
  <head>
    <title></title>
  </head>
  <body>
    <div id="app"></div>
    <script src="bundle.js"></script>
  </body>
</html>

HTML 소스에 콘텐츠가 없다 = Googlebot은 지연 후 봄 / AI 봇은 못 봄.

2. SSR (Server-Side Rendering)

서버에서 HTML을 완성해 전송. 브라우저에서 추가 JS 실행(Hydration).

<!-- SSR의 HTML 소스 - 봇에게 즉시 보이는 것 -->
<html>
  <head>
    <title>키워드 리서치 가이드</title>
  </head>
  <body>
    <h1>키워드 리서치 완전 가이드</h1>
    <p>키워드 리서치는...</p>
  </body>
</html>

HTML 소스에 콘텐츠가 있다 = 모든 봇이 즉시 볼 수 있음.

3. SSG (Static Site Generation)

빌드 시 모든 페이지를 HTML로 생성하고 CDN에 배포. 요청마다 DB 조회 없이 HTML 파일을 직접 서빙.

SEO 관점에서 가장 좋은 방식:

즉각적인 TTFB
모든 봇이 즉시 접근 가능
CDN으로 글로벌 배포 용이

4. ISR (Incremental Static Regeneration)

SSG의 장점 + 정기적 콘텐츠 업데이트. 백그라운드에서 페이지를 재생성하고 CDN 캐시를 갱신.

Next.js ISR:

export const revalidate = 3600 // 1시간마다 재생성

자세히는 렌더링 항목 참조.

JavaScript SEO 진단 5가지 방법

1. HTML 소스 직접 확인

Ctrl+U (Windows) / Cmd+Option+U (Mac)으로 HTML 소스를 확인. 중요한 콘텐츠(H1, 본문, 메타 태그)가 소스에 없으면 CSR 문제다.

2. JavaScript 비활성화 테스트

Chrome DevTools → 설정(F1) → Preferences → Debugger → Disable JavaScript 체크 → 페이지 새로고침. JavaScript 없이 콘텐츠가 보이면 SEO 친화, 빈 화면이면 CSR 의존이 높다.

3. Google Search Console URL 검사

GSC → URL 검사 → "라이브 URL 테스트" → "렌더링된 페이지" 확인. Googlebot이 실제로 본 렌더링 결과를 보여준다. 자세히는 구글 서치 콘솔 항목 참조.

4. Lighthouse

Chrome DevTools → Lighthouse → SEO 감사에서 JavaScript SEO 관련 항목 확인. 특히 "링크가 크롤 가능한가", "meta description이 있는가" 등을 확인한다.

5. Screaming Frog (JavaScript 렌더링 모드)

Screaming Frog SEO Spider의 JavaScript 렌더링 모드를 활성화하면 실제 렌더링 결과를 기반으로 크롤한다. 렌더링 전후를 비교해 JS에 의존하는 콘텐츠를 식별한다.

JavaScript SEO 5가지 핵심 원칙

원칙 1: 핵심 콘텐츠는 HTML에

봇이 즉시 볼 수 있는 HTML에 핵심 콘텐츠(H1, 본문, 메타 태그)를 포함해야 한다. JS로 동적으로 추가되는 콘텐츠는 색인 지연이나 누락 위험이 있다.

원칙 2: 메타 데이터는 반드시 HTML

타이틀 태그, 메타 디스크립션, 카노니컬, 구조화 데이터(JSON-LD)는 초기 HTML에 포함되어야 한다. JS로 동적으로 생성하면 Googlebot 렌더링 전까지 메타 정보가 없는 상태가 된다.

자세히는 타이틀 태그, 카노니컬 태그 항목 참조.

원칙 3: 내부 링크는 <a href> 태그

// 나쁨: JS 이벤트로 내비게이션
document.getElementById('link').addEventListener('click', () => {
  window.location.href = '/target-page'
})

// 좋음: HTML a 태그
;<a href="/target-page">링크 텍스트</a>

Googlebot은 JS 이벤트 핸들러보다 <a href> 태그를 더 확실하게 크롤한다. 자세히는 내부 링크 항목 참조.

원칙 4: SSR 또는 SSG 사용

SPA(Single Page Application)를 운영 중이라면 SSR 또는 SSG로 마이그레이션하는 것이 JavaScript SEO의 근본 해결책이다.

원칙 5: Progressive Enhancement

JavaScript 없이 기본 기능이 작동하도록 설계하고, JavaScript를 점진적 향상으로 사용한다. 이 원칙을 따르면 자동으로 JavaScript SEO 문제가 최소화된다.

Next.js와 JavaScript SEO

Next.js는 React 기반 프레임워크로 SSR, SSG, ISR을 모두 지원한다.

// SSG: 빌드 시 HTML 생성
export async function getStaticProps() {
  const data = await fetchData()
  return { props: { data } }
}

// ISR: 1시간마다 재생성
export const revalidate = 3600

// SSR: 매 요청마다 서버에서 렌더링
export async function getServerSideProps() {
  const data = await fetchData()
  return { props: { data } }
}

Next.js를 사용하는 사이트는 기본적으로 JavaScript SEO 문제에서 상당 부분 자유롭다. alleo.wiki도 Next.js 기반으로 운영되어 SSG를 통한 최적의 크롤 환경을 제공한다.

AEO 시대의 JavaScript SEO

AI 봇의 JS 미실행 현황

2026년 기준 대부분의 AI 봇은 JavaScript를 실행하지 않는다. 순수 CSR 사이트는 AI 인덱스에서 콘텐츠가 누락될 수 있다.

실질적 영향: AI 봇이 크롤하지 못하면

ChatGPT가 해당 콘텐츠를 답변에 인용하지 않음
Perplexity가 출처로 참조하지 않음
Google AI Overview에서 제외 가능

SSR/SSG는 AI 시대에 더욱 중요해졌다. 자세히는 llms.txt 작성 가이드 항목 참조.

Edge SSR의 부상

Cloudflare Workers, Vercel Edge Functions 같은 엣지 컴퓨팅이 SSR을 CDN 수준으로 빠르게 만들고 있다. SSR의 서버 부하 단점이 줄어드는 추세다.

한국 시장 적용

한국 SaaS의 CSR 문제

많은 한국 SaaS 서비스가 순수 React/Vue CSR로 구현되어 있다. 마케팅 랜딩 페이지가 CSR이면 SEO 효과가 거의 없다. 랜딩 페이지는 최소한 SSR 또는 SSG로 구현해야 한다.

워드프레스 = PHP SSR

카페24, 워드프레스, 아임웹 기반 사이트는 기본적으로 PHP 서버 사이드 렌더링이므로 JavaScript SEO 문제가 없다. 자체 개발 SPA 사이트에서 문제가 집중된다.

네이버 Yeti와 JavaScript

네이버 Yeti 봇은 JavaScript를 부분적으로 실행한다. 완전한 CSR은 네이버 색인에서도 불리하다. SSR/SSG는 구글과 네이버 모두에게 유리하다.

자주 묻는 질문

Q. SPA 사이트는 SEO가 절대 불가능한가요?
A. 아니다. Googlebot이 JavaScript를 실행하므로 CSR 콘텐츠도 색인된다. 그러나 색인 지연, AI 봇 미인식, 메타 데이터 문제 등 불리함이 있다. SSR/SSG 마이그레이션이 가장 근본적인 해결책이지만, CSR 상태에서도 HTML 소스에 중요 메타 데이터를 포함하고 내부 링크를 올바르게 구성하는 것으로 부분 개선이 가능하다.

Q. Googlebot이 JS를 실행하는데 왜 SSR이 여전히 필요한가요?
A. 두 가지 이유다. 첫째, Googlebot의 JS 실행은 지연이 있어 즉각적인 색인이 어렵다. 둘째, AI 봇들은 JS를 실행하지 않아 CSR 콘텐츠를 볼 수 없다. AEO를 고려한다면 SSR/SSG가 필수다.

Q. Next.js로 만들면 자동으로 SEO 친화인가요?
A. 기본 설정에서는 그렇다. 그러나 getServerSideProps나 generateStaticParams 없이 클라이언트 컴포넌트만으로 구성하면 CSR처럼 동작할 수 있다. Next.js를 사용하더라도 메타 데이터 설정, 서버 컴포넌트 활용, 올바른 링크 구조를 확인해야 한다.

Q. Dynamic Rendering은 여전히 유효한가요?
A. 구글은 2023년 이후 Dynamic Rendering(봇에게 SSR, 사용자에게 CSR)을 더 이상 권장하지 않는다. 클로킹과 유사한 패턴이어서 자세히는 클로킹 항목의 위험성을 참조한다. SSR/SSG가 올바른 대안이다.

Q. AI 봇이 언제쯤 JavaScript를 실행할까요?
A. 기술적으로 가능하지만, 수억 페이지를 크롤하는 봇에게 JS 실행은 매우 비용이 크다. Googlebot도 2단계 렌더링 큐를 운영하는 이유가 이 비용 때문이다. AI 봇들이 JS를 실행하게 되더라도 수년이 걸릴 것으로 예상되며, 그때까지는 SSR/SSG가 표준이다.