"홈페이지 새로 만들었는데, 한 달이 지나도 구글에 안 떠요."
이런 상담을 받으면 저는 가장 먼저 사이트 주소를 받아서 한 가지를 확인합니다. 화면에는 글과 사진이 멀쩡히 보이는데, 정작 구글이 그 페이지에서 읽어가는 글자는 거의 없는 경우가 있습니다. 디자인은 훌륭한데 검색엔진 눈에는 빈 페이지로 보이는 거죠. 원인은 콘텐츠가 아니라 "웹을 어떻게 개발했느냐"에 있었습니다.
"웹 개발이 SEO에 영향을 주는 이유는, 검색엔진이 사람과 다른 방식으로 페이지를 읽기 때문이다. 사람은 화면에 보이는 것을 보지만, 검색엔진은 코드를 먼저 읽고 그 다음 화면을 추측한다." — 야무진SEO
코딩을 모르는 사진작가 출신으로 3년간 30개 사이트를 직접 만들면서, 저는 이 차이를 몸으로 배웠습니다. 같은 콘텐츠를 넣어도 개발 방식 하나 때문에 어떤 사이트는 일주일 만에 색인되고, 어떤 사이트는 두 달이 지나도 검색에 안 잡혔습니다. 이 글에서는 개발 용어를 사장님 눈높이로 풀어서, 어떤 개발 방식이 검색에 유리하고 불리한지 정리하겠습니다.
검색엔진은 페이지를 어떻게 읽을까
구글봇은 사람처럼 페이지를 "보는" 게 아니라 "읽습니다". 정확히는 세 단계를 거칩니다.
첫째, 크롤링(crawling) 단계에서 봇이 페이지의 HTML 코드를 통째로 받아옵니다. 둘째, 렌더링(rendering) 단계에서 자바스크립트를 실행해 실제 화면을 그려봅니다. 셋째, 색인(indexing) 단계에서 그 결과를 데이터베이스에 저장합니다. 검색 결과에 뜨려면 이 세 단계를 모두 통과해야 합니다.
문제는 두 번째 단계입니다. HTML만 읽는 첫 단계는 빠르고 가볍지만, 자바스크립트를 실행하는 렌더링은 자원이 많이 듭니다. 그래서 구글은 자바스크립트 렌더링을 "나중에" 처리하는 대기열에 넣습니다. 콘텐츠가 자바스크립트로만 만들어진 사이트는 이 대기열에서 며칠, 길게는 몇 주를 기다리게 됩니다.
"검색엔진에게 HTML은 즉답이고, 자바스크립트는 숙제입니다. 즉답으로 보여줄 수 있는 콘텐츠를 숙제로 미루면, 채점도 그만큼 늦어집니다." — 야무진SEO
CSR vs SSR — 렌더링 방식이 색인 속도를 가른다
여기서 가장 중요한 개념이 등장합니다. 바로 렌더링을 어디서 하느냐입니다. 크게 두 가지 방식이 있습니다.
CSR(클라이언트 사이드 렌더링): 서버는 거의 빈 HTML 껍데기만 보내고, 방문자의 브라우저(클라이언트)가 자바스크립트를 돌려서 화면을 그립니다. 요즘 유행하는 리액트(React)·뷰(Vue) 기반 사이트, 그리고 일부 노코드·저코드 빌더로 만든 사이트가 이 방식을 씁니다. 화면 전환이 부드럽고 앱 같은 느낌을 주는 장점이 있습니다.
SSR(서버 사이드 렌더링): 서버가 완성된 HTML을 미리 만들어서 보냅니다. 검색엔진이 첫 단계에서 받아오는 코드 안에 이미 글과 제목이 다 들어 있죠. 워드프레스, 그리고 제대로 설계된 정적 사이트가 이 방식에 가깝습니다.
검색 관점에서 둘의 차이는 결정적입니다. CSR 사이트는 봇이 HTML을 받아도 거의 빈 껍데기뿐이라, 자바스크립트 렌더링을 끝낼 때까지 콘텐츠를 못 봅니다. 반면 SSR 사이트는 첫 코드에 콘텐츠가 다 들어 있어서, 봇이 바로 읽고 색인합니다.
제가 직접 겪은 사례입니다. 저코드 빌더로 만든 한 서비스 소개 페이지가 두 달 동안 단 한 건도 색인되지 않았습니다. 코드를 열어보니 본문 글자가 HTML에 하나도 없고 전부 자바스크립트로 그려지는 구조였습니다. 같은 콘텐츠를 서버에서 미리 렌더링되도록 바꾸자, 5일 만에 색인이 시작됐습니다. 콘텐츠는 글자 하나 안 바꿨는데 말이죠.
자바스크립트가 많을수록 검색이 불리해지는 이유
자바스크립트 자체가 나쁜 건 아닙니다. 문제는 "콘텐츠를 자바스크립트에 의존시키는 것"입니다.
검색엔진이 자바스크립트를 실행하긴 합니다. 하지만 세 가지 함정이 있습니다.
첫째, 타이밍 문제입니다. 앞서 말한 렌더링 대기열 때문에 색인이 늦어집니다. 경쟁사가 같은 키워드 글을 SSR로 올리면, 우리 CSR 페이지가 색인되기도 전에 이미 상위를 차지합니다.
둘째, 실패 위험입니다. 자바스크립트 실행 중 에러가 하나라도 나면, 봇은 그 페이지를 "빈 페이지"로 판단하고 넘어갑니다. 사람 브라우저에서는 잘 보이던 페이지가 봇에게는 백지인 거죠.
셋째, 자원 낭비입니다. 구글은 사이트마다 "크롤 예산(crawl budget)"을 둡니다. 무거운 자바스크립트를 매번 실행하느라 예산을 다 쓰면, 정작 새 글이나 중요한 페이지를 크롤할 여력이 줄어듭니다.
개발 업계에서 핫 리로딩(Hot Reloading)이나 서버리스 함수(Azure Functions 같은) 같은 용어를 들어보셨을 겁니다. 이것들은 개발자가 코드를 빠르게 수정하고 배포하기 위한 편의 도구이지, 검색엔진을 위한 기능이 아닙니다. 개발이 편한 것과 검색에 잘 잡히는 것은 전혀 다른 이야기입니다. 개발사가 "최신 기술로 만들었다"고 해도, 그게 검색에 유리하다는 보장은 없습니다.
시맨틱 마크업 — 검색엔진이 알아듣는 언어로 말하기
콘텐츠가 HTML에 들어 있다고 끝이 아닙니다. 어떤 태그로 감쌌느냐도 중요합니다. 이것을 시맨틱 마크업(semantic markup)이라고 합니다.
시맨틱 마크업이란, 내용의 역할에 맞는 HTML 태그를 쓰는 것을 말합니다. 제목은 <h1>, 본문 단락은 <p>, 메뉴는 <nav>, 본문 영역은 <main> 식으로요. 검색엔진은 이 태그를 보고 "이게 제목이구나, 이게 본문이구나" 하고 구조를 파악합니다.
반대로 모든 걸 의미 없는 <div>와 <span>으로만 채우면, 봇은 무엇이 제목이고 무엇이 핵심인지 알 수 없습니다. 디자인 위주의 빌더나 비주얼 에디터로 만든 사이트에서 이 문제가 자주 보입니다. 화면은 제목처럼 크고 굵게 보이지만, 코드상으로는 그냥 굵은 글씨 한 줄일 뿐이죠.
제 경험상 <h1> 태그를 페이지마다 정확히 한 개씩, 핵심 키워드를 담아 배치하는 것만으로도 순위가 눈에 띄게 안정됐습니다. 거창한 기술이 아니라, 검색엔진이 알아듣는 언어로 정직하게 말해주는 것입니다. HTML·CSS와 SEO 글에서 태그별 활용법을 더 자세히 다뤘습니다.
코드 경량화 — 가벼운 페이지가 검색에 유리하다
마지막 요소는 속도입니다. 구글은 페이지 로딩 속도를 순위 신호로 명시했습니다. (출처: Google Search Central, 페이지 경험 가이드)
여기서 개발 방식이 또 영향을 줍니다. 자바스크립트와 CSS 파일이 무겁고 정리가 안 되어 있으면 페이지가 느려집니다. 불필요한 라이브러리를 잔뜩 불러오는 빌더형 사이트일수록 이 문제가 심합니다.
코드 경량화란, 사용하지 않는 코드를 덜어내고 파일 크기를 줄여 페이지를 빠르게 만드는 작업입니다. 이미지 최적화, CSS 비동기 로딩, 불필요한 스크립트 제거 같은 것들이 여기에 속합니다. 속도가 빨라지면 검색 순위뿐 아니라 방문자 이탈률도 함께 좋아집니다. 속도와 사용자 경험의 관계는 코어 웹 바이탈 글에서 수치와 함께 설명했습니다.
경쟁사가 놓치는 빈틈 — 사장님이 개발사에게 꼭 물어야 할 질문
개발 용어를 백과사전처럼 설명하는 글은 많습니다. 핫 리로딩이 어떻고, 서버리스가 어떻고 하는 글들이죠. 하지만 정작 사장님에게 필요한 건 따로 있습니다. "내 사이트를 만들 개발사에게 뭘 물어봐야 하나" 입니다. 이걸 알려주는 글은 거의 없습니다.
홈페이지를 새로 맡기거나 리뉴얼할 때, 아래 다섯 가지를 그대로 물어보세요. 답을 머뭇거리는 개발사라면 SEO를 진지하게 고려하지 않은 것입니다.
- "우리 페이지 본문이 HTML 소스에 그대로 들어가나요, 자바스크립트로 그려지나요?" — SSR인지 CSR인지 확인하는 핵심 질문입니다.
- "자바스크립트를 꺼도 본문 글이 보이나요?" — 브라우저에서 JS를 끄고 페이지를 열어보면 봇이 보는 화면과 비슷합니다.
- "제목은
<h1>태그로, 본문은<p>태그로 들어가나요?" — 시맨틱 마크업 여부를 확인합니다. - "페이지 속도 점수(PageSpeed)는 몇 점인가요?" — 모바일 기준 점수를 꼭 물어보세요.
- "구글 서치 콘솔에 등록하고 색인 상태를 확인해 주시나요?" — 만들고 끝이 아니라 색인까지 책임지는지 봅니다.
이 다섯 질문에 자신 있게 답하는 개발사라면, 검색을 이해하고 만드는 곳입니다.
직접 확인하는 간단한 방법도 있습니다. 크롬에서 페이지를 연 뒤 마우스 우클릭 → "페이지 소스 보기"를 누르세요. 거기서 본문 글이 보이면 검색엔진도 봅니다. 안 보이고 빈 <div>만 가득하다면, 그 페이지는 색인에 불리한 구조입니다. 기술 SEO의 기초 점검법은 기술 SEO 기초에 정리해 두었습니다.
자주 묻는 질문 (FAQ)
리액트나 뷰로 만든 사이트는 무조건 SEO에 나쁜가요?
아닙니다. 리액트·뷰도 SSR(서버 사이드 렌더링)이나 프리렌더링을 적용하면 검색에 충분히 유리합니다. 넥스트(Next.js), 넉스트(Nuxt) 같은 프레임워크가 이걸 지원합니다. 문제는 기술 자체가 아니라 "콘텐츠를 클라이언트에만 의존시키는 설정"입니다. 같은 도구라도 어떻게 설정하느냐가 갈림길입니다.
노코드·저코드 빌더로 만들면 검색이 안 되나요?
빌더마다 다릅니다. 어떤 빌더는 SSR에 가까운 정적 HTML을 출력해 검색에 유리하고, 어떤 빌더는 본문을 전부 자바스크립트로 그려 불리합니다. 빌더를 고르기 전에 "페이지 소스 보기"로 본문이 HTML에 들어가는지 직접 확인하세요. 화려한 기능보다 이 한 가지가 검색 성패를 더 크게 좌우합니다.
이미 CSR로 만들어진 사이트인데, 처음부터 다시 만들어야 하나요?
꼭 그렇지는 않습니다. 프리렌더링을 추가하거나 핵심 페이지만 SSR로 전환하는 방법, 또는 검색이 중요한 콘텐츠 페이지만 정적으로 분리하는 방법이 있습니다. 전면 재구축보다 비용이 훨씬 적게 듭니다. 다만 구조가 복잡하면 리뉴얼이 더 깔끔할 때도 있어서, 현재 상태를 진단한 뒤 판단하는 게 맞습니다.
페이지 소스에 본문이 보이는데도 색인이 안 됩니다. 왜 그런가요?
렌더링 외의 원인일 수 있습니다. robots.txt가 크롤을 막고 있거나, noindex 태그가 들어가 있거나, 사이트맵이 제출되지 않았거나, 콘텐츠 품질이 낮은 경우입니다. 구글 서치 콘솔의 "URL 검사" 도구로 어느 단계에서 막혔는지 확인하면 원인을 좁힐 수 있습니다.
개발사가 "최신 기술이라 SEO에 좋다"고 합니다. 믿어도 되나요?
최신 기술이라는 말과 검색에 유리하다는 말은 별개입니다. 위에 정리한 다섯 가지 질문을 그대로 던져보세요. 구체적으로 답하지 못하고 "최신이라 괜찮다"만 반복한다면, 검색을 검증해본 적이 없을 가능성이 높습니다. 기술 이름이 아니라 색인 결과로 판단하세요.
웹 개발과 SEO는 따로 노는 영역이 아닙니다. 어떤 렌더링 방식으로, 어떤 태그로, 얼마나 가볍게 만드느냐가 검색 노출의 8할을 결정합니다. 디자인이 아무리 예뻐도 검색엔진이 못 읽으면 그 사이트는 어두운 골목에 켜 둔 간판과 같습니다.
지금 우리 사이트 페이지에서 "페이지 소스 보기"를 한번 눌러보세요. 본문 글이 코드 안에 보이지 않는다면, 검색엔진도 그 글을 못 읽고 있다는 뜻입니다. 직접 확인이 어렵거나 구조가 복잡하면, 무료 SEO 진단을 신청해 주세요. 렌더링 방식과 색인 상태를 직접 들여다보고, 어디부터 손대야 할지 구체적으로 알려드립니다.