로그 파일 분석(Log File Analysis)은 웹 서버나 CDN이 요청마다 남기는 액세스 로그를 모아, 구글봇 같은 검색 크롤러와 AI 크롤러가 어떤 URL을 언제 얼마나 자주 요청했고 서버가 어떤 상태 코드로 응답했는지 확인하는 테크니컬 SEO 작업이다.
넓은 뜻의 로그 분석은 장애 진단이나 보안 탐지까지 포함하는 IT 운영 용어다. 이 문서는 그 가운데 검색엔진 최적화 목적으로 웹 서버 액세스 로그를 보는 경우를 다룬다.
서치 콘솔이나 크롤링 도구는 크롤러의 행동을 추정하거나 요약해서 보여 주지만, 로그는 실제로 일어난 요청을 한 줄도 빠짐없이 담고 있다는 점이 다르다.
요청 하나가 한 줄로 기록되고, 한 줄에는 요청한 IP, 시각, 요청 URL, 상태 코드, 응답 크기, 리퍼러, 사용자 에이전트가 들어간다. 가장 널리 쓰이는 형식은 Apache의 Combined Log Format이고 Nginx의 기본 형식도 구조가 거의 같다 (Apache HTTP Server, Log Files).
구글봇이 남긴 줄은 대략 이렇게 생겼다.
66.249.66.1 - - [06/Oct/2026:08:12:45 +0900] "GET /wiki/crawl-budget/ HTTP/1.1" 200 18432 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"| 필드 | 예시 값 | SEO에서 보는 것 |
|---|---|---|
| IP 주소 | 66.249.66.1 | 진짜 크롤러인지 검증하는 근거 |
| 시각 | 06/Oct/2026:08:12:45 +0900 | 크롤링 빈도와 시간대 |
| 요청 | GET /wiki/crawl-budget/ | 어떤 URL이 크롤링되는가 |
| 상태 코드 | 200 | 크롤러가 받은 응답 (301, 404, 5xx 비율) |
| 응답 크기 | 18432 | 바이트 단위 전송량 |
| 리퍼러 | - | 크롤러는 대부분 비어 있음 |
| 사용자 에이전트 | Googlebot/2.1 | 어떤 크롤러인가 |
크롤러가 실제로 무엇을 가져갔는지 알려 주는 완전한 기록이 로그뿐이기 때문이다. 서치 콘솔의 크롤링 통계 보고서도 같은 주제를 다루지만 범위에 한계가 있다.
구글은 크롤링 통계 보고서의 예시 URL에 대해 “포괄적이지는 않지만 대표적인 예”이며 목록에 없다고 해서 요청하지 않은 것은 아니라고 설명한다 (Search Console 도움말, 크롤링 통계 보고서). 특정 URL이 지난주에 크롤링됐는지 같은 질문은 로그에서만 확실히 답할 수 있다.
두 번째 이유는 구글 이외의 크롤러다. 크롤링 통계 보고서에는 구글의 요청만 나온다.
Cloudflare 집계에서 2024년 5월부터 2025년 5월 사이 GPTBot의 요청은 305% 늘었고, 같은 기간 AI와 검색 크롤러 요청에서 Googlebot이 차지하는 비중은 30%에서 50%로 커졌다 (Cloudflare, From Googlebot to GPTBot: Who’s crawling your site in 2025). ChatGPT, Claude, 퍼플렉시티의 AI 크롤러가 내 사이트를 얼마나 읽어 가는지는 로그를 열어야 보인다.
세 번째는 크롤링 예산이다. 구글은 사이트가 5xx 오류나 429로 응답하거나 응답 시간이 늘면 크롤링 용량 한도를 내려 크롤링을 줄인다고 밝힌다 (Google 검색 센터, 크롤링 예산 관리). 크롤러에게 나간 오류 응답이 얼마나 되는지는 로그의 상태 코드 열로 바로 센다.
다만 모든 사이트에 필요한 작업은 아니다. 구글은 크롤링 통계 보고서가 고급 사용자용이며 페이지가 1,000개 미만인 사이트는 이 수준의 크롤링 세부정보를 신경 쓰지 않아도 된다고 적는다. 로그 파일 분석도 수만 쪽 이상의 쇼핑몰, 뉴스, 커뮤니티, 그리고 사이트 이전처럼 큰 변경을 앞둔 사이트에서 효용이 크다.
크롤러가 예산을 어디에 쓰는지, 어디서 오류를 만나는지, 어떤 페이지를 놓치는지를 알 수 있다. 실무에서 뽑는 지표는 다음과 같다.
| 확인 항목 | 로그에서 보는 방법 | 발견되는 문제 |
|---|---|---|
| 크롤링 낭비 | 디렉터리와 파라미터별 요청 수 집계 | 필터, 정렬, 세션 파라미터 URL에 요청이 몰림 |
| 오류 응답 | 크롤러 요청의 상태 코드 분포 | 404, 5xx, 리디렉션 체인 |
| 크롤링되지 않는 페이지 | 사이트맵 URL과 로그 URL 대조 | 중요한 페이지에 크롤러가 오지 않음 |
| 고아 페이지 | 로그에는 있고 사이트 크롤링 결과에는 없는 URL | 내부 링크가 끊긴 페이지 |
| 크롤링 빈도 | URL별 마지막 요청 시각과 요청 간격 | 갱신한 페이지가 늦게 재크롤링됨 |
| 크롤러별 비중 | 사용자 에이전트별 요청 수 | AI 크롤러 급증, 가짜 봇 |
가장 자주 나오는 발견은 크롤링 낭비다. 필터나 정렬 파라미터가 붙은 URL, 세션 식별자 URL처럼 색인될 필요가 없는 주소에 크롤러 요청이 얼마나 쓰이는지는 로그를 집계해야 숫자로 나온다.
로그를 확보하고, 진짜 크롤러의 요청만 걸러 낸 뒤, URL 묶음과 상태 코드별로 집계해 사이트 구조와 대조한다.
3단계의 검증은 터미널에서 이렇게 한다.
host 66.249.66.1
1.66.249.66.in-addr.arpa domain name pointer crawl-66-249-66-1.googlebot.com.
host crawl-66-249-66-1.googlebot.com
crawl-66-249-66-1.googlebot.com has address 66.249.66.1로그에는 방문자의 IP 주소가 들어 있으므로 분석용으로 옮기거나 외부 도구에 올릴 때는 크롤러 요청만 추려서 다루는 편이 안전하다.
CDN이나 호스팅 플랫폼의 로그 기능을 쓰고, 그것도 없으면 서치 콘솔 크롤링 통계 보고서로 대신한다.
정적 사이트를 CDN 엣지에서 바로 서빙하는 구조에서는 원본 서버 로그 자체가 없다. 이 위키도 그런 구조여서 Apache나 Nginx 로그 파일이 존재하지 않고, 크롤러 요청은 CDN 쪽 로그에만 남는다. 이런 경우에는 CDN의 로그 내보내기나 봇 분석 화면이 로그 파일 역할을 한다.
크롤링 통계 보고서는 총 크롤링 요청 수, 평균 응답 시간, 응답 코드와 파일 형식별 분포, Googlebot 유형별 분포, 지난 90일의 호스트 상태를 보여 준다 (Search Console 도움말, 크롤링 통계 보고서). 구글에 한정되고 URL 단위 전수 조회는 안 되지만, 로그 없이 볼 수 있는 가장 가까운 자료다.
SEO 전용으로는 Screaming Frog Log File Analyser 같은 데스크톱 도구가 있고, 범용으로는 GoAccess, Elastic Stack, Splunk, Grafana Loki 같은 로그 플랫폼을 쓴다. 파일이 작으면 grep과 awk, 스프레드시트만으로도 크롤러별 요청 수와 상태 코드 분포는 낼 수 있다.
할 수 있다. 다만 로그 원문은 수백만 줄이라 그대로 LLM에 넣기 어렵다. 먼저 크롤러 요청만 걸러 디렉터리와 상태 코드별로 집계한 표를 만들고, 그 표를 근거로 이상 구간을 해석하게 하는 순서가 현실적이다.
서치폴라리스가 AI 검색 가시성을 진단하고 GEO 실행까지 대행합니다.