by 남성필 에어브릿지 대표
남성필 대표가 에어브릿지 블로그에 게재한 글을 편집한 뒤 모비인사이드에서 한 번 더 소개합니다.
지난 번 글을 통해 SEO에 영향을 미치는 요인들을 3가지 포인트로 나눠서 살펴보았습니다. 이 3가지의 포인트를 중심으로 실제 SEO를 아래의 가이드에 따라 단계별로 진행할 수 있습니다.
* 주의 : 이 가이드는 철저히 주관적인 관점에서 서술되었으므로, 구글에서 제시하는 공식 가이드를 참조하고 싶으신 분은 구글의 개발자 체크리스트를 참조해주시기 바랍니다.
단계 0 : SEO를 위한 최소한의 준비
성공적인 SEO를 위해 갖춰야 할 두 가지 준비사항이 있습니다. 이 준비사항에 해당하지 않는 분들은 넘어가주셔도 좋지만, 모바일 웹사이트를 지원하지 않거나 싱글 페이지 어플리케이션(SPA)를 지원하시는 분들은 반드시 아래의 사항을 확인해야 합니다.
- Mobile-Friendly Test를 통한 모바일 웹사이트 지원여부
- 서버사이드(Server-side Rendering) 랜더링 지원여부
우선 모바일 웹사이트는 흔히들 m.을 서브도메인으로 붙여서 별도로 제공하거나 반응형 웹사이트를css media query 등으로 제공하는 방법이 있습니다. 어떤 방법을 통해서든 사용자가 보기 편한 모바일 웹사이트를 지원하는 것이 중요합니다. 구글에서 제공하는 Mobile-Friendly Test를 통해 지원여부를 알아보세요.
두 번째로 서버사이드 랜더링은 서버에서 HTML, CSS, JavaScript로 구성된 웹문서를 “완성”해서 뿌려주는 것을 뜻합니다. 이는 과거에는 당연하게 여겨졌으나, 최근에 AngularJS, ReactJS, MeteorJS 등 SPA(Single Page Application) 기술이 유행하고 있는 상황에서 언급하지 않을 수 없는 얘기입니다. 이러한 기술들의 문제는 각 주소마다 따로 웹문서를 내려주는 것이 아니라, 일단 하나의 웹문서 전체를 내려주고, 그 안에서 가상으로 라우팅을 한다는 것과 사이트 내의 콘텐츠를 웹문서가 다 DOM에 로딩되고 난 후 비동기적으로 불러온다는 것입니다.
따라서 구글 크롤러가 웹사이트를 방문했을 때는 실제 콘텐츠들이 로딩되지 않은 상태의 사실상 거의 비어있는 웹문서만을 볼 수 있게 되고, 대부분 처음 로딩되는 랜딩페이지 하나만 참조할 수 있게 됩니다.
이 문제를 해결하기 위해 각 기술 진영에서는 해결책을 내놓고 있습니다. 다만, 그 해결책들은 서버사이드 랜더링을 제공하지 않는 경우 미봉책에 지나지 않는다는 것이 문제입니다. 따라서 구글 SEO를 위해서는 구글 봇에게 따로 서버사이드 랜더링을 시켜주는 것이 필요합니다.
이 문제를 해결해주기 위한 상업 솔루션도 존재하고 있습니다. 그리고 아래와 같이 비교적 각 진영별로 유명한 해결책들이 존재하고 있습니다.
- AngularJS : 기트허브 saymedia/angularjs-server 라이브러리
- ReactJS : 서버사이드 랜더링 관련 공식 문서 / 실제 예시
- MeteorJS : PhantomJS를 사용한 Spiderable 패키지
- 내가 직접 서버사이드 랜더링 구축하기 : User-Agent를 분석하여 구글 크롤러 방문 시 서버에서 랜더링된 페이지 직접 반환 (웹프레임웍스 사이트의 이재호님의 글 참고)
단계 1 : SEO를 위한 KPI 설정하기
KPI를 설정하는 것은 어떤 프로젝트에 있어서나 중요합니다. KPI 설정을 통해서야 정확히 성과를 측정하고, 어떻게 개선되는지를 수시로 확인하면서 프로젝트의 방향성과 세부 시행 계획들을 점검할 수 있기 때문입니다.
구글 SEO를 위해서는 크게 4가지의 정량적인 지표가 있다고 볼 것입니다.
- “site:” 오퍼레이터를 통한 색인된 사이트의 갯수 확인: 사이트맵 등록 이후에, SEO 프로젝트 이후에 얼마나 인덱싱된 페이지의 숫자가 늘어나는지를 확인할 수 있습니다.
- PageSpeed Insights를 통한 사이트의 경량화 지표 확인
- 구글봇(크롤러)의 사이트 방문주기 로그 수집을 통해서 분석 및 확인
- 중요한 키워드 선정 후 주기적으로 검색 후 랭킹 확인
위에서 보다시피 site:{자신의 사이트 주소}를 구글 검색창에 검색해 얼마만큼 초반에 사이트가 인덱싱되고 있는지를 숫자로 확인할 수 있습니다. 페이스북의 경우에는 약 약 45억 개의 사이트가 인덱싱되어있는 것을 볼 수 있습니다. 반면에, 저희 사이트의 경우 약 10만 개의 사이트가 인덱싱되어있는 것을 볼 수 있습니다.
이 지표는 웹마스터 툴 등록과 사이트맵 제출 이후에 자연스럽게 늘어나게 되므로 현재 상황을 확인하는 차원에서 몇 번 보고, 웹마스터툴 등록하고 사이트맵 제출 이후에서부터 증가 추세를 보는데 활용하면 좋습니다. (페이스북 색인된 사이트 갯수 확인)
또한 PageSpeed Insights는 사이트의 경량화 지수와 경량화를 위한 구글의 조언을 알려줍니다. 점수를 100점에 가깝게 올리는 노력을 통해서 사이트가 경량화되고 있는지를 파악할 수 있습니다. 사이트가 얼마나 가벼운지도 SEO의 요인 중 하나일뿐만 아니라, 사실은 사이트의 크기가 사이트의 로딩 속도와 연관이 되어있다는 점이 더욱 중요합니다.
많은 사용자들은 페이지 로딩이 길어지면 짜증을 내면서 “뒤로가기(Backspace)” 버튼을 눌러버립니다. 이렇게 사이트 로딩 전 이탈하는 사용자들은 클릭률과 페이지 사용시간에 큰 악영향을 미치고, 궁극적으로 사이트의 신뢰도를 저하시킬 수 있습니다.
마지막으로 구글 크롤러의 방문주기는 구글이 신뢰하고, 더 가치있다고 생각하는 웹사이트일수록 더욱 짧아집니다. 예를 들어 BBC와 같이 경각을 달리하는 뉴스를 올리는 신뢰성 높은 웹사이트는 정말 몇 초, 몇 분만에 계속 구글 크롤러가 방문하여서 최신 기사들을 인덱싱해 갈 것입니다. 반면에 변화도 적고, 신뢰할 수도 없는 사이트들은 구글 크롤러들이 몇 주, 몇 달에 한 번씩 올 수도 있습니다.
ELK스텍이나 NEW RELIC과 같이 자체 로그분석 시스템을 가지고 계신 분들은 주기를 확인할 수 있으며, 그 주기가 얼마나 짧아지는지, 한 번 왔을 때 얼마나 읽어가는 지 등 데이터 분석을 통해 SEO KPI를 설정할 수 있습니다.
이외에도 반드시 정량적이라고 할 수는 없겠으나, 내가 중요하다고 생각한 키워드를 정해놓고 그 키워드들에 대해서 랭킹을 체크하는 것도 정량적으로 확인하는 좋은 방법입니다. 이 때 반드시 구글의 애드워즈 서비스를 사용하여 그 키워드가 실제로 검색이 많이 일어나는 키워드인지를 확인하는 것이 중요합니다. 왜냐하면 검색이 제대로 일어나지도 않는 엉뚱한 키워드의 랭킹을 트래킹하다가 아까운 시간과 비용을 낭비하는 수가 있기 때문입니다.
위에서 보듯이 구글 애드워즈에서는 어떤 키워드가 유의미한 검색량을 만들어내는지 알려주므로, 미리 확인하고 매번 랭킹을 확인할 키워드를 정하는 것이 좋겠습니다.
단계 2 : 제목과 설명, 대표 이미지 정하고, 기초 메타 태그로 나타내기
우선 제목을 잘 정하는 것이 중요합니다. 클릭률에 가장 핵심적인 영향을 미치는 것은 바로 제목입니다.
제목은 그 자체로 전달하고자 하는 주제의 내용을 잘 요약하고 있어야 하며, 증거 키워드(Proof Terms)가 포함되는 것이 좋습니다. 증거 키워드는 어떤 주제에 대해서 논할 때 그 키워드 자체만으로도 웹문서의 내용에 대해서 유추할 수 있게끔 해주는 증거가 되는 키워드입니다.
예를 들어 “서울 떡볶이 맛집 베스트 10 소개”을 제목으로 가진 웹문서라고 한다면, 여기서 증거 키워드는 “베스트”, “10”, “소개”같은 키워드들이 됩니다. 따라서 사용자는 이것만 보고도 이 웹문서의 작성 의도와 내용을 유추할 수 있습니다.
둘째로 웹사이트의 본문 내용이 중요합니다. 본문 내용은 제목과 연관되어야 할 뿐만 아니라 반드시 웹사이트의 제목과 연관된 키워드들(Relevant Terms)이 포함되어 있어야 합니다. 연관 키워드들은 어떤 주제에 대해서 논할 때 그 주제와 관련해서 나올 수 있는 여러 단어들입니다.
예를 들어 “서울 떡볶이 맛집 베스트 10 소개”을 제목으로 가진 웹문서라고 한다면, 여기서 연관 키워드는 떡볶이나 맛집과 관련된 “떡”, “사리”, “맛”, “매운”, 가격”, “친절”, “평점”, “리뷰”과 같은 키워들이 될 것입니다.
제목과 본문의 내용이 너무 동떨어져 있으면 문제가 될 수 있습니다.구글은 자사의 광고 플랫폼인 애드워즈에서 광고 문구와 그 문구가 가리키는 웹사이트 내의 내용이 일치해야지만 품질지수(Quality Score)을 올려주고, 광고단가를 절감해줍니다. 이와 같은 품질지수 알고리즘은 SEO 랭킹에도 반영될 것으로 추측됩니다.
마지막으로 제목, 설명, 대표 이미지는 따로 메타 정보로 분류되며 웹문서의 head섹션에 들어갈 수 있으며, 주요 메타 태그들은 아래와 같습니다. 아래에 나와있는 메타 정보들은 검색엔진의 크롤러가 해당 사이트의 정보에 대해서 더욱 체계적으로 파악할 수 있도록 돕는 역할을 하고 있습니다.
(한편 절대로 같은 제목, 설명, 대표 이미지를 반복해서 사용해서는 안됩니다.)
- title 태그 :
<title>웹문서의 제목이 들어갑니다.</title> - 기본 메타 태그 : 각종 메타 태그 참조
- 오픈그래프 태그 : 오픈그래프 개발자 문서 참조 | 에어브릿지 블로그 내 오픈그래프 글 참조
- 트위터 카드 : 트위터 개발자 문서 참조
단계 3 : 사이트 로딩속도 개선하기
사이트의 로딩속도는 가장 중요한 지표인 클릭률, 그리고 랭킹에 반영되는 웹사이트 방문시간 등에 영향을 미치는 중요한 요소입니다. 사이트 로딩속도 개선을 위한 주요 지표와 방법으로는 PageSpeed Insights를 최대한 활용하는 것이 좋습니다.
본 가이드에서는 이에 더하여 크게 백엔드와 프론트엔드 두 가지 측면에서 당장에 활용할 수 있는 간단한 가이드를 제시하고자 합니다.
백엔드, DB까지 가지 말고 메모리단에서 해결해서 로딩 속도를 줄일 수 있습니다.
백엔드에서 가장 많은 부하를 주고, 시간을 소요시키는 것은 복잡한 쿼리문을 DB에 호출하는 작업일 것입니다. 이러한 부하를 줄이고, 더 빨리 메모리단에서 데이터를 불리오기 위해서 보통 메모리단에 데이터를 임시 저장해놓는 기법을 캐싱이라고 합니다.
메모리단에 캐싱을 위해 Memcached와 Redis를 많이 사용하며 AWS의 ElastiCache 등도 최근에 많이 사용하고 있는 추세입니다. 방법은 특정 데이터가 호출되었을 경우 먼저 캐싱이 되어있는 데이터가 있는지 확인하고, 있을 시 그 데이터를 전달, 없을 경우에 DB에서 불러와서 전달 후 해당 데이터를 메모리에 저장하여 다음 번 호출 시 더 빨리 불러올 수 있도록 하는 것입니다. 이 과정에서 쓸데없는 메모리 공간의 낭비가 없도록 HIT RATE를 분석하여, TTL(Time-To-Live, 소멸시효)를 차등하여 걸어두는 보완책이 필요합니다.
이럴 통해 더 빨리 해당 웹문서를 서버에서 클라이언트(브라우저 등)으로 전달할 수 있습니다. 이 방법 외에도 백엔드에서 로딩 속도를 줄이는 다양한 해결책이 존재하고 있습니다. 예컨대 웹서버 중 nginx 캐싱 등을 활용하는 방법 등입니다.
프론트엔드, CDN을 활용하고 이미지 파일 등 용량이 많이 나가는 정적 리소스들의 크기를 줄여서 로딩 속도를 줄일 수 있습니다.
아카마이(Akamai)에 따르면 CDN(Content Delivery Network)은 “전세계 분산 인프라 및 네트워크를 활용하여 원래의 서버(origin)에 있는 데이터, 웹사이트, 멀티미디어, 소프트웨어 등을 인터넷 상에서 가속, 캐싱, 각종 최적화 하여 전달하는 서비스”입니다. 쉽게 말해서 내 서버가 미국에 있는데, 한국에서 많은 사용자들이 우리 서비스에 접속한다고 가정하면 CDN를 통해서 미리 한국에 있는 서버에 웹문서나 이미지 파일 등이 캐싱되어있다가 가장 빠른 속도로 한국에서의 접속자들에게 전달되게끔 “미리 저장해놨다가 대신 전달”하는 서비스입니다.
CDN에는 다양한 옵션들이 있습니다. 위에서 언급한 Akamai나 AWS CloudFront, Google Cloud CDN그리고 CloudFlare 등이 있습니다. CDN는 기존 서비스에도 쉽게 적용할 수 있다는 장점을 가지고 있습니다.
한편 이미지 업로드 할 시 손실 압축하여서 최대한 크기를 줄일 수 있습니다. 가장 대표적으로 큰 이미지를 받아 썸네일화 할 때 이러한 기법이 사용됩니다. 이러한 방법은 AWS 사용자들의 경우 주로 AWS의 S3 => Lambda의 연동을 통해서 이뤄지며 관련 자료는 AWS 공식문서에서 확인할 수 있습니다.
프론트엔드 최적화 작업을 다른 말로 FEO(Front-End Optimisation)라고 하기도 합니다. FEO는 상당히 많은 시간이 소요되는 아주 어려운 작업입니다. 이러한 작업의 번거로움 때문에 아카마이(Akamai)와 같이 이러한 작업을 전문적으로 솔루션화하여 제공하는 외국 업체들도 존재하고 있을 정도 입니다. 따라서 FEO 작업을 할 때에는 신중해야 합니다.
자세한 FEO 기법에 대해서 이 지면을 빌어 얘기하기는 어려운 측면이 있습니다. 특히 HTTP/2가 나오면서 기존의 FEO 기법들이 상당히 일부 도태되었습니다. 더욱 상세한 정보의 경우 아카마이의 관련 자료를 참조해주세요.
또한 구글에서 정적 자원을 가진 페이지를 빨리 랜더링하는 것과 관련된 프로젝트를 진행하고 있습니다. 정말 순수한 콘텐츠 그 자체를 빨리 전달하고자 하는 서비스들은 Accelerated Mobile Pages 프로젝트를 참조해주시길 바랍니다.
단계 4 : 소셜미디어상의 공유 유도를 통해 지속적인 랭킹 상승 및 선순환 꾀하기
소셜미디어에 나의 사이트가 공유되거나 언급될수록 사이트의 랭킹은 높아집니다. 특히 소셜 버즈(Buzz)가 SEO의 3대 요인이므로 아주 중요하다고 할 것입니다.
소셜 버즈를 상승시키는 방법에는 서비스 기획자, 특히 UX 디자이너들이 웹사이트의 콘텐츠가 소셜 미디어에 잘 공유될 수 있도록 사용자 흐름을 설계하는 것이 가장 이상적입니다. 예를 들어 위의 사례는 addthis 버튼을 통해서 저희 에어브릿지 블로그에서 공유를 유도하고 있는 모습입니다.
이러한 공유 시스템을 일일히 개발 작업을 통해서 장착하는 것이 어렵기에, 아래와 같이 웹사이트의 소셜 공유를 쉽게 유도할 수 있는 몇 가지 솔루션들을 소개합니다.
또한 페이스북 코멘트를 통해서 콘텐츠의 바이럴화를 유도하는 것도 좋은 기능입니다. 2015년 3월 페이스북이 출시한 Comment Mirroring이라는 새로운 형태의 코멘트 기능은 페이스북과 특정 웹사이트에서 작성한 코멘트가 페이스북 페이지 양쪽 모두에서 노출되도록 해주고 있습니다. 페이스북 페이지 등을 통하여 새로운 콘텐츠를 지속적으로 사용자들에게 노출하고 있는 업체의 경우 이 기능을 살펴보길 권장합니다. (개발자 문서 보러가기)
단계 5 : 수동으로 각종 사이트에 백링크 걸기
다양한 웹사이트에 수동으로 백링크를 거는 것도 SEO를 위해서 시도해볼만한 유의미한 작업입니다. 사실 이러한 수동적인 방법으로는 확장가능한(scalable) 효과는 볼 수 없습니다. 그럼에도 불구하고 조금의 백링크 효과를 주고, 서비스와 관련된 키워드를 인터넷에 검색하였을 때 관련 지면을 채울 수 있다는 점에서는 유용하다고 할 것입니다.
돈 드는 것이 아니므로 하는 것을 권장합니다. 아래의 사이트들은 회사나 서비스 정보 등록 시 SEO에 조금이라도 도움이 될 수 있는 플랫폼들입니다.
- (국내) Facebook : 두 말할 나위 없는 최고의 SEO 지면 제공
- (국내) 로켓펀치 : 스타트업 및 전문가 프로필 공유 플랫폼 | 생각보다 구글에서 SEO가 잘 되는 사이트
- (국내) 데모데이 : 스타트업 프로필 공유 플랫폼
- (국내) SlideShare : PPT, PDF 공유 플랫폼 | 정말 상당히 SEO 효과가 좋은 사이트 중 하나, 회사와 관련된 소개자료 등을 업로드해놓을 것
- (국내) Youtube : SEO 효과는 떨어지나 동영상 등 있을 시 업로드
- (해외) LinkedIn : 전세계 최대의 전문가 SNS
- (해외) CrunchBase : 전세계 최대의 기업 정보 플랫폼
- (해외) F6S : 스타트업 업계 관련 프로필 공유 및 각종 공모, 행사, 이벤트 지원
- (해외) Angel.co : 상동
단계 6 : 각종 심화 메타정보 노출하기
최근에는 각종 심화된 방법들을 통해서 웹사이트의 메타정보를 노출하는 방법이 각광받고 있습니다.
특히 국내에서는 잘 알려지지 않았으나, 해외에서는 상당히 많이 사용하고 있는 메타정보 표기법들을 알려드립니다. 어느 정도 수준에 이르른 콘텐츠를 보유한 업체들은 반드시 아래의 메타정보를 노출하길 권장합니다.
페이스북의 Applinks와 구글의 link 태그를 통해 앱 내 콘텐츠를 검색에 노출하기를 권장합니다.
Applinks 태그는 2014년 페이스북 개발자 컨퍼런스인 F8에서 처음 발표된 딥링크 표기법입니다. 딥링크는 앱 내 특정 페이지로 바로 향하는 URL로 HTTP형식이거나 커스텀 URL Scheme으로 설정될 수 있으며, 예를 들어 고양이 관련 앱의 12번 고양이 정보 상세 페이지로 향하는 URL은 goyangzoa://cat/12와 같이 될 것입니다. 마찬가지의 링크가 HTTP형식으로 표현된다면 http://goyangzoa.com/cat/12와 같이 되겠죠.
구체적으로는 특정 웹사이트와 일대일로 일치되는 앱내의 특정 페이지로 향하는 딥링크 정보를 이 Applinks 태그를 통해서 표기할 수 있습니다.
예시는 아래와 같습니다.
<head>
<!-- iOS 딥링크 정보 -->
<meta property="al:ios:url" content="applinks://docs" />
<meta property="al:ios:app_store_id" content="12345" />
<meta property="al:ios:app_name" content="App Links" />
<!-- 안드로이드 딥링크 정보 -->
<meta property="al:android:url" content="applinks://docs" />
<meta property="al:android:app_name" content="App Links" />
<meta property="al:android:package" content="org.applinks" />
<!-- 웹 fallback url 정보 -->
<meta property="al:web:url"
content="http://applinks.org/documentation" />
</head> link[rel=alternate] 태그는 구글이 현재 안드로이드 딥링크 표기를 위해 권장하고 있는 방식입니다. 아래와 같이 적용할 수 있습니다.
<head>
<link rel="alternate"
href="android-app://com.example.android/example/gizmos" />
</head>
아직 Applinks와 link 태그는 국내에서 활용도는 낮으나, 잘 활용할 경우 상당히 큰 우위를 가져올 수 있습니다.
- 구글 크롤러는 Applinks와 link[rel=alternate]의 정보를 인덱싱을 해줘서 구글 검색에 노출시켜줍니다. (Firebase 앱 인덱싱 문서 참조 | 안드로이드 앱 인덱싱 문서 참조)
- 애플에서는 여러 차례 언급될 경우 iOS9 Spotlight 검색에 노출시켜줍니다. (에어브릿지 블로그 관련 글 참조)
여기에 대해서는 좀 더 자세히 서술해야 할 필요가 있으므로, 다른 글을 통해 다시 자세히 소개하겠습니다.
자신의 콘텐츠에 자신이 있는 서비스들은 JSON-LD를 통해 구조화된 정보를 검색에 노출할 수 있습니다.
구글에서는 아래 예시와 같이 구조화된 정보를 수집하여 더 풍부한 검색결과를 제공하는 것에 사용합니다. (구글의 예시 보러가기) 이렇게 구조화된 정보를 표현하려면 Schema.org의 표준을 참고해야 합니다.
Schema.org는 2011년 6월 Bing, Google and Yahoo에 의해서 웹페이지의 마크업(Markup)에 구조화된 정보를 표기할 수 있도록 하기 위하여 만들어진 표준입니다. 예를 들어 레스토랑에 대한 정보를 나타내는 웹사이트라면, 해당 웹사이트 안에 레스토랑의 열고 닫는 시간, 평점, 메뉴, 리뷰 등 “어떤” 체계적인 정보가 있을 수 있는지를 알려주고, “어떻게” 그 체계적인 정보들을 검색엔진 크롤러에게 알려줄 것인지를 알려줍니다.
<script type="application/ld+json">
{
"@context": "http://schema.org",
"@type": "Restaurant",
"name": "Fondue for Fun and Fantasy",
"description": "Fantastic and fun for all your cheesy occasions",
"openingHours": "Mo,Tu,We,Th,Fr,Sa,Su 11:30-23:00",
"telephone": "+155501003333",
"menu": "http://example.com/menu"
}
</script>
예를 들어 위의 그림과 같이 Schema.org의 표준에 따라 레스토랑과 관련된 다양한 속성(Properties)을 명시할 수 있습니다. (Schema.org 사이트에서 확인하기)
레스토랑 페이지를 만드는 개발자는 그 형식에 맞춰서 크게 3가지 표기법(Microdata, RDFa, or JSON-LD)에 따라 정보를 나타낼 수 있는데, 그 중에서도 웹사이트의 head 섹션에 일종의 JSON 형식으로 표기할 수 있는 JSON-LD가 가장 활용하기 간편합니다. 위의 예시는 JSON-LD로 작성된 것입니다.
iOS 사파리 브라우저에서 공인한 “Smart App Banners”(스마트 앱 배너)를 HTML 한 줄로 지원할 수 있습니다.
2012년 6월, 애플은 사파리와 관련하여 “Smart App Banners”(스마트 앱 배너)를 지원한다고 공식 발표하였습니다.
스마트 앱 배너는 아래의 한 줄로 쉽게 구현할 수 있습니다.
<meta name="apple-itunes-app" content="app-id=myAppStoreID, affiliate-data=myAffiliateData, app-argument=myURL">
애플에서는 스마트 앱 배너를 통해서 앱을 설치한 사용자들에게 어떤 URL에서 설치되었는지를 확인 후 알려주는 맥락적 설치 기능을 제공하고 있으며, iTUNES Connect를 사용해서 스마트 앱 배너를 통해 설치된 통계를 분석할 수 있습니다. 자세한 것은 공식문서를 참조해주십시오. (스마트 앱 배너 /iTUNES Connect 연동 공식 문서)
마지막으로 Applinks와 JSON-LD를 통한 구조화된 데이터에 대해서는 구글이 체크하고 있으며, 구글에서 나온 구조화된 데이터 테스팅 툴을 통해서 제공 여부를 확인할 수 있습니다.
단계 7 : 웹마스터 도구(Search Console) 등록과 사이트맵 제출을 통해 기초 SEO 완성하기
구글은 웹사이트들의 자발적인 정보 제공과 체계적인 SEO를 지원하기 위하여 웹마스터 도구를 제공하고 있습니다. 웹마스터 도구는 여태까지 말씀드린 모든 사항들의 총 집합입니다. 따라서 웹마스터 툴의 간단한 GUI를 통해서 부족한 사항을 확인하고 더욱 그 사이트에 최적화를 시킬 수 있습니다. 따라서 본 가이드에서는 별도로 설명하진 않겠습니다.
그러나 마지막으로 반드시 해야 하는 사이트맵(sitemap.xml) 제출에 대해서 몇 가지 가이드를 첨부합니다.
- 사이트맵 제출이 이뤄지는 즉시부터 구글은 나의 사이트들에 대한 인덱싱을 시작할 것입니다. 따라서 sitemap.xml 제출은 실제로 사이트가 완성된 이후에 진행하는 것을 권장합니다.
- sitemap.xml 기술문서 (비디오 별도로 색인 필요)
- sitemap.xml의 경우 REST API 생성을 통해 동적으로 생성되도록 할 수도 있습니다. 단일 사이트맵 파일은 10mb, 50,000개의 URL을 색인하며 여러개의 사이트맵들을 연동시킬 수도 있습니다.
- 안드로이드 딥링크가 있는 경우 사이트맵에 앱 인덱싱을 위해 제출할 수 있습니다. (안드로이드 앱 인덱싱 문서 참조)
단계 8 : 제 3의 길, 앱 내 콘텐츠에 대한 SEO 시도하기
앱 인덱싱(App Indexing) 기술은 앱 내의 콘텐츠를 앱 밖으로 공개해주는 기술입니다. 한 마디로 앱들을 위한 SEO가 앱 인덱싱인 것입니다. 다만, 웹의 경우 크롤러가 자동으로 와서 데이터를 가져갈 수 있지만, 앱의 경우 그러기가 어렵기 때문에 직접 앱 내 콘텐츠 정보를 구글과 애플의 서버로 전송해줘야 한다는 차이가 있습니다.
앱 인덱싱 기능은 현재로서는 구글과 애플 모두가 제공하고 있습니다. 국내에서도 구글은 점차적으로 앱 내 콘텐츠 검색 기능을 확대해서 제공하고 있으며(모바일 구글 검색 시 유튜브, 페이스북 앱 검색결과 노출), 제 3의 앱들도 해당 앱을 설치를 한 사용자들에 대해서 앱 내 콘텐츠 검색결과를 제공하고 있는 것으로 보입니다. (상단은 에어브릿지 기술로 구현한 앱 인덱싱 결과)
반면 애플은 좀 더 소극적인 자세로서 iOS9 Spotlight에서 높은 수준의 콘텐츠(위키피디아, IMDB 등)만을 한정적으로 노출시키고 있는 것으로 보입니다. 본 가이드에서는 주로 구글 앱 인덱싱 위주로 다루고, iOS9 Spotlight 앱 인덱싱의 경우 본 에어브릿지 블로그의 글을 참조해주시기 바랍니다.
구글에 따르면 구글은 앱 인덱싱 기술을 통해 아래의 문제를 해결하고자 하는 것으로 보입니다.
평균적인 사람은 매일 자신이 가지고 있는 앱들 중 약 26%만을 사용하며, 전체 앱들 중 1/4은 아예 설치 후 한 번도 사용되지 않습니다. 앱 인덱싱은 구글 검색을 통해서 iOS와 안드로이드 앱 사용자들을 재진입시키는 것을 도와주는 기능입니다.
이와 같이 구글 검색에서 검색 시 이미 설치된 앱에 관련 콘텐츠가 있는 경우 구글은 높은 확률로 해당 콘텐츠를 검색결과의 상단에 노출시켜줍니다.
구글 앱 인덱싱 기능은 위에서 언급한 Applinks나 link 태그로도 사용 수 있지만, 구글이 표준을 통해 권장하는 방법은 SDK를 통해서 앱에서 직접 해당 콘텐츠와 관련된 내용을 전송하는 것입니다.
2016년 구글 I/O에서 구글은 Firebase라는 플랫폼을 통하여 향후 앱의 성장과 관련된 모든 것들을 한 번에 처리할 수 있게끔 해주겠다고 발표하였습니다. 개발적인 측면, 성장의 측면, 그리고 수익화의 측면까지 한 번에 해결해주는 플랫폼을 만든 것이죠. Firebase를 통해서 새로워진 구글 앱 인덱싱을 시도해보세요.
결론
SEO에는 왕도가 없습니다. 특히 구글 SEO에 대해서는 정직한 양질의 콘텐츠와 일정 수준 이상의 기술력의 조화만이 SEO의 정석이라는 것을 다시 한 번 되새겨봅니다.
이 글은 국내 스타트업들이 언제든지 참고할 수 있는 별도의 SEO 정보 오픈소스 프로젝트 웹사이트로 만들어 나갈 생각입니다. 특히 이 과정에서 함께 조언을 주신 모든 분들을 그 사이트에 명시하고, 개발자분들의 경우 포크(Fork)를 떠가실 수 있도록 초대할 예정입니다. SEO에 경험 많은 개발자분들의 조언과 피드백을 부탁드립니다.
