Google은 개인화가 비활성화된 경우에도 요청의 지리적 출처에 따라 동일한 쿼리에 대해 서로 다른 자연 검색 결과를 제공합니다. 뉴욕 데이터센터 IP에서 "best coffee beans"를 검색한 결과와 베를린의 가정용 IP에서 동일한 쿼리를 검색한 결과는 SERP가 다릅니다. 이 차이는 단순한 외형적 차이가 아닙니다. 이는 Google의 지역별 순위 알고리즘, 콘텐츠 현지화, 그리고 gl(국가), hl(언어), cr(국가 제한) 매개변수의 상호 작용에 의해 강제됩니다. 이러한 메커니즘을 이해하지 않고 지역 타겟 SEO 모니터링을 실행하면 잘못된 데이터가 보장됩니다. 이 글에서는 SERP가 지역별로 달라지는 이유, 프록시 로테이션이 탐지를 완화하는 방법, 그리고 30개 이상의 마켓에서 순위를 추적하기 위한 운영 워크플로우를 설명합니다.
SERP가 지역별로 다른 이유 — ccTLD, gl, hl 및 개인화
Google은 여러 신호의 조합을 통해 "로컬" SERP를 결정합니다. 가장 간단한 것은 검색 도메인의 TLD입니다 — google.de 대 google.co.jp. 그러나 ccTLD만 사용하는 것으로는 충분하지 않습니다. Google은 또한 gl 매개변수를 읽어 가정된 국가를 재정의합니다. 예를 들어, google.com?gl=DE는 글로벌 도메인에서도 독일어 결과를 강제합니다. hl 매개변수는 인터페이스 언어를 설정하며, 결과 언어에는 영향을 미치지만 지리적 가중치에는 영향을 미치지 않습니다. hl=en&gl=JP를 사용한 요청은 일본어 결과를 영어로 반환하는데, 이는 흔한 혼란의 원인입니다.
매개변수 외에도 Google은 IP 기반 지리적 위치를 적용합니다. 미국 IP에서 google.de로 요청을 보내면 Google이 IP 출처를 감지하여 영어와 독일어 결과가 혼합된 상태로 제공될 수 있습니다. 이것이 SEO 모니터링의 핵심 문제입니다. IP 주소가 사용자의 위치를 노출합니다. pws=0를 통해 개인화를 비활성화하면 사용자 기록은 제거되지만 위치 추론은 비활성화되지 않습니다. 로컬 사용자를 시뮬레이션하는 유일한 신뢰할 수 있는 방법은 대상 마켓에 속한 IP(이상적으로는 가정용 IP)를 통해 트래픽을 라우팅하는 것입니다.
가정용 IP vs 데이터센터 IP — 탐지 및 캡차 회피
Google은 IP 범위를 적극적으로 분류합니다. 데이터센터 IP(AWS, GCP, DigitalOcean)는 몇 초 내에 비인간으로 플래그 지정됩니다. 내부 테스트에 따르면 gl 매개변수로 Google을 쿼리할 때 데이터센터 IP의 60~80% 실패율이 나타납니다. 많은 요청이 캡차 또는 축소된 SERP를 반환합니다. 반면 가정용 IP는 일반 트래픽에 섞여 들어갑니다. 그러나 가정용 프록시 풀에는 높은 지연 시간, 제한된 대역폭, 가변적인 지리적 위치 정확도 등의 문제가 있습니다. 프록시 제공업체의 "가정용" IP는 실제로 Google이 다른 지역으로 매핑하는 모바일 통신사 NAT일 수 있습니다.
캡차 회피는 "숨기는" 것이 아니라 실제 브라우저를 모방하는 것입니다. 올바른 User-Agent, Accept-Language(hl와 일치), 세션당 새로운 Cookie jar를 보내야 합니다. Google의 봇 탐지는 요청 타이밍도 확인합니다. 동일한 IP에서 2초 동안 100개의 쿼리를 폭발적으로 보내면 캡차가 트리거됩니다. IP당 분당 1~2개의 요청으로 제한하세요. 처리량을 유지하려면 마켓당 최소 50개의 IP 풀을 사용하세요. 트레이드오프는 더 높은 지연 시간과 비용 대비 낮은 캡차 비율입니다. 우리는 5~10%의 캡차 비율을 정상으로 간주하고 다른 IP로 재시도합니다.
30개 이상의 국가에서 순위 추적을 위한 워크플로우
운영 패턴은 간단합니다. 마켓당 하나의 IP, 쿼리당 하나의 새로운 세션입니다. 마켓 간에 쿠키를 재사용하지 마세요. 다음 셸 스니펫은 가정용 프록시를 사용하여 독일 SERP를 위한 최소한의 curl 기반 프로브를 보여줍니다.
#!/bin/bash
# Query Google for "SEO tools" with German gl and English hl, via a residential proxy
PROXY="http://user:pass@residential-proxy-pool:8080"
curl -s --proxy "$PROXY" \
-H "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36" \
-H "Accept-Language: en-US,en;q=0.9,de;q=0.8" \
-H "Cookie: NID=...; CONSENT=..." \
"https://www.google.com/search?q=SEO+tools&gl=DE&hl=en&pws=0&num=10" \
| grep -oP '(?<=&url=)[^&]+' | head -10이것은 상위 10개의 자연 URL을 가져옵니다. 프로덕션 시스템의 경우 정적 프록시를 요청당 새 IP를 반환하는 로테이팅 엔드포인트로 교체하세요. proxy-chain와 같은 도구나 IP당 세션을 사용하는 requests 기반의 사용자 정의 Python 스크립트가 잘 작동합니다. 각 마켓의 프록시 목록을 별도의 파일에 저장하고 순환적으로 로테이션하세요.
30개 이상의 국가의 경우 30개 이상의 프록시 풀이 필요합니다. 각 풀은 속도 제한을 피하기 위해 최소 20~50개의 IP를 포함해야 합니다. 글로벌 IP의 단일 풀은 Google의 지리적 위치가 잘못 라우팅되므로 충분하지 않습니다. 우리는 국가 코드를 프록시 엔드포인트에 매핑하는 구성 파일을 사용합니다.
{
"DE": "http://user:pass@de-residential.zone:8080",
"JP": "http://user:pass@jp-residential.zone:8080",
"BR": "http://user:pass@br-residential.zone:8080"
}각 마켓 쿼리는 별도의 스레드 또는 비동기 작업에서 실행되며, 10개의 요청 후 IP당 60초의 쿨다운이 적용됩니다. 이 주기는 대부분의 마켓에서 캡차 비율을 3% 미만으로 유지합니다. 어려운 부분은 코드가 아니라 검증된 지리적 위치를 가진 신뢰할 수 있는 가정용 프록시를 확보하는 것입니다. 많은 제공업체가 "DE"를 주장하지만 프랑크푸르트 데이터센터를 통해 라우팅합니다. IP의 ASN을 확인하고 Google의 위치 추론(예: X-Robots-Tag 헤더 또는 알려진 로컬 결과 사용)과 비교하여 검증하세요.
트레이드오프: 신선도 vs 비용
가정용 프록시로 매시간 30개 마켓을 실행하면 제공업체와 데이터 볼륨에 따라 프록시 비용만 월 $200~$500 정도 듭니다. Google이 덜 공격적인 마켓(일반적으로 작은 국가)에서는 데이터센터 IP를 사용하여 비용을 줄일 수 있습니다. 그러나 데이터는 더 노이즈가 많을 것입니다. 대안은 24시간 갱신 주기를 수용하고 캡차 비율이 낮아지는 밤에 쿼리를 배치 처리하는 것입니다. 공짜 점심은 없습니다. 30개 국가에서 매일 순위 추적이 필요하다면 가정용 프록시와 강력한 재시도 메커니즘에 예산을 할당하세요. 그보다 적은 것은 정밀해 보이지만 근본적으로 잘못된 결과를 생성하며, 이는 데이터가 전혀 없는 것보다 더 나쁩니다.