동영상 버전은 여기서 봐주세요.

 

오늘은 다국가 사이트를 위한 URL을 SEO 관점에서 말씀드리겠습니다.

다국가 사이트의 도메인/URL은 크게 네가지 형태로 구분할 수 있는데요, 각각의 설명과 장담점을 말씀드리겠습니다.

 

1. ccTLD

첫번째는 탑레벨 도메인에서의 국가 분류입니다.

컨트리코드 탑 레벨 도메인이라고 해서 ccTLD라고 부르는데요, ccTLD의 예로는 아마존이 있습니다.

아마존 일본 사이트 주소는 www.amazon.co.jp이고, 영국 아마존은 www.amazon.co.uk를 사용합니다. 구글에 따르면 ccTLD 방식은 사용자와 검색엔진에게 이 사이트가 타게팅하고 있는 국가를 가장 확실하게 알려준다고 합니다.

각 사이트가 사실상 독립된 형태로 운영되기 때문에 현지화도 용이하고, 특정 국가에서 요구되는 조건이나 규제에 대한 대응이 유연합니다.

하지만 각 국가별로 모두 독립된 URL 구매가 필요하기 때문에 비용이 많이 듭니다.

또한 사이트 정책이나 구조 변화시 업무량이 많아지겠죠.

시간이 지나면서 통일된 구조와 형태를 유지하는 것도 어려워질 수 있습니다.

그리고 각 사이트가 사실상 독립된 형태기 때문에 개별 사이트의 SEO 파워가 공유되지 않는다는 단점도 있는데요, 예를 들어 독일 사이트가 굉장한 백링크를 받아서 높은 검색 경쟁력을 갖추고 있다고 해도 브라질 사이트와는 상관이 없다는 것입니다.

새로운 국가 사이트가, 즉 새로운 ccTLD를 가진 사이트가 만들어지면 다른 사이트들이 아무리 검색경쟁력이 좋아도 이 사이트는 그냥 새로 생긴 사이트 취급을 받습니다.

한편 구글의 웹마스터 트렌드 애널리스트인 Gary Illyes에 따르면, hreflang 태그를 통해 각 언어 페이지들과의 관계를 잘 어줄 경우 어느 정도 도움이 될 수 있다고 합니다.

또한 한 국가 내에서 다양한 언어를 사용할 경우에도 ccTLD만으로는 해결이 안됩니다. 캐나다를 예로 들면, .ca 뒤에 /en, /fr과 같이 서브디렉토리를 붙여줘야 하지, .ca-en, .ca-fr과 같은 형태로 사용할 수 없습니다.

참고로 중국에서 바이두 SEO를 고려하신다면 ccTLD 즉 .cn 형태의 도메인을 가장 먼저 고려하셔야 합니다. 

 

2. 서브도메인

두번째는 서브도메인인데요, 호텔스닷컴이 이런 방식으로 언어 사이트별 URL을 구성합니다.

아르헨티나는 ar.hoteles.com, 한국은 kr.hoteles.com입니다.

 

서브도메인 역시 나쁘지 않은 방식입니다.

서브도메인은 한 도메인 내에서 사용되는 것이기 때문에 각 국가 사이트별로 도메인을 구매할 필요가 없고요, 그러면서도 독립된 도메인의 형식을 갖추고 있기 때문에 구글 서치콘솔 등에서 각각의 지오타게팅을 작용할 수가 있습니다.

각 서브도메인별로 서버를 나눌 수도 있고요.

서브도메인 역시 ccTLD와 마찬가지로 검색엔진에게는 독립적으로 보여지기 때문에 각 사이트의 SEO 파워의 공유가 제한되고요, 비용을 제외한 대부분의 ccTLD의 단점을 갖고 있습니다.

 

국가별 ccTLD Map

3. 서브디렉토리

세번째는 www.youtube.com/kr과 같이 서브디렉토리를 사용하는 방식입니다.

애플 코리아의 웹사이트 주소는 www.apple.com/kr입니다. 물론 애플 코리아 웹사이트는 apple.co.kr, apple.kr로도 접근이 가능합니다만, 모두 apple.com/kr로 리다이렉트 됩니다. apple.com/kr이 메인으로 사용되는 주소라는 뜻이죠. 

 

관리의 관점에서 서브디렉토리는 가장 우수합니다.

각 언어 사이트가 그냥 큰 사이트의 폴더일 뿐이거든요.

그리고 한 국가가 새로 생성되었다고 해도, 탑도메인을 공유하고 있기 때문에 기존의 다른 국가 사이트들이 이미 구축해놓은 검색 경쟁력을 덕을 볼 수 있습니다.

구글 서치 콘솔이나 구글 어낼러틱스에서 서브디렉토리별로 독립적으로 등록을 하고 관리하는 것도 가능합니다.

구체적인 언어 구별도 가능합니다. 도메인 뒤에 /ca-en, /ca-fr과 같이 붙여주면 되거든요.

하지만 국가/언어 사이트별 서버 분리가 안되고요, 웹마스터 도구들에서 개별 사이트로 인식되지 않아 개별 지오 타게팅이 불가능합니다.

하나의 도메인에 묶인 사이트가 너무 방대하기 때문에 발생하는 기술적인 부담도 있습니다.

 

4. 파라미터

마지막으로 파라미터를 사용하는 방법이 있습니다.

https://developers.google.com/search/docs/advanced/crawling/301-redirects?hl=ko 이런 식으로요.

구글 개발자 사이트 주소는 이런 식으로 구성되어 있습니다. 뒤에 hl=ko가 있죠? 제일 마지막의 ko를 en으로 바꾸면 같은 내용의 영문 페이지로 바뀝니다.

파라미터 방식은 SEO 관점에서 특별히 언급할게 없으니 패스하겠습니다.

 

그럼 어떤 방식이 제일 좋은 방식일까요? 정답은 없습니다.

실제로 유명 웹사이트들은 각 회사의 상황에 맞게 이 세 방식 중 하나를 선택하여 사용하고 있습니다. 

예산, 관리역량, 사이트 변화 주기 등에 따라 장단점을 비교한 후 여러분에게 가장 맞는 형태를 고르시면 됩니다.

 

글쓴이 이환선

서울과 시드니에 기반을 둔 디지털 커뮤니케이션 에이전시인 주식회사 BALC(발크)의 대표이사를 맡고 있으며, 유튜브 "검색요정의 마케팅"을 운영하고 있습니다.

 

동영상 버전은 여기에서 봐주세요

 

우리나라는 웹사이트를 만들 때 URL에 대해 크게 중요하게 여기지 않는 경향이 있습니다.
하지만 URL은 검색엔진최적화에 있어 절대 소흘하게 다뤄져서는 안되는, 매우 중요한 요소입니다.
오늘은 검색엔진최적화를 위한 URL, 일명 Search Friendly URL에 대해 쉽고 빠르게 알아보겠습니다.
 

검색엔진이 읽을 수 있는 URL

검색엔진은 URL 단위로 페이지와 페이지의 정보를 수집합니다. 하지만 어떤 URL은 검색엔진의 인식을 방해하기도 합니다.
여기 러시앤캐시의 웹사이트가 있습니다. URL에 #가 있죠? 검색엔진은 # 뒤의 정보를 인식하지 못합니다.
러시앤캐시 사이트에는 다양한 URL이 존재합니다만 도메인 바로 뒤에 /#/가 있습니다.
즉, 검색엔진이 수집할 수 있는 URL은 도메인 뿐입니다.
#가 존재한다고 무조건 문제가 되는 것은 아닙니다. # 앞의 URL들이 개별 페이지의 속성을 나타낸다면 상관 없습니다만 러시앤캐시의 경우는 이 개별 페이지의 URL 정보가 # 뒤에 있습니다.
어쩔 수 없이 이런 형태의 URL을 사용해야 하는 경우에는 #가 없는 URL을 만들고, 그쪽으로 리다이렉트를 걸어줘야 합니다.
URL에 #가 있지만 문제 없는 경우는 청와대 홈페이지의 정책정보를 보시면 됩니다. 여기 URL의 #는 페이지 내의 일종의 바로가기 역할을 하는 것이지, 페이지를 구분해 주는 것은 아니기 때문에 문제 없습니다. 사실상 한 페이지에요.
 

구조화

각 페이지들은 상하위 위계 구조를 갖추고 있습니다. 그리고 검색엔진은 이 웹사이트의 구조를 URL의 형태를 통해 파악합니다.
웹사이트의 메뉴가 잘 구조화 되어 있으면 당연히 사용자에게 도움이 되겠죠. 비슷한 주제의 컨텐츠들이 모여서 카테고리 메뉴가 되고. 이러면 확실히 사이트 탐색이 편하죠. 사용자에게 도움이 되니 당연히 검색엔진도 좋아합니다.
그런데 메뉴를 아무리 잘 구성해도 URL이 잘못되어 있으면 검색엔진이 그 구조화를 알 수 없습니다.
검색엔진이 인식하는 구조화의 형태는 URL의 단계, 즉 /로 구분되는 URL의 요소들인데요, 웹사이트 내의 모든 URL이 같은 레벨에 존재한다면 검색엔진 눈에는 구조화가 되지 않은 것으로 보여집니다.
제 유튜브를 웹사이트라고 가정하고 예를 들어볼게요.
검색요정의마케팅 사이트 아래에 검색엔진최적화라는 카테고리가 있고, 그 안에 검색엔진이 좋아하는 URL이라는 페이지가 있는 셈입니다.
이 구조를 URL에 반영하면 이렇습니다.
검색요정의마케팅.com/검색엔진최적화/검색엔진이-좋아하는-URL.html
상황에 따라서 많은 변수가 있습니다만, 기본적으로는 웹사이트의 메뉴 구조가 URL에 반영된다라고 생각하시면 됩니다.
 

키워드

타겟 키워드는 본문 뿐 아니라 URL에도 들어가는 것이 좋습니다. URL 역시 검색엔진이 페이지의 주제를 파악하는 요소 중 하나고요, 비록 메이저 팩터는 아닙니다만 엄연히 노출 순위에 영향을 미치는 요소입니다.
우리나라와 외국의 쇼핑몰 URL을 하나씩 비교해보겠습니다.
지마켓 글로벌과 아마존의 아이폰 케이스 페이지 주소입니다.
둘 사이에는 매우 큰 차이가 있습니다. 바로 URL내 타겟 키워드입니다.
우리나라 쇼핑몰의 경우 개발자들이 우리는 DB와 연동되기 때문에 동적 URL을 쓸 수 밖에 없다, 따라서 키워드를 반영할 수 없다라고 선을 그어버리는 경우가 많은데요, 안되는 거 없습니다. 안하는 겁니다.
동적 URL 자체가 문제가 되는 것은 아닙니다. 페이지의 주제를 나타내는 타겟 키워드만 반영되면 됩니다.
아쉽게도 한글은 해당되지 않습니다.
 

공유되는 URL

우리 웹사이트와 개별 페이지의 방문을 유도하는 데 있어 외부 링크는 매우 중요합니다. 요즘은 많이 없어졌습니다만, 여전히 웹사이트 내에서 어떤 페이지를 방문해도 URL이 바뀌지 않는, 일반적으로는 탑도메인으로 고정된 경우가 가끔 있습니다.
어떤 사용자가 우리 웹사이트의 농구화 페이지가 마음에 들어서 페이스북에 공유합니다. 하지만 공유되는 URL은 농구화 페이지가 아닌 탑도메인, 즉 메인 페이지의 URL입니다. 그 사용자의 지인들이 페이스북 링크를 클릭하면 당연히 농구화 페이지가 아닌 메인 페이지로 랜딩될테고, 뭘 보라는 건지 모르니 그냥 이탈을 하게 됩니다.
따라서 개별 페이지의 URL이 그대로 공유되도록 해주세요.
 

대소문자 구분

관리상의 이유로 URL에 대소문자가 구분되는 경우가 있습니다.
간혹 대소문자를 잘못 넣을 경우, 즉 대문자 대신 소문자를 넣으면 아예 접속이 되지 않는 경우도 있습니다. 드물게는 주소를 직접 치고 들어오는 경우도 있으니, 대소문자 제한은 풀어주는 것이 좋습니다.
그리고 접속이 가능하다고 해도 구글 어낼러틱스 같은 많은 성과측정도구는 대소문자를 구분해서 인식합니다.
대문자 AAA.html과 소문자 aaa.html이 다른 페이지로 인식되니, URL 단위로 성과측정할 때 장애가 되겠죠.
아주 특별한 이유가 없다면 굳이 대소문자 구분을 할 필요가 없습니다.
 

"-"와 "_"

URL 내에 키워드를 넣을 경우, 그리고 그 키워드가 복합단어일 경우, 단어의 구분은 _가 아닌 -를 써줘야 합니다. 검색엔진 눈에 _는 단어 구분이 아닌 그냥 시각적인 구분점일 뿐입니다.
이 두 차이를 잘 기억하세요.
search-friendly-url=search friendly url
search_friendly_url=searchfriendlyurl
 
이 정도만 하셔도 여러분들은 URL때문에 SEO 망했다라는 얘기는 듣지 않으실 겁니다.
 
 

글쓴이 이환선

서울과 시드니에 기반을 둔 디지털 커뮤니케이션 에이전시인 주식회사 BALC(발크)의 대표이사를 맡고 있으며, 유튜브 "검색요정의 마케팅"을 운영하고 있습니다.

 

 

동영상 버전은 여기서 봐주세요.

 

다국어 사이트에서 국가별 타게팅이 필요한 이유

 

한국이라는 국가에서 한국어를 공용어로  사용하고 있는 우리는 평소 잘 생각하지 않는 개념입니다만, 언어를 특정 국가를 대표하지 않습니다. 영어, 스페인어, 독일어, 프랑스어 등은 다수의 국가에서 대표 언어로 사용되고 있습니다. 영국과 호주는 다른 국가입니다만, 같은 언어를 사용하고 있습니다.

다른 국가, 같은 언어를 이런 문제를 야기할 수 있습니다. 호주에 있는 사용자에게 영국의 사이트가 먼저 노출된다? 상점 정보와 연락처를 찾고 또는 주문을 하려고 보니 영국의 사이트입니다. 그럴 경우 호주 사이트가 있는지 찾아보는 사용자도 있습니다만, 아 이 회사는 호주에서는 사업을 제대로 안 하나보다라고 생각을 할 수도 있습니다.

물론 개발하시는 분들이 사용자가 속한 물리적 지역에 맞는 사이트로 리다이렉트 되도록 조치를 해 주시겠지만, 그렇다고 해도 앞서 언급한 타이틀과 디스크립션의 문제는 남아 있습니다.

언어 뿐 아니라 국가 타게팅의 개념이 SEO에 들어간 이유입니다.

 

웹페이지의 국가 레벨 타게팅이 필요한 또 하나의 이유는 검색결과 화면에서의 중복 노출 이슈입니다. 어떤 정보를 찾았는데 한 회사의 영국 사이트, 미국 사이트, 호주 사이트, 캐나다 사이트 등이 검색화면을 가득 채웁니다. 회사 입장에서는 기쁠 수 있겠죠. 검색경쟁력이 높다는 얘기고, 경쟁 컨텐츠들을 뒤로 밀어냈으니까요. 하지만 사용자들에게는 그저 스팸으로 여겨질 뿐입니다. 검색엔진에게도 마찬가지입니다.

 

hreflang이란?

 

다국어 사이트의 국가 레벨 타게팅에는 여러 방법이 사용되는데요, 오늘은 hreflang 태그에 대해 알아보겠습니다.

hreflang 태그는 지금까지 외부 SEO 컨설팅을 받지 않은 국내 기업의 사이트에서는 한번도 그 적용을 본 적이 없을 정도로 잘 사용되지 않는 태그입니다.

교포들이 있긴 합니다만 기본적으로 한국어 사이트는 대한민국이라는 국가에 거주하는 사람들을 위한 것입니다. 따라서 국가를 타게팅하는 이 태그가 필요하지 않은 것입니다.

 

보통 웹페이지들에는 lang 태그가 사용됩니다. lang 태그는 문서의 언어, 한국어인지, 영어인지, 독일어인지를 나타냅니다. 이것은 검색엔진이 아니라 브라우저에 언어 시그널을 보내주는 역할을 합니다. 자동번역이나 사용자 브라우저에 맞는 언어 또는 정보를 제공하는 데에 사용됩니다.

 

반면 hreflang 태그는 검색엔진, 정확하게는 구글에게 컨텐츠의 언어를 말해준다고 말할 수 있습니다. 해당 내용의 여러 언어 버전의 페이지들이 존재할 경우, 즉 다국어로 제작된 사실은 동일한 페이지들이 존재할 경우 사용자에게 적합한 언어의 페이지를 보여주는 것입니다.

 

lang 태그와 비교하며 설명드리는 것이 더 좋습니다만, HTML에 친숙하지 않은 분들께는 오히려 머리만 아픈 얘기기 때문에 오늘은 hreflang 태그만 설명을 드리겠습니다.

 

hreflang 태그의 적용

 

사용법은 매우 간단합니다.

그냥 바로 예를 들어서 설명드리겠습니다.

 

hreflang 태그를 사용할 때는 다른 두개의 태그와 함께 세개의 파트로 구성해야 합니다.

link는 현재 문서와 외부 문서의 관계를 정의하는 건데요, link rel은, 지금 각각의 문서가 서로의 다른 언어 버전, 즉 대체 입니다. alternate를 씁니다.

 

그 뒤에 hreflang에는 타게팅되는 언어와 지역을 씁니다.

위의 예를 보시면 위쪽에 gb, us, es라는 폴더 아래에 동일한 이름의 html 문서가 있습니다. 페이지죠.

폴더 이름에서 우리는 각각이 영국, 미국, 그리고 스페인 타겟의 사이트임을 알 수 있습니다.

같은 영어라고 해도 gb, 영국과 us, 미국이 구분되어 있습니다. 단순히 영어, 독일어 같은 기본 언어 뿐 아니라 영국, 미국, 호주 같은 하위 도메인을 제공해서 같은 언어를 사용하는 각 국가를 타게팅하는 것이 가능합니다.

반면 스페인어는 es-es, 또는 es-mx 멕시코입니다, 뭐 이런 하위도메인 없이 그냥 es만 써 있습니다. 이 얘기는 세부 지역을 구분하지 말고 스페인어 사용자에게는 이 사이트를 보여주라는 의미입니다.

캐나다의 경우 20% 초반인 인구가 프랑스어를 주 언어로 사용합니다. 그렇다면 캐나다에는 en-ca와 fr-ca로 태그된 페이지를 별도 운영할 수 있습니다. 이 경우 프랑스 내에 있는 사용자들에게 언어에 맞는 버전을 제공함은 물론, 영어로 된 미국 사이트나 프랑스 거주중인 프랑스어 사용자를 위한 사이트의 노출을 줄일 수 있습니다.

 

그리고 마지막에 href에 각 hreflang에 대응하는 URL을 써줍니다.

각 언어 버전을 모두 이렇게 한번에 정리한 후, 언어 버전이 존재하는 모든 페이지에 넣어주면 됩니다. 모든 언어 사이트에서 페이지 구조가 완전히 같다면 모든 페이지에 넣어주면 됩니다.

 

hreflang 태그는 지난 2011년 말에 구글에 의해 만들어졌습니다. 제가 앞서서 hreflang이 검색엔진이 아닌 구글에게 컨텐츠의 언어를 말해준다고 말한 이유입니다. 빙이나 바이두 같은 다른 많은 검색엔진은 hreflang을 인식하지 않습니다. 이 경우 컨텐트 랭귀지나 그냥 랭 태그를 이용해야 합니다. 얀덱스에는 hreflang이 사용 가능합니다.

 

 

글쓴이 이환선

서울과 시드니에 기반을 둔 디지털 커뮤니케이션 에이전시인 주식회사 BALC(발크)의 대표이사를 맡고 있으며, 유튜브 "검색요정의 마케팅"을 운영하고 있습니다.

 

 

 

 

 

+ Recent posts