AI 크롤러가 사이트 링크를 실제로 찾아가는지 확인하는 방법

앞서 소개한 41일 실험처럼, 자바스크립트로 넣은 링크는 사람 눈에는 멀쩡히 보여도 AI 크롤러 대부분에게는 없는 링크나 마찬가지일 수 있습니다. 문제는 이걸 눈으로 봐서는 확인할 수 없다는 점입니다. 브라우저는 자바스크립트를 실행한 뒤의 화면을 보여주기 때문에, 크롤러가 실제로 무엇을 받는지는 따로 확인해야 합니다.

확인 방법은 크게 세 가지로 나뉩니다. 원본 HTML에 링크가 있는지, 각 봇이 실제로 내 사이트에 오는지, robots.txt가 봇을 막고 있지는 않은지입니다. 셋 다 개발자나 별도 도구 없이도 확인할 수 있고, 순서대로 짚어보면 문제가 링크 구조 쪽인지 차단 설정 쪽인지가 갈립니다.

원본 HTML에 링크가 그대로 있는지 본다

가장 먼저 볼 것은 자바스크립트를 실행하기 전 원본 HTML에 링크가 들어 있는지입니다. 확인하는 방법은 두 가지입니다.

하나는 브라우저에서 자바스크립트를 꺼둔 채로 사이트의 주요 경로(카테고리 목록에서 상세 페이지로 넘어가는 링크, 페이지 하단의 "더보기"나 페이지네이션 등)를 실제로 클릭해 보는 것입니다. 클릭이 안 되거나 목록 자체가 비어 있다면, 그 링크는 자바스크립트가 실행된 뒤에야 생기는 링크라는 뜻입니다.

다른 하나는 페이지의 "보기 원본"(view-source) 기능으로 원본 소스를 열어, 실제로 눈에 보이는 링크들이 <a href="..."> 형태로 그 안에 있는지 찾아보는 것입니다. 화면에는 목록이 다 보이는데 원본 소스에는 몇 개만 있다면 나머지는 자바스크립트가 나중에 채워 넣은 링크입니다. 카테고리·태그 목록처럼 페이지 수가 많은 곳일수록 이 차이가 크게 벌어지는 경향이 있습니다.

서버 로그에서 봇 이름을 찾아본다

AI 크롤러는 서버에 접속할 때 자신을 알리는 이름(유저에이전트)을 남깁니다. 서버 접속 로그를 열어 GPTBot, OAI서치봇, 클로드봇, 퍼플렉시티봇, 구글봇, 구글아더, 빙봇, 메타외부에이전트, 아마존봇, 챗GPT유저 같은 이름이 실제로 찍히는지 찾아봅니다.

호스팅 업체나 서버 관리 도구에 따라 접속 로그를 보는 방법은 다릅니다. 직접 서버를 운영한다면 로그 파일에서 이 이름들로 검색해 보고, 별도 로그 도구나 CDN 대시보드를 쓴다면 유저에이전트 기준으로 필터를 겁니다.

여기서 볼 것은 두 가지입니다. 첫째는 해당 봇이 애초에 사이트에 오는지, 둘째는 새로 올린 페이지나 자바스크립트로만 연결되던 구간의 URL에도 그 봇의 접속 기록이 남는지입니다. 목록 페이지에는 자주 오는데 그 안의 상세 페이지에는 기록이 거의 없다면, 목록에서 상세로 이어지는 링크 자체를 봇이 못 찾고 있다는 뜻일 수 있습니다. 반대로 목록 페이지에도 아예 오지 않는다면 링크 문제이기 전에 그 봇 자체가 사이트에 오지 않는 것이므로, 다음 단계인 robots.txt부터 봐야 합니다.

구글 계열은 이름을 구분해서 봐야 합니다. 같은 실험에서 자바스크립트로 넣은 링크를 실제로 따라간 것은 대부분 구글아더였고, 검색 색인을 만드는 구글봇은 같은 페이지를 훨씬 적게 찾았습니다. 로그에 "구글"이 자주 보인다고 해서 그게 검색에 반영되는 구글봇인지, 아니면 다른 목적의 구글아더인지는 유저에이전트 이름까지 따로 확인해야 구분됩니다.

robots.txt가 막고 있는 건 아닌지 확인한다

로그에 특정 봇이 아예 안 보인다면, 링크 문제이기 전에 robots.txt에서 그 봇 자체를 막아뒀을 가능성부터 봐야 합니다. 도메인 뒤에 /robots.txt를 붙여 열어보면 어떤 봇을 막고 허용하는지 그대로 나옵니다.

학습용 크롤러(GPTBot, 클로드봇 등)와 검색 답변용 봇(OAI서치봇, 퍼플렉시티봇 등)을 같은 이름으로 묶어 한꺼번에 막아둔 경우도 있습니다. 검색 답변에 노출되길 원한다면 이 둘을 구분해서 규칙을 따로 넣었는지부터 확인해야 합니다. robots.txt는 봇이 자율로 지키는 규약이라, 여기서 막지 않았는데도 로그에 안 보인다면 방화벽이나 CDN 쪽 설정, 혹은 봇 차단 서비스에서 별도로 막고 있지 않은지도 함께 봐야 합니다.

세 가지를 같이 봐야 원인이 보인다

원본 HTML에는 링크가 없는데 robots.txt는 열려 있다면 링크 구조를 서버 쪽 렌더링으로 바꿔야 하는 경우이고, robots.txt에서 막혀 있다면 규칙부터 고쳐야 하는 경우입니다. 원본 HTML에도 링크가 있고 robots.txt도 열려 있는데 로그에 기록이 없다면, 방화벽이나 CDN 설정처럼 robots.txt 바깥의 차단을 살펴봐야 합니다. 세 가지를 따로 보지 않고 "이 봇이 안 온다"는 결과 하나만 보면 원인을 반대로 짚을 수 있습니다.

링크를 원본 HTML로 바꾸거나 robots.txt 규칙을 고친 뒤에는 곧바로 로그를 다시 확인합니다. 그 실험에서도 봇마다 재방문 속도가 달라, GPTBot은 전환 후 이틀 만에 다시 훑고 갔지만 다른 봇은 일주일 넘게 걸렸습니다. 하루 이틀 안에 안 보인다고 실패로 단정하기보다, 로그를 며칠에 걸쳐 지켜보는 편이 정확합니다.

한 번 확인했다고 끝나는 게 아니다

이 실험에서도 봇의 움직임은 41일 동안 계속 달라졌습니다. 초반에는 전혀 오지 않던 메타외부에이전트가 41일째에야 체계적으로 크롤링을 시작했고, 아마존봇은 반대로 중간에 사이트를 완전히 떠났습니다. 사이트 개편으로 링크 구조가 바뀌거나, robots.txt 규칙을 손봤거나, 새로운 봇 이름이 등장했을 때는 예전에 확인한 결과가 그대로 유지된다는 보장이 없습니다.

한 번 점검해서 문제가 없었다고 그대로 두기보다, 새 섹션을 만들거나 사이트 구조를 크게 바꿀 때마다 같은 세 가지(원본 HTML, 로그, robots.txt)를 다시 확인하는 편이 안전합니다. 특히 프런트엔드 프레임워크를 바꾸거나 렌더링 방식을 서버 쪽에서 클라이언트 쪽으로(또는 그 반대로) 옮기는 개편이라면, 링크가 원본 HTML에 그대로 남는지부터 다시 봐야 합니다.