자바스크립트 SEO, SPA가 구글에 안 잡히는 이유

리액트나 뷰 같은 자바스크립트 프레임워크로 만든 홈페이지가 구글 검색에 전혀 안 잡히는 경우가 있다. 원인은 대부분 하나로 좁혀진다. 페이지의 실제 내용이 자바스크립트가 실행된 뒤에야 화면에 나타나는 구조, 즉 클라이언트 사이드 렌더링이기 때문이다.

결론부터 말하면 이렇다. 구글은 자바스크립트를 실행할 수 있지만, 그 실행은 HTML을 읽는 것보다 훨씬 느리고 번거로운 별도 단계를 거친다. 검색에서 중요한 콘텐츠는 자바스크립트 실행 전 최초 HTML 안에 이미 담겨 있어야 안전하다는 것이 지금 구글이 공개적으로 권하는 방향이다.

이 글은 구글이 실제로 자바스크립트를 어떻게 처리하는지, CSR·서버사이드 렌더링·정적 사이트 생성이 뭐가 다른지, 그리고 SPA(단일 페이지 애플리케이션)를 쓰더라도 검색 노출을 지키는 법을 예시와 수치로 정리한다.

이 글에서 먼저 챙겨 갈 핵심만 추리면 이렇다.

• 구글은 자바스크립트를 실행하긴 하지만 크롤 → 렌더 → 색인 3단계를 거치며, 렌더링 단계에서 순서가 밀리거나 건너뛰어질 수 있다
• 실험 결과 구글은 같은 조건의 자바스크립트 페이지를 HTML 페이지보다 최대 9배 느리게 발견했다
• 과거에 쓰이던 다이나믹 렌더링은 2022년부터 구글이 "임시방편일 뿐 장기 해법이 아니다"라고 공식적으로 언급하며 권장을 접었다
• 지금 권장되는 대안은 서버사이드 렌더링·정적 사이트 생성·하이드레이션 세 가지다
• 제목·설명·본문 링크·구조화 데이터는 반드시 최초 HTML 안에 있어야 안전하다

자바스크립트 SEO란 무엇이고, SPA는 왜 문제가 될까?

자바스크립트 SEO는 자바스크립트로 만들어지는 콘텐츠가 검색엔진에 제대로 발견·해석·색인되도록 만드는 기술적 SEO 분야다. 문제가 자주 생기는 대표 사례가 SPA, 즉 단일 페이지 애플리케이션이다.

SPA는 처음 접속할 때 거의 빈 HTML 문서 한 장만 받고, 그 안의 자바스크립트가 실행되면서 화면 내용을 채워 넣는 방식이다. 사람이 쓰는 브라우저에서는 이 과정이 순식간에 끝나 문제를 느끼기 어렵다. 그러나 검색엔진이 최초 HTML만 먼저 확인하는 순간이 분명히 있고, 그 순간 화면에는 제목도 본문도 없는 빈 뼈대만 보일 수 있다.

실제 코드로 보면 차이가 더 분명하다. 순수 CSR 방식의 최초 HTML 응답은 흔히 이런 모습이다.

<body>
  <div id="root"></div>
  <script src="/static/js/bundle.js"></script>
</body>

제목도, 본문도, 링크도 없다. 전부 bundle.js가 실행된 뒤에야 브라우저 화면에 나타난다. 검색엔진 입장에서는 이 한 줄짜리 문서만 보고 페이지의 가치를 1차로 판단해야 하는 셈이다.

사람 눈에는 똑같은 화면이어도, 검색엔진이 "처음 받는 문서"와 "최종적으로 완성되는 화면"은 전혀 다른 두 장의 종이일 수 있다.

실제로 자주 벌어지는 상황을 예로 들어보자. 포트폴리오 사이트를 만드는 스타트업이 디자인 자유도가 높다는 이유로 리액트 SPA를 골랐다. 완성된 화면은 화려했지만, 몇 달이 지나도 회사명을 검색해도 홈페이지가 상위에 뜨지 않았다. 원인을 찾아보니 모든 페이지의 제목·본문이 자바스크립트 실행 후에만 나타나는 구조였고, 심지어 메뉴 이동도 전부 자바스크립트 클릭 이벤트로만 연결돼 있어 구글봇이 따라갈 링크 자체가 거의 없는 상태였다.

반대 사례도 있다. 비슷한 시기에 같은 업종의 다른 회사는 동일한 리액트 컴포넌트를 쓰면서도 Next.js로 서버사이드 렌더링을 적용했다. 겉모습은 거의 똑같았지만, 검색 결과에는 몇 주 만에 주요 페이지가 잡혔다. 차이는 디자인이 아니라 렌더링 설정 하나였다.

구글은 자바스크립트를 어떻게 크롤링하고 렌더링할까?

구글이 자바스크립트 페이지를 처리하는 과정은 크롤 → 렌더 → 색인, 이렇게 세 단계로 나뉜다. 예전에 널리 알려졌던 "1차 색인은 HTML만, 2차 색인은 렌더링 후"라는 이른바 '두 번의 파도(two waves)' 모델은 2018년 구글 발표에서 나온 설명인데, 지금은 공식 문서에서 그 표현 자체가 빠졌다. 지금은 이 과정을 하나의 비동기 대기열로 이해하는 쪽이 더 정확하다.

단계를 풀어보면 이렇다. 첫째, 크롤 단계에서 구글봇이 robots.txt를 확인하고 최초 HTML을 가져온다. 둘째, 렌더 단계에서 이 페이지가 헤드리스 크롬(최신 ES2020 이상 문법까지 지원하는 브라우저) 렌더링 대기열에 들어간다. 셋째, 색인 단계에서 렌더링이 끝난 뒤의 DOM, 즉 화면에 실제로 그려진 최종 결과물을 읽고 그 안의 링크까지 함께 추출한다.

최초 HTML에 noindex 태그가 들어 있으면, 구글은 렌더링 단계 자체를 건너뛸 수 있다. 자바스크립트가 나중에 그 태그를 지워도 이미 늦은 경우가 많다.

렌더 단계로 넘어가지도 못하는 더 치명적인 실수도 있다. robots.txt에서 자바스크립트나 CSS 파일 경로를 막아버리는 경우다. 예전에는 "검색엔진은 어차피 스크립트를 안 읽으니 차단해도 된다"는 생각으로 /static/js/나 /assets/ 경로를 통째로 Disallow에 넣는 사례가 흔했다. 지금은 반대다. 구글봇이 렌더링을 하려면 그 자바스크립트와 CSS 파일을 직접 받아 실행해야 하는데, robots.txt가 그 파일들을 막고 있으면 렌더링 자체가 실패하거나 빈 화면만 남는다.

실수	왜 문제가 되나	바로잡는 법
robots.txt에서 /js/, /static/ 통째로 차단	렌더링에 필요한 리소스를 구글봇이 못 받아옴	콘텐츠를 그려내는 스크립트·스타일 경로는 차단 목록에서 제외
외부 API 호출에 인증이 걸려 있어 구글봇은 데이터를 못 받음	사람 눈에는 보이는 콘텐츠가 구글에는 빈 상태로 보임	공개 콘텐츠를 보여주는 API는 인증 없이 접근 가능하게 열어둠
렌더링 대기 중 타임아웃이 짧게 걸려 있는 내부 서버 설정	복잡한 페이지는 완성되기 전에 응답이 끊김	서버 응답 자체를 가볍게 만들거나 SSR로 전환

한때 "구글은 자바스크립트를 5초만 기다려준다"는 말이 업계에 널리 돌았다. 이 숫자는 구글의 공식 규정으로 확인된 적이 없는, 근거가 약한 통설에 가깝다. 다만 렌더링이 별도 대기열을 거친다는 사실 자체는 "처리 시점을 예측하기 어렵다"는 뜻이라, 느려도 상관없다고 안심할 이유는 되지 않는다.

이 대기열에 묶인 처리 여력을 흔히 렌더링 예산이라 부른다. 크롤링 예산(구글이 한 사이트에 할당하는 크롤 요청 횟수)과 비슷한 개념인데, 범위가 하나 더 넓다. 크롤링 예산은 "얼마나 많은 페이지를 가져올 것인가"를 결정하고, 렌더링 예산은 그중에서 "얼마나 많은 페이지를 실제로 실행까지 해줄 것인가"를 결정한다. 사이트의 권위(신뢰도)가 높고 서버 응답이 빠를수록 렌더링 예산을 더 넉넉하게 배정받는 경향이 있다.

렌더링 예산을 아끼는 실무적인 방법도 몇 가지로 정리된다. 자바스크립트 번들 크기를 줄이는 것이 가장 기본이다. 번들이 무거우면 다운로드와 실행 모두에 시간이 더 걸린다. 검색 노출과 무관한 기능(채팅 위젯, 추천 알고리즘 등)은 지연 로딩으로 나중에 불러오는 것도 도움이 된다. 페이지가 처음 그려질 때 꼭 필요한 자바스크립트만 우선 실행되게 하면, 핵심 콘텐츠가 렌더링되는 시점도 함께 빨라진다.

CSR·SSR·SSG·ISR, 뭐가 다르고 뭘 골라야 할까?

네 방식의 차이는 "완성된 HTML이 언제, 어디서 만들어지는가" 하나로 정리된다.

클라이언트 사이드 렌더링(CSR)은 브라우저나 구글봇이 자바스크립트를 실행해야 화면이 완성되는 방식이다. 서버사이드 렌더링(SSR)은 요청이 올 때마다 서버가 완성된 HTML을 만들어 즉시 보내주는 방식이다. 정적 사이트 생성(SSG)은 배포(빌드) 시점에 미리 모든 페이지를 HTML로 구워 두는 방식이다. 증분 정적 재생성(ISR)은 SSG의 변형으로, 정적 페이지를 만들어 두고 일정 주기나 요청에 맞춰 백그라운드에서 다시 구워 최신 데이터를 반영한다.

방식	HTML이 완성되는 시점	검색엔진이 최초로 받는 것	잘 맞는 상황
CSR	브라우저에서 JS 실행 후	거의 빈 뼈대	로그인 뒤 대시보드, 내부 관리 화면
SSR	요청마다 서버에서 즉시	완성된 HTML	검색 노출이 필요한 페이지 전반
SSG	배포 시점에 미리	완성된 HTML	블로그처럼 자주 안 바뀌는 페이지
ISR	SSG + 주기적 재생성	완성된 HTML(주기적 갱신)	상품 목록처럼 자주 바뀌지만 매번 실시간 생성은 과한 경우

실무에서 많이 쓰는 프레임워크별로 봐도 네 방식이 전부 지원되는 것은 아니다. 프레임워크를 고를 때 이 지원 여부부터 확인하는 것이 순서다.

프레임워크	SSR	SSG	ISR	비고
Next.js(리액트)	지원	지원	지원	페이지별로 방식을 다르게 지정 가능
Nuxt(뷰)	지원	지원	일부 지원	리액트 생태계의 Next.js와 역할이 유사
Remix(리액트)	지원	제한적	미지원	요청마다 서버 렌더링에 강점
SvelteKit	지원	지원	일부 지원	번들 크기가 작아 렌더링 자체가 가벼움
순수 리액트(Create React App 등)	미지원	미지원	미지원	기본값이 CSR이라 별도 설정 없인 전환 불가

순수 리액트나 순수 뷰로 시작한 프로젝트일수록 전환 작업이 커진다. 반면 Next.js나 Nuxt처럼 서버사이드 렌더링을 기본으로 지원하는 프레임워크를 처음부터 골랐다면, 페이지별 설정만 바꿔 전환할 수 있어 부담이 훨씬 적다.

한 페이지 안에서도 섞어 쓰는 것이 가능하다. 제목·본문·가격 같은 검색에 노출돼야 하는 콘텐츠는 서버에서 완성된 HTML로 내려주고, 장바구니 버튼이나 후기 작성 폼처럼 사용자 입력이 필요한 조각만 자바스크립트로 따로 처리하는 구조다. 이런 방식을 흔히 "아일랜드(섬) 아키텍처"라 부르는데, Next.js의 서버 컴포넌트·클라이언트 컴포넌트 구분이 이 개념을 그대로 구현한 것이다. 페이지 전체를 CSR이나 SSR 하나로 못 박지 않고, 콘텐츠는 서버가, 상호작용은 클라이언트가 맡는 역할 분담이 지금 가장 현실적인 절충안이다.

표로 봐도 감이 안 오면 실제 예시를 비교해 보는 게 빠르다.

검색 노출이 목적이 아닌 화면 — 로그인 뒤 대시보드, 내부 전용 도구 — 은 CSR로 둬도 무방하다. 문제는 "검색에서 찾아와야 하는 페이지"를 CSR로 만드는 경우다.

나쁜 예는 검색 노출이 꼭 필요한 상품 상세 페이지를 순수 CSR(리액트 SPA)로 만든 경우다. 최초 HTML에는 <div id="root"></div> 한 줄만 있고, 제목·가격·설명이 전부 자바스크립트 실행 후에만 화면에 나타난다. 좋은 예는 같은 상품 페이지를 SSR이나 SSG로 만들어, 최초 HTML 응답에 이미 제목·가격·설명·구조화 데이터(JSON-LD)가 들어 있고, 이후 자바스크립트가 장바구니 버튼 같은 상호작용 기능만 덧붙이는 경우다. 이렇게 완성된 HTML 위에 자바스크립트로 상호작용만 입히는 과정을 하이드레이션이라 부른다.

SSR이나 SSG로 전환했다고 끝나는 것은 아니다. 하이드레이션 미스매치라는 또 다른 함정이 있다. 서버가 만들어 보낸 HTML과, 브라우저에서 자바스크립트가 실행되며 다시 그리는 화면이 아주 살짝 달라서 생기는 충돌이다. 예를 들어 서버에서는 "지금 시각: 오전 10시"라고 찍어 보냈는데, 브라우저에서 자바스크립트가 다시 계산하면서 "오전 10시 1분"으로 바뀌는 식이다.

사람 눈에는 큰 문제가 아니지만, 이런 불일치가 쌓이면 브라우저가 서버 HTML을 버리고 처음부터 다시 그리는 경우가 생긴다. 이렇게 되면 서버사이드 렌더링을 적용한 의미 자체가 사라진다 — 검색엔진이 받은 완성된 HTML과, 실제 최종 화면이 달라질 수 있기 때문이다. 날짜·시간, 난수로 만든 ID, 사용자 기기에 따라 달라지는 값(예: window.innerWidth)을 서버와 클라이언트가 동일하게 계산하도록 맞추는 것이 기본 대응이다.

다이나믹 렌더링은 지금도 써도 될까?

다이나믹 렌더링은 구글봇에는 미리 렌더링된 HTML을, 일반 사용자에게는 원래의 자바스크립트 버전을 각각 다르게 보여주는 방식이다. 결론은 지금은 새로 도입할 이유가 없다는 것이다.

구글은 2022년 8월 관련 공식 문서에 "다이나믹 렌더링은 임시방편이며 장기적인 해법이 아니다"라는 경고 문구를 추가했다. 이유는 간단하다. 사용자용 버전과 검색엔진용 버전을 따로 만들고 계속 동기화해야 하는 추가적인 복잡성과 리소스 부담이 크기 때문이다. 대신 구글이 권장하는 대안은 앞서 정리한 서버사이드 렌더링, 정적 렌더링(사전 렌더링), 하이드레이션 세 가지다.

다이나믹 렌더링 자체가 클로킹(사용자와 검색엔진에 다른 내용을 보여주는 어뷰징)으로 간주돼 패널티를 받는 것은 아니다. 패널티 대상이 아니라고 안심할 문제가 아니라, 더 나은 대안이 이미 공식적으로 제시된 상태라는 점이 핵심이다.

이미 다이나믹 렌더링을 운영 중이라면 당장 걷어낼 필요는 없다. 다만 새로 시작하는 프로젝트라면 처음부터 SSR이나 SSG로 설계하는 편이 유지보수 부담을 크게 줄여준다.

SPA를 그대로 써야 한다면 무엇부터 체크해야 할까?

구조를 전부 바꿀 수 없는 상황도 있다. 그럴 때는 아래 항목부터 순서대로 점검한다.

1. 제목(title)·메타 설명·h1·정규 URL(canonical)이 최초 HTML 응답 안에 그대로 있는지 확인한다.
2. 본문 링크가 실제 <a href="..."> 태그로 걸려 있는지 본다. 자바스크립트 클릭 이벤트로만 연결된 링크는 구글봇이 못 찾을 수 있다 — 이 문제만 따로 다룬 자바스크립트 링크와 AI 크롤러 글에 더 자세히 정리해 두었다.
3. 라우팅에 History API(주소가 실제로 바뀌는 방식)를 쓰는지, # 기반 프래그먼트 라우팅을 쓰지 않는지 확인한다.
4. 구조화 데이터(JSON-LD)가 렌더링 전 최초 HTML에 포함돼 있는지 본다.
5. 최초 HTML에 실수로 noindex가 남아 있지 않은지 다시 확인한다.
6. 검증은 로컬 크롤링 도구가 아니라 구글 서치 콘솔의 URL 검사 도구에서 "실제 URL 테스트" 결과를 직접 눈으로 확인한다.
7. 검색 노출과 무관한 기능은 지연 로딩으로 미뤄 렌더링 예산을 핵심 콘텐츠에 먼저 쓰도록 우선순위를 정리한다.

로컬 크롤링 도구(스크리밍프로그 등)는 자바스크립트를 완벽하게 재현하지 못하는 경우가 많다. 구글이 실제로 보는 화면과 가장 가까운 결과는 서치 콘솔의 URL 검사 도구에서 확인할 수 있다. 이 과정에서 본문 링크 구조까지 함께 점검하면 좋다. 내부 링크를 어떻게 설계해야 하는지는 내부 링크 전략 글에서 더 폭넓게 다루고 있다.

우리 사이트의 렌더링 문제는 어떻게 직접 확인할까?

도구 없이도 지금 바로 할 수 있는 점검이 있다. 가장 간단한 방법은 브라우저에서 "페이지 소스 보기"와 "개발자 도구의 요소 검사"를 나란히 열어보는 것이다. 페이지 소스 보기는 서버가 최초로 보낸 HTML 그대로를 보여준다. 반면 요소 검사(Elements 탭)는 자바스크립트 실행 뒤 최종적으로 완성된 화면을 보여준다. 이 두 화면에서 제목·본문·링크가 사라져 있다면, 구글봇도 똑같은 차이를 겪을 가능성이 크다.

조금 더 정확하게 보고 싶다면 터미널에서 curl 주소 명령으로 서버 응답을 그대로 받아보는 방법도 있다. 브라우저 없이, 자바스크립트를 전혀 실행하지 않은 순수 HTML만 눈으로 확인할 수 있다. 이 결과에 제목 태그나 본문 문장이 안 보인다면, 그 페이지는 지금 구글의 1차 크롤 단계에서 빈 문서로 취급될 가능성이 있다는 뜻이다.

라이트하우스(Lighthouse)나 페이지스피드 인사이트 점수가 높다고 안심해서는 안 된다. 이 도구들은 성능(로딩 속도)을 측정하는 것이고, 검색엔진이 콘텐츠를 발견·색인하는 문제와는 별개의 지표다.

가장 확실한 확인 방법은 역시 구글 서치 콘솔이다. URL 검사 도구에서 "실제 URL 테스트"를 누르면, 구글봇이 실제로 가져간 HTML과 렌더링된 화면의 스크린샷을 함께 보여준다. 여기서 본문·제목·링크가 보이지 않는다면, 사용자에게는 멀쩍이 보이는 화면도 구글에는 비어 있는 것과 같다. 페이지 소스 보기 → curl → 서치 콘솔 URL 검사 순서로 점검 범위를 넓혀가면 원인을 좁히기 쉽다.

구조화 데이터(JSON-LD)도 같은 기준으로 점검한다. 아래처럼 <script type="application/ld+json"> 블록이 페이지 소스 보기 단계에서도 그대로 보여야 안전하다.

<script type="application/ld+json">
{
  "@type": "Article",
  "headline": "글 제목",
  "datePublished": "2026-10-04"
}
</script>

이 코드가 자바스크립트 실행 후에만 동적으로 삽입된다면, 구조화 데이터 역시 렌더링 대기열에 묶여 있는 상태라 반영이 늦어질 수 있다.

렌더링 지연은 실제로 순위에 얼마나 영향을 줄까?

자바스크립트 렌더링은 단순히 "느리다"는 느낌이 아니라 구체적인 숫자로도 확인된다. SEO 실험 기관 어널리(Onely)가 동일한 조건으로 HTML 폴더와 자바스크립트 폴더에 각각 7개 페이지를 심어 구글봇의 발견 속도를 비교한 적이 있다. 결과는 분명했다. 구글봇이 HTML 페이지를 마지막(7번째)까지 발견하는 데 36시간이 걸린 반면, 똑같은 구조의 자바스크립트 페이지는 313시간이 걸렸다. 약 9배 차이다. 첫 번째 링크를 발견하는 데도 HTML은 25시간, 자바스크립트는 52시간으로 약 2배 차이가 났다.

렌더링이 아예 안 되는 것은 아니다. 다만 "더 늦게, 더 불확실하게" 처리된다는 뜻이다. 신상품 페이지처럼 시간이 곧 기회인 콘텐츠일수록 이 지연이 치명적으로 작용한다.

이 지연은 신규 사이트일수록 더 아프게 작용한다. 새로 만든 도메인은 원래도 구글이 크롤링 예산을 보수적으로 배정하는 경향이 있는데, 이 부분은 신규 사이트의 크롤링 예산 글에서 따로 다루고 있다. 여기에 렌더링 대기열까지 더해지면 노출까지 걸리는 시간이 눈에 띄게 길어진다. 반대로 이미 신뢰도가 쌓인 오래된 대형 사이트는 상대적으로 영향이 작다.

이 지연이 실제 사업에 끼치는 영향은 업종마다 체감 정도가 다르다. 아래 표로 정리하면 "우리 사이트는 얼마나 급한가"를 가늠하기 쉽다.

업종·페이지 유형	지연의 체감 피해	이유
이커머스 신상품·시즌 상품 페이지	크다	노출이 늦어지는 며칠이 그대로 판매 기회 손실로 이어진다
뉴스·미디어 속보 페이지	매우 크다	속보성이 생명인데 몇 시간만 늦어도 검색 가치가 사라진다
병원·동네 가게 같은 지역 소상공인 홈페이지	중간	페이지 수가 적고 갱신이 드물어 지연보다는 발행 빈도 자체가 더 중요
기업 소개·회사 연혁처럼 거의 안 바뀌는 페이지	작다	한 번만 제대로 색인되면 이후 변화가 거의 없어 지연의 피해가 누적되지 않는다
SaaS 로그인 뒤 대시보드	거의 없음	검색 노출 대상이 아니므로 렌더링 지연이 문제가 되지 않는다

신상품을 자주 올리는 쇼핑몰이나 속보를 다루는 미디어일수록 SSR·SSG 전환의 우선순위가 높다는 뜻이다. 반대로 페이지 수가 적고 거의 안 바뀌는 소개 페이지 위주라면, 전환보다 발행 빈도나 콘텐츠 품질에 먼저 시간을 쓰는 것이 합리적일 수 있다.

같은 업종 안에서도 페이지 역할에 따라 우선순위는 또 나뉜다. 쇼핑몰이라면 신상품 목록·상세 페이지가 1순위, 공지사항이나 회사 소개는 그다음으로 미뤄도 된다. 미디어라면 속보·실시간 이슈 페이지가 1순위, 과거 기사 아카이브는 이미 색인된 상태라 급하지 않다. 우선순위를 "업종 전체"가 아니라 "페이지 역할" 단위로 쪼개서 보는 것이 전환 작업의 범위를 현실적으로 줄여준다.

CSR에서 SSR·SSG로, 단계별로는 어떻게 옮겨가야 할까?

사이트 전체를 한 번에 새로 만드는 것은 현실적이지 않은 경우가 많다. 이럴 때는 검색 노출이 가장 중요한 페이지부터 순서를 정해 옮기는 방식이 안전하다.

1. 우선순위를 매긴다. 검색에서 유입이 가장 많거나, 매출·문의와 직결되는 페이지(상품 상세, 서비스 소개, 블로그 글)를 먼저 추린다. 로그인 뒤 화면처럼 검색과 무관한 페이지는 순위에서 제외한다.
2. 페이지 단위로 전환한다. Next.js 같은 프레임워크는 페이지별로 렌더링 방식을 다르게 지정할 수 있다. 사이트 전체를 한 번에 바꾸지 않고, 우선순위가 높은 페이지부터 SSR이나 SSG로 바꿔나가면 위험이 줄어든다.
3. 전환 직후에는 서치 콘솔로 확인한다. 전환한 페이지를 URL 검사 도구에 넣어 최초 HTML에 제목·본문·링크가 제대로 들어가 있는지 바로 확인한다.
4. 사이트맵과 함께 재제출한다. 전환이 끝난 페이지는 변경된 콘텐츠를 반영하도록 사이트맵에서 lastModified 값이 갱신되는지 점검하고, 서치 콘솔에서 재크롤을 요청한다.
5. 남은 CSR 페이지는 체크리스트로 관리한다. 당장 전환하지 못한 페이지는 앞서 정리한 체크리스트만이라도 지켜 피해를 최소화한다.
6. 전환 전후 데이터를 비교한다. 서치 콘솔의 "페이지" 보고서에서 전환한 페이지들의 색인 상태와 노출 수가 몇 주 사이에 어떻게 바뀌는지 추적한다. 변화가 보이지 않는다면 전환 자체가 아니라 다른 원인(콘텐츠 품질, 내부 링크 부족)을 함께 점검한다.

전부 바꾸느냐 하나도 안 바꾸느냐의 양극단이 아니다. 검색으로 돈이 들어오는 페이지부터 먼저 옮기는 것이 현실적인 전략이다.

자바스크립트 SEO를 둘러싼 오해, 뭐가 진짜고 뭐가 아닐까?

업계에 떠도는 말 중에는 사실과 반만 맞는 이야기가 많다. 실무에서 가장 자주 마주치는 오해를 정리하면 이렇다.

흔히 하는 말	실제 사실
"구글은 자바스크립트를 전혀 못 읽는다"	틀렸다. 헤드리스 크롬으로 실행은 하지만, HTML보다 느리고 대기열을 거친다
"자바스크립트는 5초 안에만 실행되면 안전하다"	공식 규정으로 확인된 적 없는 통설에 가깝다. 정확한 시간 제한은 공개돼 있지 않다
"다이나믹 렌더링은 클로킹이라 바로 페널티를 받는다"	패널티 대상은 아니다. 다만 구글이 권장을 접었을 뿐이다
"라이트하우스 점수가 100점이면 색인도 문제없다"	라이트하우스는 성능 측정 도구다. 콘텐츠 발견·색인 여부와는 별개의 지표다
"리액트·뷰로 만들면 무조건 SEO가 불리하다"	프레임워크 자체의 문제가 아니라 렌더링 방식을 어떻게 설정했는지의 문제다
"사이트맵에 올리면 렌더링 지연 문제도 해결된다"	사이트맵은 "이런 페이지가 있다"는 목록일 뿐, 렌더링 자체를 빠르게 해주지 않는다
"한 번 색인되면 렌더링 구조를 안 바꿔도 된다"	콘텐츠가 자주 바뀌는 페이지는 재렌더링도 똑같이 대기열을 거치므로 지연이 반복된다

마지막 줄이 가장 중요하다. 리액트나 뷰가 SEO에 불리하다는 통념은 정확히 말하면 "CSR로만 설정했을 때"에 한정된 이야기다. 같은 프레임워크라도 SSR이나 SSG로 설정을 바꾸면 완전히 다른 결과가 나온다.

이루웹은 왜 서버사이드 렌더링 기반으로 홈페이지를 만들까?

이루웹은 Next.js, 즉 서버사이드 렌더링과 정적 생성을 함께 지원하는 프레임워크를 기반으로 홈페이지를 제작한다. 이유는 단순하다. 자바스크립트 프레임워크의 개발 편의성은 그대로 누리면서, 검색엔진에는 완성된 HTML을 즉시 보여줄 수 있기 때문이다.

화려한 디자인의 홈페이지를 만드는 것과, 그 홈페이지가 검색에 실제로 잡히는 것은 다른 문제다. 무인도에 아무리 예쁜 호텔을 지어도 손님이 존재를 모르면 끝이다 — 렌더링 구조를 잘못 고르면 자바스크립트로 지은 '예쁜 호텔' 자체가 검색엔진 입장에서는 안 보이는 섬이 될 수 있다.

기획 단계부터 검색 노출을 염두에 둔 홈페이지가 필요하다면 SEO 최적화 홈페이지 제작 서비스에서 렌더링 구조 설계부터 함께 점검한다. 예약·커머스·대시보드처럼 로직이 복잡한 서비스라도 복잡한 플랫폼 개발에서 SSR·ISR 기반으로 검색 친화성을 유지한 채 구축할 수 있다.

서버사이드 렌더링을 챙기면 덤으로 얻는 것도 있다. 챗GPT나 퍼플렉시티 같은 AI 검색 서비스의 크롤러는 구글봇보다 자바스크립트 렌더링 지원이 더 제한적인 경우가 많다. 최초 HTML에 콘텐츠가 바로 담겨 있으면 구글뿐 아니라 이런 AI 크롤러에도 똑같이 유리하게 작동한다. 하나의 렌더링 구조 개선이 전통적인 검색 SEO와 AI 검색 대응(GEO)을 동시에 챙기는 셈이다.

상담을 진행하다 보면 "지금 사이트를 통째로 갈아엎어야 하느냐"는 질문을 자주 받는다. 대답은 대부분 "아니다"다. 기존 사이트의 디자인과 콘텐츠는 그대로 두고, 렌더링 구조만 바꾸는 리뉴얼도 충분히 가능하다. 중요한 것은 지금 쓰는 프레임워크가 서버사이드 렌더링을 지원하는지, 그리고 검색 노출이 필요한 페이지부터 우선순위를 어떻게 정할지 하는 두 가지뿐이다.

자주 묻는 질문

구글이 자바스크립트를 실행할 수 있는데 왜 문제가 되나요?

실행 자체는 가능하지만, 그 실행이 별도의 렌더링 대기열을 거치기 때문에 처리 시점이 늦어지거나 뒤로 밀릴 수 있다는 점이 문제다. 실행이 안 되는 것이 아니라, 느리고 예측하기 어렵다는 것이 핵심이다.

리액트나 뷰로 만든 사이트는 전부 SSR로 바꿔야 하나요?

아니다. 검색 노출이 필요 없는 화면, 예를 들어 로그인 뒤 대시보드나 내부 전용 도구는 CSR로 둬도 괜찮다. 검색에서 찾아와야 하는 페이지만 SSR이나 SSG로 전환하면 충분하다.

다이나믹 렌더링을 쓰면 패널티를 받나요?

패널티 대상은 아니다. 다만 구글이 2022년부터 공식적으로 권장을 접은 방식이라, 새 프로젝트에 지금 새로 도입할 이유는 없다. 이미 쓰고 있다면 당장 걷어내기보다 다음 리뉴얼 시점에 SSR·SSG로 옮기는 쪽을 권한다.

우리 사이트가 렌더링 문제를 겪고 있는지 어떻게 확인하나요?

가장 정확한 방법은 구글 서치 콘솔의 URL 검사 도구에서 "실제 URL 테스트"를 실행해, 구글이 실제로 보는 렌더링 결과와 추출된 HTML을 직접 눈으로 확인하는 것이다. 로컬 크롤러 결과만 믿지 않는 것이 중요하다.

서버 로그를 보면 구글봇의 렌더링 패턴을 알 수 있나요?

어느 정도는 가능하다. 서버 로그에서 구글봇 계정으로 들어온 요청을 추적하면, 크롤(최초 HTML 요청)과 렌더(스크립트·API 요청)가 시간 차를 두고 따로 들어오는 패턴을 확인할 수 있다. 크롤 이후 렌더링 관련 요청이 한참 뒤에 들어오거나 아예 안 들어온다면, 그 페이지가 렌더링 대기열에서 밀리고 있다는 신호로 볼 수 있다.

챗GPT 같은 AI 검색도 자바스크립트를 똑같이 처리하나요?

아니다. 구글봇은 헤드리스 크롬으로 렌더링을 지원하지만, AI 검색 서비스의 크롤러는 자바스크립트 렌더링 지원이 더 제한적인 경우가 많다. 최초 HTML에 콘텐츠가 바로 담겨 있어야 구글과 AI 검색 양쪽 모두에 안전하다.

코어 웹 바이탈과는 어떤 관계가 있나요?

방향은 같지만 측정 대상이 다르다. 코어 웹 바이탈은 이미 로딩이 끝난 페이지가 얼마나 빠르고 안정적인지를 재는 지표이고, 이 글에서 다룬 렌더링 지연은 그 이전 단계, 즉 "콘텐츠가 검색엔진에 발견·색인되기까지 걸리는 시간"의 문제다. 자바스크립트 번들을 가볍게 만들면 두 지표 모두에 함께 도움이 되는 경우가 많다.

자바스크립트 기반 홈페이지나 플랫폼을 운영 중인데 검색 노출이 예상보다 더디다면, 지금이 렌더링 구조 자체를 점검해 볼 시점입니다. 이루웹은 SEO 전문가와 개발자가 함께 Next.js 기반으로 사이트를 설계해, 화면은 그대로 두고 구조만 바꿔 검색 친화성을 높이는 작업을 도와드리고 있습니다. 현재 사이트의 렌더링 방식이 궁금하시다면 무료 상담을 통해 편하게 문의해 주시기 바랍니다.