> For the complete documentation index, see [llms.txt](https://speedyindex-1.gitbook.io/speedyindex-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://speedyindex-1.gitbook.io/speedyindex-docs/ru/ochistka-spiska-url-pered-proverkoi-indeksacii-utm-metki-dubli-i-musor.md). # Очистка списка URL перед проверкой индексации: UTM-метки, дубли и мусор Как очистить список URL от UTM-меток, дублей и мусора перед проверкой индексации: порядок шагов, правила нормализации и типичные ошибки. Список адресов для проверки индексации почти никогда не бывает чистым. Его собирают из выгрузок Search Console, отчётов по ссылкам, таблиц подрядчиков, аналитики и CMS. В итоге в нём оказываются одни и те же страницы с разными метками, адреса с `http` и `https`, с `www` и без, лишние пробелы и даже обрывки текста. Если отправить такой список на проверку как есть, отчёт покажет «не в индексе» там, где в индексе просто другая версия адреса, а лимит проверок уйдёт на дубли. Ниже — порядок очистки, который подходит и для собственного сайта, и для списка бэклинков. ## Почему «грязный» список искажает результат Поисковая система хранит в индексе одну каноническую версию страницы. Если в списке стоит `https://example.com/catalog/?utm_source=telegram`, а в индексе находится `https://example.com/catalog/`, проверка конкретного адреса с меткой честно ответит «нет». Ошибки нет, просто вы спросили не про тот адрес. Google в документации о канонических адресах приводит именно такой пример: адрес с параметром отслеживания (`gclid`) — дубль основной страницы, и сигналы с него могут объединяться с предпочтительной версией. Отсюда правило: проверять нужно ту версию, которую вы хотите видеть в поиске. ## Шаг 1. Отделите адреса от текста Выгрузки из таблиц и писем часто содержат лишнее: анкоры, комментарии, кавычки, запятые в конце строки. Оставьте в каждой строке только адрес, который начинается с `http://` или `https://`. Строки без протокола (`example.com/page`) допишите или отложите для ручной проверки. ## Шаг 2. Уберите UTM-метки и другие параметры отслеживания Метки `utm_source`, `utm_medium`, `utm_campaign`, `utm_content`, `utm_term`, а также `gclid`, `yclid`, `fbclid` и подобные не меняют содержимое страницы. Удалите их, сохранив значимые параметры: номер страницы пагинации, фильтр, если он открывает отдельную индексируемую страницу, идентификатор товара в старых CMS. Если сомневаетесь, значим ли параметр, откройте обе версии адреса и сравните содержимое и тег `rel="canonical"`. ## Шаг 3. Приведите адреса к одному виду Договоритесь о правилах нормализации и примените их ко всему списку: * **Протокол:** если сайт работает по HTTPS, заменяйте `http://` на `https://`. * **Хост:** выберите `www` или вариант без него — тот, на который настроен редирект. * **Регистр:** домен всегда в нижнем регистре; путь не трогайте, если сервер различает регистр. * **Слеш в конце:** приведите к варианту, который отдаёт `200`, а не редирект. * **Якоря:** часть после `#` на сервер не передаётся, её можно удалить. ## Шаг 4. Удалите дубли Только после нормализации дубли становятся видны. До неё `https://Example.com/page/?utm_source=x` и `https://example.com/page/` выглядят разными строками. Удалите повторы и посчитайте, сколько строк исчезло: если ушла заметная часть списка, в исходной выгрузке была системная проблема, например одна и та же ссылка, размеченная для разных каналов. Для списков на тысячи строк удобнее не писать формулы, а воспользоваться браузерным инструментом, который умеет [убрать дубли из списка ссылок](https://indexfixtools.com/ru/url-list-cleaner/) вместе с метками за один проход. ## Шаг 5. Отложите то, что проверять не нужно Перед отправкой на проверку уберите адреса, которые заведомо не должны быть в индексе: * страницы с `noindex`; * адреса, отдающие `301`, `404` или `410`; * служебные разделы: корзина, личный кабинет, внутренний поиск. Их удобнее проверить отдельно — по кодам ответа, а не по индексу. ## Шаг 6. Проверяйте чистый список Теперь список отражает именно те страницы, которые вы хотите видеть в поиске. Его можно разбить на группы: по разделам сайта, по шаблонам страниц или, для бэклинков, по доменам-донорам. Такой список удобно [проверить на наличие адресов в индексе Google](https://speedyindex.com/proverka-indeksatsii-sayta-google/) целиком и сравнить результат между группами. ## Типичные ошибки * **Удалить все параметры подряд.** Так пропадают страницы пагинации и фильтров, которые действительно индексируются. * **Нормализовать протокол и хост наугад.** Сначала проверьте, куда на самом деле ведут редиректы сайта. * **Проверять адреса с метками и делать вывод «страница не в индексе».** Проверьте каноническую версию. * **Чистить список вручную в таблице.** На больших объёмах ошибки почти неизбежны. ## Краткий чек-лист * [ ] В каждой строке только адрес с протоколом * [ ] Удалены UTM-метки и параметры отслеживания * [ ] Единый протокол, хост и вариант слеша * [ ] Дубли удалены после нормализации * [ ] Отложены адреса с `noindex`, редиректами и ошибками * [ ] Список разбит на группы для анализа ## Источники * Google Search Central: [How to specify a canonical URL with rel="canonical" and other methods](https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://speedyindex-1.gitbook.io/speedyindex-docs/ru/ochistka-spiska-url-pered-proverkoi-indeksacii-utm-metki-dubli-i-musor.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.