SPA 웹사이트 SEO, 개발팀에게 어떻게 요청해야 할까?

“저희 웹사이트가 Vue 기반 SPA인데요, SEO 최적화는 어떻게 하면 좋을까요?”

얼마 전 한 B2B 기업 마케터분께서 이런 질문을 주셨습니다. 디자인도 깔끔하고, 페이지 전환도 빠르고 부드러운데 정작 검색엔진에서는 웹사이트를 제대로 읽지 못하는 상황이었죠. 알고 보니 Vue로 만든 SPA(Single Page Application) 방식이었고, SEO 대응이 빠진 채로 서비스 중이었던 겁니다.

SPA는 빠르고 부드러운 사용자 경험을 제공하지만, 검색엔진 최적화 측면에서는 별도의 기술적 대응이 필요합니다. 문제는 이 부분이 기획 단계에서 자주 누락된다는 점이에요. 마케터 입장에서는 “검색 노출이 안 된다”는 결과만 보이지만, 개발팀에게 구체적으로 무엇을 요청해야 할지 막막한 경우가 많습니다. 오늘은 비개발자도 이해할 수 있는 SPA SEO 해결 방법과, 개발팀과의 협업을 위해 알아야 할 핵심 내용을 정리해드리겠습니다.

우리 웹사이트가 SPA인지 확인하는 방법

SPA란 무엇인가요?

먼저 SPA가 정확히 무엇인지 알아볼까요? SPA(Single Page Application)는 말 그대로 ‘단일 페이지 애플리케이션’입니다. 기존 웹사이트는 페이지를 이동할 때마다 서버에서 새로운 HTML 파일을 받아오는 방식이었어요. 하지만 SPA는 처음 접속할 때 한 번만 HTML을 받아오고, 이후에는 자바스크립트가 필요한 부분만 바꿔가며 화면을 그립니다. 그래서 SPA는 페이지 전환이 훨씬 빠르고 부드럽죠. 기존 웹사이트는 페이지를 이동할 때마다 화면이 깜빡이며 새로고침되는데, SPA는 이미 받아온 자바스크립트가 필요한 부분만 교체하기 때문에 새로고침 없이 매끄럽게 전환됩니다. 마치 앱처럼 느껴지는 이유가 바로 이 때문입니다. React, Vue, Angular 같은 프레임워크로 만든 웹사이트가 대부분 SPA 방식이에요.

비개발자도 할 수 있는 SPA 확인법

그럼 우리 웹사이트가 SPA인지 어떻게 확인할 수 있을까요? 비개발자도 쉽게 체크할 수 있는 방법이 있습니다. 크롬 브라우저에서 웹사이트에 접속한 후, F12 키를 눌러 개발자 도구를 열어보세요. 그 다음 상단의 ‘Sources’ 탭 > 왼쪽의 ‘Page’ 탭을 차례로 클릭합니다. 이 상태에서 웹사이트 내의 다른 페이지로 이동하는 메뉴를 클릭해보세요. 만약 페이지를 이동할 때마다 ‘Page’ 탭의 리소스 목록이 새로고침되면서 다시 로딩된다면, 그건 일반 웹사이트(MPA)입니다. 하지만 페이지는 바뀌는데 ‘Page’ 탭의 리소스가 그대로 유지되고 새로고침되지 않는다면, 그건 SPA예요. URL은 바뀌지만 실제로는 자바스크립트가 화면 일부만 교체하는 방식이기 때문이죠.

좀 더 간단한 방법도 있어요. 웹사이트에 접속한 상태에서 ‘마우스 우클릭 후 ‘페이지 소스 보기’를 선택해보세요. 화면에 보이는 텍스트나 콘텐츠가 소스 코드에도 그대로 보이나요? 만약 <div id=”app”></div> 같은 텅 빈 구조만 보이고 실제 콘텐츠는 보이지 않는다면, 그것도 SPA일 가능성이 높습니다.

확실하게 확인하려면 개발팀에게 직접 물어보는 게 가장 정확합니다. 이때 “우리 웹사이트 React, Vue, Angular 중에 뭐로 만들었나요?”라고 물어보세요. 이 세 가지 중 하나라는 답이 돌아온다면 SPA일 확률이 매우 높습니다. 추가로 “SSR이나 SSG가 적용되어 있나요?”라고 물어보는 것도 좋아요. 만약 “아니요, 그냥 CSR(클라이언트 사이드 렌더링)입니다”라는 답이 나온다면, SEO를 위한 별도 작업이 필요한 상황입니다. 이 질문들만으로도 개발팀과의 대화에서 현재 상황을 파악할 수 있는 단서를 얻을 수 있습니다.

왜 SPA는 SEO에 불리한가요?

SPA가 SEO에 불리한 이유를 이해하려면, 검색엔진이 웹사이트를 어떻게 읽는지 알아야 합니다. 구글이나 네이버 같은 검색엔진은 크롤러(봇)를 보내서 웹사이트의 HTML 코드를 수집하고 분석합니다. 일반 웹사이트는 서버에서 완성된 HTML을 바로 보내주기 때문에 크롤러가 콘텐츠를 쉽게 읽을 수 있어요. 하지만 SPA는 처음에 거의 빈 HTML만 보내주고, 나머지 콘텐츠는 사용자의 브라우저에서 자바스크립트로 그려냅니다. 문제는 검색엔진 크롤러가 자바스크립트를 완벽하게 실행하지 못하거나, 실행하더라도 시간이 오래 걸린다는 점이에요. 결국 크롤러 입장에서는 “어? 이 페이지에 내용이 없네?”라고 판단하게 되는 겁니다.

실제로 SPA 환경에서 발생하는 문제들을 보면 더 명확합니다. 먼저 검색 결과에 아예 노출되지 않거나, 노출되더라도 제목과 설명이 제대로 표시되지 않습니다. SPA는 페이지 소스에 메타태그가 비어있는 경우가 많아서, 검색엔진이 뭘 기준으로 검색 결과를 만들어야 할지 모르는 거죠. 또 카카오톡이나 페이스북에 링크를 공유했을 때 썸네일 이미지나 설명이 안 뜨는 경우도 많습니다. 이것도 같은 이유예요. 또 다른 문제는 SPA는 페이지가 여러 개인 것처럼 보여도 실제로는 하나의 HTML에서 동작하기 때문에, 각 페이지를 독립적으로 검색엔진에 등록하기가 어렵다는 점입니다. B2B 웹사이트에서 제품 소개 페이지, 고객 사례 페이지가 각각 검색되어야 하는 경우들이 있는데, 검색엔진은 이걸 하나의 페이지로만 인식하는 거죠.

SPA SEO 해결 방법, 개발팀에게 뭐라고 요청해야 할까?

SPA의 SEO 문제를 해결하는 방법은 크게 세 가지입니다. SSR(Server-Side Rendering, 서버 사이드 렌더링), SSG(Static Site Generation, 정적 사이트 생성), 동적 렌더링(Dynamic Rendering)이에요. 각각의 방식이 어떻게 작동하고, 어떤 장단점이 있는지 마케터 관점에서 살펴볼게요.

SSR(서버 사이드 렌더링)

SSR은 사용자가 페이지를 요청할 때마다 서버에서 HTML을 완성해서 보내주는 방식입니다. 일반적인 SPA는 빈 HTML 껍데기만 보내고 브라우저에서 자바스크립트로 콘텐츠를 채우는 방식이라면, SSR은 서버가 먼저 모든 콘텐츠를 HTML에 담아서 보내주는 거예요. 예를 들어 사용자가 상품 페이지를 클릭하면, 서버가 그 순간 데이터베이스에서 상품 정보를 가져와 HTML로 완성한 뒤 사용자에게 전달합니다. 검색엔진 크롤러가 방문했을 때도 똑같이 완성된 HTML을 받기 때문에, 빈 페이지가 아닌 실제 콘텐츠를 제대로 읽을 수 있는 거죠.

SSR은 가장 확실한 SEO 효과를 줍니다. 모든 페이지가 서버에서 렌더링되기 때문에 검색엔진이 완벽하게 읽을 수 있고, 사용자 경험도 SPA의 장점을 그대로 유지할 수 있어요. 첫 페이지는 서버에서 완성된 HTML로 빠르게 보여주고, 이후 페이지 이동은 SPA처럼 부드럽게 작동하는 방식입니다. 다만 매 요청마다 서버가 HTML을 만들어야 하기 때문에 서버 부하가 커지고, 개발 난이도와 비용이 가장 높습니다. 기존 SPA 코드를 상당 부분 수정해야 하고, 서버 인프라도 추가로 구축해야 하기 때문에 시간과 리소스가 많이 필요해요. 하지만 Next.js(React), Nuxt.js(Vue), Angular Universal(Angular) 같은 프레임워크를 활용하면 처음부터 모든 걸 개발하는 것보다 비교적 수월하게 도입할 수 있습니다. 이 프레임워크들은 SSR을 위한 구조와 도구를 이미 제공하고 있어서, 개발팀에게 “해당 프레임워크를 활용해서 SSR을 적용할 수 있을까요?”라고 요청해보시는 것도 방법입니다.

SSG(정적 사이트 생성)

SSG는 웹사이트를 빌드(제작)하는 시점에 모든 페이지를 미리 HTML 파일로 만들어두는 방식이에요. 일반 SPA가 사용자가 접속할 때마다 자바스크립트로 페이지를 그린다면, SSG는 웹사이트를 만드는 단계에서 아예 모든 페이지를 완성된 HTML 파일로 생성해둡니다. 예를 들어 블로그 글 100개가 있다면, 사이트를 만들 때 100개의 HTML 파일을 미리 생성해두는 겁니다. 그래서 사용자나 검색엔진 크롤러가 방문하면 이미 완성된 HTML을 바로 보여주기만 하면 돼요.

SSG는 SPA 환경에서도 속도가 빠르고 SEO 효과도 좋습니다. 서버가 매번 HTML을 만들 필요 없이 이미 만들어진 파일을 보여주기만 하면 되니까, 로딩 속도가 매우 빠르고 서버 부하도 적습니다. 검색엔진도 완성된 HTML을 바로 읽을 수 있어서 SEO 효과도 확실하죠. 하지만 콘텐츠가 자주 바뀌는 서비스에는 적합하지 않아요. 블로그나 회사 소개 같은 정적인 페이지에는 최고의 선택이지만, 실시간으로 변하는 가격 정보나 재고 현황 같은 데이터를 보여줘야 하는 페이지에는 어울리지 않습니다.

동적 렌더링(프리렌더링)

동적 렌더링은 방문자가 사람인지 검색엔진 봇인지 구분해서 다른 HTML을 보여주는 방식입니다. 일반 사용자에게는 기존 SPA를 그대로 보여주고, 구글봇이나 네이버봇 같은 크롤러에게만 완성된 HTML을 따로 제공하는 거죠. 구체적으로는 서버나 중간 프록시(Nginx 같은)가 방문자의 User-Agent(접속자 정보)를 체크합니다. 만약 ‘googlebot’, ‘naverbot’ 같은 검색엔진 크롤러로 확인되면, Puppeteer 같은 헤드리스 브라우저가 SPA를 실제로 실행해서 완성된 HTML을 만들어 제공해요. 일반 사용자라면 기존 SPA를 그대로 보여주고요.

동적 렌더링은 SPA 구조를 유지하면서 가장 빠르게 적용할 수 있고 기존 코드 수정이 거의 없다는 장점이 있습니다. 자체적으로 Puppeteer 기반 프리렌더 서버를 구축하거나, Prerender.io 같은 상용 서비스를 활용하면 별도의 서버가 크롤러 요청을 감지해서 자동으로 HTML을 생성해줍니다. 개발 기간도 짧고 비용도 SSR보다 저렴해서 단기간에 SEO 문제를 해결하고 싶을 때 효과적입니다.

하지만 한계도 분명합니다. 먼저 구글이 공식적으로 권장하는 방법은 아니에요. 구글은 2022년 이후 동적 렌더링을 “최후의 수단으로만 사용할 임시 우회책”이라고 가이드를 수정했습니다. 또 User-Agent로 봇을 구분하는 방식이기 때문에, 새로운 검색엔진 크롤러가 나타나면 목록을 계속 업데이트해야 하는 관리 부담이 있어요. 무엇보다 검색엔진에 제공하는 HTML과 실제 사용자에게 보여주는 내용이 다르면 클로킹(cloaking)으로 오인될 수 있습니다. 이 경우 구글 가이드라인 위반으로 검색에서 불이익을 받을 수 있어요. 그래서 동적 렌더링은 임시방편으로는 괜찮지만, 장기적으로는 SSR이나 SSG로 전환하는 게 좋습니다.

우리 회사에는 어떤 방법이 맞을까?

그렇다면 우리 회사에는 어떤 방법이 맞을까요? 개발 리소스와 예산이 충분하고, 장기적인 SEO 전략을 세우고 있다면 SSR을 추천합니다. Next.js(React), Nuxt.js(Vue), Angular Universal(Angular) 같은 프레임워크를 도입하면 SSR을 비교적 수월하게 적용할 수 있어요. 콘텐츠 업데이트가 자주 없는 페이지가 많다면 SSG를 고려해보세요. 회사 소개, 서비스 안내, 블로그 같은 페이지는 SSG로 만들고, 실시간 데이터가 필요한 부분만 따로 처리하는 하이브리드 방식도 가능합니다. 당장 예산과 시간이 부족하다면 동적 렌더링을 임시 해결책으로 사용할 수 있어요.

SPA 환경에서 당장 할 수 있는 것들

모든 페이지를 한 번에 개선하려고 하면 시간도 오래 걸리고 우선순위도 흐려집니다. 우선 SEO가 가장 중요한 핵심 페이지부터 선정해보세요. 예를 들어 제품 소개 페이지, 주요 서비스 페이지, 고객 사례 페이지처럼 검색 유입이 많거나 전환율이 높은 페이지 5~10개 정도를 먼저 리스트업하는 거예요. 개발팀에게 “이 핵심 페이지부터 SSR을 적용할 수 있을까요?”라고 제안하면 훨씬 현실적인 대화가 가능합니다. 또 각 페이지별로 타겟 키워드와 메타 정보(제목, 설명)를 미리 정리해보세요. 개발 작업이 완료된 후 바로 적용할 수 있도록 준비해두면, SEO 효과를 더 빠르게 볼 수 있습니다.

SPA 웹사이트의 SEO는 마케터 혼자 해결할 수 없는 영역입니다. 개발팀과의 협업이 필수적이고, 서로 다른 관점과 언어를 이해하는 과정이 필요해요. 중요한 건 “검색 노출 좀 되게 해주세요”라는 막연한 요청이 아니라, 구체적인 SEO 해결 방법과 우선순위를 함께 논의하는 것입니다. SSR, SSG, 동적 렌더링 중 무엇을 선택할지는 우리 회사의 리소스와 서비스 특성에 따라 달라집니다. 전체를 한 번에 바꾸려 하지 말고, 핵심 페이지부터 단계적으로 개선해보세요. 오늘 정리한 질문들과 개념들을 가지고 개발팀과 이야기를 시작해보시면 훨씬 생산적인 논의가 가능할 거예요!