SEO 로그 파일 분석: 서버 로그를 읽고 크롤 낭비를 고치기

간단 퀴즈

SEO가 맞습니까? 어떻게 시작해야 합니까?

4개 중 1번째 질문25%

사람들이 귀사가 파는 것을 Google에서 검색합니까?

네, 그럴 것 같음아니요, 새롭거나 아주 틈새임모름

서버 로그가 기록하는 것과 다른 데이터보다 나은 이유

누군가 서버에서 파일을 요청할 때마다 서버는 액세스 로그에 한 줄을 씁니다. 대부분의 서버는 Apache의 "combined" 형식과 비슷한 형식을 사용합니다. Googlebot 요청은 다음과 같이 보입니다.

66.249.66.1 - - [13/Nov/2026:08:14:22 +0100] "GET /products/red-running-shoes HTTP/1.1" 200 18342 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

왼쪽에서 오른쪽으로 읽으면 됩니다. IP 주소, 타임스탬프, HTTP 메서드와 URL, 상태 코드(여기서는 200), 전송된 바이트 수, 리퍼러, 사용자 에이전트입니다. 분석 도구에서 페이지 뷰로 나타나지 않는 요청도 모두 여기에 있습니다. 이미지, CSS 파일, 리디렉션, 404 오류가 모두 포함됩니다.

다른 데이터 소스도 각각 일부만 봅니다. Search Console의 크롤 통계 보고서는 집계된 데이터이며 Google 크롤러만 다룹니다. 분석 도구는 브라우저가 사이트의 JavaScript를 실행한 방문자만 기록합니다. Screaming Frog 같은 사이트 크롤러는 링크를 따라 도달할 수 있는 범위를 보여 주는데, 이는 Google이 실제로 요청하기로 한 내용과 같지 않습니다. 실제로 일어난 일을 기록하는 것은 서버 로그뿐입니다.

로그 분석이 중요한 이유: 크롤 예산을 쉽게 설명하면

크롤 예산은 Google이 사이트에서 크롤할 수 있고 크롤하기를 원하는 URL의 집합입니다. Google은 이를 두 가지 요인으로 설명합니다. 첫 번째는 크롤 용량 한도입니다. 서버에 과부하를 주지 않으면서 Google 크롤러가 서버와 동시에 열 수 있는 연결 수입니다. 이 한도는 사이트가 건강하게 유지될 때 올라가고, 응답이 느려지거나 5xx 또는 429 오류가 나면 내려갑니다. 두 번째는 크롤 수요입니다. 사이트 규모, 콘텐츠가 변경되는 빈도, 품질, 페이지의 인기도에 따라 달라집니다.

Google은 이 주제를 대규모 사이트를 위한 심화 가이드로 다룹니다. 대략적인 기준은 콘텐츠가 약 일주일에 한 번 바뀌는 고유 페이지 100만 개 이상의 사이트, 그리고 콘텐츠가 매일 바뀌는 고유 페이지 10000개 이상의 사이트입니다. "Discovered - currently not indexed" 상태의 URL이 많은 사이트도 범위에 포함됩니다. 작은 사이트는 보통 최신 사이트맵과 페이지 색인 생성 보고서를 정기적으로 확인하는 것으로 충분합니다. 그렇다고 로그가 그들에게 쓸모없다는 뜻은 아닙니다. 크롤링에 문제가 생겼을 때 정확히 어디가 문제인지 가장 빨리 보여 주는 것이 로그입니다.

사이트가 이 범위에 들어간다면, 로그를 읽을지 말지가 아니라 얼마나 자주 읽을지가 문제입니다. 일회성 감사는 지금의 낭비를 보여 주고, 월간 내보내기는 수정 사항이 Googlebot이 시간을 쓰는 방식을 바꿨는지 보여 줍니다. 용어의 배경은 크롤 예산 용어집 항목이 기본을 설명하고, Discovered, currently not indexed 가이드는 이런 검토를 보통 촉발하는 상태를 설명합니다.

단계별 방법

아래 워크플로는 어떤 서버, 어떤 도구에서든 동작합니다. 이후 섹션은 각 단계를 자세히 설명하고, 원시 로그 파일에 오늘 바로 실행할 수 있는 명령을 제공합니다.

올바른 계층에서 로그 가져오기

개발자나 호스팅 제공업체에 웹 서버(Apache, Nginx 또는 IIS)의 원본 액세스 로그를 요청하세요. 시작하기 전에 세 가지를 확인합니다. 로그 형식, 시간대, 보관 기간입니다. 설정에 따라 오래된 로그는 며칠 또는 몇 주 후에 순환 삭제될 수 있으니, 나중이 아니라 지금 내보내기를 요청하세요.

이 계층은 많은 사람들이 예상하는 것보다 중요합니다. CDN이 캐시에서 요청에 응답하면 원본 서버는 그 요청을 전혀 보지 못합니다. Googlebot은 원본 로그에 나타나지 않는 URL을 크롤할 수 있으므로, 원본만 내보내면 캐시된 콘텐츠에 대한 크롤 활동을 과소 집계하게 됩니다. CDN 로그도 함께 내보내고, 어느 한쪽의 합계를 신뢰하기 전에 몇 개 URL에 대해 두 출처를 비교하세요.

몇 가지 명령으로 Googlebot 필터링하고 세기

combined 형식의 로그에서 상태 코드는 9번째 필드이고 URL 경로는 7번째 필드입니다. 이 두 열이면 대부분의 첫 질문에 답할 수 있습니다. 다음 명령은 상태 코드별로 Googlebot 요청을 셉니다.

grep "Googlebot" access.log | awk '{print $9}' | sort | uniq -c | sort -rn

이 명령은 쿼리 문자열을 제거해 필터 변형이 함께 묶이도록 하고, Googlebot이 가장 많이 요청한 경로 20개를 보여 줍니다.

grep "Googlebot" access.log | awk '{print $7}' | cut -d '?' -f1 | sort | uniq -c | sort -rn | head -20

첫 번째 명령은 사용자 에이전트 텍스트를 읽으며, 이것은 누구나 위조할 수 있습니다. 다음 섹션을 마치기 전까지는 그 출력을 후보 목록으로 취급하세요. 또한 로그가 사용자 정의 형식이면 필드 번호가 달라지므로, 열을 신뢰하기 전에 한 줄을 직접 확인하세요.

Google이 설명하는 방식대로 Googlebot 검증하기

방문자가 Googlebot인지 확인하는 Google 자체의 방법은 DNS를 사용합니다. 로그의 IP 주소에 역방향 DNS 조회를 실행하고, 호스트 이름이 googlebot.com, google.com 또는 googleusercontent.com으로 끝나는지 확인한 다음, 그 호스트 이름에 정방향 조회를 실행해 원래 IP가 반환되는지 확인합니다. Google의 문서는 66.249.66.1이 crawl-66-249-66-1.googlebot.com으로 역방향 해석되는 예를 사용합니다.

host 66.249.66.1

정방향 확인은 두 번째 명령이며, 같은 IP를 반환해야 합니다.

host crawl-66-249-66-1.googlebot.com

수백만 줄을 처리한다면 DNS 조회는 느려집니다. Google은 Googlebot용 common-crawlers.json을 포함해 크롤러 IP 범위가 담긴 JSON 파일도 공개합니다. 이 범위와 대조하는 편이 더 빠르며, 공식 검증 가이드에서 Googlebot 검증에 관한 Google 가이드로 두 방법을 모두 설명합니다.

그룹화하고 측정해 결과 읽기

URL별 원시 개수는 실행하기 어렵습니다. 수정은 보통 한 페이지가 아니라 템플릿 단위로 적용되므로, 먼저 URL을 템플릿별로 그룹화하세요. 그다음 각 그룹에 대해 네 가지를 측정합니다. 비즈니스 중요도에 비해 Googlebot 히트를 얼마나 받는지, 상태 코드 구성은 어떤지, 발행 후 새 페이지가 첫 히트를 얼마나 빨리 받는지, 히트가 순위를 원하는 페이지에 집중되는지입니다.

결과는 단일 숫자가 아니라 패턴으로 읽으세요. Googlebot 히트 대부분이 필터 URL에 몰리고 제품 페이지에는 일부만 간다면 크롤 예산이 새고 있는 것이며, 문제는 제품 페이지보다 내부 링크나 매개변수 처리일 가능성이 높습니다. 다음 섹션은 찾아야 할 신호를 나열합니다.

로그에 숨어 있는 일곱 가지 신호

Googlebot 줄이 검증되고 그룹화되면, 일곱 가지 신호가 대부분의 크롤 문제를 설명합니다. 아래 표는 찾아야 할 패턴과 일반적인 수정 방법을 보여 줍니다. 각 수정은 사이트의 변경이므로 다음 내보내기에서 확인하세요.

신호	로그에 나타나는 내용	할 일
크롤 낭비	필터, 정렬 순서, 사이트 내 검색, 세션 URL에 대한 Googlebot 히트	canonical로 통합하고, 이 URL로 가는 내부 링크를 제거하며, 통합할 수 없는 쓸모없는 변형은 robots.txt로 차단합니다
리디렉션	301 또는 302 응답에 대한 히트, 두 번 이상 거치는 리디렉션 체인	최종 URL로 직접 링크합니다. 301 대 302 가이드가 올바른 리디렉션 유형을 고르는 데 도움이 됩니다
오류	404 또는 410에 대한 반복 히트, 5xx 응답의 급증	여전히 중요한 페이지는 복구하거나 리디렉션하고, 5xx 응답은 Google의 크롤량을 줄이므로 서버 오류를 고칩니다
누락된 크롤	기간 내에 Googlebot 히트가 전혀 없는 중요한 URL	내부 링크, 사이트맵 항목, 크롤러를 멀리 밀어낼 수 있는 robots.txt 규칙을 확인합니다
중복	끝의 슬래시, 대문자, 매개변수 등으로 여러 URL에서 같은 콘텐츠가 히트됨	정식 URL 하나를 고르고 어디서든 그 URL로 링크합니다
첫 크롤까지의 시간	새 페이지가 발행된 후 첫 Googlebot 히트까지의 시간	자주 크롤되는 페이지에서 새 페이지로 링크하고, 사이트맵을 깔끔하게 유지합니다
응답 시간	Googlebot 히트가 가장 많은 템플릿에서의 느린 응답	Google은 응답이 느리면 크롤을 덜 한다고 말하므로, 이 템플릿을 가장 먼저 빠르게 만듭니다

"누락된 크롤" 행은 사람들이 자주 건너뛰는 행이며, 종종 가장 비용이 큽니다. 로그에 한 번도 나타나지 않는 페이지는 콘텐츠가 훌륭하더라도 아무 순위도 얻지 못할 수 있습니다. URL이 사이트맵에는 있는데 로그에 전혀 나타나지 않는다면, 그 페이지는 아마 크롤러가 따라가지 않는 경로로만 도달 가능할 것입니다. Crawled, currently not indexed 가이드는 Googlebot이 페이지를 방문했지만 여전히 색인하지 않는 반대 상황을 다룹니다.

분석을 실행하는 세 가지 방법 비교

로그 분석은 스크립트, 데스크톱 애플리케이션 또는 플랫폼으로 실행할 수 있습니다. 각각은 다른 규모와 다른 팀에 맞습니다. 올바른 선택은 사이트 규모보다는 답이 얼마나 자주 필요한지, 그리고 누가 그 결과를 읽는지에 더 크게 좌우됩니다.

명령줄: grep, awk, Python

원리: 스크립트로 원본 파일을 파싱하고 결과를 파일이나 스프레드시트에 씁니다. 사용 시점: 일회성 점검, 소규모 사이트, 또는 완전한 제어를 원하는 개발자. 장점: 무료이고, 모든 줄을 볼 수 있으며, 예약 작업으로 자동화할 수 있습니다. 한계: 작성하고 유지하는 데 시간이 걸리고, 컴퓨터 성능만큼만 빠르며, 차트가 없고, 봇은 직접 검증해야 합니다.

예시: 방법 섹션의 명령을 같은 내보내기에 대해 한 달에 한 번 실행하면 Googlebot의 상태 코드 구성과 상위 경로를 얻을 수 있습니다. 짧은 Python 스크립트도 같은 일을 하면서 DNS 검사를 추가할 수 있으며, 이는 느리지만 더 정확합니다.

데스크톱 도구: Screaming Frog Log File Analyser

원리: 원본 로그를 데스크톱 프로젝트로 가져오면, 도구가 봇을 그룹화하고, 신원을 확인하고, 차트를 그립니다. 사용 시점: URL이 수만 개인 사이트에서 작업하는 컨설턴트나 사내 분석가. 장점: W3C Extended 형식의 Apache, IIS, Nginx 로그를 읽고, 검색 엔진 봇을 검증하며, 크거나 느린 페이지를 표시합니다. 한계: 무료 버전은 제한이 있으며, 불러올 수 있는 데이터 양은 하드 디스크에 따라 달라집니다.

구매하기 전에 Screaming Frog Log File Analyser 페이지를 읽어 보세요. 함께 쓰는 크롤러에 대한 전체 안내는 Screaming Frog SEO Spider 가이드를 참고하세요. 로그 분석기는 크롤러가 할 수 없는 한 가지 일을 합니다. 링크가 암시하는 내용이 아니라, 봇이 실제로 요청한 내용을 보여 줍니다.

플랫폼: 지속적인 로그 모니터링

원리: 플랫폼은 대개 CDN이나 서버에서 일정에 따라 로그를 받아, 사이트 크롤 데이터 및 색인 데이터와 결합합니다. 사용 시점: 여러 시장에 걸쳐 매주 크롤을 모니터링하는 대형 이커머스 사이트나 엔터프라이즈 팀. 장점: 매우 큰 로그도 처리하고, 이력을 보관하며, 여러 팀이 대시보드를 공유할 수 있습니다. 한계: 비용이 더 높고, 도입에 시간이 걸리며, 벤더 종속은 현실적인 문제이므로 약정하기 전에 데이터를 어떻게 내보낼 수 있는지 확인하세요. 이 범주의 벤더로는 Oncrawl과 Botify가 있으며, 각 벤더에게 봇을 어떻게 검증하는지 물어볼 만합니다.

기준	명령줄	데스크톱 도구	플랫폼
비용	무료	로그 이벤트 1000개까지 무료, 전체 라이선스는 연 99파운드	구독, 가격은 볼륨에 따라 다름
설정	스크립트를 직접 작성하고 유지	설치, 가져오기, 시작	커넥터와 온보딩
볼륨	컴퓨터 성능에 제한됨	하드 디스크와 라이선스에 제한됨	매우 큰 로그용으로 설계됨
봇 검증	수동, DNS 또는 IP 범위 검사 사용	기본 제공	벤더에게 문의
적합한 대상	일회성 점검과 소규모 사이트	컨설턴트와 중간 규모 사이트	주간 모니터링을 하는 엔터프라이즈 및 이커머스 팀

Google 크롤 통계 보고서: 유용하지만 충분하지 않음

로그를 하나라도 내보내기 전에 Search Console의 크롤 통계 보고서를 여세요. 이 보고서에는 총 크롤 요청 수, 총 다운로드 크기, 평균 응답 시간, 유형별로 그룹화된 응답, 파일 유형, 크롤 목적, 각 요청을 수행한 Googlebot 유형이 표시됩니다. 추세를 확인하기에는 가장 빠른 보기이며, Google Search Console 튜토리얼에서 위치를 설명합니다.

그 한계가 로그가 여전히 중요한 이유를 설명합니다. 이 보고서는 도메인 속성과 루트 수준 URL 접두사 속성에서만 사용할 수 있습니다. Google 크롤러만 다루므로 GPTBot, ClaudeBot 및 기타 봇은 빠져 있습니다. URL을 하나씩 나열하지 않고 데이터를 그룹화하므로, 크롤 요청이 줄었다는 것은 알려 줄 수 있어도 어떤 템플릿이 그것을 잃었는지는 알려 주지 못합니다. 이 보고서로 무언가 바뀌었음을 알아채고, 로그로 무엇이 바뀌었는지 알아내세요.

Google의 크롤 통계 도움말 페이지는 각 그룹화 방식을 설명합니다. 차트와 로그 내보내기가 맞지 않으면, 시간 범위와 검증 단계를 확인하기 전까지는 어느 쪽도 믿지 마세요. 이런 불일치 대부분은 다른 시간 범위, 캐시에서 응답하는 CDN, 또는 검증되지 않은 요청을 포함한 봇 수에서 비롯됩니다.

크롤 낭비를 확인했을 때 고치기

수정 사항은 신호에서 나옵니다. 대부분은 세 가지 동작으로 귀결됩니다. 중요하지 않은 페이지로 크롤러를 보내지 않기, 페이지가 이동했을 때 최종 URL로 곧장 보내기, 그리고 중요한 페이지를 더 빨리 로드되게 만들기입니다.

패싯 내비게이션. 필터와 정렬 순서는 거의 같은 콘텐츠를 가진 많은 URL을 만듭니다. 가능하면 canonical로 통합하고, 검색 가치가 없는 변형으로 가는 내부 링크를 제거하세요. 통합할 수 없고 크롤에서 제외되어야 하는 변형이라면 robots.txt에서 차단하세요. 여기서 Google의 지침은 구체적입니다. 이 목적에 noindex를 쓰지 마세요. Google은 태그를 보려면 여전히 페이지를 요청해야 하기 때문입니다. 테스트해 볼 만한 규칙의 예는 다음과 같습니다.

User-agent: Googlebot
Disallow: /*?sort=
Disallow: /*?color=

robots.txt 변경은 적당히 하세요. Google은 사이트가 이미 용량 한도에 도달한 경우가 아니라면, URL을 차단해도 다른 페이지의 크롤 예산이 생기지 않는다고 말합니다. 차단은 가치 없는 URL을 위한 것이지, 최고의 페이지로 예산을 밀어주는 수단이 아닙니다. 저희 robots.txt 용어집 항목은 이 파일이 어떻게 읽히는지 설명합니다.

리디렉션 체인. 페이지가 두 번 이동했다면, 크롤러는 매번 두 리디렉션을 모두 거칩니다. 내부 링크를 최종 URL을 가리키도록 업데이트한 다음, 외부 링크를 위해 오래된 리디렉션은 그대로 두세요. 영구 리디렉션과 임시 리디렉션 중 무엇을 쓸지도 같은 이유로 중요하며, 301 대 302 가이드가 자세히 다룹니다.

삭제된 페이지. 영구적으로 제거된 페이지에는 404 또는 410을 반환하세요. Google은 소프트 404가 계속 크롤되어 크롤 예산을 낭비한다고 말합니다. 따라서 200 상태로 제공되는 '페이지를 찾을 수 없음' 메시지는 실제 404보다 나쁩니다.

응답 시간과 캐싱. Google은 느리거나 실패하는 응답 때문에 크롤을 덜 한다고 말합니다. 변경되지 않은 페이지를 캐시에서 제공할 수 있도록 304(Not Modified) 응답을 지원하세요. 그다음 Googlebot 히트를 가장 많이 받는 템플릿을 살펴보고, 그 응답을 먼저 빠르게 만드세요.

가장 큰 손해를 주는 실수와 피하는 방법

잘못되는 로그 분석 대부분은 아래의 작은 실수 목록 중 하나를 저지릅니다. 각 실수마다 데이터에서 발견할 수 있는 증상과, 같은 주에 적용할 수 있는 수정이 있습니다.

사용자 에이전트 문자열을 신뢰하기

무엇인지: "Googlebot"이라고 말하는 모든 요청을 Google의 크롤로 세는 것. 발견하는 방법: Google 호스트 이름으로 역방향 해석되지 않는 IP 주소에서 온 Googlebot 히트, 또는 단일 주소에서 갑작스럽게 늘어난 히트. 고치는 방법: 무언가를 세기 전에 방법 섹션의 검증을 실행하고, 검증되지 않은 히트는 별도의 버킷에 보관해 스크래퍼 활동도 계속 볼 수 있게 하세요.

200 응답만 읽기

무엇인지: 200을 반환하는 페이지에만 집중하고 나머지는 무시하는 것. 발견하는 방법: 보고서에 3xx, 4xx, 5xx 섹션이 없거나, 상태 코드 구성이 한 번도 논의되지 않음. 고치는 방법: 항상 상태 코드 분포부터 시작하세요. 404 히트의 증가는 깨진 내부 링크를, 5xx 히트의 증가는 전체 크롤을 느리게 하는 서버 문제를 드러낼 수 있습니다.

색인에서 제거하려는 페이지를 차단하기

무엇인지: noindex 태그도 있는 페이지에 robots.txt 규칙을 추가하는 것. 발견하는 방법: 페이지가 색인에 남아 있고, 크롤러가 요청을 차단당했기 때문에 로그에 Googlebot 히트가 보이지 않음. 고치는 방법: Google이 noindex 태그를 읽을 수 있도록 차단을 풀고, 페이지가 색인에서 빠질 때까지 기다린 뒤, 여전히 필요하다면 차단을 다시 적용하세요. Blocked by robots.txt 가이드는 이 경우 나타나는 Search Console 상태를 설명합니다.

길이가 다른 기간 비교하기

무엇인지: 수정 전 3일 내보내기와 수정 후 30일 내보내기를 비교하는 것. 발견하는 방법: 합계는 크게 움직이지만 템플릿별 비율은 움직이지 않음. 고치는 방법: 가능하면 같은 일수, 같은 시기끼리 비교하고, 볼륨이 바뀔 때는 원시 합계가 아니라 비율을 비교하세요.

가치가 아니라 히트를 측정하기

무엇인지: 색인되는 페이지에 도달하는지 확인하지 않고 Googlebot 히트가 늘었다고 기뻐하는 것. 발견하는 방법: 히트가 색인되지 않았거나 트래픽을 전혀 얻지 못하는 URL에 집중됨. 고치는 방법: 로그 그룹을 Search Console의 URL 검사 도구에서 얻은 색인 상태와 결합하고, 크롤이 중요한 페이지 쪽으로 이동했을 때만 수정을 성공으로 간주하세요.

같은 로그에서 AI 봇은 어디에 해당하나

같은 로그는 AI 크롤러가 사이트에서 무엇을 하는지도 보여 줍니다. 방법은 같습니다. 그룹화하고, 벤더가 검증 방법을 제공하는 경우 검증하고, 상태 코드를 읽으세요. AI 크롤러 로그 가이드는 찾아야 할 봇과 Googlebot과 어떻게 다른지를 다룹니다. 이 글은 Googlebot 방법을 깊이 다루며, 아래 섹션은 두 가지를 하나의 보고서로 합치는 방법을 보여 줍니다.

봇 유형	예시	로그에서 확인할 것	더 읽을거리
검색 크롤러	Googlebot	템플릿별 히트, 상태 코드 구성, 새 페이지의 첫 크롤까지 걸리는 시간	이 글의 위 섹션들
학습 크롤러	GPTBot, ClaudeBot, CCBot	콘텐츠를 아예 요청하는지, robots.txt를 존중하는지	AI 크롤러용 Robots.txt
검색 증강 크롤러	ChatGPT-User, PerplexityBot	사용자 질문과 연결된 짧은 방문 급증과, 그 급증이 도달하는 페이지	AI 크롤러 로그

학습과 검색 증강의 구분은 AI 크롤러가 문서화된 방식에서 비롯됩니다. 학습 크롤러는 모델을 위해 콘텐츠를 수집하고, 검색 증강 크롤러는 사용자가 질문할 때 페이지를 가져옵니다. 보고서에서 둘을 분리해 두어야 합니다. 한쪽에 대한 정책 결정이 다른 쪽에 자동으로 적용되지는 않기 때문입니다.

이 수정 사항을 적용하면서 Google 트래픽과 AI 트래픽을 나란히 보고 싶다면, Sorank의 GEO / SEO 대시보드가 둘을 한 화면에서 보여 줍니다. 로그에서 얻은 변경이 크롤 수치뿐 아니라 트래픽도 움직이는지 확인하는 데 쓰세요.