Параметры URL Google Поиска: что по-прежнему работает в 2026 году

Примерно в сентябре 2025 года у многих SEO-инструментов и пользовательских скриптов тихо перестала работать часть функций. Причина? Google перестал стабильно учитывать параметр num=100, на который power users годами опирались, чтобы получать по 100 результатов на странице. Формального уведомления о выводе из поддержки не было — лишь представитель Google сообщил Search Engine Land, что параметр «официально не поддерживается». Примерно в то же время Google добавил больше режимов udm наряду со старыми вертикалями tbm, объявил о постепенном редиректе доменов с кодами стран на google.com и сообщил, что AI Overviews достигли более 2,5 млрд пользователей в месяц.

Если вы строите поисковые URL, отслеживаете позиции или автоматизируете исследования с помощью параметров URL Google, высока вероятность, что часть ваших процессов сейчас незаметно работает хуже. В Thunderbit мы изучили актуальную документацию Google, недавние анонсы изменений, обратную инженерную разметку и живые проверки, чтобы отделить стабильные настройки от контекстных. В итоге получился справочник с датой актуальности и советом «сначала тестируйте, потом внедряйте» по параметрам Google Search, важным в 2026 году, включая соответствия tbm/udm, формулу кодирования uule для геотаргетинга на уровне города и конфликты параметров, которые могут сэкономить часы отладки.

Что такое параметры URL Google Search?

Параметры URL Google Search — это пары key=value, которые идут после ? в поисковом URL Google. Они управляют всем: от самого запроса до страны, по которой показываются результаты, и до того, увидите ли вы изображения, новости или обычные синие ссылки.

Типичный URL поиска Google выглядит так:

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 говорит Google показывать результаты так, будто вы в США
• tbs=qdr:m фильтрует результаты за последний месяц

Важно различать: операторы поиска вроде site:, filetype: и intitle: находятся внутри значения q=. Это часть запроса. Параметры URL вроде gl, hl и tbs — это отдельные ключи в URL, которые управляют тем, как Google обрабатывает и отображает результаты. И то и другое важно, но это разные механизмы.

Google никогда не публиковал единую, версионированную спецификацию этих параметров. Часть из них пришла из формы расширенного поиска, часть — из Custom Search API, а часть была восстановлена по наблюдениям за собственными URL Google. Поэтому эта статья основана на живых тестах и задокументированном поведении, а не на официальном контракте API.

Почему параметры URL Google Search важны в 2026 году

Параметры URL — это не только задача для разработчиков. Если вы работаете в SEO, маркетинге, продажах, операциях или продукте и вам нужно понимать, что Google показывает по конкретному запросу, на конкретном рынке и в конкретный момент времени, — эти параметры являются вашим набором инструментов.

Кратко о том, кому и чем они полезны:

Сценарий	Кому помогает	Ключевые параметры
Отслеживание позиций SEO по странам	Команды SEO и маркетинга	gl, hl, uule, pws
Мониторинг конкурентов по датам	Стратегия и операционные команды	tbs, q с site:
Мониторинг рекламы на конкретных рынках	Команды paid media	gl, hl, udm
Аудиты локального SEO на уровне города	Владельцы локального бизнеса	uule, gl
Исследование контента / отслеживание трендов	Контент-команды	tbs (фильтры по датам), lr
Передача поисковых данных в AI/LLM-приложения	Продуктовые и data-команды	Несколько параметров + структурированное извлечение

Три крупных изменения особенно сильно отличают 2026 год:

1. num=100 больше не работает надёжно. Старый приём для получения 100 результатов на страницу перестал стабильно работать в сентябре 2025. Google формально не объявлял его устаревшим; представитель компании сказал, что параметр никогда официально не поддерживался.
2. Редиректы ccTLD — это миграция, а не завершённый переход. В апреле 2025 Google объявил о постепенном редиректе доменов с кодами стран (google.co.uk, google.de и т. д.) на google.com. Google не публиковал уведомление о завершении, поэтому не стоит считать, что все локали уже ведут себя одинаково.
3. AI Overviews изменили SERP. Google сообщает, что AI Overviews достигли более 2,5 млрд пользователей в месяц и охватывают более 200 стран и территорий. Реверс-инжиниринг режимов udm может менять выдачу в отдельных сценариях, но это не гарантированный переключатель AI Overview.

Если ваши процессы не были обновлены с учётом этих изменений, вы, вероятно, уже получаете искажённые или вводящие в заблуждение результаты и даже не замечаете этого.

Шпаргалка по параметрам URL Google Search (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
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, etc.	Поля формы расширенного поиска	Разные	✅ Активны
as_sitesearch	Ограничение по домену (Advanced Search)	as_sitesearch=example.com	✅ Активен
as_filetype	Ограничение по типу файла (Advanced Search)	as_filetype=pdf	✅ Активен
ie, oe	Кодировка ввода/вывода	ie=UTF-8	✅ Активны (редко нужны)
kgmid, si, ibp	Сущность Knowledge Graph / вид функции	Разные	⚠️ Контекстные (не для общего применения)
ei, ved, sxsrf, sclient	Сессия/трекер/телеметрия	Разные	🔒 Внутренние (игнорировать)
gbv	Базовый HTML-вид (ранее)	gbv=1	❌ Ненадёжен в 2026

Удаляйте ei, ved, sxsrf и sclient из любых URL, которые вы сохраняете или пересылаете. Это сессионные и телеметрические данные, которые Google добавляет автоматически, — они не нужны для построения поисковых ссылок.

Основные параметры Google Search 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: кнопок, подписей, заголовков блока "Похожие вопросы" и т. д., а также влияет на то, какие результаты Google приоритизирует. Используются коды ISO 639-1, например en, fr, de, ja, или теги BCP 47 вроде en-gb и pt-br.

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, удалите его — Google silently его игнорирует.

pws — отключение персонализации

pws=0 просит Google отключить персонализацию, связанную с аккаунтом. Это критически важно для отслеживания позиций в SEO, когда вам нужны результаты без влияния истории поиска, прошлых кликов или настроек аккаунта.

Но важно понимать: pws=0 уменьшает персонализацию, но не убирает все контекстные факторы. Google говорит, что результаты всё равно могут отличаться в зависимости от времени, местоположения, языка и устройства. То есть по-настоящему «нейтральной» выдачи Google не существует.

safe и filter — SafeSearch и фильтрация дублей

• safe=active включает SafeSearch; safe=off отключает его. Учтите, что настройки аккаунта, политики администратора, сетевые конфигурации или местные законы могут переопределить этот параметр.
• filter=0 отключает фильтрацию дублей в Google. Полезно, если вы хотите увидеть все результаты, включая почти дубли, которые обычно сворачиваются.

nfpr — отключение автокоррекции

nfpr=1 не даёт Google принудительно переписывать запрос, если система считает, что вы допустили ошибку. Это полезно при отслеживании брендовых терминов с необычным написанием, технического жаргона или намеренно искажённых запросов, на которые ориентируются конкуренты.

Важно: nfpr=1 отключает только принудительное переписывание. Для более широкого контроля — отключения расширения синонимов, исправления орфографии и других автоматических модификаций — используйте tbs=li:1 (verbatim-режим), о котором я расскажу ниже в разделе tbs.

Переход с tbm на udm: что изменилось и что использовать теперь

Это одно из самых заметных изменений параметров за последние годы — и одно из самых простых для преувеличения.

tbm уже более десяти лет используется для переключения между вертикалями поиска Google — изображениями, новостями, видео, покупками. Google также ввёл числовую систему udm с частично пересекающимися и дополнительными режимами. Поскольку Google не публиковал стабильный реестр для обычных пользователей, воспринимайте это как контекстное соответствие, а не как чистую и завершённую замену.

Полная таблица соответствий tbm → udm

Ниже приведены соответствия, основанные на наблюдаемом поведении интерфейса и живых проверках на дату 12 августа 2026 года. Несколько значений удалялись или переписывались в анонимных запросах, поэтому каждую строку нужно тестировать в том аккаунте, регионе и клиенте, где она будет использоваться:

Старый параметр	Старое значение	Новый параметр	Новое значение	Статус
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. Приём URL зависит от аккаунта, региона, клиента, cookies и экспериментальной группы. В моих тестах некоторые значения udm удалялись в анонимных HTTP-запросах, но нормально работали в интерактивной браузерной сессии. Не стоит считать, что каждое значение работает везде одинаково.

Что делает udm=14 и почему SEO-специалисты его любят

udm=14 стал своего рода культовым параметром в SEO-сообществе. Android Central описал его как способ получить классическую веб-выдачу без AI Overviews. Во многих сессиях он действительно показывает традиционную SERP с синими ссылками, но это неофициальная и не универсальная гарантия.

Почему это важно? Если вы отслеживаете позиции или проводите SEO-аудит, AI Overviews могут увести органические результаты ниже первого экрана и затруднить оценку позиций. udm=14 может дать более чистую картину, если Google его учитывает.

Но udm=14 не гарантированно работает в любом контексте. В живых проверках 12 августа 2026 года Google иногда удалял или переписывал значения udm в зависимости от контекста запроса. Результат будет отличаться в зависимости от сессии, аккаунта, региона, клиента и экспериментальной группы.

udm=50 замечен в режимах AI Mode/AI-result, но его нельзя описывать как гарантированный способ принудительно включить AI Overview для любого запроса.

Что делать: обновите рабочие процессы с tbm на udm

Моя рекомендация:

• Новые реализации: воспринимайте udm как экспериментальный/контекстный ввод и закладывайте fallback-логики.
• Существующие процессы: при необходимости поддерживайте и тестируйте как tbm, так и udm, а не предполагайте, что миграция уже завершена.
• Никогда не используйте оба одновременно: если в URL присутствуют и tbm, и udm, поведение становится непредсказуемым. В моих тестах Google иногда удалял оба параметра и возвращал обычный запрос. Об этом ещё будет сказано в разделе конфликтов.

Полный синтаксис tbs: собственные диапазоны дат, сортировка по дате и verbatim

tbs — один из самых мощных параметров в наборе Google Search URL, и большинство гайдов затрагивают его лишь поверхностно. Он отвечает за фильтрацию по времени, сортировку по дате, verbatim-режим и многое другое — всё это упаковано в одно значение через запятую.

Стандартные фильтры по времени

Значение tbs	Значение	Пример фрагмента URL
qdr:h	Последний час	&tbs=qdr:h
qdr:d	Последние 24 часа	&tbs=qdr:d
qdr:w	Последняя неделя	&tbs=qdr:w
qdr:m	Последний месяц	&tbs=qdr:m
qdr:y	Последний год	&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 связывает с датами между 1 января и 1 июня 2026 года. Очень полезно для конкурентного анализа — например, «что конкуренты публиковали о ценах в 1 квартале 2026 года?» Только не забудьте закодировать всё значение URL-encoding’ом, потому что двоеточия и слэши нужно экранировать.

Практическая ремарка: привязка даты у Google не всегда точна. Дата, которую вы видите в выдаче, — это лучший прогноз Google, а не обязательно реальная дата публикации. Всегда проверяйте дату на самой странице.

Сортировка по дате и verbatim-режим

Здесь руководство затрагивает то, чего нет у большинства конкурирующих статей.

sbd:1 сортирует результаты по дате — сначала самые новые. Сам по себе этот параметр полезен, но не особенно необычен. Хитрость в том, что его можно совмещать с фильтрами по периоду в одном значении tbs:

&tbs=qdr:m,sbd:1

Так вы получаете результаты за последний месяц, отсортированные по дате — от новых к старым. Это самый быстрый способ найти только что опубликованные материалы по теме. Я постоянно использую эту комбинацию для мониторинга контента конкурентов.

li:1 включает verbatim-режим — по сути URL-аналог нажатия на инструмент Google "Verbatim" в интерфейсе поиска. 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, uule и cr

Параметр	Точность	Типичный сценарий	Нужна ли кодировка?
gl=us	Уровень страны	Быстрая имитация страны	Нет
cr=countryUS	Уровень страны (ограничение)	Фильтрация по стране хостинга	Нет
uule=w+CAIQICI...	Уровень города/DMA	Проверка локальных позиций в SEO	Да

Алгоритм кодирования uule (пошагово)

Параметр uule использует закодированный сигнал с именем локации. Способ его построения восстановлен по наблюдениям, а не официально задокументирован Google, но он широко подтверждён SEO-сообществом.

Более надёжный подход — кодировать небольшой payload Protocol Buffers, а не полагаться на часто копируемый короткий вариант (он может ломаться на не-ASCII символах). Вот процесс:

1. Получите каноническое название локации в Google. Google публикует географические цели с каноническими именами через данные геотаргетинга Google Ads API. Пример: New York,New York,United States
2. Закодируйте название в байты UTF-8.
3. Соберите небольшой protobuf payload с именем и его длиной в байтах.
4. Закодируйте payload в 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+ корректно кодируется как %2B вашей URL-библиотекой. Большинство реализаций URLSearchParams или urllib.parse.urlencode делают это автоматически.

Правильно собранный uule — это всё равно лишь один сигнал о локации. Он не отменяет IP-адрес, настройки аккаунта, устройство или экспериментальную группу. Используйте его для ориентировочной проверки локального SEO, но не как гарантию точных городских позиций.

Когда параметры Google Search URL тихо конфликтуют друг с другом

Комбинации параметров могут ломаться без ошибок: Google может проигнорировать один из входов, переписать URL или показать другую выдачу. Проверки конфликтов ниже стоит добавить в любой рабочий процесс, где формируются поисковые ссылки.

Ни одна из конкурирующих статей не рассматривает взаимодействие параметров. Но если вы строите поисковые URL с несколькими параметрами — а вы, скорее всего, именно так и делаете, — нужно понимать, какие сочетания дружат, а какие мешают друг другу.

gl + uule: что имеет приоритет?

Когда присутствуют оба параметра, uule даёт более точный сигнал о локации, чем gl. Если задать gl=uk и uule, указывающий на Токио, вы получите результаты с влиянием Токио, а не Великобритании.

Рекомендация: если используете uule, либо вообще не указывайте gl, либо ставьте gl той страны, к которой относится город из uule. Не отправляйте противоречивые сигналы.

tbm + udm: не используйте оба сразу

В моих тестах, когда в одном URL одновременно были tbm и udm, Google иногда удалял оба параметра и возвращал обычную веб-выдачу. Поведение непоследовательно и зависит от сессии и аккаунта.

Рекомендация: для новых реализаций используйте только udm. Если нужно поддерживать старые сценарии, выбирайте один из двух — никогда не оба одновременно.

lr + cr: двойная фильтрация может дать ноль результатов

Это тонкая ловушка. lr=lang_en ограничивает выдачу англоязычным контентом. cr=countryJP ограничивает страницы, размещённые в Японии. Если объединить их, вы фактически ищете «англоязычные страницы, размещённые в Японии» — а это очень маленький кусок веба.

Рекомендация: используйте только один из параметров, если вам не нужна именно их пересекающаяся выборка. Если всё же комбинируете, будьте готовы к значительно меньшему числу результатов.

num + start: сломанная пагинация

Старые скрипты, использующие num=100&start=0, теперь тихо возвращают только около 10 результатов. Параметр num больше не учитывается, но ошибки он не вызывает — просто игнорируется.

Рекомендация: удалите num из всех URL. Делайте пагинацию через 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 Search URL к структурированному извлечению данных

Теперь у вас есть точный URL поиска Google — правильный запрос, правильная страна, правильный диапазон дат, классическая веб-выдача. Следующий шаг — получить структурированные данные из результатов.

Если вы строите трекер позиций, мониторите конкурентов или передаёте поисковые данные в исследовательский workflow, увидеть правильные результаты — это только половина дела. Вам нужны заголовки, URL, сниппеты, позиции и даты в таблице или базе данных.

Создание целевого URL Google Search (собираем всё вместе)

Полный пример с несколькими параметрами:

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)

Анонимные HTTP-запросы к Google часто возвращают JavaScript-оболочку без серверной выдачи или предупреждение о необычном трафике — и именно здесь у браузерного извлечения есть преимущество.

Извлечение данных SERP без написания парсера

Парсинг HTML Google — дело хрупкое. DOM часто меняется, имена классов замаскированы, а то, что вы видите в браузере, не всегда совпадает с тем, что приходит в сыром HTTP-ответе.

Более простой путь для неразработчиков: откройте в Chrome тщательно собранный поисковый URL, а затем используйте браузерный инструмент извлечения, чтобы получить структурированные данные с видимой страницы. В Thunderbit мы создали наше расширение для Chrome именно для таких сценариев — можно использовать AI Suggest Fields, чтобы определить колонки вроде заголовка результата, целевого URL, текста сниппета и видимой позиции, а затем извлечь их в таблицу без написания парсера.

Это не единственный путь. Подход на коде тоже работает, особенно если нужна массовая или повторяющаяся выгрузка. Но для разовых исследований, аудитов и конкурентного анализа браузерное извлечение полностью избавляет от хрупкости HTML-парсинга.

Когда лучше использовать официальный API

Напоминание о ответственном использовании — и это важно.

Условия использования Google запрещают автоматизированный доступ, который обходит защитные меры, а справка Google Search прямо относит поисковые скраперы и софт, отправляющий автоматические запросы для определения позиций, к автоматизированному трафику. Запуск Google-скрапера в промышленном масштабе повышает риск блокировок IP, CAPTCHA и потенциальных юридических проблем.

Для производственных задач и больших объёмов поисковых данных лучше использовать официальный API. Google Custom Search JSON API закрывается для новых клиентов — существующие пользователи должны перейти до 1 января 2027 года, при этом доступно 100 бесплатных запросов в день и по $5 за 1 000 запросов после этого. В дальнейшем Google рекомендует Vertex AI Search для поиска по контролируемым сайтам.

Для собственных сайтов Search Console Search Analytics API — это первоисточник по кликам, показам, CTR и средней позиции, без необходимости скрапинга.

Считайте знание URL-параметров диагностическим и исследовательским инструментом: отлично подходит для создания точных поисковых ссылок, ручных аудитов и понимания того, что показывает Google. Но это не замена официальным API в масштабе.

Операторы Google Search: параметры внутри вашего запроса

Операторы поиска живут внутри параметра 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 года, отсортированные по дате, для рынка США, с классической веб-выдачей. Получается очень точный запрос для конкурентной разведки, собранный только из параметров URL и операторов.

Google говорит, что результаты site: не гарантируют полноту — не воспринимайте site:-запрос как полный инвентарь всех проиндексированных страниц.

Ответственное использование: условия Google и лимиты запросов

Короткий, но важный контекст.

Условия использования Google запрещают злоупотребление доступом и обход защитных механизмов. Google Search Help отдельно упоминает поисковые скраперы и автоматизированный софт для определения позиций как примеры автоматизированного трафика. Нарушение этих правил может привести к блокировкам IP, CAPTCHA, ограничениям аккаунта и потенциальным юридическим последствиям.

Знание URL-параметров лучше всего использовать для: ручного создания точных поисковых URL, построения удобных ссылок для команды, небольших аудитов в браузере и понимания того, как работает интерфейс поиска Google. Для автоматизированной работы в масштабе используйте официальные API Google — либо лицензированного стороннего поставщика данных о поиске, например Brave Search API.

В Thunderbit наше расширение для браузера создано для инициируемого пользователем извлечения данных с видимой страницы, а не для массовых автоматических запросов к Google. Это важное различие.

Ключевые выводы: ваш набор инструментов по параметрам Google Search URL на 2026 год

Краткая версия:

• Используйте gl + hl для сигналов локализации и не полагайтесь только на ccTLD во время миграции редиректов Google
• Тестируйте и udm, и tbm, где это актуально — ни один из них не является стабильным версионированным consumer API
• udm=14 может запрашивать классическую веб-выдачу без AI Overviews, но Google может удалить или переписать этот параметр
• Используйте uule для геотаргетинга на уровне города с формулой protobuf-кодирования, описанной выше
• Освойте tbs для точной фильтрации по датам (cdr:1,cd_min:...,cd_max:...), сортировки по дате (sbd:1) и verbatim-поиска (li:1)
• Остерегайтесь конфликтов параметров: gl vs. uule, tbm vs. udm, lr vs. cr
• num=100 ненадёжен и никогда официально не поддерживался — безопаснее использовать start с шагом 10
• Для структурированных данных SERP используйте браузерные инструменты вроде Thunderbit для разовых задач, а для промышленного масштаба — официальные API
• Соблюдайте условия Google — параметры URL это инструмент исследования, а не лицензия на скрапинг

Google продолжает менять параметры без объявлений. Я буду поддерживать этот справочник актуальным по мере изменений — добавьте страницу в закладки и проверяйте обновления.

Узнать больше

• 9 лучших SEO API в 2026 году (с реальными данными о стоимости одного запроса)
• Как освоить скрапинг поисковых систем: полное руководство
• 27 лучших инструментов для анализа и мониторинга позиций сайта
• Как использовать пагинацию Web Scraper для эффективного извлечения данных
• Что такое search automation? Преимущества, инструменты и стратегии

FAQ

Что делает udm=14 в URL поиска Google?

udm=14 может запросить классическую веб-выдачу без AI Overviews, поэтому этот параметр популярен среди SEO-специалистов. Он восстановлен по наблюдениям, а не официально задокументирован Google, и Google может удалить или переписать его в зависимости от сессии, аккаунта, региона, клиента и экспериментальной группы.

Работает ли параметр num в 2026 году?

Не полагайтесь на него. Google перестал стабильно учитывать num=100 в сентябре 2025 года, а представитель компании заявил, что этот параметр никогда официально не поддерживался. Используйте start с шагом 10 как более безопасный вариант пагинации и проверяйте фактическое число результатов, потому что Google всё ещё может переписать или ограничить ответ.

Как имитировать поиск Google из конкретного города?

Используйте параметр uule с закодированным названием города. В разделе выше про кодирование приведён алгоритм на основе protobuf и пример на Python. Вам понадобится каноническое название локации из Google (доступно в данных геотаргетинга Google Ads), которое вы кодируете в значение uule вроде uule=w+CAIQICIeNew+York,New+York,United+States.

В чём разница между gl, lr и cr?

Эти три параметра управляют разными аспектами гео- и языкового таргетинга. gl имитирует ваше местоположение на уровне страны (влияет на ранжирование и локальные результаты). lr ограничивает выдачу страницами, написанными на определённом языке контента. cr ограничивает выдачу страницами, размещёнными в определённой стране. Их можно комбинировать, но противоречивые сочетания (например, lr=lang_en + cr=countryJP) резко сузят результаты.

Можно ли объединять несколько значений tbs в одном URL?

Да — разделяйте их запятыми внутри одного параметра tbs. Например, tbs=qdr:m,sbd:1 фильтрует результаты за последний месяц и сортирует их по дате (сначала новые). Можно также добавить li:1 для verbatim-режима: tbs=qdr:m,sbd:1,li:1. Синтаксис tbs не документирован, поэтому тестируйте конкретные комбинации, чтобы убедиться, что они работают как ожидается.