8단계로 끝내는 구글 SEO 실천법 - 3
지난 번 글을 통해 SEO에 영향을 미치는 3가지의 포인트를 중심으로 실제 SEO에 적용할 수 있는 부분을 살펴보았습니다. 이번 글에서는 실전적으로 활용할 수 있는 나머지 6가지 SEO 포인트에 대해서 정리하였습니다.
주의 : 이 가이드는 철저히 주관적인 관점에서 서술되었으므로, 구글에서 제시하는 공식 가이드를 참조하고 싶으신 분은 구글의 개발자 체크리스트를 참조해주시기 바랍니다.
단계 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 기법들이 상당히 일부 도태되었습니다. 더욱 상세한 정보의 경우 Akamai의 관련 자료를 참조해주세요.
또한 구글에서 정적 자원을 가진 페이지를 빨리 랜더링하는 것과 관련된 프로젝트를 진행하고 있습니다. 정말 순수한 콘텐츠 그 자체를 빨리 전달하고자 하는 서비스들은 Accelerated Mobile Pages 프로젝트를 참조해주시길 바랍니다.
단계 4 : 소셜미디어상의 공유 유도를 통해 지속적인 랭킹 상승 및 선순환 꾀하기
소셜미디어에 나의 사이트가 공유되거나 언급될수록 사이트의 랭킹은 높아집니다. 특히 소셜 버즈(Buzz)가 SEO의 3대 요인이므로 아주 중요하다고 할 것입니다.
소셜 버즈를 상승시키는 방법에는 서비스 기획자, 특히 UX 디자이너들이 웹사이트의 콘텐츠가 소셜 미디어에 잘 공유될 수 있도록 사용자 흐름을 설계하는 것이 가장 이상적입니다. 예를 들어 위의 사례는 addthis 버튼을 통해서 저희 에어브릿지 블로그에서 공유를 유도하고 있는 모습입니다.
이러한 공유 시스템을 일일히 개발 작업을 통해서 장착하는 것이 어렵기에, 아래와 같이 웹사이트의 소셜 공유를 쉽게 유도할 수 있는 몇 가지 솔루션들을 소개합니다.
(해외) sumome
(국내) LiveRe
(해외) addthis
(해외) getsocial
또한 페이스북 코멘트를 통해서 콘텐츠의 바이럴화를 유도하는 것도 좋은 기능입니다. 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 태그를 통해서 표기할 수 있습니다.
예시는 아래와 같습니다.
link[rel=alternate] 태그는 구글이 현재 안드로이드 딥링크 표기를 위해 권장하고 있는 방식입니다. 아래와 같이 적용할 수 있습니다.
아직 Applinks와 link 태그는 국내에서 활용도는 낮으나, 잘 활용할 경우 상당히 큰 우위를 가져올 수 있습니다.
구글 크롤러는 Applinks와 link[rel=alternate]의 정보를 인덱싱을 해줘서 구글 검색에 노출시켜줍니다. (Firebase 앱 인덱싱 문서 참조 | 안드로이드 앱 인덱싱 문서 참조)
애플에서는 여러 차례 언급될 경우 iOS9 Spotlight 검색에 노출시켜줍니다. (에어브릿지 블로그 관련 글 참조)
여기에 대해서는 좀 더 자세히 서술해야 할 필요가 있으므로, 다른 글을 통해 다시 자세히 소개하겠습니다.
자신의 콘텐츠에 자신이 있는 서비스들은 JSON-LD를 통해 구조화된 정보를 검색에 노출할 수 있습니다.
구글에서는 위의 예시와 같이 구조화된 정보를 수집하여 더 풍부한 검색결과를 제공하는 것에 사용합니다. (구글의 예시 보러가기) 이렇게 구조화된 정보를 표현하려면 Schema.org의 표준을 참고해야 합니다.
Schema.org는 2011년 6월 Bing, Google and Yahoo에 의해서 웹페이지의 마크업(Markup)에 구조화된 정보를 표기할 수 있도록 하기 위하여 만들어진 표준입니다. 예를 들어 레스토랑에 대한 정보를 나타내는 웹사이트라면, 해당 웹사이트 안에 레스토랑의 열고 닫는 시간, 평점, 메뉴, 리뷰 등 "어떤" 체계적인 정보가 있을 수 있는지를 알려주고, "어떻게" 그 체계적인 정보들을 검색엔진 크롤러에게 알려줄 것인지를 알려줍니다.
예를 들어 위의 그림과 같이 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"(스마트 앱 배너)를 지원한다고 공식 발표하였습니다.
스마트 앱 배너는 아래의 한 줄로 쉽게 구현할 수 있습니다.
애플에서는 스마트 앱 배너를 통해서 앱을 설치한 사용자들에게 어떤 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를 통해서 새로워진 구글 앱 인덱싱을 시도해보세요.
안드로이드 구글 앱 인덱싱
iOS 구글 앱 인덱싱
결론
SEO에는 왕도가 없습니다. 특히 구글 SEO에 대해서는 정직한 양질의 콘텐츠와 일정 수준 이상의 기술력의 조화만이 SEO의 정석이라는 것을 다시 한 번 되새겨봅니다.
이 글은 국내 스타트업들이 언제든지 참고할 수 있는 별도의 SEO 정보 오픈소스 프로젝트 웹사이트로 만들어 나갈 생각입니다. 특히 이 과정에서 함께 조언을 주신 모든 분들을 그 사이트에 명시하고, 개발자분들의 경우 포크(Fork)를 떠가실 수 있도록 초대할 예정입니다. SEO에 경험 많은 개발자분들의 조언과 피드백을 부탁드립니다.
