Адреса ?brand=a&size=42 и ?size=42&brand=a могут показывать один результат, но CMS оставляет оба во внутренних ссылках. Начните с доказательства равенства состояния каталога. Алфавитная сортировка параметров без понимания приложения способна изменить повторяющиеся ключи или подписанные ссылки.
Докажите эквивалентность перестановок параметров
Нормализуйте только параметры, порядок которых действительно не влияет на смысл. Учитывайте повторяющиеся ключи, пустые значения, регистр и кодирование. UTM, пагинация и фильтры имеют разные роли; общий запрет на query string проблему не решает.
Google рекомендует согласовывать указанный canonical с другими сигналами, включая внутренние ссылки. Официальная документация.
URL с двумя переставленными параметрами ещё не является доказанным дублем. В некоторых приложениях первый или последний повтор ключа определяет результат. Начните с двух простых адресов и сопоставьте состояние интерфейса, товары, порядок выдачи и количество результатов. Затем повторите с одинаковой авторизацией и языком. Если ответы различаются, выясните, должно ли это различие существовать. Техническая нормализация полезна после понимания семантики, а не вместо него. Самостоятельный фильтр также может сохранять свой URL, даже если его параметры допускают перестановку.
Отделите ключи фильтра, страницы и аналитики
Учебные сценарии в таблице задают ожидаемое поведение; фактические ответы своего сайта заносите отдельно.
| Сценарий | Отличие | Решение | Проверка |
|---|---|---|---|
| ?brand=a&size=42 | Два фильтра | Сравнить с перестановкой | Одинаковое состояние |
| ?size=42&brand=a | Те же два фильтра | Выбрать единый порядок | Согласованный canonical |
| ?tag=a&tag=b | Повторяющийся ключ | Проверить семантику | Не сортировать вслепую |
| ?page=2&brand=a | Другая часть каталога | Сохранить номер | Не смешивать с первой |
Укажите для каждого ключа владельца: brand и size обрабатывает каталог, page выбирает часть списка, utm_source нужен учёту переходов. Добавьте, влияет ли ключ на содержимое, порядок или только измерение. Это позволяет описать нормализацию без широкого правила «убрать всё после вопроса». Параметр языка или валюты требует отдельной проверки, если реально меняет страницу. Для устаревших ключей запишите ожидаемое игнорирование или преобразование. После изменения пользователь должен видеть ту же принятую комбинацию, а команда — понимать, почему часть параметров сохранилась.
Сравните ответ сервера с нормализацией в браузере
Сохраните пары URL и сравните выбранные фильтры, набор товаров, пагинацию и ответ сервера. Повторите после обновления страницы: клиентская нормализация адресной строки может скрывать расхождение серверных ответов.
Проверяйте исходный GET до выполнения приложения. История браузера может заменить адрес после загрузки через history.replaceState, но сервер по исходному адресу продолжит отдавать другую версию. Запишите исходный URL, конечный URL, HTTP-статус и canonical до и после запуска JavaScript. Если настройка находится на CDN, сравните запросы через публичный маршрут и допустимый внутренний диагностический путь. Не обходите защиту случайным параметром: он может изменить ключ кеша и показать ответ, который обычный посетитель никогда не получает.
Проверьте повторяющиеся ключи и кодирование
Учебная пара содержит brand и size в двух порядках. Третий контрольный адрес добавляет page=2. Если первые два эквивалентны, а третий показывает другие товары, нормализация должна объединить только первую пару.
Испытайте tag=a&tag=b, пустое size=, значение с пробелом и кириллический бренд. URLSearchParams удобен для разбора, но не принимает за вас решение о том, можно ли переставлять повторяющиеся значения. Подписанные ссылки особенно чувствительны к преобразованию: их валидатор может проверять точное представление строки. В тестовой таблице храните исходную строку и результат, затем сравнивайте смысл, а не только красоту адреса. Проверка кодирования должна показать, что выбранное пользователем значение не меняется и не становится двумя отдельными параметрами.
Согласуйте генераторы URL вместо массовой сортировки
Выберите единый генератор URL для меню, фильтров и canonical. Перенаправление применяйте только к доказанно эквивалентным адресам; для служебных подписанных запросов сохраняйте требования их протокола.
Один helper формирования ссылок проще контролировать, чем три независимо написанных правила в меню, фильтре и sitemap. Задайте порядок известных ключей, обработку пустых значений и сохранение значимых исключений. Вывод canonical должен использовать согласованный результат. Редирект необязательно применять ко всем вариантам: выберите его там, где сервер действительно должен менять адрес и эквивалентность доказана. Затем проверьте, что меню и фильтр больше не создают ненормализованные варианты. Исправление только canonical оставляет старый источник размножения URL в интерфейсе.
Приёмка без потери выбранного состояния
Слепая сортировка нескольких одинаковых ключей способна переставить значения. Декодирование и повторное кодирование также нужно проверять на пробелах, кириллице и специальных символах.
Для приёмки возьмите две эквивалентные перестановки и один намеренно отличающийся адрес с page=2. Первые должны указывать на принятую основную форму, третий сохраняет собственный набор товаров и страницу. Дополнительно проверьте сохранённые пользователем ссылки и переход из письма с UTM. Исчезновение технического дубля не должно сбрасывать вариант товара или мешать работе аналитики. В отчёте разделите подтверждённое равенство ответов и дальнейшую обработку адресов поисковиком. Последнюю нельзя вывести из одного свежего запроса сервера.
Проверьте границы правил на необычных значениях
Добавьте неизвестный ключ и значение, содержащее знак равенства. При разборе вручную через split легко потерять часть значения; используйте стандартный URL-парсер и проверяйте результат. Для каждой политики определите, как система реагирует на неизвестные параметры: игнорирует, сохраняет или отвергает. Это продуктовый выбор, который не следует выводить из алфавитного порядка. Проверьте также URL с fragment: фрагмент обрабатывается клиентом и не передаётся серверу в HTTP-запросе как query string. Если приложение использует его для состояния, серверный редирект и canonical должны согласовываться с фактической архитектурой. Разные механизмы адреса нельзя склеивать одним регулярным выражением, даже если итоговая строка выглядит аккуратнее.
Критерии завершения проверки
Эквивалентные пары приводят к согласованному основному адресу. Значимый page=2 сохраняется, выбранные фильтры не сбрасываются, новые внутренние ссылки больше не порождают обе перестановки.
- ?brand=a&size=42: Одинаковое состояние. Зафиксируйте фактический результат и адрес проверенного сценария.
- ?size=42&brand=a: Согласованный canonical. Зафиксируйте фактический результат и адрес проверенного сценария.
- ?tag=a&tag=b: Не сортировать вслепую. Зафиксируйте фактический результат и адрес проверенного сценария.
- ?page=2&brand=a: Не смешивать с первой. Зафиксируйте фактический результат и адрес проверенного сценария.
Для смежных вопросов: Параметры URL и SEO: фильтры, UTM-метки и дубли — как не убить индексацию и Дублированный контент: как найти и исправить через canonical. Отдельные проверки сайта собраны на странице технического аудита reChecker.