2025년 9월 즈음, 여러 SEO 도구와 커스텀 스크립트가 아무 말 없이 멈춰 서기 시작했습니다. 왜 그랬을까요? Google이 예전부터 고급 사용자들이 1페이지에 100개 결과를 가져오는 데 써 온 num=100 파라미터를 더 이상 안정적으로 처리하지 않기 시작했기 때문입니다. 공식 종료 공지는 따로 없었습니다. 다만 Search Engine Land에 밝힌 Google 대변인은 그 파라미터가 "공식 지원 대상이 아니었다"고 설명했습니다. 같은 시기 Google은 기존 tbm 세로 검색에 더해 여러 udm 모드를 도입했고, 국가 코드 도메인이 점차 google.com으로 리디렉션될 것이라고 발표했으며, AI Overviews가 월간 사용자 25억 명 이상에 도달했다고 밝혔습니다.
Google의 URL 파라미터를 활용해 검색 URL을 만들고, 순위를 추적하고, 리서치를 자동화해 왔다면, 지금도 일부 워크플로는 조용히 성능이 떨어지고 있을 가능성이 큽니다. Thunderbit에서는 Google의 최신 문서, 최근 변경 공지, 역공학 자료, 실제 테스트 결과를 모두 살펴보며 안정적으로 쓸 수 있는 값과 상황에 따라 달라지는 값들을 구분했습니다. 그 결과 2026년에 꼭 알아야 할 Google 검색 URL 파라미터를 정리한, 날짜가 표시된 실전용 레퍼런스를 만들 수 있었습니다. 여기에는 tbm/udm 매핑, 도시 단위 지오 타겟팅을 위한 uule 인코딩 공식, 그리고 디버깅 시간을 크게 줄여 주는 파라미터 충돌 사례까지 담았습니다.
Google 검색 URL 파라미터란?
Google 검색 URL 파라미터는 Google 검색 URL에서 ? 뒤에 붙는 key=value 형태의 값입니다. 무엇을 검색할지부터, 어느 나라의 결과를 볼지, 이미지·뉴스·일반 웹 결과 중 무엇을 볼지까지 이 값으로 모두 조절합니다.
일반적인 Google 검색 URL은 이렇게 생겼습니다.
https://www.google.com/search?q=best+crm+software&hl=en&gl=us&tbs=qdr:m
- 기본 URL:
https://www.google.com/search ?는 쿼리 문자열이 시작된다는 뜻입니다q=best+crm+software는 검색어입니다(공백은+로 인코딩)&는 각 파라미터를 구분합니다hl=en은 인터페이스 언어를 영어로 설정합니다gl=us은 미국에서 검색한 것처럼 결과를 보여 달라는 의미입니다tbs=qdr:m은 최근 한 달 결과로 필터링합니다
여기서 하나 짚고 넘어갈 점이 있습니다. site:, filetype:, intitle: 같은 검색 연산자는 q= 안에 들어갑니다. 즉, 검색어의 일부입니다. 반면 gl, hl, tbs 같은 URL 파라미터는 URL의 별도 키로, Google이 결과를 처리하고 보여 주는 방식을 조정합니다. 둘 다 중요하지만 역할은 다릅니다.
Google은 이 파라미터들에 대한 단일 버전별 명세를 공개한 적이 없습니다. 일부는 고급 검색 폼에서, 일부는 Custom Search API에서, 또 일부는 Google 자체 URL을 관찰해 역공학한 결과입니다. 즉, 이 글은 공식 API 계약이 아니라 실제 테스트와 문서화된 동작을 바탕으로 만든 참고 자료입니다.
2026년에 Google 검색 URL 파라미터가 중요한 이유
URL 파라미터는 개발자만 쓰는 도구가 아닙니다. 특정 쿼리의 결과를, 특정 시장에서, 특정 시점 기준으로 이해해야 하는 SEO, 마케팅, 영업, 운영, 제품 담당자라면 이 파라미터들이 핵심 도구입니다.
어떤 업무에 어떤 도움이 되는지 간단히 정리하면 다음과 같습니다.
| 활용 사례 | 도움이 되는 팀 | 핵심 파라미터 |
|---|---|---|
| 국가별 SEO 순위 추적 | SEO & 마케팅 팀 | gl, hl, uule, pws |
| 날짜 기준 경쟁사 모니터링 | 전략 & 운영 팀 | tbs, q와 site: |
| 특정 시장의 광고 모니터링 | 유료 미디어 팀 | gl, hl, udm |
| 로컬 SEO 감사(도시 단위) | 지역 비즈니스 운영자 | uule, gl |
| 콘텐츠 리서치 / 트렌드 추적 | 콘텐츠 팀 | tbs(날짜 필터), lr |
| 검색 데이터를 AI/LLM 앱에 연결 | 제품 & 데이터 팀 | 여러 파라미터 + 구조화 추출 |
2026년에 달라진 핵심 변화는 세 가지입니다.
num=100은 더 이상 믿을 수 없습니다. 예전의 결과 수 조절 꼼수는 2025년 9월부터 안정적으로 동작하지 않기 시작했습니다. Google은 이를 정식 종료했다고 발표하지 않았고, 대변인은 애초에 공식 지원 기능이 아니었다고 설명했습니다.- ccTLD 리디렉션은 끝난 일이 아니라 진행 중인 전환입니다. Google은 2025년 4월 국가 코드 도메인(google.co.uk, google.de 등)이 점차 google.com으로 리디렉션될 것이라고 밝혔습니다. 아직 완료 공지는 없으니, 모든 로케일이 똑같이 동작한다고 보면 안 됩니다.
- AI Overviews가 SERP를 크게 바꿔 놓았습니다. Google은 AI Overviews가 월간 사용자 25억 명 이상과 200개국 이상에 도달했다고 밝혔습니다. 역공학된
udm모드는 일부 상황에서 결과 화면을 바꿀 수 있지만, AI Overview를 강제로 켜는 확실한 스위치는 아닙니다.
이런 변화에 맞게 워크플로를 업데이트하지 않았다면, 본인도 모르는 사이에 결과가 왜곡되거나 부정확해졌을 가능성이 큽니다.
Google 검색 URL 파라미터 치트시트(2026)
자세한 설명에 들어가기 전에, 아래 요약 표가 지금 기준으로 가장 실용적인 최신 목록입니다. 북마크해 두셔도 좋습니다.
| 파라미터 | 기능 | 예시 값 | 상태 |
|---|---|---|---|
q | 검색어(내부에 연산자 포함 가능) | q=best+crm+software | ✅ 사용 가능 |
hl | 인터페이스 언어 | hl=en, hl=ja | ✅ 사용 가능 |
gl | 국가/시장 맥락 | gl=us, gl=jp | ✅ 사용 가능 |
lr | 결과를 특정 콘텐츠 언어로 제한 | lr=lang_en | ✅ 사용 가능 |
cr | 결과를 특정 호스팅 국가로 제한 | cr=countryUS | ✅ 사용 가능 |
start | 페이지 오프셋 | start=10(2페이지) | ✅ 사용 가능 |
num | 페이지당 결과 수(과거 기능) | num=100 | ⚠️ 공식 지원 아님, 2025년 9월 이후 불안정 |
udm | 상황 기반 콘텐츠 모드 | udm=14(클래식 웹) | ⚠️ 역공학 기반, 상황에 따라 다름 |
tbm | 검색 세로 유형 | tbm=isch(이미지) | ⚠️ 아직 관찰되지만 udm과 함께 테스트 필요 |
tbs | 시간 필터, 정렬, verbatim | tbs=qdr:w | ✅ 사용 가능 |
safe | SafeSearch 제어 | safe=active | ✅ 사용 가능 |
filter | 중복 결과 필터링 | filter=0 | ✅ 사용 가능(관찰됨) |
nfpr | 자동 교정 비활성화 | nfpr=1 | ✅ 사용 가능(관찰됨) |
pws | 개인화 비활성화 | pws=0 | ✅ 사용 가능 |
uule | 도시/DMA 단위 지오 타겟팅 | uule=w+CAIQICI... | ✅ 사용 가능(역공학) |
as_q, as_epq, as_eq 등 | 고급 검색 폼 필드 | 다양함 | ✅ 사용 가능 |
as_sitesearch | 도메인 제한(고급 검색) | as_sitesearch=example.com | ✅ 사용 가능 |
as_filetype | 파일 형식 제한(고급 검색) | as_filetype=pdf | ✅ 사용 가능 |
ie, oe | 입력/출력 인코딩 | ie=UTF-8 | ✅ 사용 가능(거의 필요 없음) |
kgmid, si, ibp | Knowledge Graph 엔티티 / 기능 뷰 | 다양함 | ⚠️ 상황 의존적(일반 용도 아님) |
ei, ved, sxsrf, sclient | 세션/추적/텔레메트리 | 다양함 | 🔒 내부용(무시) |
gbv | 기본 HTML 보기(과거 기능) | gbv=1 | ❌ 2026년에는 불안정 |
저장하거나 공유하는 URL에서는 ei, ved, sxsrf, sclient를 제거하세요. 이 값들은 Google이 자동으로 붙이는 세션 및 텔레메트리 정보로, 검색 URL을 구성하는 데는 필요하지 않습니다.
여전히 동작하는 핵심 Google 검색 URL 파라미터
아래 항목들은 2026년 중반 기준으로 실제 테스트를 마쳤습니다. 가장 자주 쓰게 될 파라미터들입니다.
q — 검색어
q 파라미터는 검색어를 담습니다. 공백은 + 또는 %20으로 인코딩됩니다. Google이 문서화한 검색 연산자는 모두 q 값 안에 들어가며, 별도 URL 파라미터가 아닙니다.
예시는 다음과 같습니다.
- 정확한 문구:
q=%22google+search+url+parameters%22 - 사이트 제한:
q=site%3Aexample.com+pricing - 파일 형식:
q=filetype%3Apdf+annual+report+2026 - 복합 조건:
q=site%3Acompetitor.com+intitle%3Apricing+after%3A2026%2F01%2F01
검색어 값 전체는 항상 URL 인코딩하세요. 따옴표, 콜론, 슬래시가 URL을 깨지 않도록 반드시 제대로 인코딩해야 합니다.
hl — 인터페이스 언어
hl은 Google 인터페이스의 언어(버튼, 라벨, "다른 사람들도 묻는 질문" 제목 등)를 제어하고, 어떤 결과를 우선적으로 보여 줄지도 영향을 줍니다. en, fr, de, ja 같은 ISO 639-1 코드나 en-gb, pt-br 같은 BCP 47 태그를 사용합니다.
hl은 결과 문서 전체를 그 언어로 강제하지는 않습니다. 영향은 크지만, 관련성이 높다면 Google은 다른 언어의 결과도 보여 줄 수 있습니다. 콘텐츠 언어 제한이 필요하다면 lr을 사용하세요.
gl — 국가 / 지리 위치
gl은 사용자가 어느 나라에서 검색하는 것처럼 보일지를 ISO 3166-1 alpha-2 코드(us, gb, jp, de)로 시뮬레이션합니다. ccTLD가 점차 google.com으로 리디렉션되는 상황에서, 지금은 gl이 국가별 결과를 얻는 주요 방법입니다.
같은 검색어라도 gl 값이 달라지면 결과, 추천 스니펫, 로컬 팩이 완전히 달라질 수 있습니다. 예를 들어 q=best+bank&gl=us와 q=best+bank&gl=jp는 전혀 다른 은행 결과를 보여 줍니다.
팁: 정확한 로컬라이즈 결과를 보려면 gl과 hl을 함께 쓰세요. gl=jp에 hl=en을 조합하면 일본 시장 결과를 영어 인터페이스로 볼 수 있어, 국제 SEO 감사에 유용합니다.
lr과 cr — 언어 제한과 국가 제한
이 둘은 자주 헷갈립니다. 차이는 분명합니다.
lr=lang_en은 영어로 작성된 페이지로 결과를 제한합니다(콘텐츠 언어)cr=countryUS는 미국에 호스팅된 페이지로 결과를 제한합니다(서버 위치 / 국가 연관성)gl=us는 미국에서 검색하는 것처럼 시뮬레이션합니다(순위, 로컬 결과, 광고에 영향)
lr과 cr은 둘 다 Google의 고급 검색 폼에서 설정할 수 있습니다. 함께 쓸 때는 주의하세요. lr=lang_en + cr=countryJP는 "일본에 호스팅된 영어 페이지"만 보겠다는 뜻이라 범위가 매우 좁습니다. 이 조합은 뒤에서 다룰 충돌 섹션에서 더 설명하겠습니다.
start — 페이지네이션
start=10은 11번째 결과부터 보여 달라는 뜻이고(2페이지), start=20은 3페이지를 뜻합니다. num=100이 더는 믿을 수 없는 만큼 start를 10씩 늘리는 방식이 안전한 기본값이지만, Google이 페이지네이션을 다시 구성하거나 제한할 수도 있습니다.
예전의 num=100&start=0 꼼수로 100개 결과를 한 번에 가져오던 방식은 더 이상 동작하지 않습니다. 아직도 스크립트에 num이 남아 있다면 제거하세요. 조용히 무시되고 있을 가능성이 큽니다.
pws — 개인화 비활성화
pws=0은 계정 기반 개인화를 끄도록 Google에 요청합니다. 자신의 검색 기록, 클릭한 결과, 계정 선호도에 영향을 받지 않는 결과를 보고 싶을 때, 특히 SEO 순위 추적에서 중요합니다.
주의할 점은, pws=0이 개인화를 줄여 주긴 하지만 모든 맥락 요소를 없애지는 않는다는 것입니다. Google에 따르면 결과는 여전히 시간, 위치, 언어, 기기에 따라 달라질 수 있습니다. 완전히 "중립적인" Google SERP란 존재하지 않습니다.
safe와 filter — SafeSearch와 중복 필터링
safe=active는 SafeSearch를 켭니다.safe=off는 끕니다. 다만 계정 설정, 관리자 정책, 네트워크 구성, 지역 법규가 이 값을 덮어쓸 수 있습니다.filter=0는 Google의 중복 결과 필터링을 끕니다. 보통은 합쳐서 보여 주는 거의 중복된 결과까지 모두 보고 싶을 때 유용합니다.
nfpr — 자동 교정 비활성화
nfpr=1은 Google이 오타라고 판단했을 때 검색어를 강제로 다시 쓰지 못하게 막습니다. 특이한 철자의 브랜드명, 기술 용어, 또는 경쟁사가 타깃하는 의도적 오타 검색어를 추적할 때 유용합니다.
다만 nfpr=1은 강제 재작성만 막습니다. 동의어 확장, 철자 변경, 기타 자동 수정까지 더 넓게 제어하려면 아래 tbs 섹션에서 설명하는 tbs=li:1(verbatim 모드)을 사용하세요.
tbm에서 udm으로의 전환: 무엇이 바뀌었고 이제 무엇을 써야 하나?
이것은 최근 몇 년간 가장 큰 파라미터 변화 중 하나지만, 과장되기 쉬운 부분이기도 합니다.
tbm은 이미지, 뉴스, 동영상, 쇼핑 같은 Google의 검색 세로 유형을 바꿀 때 10년 넘게 널리 쓰여 온 방식입니다. Google은 여기에 겹치는 숫자 기반 udm 시스템도 도입했습니다. 하지만 안정적인 공개 레지스트리를 제공하지는 않았기 때문에, 이걸 깔끔한 교체 관계라기보다 상황별 매핑으로 보는 편이 맞습니다.
tbm → udm 완전 매핑 표
아래 매핑은 관찰된 UI 동작과 2026년 8월 12일의 실시간 점검을 합친 것입니다. 익명 요청에서는 일부 값이 제거되거나 다시 쓰였기 때문에, 실제 사용할 계정, 지역, 클라이언트 환경에서 반드시 각 행을 테스트해야 합니다.
| 기존 파라미터 | 기존 값 | 새 파라미터 | 새 값 | 상태 |
|---|---|---|---|---|
tbm=lcl | 장소/로컬 | udm=1 | 장소/로컬 | ⚠️ 상황 의존적 |
tbm=isch | 이미지 | udm=2 | 이미지 | ⚠️ 상황 의존적 |
tbm=vid | 동영상 | udm=7 | 동영상 | ⚠️ 상황 의존적 |
tbm=nws | 뉴스 | udm=12 | 뉴스 | ⚠️ 상황 의존적 |
| — | — | udm=14 | 클래식 웹(AI Overview 없음) | 🆕 신규, tbm 대응값 없음 |
| — | — | udm=18 | 포럼 | 🆕 신규, tbm 대응값 없음 |
tbm=shop | 쇼핑 | udm=28 | 쇼핑 | ⚠️ 상황 의존적 |
tbm=bks | 도서 | udm=36 | 도서 | ⚠️ 상황 의존적 |
| — | — | udm=39 | 짧은 동영상 | 🆕 신규, tbm 대응값 없음 |
| — | — | udm=50 | AI Overview 모드 | 🆕 신규, tbm 대응값 없음 |
Google은 안정적인 udm 레지스트리를 공개하지 않았습니다. 이 점이 아주 중요합니다. 이 값들은 Google UI 동작을 관찰해 역공학한 결과입니다. URL 허용 여부는 계정, 지역, 클라이언트, 쿠키, 실험 그룹에 따라 달라집니다. 테스트해 보니 일부 udm 값은 익명 HTTP 요청에서는 제거되었지만, 브라우저 세션에서는 잘 작동했습니다. 모든 값이 보편적으로 작동한다고 생각하면 안 됩니다.
udm=14가 하는 일과 SEOs가 좋아하는 이유
udm=14는 SEO 커뮤니티에서 일종의 인기 비법처럼 굳어졌습니다. Android Central은 이를 AI Overviews 없이 클래식 웹 결과 화면을 요청하는 방법으로 소개했습니다. 많은 세션에서 전통적인 파란 링크 SERP를 보여 주지만, 공식적이거나 전 세계적으로 보장되는 기능은 아닙니다.
왜 중요할까요? 순위 추적이나 SEO 감사에서는 AI Overviews가 오가닉 결과를 아래로 밀어내기 때문에 실제 순위를 파악하기가 더 어려워집니다. Google이 이를 받아들여 준다면 udm=14는 더 깔끔한 화면을 보여 줄 수 있습니다.
하지만 udm=14가 모든 상황에서 확실히 작동한다고 보기는 어렵습니다. 2026년 8월 12일 실시간 점검에서도 Google은 요청 맥락에 따라 udm 값을 지우거나 다시 쓰는 경우가 있었습니다. 세션, 계정, 지역, 클라이언트, 실험 그룹에 따라 결과는 달라질 수 있습니다.
udm=50은 AI Mode / AI 결과 맥락에서 관찰된 적이 있지만, 임의의 쿼리에 대해 AI Overview를 강제로 띄우는 확실한 방법이라고 말하면 안 됩니다.
해야 할 일: 워크플로를 tbm에서 udm으로 업데이트하기
제 권장 사항은 다음과 같습니다.
- 새 구현:
udm을 실험적/상황 기반 입력으로 취급하고 대체 경로를 준비하세요. - 기존 워크플로: 관련이 있다면
tbm과udm둘 다 지원하고 테스트하세요. 전환이 끝났다고 단정하지 마십시오. - 둘 다 함께 쓰지 마세요: URL에
tbm과udm이 동시에 있으면 동작이 예측 불가능합니다. 테스트에서는 Google이 둘 다 제거하고 일반 쿼리로 돌려주는 경우도 있었습니다. 충돌 섹션에서 다시 다룹니다.
tbs 전체 문법: 사용자 지정 날짜 범위, 날짜순 정렬, verbatim
tbs는 Google 검색 URL 도구상자에서 가장 강력한 파라미터 중 하나지만, 대부분의 가이드는 표면만 다룹니다. 이 파라미터 하나에 시간 필터링, 날짜 정렬, verbatim 모드 등이 쉼표로 구분된 값으로 모두 들어갑니다.
표준 시간 필터
tbs 값 | 의미 | 예시 URL 조각 |
|---|---|---|
qdr:h | 지난 1시간 | &tbs=qdr:h |
qdr:d | 지난 24시간 | &tbs=qdr:d |
qdr:w | 지난 1주 | &tbs=qdr:w |
qdr:m | 지난 1개월 | &tbs=qdr:m |
qdr:y | 지난 1년 | &tbs=qdr:y |
이 정도는 대부분의 가이드가 다룹니다. 하지만 tbs는 훨씬 더 많은 일을 할 수 있습니다.
사용자 지정 날짜 범위
특정 기간의 결과가 필요하신가요? cdr:1,cd_min:MM/DD/YYYY,cd_max:MM/DD/YYYY 문법을 사용하세요.
&tbs=cdr:1,cd_min:01/01/2026,cd_max:06/01/2026
이렇게 하면 Google이 2026년 1월 1일부터 6월 1일 사이의 날짜와 연관지은 결과만 필터링합니다. 경쟁사 조사에 아주 유용합니다. 예를 들어 "2026년 1분기에 경쟁사들이 가격 관련해 무엇을 발행했는가?" 같은 질문에 잘 맞습니다. 다만 콜론과 स्ल래시는 인코딩이 필요하므로 전체 값을 URL 인코딩해야 합니다.
실무 팁 하나: Google의 날짜 연관은 항상 정확하지 않습니다. 검색 결과에 표시된 날짜는 실제 게시일이 아니라 Google의 추정치일 수 있습니다. 대상 페이지에서 날짜를 반드시 다시 확인하세요.
날짜순 정렬과 Verbatim 모드
여기서는 경쟁 글들이 잘 다루지 않는 영역까지 설명합니다.
sbd:1 은 결과를 날짜순으로 정렬합니다(최신순). 단독으로도 유용하지만, 더 흥미로운 점은 시간 범위 필터와 하나의 tbs 값 안에서 함께 쓸 수 있다는 것입니다.
&tbs=qdr:m,sbd:1
이렇게 하면 지난 한 달 결과를 날짜순(최신순)으로 볼 수 있습니다. 특정 주제에서 방금 나온 콘텐츠를 찾는 가장 빠른 방법입니다. 경쟁사 콘텐츠 모니터링에서 저는 이 조합을 아주 자주 씁니다.
li:1 은 verbatim 모드를 켭니다. 검색 인터페이스에서 Google의 "Verbatim" 도구를 눌렀을 때와 같은 효과를 URL로 구현한 것입니다. Verbatim 모드는 자동 교정, 동의어 확장, 철자 변경, 기타 자동 쿼리 수정을 비활성화합니다.
li:1과 nfpr=1의 차이는 범위에 있습니다.
nfpr=1: 강제 철자/쿼리 재작성만 막습니다(예: Google이 "teh"를 "the"로 바꾸지 못하게 함)tbs=li:1: 철자, 동의어, 관련어, 개인화 조정 등 모든 자동 수정을 끕니다
여러 tbs 값을 한 번에 묶을 수도 있습니다. 예를 들어 tbs=qdr:m,sbd:1,li:1은 지난 한 달 결과를 날짜순으로 보여 주면서 verbatim 일치도 적용합니다. 테스트해 본 결과 이 조합은 잘 작동했지만, tbs는 공식 문서화된 문법이 아니므로 본인 쿼리로 다시 확인하는 것이 좋습니다.
도시 단위 지오 타겟팅용 uule 코드를 만드는 방법
gl이 국가 단위 확대경이라면, uule은 도시 단위 현미경입니다. 로컬 SEO에서 내 비즈니스가 덴버와 댈러스에서 어떻게 다르게 보이는지, 또는 도쿄 시부야 구의 검색자가 무엇을 보는지 확인하려면 gl만으로는 부족합니다.
상위권 글들 가운데 실제로 uule 코드를 어떻게 만드는지까지 설명하는 글은 거의 없습니다. 보통은 파라미터가 있다는 정도만 말하고 끝냅니다. 아래에서 전체 과정을 설명하겠습니다.
gl vs uule vs cr, 언제 무엇을 써야 하나
| 파라미터 | 세부 수준 | 대표 활용 사례 | 인코딩 필요 여부 |
|---|---|---|---|
gl=us | 국가 단위 | 빠른 국가 시뮬레이션 | 아니오 |
cr=countryUS | 국가 단위(제한) | 호스팅 국가로 필터링 | 아니오 |
uule=w+CAIQICI... | 도시/DMA 단위 | 로컬 SEO 순위 확인 | 예 |
uule 인코딩 알고리즘(단계별)
uule 파라미터는 인코딩된 명명 위치 신호를 사용합니다. 이 구성 방식은 Google이 공식 문서로 공개하지 않은 역공학 결과이지만, SEO 커뮤니티에서 널리 검증되었습니다.
널리 복사되는 단축 방식은 비ASCII 문자에서 실패할 수 있으니, 더 안전한 방법은 작은 Protocol Buffers 페이로드를 인코딩하는 것입니다. 과정은 다음과 같습니다.
- Google의 표준 위치명을 가져옵니다. Google Ads API의 지오 타겟팅 데이터에서 표준 위치명을 제공합니다. Google Ads API 지오 타겟팅 데이터를 참고하세요. 예:
New York,New York,United States - 이 이름을 UTF-8 바이트로 인코딩합니다.
- 이름과 바이트 길이를 담은 작은 protobuf 페이로드를 만듭니다.
- 페이로드를 Base64url로 인코딩한 뒤
w+를 앞에 붙입니다.
아래는 이를 수행하는 Python 예시입니다.
import base64
def encode_varint(value: int) -> bytes:
out = bytearray()
while True:
byte = value & 0x7F
value >>= 7
if value:
out.append(byte | 0x80)
else:
out.append(byte)
return bytes(out)
def build_uule(canonical_name: str) -> str:
name = canonical_name.encode("utf-8")
payload = b"\x08\x02\x10\x20\x12" + encode_varint(len(name)) + name
encoded = base64.urlsafe_b64encode(payload).decode().rstrip("=")
return "w+" + encoded
# 예시
print(build_uule("New York,New York,United States"))
# 출력: w+CAIQICIeTmV3IFlvcmssTmV3IFlvcmssVW5pdGVkIFN0YXRlcw
이 값을 URL에 넣을 때는 w+의 +가 URL 라이브러리에 의해 %2B로 올바르게 인코딩되는지 확인하세요. 대부분의 URLSearchParams나 urllib.parse.urlencode 구현은 이를 자동으로 처리합니다.
올바르게 만든 uule도 결국 하나의 위치 신호일 뿐입니다. IP 주소, 계정 설정, 기기, 실험 그룹을 덮어쓰지는 못합니다. 정확한 도시 순위를 보장하는 도구가 아니라, 방향성을 보는 로컬 SEO 체크 용도로 쓰세요.
Google 검색 URL 파라미터가 조용히 충돌하는 경우
파라미터 조합은 조용히 실패할 수 있습니다. Google이 입력 하나를 무시하거나, URL을 다시 쓰거나, 아예 다른 화면을 보여 줄 수 있습니다. 아래 충돌 체크는 검색 링크 워크플로마다 넣어 둘 가치가 있습니다.
이런 파라미터 상호작용을 다룬 경쟁 글은 거의 없습니다. 하지만 여러 파라미터를 조합해 검색 URL을 만들고 있다면 — 아마 그렇겠죠 — 어떤 조합이 잘 맞고 어떤 조합이 충돌하는지 알아야 합니다.
gl + uule: 어느 쪽이 우선인가?
둘 다 있으면 uule이 gl보다 더 구체적인 위치 신호를 제공합니다. gl=uk이면서 Tokyo를 가리키는 uule을 넣으면, UK 결과가 아니라 Tokyo 영향이 반영된 결과가 나옵니다.
권장 사항: uule을 사용할 경우 gl은 아예 빼거나, 최소한 uule 도시가 속한 국가로 맞추세요. 서로 모순되는 신호를 보내지 마십시오.
tbm + udm: 둘 다 쓰지 마세요
테스트 결과, 같은 URL에 tbm과 udm이 함께 있으면 Google이 둘 다 제거하고 일반 웹 쿼리로 되돌리는 경우가 있었습니다. 이 동작은 세션과 계정에 따라 들쭉날쭉했습니다.
권장 사항: 새 구현에서는 udm만 쓰세요. 기존 워크플로를 지원해야 한다면 하나만 선택하고, 절대 둘 다 함께 쓰지 마십시오.
lr + cr: 이중 필터링으로 결과가 0개가 될 수 있음
이건 꽤 미묘한 함정입니다. lr=lang_en은 영어 콘텐츠로 제한하고, cr=countryJP는 일본에 호스팅된 페이지로 제한합니다. 둘을 합치면 "일본에 호스팅된 영어 페이지"만 찾겠다는 뜻이라 웹 전체에서 매우 작은 부분만 남게 됩니다.
권장 사항: 딱 그 교집합이 필요한 경우가 아니면 둘 중 하나만 쓰세요. 함께 사용한다면 결과 수가 크게 줄어들 수 있습니다.
num + start: 깨진 페이지네이션
예전 스크립트에서 num=100&start=0을 쓰던 방식은 이제 조용히 약 10개 결과만 반환합니다. num은 더 이상 존중되지 않지만 오류를 내지 않고 그냥 무시됩니다.
권장 사항: 모든 URL에서 num을 제거하세요. start를 10씩 늘리며 페이지를 넘기고, 페이지 간 중복 결과를 제거하세요.
빠른 충돌 참고표
| 조합 | 결과 | 권장 사항 |
|---|---|---|
gl + uule | uule이 더 구체적인 신호 제공 | 국가와 도시를 맞추거나 gl을 생략 |
tbm + udm | 예측 불가 — 둘 다 제거될 수 있음 | udm만 사용 |
lr + cr | 과도한 제한, 결과가 거의 없음 | 둘 중 하나만 사용 |
num + start | num 무시, 약 10개 결과만 반환 | num 제거, start로 페이지네이션 |
nfpr=1 + tbs=li:1 | 관련은 있지만 동일하진 않음 | 쿼리별로 테스트 |
hl + lr | 인터페이스 언어 ≠ 콘텐츠 언어 제한 | 의도적으로 사용하세요; hl은 콘텐츠 필터가 아님 |
Google 검색 URL 파라미터에서 구조화 데이터 추출까지
이쯤이면 정확한 Google 검색 URL을 만들 수 있습니다. 올바른 쿼리, 올바른 국가, 올바른 날짜 범위, 클래식 웹 결과까지 준비된 상태입니다. 다음 단계는 결과에서 구조화된 데이터를 꺼내는 일입니다.
순위 추적기를 만들든, 경쟁사를 모니터링하든, 검색 데이터를 리서치 워크플로에 넣든, 올바른 결과를 보는 것만으로는 충분하지 않습니다. 제목, URL, 스니펫, 순위 위치, 날짜를 스프레드시트나 데이터베이스로 가져와야 합니다.
타깃 Google 검색 URL 만들기(전체 조합 예시)
여러 파라미터를 결합한 완전한 예시는 다음과 같습니다.
https://www.google.com/search?q=site%3Acompetitor.com+intitle%3Apricing&hl=en&gl=us&tbs=qdr:m,sbd:1&udm=14&pws=0
분해해 보면:
q=site%3Acompetitor.com+intitle%3Apricing— competitor.com 도메인에서 제목에 "pricing"이 들어간 페이지hl=en— 영어 인터페이스gl=us— 미국 시장 맥락tbs=qdr:m,sbd:1— 지난 한 달, 날짜순 정렬udm=14— 클래식 웹 결과(AI Overviews 없음)pws=0— 개인화 비활성화
curl로 프로그램적으로 만들 수도 있습니다.
curl -L -G 'https://www.google.com/search' \
--data-urlencode 'q=site:competitor.com intitle:pricing' \
--data-urlencode 'hl=en' \
--data-urlencode 'gl=us' \
--data-urlencode 'tbs=qdr:m,sbd:1' \
--data-urlencode 'udm=14' \
--data-urlencode 'pws=0' \
-H 'User-Agent: Mozilla/5.0'
또는 Python으로:
import requests
params = {
"q": "site:competitor.com intitle:pricing",
"hl": "en",
"gl": "us",
"tbs": "qdr:m,sbd:1",
"udm": "14",
"pws": "0",
}
response = requests.get(
"https://www.google.com/search",
params=params,
headers={"User-Agent": "Mozilla/5.0"},
timeout=20,
)
print(response.url)
Google에 대한 익명 HTTP 요청은 서버 렌더링 결과가 없는 JavaScript 셸이나 비정상 트래픽 경고를 반환하는 경우가 많습니다. 바로 이런 지점에서 브라우저 기반 추출이 강점을 가집니다.
파서 없이 SERP 데이터 추출하기
Google HTML을 직접 파싱하는 일은 아주 취약합니다. DOM 구조는 자주 바뀌고, 클래스명은 난독화되어 있으며, 브라우저에서 보이는 화면과 원시 HTTP 응답이 항상 같지도 않습니다.
비개발자에게 더 쉬운 방법은, 정교하게 만든 검색 URL을 Chrome에서 열고 브라우저 기반 추출 도구로 보이는 페이지에서 구조화 데이터를 뽑는 것입니다. Thunderbit에서는 이런 워크플로를 위해 Chrome 확장 프로그램을 만들었습니다. AI Suggest Fields를 사용해 결과 제목, 목적지 URL, 스니펫 텍스트, 보이는 순위 같은 컬럼을 찾아낸 뒤, 파서를 직접 작성하지 않고도 스프레드시트로 추출할 수 있습니다.
이 방법만 있는 것은 아닙니다. 코드 기반 접근도 잘 작동합니다. 특히 대규모이거나 반복적인 추출이 필요하다면 더 적합할 수 있습니다. 하지만 일회성 리서치, 감사, 경쟁사 분석이라면 브라우저 기반 추출이 HTML 파싱의 취약성을 아예 피할 수 있습니다.
공식 API를 써야 할 때
책임 있는 사용이 중요합니다.
Google 이용약관은 보호 조치를 우회하는 자동 접근을 금지하며, Google Search Help는 순위 확인을 위해 자동 쿼리를 보내는 검색 스크래퍼와 소프트웨어를 명시적으로 자동 트래픽으로 분류합니다. 운영 규모의 Google 스크래퍼를 돌리면 IP 차단, CAPTCHA, 잠재적인 법적 문제를 맞을 수 있습니다.
대규모의 프로덕션 검색 데이터가 필요하다면 더 나은 선택은 공식 API입니다. Google의 Custom Search JSON API는 신규 고객을 받지 않고 있으며, 기존 사용자는 2027년 1월 1일까지 전환해야 합니다. 이후에는 하루 100회 무료 쿼리와 1,000쿼리당 5달러가 적용됩니다. Google은 앞으로 제어된 사이트 검색에는 Vertex AI Search를 권장합니다.
자신이 소유한 사이트라면 Search Console의 Search Analytics API가 클릭수, 노출수, CTR, 평균 순위를 얻는 1차 데이터 소스입니다. 스크래핑이 필요 없습니다.
URL 파라미터 지식은 진단과 리서치 도구로 생각하세요. 정밀한 검색 링크를 만들고, 수동 감사를 수행하고, Google이 무엇을 보여 주는지 이해하는 데는 아주 좋습니다. 하지만 대규모 작업을 대신하는 수단은 아닙니다.
Google 검색 연산자: 쿼리 안에 들어가는 파라미터
검색 연산자는 q= 파라미터 내부에 들어가지만, URL 파라미터와 함께 써야 하는 중요한 동반자입니다. 아래 표에는 Google이 현재 문서화한 연산자와 실제로도 여전히 잘 작동하는 몇 가지를 함께 정리했습니다.
| 연산자 | 기능 | 예시 |
|---|---|---|
site: | 도메인 제한 | q=site:example.com+SEO |
filetype: | 파일 형식 제한 | q=filetype:pdf+annual+report |
intitle: | 제목에 반드시 포함 | q=intitle:pricing+SaaS |
inurl: | URL에 반드시 포함 | q=inurl:blog+marketing |
- | 특정 용어 제외 | q=apple+-fruit |
"" | 정확히 일치하는 문구 | q=%22google+search+url+parameters%22 |
OR | 둘 중 하나 | q=scraping+OR+crawling |
before: | 특정 날짜 이전 결과 | q=AI+before:2026-01-01 |
after: | 특정 날짜 이후 결과 | q=AI+after:2025-06-01 |
related: | 유사한 사이트 | q=related:hubspot.com |
진짜 힘은 q 안의 연산자와 바깥의 URL 파라미터를 함께 쓸 때 나옵니다.
q=site:competitor.com+intitle:pricing+after:2026/01/01&tbs=sbd:1&gl=us&udm=14
이 식은 competitor.com에서 제목에 "pricing"이 들어가고, 2026년 1월 이후에 발행되었으며, 미국 시장 기준으로 날짜순 정렬된 클래식 웹 결과를 찾습니다. URL 파라미터와 연산자만으로 만든 꽤 정밀한 경쟁 정보 검색입니다.
Google은 site: 결과가 완전하다고 보장하지 않는다고 말합니다. 따라서 site: 쿼리를 색인된 전체 페이지의 완전한 목록처럼 취급하면 안 됩니다.
책임 있는 사용: Google 이용약관과 속도 제한
짧지만 중요한 내용입니다.
Google 이용약관은 남용적인 접근과 보호 조치 우회를 금지합니다. Google Search Help는 검색 스크래퍼와 자동 순위 확인 소프트웨어를 자동 트래픽의 예로 명시합니다. 이를 위반하면 IP 차단, CAPTCHA, 계정 제한, 심지어 법적 조치로 이어질 수 있습니다.
URL 파라미터 지식은 다음 용도로 가장 잘 활용됩니다: 정밀한 검색 URL 수동 구성, 팀용 북마크 가능한 검색 링크 작성, 브라우저에서 소규모 감사 수행, Google 검색 인터페이스의 작동 방식 이해. 운영 규모의 자동화 작업에는 Google의 공식 API 또는 Brave Search API 같은 라이선스가 있는 서드파티 검색 데이터 제공업체를 사용하세요.
Thunderbit의 브라우저 확장 프로그램은 고빈도 자동 Google 질의가 아니라, 사용자가 직접 열어 본 페이지에서 데이터를 추출하는 용도로 설계되었습니다. 이 차이는 꽤 중요합니다.
핵심 정리: 2026년 Google 검색 URL 파라미터 도구상자
압축해서 정리하면 다음과 같습니다.
- 현지화 신호는
gl+hl을 사용하세요. Google의 리디렉션 전환기에는 ccTLD만 믿지 마십시오 - 관련 상황에서는
udm과tbm을 둘 다 테스트하세요. 둘 다 버전이 고정된 안정적 소비자 API가 아닙니다 udm=14는 AI Overviews 없이 클래식 웹 결과를 요청할 수 있지만, Google이 값을 제거하거나 다시 쓸 수 있습니다- 도시 단위 지오 타겟팅에는
uule을 사용하세요. 위의 protobuf 인코딩 공식을 활용하면 됩니다 tbs를 제대로 익히세요. 정밀한 날짜 필터링(cdr:1,cd_min:...,cd_max:...), 날짜순 정렬(sbd:1), verbatim 검색(li:1)에 유용합니다- 파라미터 충돌을 조심하세요:
gl대uule,tbm대udm,lr대cr num=100은 불안정하고 애초에 공식 지원도 아니었습니다. 더 안전한 기본값은start를 10씩 늘리는 방식입니다- 구조화된 SERP 데이터가 필요하다면, 일회성 작업에는 Thunderbit 같은 브라우저 기반 도구를, 대규모 운영에는 공식 API를 사용하세요
- Google 이용약관을 준수하세요. URL 파라미터는 리서치 도구이지, 스크래핑 허가증이 아닙니다
Google은 공지 없이 파라미터를 계속 바꾸고 있습니다. 변동 사항이 생기면 이 레퍼런스를 계속 최신으로 유지하겠습니다. 북마크해 두고 다시 확인하세요.
더 알아보기
- 2026년 최고의 SEO API 9선(실제 요청당 비용 데이터 포함)
- 검색 엔진 스크래핑 마스터하기: 완전 가이드
- 웹사이트 순위를 분석하고 모니터링하는 최고의 도구 27선
- 효율적인 추출을 위한 Web Scraper 페이지네이션 사용법
- 검색 자동화란? 장점, 도구, 전략
자주 묻는 질문
Google 검색 URL에서 udm=14는 무엇을 하나요?
udm=14는 AI Overviews 없이 클래식 웹 결과 화면을 요청할 수 있어 SEO 실무자들에게 인기가 많습니다. 다만 이는 역공학으로 알아낸 값이며 Google이 공식 문서로 보장한 계약은 아닙니다. 세션, 계정, 지역, 클라이언트, 실험 그룹에 따라 Google이 값을 제거하거나 다시 쓸 수 있습니다.
2026년에도 num 파라미터는 작동하나요?
믿지 마세요. Google은 2025년 9월부터 num=100을 안정적으로 처리하지 않기 시작했습니다. 또한 대변인은 이 파라미터가 애초에 공식 지원 대상이 아니었다고 밝혔습니다. 더 안전한 페이지네이션 기본값은 start를 10씩 늘리는 방식이며, Google이 응답을 다시 쓰거나 제한할 수 있으므로 반환된 결과 수도 확인해야 합니다.
특정 도시에서 하는 것처럼 Google 검색을 시뮬레이션하려면 어떻게 하나요?
인코딩된 도시 이름과 함께 uule 파라미터를 사용하세요. 위의 인코딩 섹션에 protobuf 기반 알고리즘과 Python 예제가 있습니다. 필요한 것은 Google의 표준 위치명이며, Google Ads 지오 타겟팅 데이터에서 확인할 수 있습니다. 이를 uule=w+CAIQICIeNew+York,New+York,United+States 같은 값으로 인코딩하면 됩니다.
gl, lr, cr의 차이는 무엇인가요?
이 세 파라미터는 지리 및 언어 타겟팅의 서로 다른 측면을 제어합니다. gl은 국가 수준에서 검색 위치를 시뮬레이션하고(순위와 로컬 결과에 영향), lr은 특정 콘텐츠 언어로 작성된 페이지로 제한하며, cr은 특정 국가에 호스팅된 페이지로 제한합니다. 함께 사용할 수는 있지만, lr=lang_en + cr=countryJP처럼 모순되는 조합은 결과를 크게 줄입니다.
한 URL에서 여러 tbs 값을 조합할 수 있나요?
네. 하나의 tbs 파라미터 안에서 쉼표로 구분하면 됩니다. 예를 들어 tbs=qdr:m,sbd:1은 지난 한 달 결과를 최신순으로 보여 줍니다. 여기에 li:1을 더해 tbs=qdr:m,sbd:1,li:1처럼 verbatim 모드도 넣을 수 있습니다. tbs 문법은 공식 문서화되어 있지 않으므로, 기대한 대로 작동하는지 각 조합을 직접 테스트하는 것이 좋습니다.
