Нормализация URL

Одна и та же страница может быть записана разными строками: верхний регистр домена, порт 443 у HTTPS, сегменты /a/../b, фрагмент #section. Стандартный разбор URL приводит такие части к предсказуемому виду. Инструмент обрабатывает список и помечает совпавшие строки после нормализации. Это удобно перед импортом карты редиректов, сравнением выгрузок или поиском явных дублей в таблице адресов. Он не делает сетевых запросов и не проверяет, действительно ли сервер считает два URL одной страницей.

Не всякая косметическая разница безопасна для автоматического удаления. Сервер может различать /catalog и /catalog/, а регистр пути часто значим. Параметры query могут менять товарную выдачу, а порядок параметров — обработку приложения или подпись ссылки. Поэтому нормализатор не сортирует query и не убирает завершающий слеш. Фрагмент после # удаляется, поскольку не отправляется серверу в обычном HTTP-запросе, но для одностраничных приложений он может быть частью навигационного состояния. Сверяйте результат с устройством конкретного сайта.

Вставьте URL по одному в строке. Инструмент применит стандартное разрешение адреса и покажет совпадения после нормализации.

Начните с кнопки «Вставить пример», чтобы увидеть ожидаемый формат ввода. Затем замените демонстрационные значения своими данными в полях «Исходные данные». Нажмите «Получить результат». Если формат неверный, инструмент покажет ошибку на русском языке; исправьте исходные данные и повторите действие.

Готовый результат можно скопировать одной кнопкой или скачать в файл normalized-urls.txt. Проверьте итог перед публикацией на рабочем сайте: инструмент видит только переданные ему данные и не знает особенностей вашего проекта. Для больших выгрузок удобно сначала обработать небольшой фрагмент и убедиться, что структура результата подходит дальнейшему процессу.

HTTPS://EXAMPLE.COM:443/a/../b#top становится https://example.com/b.

HTTPS://EXAMPLE.COM:443/a/../b#top
https://example.com/b

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

Путь, query и завершающий слеш могут быть значимы для сервера. Инструмент не удаляет их без команды.

Технически корректный результат ещё не означает, что он подходит бизнес-логике сайта. Например, URL может быть синтаксически верным, но вести на удалённую страницу; XML может быть хорошо сформированным, но не соответствовать настройкам конкретной площадки. После автоматической проверки откройте итог в целевой системе или браузере и сравните его с ожидаемым поведением.

Если инструмент сообщает об ошибке, начните с названного поля или строки. При обработке файлов проверьте кодировку, переносы строк, кавычки и спецсимволы. Они часто попадают в данные при экспорте из Excel, CMS или интеграции и могут менять смысл результата.

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

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

При подготовке списка для миграции импортируйте URL из нескольких источников: старого sitemap, аналитики, логов и внешних ссылок. Нормализация покажет точные совпадения после стандартного разбора, но отдельной проверкой стоит найти семантические дубли вроде /catalog и /catalog/. Для каждого спорного случая откройте адреса и сравните конечный ответ и canonical. Не удаляйте строку из карты лишь потому, что браузер показывает похожий путь: редирект может быть нужен для старой ссылки с конкретным регистром или параметрами.

Если в исходной выгрузке попались некорректные адреса, исправляйте их на стороне источника. Массовая ручная подмена может скрыть системную ошибку экспорта и повториться в следующем файле. Для международных доменов учитывайте Punycode: URL API может вывести ASCII-представление домена, хотя в интерфейсе он написан кириллицей. Это ожидаемая форма для технического сравнения. После нормализации используйте результат как вход для проверки карты редиректов, а затем отдельно проверяйте опубликованные правила по HTTP.

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

Поля этого инструмента обрабатываются в вашем браузере. Содержимое не отправляется на сервер Pugofka, а локальный файл читается только после вашего выбора. Для XML определяется кодировка из объявления или BOM; при отсутствии подсказки сначала пробуется UTF-8, затем Windows-1251. Виджет скрыт от записи содержимого в Вебвизоре; в Яндекс Метрику передаются slug инструмента и тип действия — открытие, первое взаимодействие, запуск, получение результата, копирование или скачивание.

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

Используйте результат как рабочий черновик: вставьте его в конфигурацию, страницу или документ и повторно проверьте там, где он будет применяться. Если вы меняете индексируемые страницы, обновите связанные ссылки и карту сайта. Для миграции URL дополнительно запустите сетевую проверку редиректов, чтобы увидеть фактические HTTP-ответы после публикации.

Если задача связана с каталогом, импортом или поддержкой интернет-магазина, команда Pugofka может помочь встроить такую проверку в регулярный обмен данными и исправить источник ошибок. Одноразовая онлайн-утилита полезна для диагностики, а постоянный поток данных обычно требует автоматической проверки на стороне проекта.