IT회사에서 일하다 보니, 마케터이면서도 개발에 관한 내용을 꽤 주워듣는 편이다.
사실 개발자만큼 전문적이지 못하지만,
비개발자가 이해할 수 있을정도로 SPA SEO 방법을 정리해보고자 한다.
※ 혹시나 잘못 설명한 부분이 있다면, 꼭꼭 댓글 부탁드립니다❤
- SPA(Single Page Application) 란?
- SPA SEO 문제 발생 이유
- SPA SEO 방법 3가지
- History API
- Server Side Rendering
- Pre-Rendering
1. SPA(Single Page Application) 란?
SPA는 Single Page Application, 단일 페이지 애플리케이션이라고 풀어서 설명할 수 있다.
말 그대로 하나의 페이지에서 동적으로 데이터를 불러오는 것이다.
쉽게 설명해보자면, 기존 웹페이지와 SPA의 로딩 방식을 보면 이해할 수 있다.
기존 웹페이지는 페이지를 하나씩 불러오는 방식이었다.
예를 들면, 내가 1번 게시물에서 2번 게시물로 이동할 경우
2번 게시물에 있는 웹 요소를 서버에 모두 요청해서 다시 받아오는 방식이었다.
(1번 게시물과 2번 게시물이 80% 정도 비슷하다고 해도!)
하지만, SPA는 1번 게시물에서 2번 게시물을 요청하는 경우
필요한 부분만 서버에서 받아와 로딩해주는 방식이다.
그래서, 더욱 빠른 로딩이 가능하며 사용자 경험도 더 좋다고 한다.
비개발자분들이 이 개념을 쉽게 이해하기 위해서는 모바일 애플리케이션을 생각해보면 좋을 것 같다.
모바일 애플리케이션도 웹을 기반으로 하는 애플리케이션이 있고, 네이티브 애플리케이션이 있다.
예를 들면, 우리가 흔히 사용하는 네이버 앱 > 뉴스 페이지 영역은 웹 기반이다.
그렇기 때문에 페이지를 다시 로딩할 때마다 화면이 깜빡 거리는 현상을 볼 수 있다. (다시 로딩되는 중!)
하지만, 네이티브 앱을 사용해보면 화면 깜빡임 없이 로딩되는 걸 볼 수 있다.
(카카오톡 같은 앱은 탭을 이동해도 깜빡이지 않음)
2. SPA SEO문제 발생 이유
그러면 이 좋은 SPA의 문제점은 무엇일까?
사실 앱으로 만들면 문제가 되지 않지만 웹사이트를 만들었을 때는 SEO문제가 발생한다.
SEO의 의미가 궁금하신 분은 더보기를 클릭해주세요. 😉
※ SEO : Search Engine Optimization의 약자로 검색엔진 최적화를 뜻한다.
네이버, 구글에 검색했을 때 우리 웹사이트가 잘 나오게 하는 것을 검색엔진 최적화라고 말한다.
문제가 발생하는 이유는 간단하다.
우리 웹사이트가 검색 엔진에 노출되는 방식은 아래와 같은 순서로 색인된다.
1) 검색엔진 로봇이 사이트를 돌아다닌다. (혹은 우리가 제출한 URL을 타고 들어올 수도 있음)
2) 사이트의 웹문서 파일을 읽는다. (주로 HTML 코드 파일)
3) 읽은 파일 내용을 토대로 검색 엔진에 노출시켜준다.
웹페이지가 각각 100개씩 있는 페이지는 검색 봇이 페이지를 읽을 수 있다.
하지만, 페이지는 1개이고 필요한 부분만 JavaScript로 바꿔준다면?
검색봇이 페이지를 읽을 수 없게 된다.
(주요 포털 중 구글은 JavaScript를 읽을 수 있다고 했지만,
이 또한 봇 할당량이 높아져서 비추천하며 다른 검색엔진은 Java Script를 읽을 수 없다..!)
3. SPA SEO 방법 3가지
1) SSR (Server Side Rendering)
렌더링이 이란 화면을 그려내는 것이라고 이해하면 된다.
포토샵이나 영상 작업을 해보신 분들은 저장할 때 Rendering... 이렇게 뜨는 걸 보셨을 텐데,
웹이니까 웹페이지를 그려낸다라고 보는 게 이해하기 쉬울 것 같다.
무튼 SSR은 서버사이드 렌더링의 줄임말이며, 서버 측에서 렌더링을 한다라는 뜻이다.
서버측에서 렌더링을 한다는 얘기는 서버측에서 화면을 그려준다! 라고 이해하면 된다.
(그렇기 때문에, 화면을 그릴 때마다 서버에 요청을 해야 하고 깜빡임 현상이 일어나게 된다.)
SSR 방식으로 웹페이지가 화면에 로딩되는 방식은 아래와 같다.
1. 서버에서 렌더링 해서 보내주면 브라우저에서 화면을 뿌려준다. (사용자가 화면을 볼 수 있는 상태가 됨)
2. 동적인 요소 (Java Script)를 실행할 수 있도록 다운로드한다.
3. 브라우저가 동적인 요소를 실행할 수 있도록 화면을 구성한다. (사용자의 요청에 응답할 수 있음)
즉 SSR방식은 서버에서 구조적이 부분만 빠르게 가져와서 보여준다.
그렇기 때문에 초기 로딩 속도가 빠르다는 장점이 있으며,
화면에 뿌려주는 저 순간에 검색 봇이 화면을 읽을 수 있기 때문에 SEO도 원활하게 진행할 수 있다.
SPA는 주로 CSR(Client Side Rendering) 방식으로 구현되는데,
CSR은 반대로 모든 요소를 다 받아와서 화면을 그려낸다.
그리고, 사용자가 요청할 경우 필요한 내용만 서버에 요청해서 빠르게 화면을 그려낸다.
그렇기 때문에 초기 로딩 속도는 조금 느리지만, (앱 구동할 때 느린 것과 마찬가지라고 보시면 될 듯!)
구동 후 웹페이지보다 훨씬 빠르게 동작하는 것을 알 수 있다.
보통 SPA를 SSR 방식으로 구현하면, SEO가 원활하다고 하기 때문에 적용 방법 중 하나로 제시가 된다.
그런데 내가 알기로는 CSR 방식으로 구현된 SPA를 SSR로 다시 변경하는 건 매우 어렵다고 한다...!
그래서, SPA 웹사이트가 완성된 후에 이 방식을 변경하는 건 무리가 있다고 판단하고 있다.
물론 SPA 웹사이트를 만들기 전이라면, SSR 방식을 활용하는 것도 좋은 대안이 될 수 있다.
SSR방식으로 개발할 수도 있지만,
SSR방식을 지원하는 프레임워크를 사용해도 된다. (React의 Next.js / Vue의 Nuxt가 있다고 알고 있습니다.)
마케터나 기획자라면, 초반에 개발자들에게 요 부분을 꼭 제시해보도록 하자!
2) Pre-Rendering
Pre-Rendering은 사전 렌더링이라고도 부른다.
아마 SPA가 완성된 후에 적용할 수 있는 거의 유일한 방법이 아닐까 싶다..!
Pre-Rendering은 서버에서 실제 사람인지 아니면 검색 봇인지 판단해서,
검색 봇에게는 검색 봇이 읽을 수 있도록 렌더링 된 페이지를 전달해주는 것이다.
(※ 각 포털 사이트의 User Agent 값을 추가해주면 검색 봇을 선별할 수 있다.)
사전 렌더링 방식은 플러그인이나 라이브러리가 굉장히 다양하다.
react-helmet, prerender-spa-plugin, prerender.io, puppeteer, rendertron 등...!
방법에 난이도도 다르고, 정적/동적 라우팅을 설정할 수 있는 게 차이점인 것 같다.
정적/동적 라우팅 의미가 궁금하신 분은 더보기를 클릭해주세요. 😉
※ 정적/동적 라우팅이란
라우팅은 경로를 지정해주는 것을 이야기하는데,
정적 = URL이 고정되어있는 것을 이야기한다.
(사용자가 어떤 URL에 접속할지 사전에 리스트를 미리 가지고 있다면, 정적 라우팅 사용 가능!)
동적 = URL이 변할 수 있는 것을 이야기한다.
(쉽게 말해 블로그의 경우 blog/1, blog/2처럼 글 쓸 때마다 URL이 생성된다. 이건 동적 라우팅을 사용해야 한다)
동적, 정적 라우팅 중 당연히 정적 라우팅 구현이 훨씬 쉬운 것 같다.
요건 구현 방안이 다양해서 개발자와 상의하며 구현해보는 것이 좋을 것 같다.
3) History API
구글 자바스크립트 검색 엔진 최적화 문서를 보면 이런 말이 있다.
| 클라이언트 측 라우팅 방식을 사용하는 단일 페이지 애플리케이션의 경우 History API를 사용하여 웹 앱의 다양한 보기 간 라우팅을 구현합니다. |
이게 무슨 말인지 다시 풀어보면,
클라이언트 측 라우팅 방식 (CSR, Client Side Rendering)을 사용하는 SPA(Single Page Application) 페이지의 경우,
History API를 사용하여 보기 간의 라우팅(경로 지정)을 해야 한다는 이야기다.
즉, CSR 방식의 SPA는 하나의 페이지에서 동적으로 요소를 호출해오기 때문에, URL이 바뀌지 않는다는 단점이 있다.
그래서 검색 봇은 경로를 읽을 수 없다.
쉽게 예를 들면, 검색봇은 URL이라는 지도를 보고 경로를 탐색한다.
가게 위치가 1,2,3이라고 지정되어있기 때문에 봇은 이 지도를 읽고
우리 웹사이트에는 총 100개의 가게가 존재한다고 확인할 수 있다.
하지만, SPA는 하나의 주소에 여러 가지 요소가 변화하는 백화점 같은 곳이다.
검색 봇은 백화점 위치만 보고 한 개의 건물이라고 생각하지만,
백화점 안에는 주소는 같지만 엄청 여러 개의 가게가 있는 것과 동일하다.
그래서, 경로를 지정해주고 봇이 페이지를 읽을 수 있도록 하기 위해 HTML5의 History API 사용을 권장한다.
HTML5의 History API를 사용하면 이전, 이후 URL 경로를 만들어줄 수 있기 때문이다.
History API는 깜빡임 없이 페이지를 로딩하면서, URL이 바뀌게 설정할 수 있다.
단점은 History API는 인터넷 익스플로러 10 이하 버전에서는 지원 안 한다는 것이다.
우리나라는 아직 IE 사용비율이 꽤 있기 때문에...
이 부분은 기획자, 마케터가 고려해야 할 부분인 것 같다.
※ 참고 :
History API - MDN Web Docs
Google - 자바스크립트 검색엔진 최적화 기본 사항 이해하기
Google - 동적 렌더링 구현
마치며,
이 글을 쓰게 된 이유는 두 가지였다.
첫 번째는 비개발자가 알기 쉽게 정리된 글이 별로 없었다.
글을 읽다 보면 렌더링이 뭔지, 라우팅이 뭔지 개념을 찾아봐야 하는 게 너무 어려웠다.
그리고, 한글로 명쾌하게 SEO방식을 정리한 내용이 없어서 너무 아쉬웠다.
두 번째는 검증을 위해서다.
사실 내가 개발자가 아니고 개발 관련 용어나 프로세스를 100% 이해하지 못한다.
여기저기 돌아다니며, 내가 이해한 내용을 정리했지만 잘못 이해한 내용이 있을 수 있다.
그래서, 이런 부분이 있다면 바로 잡고 싶어서 글을 쓰게 되었다.
모든 마케터, 기획자 분들에게 도움이 되길 바라는 마음으로 글을 마칩니다.
잘못된 내용이 있다면, 말씀해주세요!
지속적으로 업데이트하겠습니다. 😉
'마케팅 > 이슈 및 트렌드' 카테고리의 다른 글
| 네이버 PC 검색 화면 개편 변경 사항 총정리 (0) | 2020.11.07 |
|---|---|
| 소비자 구매 경로 AIDMA와 AISAS의 차이점! (0) | 2020.10.26 |
댓글