2026년 10월 7일 기준으로 Shifter는 Oxylabs와 Bright Data보다 많은, 가장 큰 규모의 실시간 미국 IP 풀을 보유하고 있으며, 비용은 그 일부에 불과합니다.Shifter는 이제 가장 많은 미국 라이브 IP 풀을 보유하고 있습니다

벤치마크 보기

지식

SEO 클로킹: 개념과 여러 위치에서 탐지하는 방법

SEO 클로킹이란 무엇인지, Google이 클로킹으로 보는 것과 보지 않는 것은 무엇인지, 그리고 사용자 에이전트, 리퍼러, 위치별 응답을 비교해 자사 사이트나 경쟁사 사이트에서 클로킹을 탐지하는 방법을 설명합니다.

Daniel Okafor

2026년 10월 18일 · 7 분 소요

SEO 클로킹은 검색엔진에는 한 가지 버전의 페이지를 보여주고 사람에게는 다른 버전을 보여주는 것을 말합니다. 크롤러는 순위가 잘 나오는 깔끔하고 키워드가 풍부한 페이지를 받고, 클릭한 방문자는 다른 것을 받습니다. 리디렉션이나 다른 상품, 노골적인 스팸인 경우가 많습니다. Google은 스팸 정책에 클로킹을 명시하고 있으며, 적발된 사이트는 개별 페이지 또는 도메인 전체의 순위를 잃을 수 있습니다.

대부분의 팀은 방어하는 입장에서 클로킹을 접합니다. 해킹당한 사이트가 소유자도 본 적 없는 의약품이나 카지노 키워드로 순위에 오르거나, 경쟁사의 순위 페이지가 스니펫에서 약속한 내용과 다른 경우입니다. 어느 쪽이든 이를 찾아내는 것은 SEO 모니터링의 문제입니다. 각 유형의 방문자가 보는 방식 그대로 페이지를 보고 비교해야 합니다.

클로킹에 해당하는 것

Google의 정의는 의도에 초점을 둡니다. 순위를 조작하고 사용자를 오도할 목적으로 사용자와 검색엔진에 서로 다른 콘텐츠를 제공하는 것입니다. Google이 직접 드는 예로는 크롤러에게는 여행지에 관한 페이지를 제공하면서 방문자에게는 할인 의약품 페이지를 보여주는 경우, 요청자가 검색엔진일 때만 텍스트나 키워드를 삽입하는 경우가 있습니다.

작동 방식은 언제나 같습니다. 서버나 페이지의 스크립트가 누가 요청하는 것처럼 보이는지에 따라 무엇을 보낼지 결정합니다. 이때 사용하는 신호는 다음과 같습니다.

  • 사용자 에이전트. 조잡한 방식입니다. “Googlebot”이라고 표시된 요청은 모두 깔끔한 페이지를 받습니다.
  • IP 주소. 정교한 방식입니다. Google이 공개한 크롤러 대역에서 오고 역방향 DNS로 검증된 요청만 깔끔한 페이지를 받으므로, 사용자 에이전트를 위조하는 것만으로는 이를 열 수 없습니다.
  • 리퍼러. Google 검색결과 페이지에서 유입된 방문자는 리디렉션되고, 사이트 소유자를 포함해 URL을 직접 입력한 사람은 정상적인 사이트를 봅니다.
  • 위치와 네트워크. 대상 국가에서 가정용 회선으로 접속한 방문자는 페이로드를 받고, 사무실, 클라우드, 데이터센터 대역은 깔끔한 버전을 받습니다. 검토자와 보안 스캐너가 그런 곳에서 접속하기 때문입니다.
  • 기기. 일부 수법은 모바일 방문자만 리디렉션합니다. 수익이 나는 곳이 모바일이기 때문입니다.

실제 사례는 대부분 이 중 두세 가지를 조합하며, 그래서 자기 자리에서 한 번 확인해서는 대개 아무것도 드러나지 않습니다.

클로킹이 아닌 것

정상적인 설정 중에도 방문자에 따라 다른 응답을 제공하는 경우가 많습니다. Google은 크롤러가 비슷한 조건의 사용자가 보는 것과 같은 것을 본다면 문제없다고 말합니다.

  • 지역 및 언어 개인화. 독일 방문자에게 유로로 가격을 보여주는 것은 클로킹이 아닙니다. 같은 장소의 사용자와 Googlebot을 다르게 취급한다면 클로킹입니다. 위치에 따라 사람들이 보는 결과가 어떻게 달라지는지는 현지화된 Google 검색결과 가이드에서 다룹니다.
  • 페이월과 게이트 콘텐츠. Google은 페이월 콘텐츠용 구조화 데이터를 문서화해 두었는데, 바로 퍼블리셔가 클로킹으로 간주되지 않으면서 크롤러에게 전체 기사를 보여줄 수 있도록 하기 위해서입니다.
  • 기기별 레이아웃. 주요 콘텐츠가 동등하다면 모바일과 데스크톱에 서로 다른 마크업을 쓰는 것은 문제없습니다.
  • 봇용 렌더링. 크롤러에게 사전 렌더링된 HTML을 제공하는 방식은 한때 무거운 JavaScript에 대한 해결책으로 권장되었습니다. 현재 Google은 이를 장기적인 해결책이 아닌 임시방편이라고 부르지만, 콘텐츠가 일치한다면 클로킹은 아닙니다.

각 경우의 판단 기준은 같은 질문입니다. 크롤러와 같은 위치에 있는 실제 사용자가 같은 콘텐츠를 받을까요?

한 곳에서 확인할 수 없는 이유

클로킹된 페이지는 확인할 가능성이 가장 높은 바로 그 사람들에게 깔끔하게 보이도록 만들어집니다. 그래서 세 가지 사각지대가 생깁니다.

  1. 당신이 제외된 대상입니다. 로그인한 상태로, 사무실에서, 또는 URL을 직접 입력해 자사 사이트를 확인하면 리퍼러 기반 해킹은 절대 드러나지 않습니다. 사이트 소유자는 Search Console이나 고객을 통해 이를 알게 되는 경우가 많습니다.
  2. 당신은 Googlebot이 될 수 없습니다. Googlebot 사용자 에이전트를 보내면 조잡한 클로킹만 잡을 수 있습니다. 크롤러의 IP를 검증하는 수법이라면 당신을 일반 사용자로 취급합니다.
  3. 당신은 잘못된 시장이나 네트워크에 있습니다. 한 국가의 가정용 회선 모바일 방문자에게만 작동하는 수법은 다른 국가의 클라우드 서버에서는 보이지 않습니다.

따라서 탐지는 비교 작업이며, 클로킹이 필터링하는 조건을 모두 포괄할 만큼 충분한 관측 지점에서 실행해야 합니다.

탐지 워크플로

1단계: 먼저 Google의 시점을 확보합니다. Search Console에서 URL Inspection 도구의 실시간 테스트는 Google 자체 인프라에서 Googlebot으로 페이지를 가져와 렌더링된 HTML과 스크린샷을 보여줍니다. Rich Results Test는 소유하지 않은 페이지에 대해 같은 기능을 합니다. 실제 Googlebot IP에서 요청이 오기 때문에, 크롤러 버전을 확인하는 유일하게 신뢰할 수 있는 방법입니다.

2단계: 사용자 시점을 수집합니다. 같은 URL을 일반 방문자로서 가져오되, 한 번에 한 가지 조건만 바꿉니다.

변형사용자 에이전트리퍼러네트워크
기준데스크톱 브라우저없음사무실
검색 유입데스크톱 브라우저google.com 검색결과 페이지사무실
모바일 검색 유입모바일 브라우저google.com 검색결과 페이지대상 국가의 가정용 IP
데스크톱 검색 유입, 대상 시장데스크톱 브라우저google.com 검색결과 페이지대상 국가의 가정용 IP
조잡한 봇 확인Googlebot 문자열없음사무실

가정용 IP 행에서 레지덴셜 프록시가 필요합니다. 테스트 중인 국가의 가정용 회선을 사용하므로, 요청이 해당 수법이 기다리는 방문자처럼 보입니다. 프록시 지역, 시간대, 로캘 맞추기 가이드에서 설명한 것처럼 로캘, 시간대, 언어를 출구 국가와 일치시키세요. 그렇지 않으면 잘 만들어진 수법은 당신을 이상치로 취급합니다.

3단계: 중요한 부분을 비교합니다. 원시 HTML은 토큰과 타임스탬프 때문에 어떤 두 요청 사이에서도 다릅니다. 순위나 방문자 경험을 바꾸는 부분을 비교하세요.

  • 리디렉션 후의 최종 URL과 체인의 모든 홉
  • title, meta description, canonical, robots 지시어
  • 정규화하고 해시한 본문 텍스트
  • 외부 링크, 특히 낯선 도메인으로 향하는 링크

4단계: 반복합니다. 해킹과 경쟁사의 수법은 방문의 일부에만, 또는 특정 시간대에만 작동하는 경우가 많습니다. 한 번 깨끗한 결과가 나왔다고 해서 증거로는 약합니다. 페이지가 깨끗하다고 결론 내리기 전에 다양한 출구와 시간대에 걸쳐 매트릭스를 여러 번 실행하세요.

다음은 최소한의 비교 스크립트입니다. PROXY_URL을 국가 타겟이 지정된 레지덴셜 게이트웨이로 설정하고, 관심 있는 시장마다 변형을 추가하세요.

import hashlib, os, re
import requests

URL = "https://example.com/some-page"
DESKTOP = "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0 Safari/537.36"
MOBILE = "Mozilla/5.0 (iPhone; CPU iPhone OS 18_0 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/18.0 Mobile/15E148 Safari/604.1"
GOOGLEBOT = "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
SERP = "https://www.google.com/"
RESI = {"http": os.environ["PROXY_URL"], "https": os.environ["PROXY_URL"]}

VARIANTS = {
    "baseline": dict(ua=DESKTOP, ref=None, proxies=None),
    "from_search": dict(ua=DESKTOP, ref=SERP, proxies=None),
    "mobile_market": dict(ua=MOBILE, ref=SERP, proxies=RESI),
    "desktop_market": dict(ua=DESKTOP, ref=SERP, proxies=RESI),
    "googlebot_ua": dict(ua=GOOGLEBOT, ref=None, proxies=None),
}

def tag(html, pattern):
    m = re.search(pattern, html, re.I | re.S)
    return m.group(1).strip() if m else ""

def fingerprint(ua, ref, proxies):
    headers = {"User-Agent": ua, "Accept-Language": "en-US,en;q=0.9"}
    if ref:
        headers["Referer"] = ref
    r = requests.get(URL, headers=headers, proxies=proxies, timeout=30)
    html = r.text
    text = re.sub(r"<script.*?</script>|<style.*?</style>|<[^>]+>", " ", html, flags=re.S)
    text = re.sub(r"\s+", " ", text).strip().lower()
    return {
        "final_url": r.url,
        "hops": [h.headers.get("Location", "") for h in r.history],
        "title": tag(html, r"<title[^>]*>(.*?)</title>"),
        "canonical": tag(html, r'<link[^>]+rel=["\']canonical["\'][^>]+href=["\']([^"\']+)'),
        "robots": tag(html, r'<meta[^>]+name=["\']robots["\'][^>]+content=["\']([^"\']+)'),
        "text_hash": hashlib.sha256(text.encode()).hexdigest()[:12],
    }

results = {name: fingerprint(**v) for name, v in VARIANTS.items()}
base = results["baseline"]
for name, res in results.items():
    diffs = [k for k in res if res[k] != base[k]]
    print(f"{name:15} {'SAME' if not diffs else 'DIFFERS: ' + ', '.join(diffs)}")

text_hash만 다르다면 무해한 개인화일 수 있습니다. final_url이 다르거나, 새로운 리디렉션 홉이 생기거나, 검색 유입 방문자에게만 나타나는 title이 있다면 조사해야 할 패턴입니다. 그런 다음 사용자 시점을 URL Inspection 실시간 테스트의 HTML과 비교하세요.

발견했을 때 해야 할 일

자사 사이트라면, 먼저 보안 사고로 취급하세요. 직접 만들지 않은 사이트에서 리퍼러 및 IP 기반 클로킹이 발견된다면 거의 항상 침해를 의미합니다. 서버 규칙이 주입되었거나, 플러그인이나 테마가 변조되었거나, 템플릿에 스크립트가 추가된 경우입니다. 코드를 제거하고, 침입 경로를 막은 뒤, Google이 수동 조치를 적용했다면 Search Console에서 검토를 요청하세요. 이후 같은 시장에서 비교 매트릭스를 다시 실행해 완전히 제거되었는지 확인하세요.

경쟁사 사이트라면, 신고하기 전에 기록부터 남기세요. Rich Results Test로 크롤러 버전을, 타임스탬프, 출구 국가, 기기와 함께 사용자 버전을, 그리고 전체 리디렉션 체인을 캡처하세요. Google은 검색 품질 신고 양식을 통해 스팸 신고를 받습니다. 같은 행위의 유료 검색 버전에 대해서는 클로킹 및 지역 타겟 광고 잡아내기 가이드에서 광고 측면을 다룹니다.

모니터링을 계속하세요. 침입 경로를 고치지 않으면 해킹은 다시 돌아오며, 순위가 가장 높은 페이지에 다시 나타나는 경향이 있습니다. 자연 검색 트래픽을 보내주는 국가에서 주요 랜딩 페이지를 대상으로 매주 매트릭스를 실행하는 것은 저렴한 조기 경보 수단입니다.

FAQ

SEO 클로킹은 불법인가요?

일반적으로 법적인 문제는 아니며, 검색엔진 정책 위반입니다. Google은 스팸 정책에 이를 명시하고 있으며, 클로킹을 사용하는 페이지의 순위를 낮추거나 삭제할 수 있습니다. 클로킹이 사기나 악성코드를 숨기는 경우에는 콘텐츠 자체에 다른 법률이 적용될 수 있습니다.

국가별로 다른 콘텐츠를 보여주는 것도 클로킹인가요?

그 자체로는 아닙니다. 국가별로 가격, 언어, 상품을 현지화하는 것은 일반적인 일입니다. 같은 상황의 사용자와 크롤러를 다르게 취급할 때 클로킹이 됩니다.

사용자 에이전트를 Googlebot으로 바꿔서 클로킹을 확인할 수 있나요?

조잡한 클로킹만 확인할 수 있습니다. 정교한 수법은 크롤러의 IP를 검증하므로, 위조된 사용자 에이전트는 일반 방문자로 취급됩니다. Google의 실제 시점을 보려면 Search Console의 URL Inspection 실시간 테스트나 Rich Results Test를 사용하세요.

클로킹을 탐지하는 데 왜 레지덴셜 IP가 필요한가요?

많은 수법이 대상 시장의 일반 방문자에게만 페이로드를 보여주고, 사무실, 클라우드, 데이터센터 주소에는 깔끔한 페이지를 보여줍니다. 해당 시장의 가정용 회선에서 확인하는 것이 그 방문자들이 무엇을 받는지 볼 수 있는 방법입니다.

결론

클로킹은 확인할 가능성이 가장 높은 사람에게서 숨기 때문에, 자기 자리에서 한 번 보는 것으로는 증명되는 것이 거의 없습니다. Google 자체 도구로 Google의 시점을 확보하고, 중요한 시장에서 리퍼러, 기기, 가정용 회선별로 사용자 시점을 수집하고, 최종 URL, title, 본문을 비교한 뒤, 페이지가 깨끗하다고 판단하기 전에 반복하세요. 자사 사이트라면 발견 사항을 침해로 취급하고 침입 경로를 고치세요. 여러 위치에서 페이지가 어떻게 노출되는지 장기적으로 추적하려면 지오그리드 순위 추적 가이드를 참고하세요.

시작할 준비가 되셨나요?

205M개 이상의 IP, 195개 이상의 국가를 지원하는 Shifter의 레지덴셜 프록시를 $0.10/GB부터 이용해보세요.

시작하기