HTTP QUERY и Googlebot: почему SEO пока не нужно менять URL-фильтры

Google в перспективе может добавить поддержку HTTP-метода QUERY в своего поискового робота. Об этом сообщил специалист Google Гэри Ийеш, уточнив важное условие: сначала стандарт должен получить заметное распространение в веб-инфраструктуре.

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

Практический вывод на сегодня простой: срочно ничего переделывать не нужно. Но полезно понять, какую проблему пытается решить QUERY и почему она не сводится к «новому методу для SEO».

Чем QUERY отличается от GET и POST

GET традиционно используют для получения данных. Параметры запроса обычно передаются в URL: например, категория, бренд, диапазон цены, размер, сортировка и номер страницы. Такой подход понятен браузерам, CDN, серверам, аналитическим системам и поисковым роботам.

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

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

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

Идея выглядит логичной: вынести сложные параметры из URL в структурированное тело запроса, не превращая операцию в POST. Однако сам по себе HTTP-метод не делает страницу автоматически доступной для поиска и не решает архитектурные ошибки каталога.

Где это потенциально полезно для SEO

Самый понятный сценарий — интернет-магазин или маркетплейс с фасетной навигацией. Пользователь выбирает несколько характеристик: бренд, материал, цвет, наличие, цену, рейтинг, способ доставки. Для серверной инфраструктуры такой набор удобнее представить структурированными данными, чем длинной цепочкой query-параметров.

В теории QUERY мог бы сделать работу со сложными состояниями фильтра более аккуратной. Серверу и CDN проще отличать нормализованные запросы, а поисковому роботу — получать результат фильтрации без сверхдлинного URL. Также потенциально уменьшается соблазн использовать POST там, где команда фактически строит страницы поиска.

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

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

• огромное число слабых или почти одинаковых страниц;
• расход crawl budget на неважные комбинации;
• дублирование листингов и метаданных;
• размывание внутренних ссылочных сигналов;
• нестабильные URL и непредсказуемая каноникализация.

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

Почему внедрение не случится быстро

Google прямо связывает возможную поддержку с распространением стандарта. Для реального использования недостаточно, чтобы метод понимал один поисковый робот или отдельный сайт.

Поддержка потребуется по всей цепочке: веб-серверам, фреймворкам, CDN, балансировщикам, прокси, WAF-решениям, инструментам мониторинга и браузерам. Каждый промежуточный слой должен корректно принимать, передавать, кэшировать и не блокировать новый тип запроса.

Отдельный вопрос — браузерная платформа. Понадобятся согласованные подходы к HTML-формам, JavaScript API, CORS и поведению кэшей. Иначе у команды может получиться технически корректный endpoint, который нельзя надёжно использовать в обычном пользовательском сценарии или который по-разному обрабатывается на разных уровнях инфраструктуры.

Есть и операционная сторона. Многие корпоративные правила безопасности строятся вокруг привычного набора методов GET, POST, PUT, PATCH и DELETE. Новый метод нужно будет добавить в allowlist, логи, правила защиты, тестовые сценарии и документацию. Именно такие детали обычно делают путь от стандарта до массовой практики длиннее, чем кажется по одному анонсу.

Что делать владельцам сайтов сейчас

Рекомендация Google не меняется: использовать обычные URL и следить за их структурой. Для SEO это по-прежнему наиболее прозрачная и совместимая модель.

Командам с большими каталогами я бы советовал сосредоточиться на пяти практических задачах:

1. Нормализовать параметры фильтрации: закрепить единый порядок, формат значений и правила удаления пустых параметров.
2. Разделить пользовательские фильтры и SEO-посадочные страницы. Не каждая комбинация, полезная покупателю, должна индексироваться.
3. Настроить понятные canonical, robots-правила и внутреннюю перелинковку для приоритетных листингов.
4. Проверить, как фильтры видны в логах сервера и в отчётах по обходу. Без этого легко спорить о crawl budget абстрактно.
5. Не переносить навигацию на POST только ради сокращения URL, если требуется стабильная, доступная и анализируемая страница результата.

Если в продукте уже есть сложный внутренний поиск, полезно отдельно оценивать пользовательскую и поисковую архитектуру. Иногда API может использовать один удобный формат запросов, а SEO-слой — публиковать ограниченный набор чистых HTML-страниц с постоянными URL. Это не компромисс «из прошлого», а часто наиболее надёжная конструкция.

Практический вывод

Поддержка QUERY со стороны Googlebot — интересный сигнал о развитии веб-стандартов, а не повод срочно переписывать фасетную навигацию. Потенциально метод может улучшить работу со сложными запросами и фильтрами, если его поддержит вся экосистема.

До этого момента SEO-командам стоит делать то, что работает уже сейчас: проектировать короткие и устойчивые URL, ограничивать индексирование неценных комбинаций, сохранять доступность значимых страниц в HTML и контролировать обход по данным.

Технология передачи параметров важна. Но для видимости сайта важнее управляемая информационная архитектура — и новый HTTP-метод этого правила не отменит.