“검색엔진은 사람과 보는 눈이 다르다”라고 누누히 밝혔지만, 사실 검색엔진은 많은 부분에서 사람들의 의사 결정을 모방하고 있다. "보다 인간스러움”은 모든 AI의 목표다.

특히 이것이 좋은 컨텐츠인가에 대한 검색엔진의 관점은 거의 완벽하게 사람들의 시선과 일치한다. 검색엔진최적화의 테크닉은 이것과 관련되어 있거나, 이것을 검색엔진에게 보다 잘 전달하기 위한 방법들이다.

 

검색엔진의 입장에서 좋은 컨텐츠란 무엇일까? 특정 키워드를 검색한 사람을 대상으로, 이 컨텐츠를 제공해줬을 때 사용자가 만족하는 것이다. 사용자의 만족도는 단순히 컨텐츠의 품질로 결정될까? 웹사이트의 속도, 모바일에서 버튼과 텍스트의 크기, 정보의 다양성, 관련된 정보의 연관 탐색 등등 수많은 사용자 경험 요소들이 사용자의 만족도에 영향을 미친다. 그래서 검색엔진최적화에서 사이트 로딩 속도, 링크간의 거리, 사진과 동영상 등의 포함여부, 링크 등을 다루는 것이다. 오늘은 이 수많은 검색엔진최적화 요소 중 웹사이트의 구조화를 다루고자 한다.

 

여기 이순신 장군이라는 동일한 주제를 다루는 두권의 책이 있다. A는 “이순신에 대하여”라는 제목만 있을 뿐, 내용에서는 별도의 챕터 구분이 없다. B는 제목은 동일하지만 아래와 같이 세부 챕터를 갖고 있다.

 

제목: 이순신에 대하여

1장: 이순신의 유년시절

 1절: 이순신의 출생

 2절: 어린 이순신

2장: 이순신의 청년기

3장: 과거 급제와 전장에서의 활약

….

6장: 이순신의 눈부신 업적

7장: 이 시대의 우리가 이순신을 돌아봐야 하는 이유

 

어떤 책이 독자들에게 내용을 잘 전달할까?

사람의 머리는 모든 걸 한번에 담아두고 정리하지 못한다. 정보를 세부 주제에 따라 별도의 수납함에 정리하게 되는데, 당연히 정보의 제공 단계에서 주제가 구분되는 것이 효율적이다.

 

웹사이트에도 수많은 정보가 있다. 그 모든 정보들이 한 페이지에 모두 들어있는 것이 아니라, 주제에 따라 분류되어 있다. 모든 내용이 한 페이지에 들어 있다면 사용자들이 읽거나 이해하기 힘들 것이고, 이해에 앞서 많은 사용자들이 이탈하게 될 것이다. 이러한 이유로 연관된 주제에 따라 페이지를 구분하여 제작한다. 그리고 그 분류는 메뉴에 잘 반영되어 있다. 하지만 메뉴는 인간 사용자를 위한 것이며, 검색엔진에게 그 분류를 전달하기 위해서는 다른 요소가 필요하다.

 

 

일상에서 접하는 구조화의 예

 

회사의 예를 들어보자

매드타임스/편집부/기자1

매드타임스/편집부/기자2

매드타임스/인사부/직원1

매드타임스/영업부/직원2

조직도가 이렇게 구조화되어 있다면 어떤 직원이 어떤 일을 하는지 파악하기 쉬울 것이며, 어떤 업무를 위해 어떤 직원에게 연락해야 하는지도 쉽게 알 수 있다.

하지만 아래와 같이 조직도가 구성되어 있다면 어떨까?

매드타임스/기자1

매드타임스/기자2

매드타임스/직원1

매드타임스/직원3

 

또한 조직 내에는 직급도 존재한다.

미팅에 참석했는데 매드타임스의 모든 기자가 “기자”라는 타이틀을 갖고 있다면, 누가 책임자인지 알 수 없게 된다. 구조화에는 단순히 주제별 분류 뿐 아니라, 상하위 서열이 존재해야 한다. 위의 구조화를 직급으로 표현한다면 아래와 같다.

대표이사/편집부장/기자1

대표이사/편집부장/기자2

대표이사/인사부장/직원1

이를 통해 우리는 편집부장이 편집부 기자들 모두와 관련된 일을 하며, 직원1은 인사부장의 업무를 돕는다는 것을 알 수 있다.

 

 

검색엔진최적화를 위한 URL의 구조화란?

 

웹사이트 내 페이지들의 수직/수평 구조를 파악하기 위하여 검색엔진은 URL을 이용한다. URL이 어떻게 구성되어 있는가에 따라 그 페이지가 어떤 주제의 상/하위 페이지이며 어떤 페이지들과 주제를 공유하고 있는지를 파악한다.

 

일반적인 URL은 아래와 같이 구성된다.

도메인.com/1단계분류/2단계분류/페이지1.html

도메인.com/1단계분류/2단계분류/페이지2.html

검색엔진은 이 URL로부터 특정 페이지가 어느 주제의 카테고리이며, 어느 페이지와 인접한 주제인지 파악한다.

웹사이트의 페이지들 역시 이렇게 구조화되어야 하며, 그 관계는 메뉴 뿐 아니라 URL에 반영되어야 한다.

쉽게 요약하자면, 각 웹페이지의 레벨은 /로 구분되어야 하며, 같은 / 레벨에는 컨텐츠 구조에서 같은 레벨에 속한 페이지가 위치해야 한다.

아래 두개의 URL 구조를 비교해보자.

도표의 계층은 웹페이지의 계층이며, 그 안에 URL이 기재되어 있다.

좌측의 URL 구조는 웹페이지의 계층 구조를 반영하고 있다. 신발과 의류라는 카테고리 페이지는 2 Depth, 하위의 제품군 페이지는 3 Depth의 URL 구조를 갖추고 있다.

또한 농구화와 축구화는 신발이라는 카테고리 페이지를 상위에 공유하고 있다.

편의상 제품군을 최하 계층의 페이지로 표현했지만, 개별 제품군 페이지의 경우 아디다스.com/신발/농구화/게임토커.html 이렇게 구성될 것이다.

반면 오른쪽의 URL은 카테고리 페이지와 제품군 페이지 모두 2 Depth의 URL로 구성되어 있다. 이는 웹페이지의 계층 구조와 상이하며, 검색엔진은 최상위 도메인 페이지(메인페이지)를 제외한 모든 페이지가 같은 레벨에서 존재한다고 생각할 것이다.

당연히 좌측의 URL 구조가 검색엔진최적화에서 권장되는 형태다.

 

마지막으로 마케팅 관련 매체인 매드타임스의 URL을 예로 살펴보자.

메인: http://www.madtimes.org/

Trends 메인: http://www.madtimes.org/news/articleList.html?sc_section_code=S1N37&view_type=sm

Trends-Watch 메인: http://www.madtimes.org/news/articleList.html?sc_sub_section_code=S2N80&view_type=sm

Trends-Watch 기사: http://www.madtimes.org/news/articleView.html?idxno=4139

메뉴에서는 이 네 페이지가 수직 구조를 갖추고 있다. 하지만 URL을 살펴보면, Trends의 메인, Trends 내 세부 주제인 Watch의 메인, 그리고 구조에서 제일 하단에 있는 기사 모두 http://www.madtimes.org/news/articleList.html에서 Depth(“/“로 구분되는 URL의 단위)가 끝나는, 모두 동일한 Depth를 갖고 있다. 단순히 그 뒤에 파라미터로 페이지가 구분될 뿐인데, 파라미터는 URL의 구조를 정의하지 못한다. 직급 구분이 없이 모두 수평 구조로 나열된 것이라 말할 수 있으며, 이 URL 구조는 아래와 같이 개선되어야 한다.

메인: http://www.madtimes.org/

Trends 메인: http://www.madtimes.org/news/trends

Trends-Watch 메인: http://www.madtimes.org/news/trends/watch

Trends-Watch 기사: http://www.madtimes.org/news/trends/watch/기사페이지

 

마지막으로 한번 더 강조하자면, 검색엔진은 사용자가 탐색하고 이해하기 쉽게 구조화된 웹사이트를 좋아한다. 그리고 그 구조는 URL을 통해 전달되므로 절대로 소흘하게 여겨서는 안된다.

지난 글에서 검색엔진이 컨텐츠의 정보를 읽지 못하게 만드는 장애요인들을 살펴봤다. 오늘은 컨텐츠에 대한 검색엔진의 접근 자체를 막는 대표적인 요소들을 살펴보고자 한다. 

[지난 글 보기] - 검색엔진의 눈을 가리는 웹사이트 - 1. 컨텐츠

 

1. URL

 

검색엔진최적화에서 URL은 생각보다 훨씬 더 중요하다. URL은 많은 검색엔진최적화 컨설턴트들이 웹사이트 분석시 제일 먼저 확인하는 요소 중 하나이며, 구조화와 타겟 키워드 등 다양한 측면에서의 최적화가 필요하다.

 

URL의 가장 기본적이며 중요한 역할은 “검색엔진에게 웹사이트 내 페이지들을 안내하는 이정표” 역할을 수행한다는 것이다. 반대로 URL로 인해 검색엔진이 개별 웹페이지들을 인식하지 못하게 될 수도 있다. 

URL에 대해서는 하나의 컨텐츠를 별도로 작성해야 할 정도지만, 오늘은 단 하나만 기억하자. 

“#는 나쁘다”

소셜미디어의 해시태그로 인해 더없이 친숙한 #지만, URL에서의 #는 매우 나쁘다. 

 

검색엔진은 # 뒤의 정보를 읽지 못한다.

여기 여러 페이지의 URL들이 있다. 

도메인.com/aaa/#a

도메인.com/aaa/#b

도메인.com/aaa/#c

도메인.com/aaa/#d

분명 우리 눈에는 4개의 분리된 페이지들인데, 검색엔진에게는 도메인.com/aaa까지만 인식된다. # 뒤의 정보를 읽지 못하기 때문이다. URL 단위로 페이지를 수집하여 보여주는 검색엔진이 개별 페이지를 분리해서 인식하지 못한다는 것은 큰 문제가 된다.

 

URL이 이렇게 구성되는 가장 흔하고 쉬운 예는 탭으로 컨텐츠를 구분하여 보여주는 페이지다. 

아래와 같은 구조의 웹사이트를 예로 들자면, 1의 메뉴를 클릭했을 때 2의 영역은 바뀌지 않고 3의 영역만 바뀌는 구조다.

디자인적 예시일 뿐, 실제 삼성반도체 미국의 사이트는 아무런 문제가 없다

 

페이지를 이렇게 구성하는 기획자의 가장 큰 논리는 사용자 편의성이다. 굳이 모든 페이지를 다시 로딩하지 않고 하단의 페이지만 바꿈으로써 사용자들의 편의성을 높인다는 것인데, 의미가 없는 말은 아니지만 다시 생각해볼 필요가 있다.

첫째, 페이지 전체를 로딩하는 경험(페이지를 새로 이동한다는 느낌)이 정말로 사용자에게 불편함을 주는가? 물론, 페이지를 이동할 때마다 절반 이상의 트래픽이 이탈한다는 연구 결과가 있긴 하지만 전체 리로딩과 부분 교체 사이에 유의미한 차이가 있을까? 

둘째, 상단의 정보를 다시 로딩하기 위해 걸리는 시간이 사용자 편의성을 해칠 정도인가? 그 정도로 열악한 인터넷 환경이 얼마나 될 것이며, 만일 로딩 시간이 이슈라면 그 시간을 줄이기 위한 페이지 최적화가 우선이 아닐까?

셋째, 사용자 편의성이 높아진다고 가정하면, 그것이 과연 검색노출 제한과 맞바꿀 정도의 가치인가?

 

긴 페이지 내의 특정 부분으로 바로 이동하게 만드는 용도로 #를 사용하는 경우도 있는데, 해당 페이지의 대표 주소를 #로 막아버리지만 않는다면 이 경우는 큰 문제가 되지 않는다.

 

부득히하게 #를 사용하는 경우 #!와 같이 !를 분이는 방법(hashbang이라고 부른다)이 있으나, 활용이 제한적이며 기술적인 설명이 필요하니 본 글에서 다루지는 않겠다. 

 

 

2. Robots.txt, Noindex Tag

 

Robots.txt 파일은 검색엔진의 수집 활동을 제어하는 역할을 한다. 웹사이트 내에는 검색 결과에 드러나서는 안되는 페이지들은 존재한다. 각 회원의 개인정보 페이지나 보안 자료, 그리고 어드민 관련 페이지들이 대표적이다. 또한 웹사이트 내에는 “서버에서는 삭제하지는 않지만 사람들이 방문해서는 안되는 옛날 페이지”들이 존재하기도 한다. 이러한 페이지들은 Robots.txt 파일을 통해 검색엔진의 접근을 차단할 수 있다.

 

아래의 Robots.txt 파일 예를 보자

User-agent: *

Disallow: /admin

Disallow: /member

User-agent: Baiduspider

Disallow: /

 

이 파일은 두개의 정보를 담고 있다.

먼저, 모든 검색엔진에 대해(User-agent: *) /admin과 /member에 속한 모든 페이지에 접근하지 말라고 전달(Disallow)한다.

또한 바이두(User-agent: Baiduspider)는 모든 페이지에 접근하지 않도록 명령(Disallow: /)한다.

 

흔하지 않지만 간혹 아래와 같은 Robots.txt 파일이 올려져 있는 것을 보게 된다.

User-agent: *

Disallow: /

모든 검색엔진(User-agent: *)은 이 사이트의 모든 페이지에 접근하지 말라(Disallow: /)는 것이다. 이런 요구를 전달하고 있으니, 당연히 검색엔진은 해당 사이트의 정보를 가져가지 않는다.

 

Noindex 태그는 각 페이지에 적용되어 검색엔진의 인덱싱을 차단하는데, 이 역시 불필요하게 사용되어서는 안된다. 

 

 

3. Redirect

 

A라는 페이지로 방문한 사용자를 B 페이지로 자동으로 보내는 것을 리다이렉트라고 한다. 웹사이트 개편이나 다른 수많은 이유로 아주 흔히 사용되는 방법인데, 어떤 식으로 해도 사용자에게는 문제가 없지만 검색엔진 대상으로는 약간의 주의가 필요하다.

먼저, 리다이렉트는 301과 302라는 두개의 방식이 있다. 301은 영구, 302는 임시라는 것만 알아두자.

 

A 페이지가 영원히 없어져서 기존에 블로그 또는 소셜에 공유된 A 페이지 링크를 클릭한 사람들을 B 페이지로 안내해야 한다면 301이 적용되어야 한다. 그러나 A 페이지의 내용 또는 디자인적 개편 기간 동안에만 임시로 B 페이지로 사람들을 안내한다면 여기에는 302 방식의 리다이렉트가 적용되어야 한다. 

 

조금 더 이해하기 쉬운 우리 일상 생활의 예를 들어보자.

301: 이번에 다른 집으로 이사를 한다. 따라서 주민등록상의 내 주소를 바꿔야 하며, 공식적으로 나의 주소는 바뀌게 된다.

302: 리모델링 하는 한달 동안만 근처의 오피스텔에서 생활한다. 한달 후에 다시 원래 집으로 돌아가므로, 주민등록상의 주소를 바꾸지 않는다. 쇼핑 배송 주소는 임시로 바꾸겠지만, 공식적인 나의 주소는 바뀌지 않는다.

 

공식적으로 웹페이지의 주소가 바뀌는 경우(301 리다이렉트) 검색엔진은 바뀐 주소를 검색 결과 화면에 노출할 것이다. 그러나 임시로 리다이렉트를 적용하면(302) 검색엔진은 기존의 페이지 주소를 수집한다. 따라서 어떤 페이지 주소를 검색엔진에 등록할 것인가에 따라 리다이렉트 방식을 적용해야 한다.

+ Recent posts