구글봇 HTTP 메서드 확장, 서버 로그 분석 가이드

구글의 크롤러가 페이지를 가져올 때 쓰는 요청 방식은 오래도록 GET 하나뿐이라고 알려져 있었다. 그런데 2026년 8월, 구글의 검색 애널리스트 게리 일예스(Gary Illyes)가 링크드인에서 이 통념을 직접 뒤집었다. 구글의 크롤러들이 GET과 POST 외에도 HEAD·OPTIONS·PUT·PATCH·DELETE 요청까지 보내고 있다는 사실을 공개한 것이다.

비중은 전체 요청의 1.5퍼센트 미만으로 크지 않다. 하지만 서버 로그를 직접 들여다보는 운영자라면 "왜 구글봇 IP에서 DELETE 요청이 찍히지?" 같은 낯선 로그 한 줄에 당황할 수 있다. 이 글은 그 원인과, 진짜 구글봇인지 가짜 봇인지 구분하는 법, 방화벽·robots.txt로 안전하게 대응하는 법을 실무 순서대로 정리했다.

이 글에서 먼저 챙겨 갈 핵심만 추리면 이렇다.

• 구글이 공식 확인한 내용: 구글 크롤러가 HEAD·OPTIONS·PUT·PATCH·DELETE까지 보내며, 전체 요청의 1.5퍼센트 미만이고 원인은 자바스크립트 렌더링 과정이다
• 이런 요청이 실제 서버 로그에 어떤 모양으로 남는지, 왜 렌더링 단계에서 발생하는지에 대한 기술적 배경
• 논의 중인 새 HTTP 표준 QUERY 메서드와는 아직 별개 사안이라는 것, 구글이 이를 크롤링에 쓴다는 공식 발표는 없다는 것
• 서버 로그에서 진짜 구글봇인지 가짜인지 역방향 DNS 조회와 공식 IP 대역 파일로 검증하는 4단계 절차, 그리고 명령어 예시
• GPTBot·클로드봇·퍼플렉시티봇 같은 AI 크롤러는 구글봇과 완전히 다른 주체라는 점과 구분하는 법
• 방화벽·CDN에서 이런 요청을 안전하게 허용하거나 차단해도 검색 순위에 불이익이 없는 이유와 실무 설정 예시

조금 더 풀어보면, 이번 발표가 중요한 이유는 "새로운 위협"이어서가 아니라 로그 분석의 기준이 바뀌었기 때문이다. 지금까지는 구글봇 로그에서 GET 이외의 메서드가 보이면 십중팔구 가짜 봇이나 스크래퍼를 의심하는 것이 정석이었다. 이제는 진짜 구글봇도 그런 요청을 남길 수 있으므로, 메서드 종류만으로 판단하지 말고 출처 IP를 함께 검증하는 습관이 필요해졌다.

이 글은 서버 로그를 직접 열어 보는 운영자, 개발자, 그리고 방화벽·CDN 규칙을 관리하는 담당자를 염두에 두고 썼다. 전문 용어가 나올 때마다 바로 뒤에 쉬운 말로 풀어 적었으니, 서버 로그를 처음 열어 보는 사람도 순서대로 읽으면 오늘 바로 자기 사이트 로그를 확인할 수 있다.

이 문제가 앞으로 더 흔해질 가능성이 크다는 점도 짚어 둘 만하다. 국내 홈페이지·쇼핑몰 제작에서도 리액트·뷰 같은 자바스크립트 프레임워크로 화면을 그리는 방식이 계속 늘고 있고, 이런 구조일수록 페이지 안에 API 호출 코드가 많아 앞으로 이런 요청을 마주칠 사이트의 범위도 함께 넓어질 것으로 보인다. 지금 미리 구분법과 대응법을 익혀 두면 나중에 당황하지 않는다.

사실 구글봇의 통신 방식이 바뀐 것이 이번이 처음은 아니다. 구글은 2020년 9월에도 구글봇이 기존 HTTP/1.1 대신 HTTP/2(같은 연결로 여러 요청을 동시에 처리해 속도를 높인 프로토콜)로도 크롤링을 시작한다고 발표한 적이 있다. 그때도 사이트 운영자가 별도로 조치할 일은 거의 없었고, 원치 않으면 서버 설정으로 HTTP/1.1만 쓰도록 되돌릴 수 있는 정도였다. 이번 HTTP 메서드 확장도 같은 맥락으로 보면 이해가 쉽다. 크롤러의 통신 방식은 계속 진화해 왔고, 그때마다 사이트 운영자에게 요구되는 일은 "이해하고 필요하면 검증하는 것"이지 "무조건 차단하는 것"이 아니었다.

구글봇이 HEAD·OPTIONS·PUT·PATCH·DELETE도 보낸다는 게 무슨 뜻인가?

결론부터 말하면, 구글 크롤러가 페이지를 렌더링하는 과정에서 페이지 안의 자바스크립트 코드가 실행하는 요청을 그대로 따라가다 보니 이런 메서드가 발생한다. 일예스는 이를 "일부 자바스크립트가 이런 요청을 일으키고, 렌더링 과정이 그것을 그대로 수행한다"고 설명했다.

이해를 도우려면 각 메서드가 원래 무엇을 위해 만들어졌는지부터 짚어야 한다. 아래 표로 정리했다.

메서드	원래 용도	구글봇 로그에 남는 이유
GET	페이지·리소스를 그대로 가져오기	구글봇 크롤링의 기본이자 절대다수
HEAD	본문 없이 응답 헤더만 확인	페이지 존재·변경 여부를 가볍게 먼저 확인할 때
OPTIONS	서버가 허용하는 메서드를 사전 조회(CORS 프리플라이트)	페이지 내 자바스크립트가 다른 도메인의 API를 호출하기 직전에 브라우저(와 렌더링 엔진)가 자동으로 보냄
PUT	서버의 특정 자원을 통째로 생성·교체	페이지 스크립트가 저장·업로드 API를 호출하는 코드를 렌더링 중 실행
PATCH	자원의 일부만 수정	폼 제출·설정 변경 API를 호출하는 스크립트가 실행될 때
DELETE	자원을 삭제	장바구니 삭제, 계정 탈퇴 같은 버튼의 이벤트 코드가 렌더링 중 실행될 때

여기서 짚어야 할 좋은 예와 나쁜 예가 있다. 나쁜 예는 이런 로그를 보자마자 "해킹 시도"나 "가짜 봇"으로 단정하고 해당 IP 전체를 서버 방화벽에서 영구 차단해 버리는 대응이다. 만약 그 IP가 실제 구글 IP 대역이었다면, 정상적인 페이지 크롤링까지 함께 막혀 색인 누락으로 이어질 수 있다.

좋은 예는 순서를 지키는 것이다. 먼저 해당 IP가 진짜 구글 소유인지 검증하고(다음 장에서 다룬다), 진짜라면 차단할 필요 없이 그대로 두는 것이다. 구글 자신도 이 요청들이 사이트 소유자의 별도 조치를 요구하는 사안이 아니라고 설명했다. 렌더링 엔진이 페이지 코드를 실행하다 보니 부수적으로 남는 흔적일 뿐, 실제로 서버의 데이터를 생성·수정·삭제하겠다는 의도가 아니기 때문이다.

구글봇이 PUT·PATCH·DELETE를 보냈다고 해서 그 요청이 실제로 성공해 서버 데이터가 바뀐다는 뜻은 아니다. 대부분의 서버는 인증 없는 이런 요청에 404나 405 같은 오류 응답을 정상적으로 돌려주고, 그것으로 끝이다.

왜 하필 렌더링 단계에서 이런 요청이 발생하나?

이 질문에 답하려면 구글이 페이지를 처리하는 방식부터 알아야 한다. 구글은 단순히 HTML 문서만 읽어 가는 것이 아니라, 웹 렌더링 서비스(WRS)라는 내부 시스템으로 페이지를 실제 브라우저처럼 열어서 자바스크립트까지 실행한다. WRS는 최신 크롬(Chromium) 엔진을 기반으로 동작하는데, 이 말은 사람이 브라우저로 접속했을 때와 거의 똑같이 페이지 코드를 실행한다는 뜻이다.

문제는 요즘 홈페이지·쇼핑몰이 대부분 자바스크립트 프레임워크(리액트, 뷰 등)로 만들어진다는 점이다. 이런 사이트는 페이지가 열리자마자, 혹은 특정 조건에서 자동으로 API를 호출하는 코드가 실행되도록 짜여 있는 경우가 많다. 예를 들어 장바구니 페이지가 열리면 "최신 재고 상태로 동기화"하는 코드가 PATCH 요청을 자동으로 보내도록 구현돼 있을 수 있다. 사람이 방문했을 때는 이 코드가 정상적으로 로그인 세션과 함께 동작하지만, 구글봇이 렌더링할 때는 로그인 세션이 없는 상태로 같은 코드가 실행되면서 인증되지 않은 PATCH·DELETE 요청만 서버에 남는 것이다.

• 나쁜 예: 페이지가 로드되자마자(사용자의 클릭 없이) 삭제·수정성 API를 자동 호출하도록 코드를 짜서, 크롤러가 접근할 때마다 불필요한 요청이 반복적으로 발생하게 방치하는 경우.
• 좋은 예: 삭제·수정성 API 호출은 반드시 사용자의 명시적인 클릭 이벤트 안에서만 실행되도록 코드를 짜고, 페이지 로드 시점에는 조회(GET)성 API만 호출하도록 설계하는 경우. 이렇게 하면 크롤러의 자동 렌더링 과정에서 불필요한 메서드가 아예 발생하지 않는다.

즉 이번 이슈는 구글봇의 문제라기보다, 프런트엔드 코드가 부수 효과(side effect)를 언제 실행하는지에 대한 설계 문제에 더 가깝다. 서버 로그에서 이런 요청이 유독 많이 보인다면, 방화벽 설정을 손보기 전에 해당 페이지의 자바스크립트 코드가 로드 시점에 불필요한 API를 호출하고 있지는 않은지부터 개발팀과 함께 점검해 보는 편이 근본적인 해결책이다.

조금 더 구체적인 상황으로 들어가 보자. 쇼핑몰의 상품 상세 페이지를 예로 들면, 사용자가 "찜하기" 버튼을 누를 때만 실행되어야 할 코드가 실수로 페이지가 열리자마자 실행되는 함수 안에 잘못 배치돼 있는 경우가 실무에서 종종 발견된다. 사람이 방문할 때는 로그인하지 않은 상태라 이 요청이 서버에서 401 오류로 조용히 실패하고 화면에는 아무 문제도 보이지 않으니 개발 단계에서 놓치기 쉽다. 하지만 구글봇이 그 페이지를 렌더링할 때마다 이 코드가 똑같이 실행되며 로그에 흔적을 남긴다. 화면에 보이는 버그가 아니어서 QA(품질 검증) 단계에서 잡히지 않고, 서버 로그를 열어 봐야만 드러나는 유형의 문제라는 뜻이다. 이런 사례일수록 방화벽보다 코드 리뷰가 먼저다.

HTTP QUERY라는 새 메서드까지 신경 써야 할까?

짧게 답하면, 지금 당장은 아니다. 최근 IETF(인터넷 표준을 정하는 국제 기구)에서 QUERY라는 새로운 HTTP 메서드를 표준화하는 논의가 진행되어 왔고, 이는 GET처럼 안전하지만(서버 상태를 바꾸지 않지만) POST처럼 본문(body)에 검색 조건을 담아 보낼 수 있게 하려는 취지의 메서드다. 예를 들어 검색 조건이 너무 길어 URL에 다 담기 어려운 경우, 지금은 편법으로 POST를 쓰는 경우가 많은데 QUERY는 이런 상황을 위해 설계됐다.

다만 이 글을 쓰는 시점 기준으로, 구글이 QUERY 메서드를 크롤링이나 색인에 도입하겠다고 공식 발표한 사실은 확인되지 않는다. 앞서 다룬 HEAD·OPTIONS·PUT·PATCH·DELETE 확인과는 별개의 사안이므로, 두 소식을 하나로 섞어 "구글이 QUERY까지 쓰기 시작했다"고 이해하면 곤란하다. 표준 자체는 향후 여러 서비스에서 채택될 가능성이 있는 만큼, 관련 공식 발표가 나오면 그때 서버 대응을 점검해도 늦지 않다. 지금 단계에서 서버·방화벽 설정을 QUERY 메서드에 맞춰 미리 바꿀 필요는 없다.

내 서버 로그에서 진짜 구글봇인지 어떻게 확인하나?

결론부터 말하면, User-Agent(사용자 에이전트) 문자열만 보고 판단해서는 안 된다. User-Agent는 요청을 보내는 쪽이 스스로 밝히는 이름표에 불과해서 누구나 "Googlebot"이라고 자칭하는 가짜 요청을 쉽게 만들 수 있다. 구글도 공식 문서에서 "HTTP 사용자 에이전트 문자열은 스푸핑(위조)될 수 있다"고 명시한다.

먼저 로그에서 의심되는 요청을 걸러내는 것부터 시작하자. 리눅스 서버라면 접속 로그 파일에서 다음처럼 특정 메서드만 뽑아 볼 수 있다.

grep -E "PUT|PATCH|DELETE" access.log | grep -i googlebot

이렇게 뽑은 로그 한 줄은 대략 다음과 같은 모양이다.

66.249.66.1 - - [05/Sep/2026:16:03:12 +0900] "PATCH /api/cart HTTP/1.1" 405 128 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

이 한 줄에서 확인할 것은 크게 세 가지다. 접속 IP(66.249.66.1), 요청 메서드(PATCH), 그리고 User-Agent 문자열이다. User-Agent에 "Googlebot"이 적혀 있어도 이것만으로는 증거가 되지 않으므로, IP를 기준으로 진위를 검증하는 다음 절차를 거쳐야 한다.

진짜 구글봇인지 확인하는 공식 절차는 다음 네 단계다.

1. 역방향 DNS 조회: 로그에 남은 접속 IP로 도메인 이름을 알아낸다. 리눅스·맥 터미널이라면 host [IP주소] 명령으로 확인할 수 있다. 예를 들어 host 66.249.66.1을 실행하면 crawl-66-249-66-1.googlebot.com 같은 결과가 나온다.
2. 도메인 검증: 1단계에서 나온 도메인이 googlebot.com, google.com, googleusercontent.com 중 하나로 끝나는지 확인한다. 다른 도메인이면 구글이 아니다.
3. 정방향 DNS 조회: 2단계에서 확인한 도메인 이름으로 다시 IP를 조회한다(host crawl-66-249-66-1.googlebot.com).
4. IP 일치 확인: 3단계에서 나온 IP가 처음 로그에 있던 접속 IP와 같은지 대조한다. 같아야 진짜다.

매번 IP 하나씩 수동으로 확인하기 번거롭다면, 구글이 공개한 IP 대역 파일로 한 번에 자동 검증할 수 있다. 일반 크롤러(구글봇 포함) IP 대역은 https://developers.google.com/static/crawling/ipranges/common-crawlers.json에서 CIDR 형식(예: 192.178.5.0/27처럼 특정 범위의 IP 주소를 나타내는 표기법)으로 제공된다. 이 외에 특수 크롤러용 special-crawlers.json, 사용자 요청 기반 도구용 user-triggered-fetchers.json 파일도 별도로 있다. 서버 스크립트에 이 JSON을 주기적으로 내려받아 대조하는 로직을 넣으면 로그 분석을 자동화할 수 있다.

이 파일은 IP 대역 목록을 담은 단순한 JSON 구조라, 파이썬이나 셸 스크립트로 손쉽게 파싱해 서버의 로그 분석 배치 작업에 붙일 수 있다. 대략의 형태는 {"prefixes": [{"ipv4Prefix": "192.178.5.0/27"}, {"ipv6Prefix": "2001:4860:4801::/48"}]}처럼 IPv4·IPv6 대역을 배열로 나열하는 식이다.

User-Agent만 보고 방화벽 규칙을 짜면 언젠가 반드시 뚫리거나, 반대로 진짜 구글봇을 차단하는 사고가 난다. 로그 자동화 파이프라인을 만든다면 반드시 위 4단계나 IP 대역 파일 대조 로직을 함께 넣어야 한다.

이 검증 절차를 게을리하면 생기는 사고는 대개 방향이 반대다. 가짜 봇을 진짜로 오인해 방치하거나, 반대로 진짜 구글봇을 가짜로 의심해 차단해 버린다. 예를 들어 "로그인하지 않은 사용자의 과도한 접근"을 막으려던 규칙에 구글봇까지 우연히 걸리면, 매출 지표에는 티가 안 나고 서치 콘솔의 색인 페이지 수가 서서히 줄어드는 것을 보고서야 뒤늦게 알아차리는 경우가 많다. 방화벽 규칙을 새로 넣거나 고친 뒤에는 항상 이 검증 절차로 구글봇 접근을 재확인하는 습관이 필요하다.

구글봇에도 여러 종류가 있고, 각각 robots.txt에서 지정하는 이름(토큰)이 다르다. 아래 표를 참고하자.

크롤러	robots.txt 토큰	역할
Googlebot	Googlebot	데스크톱·모바일 페이지의 기본 크롤러
Googlebot Image	Googlebot-Image	이미지 검색용
Googlebot Video	Googlebot-Video	동영상 검색용
Googlebot News	Googlebot-News	구글 뉴스용
Google StoreBot	Storebot-Google	쇼핑·상품 페이지 크롤링용
Google-InspectionTool	Google-InspectionTool	URL 검사 도구 등 사용자가 직접 실행하는 검사용
GoogleOther	GoogleOther	검색 외 다른 구글 제품이 쓰는 범용 크롤러

이 표에서 눈여겨볼 점은, HEAD·OPTIONS·PUT·PATCH·DELETE 요청이 어느 크롤러에서 발생했는지도 함께 기록해 두면 원인 분석이 쉬워진다는 것이다. 예를 들어 Googlebot-Image에서 이런 요청이 남는다면 이미지 페이지에 포함된 스크립트를, GoogleOther에서 남는다면 검색과 무관한 다른 구글 제품의 크롤링 목적을 의심해 볼 수 있다.

AI 크롤러는 구글봇과 어떻게 구분하나?

결론부터 말하면, GPTBot·클로드봇(ClaudeBot)·퍼플렉시티봇(PerplexityBot)·CCBot 같은 AI 크롤러는 구글봇과 전혀 다른 회사가 운영하는, 완전히 별개의 주체다. 서버 로그에 이런 이름이 보인다고 구글 관련 요청으로 착각하면 안 된다.

크롤러	운영 주체	robots.txt 토큰
GPTBot	오픈AI	GPTBot
ClaudeBot	앤트로픽	ClaudeBot
PerplexityBot	퍼플렉시티	PerplexityBot
CCBot	커먼크롤(비영리 아카이브)	CCBot
Bingbot	마이크로소프트	bingbot

이 크롤러들은 구글 IP 대역과 무관하며, 앞서 설명한 역방향 DNS 검증법도 각 회사가 공개한 방식을 따로 확인해야 한다. 실제로 최근에는 클로드봇의 크롤링 요청량이 커먼크롤(CCBot)을 넘어섰다는 통계가 나올 만큼 AI 크롤러들의 트래픽 비중 자체가 빠르게 커지고 있다.

여기서 나쁜 예는 "봇 이름에 뭔가 낯선 게 보이면 전부 구글봇 관련 문제로 취급"하는 대응이다. AI 학습용 크롤러 차단 여부를 결정하는 문제와, 이번에 확인된 구글 자체 크롤러의 HTTP 메서드 확장 문제는 서로 다른 사안이다. 좋은 예는 두 사안을 분리해서, 구글봇은 검증 절차로 진위만 확인하고, AI 학습용 크롤러는 robots.txt로 별도 허용·차단 정책을 세우는 것이다.

한 가지 더 주의할 점은, Cloudflare 같은 CDN·방화벽 서비스에서 "AI 봇 차단"이라는 큰 범주의 규칙을 켰다가 구글봇까지 함께 걸리는 사고가 실제로 보고된 적이 있다는 사실이다. AI 크롤러 차단 규칙을 설정할 때는 반드시 구글봇이 예외 처리되는지 별도로 확인해야 한다. 자세한 사례는 클라우드플레어 AI 크롤러 정책과 구글봇 차단 이슈에 정리해 두었다.

실무에서 자주 나오는 실수 패턴 하나를 더 짚어 보자. User-Agent에 "bot"이라는 단어가 들어가면 무조건 걸러내는 식으로 뭉뚱그려 차단 규칙을 짜는 경우다. 이러면 악성 스크래퍼뿐 아니라 Googlebot-Image·Storebot-Google처럼 이름에 "bot"이 포함된 정상 크롤러까지 함께 막힌다. 좋은 예는 반대 순서다. 허용할 대상(검증된 구글 IP 대역과 주요 검색엔진)을 먼저 정해 두고, 그 외에서만 차단 여부를 따지는 것이다.

방화벽·CDN에서 구글봇을 안전하게 허용하려면 어떻게 설정하나?

결론부터 말하면, User-Agent가 아니라 검증된 IP 대역을 기준으로 허용 규칙을 만들어야 한다. 실무에서 자주 쓰는 방법 세 가지를 정리했다.

• IP 대역 화이트리스트: 앞서 소개한 공식 JSON 파일의 IP 대역을 서버·방화벽 설정에 반영해, 이 대역에서 오는 요청은 메서드 종류와 무관하게 정상적으로 처리하도록 둔다.
• CDN의 검증된 봇 기능 활용: Cloudflare 등 주요 CDN은 자체적으로 "검증된 봇(Verified Bots)" 목록을 관리하며, 이 안에 구글봇이 포함된다. 방화벽 규칙을 만들 때 이 기능을 활용하면 IP 대역을 직접 관리하지 않아도 된다.
• 메서드 자체는 서버가 알아서 처리하게 둔다: PUT·PATCH·DELETE 같은 메서드가 인증되지 않은 요청으로 들어오면, 대부분의 웹 서버·프레임워크는 이미 401(인증 필요)이나 405(허용되지 않는 메서드) 응답을 자동으로 돌려준다. 이 정상 동작을 굳이 별도 차단 규칙으로 덮어씌울 필요는 없다.

엔진엑스(Nginx)를 쓰는 서버라면, 굳이 별도 차단 규칙을 추가하지 않아도 특정 경로에서 허용하는 메서드를 아래처럼 명시적으로 제한해 둘 수 있다. 이렇게 하면 어떤 요청자든(구글봇 포함) 지정하지 않은 메서드로 접근하면 자동으로 405 응답을 받는다.

location /api/ {
  limit_except GET POST {
    deny all;
  }
}

이런 설정은 "구글봇을 차단하기 위한" 규칙이 아니라, 애초에 인증되지 않은 쓰기성 요청을 누구에게도 허용하지 않는 정상적인 보안 설정이라는 점을 기억하자. 구글봇도 이 규칙에 걸리면 그저 405 응답을 받고 넘어갈 뿐, 별도로 예외 처리를 해 줄 필요가 없다.

방화벽 규칙을 바꾼 직후에는 반드시 서치 콘솔의 크롤링 통계 보고서에서 호스트 상태와 응답 코드 추이를 며칠간 관찰하는 것이 안전하다. 규칙 하나 때문에 정상 크롤링이 막혔는지 가장 빠르게 확인할 수 있는 공식 창구이기 때문이다.

robots.txt로 이 요청들을 막아도 검색 순위에 문제없나?

결론부터 말하면, robots.txt는 애초에 HTTP 메서드를 구분하는 도구가 아니다. robots.txt는 "이 경로는 크롤링하지 말아 달라"고 요청하는 파일일 뿐, GET인지 PUT인지를 지정할 수 있는 문법 자체가 없다. 메서드 단위로 요청을 걸러내려면 robots.txt가 아니라 서버나 방화벽·CDN 설정에서 처리해야 한다.

그렇다면 방화벽에서 PUT·PATCH·DELETE 요청을 걸러도(405 응답을 돌려줘도) 검색 순위에 불이익이 있을까. 결론은 없다. 구글이 실제 페이지 콘텐츠를 가져와 색인하는 요청은 여전히 GET이 절대다수이며, 이번에 확인된 나머지 메서드들은 렌더링 과정의 부수적 흔적일 뿐 색인 여부를 좌우하는 핵심 요청이 아니기 때문이다. 반대로 지나치게 공격적인 차단 규칙으로 정상 GET 요청까지 함께 막히는 경우가 실질적인 위험이므로, 규칙을 만들 때는 메서드가 아니라 항상 IP 검증을 기준으로 삼아야 한다.

또한 이번 확인 내용과 별개로, robots.txt 자체를 처음부터 다시 점검하고 싶다면 구글봇과 인덱서의 차이를 다룬 글을 함께 참고하면 좋다. 크롤러가 무엇을 가져가고, 그중 무엇이 실제로 색인에 반영되는지를 구분해서 이해하면 로그를 볼 때 훨씬 덜 헷갈린다.

이런 요청을 정기적으로 모니터링하려면 어떤 도구를 쓰면 좋은가?

결론부터 말하면, 처음부터 거창한 도구를 도입할 필요는 없다. 트래픽이 많지 않은 사이트라면 앞서 소개한 grep·awk 같은 기본 명령어를 활용한 짧은 셸 스크립트만으로도 충분하다. 예를 들어 매일 새벽 한 번씩 전날 로그에서 GET·HEAD를 제외한 메서드의 건수를 세어 이메일로 알려 주는 간단한 크론(cron, 정해진 시간마다 자동으로 명령을 실행하는 스케줄러) 작업만 걸어 두어도 이상 징후를 놓치지 않을 수 있다.

트래픽이 많거나 여러 서버를 함께 운영하는 규모라면 GoAccess처럼 로그를 실시간으로 시각화하는 오픈소스 도구나, 로그를 모아 검색·분석하는 ELK 스택(일래스틱서치·로그스태시·키바나) 같은 도구가 낫다. 여기에 IP 대역 대조 로직을 결합하면 "검증된 구글봇 요청"과 "미검증 요청"을 나눠 보는 것도 가능하다.

어떤 도구를 쓰든 핵심은 하나다. 메서드 종류나 요청 건수 자체보다, 그 요청이 검증된 구글 IP에서 왔는지 여부를 기준으로 이상 여부를 판단하는 것이다. 이 기준만 지키면 도구는 셸 스크립트든 값비싼 로그 분석 플랫폼이든 크게 상관없다.

오늘 바로 해 볼 수 있는 점검 순서는 무엇인가?

결론부터 말하면, 순서는 다음과 같다. 먼저 최근 한 주 정도의 접속 로그에서 GET·HEAD 외의 메서드가 얼마나 되는지 세어 본다. 그다음 그 요청들의 접속 IP를 추려서 앞서 소개한 4단계 검증(또는 IP 대역 파일 대조)으로 실제 구글 소유인지 가려낸다. 진짜 구글이라면 그대로 두고, 아니라면 일반적인 악성 트래픽 대응 절차를 따른다.

이 과정에서 특정 페이지에서 유독 PUT·PATCH·DELETE 요청이 몰린다면, 그 페이지의 프런트엔드 코드를 열어 페이지 로드 시점에 자동으로 실행되는 API 호출이 있는지 개발팀과 함께 확인해 보자. 앞서 설명했듯 이런 요청은 대개 사용자 이벤트 없이 실행되는 코드에서 비롯되므로, 코드를 손보는 것이 방화벽 규칙을 늘리는 것보다 더 근본적인 해결책이 될 때가 많다.

자주 묻는 질문

서버 로그에 구글봇 IP로 된 PUT·DELETE 요청이 갑자기 늘면 위험 신호인가?

먼저 앞서 소개한 4단계 검증으로 그 IP가 진짜 구글 소유인지부터 확인해야 한다. 진짜라면 위험 신호가 아니라 렌더링 과정에서 자연히 발생하는 요청이므로 특별한 조치가 필요 없다. 검증 결과 구글 소유가 아니라면, 그때는 스크래퍼나 자동화 공격 시도로 보고 일반적인 봇 대응 절차를 적용하면 된다.

구글봇의 HEAD·OPTIONS·PUT·PATCH·DELETE 요청을 방화벽에서 막으면 순위에 불이익이 있나?

없다. 구글이 실제로 페이지를 가져와 색인하는 데는 GET 요청이 쓰이며, 나머지 메서드는 렌더링의 부수 효과다. 다만 차단 규칙을 만들 때 실수로 정상 GET 요청까지 함께 막지 않도록, 메서드 단위가 아니라 검증된 IP 대역을 기준으로 규칙을 짜는 것이 안전하다.

User-Agent 문자열만 보고 구글봇 여부를 판단해도 되나?

권장하지 않는다. User-Agent는 요청을 보내는 쪽이 스스로 적어 넣는 값이라 누구나 위조할 수 있다. 역방향 DNS 조회와 정방향 재조회, 또는 구글이 공식 제공하는 IP 대역 JSON 파일로 대조하는 방법이 신뢰할 수 있는 검증법이다.

이 변화가 카페24·워드프레스 같은 국내 사이트에도 똑같이 적용되나?

그렇다. 구글의 크롤러 동작 방식은 사이트가 어떤 플랫폼으로 만들어졌는지와 무관하게 동일하게 적용된다. 다만 카페24·아임웹 같은 폐쇄형 플랫폼은 서버 로그나 방화벽 설정에 운영자가 직접 접근하기 어려운 경우가 많아, 로그 기반 대응 자체가 제한적일 수 있다는 점은 감안해야 한다.

Cloudflare의 검증된 봇 기능은 어디서 켜나?

Cloudflare 대시보드의 보안(Security) 메뉴 안 봇 관리(Bots) 설정에서 확인할 수 있다. 여기서 구글봇을 포함한 주요 검색엔진 크롤러가 "검증된 봇"으로 자동 분류되며, 다른 차단 규칙을 만들 때 이 분류를 예외 조건으로 지정하면 실수로 구글봇을 막는 사고를 줄일 수 있다. 다만 화면 구성은 서비스 업데이트에 따라 바뀔 수 있으므로 실제 적용 전에는 최신 화면을 직접 확인하는 것이 안전하다.

---

서버 로그를 직접 열어 구글봇의 진위를 가리고 방화벽 규칙까지 손보는 일은 사이트 운영자 혼자 처리하기에는 확인할 것이 많고, 자칫 규칙 하나를 잘못 걸면 정상 크롤링이 막혀 색인에 문제가 생길 수 있는 민감한 영역입니다. 이루웹은 홈페이지 제작 단계에서부터 이런 서버·크롤링 설정까지 함께 점검해 드리고 있습니다.

지금 운영 중인 사이트의 크롤링 상태나 서버 로그가 걱정되신다면, 이루웹 SEO 서비스 페이지에서 어떤 점검을 도와드리는지 살펴보시고, 상담 문의로 편하게 연락 주시면 현재 사이트 상태를 함께 확인해 드리겠습니다. 새로 홈페이지 제작을 고려 중이시라면 홈페이지 제작 서비스 페이지도 참고해 보시길 권해 드립니다.