JavaScript 자체가 SEO의 적은 아닙니다. 문제는 많은 팀이 "브라우저에서 잘 보이면 검색엔진도 다 알아서 읽겠지"라고 생각하는 데서 시작됩니다. 실제로는 그렇지 않습니다.
이 글은 거의 대부분의 핵심 콘텐츠를 클라이언트 사이드 JavaScript로 넣는 테스트 페이지를 기반으로 합니다. 각 검색엔진이 무엇을 먼저 읽는지, 얼마나 늦게 따라오는지, 어디서 한계가 드러나는지를 확인하는 실험입니다.
React, Vue, Next.js, Nuxt 같은 프레임워크를 쓰고 있다면 이 이야기는 실무와 꽤 가깝습니다. 배포 전에 크롤러가 실제로 무엇을 받는지 보고 싶다면 SEO Analyzer로 초기 HTML과 렌더링 결과를 먼저 점검하는 편이 좋습니다.
먼저 짚어야 할 것: Google의 2단계 인덱싱
Google은 JS가 많은 페이지를 한 번에 다 처리하지 않는 경우가 많습니다.
- 먼저 초기 HTML을 크롤링하고 1차 인덱싱합니다.
- 나중에 렌더링 자원이 생기면 JavaScript를 실행하고 최종 DOM을 다시 봅니다.
즉, 핵심 정보가 JS 실행 이후에만 생기면 첫 번째 웨이브에서는 빠집니다.
이 차이 때문에 처음에는 이상한 snippet이 뜨고, 며칠 뒤에야 수정되는 일이 생깁니다.
실험 페이지는 어떻게 만들었나
테스트 페이지는 일부러 극단적으로 구성했습니다.
- 초기 HTML은 거의 비어 있음
title,H1, meta description, 본문이 JS로만 들어감- 내용은 AJAX로 불러옴
Articleschema도 JS로 주입
즉, JavaScript를 실행하지 않으면 검색엔진이 읽을 수 있는 핵심 정보가 거의 없게 만든 셈입니다.
1$(document).ready(function () { 2 $.ajax({ 3 url: '/api/get-article-data', 4 success: function(data) { 5 $('title').text(data.title); 6 $('h1#main-title').text(data.h1); 7 $('meta[name="description"]').attr('content', data.description); 8 $('#article-content').html(data.body); 9 10 var script = document.createElement('script'); 11 script.type = 'application/ld+json'; 12 script.text = JSON.stringify(data.schemaData); 13 document.head.appendChild(script); 14 } 15 }); 16});
이렇게 하면 SERP 문구가 바뀌는지 아닌지만 봐도 렌더링 여부를 꽤 직관적으로 판단할 수 있습니다.
Google 도구는 무엇을 볼 수 있었나
먼저 Google의 Rich Results Test는 최종 DOM을 잘 생성했고, JavaScript로 들어간 요소도 읽어냈습니다.
즉, Google은 이 페이지를 기술적으로 읽을 수 있었습니다. 다만 "읽을 수 있다"와 "바로 인덱스에 반영한다"는 전혀 다른 문제입니다.
첫 번째 웨이브에서 실제로 보인 것
URL 제출 후 몇 시간 안에 Google, Bing, Yandex 모두 결과에는 페이지가 나타났습니다. 하지만 snippet은 렌더링 후 콘텐츠가 아니라 초기 HTML에서 가져온 내용이었습니다.
여기가 핵심입니다. 페이지는 "인덱스됨" 상태일 수 있어도, 우리가 의도한 형태로 읽힌 것은 아닐 수 있습니다.
이 문제는 특히 아래 상황에서 더 크게 느껴집니다.
- 빠른 색인이 필요한 신규 페이지
- 뉴스나 이벤트성 콘텐츠
- 당장 반영돼야 하는 title/description 수정
- 배포 후 바로 성과를 봐야 하는 랜딩 페이지
두 번째 웨이브: Google은 결국 따라오지만 느리다
며칠 뒤 site: 검색에서는 원래 JavaScript 실행 후에만 존재하던 문장이 보이기 시작했습니다. 즉, Google이 최종 DOM을 반영한 것입니다.
이건 중요한 결론입니다. Google은 AJAX 기반 CSR 콘텐츠도 읽을 수 있습니다. 다만 시간 차가 생깁니다.
프로젝트에 따라 이 지연은 감수할 수도 있고, 비즈니스상 받아들이기 어려울 수도 있습니다.
Bing과 Yandex에서는 차이가 더 분명했다
같은 실험 동안 Bing과 Yandex는 초기 HTML에 훨씬 더 묶여 있었습니다. Google만큼 유연하게 렌더링 결과를 따라오지 못했습니다.
이건 Google만 보고 설계한 사이트가 다른 검색엔진에서 왜 약해지는지를 잘 보여줍니다. 국내라면 Baidu 같은 엔진까지 고려해야 할 수도 있고, 러시아권이라면 Yandex도 여전히 무시하기 어렵습니다.
대안으로 시험한 것: Dynamic Rendering
추가로 dynamic rendering도 적용했습니다.
- 일반 사용자 브라우저에는 기존 JS 페이지 제공
- 검색엔진 크롤러에는 미리 렌더링한 HTML 제공
이후 Yandex는 스니펫을 업데이트하고, 프리렌더된 콘텐츠를 기반으로 결과를 보여줬습니다.
이게 모든 프로젝트의 정답이라는 뜻은 아닙니다. 하지만 검색엔진이 즉시 읽을 수 있는 HTML을 주면 문제가 크게 줄어든다는 점은 분명합니다.
이 실험이 남기는 핵심 정리
1. Google이 JS를 렌더링한다고 해서 안심할 수는 없다
많은 팀이 "Google이 JS 렌더링 가능"이라는 말을 "그럼 어디에 콘텐츠를 두든 상관없다"로 받아들입니다. 그건 다릅니다.
- 렌더링에는 큐가 있음
- 반영에는 지연이 있음
- 모든 페이지가 같은 속도로 처리되지 않음
- 핵심 콘텐츠가 초기 HTML 밖에 있으면 SEO 즉시성이 떨어짐
2. 초기 HTML은 여전히 가장 강한 안전장치다
SEO에 중요한 페이지라면 최소한 아래는 초기 HTML에 포함되는 편이 낫습니다.
<title>- meta description
- H1
- 핵심 본문
- 주요 링크
- 중요한 구조화 데이터
이게 검색엔진 간 편차를 줄이는 가장 현실적인 방법입니다.
3. SSR과 SSG는 여전히 가장 안정적이다
기술적으로 가능하다면 SSR 또는 SSG가 핵심 콘텐츠용으로는 더 낫습니다. CSR을 쓰지 말라는 뜻이 아니라, 제목과 본문 의미를 렌더링 큐에 맡기지 말자는 이야기입니다.
4. Dynamic rendering은 임시 대응에 가깝다
레거시 구조나 어려운 마이그레이션에서는 도움이 될 수 있습니다. 하지만 운영 복잡도가 늘어나고, 잘못 다루면 사용자 버전과 봇 버전의 차이 문제가 생깁니다.
실무 권장 사항
정리하면 이 정도로 압축할 수 있습니다.
- SEO 핵심 콘텐츠를 CSR에만 의존하지 않는다.
- 크롤러가 실제로 받는 HTML을 확인한다.
- 빠른 색인이 중요하면 SSR 또는 SSG를 우선한다.
- CSR은 상호작용 레이어에 쓰고, 의미 레이어는 초기 HTML에 둔다.
- Dynamic rendering은 구조상 어쩔 수 없을 때만 고려한다.
실제 점검 단계에서는 SEO Analyzer로 초기 HTML과 렌더링 상태를 확인하고, Meta Tag Generator로 제목과 메타 신호를 고정해 두는 편이 안전합니다.
마무리
이 실험이 보여주는 건 "JavaScript가 SEO를 망친다"가 아닙니다. 더 정확히 말하면, 핵심 의미를 클라이언트 렌더링 뒤로 미루면 색인 지연과 검색엔진별 편차를 감수해야 한다는 뜻입니다.
규칙을 하나만 남긴다면 이겁니다. 인터랙션은 JavaScript에 맡겨도 좋지만, SEO의 핵심 의미는 가능한 한 처음부터 HTML에 담아 두세요. 그게 결국 제일 덜 위험합니다.
