Что делать с карточкой товара, которого нет в наличии

Надпись «нет в наличии» — не техническая ошибка и не повод автоматически удалять карточку. Это состояние предложения, которое нужно одинаково честно отразить человеку, поисковому роботу, товарному фиду и разметке. Если товар вернётся, полезный URL обычно разумно сохранить с ответом 200 OK, статусом OutOfStock, понятной датой или условием ожидания и подходящими альтернативами. Если модель снята навсегда и страница больше ничего не даёт покупателю, потребуется другой сценарий.

Проблемы начинаются, когда разные части магазина рассказывают разные истории. В карточке написано «нет», в Schema.org осталось InStock, в рекламном фиде стоит наличие, а кнопка позволяет оформить заказ, который отменит менеджер. Обратная крайность — мгновенно отдавать 404 для популярной карточки после временного обнуления остатков. В первом случае магазин вводит пользователя в заблуждение, во втором теряет сохранённый адрес, ссылки, отзывы и возможность вернуть спрос после поставки.

Ни один код ответа и ни одна разметка сами по себе не гарантируют позиции или расширенный результат. Рабочая стратегия начинается с различения временного отсутствия, предзаказа, поставки под заказ и окончательного прекращения продаж. Затем для каждого состояния задают правила интерфейса, URL, внутренних ссылок, фида, Sitemap и мониторинга. Ниже — система, которую можно превратить в техническое задание для магазина любого размера.

Почему отсутствие товара — часть пользовательского спроса

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

Сначала посмотрите на намерение запроса и историю URL. Карточка с внешними ссылками, обзорами, стабильными показами и сезонными возвратами товара ценнее одноразовой страницы неизвестного артикула. Разобраться в различиях между исследовательским и транзакционным спросом поможет материал о поисковом интенте. В аналитике отдельно отмечайте запросы по модели, переходы из категорий и прямые открытия сохранённой ссылки: это разные причины оставить страницу доступной.

Не оценивайте ценность только по продажам последних семи дней. У сезонной техники может быть нулевой остаток между партиями, а у мебели срок поставки измеряется неделями. Зафиксируйте обычную длительность отсутствия, вероятность возврата, спрос и качество альтернатив. Если поставка ожидается через десять дней, уничтожать URL нелогично. Если производитель окончательно прекратил модель два года назад, а замены нет, сохранение пустой карточки лишь увеличивает долю бесполезных страниц.

Четыре состояния вместо расплывчатого «нет»

Минимальная модель состоит из четырёх различимых состояний. «В наличии» означает, что товар действительно можно добавить в корзину и получить на заявленных условиях. «Временно нет» — заказ сейчас не принимается, но возврат ожидается. «Предзаказ» означает, что магазин принимает обязательство до появления товара и сообщает условия. «Снят с продажи» — модель больше не вернётся. Для поставки под заказ можно добавить отдельное состояние BackOrder, если процесс и срок реальны, а не используются как декоративная обещалка.

Одного текста возле цены недостаточно: статус влияет на кнопку, срок, фид, структурированные данные, сортировку и уведомления. Создайте таблицу соответствий, а не набор независимых условий в разных сервисах. Поле статуса должно иметь владельца и единый источник — складскую систему, PIM или каталог. Ручное изменение допустимо как контролируемое исключение с журналом, сроком действия и ответственным сотрудником.

Термины на странице должны быть понятны без знания складской системы. Не заменяйте «нет в наличии» сообщением «доступность уточняйте»: оно перекладывает проверку на покупателя. Если дата поставки неизвестна, так и напишите. Если известен интервал, покажите источник и дату обновления. Для варианта по цвету или размеру статус нужен каждому конкретному предложению, а не всей модели сразу.

Опишите переходы между состояниями как конечный автомат. Из «в наличии» товар может уйти во «временно отсутствует», но не должен автоматически становиться «снят навсегда» после заданного тайм-аута без подтверждения. Из предзаказа он переходит в наличие либо в отменённую поставку, причём подписчики получают сообщение об изменении. Запрещённые переходы тоже важны: отрицательный остаток не должен включать продажу, а удаление записи поставщиком не должно мгновенно уничтожать карточку до сверки с локальным каталогом.

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

Как сделать временно недоступную карточку полезной

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

Полезная карточка отвечает на следующий вопрос. Когда ожидается поставка? Можно ли получить уведомление? Есть ли тот же товар в другом цвете, магазине или комплектации? Какая модель действительно заменяет отсутствующую? Блок не должен превращаться в витрину случайных бестселлеров. Сравните ключевые параметры и объясните различие: «дороже на 900 рублей, но такая же ширина и выше мощность», а не просто «вам может понравиться».

Сохраните обычную навигацию и хлебные крошки. Пользователь должен легко вернуться в категорию, применить фильтр «в наличии» и увидеть аналог. Практические требования к содержанию карточки собраны в руководстве по SEO карточек товара, а изображения стоит оптимизировать по рекомендациям из материала о сжатии фотографий. Не удаляйте медиа только потому, что остаток стал нулевым: они продолжают помогать сравнению и послепродажным задачам.

Не раздувайте текст шаблонными абзацами о качестве магазина. Лучше дать конкретику: артикул производителя, совместимость, таблицу размеров, паспорт, ответы на частые вопросы и честное состояние. Если часть сведений устарела вместе с моделью, пометьте это и не переносите автоматически в новую карточку. Содержание должно описывать предмет, а не симулировать его наличие.

Учитывайте мобильный сценарий. Статус и недоступная кнопка должны быть видны до длинного описания, а форма уведомления — работать с клавиатуры и сообщать об ошибке понятным текстом. Не оставляйте липкую панель «купить» после отключения основной кнопки. При открытии старой ссылки из письма пользователь сразу должен понять, почему заказ невозможен и что можно сделать дальше, не прокручивая несколько экранов.

Уведомление о поступлении и честные альтернативы

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

Алгоритм альтернатив лучше строить по обязательным ограничениям. Для чехла важна совместимость, для встраиваемой техники — габариты, для обуви — доступный размер, для лекарства — решение специалиста, а не SEO-совет. Сначала отберите товары той же задачи, затем отфильтруйте доступные и лишь после ранжируйте по цене, характеристикам и популярности. Всегда показывайте, почему предложена замена.

Если доступен другой вариант одной модели, переключатель должен сразу показывать его цену и остаток. Не создавайте впечатление, что красный размер M есть в наличии, когда остался только синий XL. Для сложных каталогов правила вариантов связаны с URL и фидами; отдельная статья о разметке Product помогает проверить предложения, а материал о фасетной навигации — не превратить размеры и цвета в бесконечные дубли.

HTTP-ответ, canonical и доступность индексирования

Временно отсутствующая, но полезная карточка обычно продолжает отвечать 200 OK. Этот код означает, что документ доступен, а не то, что товар находится на складе. Статус предложения передают текстом и данными. Нельзя использовать мягкую ошибку: пустой шаблон с сообщением «товар не найден» и ответом 200 не становится полезной карточкой. Проверить различия кодов поможет справочник по HTTP-ответам.

Разведите уровни и в автотестах: HTTP-код описывает доступность URL, а Offer.availability — возможность купить предложение. Нулевой остаток не превращает существующий полезный документ в ошибку. Ответы 404 и 410 нужны, когда самого ресурса больше нет и выбран сценарий удаления, а не для ежедневного переключения складского поля.

Canonical на временной карточке обычно остаётся самоссылочным. Не направляйте все отсутствующие товары на категорию: содержание не является дублем категории, а поисковая система может проигнорировать такое указание. Не ставьте noindex только из-за краткого нулевого остатка, если ожидаете возврат товара и хотите сохранить URL. Общие принципы выбора основной версии разобраны в материале о rel canonical.

Оставьте URL доступным в robots.txt. Если страница закрыта от обхода, робот не увидит ни обновлённый статус, ни noindex, ни возврат товара. В Sitemap логично держать временно отсутствующую важную карточку, если она остаётся индексируемой, и обновлять lastmod только при существенном изменении документа. Массовая подмена даты при каждом запуске выгрузки обесценивает сигнал.

Проверьте серверный рендеринг: статус, название и основные ссылки должны быть доступны без обязательного выполнения сложного JavaScript. Контент не должен на секунду показывать «в наличии», пока браузер загружает остатки. Кэш на CDN, HTML и API обязан инвалидироваться согласованно; иначе поисковый робот и покупатель получают разные версии в зависимости от точки входа.

Product, Offer и корректный статус OutOfStock

Разметка описывает видимый товар и предложение, а не создаёт их. Для временно отсутствующей карточки можно сохранить Product, характеристики, изображения, бренд и идентификаторы, а внутри Offer передать availability со значением https://schema.org/OutOfStock. Цена, валюта, URL и состояние должны совпадать с тем, что видит человек. Если цена больше не актуальна и на странице её нет, не держите её только ради валидатора.

Разметку лучше генерировать из того же объекта данных, который формирует интерфейс и выгрузку. Отдельная строка, вручную зашитая в JSON-LD, быстро расходится со складом. При вариантах предложение относится к выбранному размеру, цвету или комплектации. Агрегировать несовместимые остатки в общий InStock нельзя: посетитель должен попасть на состояние, соответствующее размеченному предложению.

Валидная разметка даёт поисковой системе машиночитаемое описание, но не гарантирует rich result, цену в сниппете или более высокую позицию. Google учитывает свои правила качества и может выбрать обычный результат. Проверяйте JSON-LD после каждого изменения шаблона, сопоставляйте его с видимым текстом и не размечайте скрытые или вымышленные отзывы.

Синхронизация страницы, фида и оформления заказа

Товарный фид — не архив желаемого ассортимента. В Google Merchant Center значение out_of_stock должно совпадать с посадочной страницей и возможностью оформить заказ. В YML наличие обычно передаётся атрибутом available, и оно также должно соответствовать сайту. Если товар временно закончился, не обязательно удалять его из Google-источника данных: корректнее обновить статус. Окончательно прекращённую модель, напротив, удаляют из активной выгрузки по правилам канала.

Синхронизация включает пять точек: каталог или PIM, HTML-карточку, структурированные данные, фид и фактический checkout. Последняя точка особенно важна. Можно идеально обновить разметку, но оставить товар покупаемым через старую корзину или API. И наоборот, доступный товар может ошибочно блокироваться интерфейсом после запоздавшей выгрузки.

Установите допустимое время рассогласования. Для быстро продающихся остатков это могут быть минуты, для стабильного каталога — часы, но не бесконечность. Логируйте момент изменения на складе, публикации страницы и формирования фида. Контрольный робот ежедневно выбирает товары из каждого состояния, загружает HTML и JSON-LD, читает выгрузку и тестирует кнопку. Расхождение должно создавать задачу, а не теряться в общем отчёте.

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

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

Внутренние ссылки, категории и сортировка

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

Полностью обрывать внутренние ссылки на ценную временную карточку тоже рискованно. Оставьте её в тематической категории, истории просмотров, статьях и таблицах совместимости там, где переход полезен. Анкор описывает товар, а не состояние: «пылесос Model X», а статус отображается рядом. Как распределять связи между уровнями, подробно разобрано в руководстве по структуре сайта.

Когда категория временно опустела, не подменяйте её страницей ошибки. Сохраните описание задачи, объясните ситуацию, предложите соседние категории и уведомление, если поставка ожидается. Однако сотни постоянно пустых фильтров не нужны. Их следует исключить из Sitemap и навигации, а правила параметров проверить по материалу об индексном мусоре. Пустой фильтр и отсутствующий товар — разные сущности: первый часто не имеет самостоятельной ценности, второй может сохранять знания и спрос.

Что делать с товаром, снятым навсегда

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

Если точной замены нет и карточка не представляет справочной ценности, верните 404 Not Found или 410 Gone, уберите URL из Sitemap, категорий, фида и рекламных кампаний. Исправьте внутренние ссылки. Разница между временным и постоянным перенаправлением раскрыта в статье о редиректах 301 и 302, а цепочки следует исключать по рекомендациям о каскадах перенаправлений.

Иногда архивная карточка остаётся ценной: популярная снятая модель имеет инструкции, совместимые расходники, историю характеристик и много естественных ссылок. Тогда можно сохранить 200, но крупно написать «снят с производства», убрать Offer, не показывать недостоверную цену и направить к обслуживанию или заменам. Это решение должно быть выборочным. Массовый вечный архив из однотипных карточек увеличит тонкий контент; критерии оценки описаны в материале о малозначимых страницах.

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

Числовой пример: 12 000 карточек и прозрачная арифметика

Представим магазин с 12 000 товарных URL. Ночной снимок показал 8 760 доступных товаров, 2 040 временно отсутствующих, 360 предзаказов, 240 позиций под заказ и 600 снятых моделей. Проверка суммы: 8 760 + 2 040 + 360 + 240 + 600 = 12 000. До регламента все URL отвечали 200, во всех Offer стоял InStock, а выгрузка обновлялась раз в сутки.

Команда разобрала 600 снятых карточек. Для 150 нашлась точная модель-преемник — настроили 150 прямых 301. Ещё 90 страниц сохранили как полезные архивы с инструкциями и совместимыми деталями. Остальные 360 вернули 410. Контроль: 150 + 90 + 360 = 600. Из Sitemap удалили 510 URL — редиректы и 410, а 90 архивов оставили только при достаточной ценности.

Для 2 040 временно отсутствующих карточек сохранили 200 и самоссылочный canonical, выставили OutOfStock, отключили покупку и добавили подписку. Из них у 1 428 были подходящие доступные аналоги: 1 428 / 2 040 × 100 = 70%. За четыре недели карточки собрали 714 подтверждённых подписок, то есть 714 / 2 040 × 100 = 35% от числа временно отсутствующих URL, если считать одну уникальную подписку на карточку в выбранном срезе.

Автопроверка взяла все 12 000 URL и нашла 186 рассогласований между HTML и фидом. После исправления осталось 18: доля снизилась с 186 / 12 000 × 100 = 1,55% до 18 / 12 000 × 100 = 0,15%. Сокращение составило (186 − 18) / 186 × 100 ≈ 90,3%. Это проверяемый операционный результат, а не обещание роста позиций.

Через месяц вернулись 640 из 2 040 временно отсутствующих товаров. Для них синхронно включили кнопку, InStock и доступность в фиде. Доля возврата равна 640 / 2 040 × 100 ≈ 31,4%. Сохранённые URL снова принимали заказы без восстановления удалённых страниц. Чтобы оценить бизнес-эффект, команда сравнила конверсию вернувшихся товаров, подписки и отмены, но не приписывала SEO каждую покупку без корректной атрибуции.

Контроль качества и регламент команды

Регламент начинается с владельцев. Закупки подтверждают жизненный цикл, склад передаёт остаток, разработка обеспечивает согласованную публикацию, контент отвечает за объяснения и альтернативы, SEO — за URL, индексирование и выборочную проверку. Для каждого перехода статуса задайте срок: например, HTML и checkout меняются не позднее пяти минут, фид — пятнадцати, а окончательное удаление требует подтверждения двух ответственных.

Ежедневный отчёт должен показывать не только число отсутствующих товаров. Нужны новые переходы в OutOfStock, возвраты в наличие, карточки без альтернатив, расхождения HTML — JSON-LD — фид — checkout, снятые URL с ответом 200, ошибки редиректов и доля отсутствующих на первых страницах категорий. Отдельно следите за отменёнными заказами: это самый понятный сигнал, что доступность неверна.

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

Выборку стройте по риску, а не только случайно. Включайте самые посещаемые карточки, последние единицы, товары с несколькими вариантами, позиции нескольких продавцов, недавние переходы между статусами и страницы с активной рекламой. Раз в неделю добавляйте случайный слой, чтобы находить неизвестные классы ошибок. Для каждого инцидента сохраняйте URL, ожидаемое и фактическое состояние, временные метки систем и первопричину; тогда отчёт превращается в материал для устранения повторов.

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

Оценивайте стратегию по нескольким группам метрик: точность наличия, отмены, подписки, переходы к аналогам, доля полезных страниц, индексирование и органические посадки. Рост одной цифры не всегда хорош: больше подписок может означать нехватку товара, а меньше индексируемых URL — как очистку, так и случайное удаление спросовых карточек. Сопоставляйте метрики с изменениями ассортимента и сезона.

Раз в квартал пересматривайте сами правила: сроки поставок, поведение покупателей и каналы продаж меняются. Критерий полезного архива, допустимая задержка фида и список обязательных альтернатив должны оставаться измеримыми, понятными команде и одинаковыми для всех шаблонов магазина.

Главный вывод

Временное отсутствие — состояние предложения, а не смерть страницы. Сохраняйте полезную карточку с 200 OK, честным сообщением и Offer.availability = OutOfStock; синхронизируйте это состояние с фидом и checkout; предлагайте уведомление и объяснённые аналоги. Окончательно снятый товар обрабатывайте отдельно: точный 301, полезный архив либо 404/410. Такая система уменьшает противоречия и помогает человеку продолжить выбор, но сама по себе не гарантирует rich result, индексацию или позиции.