SKU / внешний ID
Совпадает ли ключ, по которому импорт должен узнавать существующий товар.
Отраслевая практика · интернет-магазины
После импорта появились дубли товаров: где искать причину и как исправить
После загрузки каталога «дубль товара» может означать три разные вещи: в CMS созданы две записи одного товара, одна карточка открывается по нескольким URL или вариации ошибочно превратились в отдельные почти одинаковые страницы. Сначала определяем тип дубля, затем исправляем импорт и только после этого чистим последствия в поиске.
Быстрый маршрут
Что проверить за первые 5 минут
Не начинайте с массового удаления. Возьмите 3–5 пар дублей и сравните их на уровне данных, URL и истории импорта.
Дата создания
Появилась ли вторая запись именно во время последней загрузки каталога.
URL и canonical
Это две записи CMS или одна карточка, доступная по двум адресам.
Вариации
Не превратились ли размеры, цвета или комплектации в отдельные товары.
Лог импорта
Обновлял ли импорт существующие записи или создавал новые.
Главный вопрос: что импорт считает идентификатором товара.Если ключ сопоставления изменился, потерялся или нормализуется иначе, система перестаёт узнавать старую карточку и создаёт новую.
Сначала классификация
«Дубли товаров» бывают трёх разных типов
Внешне они похожи, но техническое решение у каждого своё. Поэтому важно не смешивать данные каталога и поисковые URL.
Две записи одного товара
В CMS существуют два разных ID товара с одинаковым SKU, названием, фото или внешним идентификатором. Это прежде всего ошибка импорта или модели данных.
Одна запись по нескольким URL
Товар в базе один, но открывается через разные категории, параметры, регистр, слеши или технические маршруты. Это URL-дублирование.
Вариации стали отдельными карточками
Цвет, размер или комплектация импортируются как самостоятельные товары, хотя шаблон и поисковая задача у них почти одинаковы.
Старая и новая версия товара
Импорт создал новую карточку, а прежняя осталась опубликованной. Часто это происходит после смены артикула, внешнего ID или структуры выгрузки.
Шаг 1
Проверьте ключ, по которому импорт обновляет существующий товар
Надёжный импорт должен понимать, какая строка входного файла соответствует уже существующей записи. В зависимости от системы это может быть внутренний ID, внешний ID из ERP, SKU/артикул или специально настроенный уникальный ключ.
Типичная причина дублей — ключ изменился между выгрузками. Например, ERP начала передавать новый внешний идентификатор, у артикула исчезли ведущие нули, в одном файле используется строка AB-001, а в другом AB001, либо прежнее поле перестало загружаться. Для импортера это уже другой объект.
| Что сравнить | Старая карточка | Новая карточка | Что означает расхождение |
|---|---|---|---|
| Внешний ID | Старое значение | Новое / пустое | Импорт мог потерять связь с прежней записью |
| SKU / артикул | 001245 | 1245 | Нормализация изменила уникальный ключ |
| Внутренний ID CMS | Существовал до импорта | Создан во время импорта | Вместо update выполнен create |
| Дата изменения | Старая | Совпадает с импортом | Хороший маркер момента появления дубля |
Сопоставление по названию обычно ненадёжно: название меняется, локализуется, дополняется характеристикой и может повторяться у разных товаров. Исправлять нужно правило идентификации, а не только уже созданные дубли.
Шаг 2
Отделите дубли записей от нескольких URL одной карточки
Если в админке товар один, а краулер находит несколько адресов с одинаковым содержимым, проблема находится не в импорте записей, а в маршрутизации. Частые источники: путь через разные категории, GET-параметры, сортировки, метки, альтернативный регистр, технический endpoint или несколько вариантов слеша.
Яндекс указывает, что страницы с одинаковым или схожим содержимым могут быть объединены в группу дублей, а rel="canonical" является рекомендацией о предпочитаемой версии. Для незначимых GET-параметров в Вебмастере также есть отдельная настройка индексирования. Справка Яндекса по canonical и настройка GET-параметров полезны для сверки технического решения.
Но canonical не должен маскировать две реальные записи товара. Если в CMS действительно два объекта, сначала устраняем источник создания дублей и определяем, какая карточка остаётся основной.
Шаг 3
Проверьте, не изменил ли импорт модель вариаций
Размеры, цвета и комплектации могут храниться как варианты одной карточки или как отдельные товары. Универсального правила нет: решение зависит от ассортимента, интерфейса, наличия самостоятельного спроса и того, насколько сильно различаются данные вариантов.
Проблема начинается, когда модель меняется случайно. Вчера цвет был атрибутом одной карточки, сегодня каждая строка выгрузки создаёт отдельный URL с тем же описанием и фотографиями. Каталог резко растёт, а поисковая ценность новых страниц почти не меняется.
Если отдельная вариация не имеет самостоятельной задачи для пользователя, не отличается содержанием и существует только потому, что так устроен файл импорта, это слабая причина создавать под неё отдельный индексируемый URL.
Шаг 4
Найдите старые карточки, которые импорт перестал обновлять
При смене идентификаторов старые записи часто не удаляются и продолжают участвовать в категориях, Sitemap и внутреннем поиске. Рядом появляются новые карточки — уже с актуальной ценой и остатком.
Полезно сравнить пары по изображению, названию, бренду, характеристикам, SKU, внешнему ID и времени последнего обновления. Отдельно проверьте, не остались ли старые URL в фиде, Sitemap или ссылках категорий.
Если старая карточка больше не нужна и для неё есть точная новая замена, можно планировать прямой 301 на соответствующую карточку. Если соответствия нет, массово отправлять все старые товары на категорию или главную не стоит.
Системная проверка
Диагностируйте каталог сразу на четырёх уровнях
Одна админка не показывает всю картину. Для уверенного вывода нужны данные импорта, CMS, публичных URL и поисковых сигналов.
Файл импорта
Уникальные ключи, количество строк, повторяющиеся SKU, пустые идентификаторы и изменение формата.
CMS / база
Сколько записей создано, какие ID появились в момент импорта и какие старые товары перестали обновляться.
Публичный сайт
URL, canonical, категории, вариации, внутренние ссылки и фактический HTTP-ответ карточек.
Поисковые сигналы
Sitemap, исключённые дубли, выбранные канонические URL и фактические страницы в поиске.
Для больших каталогов полезно выгрузить пары «внешний ID → SKU → внутренний ID → URL → статус → canonical». Такая таблица быстро показывает, где один товар раздвоился и на каком уровне это произошло.
Практический пример
После обновления интеграции каталог вырос на несколько тысяч карточек
Представим магазин с 18 000 товаров. После обновления обмена с ERP в CMS стало около 20 400 карточек, хотя ассортимент почти не изменился. Новые товары визуально совпадают со старыми, но получают другие внутренние ID и URL.
| Проверка | Наблюдение | Вывод |
|---|---|---|
| Дата создания | 2 400 карточек созданы в окно импорта | Дубли связаны с конкретной загрузкой |
| SKU | У старых записей есть ведущие нули, у новых нет | Ключ нормализуется по-разному |
| Внешний ID | У новых товаров поле пустое | Интеграция перестала передавать стабильный идентификатор |
| Canonical | Каждая карточка указывает сама на себя | Для поиска это две самостоятельные страницы, а не URL-дубли одной записи |
Исправление начинается с интеграции: возвращаем устойчивый ключ сопоставления и сначала тестируем update на небольшой выборке. Затем строим карту «старая карточка → новая карточка», выбираем основную версию, обновляем внутренние ссылки и Sitemap. Только после подтверждения соответствий удаляем или перенаправляем лишние URL.
Числа в примере условные. Важна последовательность: сначала доказать механизм появления дублей, затем исправить источник, потом чистить каталог и поисковые последствия.
Типовые сценарии
По симптомам можно быстро сузить круг причин
Сравните уникальный ключ и режим create/update до и после изменения интеграции.
Проверяйте маршрутизацию, параметры, категории, canonical и внутренние ссылки.
Смотрите модель вариаций и правила, по которым строки выгрузки превращаются в карточки.
Импорт, вероятно, перестал узнавать старые записи после смены идентификатора.
Проверяйте скрытые URL, параметры, архивные карточки, Sitemap и старые внутренние ссылки.
Это ещё не доказательство дубля товара: сравните идентификаторы, содержание, назначение и URL.
Чего не делать
Ошибки, которые превращают локальный сбой импорта в большую SEO-проблему
Удалить все новые карточки сразу
Можно потерять актуальные цены, остатки или новые идентификаторы до того, как станет понятна правильная пара.
Склеить товары только по названию
У разных моделей названия могут совпадать, а одна модель может менять название между выгрузками.
Поставить canonical и забыть об импорте
Canonical не исправляет размножение записей в CMS и не останавливает появление новых дублей.
Перенаправить всё на категорию
Точная замена товара полезнее общего редиректа. Массовый редирект без соответствий скрывает ошибку структуры.
Закрыть дубли noindex
Это может убрать часть URL из поиска, но база, Sitemap, ссылки и следующий импорт останутся неправильными.
Исправлять только метатеги
Уникальные Title не превращают две записи одного товара в две полезные страницы.
Чек-лист
Как безопасно убрать дубли после импорта
- Зафиксировать момент появления: какой импорт, файл или изменение интеграции предшествовали проблеме.
- Выбрать несколько пар: не начинать с массовых действий по всему каталогу.
- Определить тип дубля: две записи, несколько URL, вариации или старая/новая версия.
- Сравнить ключи: внешний ID, SKU, внутренний ID и правила нормализации.
- Исправить источник: добиться update существующей карточки вместо повторного create.
- Проверить тестовый импорт: на малой выборке убедиться, что дубли больше не создаются.
- Построить соответствия: старая карточка → основная карточка для каждой подтверждённой пары.
- Проверить URL-сигналы: HTTP, canonical, внутренние ссылки, категории и Sitemap.
- Очистить последствия: удалить, объединить или перенаправить только после подтверждения пар.
- Повторить crawl: убедиться, что лишние URL не продолжают появляться из шаблонов и ссылок.
- Проверить Вебмастер: наблюдать исключённые дубли и выбранные поиском версии страниц после переобхода.
Когда нужен доступ к проекту
Какие данные позволяют найти причину быстрее
Для массовых дублей обычно нужны исходный файл или API-ответ импорта, настройки сопоставления полей, лог последней загрузки, выгрузка ID/SKU из CMS и crawl публичного каталога. Если импорт связан с ERP или 1С, полезно сравнить идентификаторы до и после изменения обмена.
Перед массовой очисткой сделайте backup базы и файлов. Если магазин принимает заказы, изменения в товарных ID, вариациях и связях с заказами нужно тестировать на копии или ограниченной выборке.
Вопросы
Короткие ответы
Можно ли просто удалить все дубли товаров?
Только после того, как понятно, какая запись основная и почему дубль появился. Иначе следующий импорт создаст его снова или будут потеряны актуальные данные.
Canonical решит проблему двух одинаковых карточек?
Он помогает поисковику понять предпочитаемый URL, но не исправляет две записи товара в CMS, внутренние ссылки и работу импорта.
Какой ключ лучше использовать при импорте?
Стабильный уникальный идентификатор, который не меняется между выгрузками. Конкретное поле зависит от системы; важнее его неизменность и однозначность.
Нужно ли объединять все вариации в одну карточку?
Нет универсального требования. Решение зависит от самостоятельности варианта, пользовательского сценария, ассортимента и структуры сайта.
Что делать со старым URL после объединения дублей?
Если есть точная основная карточка и старый URL больше не нужен, обычно рассматривают прямой постоянный редирект. Сначала проверьте соответствие и внутренние ссылки.
Как понять, что проблема больше не повторится?
Повторите тестовый импорт, сравните количество записей до и после и убедитесь, что существующие товары обновляются, а новые создаются только для действительно новых идентификаторов.