로그 파일 분석

요약 — 웹 서버는 Googlebot 같은 검색엔진 봇의 방문을 포함해 받은 모든 요청을 기록합니다. 로그 파일 분석은 이 기록을 읽어 봇이 실제로 가져간 페이지, 빈도, 오류 여부를 확인하는 작업입니다. 실제로 일어난 일을 보여 주는 유일한 곳이지만 대부분의 소규모 사이트에는 필요하지 않습니다.

탭하여 확대

The four-week chart compares automated and human requests to HTML content. Bot share is higher in the captured worldwide Cloudflare traffic period.

로그 파일이란?

사람이나 Googlebot 또는 임의의 봇이 사이트 페이지를 요청할 때마다 서버는 파일에 한 줄을 기록합니다. 이 파일이 액세스 로그입니다. 각 줄에는 대체로 다음 내용이 있습니다.

• 누가 요청했는지(IP 주소와 Googlebot 같은 ‘사용자 에이전트’ 이름)
• 무엇을 요청했는지(URL)
• 언제 요청했는지(타임스탬프)
• 무엇을 돌려받았는지(정상은 200, 찾을 수 없음은 404 등 HTTP 상태 코드)

이 기록이 몇 주 쌓이면 검색엔진이 사이트를 크롤링한 방식을 완전하고 정직하게 볼 수 있습니다. 추정이 아니라 실제 요청입니다.

읽어야 하는 이유

다른 SEO 도구는 봇의 크롤링을 추측하거나(크롤러가 검색엔진처럼 사이트를 순회) 요약합니다(Google Search Console의 표본·반올림 보기). 로그는 요청별 실제 상황을 보여 주므로 다음 질문에 답할 수 있습니다.

• Googlebot이 실제로 방문하거나 무시하는 페이지는 무엇인가?
• 중요한 페이지 대신 쓸모없는 URL에 시간을 낭비하는가?
• 봇이 깨진 페이지(404)나 서버 오류(5xx)를 만나는가?
• 봇이 한 번도 도달하지 않은 페이지가 있는가?

건너뛸 수 없는 규칙

누구나 Googlebot인 척할 수 있습니다. 로그의 사용자 에이전트 이름은 단순 텍스트라 스크레이퍼가 방어를 피하려고 Googlebot을 넣을 수 있습니다. 따라서 ‘Googlebot’ 줄 하나를 믿기 전에 실제 Google인지 검증해야 합니다. 고급·스크립트 탭에 간단한 DNS 검사가 있습니다. 검증을 건너뛰면 가짜 트래픽으로 결론을 내립니다.

정말 필요한가요?

소규모 사이트라면 솔직히 대개 필요하지 않습니다. 로그 파일 분석은 URL이 수만 개인 대규모 사이트, 필터 페이지가 많은 전자상거래, 마이그레이션 중인 사이트, Google이 페이지를 ‘발견’했지만 색인하지 않았다고 표시하는 사이트에서 효과가 큽니다. 페이지가 수백 개이고 모두 정상 크롤링된다면 다른 작업이 낫습니다. 크롤링 예산과 마찬가지로 대부분의 사이트는 걱정할 필요가 없습니다.

봇 검증, 크롤링 낭비, 고아 페이지 찾기까지 실제 절차는 고급 탭을 참고하세요.

요약 — 로그는 모든 요청·봇·상태 코드를 담은 비표본 크롤링 원장입니다. 반드시 먼저 역방향 + 정방향 DNS 또는 Google 공개 IP 범위 JSON으로 Googlebot/Bingbot을 검증하고 검증된 집합만 계산해야 합니다. 사용자 에이전트는 끊임없이 위조됩니다. 이후 가장 많이·적게 크롤링된 URL과 섹션, 시간별 빈도, 빈도 우선 상태 코드, 매개변수·패싯·내부 검색·무한 페이지 같은 크롤링 낭비, 사이트 크롤과 대조한 고아·미크롤링 페이지, 모바일·데스크톱 Googlebot 비율을 읽습니다. Bing은 공식 IP 범위를 공개하지 않아 *.search.msn.com DNS가 검증 방식입니다. 로그는 GSC Crawl Stats를 보완하지 대체하지 않습니다. 2026년에는 AI 봇도 매우 큰 비중을 차지합니다.

로그가 진실한 근거인 이유

검색엔진 크롤링을 ‘보는’ 세 방식은 동등하지 않습니다.

• Screaming Frog SEO Spider나 Ahrefs Site Audit 같은 크롤 도구는 크롤링을 시뮬레이션합니다. 봇이 찾을 수 있는 것을 보여 줄 뿐 Google이 실제 가져간 것은 아닙니다.
• GSC Crawl Stats는 실제 상황을 요약하지만 표본·집계·상한이 있습니다(약 1000개 행, 약 90일, URL별 내보내기 없음).
• 서버 로그는 정확한 URL·타임스탬프·상태 코드와 함께 모든 봇의 모든 요청을 기록합니다.

검토한 Ahrefs 로그 파일 안내서는 서버 로그가 “the most trustworthy source of information to understand the URLs that search engines have crawled.” (번역) 「검색엔진이 크롤링한 URL을 이해하는 데 가장 신뢰할 수 있는 정보원」이라고 설명합니다. 이 기법이 존재하는 이유입니다. Googlebot이 할 수도 있는 일이나 반올림된 요약이 아니라 실제로 한 일을 알려면 로그를 봅니다.

일반적인 로그 줄에는 IP 주소, 사용자 에이전트, URL 경로, 타임스탬프, 요청 메서드(GET/POST), HTTP 상태 코드가 있습니다. 아래 작업은 이 필드를 유용하게 나누는 과정입니다.

실제로 필요한 경우와 그렇지 않은 경우

로그 파일 분석은 대규모 사이트용 도구입니다. URL 수만 개, 전자상거래·패싯 탐색, 마이그레이션 중인 사이트, Discovered – currently not indexed 상태의 사이트에서 값어치를 합니다. 크롤링 예산 안내서에서 “Most sites don’t need to worry about crawl budget, but there are few cases where you may want to take a look.” (번역) 「대부분의 사이트는 크롤링 예산을 걱정할 필요가 없지만 살펴볼 만한 몇 가지 경우가 있습니다」라고 썼습니다. Google Daniel Waisberg도 Crawl Stats에 관해 비슷하게 설명했으며 Search Engine Journal 보도에 따르면 약 1000페이지 미만 사이트에는 큰 걱정거리가 아닙니다.

페이지가 수백 개이고 잘 크롤링된다면 건너뛰고 더 효과가 큰 문제를 고치세요.

로그 구하기(가장 어려운 부분은 접근권)

로그는 요청이 실제로 끝난 곳에 있습니다.

• Apache·Nginx → 가장 흔한 Apache ‘combined’ 로그 형식
• Microsoft IIS → W3C 형식
• AWS ELB/ALB → ELB 형식
• CDN(Cloudflare, Fastly, Akamai) → 자체 로그 내보내기. CDN 앞단 사이트에서 오리진 전용 로그는 에지 캐시 적중을 놓치므로 봇이 실제 도달한 계층의 로그를 가져오세요.

크롤링 빈도 변화를 포착하려면 최소 30일, 이상적으로 90일을 확보하세요. 서버 로그 접근권을 받는 과정 자체가 DevOps 승인 때문에 가장 어려울 때가 많습니다. Google 담당자도 Search Off the Record의 마이그레이션 에피소드에서 실무상 로그 파일 확보가 어렵다고 말했습니다. 요청 시간을 계획하세요.

로그에는 봇뿐 아니라 실제 방문자의 모든 요청이 있으며 URL 경로와 함께 쿼리 문자열, 세션 식별자, 기타 민감 정보가 들어갈 수 있습니다. OWASP 로깅 지침은 인증 자격 증명, 액세스 토큰, 개인 식별 정보를 로그에 직접 남기지 말고 먼저 제거·마스킹·해시하라고 명시합니다. 분석용 로그를 누구에게 넘기기 전에 접근 통제와 내보내기 과정에 반영하세요.

1단계 — 봇이 진짜인지 검증(모든 작업보다 먼저)

많은 안내서가 한 줄로 넘기는 단계지만 그렇게 하지 마세요. Ahrefs 설명대로 많은 봇이 방화벽을 피하려 Googlebot인 척합니다. 사용자 에이전트는 인증되지 않은 텍스트이므로 모든 ‘Googlebot’ 줄을 입증해야 할 주장으로 취급하세요.

Googlebot — 유효한 두 방식:

1. 역방향 + 정방향 DNS(양방향 검사). Google 절차대로 로그 IP에 host 명령으로 역방향 DNS를 실행하고 도메인이 googlebot.com, google.com, googleusercontent.com인지 확인합니다. 그 호스트 이름에 정방향 DNS를 실행해 원래 IP로 돌아오는지 검증합니다. 위조자가 역방향 DNS를 *.googlebot.com처럼 보이게 할 수 있어도 같은 IP로 돌아오는 왕복 검사가 신뢰성을 만듭니다. macOS/Linux·Windows 명령은 스크립트 탭에 있습니다.
2. Google 공개 IP 범위와 대조. Google은 크롤러 IP를 CIDR 형식 JSON으로 공개합니다. Googlebot 등에 common-crawlers.json, special-crawlers.json, 사용자 트리거 fetcher 파일, 전체 Google의 goog.json이 있습니다. Googlebot 안내서에서 Google이 “provided a list of public IPs you can use to verify the requests are from Google… You can compare this to the data in your server logs.” (번역) 「요청이 Google에서 왔는지 확인할 공개 IP 목록을 제공했으며 서버 로그 데이터와 비교할 수 있다」고 설명했습니다.

Bingbot — DNS만 사용. 핵심 차이는 Bing이 공식 IP 범위를 공개하지 않는다는 것입니다. Bing은 “…like other search engines, Bing does not publish a list of IP addresses or ranges from which we crawl the Internet,” (번역) 「다른 검색엔진처럼 인터넷 크롤링에 쓰는 IP 주소나 범위 목록을 공개하지 않는다」고 하며 이유는 “the IP addresses or ranges we use can change any time.” (번역) 「사용하는 IP 주소나 범위가 언제든 바뀔 수 있기 때문」이라고 설명합니다. 따라서 *.search.msn.com으로 끝나는 호스트(예: msnbot-157-55-33-18.search.msn.com)에 역방향 + 정방향 DNS를 사용하거나 Verify Bingbot 도구를 씁니다. 이후 Microsoft가 bingbot IP JSON을 공개했지만 공식 검증 지침은 IP 변경 때문에 여전히 DNS 중심입니다.

가짜는 제외하세요. 모든 크롤링 계산은 검증된 집합만 사용합니다. 검증되지 않은 ‘Googlebot’은 대개 스크레이퍼나 위조 봇이며 크롤링 낭비 분석이 아니라 보안 검토 대상입니다.

2단계 — 확인할 항목

검증된 적중만 남긴 뒤 다음을 읽습니다.

• 가장 많이·적게 크롤링된 URL과 섹션. URL·디렉터리별 요청 순위를 내면 크롤링 예산이 실제 어디에 쓰이는지 드러납니다.
• 시간별 크롤링 빈도. URL·섹션별 추세에서 마이그레이션 문제로 인한 감소나 새 섹션·스파이더 트랩의 무한 URL로 인한 급증을 찾습니다.
• 빈도 우선 봇 상태 코드. 200, 301/302와 체인, 404, 5xx를 정량화합니다. 주 5000회 적중한 404는 한 번 적중한 404와 다릅니다. 존재 여부가 아니라 크롤링 빈도로 우선 처리하세요.
• 크롤링 낭비. 패싯 탐색, URL 매개변수, 내부 검색 결과, 무한 달력·페이지가 예산을 크게 소모할 수 있으며 로그가 봇이 시간을 쓰는 불필요한 패턴을 보여 줍니다.
• 고아·미크롤링 페이지. 두 데이터세트가 모두 필요합니다. 로그에는 있지만 사이트 크롤에는 없는 URL은 고아·오래된 리디렉션·외부 링크 페이지이고, 크롤에는 있지만 로그에 없는 URL은 Google이 가져간 적 없는 페이지입니다.
• 모바일·데스크톱 Googlebot. 사용자 에이전트별로 나눕니다. 모바일 우선 전환 후에는 Googlebot Smartphone이 다수여야 하며 데스크톱 비중이 높으면 조사할 가치가 있습니다.
• 응답 시간·크롤링 상태. 평균 응답 시간이 지속해서 늘면 크롤링 감소와 연관됩니다. Waisberg 안내를 다룬 SEJ 보도는 “Watch out for a consistent increase in average response time. Google says it might not affect crawl rate immediately, but it’s a good indicator that your servers might not be handling all the load.” (번역) 「평균 응답 시간이 꾸준히 증가하는지 살피세요. 크롤링 속도에 즉시 영향을 주지는 않을 수 있지만 서버가 전체 부하를 감당하지 못하고 있음을 보여 주는 지표입니다」라고 설명합니다.

로그가 알려주지 않는 것

데이터를 과도하게 해석하지 않도록 다음을 구분하세요.

• 크롤링 ≠ 색인. Googlebot이 매일 가져가도 계속 미색인일 수 있습니다. 로그는 가져오기만 입증하므로 GSC 페이지 색인·URL 검사와 함께 색인 상태를 확인하세요.
• 크롤링 ≠ 순위이며 더 많이 크롤링해도 도움이 되지 않습니다. “The rate of crawling isn’t going to impact your rankings.” (번역) 「크롤링 속도는 순위에 영향을 주지 않습니다」라고 반복해 설명했습니다. 크롤링 양을 순위 수단처럼 좇지 마세요.
• noindex는 크롤링을 줄이지 않습니다. noindex는 색인만 제어하며 실제 크롤링을 막으려면 robots.txt나 상태 코드를 사용합니다.
• 크롤링 ≠ 모델 학습·인용. 검증된 GPTBot·ClaudeBot·PerplexityBot 적중은 그 요청, 즉 가져오기가 있었음을 입증할 뿐입니다. 모델 학습에 사용됐는지, 이후 보관됐는지, 채팅 답변에 인용됐는지는 별개의 관찰되지 않은 결과입니다.

2026년의 변화: 로그에 가득한 AI 봇

현대 로그 파일의 등장인물이 바뀌었습니다. Cloudflare Radar 분석 새로운 웹 크롤러 만나기에서는 검색엔진 봇이 여전히 가장 많이 크롤링하지만 AI 봇이 확실한 2위이고 몇 년 안에 추월할 추세입니다. GPTBot·ClaudeBot·PerplexityBot 등이 많이 나타나므로 검증 적중을 사용자 에이전트별로 나누면 요청 비중에서 AI 크롤러가 검색엔진과 비슷해도 놀랄 일이 아닙니다. Screaming Frog Log File Analyser도 이를 위한 AI 봇 전용 안내를 추가했습니다.

전체 크롤링에서의 위치

로그는 크롤링 클러스터 전체의 진단 계층입니다. Gary Illyes가 “the number of URLs Googlebot can and is willing or is instructed to crawl” (번역) 「Googlebot이 크롤링할 수 있고 하려 하거나 지시받은 URL 수」라고 정의한 크롤링 예산 소비를 실제로 측정합니다. 달력·패싯의 무한 URL 공간이 거의 같은 요청의 홍수로 나타나는 스파이더 트랩도 잡습니다. 정확한 lastmod, 중요 페이지 내부 링크 같은 크롤링 빈도 작업이 봇 행동을 바꿨는지도 확인합니다. 로그는 GSC Crawl Stats를 보완하지 대체하지 않습니다. Crawl Stats는 표본 입구이고 로그는 비표본·다중 봇·URL별 세부 정보입니다.

AI 요약

고급 버전을 압축하면 다음과 같습니다.

• 로그는 진실한 근거입니다. 크롤 도구는 시뮬레이션하고 GSC는 표본화하지만 서버 액세스 로그는 URL·타임스탬프·상태 코드와 함께 모든 요청과 봇을 기록합니다.
• 분석 전에 검증하세요. 사용자 에이전트는 계속 위조됩니다. Googlebot은 역방향 + 정방향 DNS 또는 Google 공개 IP 범위 JSON, Bingbot은 *.search.msn.com 역방향 DNS로 확인합니다(Bing은 공식 IP 범위를 공개하지 않음). 검증 집합만 계산하세요.
• 읽을 항목: 가장 많이·적게 크롤링된 URL·섹션, 시간별 빈도, 빈도 우선 상태 코드(주 5000회 404 ≠ 한 번), 크롤링 낭비, 크롤과 대조한 고아·미크롤링 페이지, 모바일·데스크톱 Googlebot 비율, 크롤링 상태 경고인 응답 시간 증가
• 과도하게 해석하지 마세요: 크롤링 ≠ 색인 ≠ 순위, 더 많은 크롤링은 순위를 돕지 않고 noindex는 크롤링을 줄이지 않습니다. 검증된 AI 봇 적중은 가져오기만 입증하며 모델 학습·답변 인용을 입증하지 않습니다.
• 범위: 대규모 사이트·전자상거래·마이그레이션 도구이며 소규모 사이트 대부분에는 필요하지 않습니다.
• 2026년: GPTBot·ClaudeBot·PerplexityBot 같은 AI 봇이 로그 트래픽에서 크고 성장하는 비중입니다.
• GSC Crawl Stats를 보완하므로 둘 다 사용하세요.

공식 문서

크롤러 검증과 크롤링 데이터 해석을 위한 1차 출처 문서입니다.

Google

• Google 크롤러·fetcher 요청 검증 — 공식 두 방식인 수동 역방향 + 정방향 DNS와 공개 IP 범위 대조
• Googlebot 검증 방법(Search Central 블로그) — 여전히 인용되는 이전 동반 문서
• common-crawlers.json — CIDR 형식의 Googlebot·공통 크롤러 IP. “the IP addresses in the JSON files are represented in CIDR format” (번역) 「JSON 파일의 IP 주소는 CIDR 형식으로 표시됩니다」. 동반 파일은 special-crawlers.json, user-triggered-fetchers.json, 전체 Google goog.json입니다.
• Google 크롤러·fetcher 개요 — 로그에서 보게 될 모든 Google 사용자 에이전트
• Crawl Stats 보고서(도움말)와 출시 블로그 — 로그가 보완하는 공식 표본 보기

Bing / Microsoft

• Bingbot 검증 방법(웹마스터 도움말) — 공식 검증 페이지
• Bingbot이 진짜 Bingbot인지 확인하는 방법(블로그) — 공식 역방향 + 정방향 DNS와 Bing이 IP 범위를 공개하지 않는다는 설명
• Verify Bingbot 도구 — IP 붙여넣기 검사

출처 인용

공식 기록상 발언입니다. 지원되는 링크는 출처 페이지의 인용 구절로 바로 이동합니다.

Google — 크롤러 검증

• “Run a reverse DNS lookup on the accessing IP address from your logs, using the host command.” (번역) 「host 명령으로 로그의 접근 IP 주소에 역방향 DNS 조회를 실행하세요.」 — Google Search Central 문서. 인용으로 이동
• “Verify that the domain name is either googlebot.com, google.com, or googleusercontent.com.” (번역) 「도메인 이름이 googlebot.com, google.com, googleusercontent.com 중 하나인지 확인하세요.」 인용으로 이동
• “Run a forward DNS lookup on the domain name retrieved in step 1 using the host command on the retrieved domain name.” (번역) 「1단계에서 얻은 도메인 이름에 host 명령으로 정방향 DNS 조회를 실행하세요.」 인용으로 이동
• “Verify that it’s the same as the original accessing IP address from your logs.” (번역) 「로그의 원래 접근 IP 주소와 같은지 확인하세요.」 인용으로 이동

Bing — 검증과 미공개 IP 범위

• “Perform a reverse DNS lookup using the IP address from the logs to verify that it resolves to a name that end with search.msn.com.” (번역) 「로그의 IP 주소로 역방향 DNS를 실행해 search.msn.com으로 끝나는 이름으로 해석되는지 확인하세요.」 — Bing Webmaster 블로그. 인용으로 이동
• “…like other search engines, Bing does not publish a list of IP addresses or ranges from which we crawl the Internet.” (번역) 「다른 검색엔진처럼 Bing은 인터넷 크롤링에 쓰는 IP 주소나 범위 목록을 공개하지 않습니다.」 이유는 “the IP addresses or ranges we use can change any time, so responding to requests differently based on a hardcoded list is not a recommended approach.” (번역) 「사용 IP가 언제든 바뀔 수 있어 하드코딩 목록으로 요청을 다르게 처리하는 방식은 권장되지 않기 때문입니다.」 인용으로 이동

Patrick Stox — 로그 용도 (Ahrefs 작업에서 발췌)

• 서버 로그는 “the most trustworthy source of information to understand the URLs that search engines have crawled.” (번역) 「검색엔진이 크롤링한 URL을 이해하는 데 가장 신뢰할 수 있는 정보원」입니다. 인용으로 이동
• “Many bots pretend to be Googlebot to get past firewalls.” (번역) 「많은 봇이 방화벽을 피하려 Googlebot인 척합니다.」 인용으로 이동
• “If you want to see hits from all bots and users, you’ll need access to your log files.” (번역) 「모든 봇과 사용자의 적중을 보려면 로그 파일 접근권이 필요합니다.」 인용으로 이동
• “The rate of crawling isn’t going to impact your rankings.” (번역) 「크롤링 속도는 순위에 영향을 주지 않습니다.」 인용으로 이동

Google Gary Illyes — 로그로 측정하는 크롤링 예산

• 크롤링 예산은 “the number of URLs Googlebot can and is willing or is instructed to crawl.” (번역) 「Googlebot이 크롤링할 수 있고 하려 하거나 지시받은 URL 수」입니다. 보도 읽기

Google Daniel Waisberg — 크롤링 상태 신호인 응답 시간 (Crawl Stats 안내에 대한 SEJ 설명)

• “Watch out for a consistent increase in average response time. Google says it might not affect crawl rate immediately, but it’s a good indicator that your servers might not be handling all the load.” (번역) 「평균 응답 시간이 계속 늘어나는지 주의하세요. 즉시 크롤링 속도에 영향을 주지 않을 수 있지만 서버가 모든 부하를 처리하지 못한다는 좋은 신호입니다.」 인용으로 이동

봇이 진짜 Googlebot인지 검증(역방향 + 정방향 DNS)

로그의 사용자 에이전트는 단순 텍스트라 스크레이퍼가 방화벽을 피하려 Googlebot을 위조합니다. 신뢰할 검사는 양방향 DNS뿐입니다. IP를 역방향 조회해 Google 도메인인지 확인하고 호스트 이름을 정방향 조회해 같은 IP로 돌아오는지 확인하세요.

macOS / Linux(host 사용)

# 1) Reverse DNS the IP from your logs — it must end in googlebot.com,
#    google.com, or googleusercontent.com
host 66.249.66.1
# → 1.66.249.66.in-addr.arpa domain name pointer crawl-66-249-66-1.googlebot.com

# 2) Forward DNS that hostname back — it must resolve to the same IP
host crawl-66-249-66-1.googlebot.com
# → crawl-66-249-66-1.googlebot.com has address 66.249.66.1

Windows(nslookup 사용)

:: 1) Reverse DNS the IP — confirm it ends in a Google domain
nslookup 66.249.66.1

:: 2) Forward DNS the returned hostname — confirm it matches the original IP
nslookup crawl-66-249-66-1.googlebot.com

역방향 조회가 Google 도메인으로 가지 않거나 정방향 조회가 원래 IP를 돌려주지 않으면 Googlebot이 아닙니다. Bingbot도 같은 두 단계를 실행하되 search.msn.com으로 끝나는 호스트 이름을 기대하세요. DNS 대신 CIDR 형식의 Google 공개 범위 common-crawlers.json과 IP를 대조할 수도 있습니다.

원시 로그에서 크롤러 적중 추출·집계

combined 형식 Apache/Nginx 액세스 로그용 간단한 한 줄 명령입니다. 사용자 에이전트 문자열로 선택하므로 수치를 믿기 전에 IP를 검증하세요.

# Pull only the lines claiming to be Googlebot
grep -i "googlebot" access.log > googlebot-hits.log

# Count Googlebot hits per URL, most-crawled first
# (combined format: $7 is the request path)
grep -i "googlebot" access.log \
  | awk '{print $7}' \
  | sort | uniq -c | sort -rn | head -50

# Count Googlebot hits per status code (combined format: $9 is the status)
grep -i "googlebot" access.log \
  | awk '{print $9}' \
  | sort | uniq -c | sort -rn

# List the URLs Googlebot hit that returned a 404, by frequency
grep -i "googlebot" access.log \
  | awk '$9 == 404 {print $7}' \
  | sort | uniq -c | sort -rn

# Get the unique IPs claiming Googlebot — the list you then verify by DNS
grep -i "googlebot" access.log | awk '{print $1}' | sort -u

로그 형식이 다르면 $7/$9 필드 위치를 조정하세요. IIS/W3C와 ELB는 필드 순서가 다릅니다.

로그 파일 분석 절차

• 로그 확보 — 서버 액세스 로그 또는 CDN/로드 밸런서 내보내기. CDN 앞단 사이트는 오리진 로그가 캐시 적중을 놓치므로 에지 로그도 가져옵니다.
• 충분한 기간 — 최소 30일, 이상적으로 90일
• 봇부터 검증 — 역방향 + 정방향 DNS 또는 Google 공개 IP 범위. Bingbot은 *.search.msn.com DNS 사용
• 가짜 제외 — 검증 집합만 계산하고 위조 ‘Googlebot’은 보안 검토로 전달
• 가장 많이·적게 크롤링된 URL·섹션 순위 — 예산 사용처 확인
• 시간별 크롤링 빈도 추세 — 마이그레이션 감소와 새 섹션·스파이더 트랩 급증 발견
• 상태 코드 집계 — 200 / 301-302 체인 / 404 / 5xx; 존재보다 크롤링 빈도로 우선 처리
• 크롤링 낭비 탐색 — 매개변수, 패싯 탐색, 내부 검색, 무한 페이지·달력
• 고아·미크롤링 페이지 찾기 — 로그와 사이트 크롤 대조(로그만 = 고아, 크롤만 = 미수집)
• 모바일·데스크톱 Googlebot 비율 확인 — Smartphone이 다수여야 함
• 평균 응답 시간 관찰 — 상승 추세가 크롤링을 제한할 수 있음
• AI 봇 분류 — GPTBot·ClaudeBot·PerplexityBot 등이 실제 트래픽 비중 차지
• GSC로 확인 — Crawl Stats·URL 검사와 함께 사용(크롤링 ≠ 색인)

분석 시트에 만들 항목

Screaming Frog Log File Analyser, BigQuery, Ahrefs 로그 파일 템플릿 중 무엇을 쓰든 같은 몇 가지 보기를 만듭니다. 봇 검증 후 각 줄을 열로 파싱하고 피벗하세요.

각 로그 줄에서 파싱할 열

만들 피벗

• URL별 및 디렉터리별 크롤링 내림차순 — 가장 많이·적게 크롤링됨
• 상태 코드별, 이어서 상태 코드 × URL — 빈도 높은 404 강조
• 섹션별 일/주 크롤링 — 빈도 추세
• 봇/사용자 에이전트별 크롤링 — 모바일·데스크톱 비율과 AI 봇 비중
• 로그 URL 목록과 Screaming Frog·Ahrefs 크롤 내보내기를 VLOOKUP/병합한 로그 대 크롤 조인 — 고아·미수집 페이지 노출

Ahrefs 안내서는 이를 설정한 다운로드 템플릿을 제공하며 로그 파일 분석 안내서에서 연결합니다.

로그 파일 해석: 확인할 항목

모든 로그 분석에 반복 적용할 관점입니다. 먼저 검증하고 다음 순서로 진행하세요.

1. 검증 후 분석. 데이터 품질은 봇 신원에 달렸습니다. 역방향 + 정방향 DNS 또는 IP 범위를 사용하고 검증 집합만 분석하세요. 위조 봇은 SEO가 아니라 보안 대상입니다.

2. 예산은 어디에 쓰이는가? (최다·최소 크롤링) URL·섹션별 순위를 내어 잘못된 곳에 쓰이는 관심과 충분히 받지 못하는 중요 페이지를 찾습니다.

3. 봇은 무엇을 만나는가? (빈도별 상태 코드) 200은 정상이고 3xx 체인, 404, 5xx는 누수입니다. 오류 존재 여부가 아니라 봇 적중 빈도로 분류하세요.

4. 무엇이 낭비되는가? (크롤링 낭비) 매개변수, 패싯 탐색, 내부 검색, 무한 페이지·달력이 대표적인 예산 소모처이며 로그가 정확한 문제 패턴을 보여 줍니다.

5. 무엇이 빠졌는가? (고아·미크롤링) 로그와 크롤을 대조합니다. 로그에는 있고 크롤에는 없으면 고아·오래된 리디렉션·외부 링크이고, 크롤에는 있고 로그에는 없으면 Google이 가져간 적 없는 URL입니다.

6. 누가 크롤링하는가? (봇 구분) 모바일·데스크톱 Googlebot 비율은 Smartphone이 다수여야 하며 검색엔진에 가까워진 AI 봇 비중도 확인합니다.

7. 서버가 건강한가? (응답 시간) 평균 응답 시간 상승은 크롤링이 제한될 수 있다는 초기 경고입니다.

로그 파일 분석 도구

• Screaming Frog SEO Log File Analyser — 핵심 데스크톱 도구입니다. 검색 봇을 자동 검증하고 위조 IP를 표시하며 User-Agent + Verification-Status 필터를 제공합니다. SEO Spider 크롤을 가져와 “Not In URL Data” 필터로 고아 페이지를 찾습니다. 즉 “URLs which were discovered in your logs, but are not present in the crawl data imported.” (번역) 「로그에서 발견됐지만 가져온 크롤 데이터에는 없는 URL」입니다. AI 봇 모니터링 전용 안내도 있습니다. 도구
• BigQuery와 Splunk / ELK Stack / Logflare / logz.io — 로그 양이 데스크톱 도구에 너무 클 때 원시 대규모 저장·쿼리
• Ahrefs — 로그를 Ahrefs Site Audit 크롤과 대조해 고아 페이지와 봇 도달 확인
• Semrush Log File Analyzer, OnCrawl, Botify, JetOctopus — 다른 크롤+로그 플랫폼이며 뒤의 세 도구는 엔터프라이즈 중심
• GSC Crawl Stats — 공식 무료 표본 입구. 원시 로그를 대체하지 않고 보완하며 집계·상한·URL별 내보내기 제한이 있습니다.
• Verify Bingbot 도구 — IP를 붙여 진짜 Bingbot인지 확인: bing.com/toolbox/verify-bingbot

피해야 할 실수

• 검증 없이 ‘Googlebot’ 문자열 신뢰. 사용자 에이전트는 누구나 Googlebot을 넣어 방어를 피하거나 가짜 트래픽으로 분석을 오염시킬 수 있는 인증되지 않은 텍스트입니다. 대신: 한 줄이라도 계산하기 전에 역방향 + 정방향 DNS 또는 Google 공개 IP 범위를 사용하세요.
• GSC Crawl Stats를 전체 상황으로 보기. 약 1000개 행과 약 90일로 표본·반올림·상한이 있고 URL별 내보내기가 없어 기록이 아니라 요약입니다. 대신: 로그를 진실한 근거, Crawl Stats를 빠른 보완 입구로 사용하세요.
• CDN 앞단 사이트에서 오리진 로그만 가져오기. 에지 캐시가 처리한 모든 요청을 놓쳐 봇이 실제 받은 내용을 불완전하게 분석합니다. 대신: 오리진뿐 아니라 봇이 도달한 CDN/에지 계층에서 가져오세요.
• 404·5xx를 빈도 아닌 존재로 수정. 월 한 번 적중한 404와 주 5000회 적중한 404는 다른 문제인데 같은 긴급도로 처리하면 노력을 낭비합니다. 대신: 봇의 실제 적중 빈도로 상태 코드 문제 순위를 정하세요.
• 크롤링 양을 순위 수단처럼 좇기. 더 많이 크롤링해도 순위가 오르지 않으며 성장 지표가 아니라 진단 신호입니다. 대신: 극대화할 KPI가 아니라 감소·스파이더 트랩 등 문제를 찾는 데 사용하세요.
• 크롤링을 막으려고 noindex 사용. noindex는 색인만 제어하며 Google이 태그를 보려면 페이지를 가져와야 합니다. 대신: 실제 목표라면 robots.txt나 상태 코드로 크롤링 자체를 막으세요.
• 로그만 보고 URL을 ‘고아’로 부르기. 로그에는 있지만 최신 크롤에는 없는 URL이 오래된 리디렉션·외부 링크·실제 고아 중 무엇인지는 로그만으로 알 수 없습니다. 대신: 결론 전에 실제 사이트 크롤과 대조하세요.

로그 파일 분석 상시 KPI

검증된 봇 비중

• 지표: 사용자 에이전트상 Googlebot/Bingbot이라고 주장하는 전체 적중 중 검증된 Googlebot/Bingbot 적중 비율
• 알 수 있는 것: ‘봇 트래픽’ 중 실제 검색엔진이 아니라 위조 스크레이퍼인 비중
• 수집 방법: 주장된 모든 봇 IP를 역방향 + 정방향 DNS 또는 IP 범위 JSON으로 검사해 통과율 계산
• 벤치마크 / 현실적 범위: 보편 수치는 없으며 스크레이핑 강도에 따라 다릅니다. 고정 기준이 아니라 낮거나 하락하는 검증 비중이 대응 신호입니다.
• 주기: 새 로그 기간을 가져올 때마다

크롤링 낭비 비중

• 지표: 매개변수·패싯·내부 검색·무한 페이지/달력에 적중한 검증 봇 요청 비율(%)
• 알 수 있는 것: 중요 페이지가 아닌 불필요한 URL에 쓰이는 크롤링 예산
• 수집 방법: 쿼리 문자열과 알려진 패싯·검색 경로 등 URL 패턴으로 검증 적중 구분
• 벤치마크 / 현실적 범위: URL 구조와 패싯에 따라 달라 보편 수치는 없습니다. 첫 수집에서 자체 기준선을 만들고 추세를 추적하세요.
• 주기: 30–90일 로그 기간, robots.txt 규칙·매개변수 처리·페이지 수정 후 재검사

빈도 가중 상태 코드 구성

• 지표: 검증 봇 요청 중 200 / 3xx / 404 / 5xx 비율
• 알 수 있는 것: 봇이 정상 콘텐츠 대신 오류에 가져오기를 소모하는 위치와 악화 여부
• 수집 방법: 검증 로그 줄의 상태 코드 필드 집계
• 벤치마크 / 현실적 범위: 사이트 나이와 리디렉션 기록에 따라 달라 보편 목표는 없습니다. 단일 시점보다 추세를 보고 404/5xx 비중 상승에 대응하세요.
• 주기: 30–90일 또는 마이그레이션 직후

모바일·데스크톱 Googlebot 비율

• 지표: 검증 Googlebot 적중 중 Smartphone 사용자 에이전트와 Desktop의 비중
• 알 수 있는 것: 모바일 우선 색인 이후 기대대로 Google이 모바일 우선 크롤링하는지 여부
• 수집 방법: Googlebot UA 문자열(Smartphone 대 Desktop)로 검증 적중 구분
• 벤치마크 / 현실적 범위: 대부분의 사이트에서 Smartphone이 다수여야 합니다. 데스크톱 비중이 높으면 조사할 가치가 있지만 자체로 확정 실패는 아닙니다.
• 주기: 로그를 가져올 때마다

고아 / 미크롤링 페이지 수

• 지표: 로그에는 있지만 최신 크롤에는 없는 URL(고아·오래된 링크)과 최신 크롤에는 있지만 로그에는 없는 URL(미수집)
• 알 수 있는 것: 봇이 쉽게 도달하지 못하는 페이지와 내부 링크가 있지만 Google이 가져가지 않은 페이지
• 수집 방법: 검증 적중 URL 목록을 Screaming Frog·Ahrefs 사이트 크롤 내보내기와 조인
• 벤치마크 / 현실적 범위: 사이트 크기와 최근 마이그레이션·재구성에 따라 전적으로 달라집니다. 외부 수치 대신 시간별 자체 수를 추적하세요.
• 주기: 대규모 사이트는 분기별 또는 마이그레이션 직후

로그 분석용 복사 가능한 프롬프트

이미 가져와 검증한 로그 데이터를 해석하기 위한 것입니다. 로그 데이터를 생성하라는 용도가 아니며 AI가 로그 줄이나 통계를 꾸며내게 하지 마세요.

URL 표본에서 크롤링 낭비 요약

Here is a list of URL paths that verified Googlebot hits landed on, one per
line, from my server logs. Group them into patterns (query parameters,
faceted navigation, internal search, pagination/calendars, or "looks like a
real page"), and tell me which pattern has the most URLs. Don't invent URLs
that aren't in the list — only group what I've pasted.

[paste your URL list here]

예상 결과: 이름이 붙은 소수의 묶음과 개수, 가장 큰 크롤링 낭비 후보 표시입니다. 최종 답이 아니라 실제 경로로 검증할 출발점으로 사용하세요.

상태 코드 구성 우선순위 정하기

I have this table of HTTP status codes and how many times verified Googlebot
hit each one over the last 30 days. Rank them by which I should fix first,
weighting frequency over severity — a 404 hit 5,000 times matters more than a
500 hit twice. Explain the reasoning in one line per row.

status_code, hit_count
[paste your table here]

예상 결과: 수정 우선순위로 재정렬한 같은 행과 각 한 줄의 이유입니다. 실행 전에 사이트 맥락으로 논리를 점검하세요.

DevOps에 로그 접근 요청 초안

Write a short, plain-English email to my DevOps/hosting team asking for
30-90 days of raw web server access logs (Apache/Nginx combined format, or
our CDN's edge logs if we're behind one) for [site name]. Explain in one
sentence why I need it (verifying real Googlebot/Bingbot crawl activity vs
GSC's sampled report) and ask what export format and delivery method works
for them.

예상 결과: 실제 사이트 이름을 넣어 직접 검토·전송할 짧은 이메일 초안입니다. 이 도구는 대신 메시지를 보내지 않습니다.

DNS 검증 결과 설명

I ran a reverse DNS lookup on an IP from my server logs and then a forward
DNS lookup on the hostname it returned. Here's the raw output from the
`host` command. Tell me plainly whether this confirms the request came from
real Googlebot or Bingbot, and point to exactly which line proves or
disproves it.

[paste your host/nslookup output here]

예상 결과: 출력의 특정 줄에 연결된 쉬운 판정입니다. 보조 의견으로만 사용하고 실제 규칙, 즉 호스트 이름이 Google/Bing 도메인으로 끝나며 정방향 조회가 원래 IP를 반환해야 함을 이해하세요.

볼 만한 자료

관련 글

• SEO 로그 파일 분석 방법 [템플릿 포함] — 이 문서가 사용하는 구조와 템플릿의 Ahrefs 핵심 안내
• 언제 크롤링 예산을 걱정해야 하나 — 로그 분석이 시간 가치가 있는 경우와 없는 경우
• Googlebot이란 무엇이며 어떻게 작동하나 — 크롤러와 IP 검증 배경
• 새로운 웹 크롤러: AI 봇이 검색엔진 봇을 따라잡다 — 2026년 로그가 달라진 이유
• 기술 SEO 초보자 가이드 — 전체 기술 SEO에서 크롤링·로그의 위치

발표 자료

• 검색 작동 방식(SlideShare) — 하나의 크롤링 예산 풀을 공유하는 Desktop·Mobile·Image·News·Video·Ads 등 1000개 이상 특수 크롤러 시스템으로서 Googlebot과 주로 Mountain View에서 출발하는 요청을 설명합니다. 올바른 검증을 대체하지 않고 함께 쓰는 로그 타당성 검사입니다. 상시 단서: “This is my understanding of systems… not going to be 100% complete or accurate.” (번역) 「시스템에 대한 제 이해이며 100% 완전하거나 정확하지는 않습니다.」

기타 자료

• Screaming Frog Log File Analyser 사용자 안내와 AI 봇 안내
• Search Engine Land 로그 파일 분석 안내(Kody Wirth) — 형식·도구·확인 패턴의 실무 절차
• Search Engine Journal Google Crawl Stats 보고서 사용법 — 응답 시간 경고를 포함한 Google Daniel Waisberg의 Crawl Stats 안내로 로그 분석의 좋은 동반 자료
• Search Engine Journal 색인·크롤링 예산(Illyes + Splitt) — 크롤링 예산 정의와 품질이 크롤링 수요를 만드는 방식
• Search Engine Roundtable Bingbot IP 주소 공개 — Microsoft가 결국 bingbot IP JSON을 공개했지만 공식 안내는 여전히 DNS 중심이라는 단서
• Conductor SEO 로그 파일 분석 — 로그가 보여 주는 것과 대응 방법에 관한 쉬운 설명
• r/TechSEO — 크롤링·색인 디버깅 커뮤니티

동영상

• Google Search Central(YouTube) — Martin Splitt의 크롤링·렌더링 설명과 로그에서 검증하는 봇의 배경을 다룬 How Google Search Works 시리즈. 채널

퀴즈

봇 검증과 로그가 실제로 보여 주는 내용을 해석하는 문제 다섯 개입니다.

변경 내역