크롤링 프로세스의 단계와 구성 요소

웹사이트를 크롤한다는 것은 무슨 의미일까요?

본격적으로 들어가기 전에 웹사이트 크롤링 프로세스를 정의하고, 그것이 구글 검색결과에 노출되기 위한 모든 시도에서 갖는 중요성을 짚어 보겠습니다.

웹사이트를 크롤한다는 것은 스파이더 또는 크롤러가 웹사이트의 여러 페이지를 돌아다니며, 접근 가능한 모든 정보를 수집해 저장하고 처리한 뒤 분류하는 프로세스로 이해할 수 있습니다.

방금 정리한 정의 안에서 핵심이 되는 몇 가지 용어를 강조해 둘 가치가 있습니다.

• ›

  순회(Journey): 실제 거미를 떠올려 보세요. 이 친근한 곤충은 가능한 한 많은 페이지를 거쳐 가능한 한 많은 정보를 추출해야 합니다. 한 페이지에서 다른 페이지로 이동할 때 그 사이를 연결하는 내부 링크를 통해 이동합니다. 그래서 스파이더가 사이트의 전부는 아니더라도 우리에게 가장 중요한 페이지들을 "발견"할 수 있도록 올바른 내부 링크 구조를 갖추는 것이 중요합니다.

• ›

  접근성(Accessibility): 정보가 이 스파이더에게 접근 가능해야 합니다. 즉, 의도적으로든 실수로든 그들의 접근을 제한하고 있다면, 스파이더가 모든 콘텐츠를 처리하지 못하게 되고, 따라서 그것을 이해하고 분류할 수도 없게 됩니다.

페이지 콘텐츠에 대한 이러한 차단이나 제한은 여러 가지 방식으로 일어날 수 있으며, 글의 뒷부분에서 좀 더 자세히 설명하겠습니다.

크롤러

우리는 스파이더, 즉 크롤러 또는 봇에 대해 이야기했습니다. 이들을 우리 웹사이트의 문서를 분석하는 프로그램, 즉 검색하고 분류하고 정리하는 "사서" 같은 존재라고 정의할 수 있습니다. 이들의 주된 기능은 따라서 데이터베이스를 구축하는 것입니다. 수집하는 정보 종류에 따라 여러 유형이 있습니다. 가장 일반적인 몇 가지를 언급해 보겠습니다.

Googlebot: 우리의 콘텐츠를 크롤하고 자연 검색결과(SERP) 안에서 분류하는 담당 스파이더입니다. SEO 담당자에게 가장 중요한 봇이죠.

이 안에서도 몇 가지 하위 유형을 구분할 수 있습니다.

• ›

  Googlebot (smartphones): 모바일 버전

• ›

  Googlebot (desktop version): 데스크톱 버전

• ›

  Googlebot Images: 이미지 크롤 담당

• ›

  Googlebot News: 뉴스용

• ›

  Googlebot Video: 동영상용

로그에서 확인된 봇 예시:

Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/W.X.Y.Z‡ Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)

이게 전부는 아닙니다. Adsbot, Adsense 등 다른 봇들도 있죠. SEO 분야에서 관련성 높은 것들은 이미 언급했고, 나머지를 구분하는 일은 이 글의 초점은 아닙니다. 추가 정보는 다음 **구글 공식 링크**에서 확인할 수 있습니다.

구글의 크롤링과 색인 프로세스의 단계

이제 크롤링이 무엇인지, 누가 그 기능을 담당하는지, 프로세스에 대해 이야기했으니 좀 더 구체적으로 살펴보겠습니다.

첫 번째 단계: 크롤링과 분류

우리의 페이지가 구글의 결과에 등장하기까지의 프로세스는 살펴본 것처럼 스파이더(크롤러)가 수행하는 첫 번째 크롤링 단계를 거치며, 이를 통해 우리의 콘텐츠를 읽고 해석하고 색인해 분류합니다.

자세히 분석하고 싶은 단어가 바로 이 새로운 단어, 분류입니다. 구글은 우리의 콘텐츠를 단순하고 빠르게 완벽히 이해해야 합니다. 뒤에서 보겠지만, 구글은 우리의 웹사이트에 특정한 시간을 할애하며, 그 시간 안에 콘텐츠를 "이해"하고 사용자의 다양한 검색 의도와 연결지어야 하기 때문입니다.

그래서 현대 SEO에서 **"검색 의도(Search Intent)"**라는 단어가 그렇게 자주 들리는 것입니다. 구글이 분류 과정에서 이를 고려하며, 그것이 SERP 랭킹에서 우리 페이지가 차지할 위치를 결정하기 때문입니다.

따라서 크롤링 프로세스는 깔끔하고, 단순하고, 빠르고, 장애물이 없어야 합니다. 모든 것이 명확해야 우리가 올바르게 분류될 수 있습니다.

두 번째 단계: 색인

분류에 앞서 진행되며 마찬가지로 핵심적인 역할을 하는 색인 단계도 잊을 수 없습니다. 이 단계는 구글이 우리의 콘텐츠를 데이터베이스에 추가, 즉 색인하는 단계이기 때문입니다.

구글 봇 차단

앞서 우리가 스파이더의 콘텐츠 접근을 제한할 수 있는 방법이 있다고 언급했습니다. 이를 위해 SEO에서 매우 중요한 비중을 차지하는 robots.txt라는 요소가 있습니다.

robots.txt 파일은 서버에 업로드하는 텍스트 파일로, 다양한 스파이더에게 사이트의 URL을 크롤하도록 허용하거나 차단하기 위한 정확한 지시를 내립니다. 이 차단은 다음에 적용할 수 있습니다.

• ›

  도메인 전체

• ›

  특정 경로

• ›

  특정 URL

• ›

  또는 특정 패턴에 일치하는 URL 집합

이 파일의 설정 예시를 살펴보겠습니다.

User-agent: *

Disallow: /wp-admin/

Allow: wp-admin/admin-ajax.php

Sitemap: /sitemap.xml

보시다시피 첫 줄에 user-agent를 명시(차단하거나 허용하려는 크롤러의 이름, 앞서 본 것 중 하나)한 뒤, 진입을 금지하는 "disallow" 명령이나 허용하는 "allow" 명령이 따라옵니다.

이 구체적인 사례에서 *를 사용해 "예외 없이 모든 크롤러"를 의미하고 있습니다. /wp-admin/ 경로로의 진입을 금지하면서, 그 경로 안의 /admin-ajax.php에는 진입을 허용하고 있죠.

이 파일의 잘못된 설정은 콘텐츠의 중요한 부분을 차단해 버리는 결과를 초래할 수 있습니다. 사이트를 개발 중에는 전체를 차단해 두었다가 운영 환경으로 옮긴 뒤 그 차단을 해제하는 것을 잊어버리는 흔한 실수가 있는데, 이 경우 구글이 사이트에 접근할 수 없게 됩니다.

구글의 스파이더가 우리 콘텐츠를 크롤할 때 마주칠 수 있는 또 다른 문제는 웹사이트 안의 내부 링크를 따라가지 못하는 것이며, 이로 인해 나머지 URL에 접근하지 못하는 것입니다. 이런 일은 우리가 그 링크에 "href" 대신 javascript 요소를 사용할 때 발생합니다. 이 관행은 사용자 입장에서 JS 사용이 많은 장점이 있어 매우 일반적이지만, 올바르게 사용하지 않고 내부 링크에 더해지면 구글이 따라가지 못할 수 있습니다.

SEO 세계에서는 이를 "링크 난독화(link obfuscation)"라고 합니다. 오늘 시점에서는 구글이 JS로 만들어진 페이지를 올바르게 크롤하고 렌더링할 수 있는지에 대한 논쟁이 여전히 진행 중입니다.

서버 응답 코드

이 프로세스를 잘 이해하려면 SEO 담당자가 매일 다뤄야 하는 개념인 서버 응답 코드를 빼놓을 수 없습니다.

앞서 구글이 우리를 찾는 사이클을 살펴봤는데, 이게 어떻게 일어나는 걸까요? 사용자가 구글에서 검색(쿼리)을 수행합니다. 검색엔진은 자신의 데이터베이스에서 그 검색에 대해 분류된 가장 관련성 높은 결과(SERP)를 보여줍니다.

다양한 결과(노출)를 본 사용자는 자신이 필요로 하는 것에 가장 잘 맞는다고 판단되는 결과를 클릭합니다. 그 순간 웹사이트가 호스팅된 서버에 대한 구글의 요청이 발생하여, 콘텐츠를 "서비스"하도록 합니다.

이때 해당 코드를 통해 서버 응답이 생성됩니다. SEO 담당자로서 고려해야 할 가장 관련성 높은 코드들을 살펴보겠습니다.

• ›

  200: 페이지가 존재하고, 콘텐츠가 있으며, 표시하는 데 문제가 없다는 것을 구글에 알리는 응답 코드입니다. 그 코드 200 페이지의 콘텐츠가 최적이라는 전제 하에, SEO 담당자가 가장 원하는 코드입니다.

• ›

  30x: 30x 상태 코드 계열은 리디렉션에 해당합니다. 가장 주목할 만한 것은 301(영구), 302와 307(임시)입니다. 기본적으로 구글에게 "이봐, 네가 요청한 이 URL A는 더 이상 이게 아니라, 이 다른 URL B야"라고 알려줍니다. 그 외에도 더 있지만, 지금 다루는 개념의 초점은 아닙니다. 권위(authority)를 모두 이전하는 301이 SEO 담당자가 선호하는 코드라는 점은 알아둘 필요가 있습니다.

추천 읽기: 301 리디렉션 튜토리얼

• ›

  40X: 오류 코드입니다. SEO 담당자가 가장 원치 않는 코드입니다. 가장 흔한 것은 그 유명한 404입니다. 이 코드가 등장하면, URL에 대한 구글의 요청에 대해 그 URL이 더 이상 존재하지 않으며 따라서 오류라고 알려주는 것입니다.

• ›

  410: 40x 계열에서 SEO 가치 때문에 따로 짚고 싶은 코드입니다. 이 코드를 사용하면, 어떤 URL에 대한 구글 서버의 요청에 대해 "영원히 사라졌다"고 알리는 것입니다. 흥미로운 점은 404와 달리 구글이 그것이 다시는 거기에 없을 것임을 이해해 더 이상 크롤하려 하지 않는다는 것이며, 404의 경우에는 우리가 고치고 싶어 할 수 있다고 생각하고 다시 크롤한다는 점입니다.

• ›

  50x: 이 유형의 응답은 서버 오류와 연관되어 있습니다. 어떤 이유로 우리의 서버가 실패했을 때, 구글이 어떤 URL의 콘텐츠를 우리에게 요청하면 서버가 실패할 경우 505 상태 코드를 반환합니다.

크롤 예산

지금 시점에서 우리가 다뤄야 할 또 하나의 용어가 있는데, 몇 년 전 SEO 세계에서 인기를 끈 크롤 예산이라는 용어입니다.

크롤 예산은 구글의 스파이더가 웹사이트와 그 모든 URL을 크롤하는 데 소비하는 시간입니다. 앞서 말한 것처럼 유한한 시간이죠. 그래서 그 시간 안에 우리 사이트의 가장 관련성 높은 페이지들이 보이도록 만들기 위해 웹사이트를 최적화하는 것이 중요합니다.

크롤러가 웹사이트를 훑는 데 쓰는 이 시간은 고정된 값이 아니며, 콘텐츠 업데이트 빈도, 도메인의 권위(인기도) 등의 요소에 따라 늘어나거나 줄어듭니다.

웹사이트의 품질이 높을수록, 권위가 클수록, 신선한 콘텐츠가 많을수록 구글은 우리를 더 관련성 높다고 보고 더 많은 예산을 크롤에 할당하게 됩니다.

Screaming Frog 같은 크롤링 프로그램으로는 우리의 웹사이트를 이상적으로 시뮬레이션해 크롤할 수 있습니다. 즉 스파이더가 우리의 모든 URL을 충분한 시간 안에 돌아볼 수 있는 것처럼 말이죠.

하지만 Googlebot에 대해 이야기할 때는 그렇게 작동하지 않습니다. 오히려 구글이 웹사이트를 방문할 때마다 어떤 URL은 다른 URL보다 더 자주 방문하게 됩니다. 사실 어떤 URL은 방문조차 하지 않을 수 있죠. 이는 서버 로그(구글이 어떤 URL을 크롤했는지, 얼마나 자주 했는지, 일정 기간 동안 몇 번 했는지의 기록)로 분석합니다.

여기까지가 크롤링이란 무엇인지 그리고 구글의 크롤링 시스템을 구성하는 다양한 요소들에 대한 이해를 위한 분석입니다.

질문이나 제안이 있으신가요? 늘 그렇듯… 여러분의 의견을 듣고 싶습니다!