11 подписчиков
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. Также потенциально уменьшается…
2 минуты
Вчера