В интернет-магазине закончился холодильник Bosch. Остаток в учётной системе стал равен нулю, карточка товара получила надпись «Нет в наличии», и дальше возникает вопрос, который выглядит простым только первые тридцать секунд: что теперь делать с URL?

Оставить страницу с кодом 200?

Перенаправить покупателя через 301 на новый холодильник?

Вернуть обычный 404?

Или использовать более категоричный 410 Gone, чтобы поисковик понял, что товар исчез навсегда?

Универсального ответа нет, потому что нулевой остаток на складе ничего не говорит о судьбе самого URL.

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

Поэтому главное правило выглядит так:

HTTP-код описывает состояние интернет-ресурса, а наличие на складе — состояние товара. Это связанные, но совершенно не одинаковые вещи.

Если эти два слоя смешать, интернет-магазин быстро получает тысячи неправильных редиректов, исчезающие из поиска полезные страницы или, наоборот, огромный кладбищенский каталог пустых карточек с 200 OK.

Ноль на складе — это ещё не 404

Начнём с самой распространённой ошибки.

В базе магазина есть поле:

stock = 0

Разработчик смотрит на него и пишет примерно такую бизнес-логику:

if ( $stock === 0 ) {
    status_header( 404 );
}

Технически код работает. Логически — нет.

Один и тот же нулевой остаток способен означать совершенно разные вещи.

Холодильники закончились утром, но следующая машина приедет в пятницу.

Поставщик задерживает поставку, и точной даты пока нет.

Это сезонная садовая мебель, которая вернётся весной.

Модель больше никогда не будет производиться.

Модель снята, но производитель выпустил прямой аналог.

Продажи прекращены, но тысячи владельцев продолжают искать характеристики старого устройства.

Поэтому складской статус недостаточен для принятия решения о URL.

Нужно отделить два слоя.

Состояние товара:

InStock
OutOfStock
BackOrder
PreOrder
Discontinued

Состояние ресурса:

200 OK
301 Moved Permanently
404 Not Found
410 Gone

Google поддерживает в Product structured data отдельные значения InStock, OutOfStock, BackOrder, PreOrder и Discontinued. Сам факт отсутствия товара поэтому не требует превращать существующую страницу в ошибку.

Четыре вопроса перед любым изменением карточки

До выбора между 200, 301, 404 и 410 достаточно последовательно ответить на четыре вопроса.

Вернётся ли именно этот SKU

Не «появится ли когда-нибудь похожий холодильник», а вернётся ли конкретная модель.

Если вернётся, URL обычно продолжает существовать.

Можно ли оформить заказ сейчас

Товар может физически отсутствовать на складе, но магазин продолжает принимать заказы с отложенной поставкой.

Это уже не тот же сценарий, что простое «товара нет, заказать нельзя».

Есть ли настоящая замена

Не любой другой товар из категории.

Не более дорогая модель, которую сейчас удобно продать.

А действительно логичный преемник, на который пользователь старой страницы мог бы попасть вместо неё и не удивиться.

Нужна ли старая страница после окончания продаж

Иногда карточка давно перестала быть коммерческой, но продолжает выполнять информационную функцию.

Именно последний вопрос чаще всего выпадает из стандартных автоматических правил интернет-магазина.

Ситуация №1. Товар временно закончился, но вернётся

Допустим, Bosch KGN39VL25 закончился в четверг, а следующая поставка ожидается через две недели.

Сам товар временно недоступен.

Но ресурс не исчез.

На карточке по-прежнему есть:

• модель;
• фотографии;
• характеристики;
• размеры;
• отзывы;
• описание;
• информация о гарантии;
• пользовательский спрос.

В такой ситуации логичным техническим состоянием страницы остаётся:

HTTP/2 200 OK

А состояние предложения меняется на:

OutOfStock

Google Merchant Center прямо определяет out_of_stock как ситуацию, когда товар сейчас недоступен для покупки или магазин не принимает на него заказ. При этом Google рекомендует не удалять временно закончившийся товар только из-за отсутствия остатка.

То есть совершенно нормальная конфигурация выглядит так:

URL существует → 200
товара временно нет → OutOfStock

Никакого противоречия здесь нет.

Что показать пользователю

Слабый вариант карточки:

Нет в наличии.

И всё.

Пользователь пришёл из поиска, потратил время и получил цифровой аналог закрытой двери.

Полезная карточка может объяснить:

• действительно ли товар временно закончился;
• ожидается ли новое поступление;
• можно ли подписаться на уведомление;
• какие варианты той же модели доступны;
• какие актуальные модели максимально близки по характеристикам.

Если дата известна и магазин уверен в ней, её можно показать.

Если не известна — лучше честно написать, что точной даты нет, чем каждую неделю обещать новую пятницу.

Нужно ли убирать цену

Не обязательно.

Для Merchant Center Google даже требует, чтобы цена оставалась заметна на landing page у товара со статусом out_of_stock, если такой продукт продолжает находиться в товарных данных.

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

Ситуация №2. Поставка неизвестна

Теперь поставщик говорит:

Когда-нибудь привезём, но когда — неизвестно.

Товар может вернуться, и удалять его пока рано.

Карточка по-прежнему способна отдавать:

200 OK

а availability:

https://schema.org/OutOfStock

Google Search прямо определяет OutOfStock как состояние, когда товар в данный момент отсутствует.

Главное — не превращать неопределённость в выдуманный срок.

Почему здесь не всегда подходит BackOrder

BackOrder означает более конкретную ситуацию: товара сейчас нет, но магазин принимает заказ и планирует отправить его после появления.

В Merchant Center при backorder нужно указывать availability_date, то есть дату будущей доступности/отправки; она должна быть также заметна на landing page.

Поэтому если магазин сам не знает, когда холодильник появится, и заказы не принимает, писать BackOrder просто для красивого статуса не нужно.

Это обычный:

OutOfStock

А когда BackOrder уместен

Представим другую ситуацию.

Холодильника сегодня нет на складе, но поставка подтверждена на 4 ноября. Магазин принимает оплату сейчас и доставит после поступления.

Тогда:

200 OK
BackOrder
availability_date = подтверждённая дата

логичнее.

Google отдельно различает preorder и backorder: preorder предназначен для ещё не вышедших продуктов, а уже существующий товар, который временно отсутствует, но снова будет доступен и уже принимается к заказу, относится к backorder.

Это мелкая на первый взгляд терминология, но именно такие мелочи потом становятся причиной несоответствий между сайтом, Schema.org и Merchant Center.

Ситуация №3. Товар снят, но есть новая модель

Теперь производитель официально прекратил выпуск Bosch KGN39VL25.

На замену вышел Bosch KGN39VL35.

Похожее название ещё не делает его автоматически правильной целью для редиректа.

Нужно проверить, действительно ли новая модель является преемником старой:

• тот же тип устройства;
• близкие размеры;
• то же назначение;
• аналогичный набор основных функций;
• сопоставимый ценовой сегмент;
• производитель сам позиционирует её как замену либо пользовательская задача фактически та же.

Если да, появляется основание для:

301 Moved Permanently

Google рекомендует постоянный 301, когда содержимое страницы перемещено или у старого URL появился ясный заменяющий ресурс.

Это важная формулировка.

Не «есть хоть что-нибудь похожее».

А clear replacement.

Почему 301 здесь логичен

Пользователь запросил:

Bosch KGN39VL25

Приходит на старый URL.

Магазин уже не может предоставить старый товар, но действительно существует его актуальный преемник.

Постоянный redirect сообщает одновременно человеку и поисковой системе:

этот ресурс больше не используется, актуальная версия находится здесь.

Яндекс описывает 301 аналогично: ресурс перемещён навсегда, старый документ больше не используется, а робот должен работать с целевой страницей.

Почему нельзя редиректить на случайно похожий товар

Допустим, закончился бюджетный холодильник за 45 000 ₽.

Магазин делает 301 на совершенно другую двухдверную модель за 160 000 ₽ только потому, что обе принадлежат Bosch.

Для магазина это «похожий товар».

Для пользователя — совсем другая страница.

HTTP 301 сообщает не «возможно, вам понравится ещё вот это», а фактически:

запрошенный ресурс постоянно переехал сюда.

Это гораздо более сильное утверждение.

Похожие товары можно показывать на самой странице, не превращая каждый из них в цель перенаправления.

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

Удалён:

/holodilniki/bosch-kgn39vl25/

Редирект:

/holodilniki/

Вроде бы логично: холодильник был частью категории холодильников.

Но пользователь искал конкретную модель, а оказался в каталоге из 800 товаров.

Это не тот же ресурс.

И уж тем более сомнителен массовый вариант:

10 000 снятых SKU
↓
301
↓
главная страница

Google отдельно предупреждает, что массовое перенаправление старых URL на нерелевантную страницу, например на главную, может восприниматься как soft 404.

301 не является контейнером, куда можно складывать все удалённые URL ради сохранения «SEO-веса».

Ситуация №4. Товар снят навсегда и аналога нет

Bosch KGN39VL25 больше не производится.

Прямого преемника нет.

Магазин не собирается возвращать товар.

Теперь задаём следующий вопрос:

есть ли какая-либо разумная причина сохранять эту страницу?

Если нет, ресурс действительно закончил жизненный цикл.

И здесь появляется нормальная ветка:

404 Not Found

или:

410 Gone

Google рекомендует возвращать 404 или 410 для содержимого, которое больше не существует и не имеет подходящей замены.

Яндекс отдельно определяет 410 Gone как состояние, когда ресурс окончательно удалён, и рекомендует 301 для тех случаев, где ресурс именно переехал.

Что выбрать — 404 или 410

404 Not Found означает, что сервер не нашёл ресурс по данному адресу.

410 Gone семантически сильнее: ресурс существовал, но теперь удалён окончательно.

Поэтому если система достоверно знает, что SKU больше никогда не вернётся и URL намеренно закрыт, 410 вполне логичен.

Но не нужно превращать это в SEO-миф:

410 всегда лучше 404.

или:

Google удалит 410 за сутки, а 404 будет хранить полгода.

Официальная документация Google допускает для удалённого содержимого оба варианта. Она не обещает универсальный магический выигрыш в индексации от одного конкретного кода.

На практике гораздо важнее, чтобы сервер вообще перестал лгать.

Если товара действительно нет, страница не должна показывать:

Товар снят с производства

и одновременно отвечать:

200 OK

если никакого полезного содержимого на ней больше не осталось.

Soft 404: товар исчез, а сервер делает вид, что всё хорошо

Одна из худших реализаций выглядит так.

Пользователь открывает старую карточку.

Видит:

Товар не найден.

Но заголовки ответа:

HTTP/2 200 OK

Для человека ресурс отсутствует.

Для протокола всё прекрасно.

Google называет подобные ситуации soft 404: страница возвращает успешный 2xx, но содержимое выглядит как ошибка, пустой документ или сообщение об отсутствии ресурса.

Надпись «Нет товара» сама по себе не превращает страницу в soft 404 — временно отсутствующая полноценная карточка может совершенно корректно жить с 200.

Проблема возникает, когда основного содержимого фактически больше нет.

Например:

Bosch KGN39VL25

Товар удалён.

И больше ничего.

Нет характеристик.

Нет фотографий.

Нет документации.

Нет альтернатив.

Нет объяснения.

Технически поддерживать такой пустой документ с 200 уже трудно оправдать.

Ситуация №5. Товар снят навсегда, но карточка всё ещё нужна

А теперь наиболее интересный сценарий.

Bosch KGN39VL25 сняли с производства четыре года назад.

Магазин никогда больше его не продаст.

Но в Google и Яндексе люди продолжают искать:

• Bosch KGN39VL25 характеристики;
• Bosch KGN39VL25 размеры;
• Bosch KGN39VL25 инструкция;
• Bosch KGN39VL25 компрессор;
• полка Bosch KGN39VL25;
• чем заменить Bosch KGN39VL25;
• Bosch KGN39VL25 отзывы.

То есть коммерческий жизненный цикл товара завершён.

Информационный жизненный цикл страницы — нет.

В такой ситуации автоматически отдавать 410 только потому, что ERP сказала discontinued = 1, может быть плохим решением.

Карточку можно превратить в полноценную архивную страницу товара.

Она продолжает возвращать:

200 OK

Но честно сообщает:

Модель снята с производства и больше не продаётся.

Дальше пользователь получает:

• полные характеристики;
• фотографии;
• инструкцию;
• дату или период производства;
• совместимые расходники;
• информацию о ремонте или запчастях;
• модель-преемник, если она появилась;
• актуальные похожие решения.

Теперь страница существует уже не потому, что на ней есть кнопка «Купить».

Она существует потому, что отвечает на реальную пользовательскую задачу.

Google Search поддерживает для Offer.availability значение:

https://schema.org/Discontinued

то есть позволяет прямо сообщить, что товар снят с продажи.

И здесь появляется важная граница между архивной карточкой и мёртвой карточкой.

Архивная:

товар купить нельзя, но страница всё ещё полезна.

Мёртвая:

товар купить нельзя, а страница больше ничего не даёт.

Первая может иметь смысл с 200.

Вторая — кандидат на 404, 410 или 301 при наличии реальной замены.

Decision tree: 200, 301, 404 или 410

Теперь всю логику можно собрать в одно дерево.

ТОВАР НЕДОСТУПЕН
│
├── Вернётся тот же SKU?
│   │
│   ├── Да
│   │   │
│   │   ├── Заказы сейчас принимаются?
│   │   │   │
│   │   │   ├── Да → 200 + BackOrder
│   │   │   │          + реальная дата поставки
│   │   │   │
│   │   │   └── Нет → 200 + OutOfStock
│   │
│   └── Нет
│       │
│       ├── Есть настоящий прямой преемник?
│       │   │
│       │   ├── Да → 301 на преемника
│       │   │
│       │   └── Нет
│       │       │
│       │       ├── Старая карточка остаётся полезной?
│       │       │   │
│       │       │   ├── Да → 200 + архив + Discontinued
│       │       │   │
│       │       │   └── Нет → 404 или 410

Главная ценность схемы в том, что решение начинается не с HTTP-кода.

Сначала выясняется судьба товара и задача страницы.

И только потом появляется код ответа.

Сезонный товар — отдельная история

Представим искусственную новогоднюю ёлку.

Она появляется в продаже осенью, полностью заканчивается в январе и возвращается следующей осенью.

Если каждый январь делать:

404

а в октябре создавать новую страницу, магазин собственными руками каждый год обнуляет стабильность URL.

Если это действительно тот же товар или стабильная сезонная позиция, гораздо разумнее сохранить страницу:

200 OK

а availability менять по фактическому состоянию.

То же может относиться к:

• зимним шинам;
• садовой мебели;
• бассейнам;
• сезонной технике;
• праздничному декору;
• части туристического ассортимента.

Сезон закончился — не значит, что ресурс исчез навсегда.

Если же ассортимент каждый год совершенно новый и старый SKU уже не вернётся, решение снова возвращается к нашей схеме: преемник, архив или удаление.

Что делать, если закончилась целая категория

Карточка одного холодильника и категория «Холодильники Bosch» — разные типы ресурсов.

Поэтому нельзя механически переносить решение SKU на категорию.

Товары временно закончились

Допустим, из-за проблем с поставками категория временно опустела.

Сам раздел сайта по-прежнему существует.

Он имеет историю, внутренние ссылки и пользовательский смысл.

Удалять его только из-за сегодняшнего нулевого ассортимента необязательно.

Но страница не должна выглядеть так:

Холодильники Bosch

Товаров не найдено.

Конец.

Google указывает, что пустые или практически пустые документы с успешным ответом могут интерпретироваться как soft 404.

Поэтому если категория действительно временно сохраняется, на ней должны оставаться полезные элементы:

• объяснение временного отсутствия;
• уведомление о поступлении;
• соседние линейки;
• актуальные альтернативы;
• информация о бренде;
• ссылки на близкие категории.

Категорию заменил новый раздел

Например, старая структура:

/catalog/refrigerators-old-series/

полностью заменена новой:

/catalog/refrigerators/

и смысл ресурсов фактически совпадает.

Тогда постоянный redirect выглядит логично.

Категория исчезла без замены

Если магазин вообще перестал работать с брендом, раздел больше не имеет пользовательской ценности и прямого преемника нет, нормальным финалом могут быть 404 или 410.

Опять же — не главная страница только потому, что «туда всегда можно перенаправить».

Что делать с Schema.org

Для поисковой системы наличие лучше передавать не текстом, который она должна угадывать, а структурированными данными Product / Offer, если разметка соответствует реальному содержимому страницы.

Google Search официально поддерживает несколько значений ItemAvailability.

Товар есть

{
  "@type": "Offer",
  "availability": "https://schema.org/InStock"
}

Временно отсутствует

{
  "@type": "Offer",
  "availability": "https://schema.org/OutOfStock"
}

OutOfStock буквально означает, что товар сейчас отсутствует.

Доступен под заказ

{
  "@type": "Offer",
  "availability": "https://schema.org/BackOrder"
}

Снят с производства

{
  "@type": "Offer",
  "availability": "https://schema.org/Discontinued"
}

Schema.org определяет Discontinued как состояние товара, выпуск или предложение которого прекращены. Google Product structured data тоже поддерживает это значение.

Подробно сам принцип структурированных данных я уже разбирал в материале Rich snippets: как внедрить, проверить и использовать в поиске.

Что учитывает Яндекс

Яндекс также использует Product совместно с Offer или AggregateOffer и учитывает свойство availability.

В официальной документации Вебмастера отдельно указано, что если Offer.availability сообщает об отсутствии товара, цена в соответствующем поисковом представлении не выводится.

То есть наличие — не декоративное поле Schema.org.

Оно реально участвует в передаче товарного состояния поисковой системе.

Merchant Center — это отдельный слой

Здесь возникает одна из самых частых архитектурных ошибок.

В магазине есть:

1. HTML-страница;
2. Schema.org;
3. товарный feed;
4. Merchant Center;
5. checkout.

Люди начинают относиться к ним как к одному объекту.

Например:

Мы удалили товар из Merchant Center, значит надо удалить страницу.

Нет.

Merchant Center описывает коммерческое товарное предложение в инфраструктуре Google.

URL сайта может продолжать существовать как полноценный документ.

Товар временно закончился

В feed:

availability = out_of_stock

Google рекомендует именно такое значение, когда товар временно недоступен и магазин не принимает заказ.

Товар можно заказать сейчас, но доставят позже

availability = backorder
availability_date = ...

Причём дата обязательна и должна совпадать с информацией на landing page.

Товар ещё не вышел

Вот здесь:

preorder

Google отдельно подчёркивает: preorder предназначен для продукта, который ещё не был выпущен, а не для старого товара, временно исчезнувшего со склада.

Товар снят навсегда

Вот здесь особенно интересный нюанс.

Google Merchant Center рекомендует не держать постоянно снятый товар как out_of_stock, а удалить discontinued product из product data.

При этом HTML-страница может остаться архивной.

Получается совершенно нормальная архитектура:

HTML URL → существует → 200
Schema.org → Discontinued
Merchant Center → товара уже нет

На первый взгляд непривычно.

На деле всё логично: Google Shopping больше не должен предлагать продукт к покупке, но обычный поиск всё ещё может использовать страницу как источник информации о модели.

Почему availability должен совпадать

Представим ситуацию:

На странице написано:

Нет в наличии.

В JSON-LD:

"availability": "https://schema.org/InStock"

В Merchant Center:

in_stock

А в checkout товар вообще нельзя положить в корзину.

Для покупателя это просто раздражает.

Для Merchant Center — ещё и техническая проблема.

Google требует согласованности availability между product data, landing page, structured data и checkout; несоответствия способны привести к отклонению товарного предложения.

Поэтому изменение складского статуса должно обновлять все связанные представления максимально синхронно.

Хорошая архитектура:

ERP / склад
      ↓
единый product state
      ↓
страница
Schema.org
feed
checkout

Плохая:

ERP → одно
WordPress → другое
JSON-LD → старое
feed → вчерашнее
checkout → неожиданность

Именно второй вариант потом рождает бесконечные вопросы:

Почему Google считает товар доступным, хотя его нет уже две недели?

Нужно ли оставлять снятый товар в Sitemap

XML Sitemap — это список URL, которые сайт хочет предложить поисковику для обхода как актуальные страницы.

Поэтому решение опять зависит от судьбы ресурса.

Товар временно OutOfStock

Карточка остаётся полноценным URL:

200 OK

Поэтому нет логической причины удалять её из Sitemap только из-за временного нулевого остатка.

Старый URL перенаправлен

Если карточка теперь:

301

старый адрес уже не является canonical-документом.

В актуальном Sitemap логичнее оставлять конечный URL, а не источник постоянного перенаправления.

Товар удалён через 404/410

Такой URL из актуального Sitemap убирается.

Иначе сайт одновременно сообщает:

этот адрес является актуальной страницей, которую стоит обходить

и:

этого ресурса больше не существует.

Подробнее настройку XML-карты сайта здесь имеет смысл связывать с отдельным материалом о Sitemap, если соответствующая страница уже опубликована на сайте.

Что делать с canonical

Canonical тоже часто пытаются использовать как универсальный ремонтный инструмент.

Временно отсутствующий товар

Карточка существует.

Она самостоятельная.

Обычно:

<link rel="canonical"
      href="https://example.ru/product/bosch-kgn39vl25/">

то есть self-canonical.

Не нужно ставить canonical на категорию только потому, что товара сегодня нет.

Категория «Холодильники Bosch» и конкретный Bosch KGN39VL25 отвечают на разные пользовательские запросы.

Разницу между типами коммерческих страниц я разбирал в материале Коммерческие запросы: как определить интент и выбрать страницу.

При 301

Если старый URL постоянно перенаправляется, главным сигналом уже является сам redirect.

Нет смысла рассчитывать, что canonical на недоступной старой HTML-странице будет основным механизмом переноса.

При 404 и 410

Canonical не способен превратить несуществующий ресурс в корректно удалённый.

Если страницы нет — сервер должен сообщить это HTTP-кодом.

Подробная механика описана в материале о том, как должна работать корректная страница 404.

Что делать со ссылками на удалённый товар

Перед массовым удалением каталога полезно проверить, что именно вы собираетесь уничтожить.

Допустим, интернет-магазин решил разом закрыть 12 000 старых SKU.

Самое простое правило:

discontinued = yes
→
410

занимает несколько часов разработки.

Но внутри этих 12 000 URL могут оказаться совершенно разные страницы.

Например:

Группа	URL
нет показов и переходов за год	8 400
есть длинный брендовый спрос	2 100
есть внешние ссылки	900
получают коммерческий или информационный трафик	600

Часть групп будет пересекаться, но уже видно: перед массовым удалением полезно проверить хотя бы:

• показы;
• клики;
• внешние ссылки;
• внутренние ссылки;
• прямые заходы;
• реальный поисковый спрос;
• наличие преемника;
• документационный спрос.

Есть сильные внешние ссылки и настоящий преемник

Хороший кандидат на релевантный 301.

Есть внешние ссылки, но преемника нет

Нельзя делать нерелевантный redirect только потому, что жалко ссылку.

Иногда полезнее сохранить архивную страницу.

Иногда — честно удалить её.

Трафик идёт по информационным запросам

Это серьёзный аргумент в пользу архива.

Например, пользователь ищет старый холодильник не потому, что хочет его купить, а чтобы подобрать полку.

Удалить такую карточку означает убрать полезный ответ на действующий запрос.

Что делать с внутренними ссылками

После 301, 404 или 410 недостаточно изменить только карточку.

Нужно найти места, откуда на неё продолжает вести сайт:

• категории;
• подборки;
• статьи;
• блоки «Популярное»;
• старые акции;
• меню;
• сравнения;
• перелинковка товаров.

После 301

Внутренние ссылки лучше обновить на конечный URL.

Не нужно специально заставлять собственного пользователя проходить через redirect, если новый адрес уже известен.

После 404/410

Ссылку нужно удалить либо заменить релевантной.

Сам факт корректного 404 не делает битую внутреннюю ссылку полезной.

Можно ли всё автоматизировать

Да, но автоматизировать нужно решение, а не один складской флаг.

Плохая модель:

stock = 0
→
404

Чуть лучше:

stock > 0
→ InStock

stock = 0
→ OutOfStock

Но для полноценного жизненного цикла товара нужны дополнительные состояния.

Например:

active
temporarily_out_of_stock
backorder
seasonal
discontinued_with_successor
discontinued_archive
removed

И уже из них строится техническое поведение.

Примерно так:

switch ( $product_state ) {

    case 'temporarily_out_of_stock':
        // HTTP 200
        // Schema: OutOfStock
        break;

    case 'backorder':
        // HTTP 200
        // Schema: BackOrder
        // availability date
        break;

    case 'discontinued_with_successor':
        // HTTP 301
        // Location: exact successor URL
        break;

    case 'discontinued_archive':
        // HTTP 200
        // Schema: Discontinued
        break;

    case 'removed':
        // HTTP 404 or 410
        break;
}

Теперь интернет-магазин кодирует бизнес-смысл, а не пытается угадать его из одного числа на складе.

Один холодильник Bosch во всех сценариях

Соберём всё в практическую таблицу.

Что произошло	HTTP	Страница	Availability	Sitemap
закончился, поставка ожидается	200	оставить	OutOfStock	оставить
закончился, дата неизвестна	200	оставить	OutOfStock	оставить
отсутствует, но заказ принимается	200	оставить	BackOrder	оставить
ещё не выпущен, принимается предзаказ	200	оставить	PreOrder	оставить
снят, есть настоящий преемник	301	перенаправить	—	старый убрать
снят, замены нет, карточка бесполезна	404/410	удалить	—	убрать
снят, но страница нужна как архив	200	сохранить архив	Discontinued	можно оставить
сезонный и снова вернётся	200	сохранить	OutOfStock	оставить

Именно эта таблица показывает, почему фраза:

Что делать с товаром, если его нет?

сама по себе недостаточна.

Нужно знать почему его нет и что будет дальше.

Как эта задача выглядит на большом магазине

На магазине из 200 товаров всё можно проверить вручную.

На каталоге из 500 000 SKU ручное решение невозможно.

Поэтому нормальная архитектура должна отделять:

остаток

от:

жизненного состояния SKU

и от:

состояния URL.

Это три разных поля.

Например:

stock_status:
in_stock / zero

lifecycle:
active / seasonal / discontinued / archived

url_action:
200 / redirect / removed

Тогда бизнес может управлять каталогом системно.

Без этого через несколько лет любое крупное e-commerce решение превращается в археологические раскопки из старых редиректов, пустых карточек и правил, смысл которых помнит только разработчик, уволившийся в 2021 году.

Когда 301 действительно нужен

Полезный тест очень простой.

Представьте, что пользователь самостоятельно нажал ссылку на старую карточку.

После автоматического redirect он увидел новую страницу.

Его первая реакция:

Да, это именно то, что я ожидал вместо старой модели.

Тогда цель, вероятно, подходит.

Если реакция:

А почему меня вообще сюда отправили?

редирект подозрителен.

Технически это не формула Google, но для проектирования e-commerce URL она работает удивительно хорошо.

Когда лучше оставить архив вместо редиректа

Есть старая фотокамера.

Через пять лет производитель выпустил десять новых поколений.

Куда её редиректить?

На последнюю модель?

Цены отличаются втрое.

Характеристики совсем другие.

На категорию фотоаппаратов?

Пользователь искал конкретное устройство.

В таком случае архивная карточка часто честнее:

Модель снята с производства. Вот её характеристики, инструкция, совместимые аксессуары и современные альтернативы.

И уже из неё можно дать обычные ссылки на новые товары.

Ссылка:

возможно, вам подойдёт эта модель

и HTTP redirect:

запрошенный ресурс теперь находится здесь

— принципиально разные вещи.

Когда 404 или 410 лучше любого «SEO-редиректа»

Иногда страницы просто больше не нужны.

Допустим, магазин когда-то продавал одноразовую дешёвую позицию.

Она:

• не получает трафика;
• не имеет ссылок;
• не имеет документационного спроса;
• не вернётся;
• не имеет прямого преемника.

Оставлять её вечно только потому, что «404 плохо для SEO», не имеет смысла.

Корректный 404 сам по себе не является наказанием сайта.

На Vagizov.com это подробно разобрано в материале о правильной обработке страницы 404 и её HTTP-статуса.

Ошибка возникает не тогда, когда сервер честно сообщает об отсутствии ресурса.

Ошибка возникает, когда мы:

• продолжаем ссылаться на него;
• держим в Sitemap;
• отдаём 200 для пустой страницы;
• перенаправляем куда попало.

Почему нельзя оценивать решение только по «сохранению веса»

При обсуждении старых товарных страниц почти всегда появляется аргумент:

Но на URL были ссылки, надо обязательно поставить 301, чтобы не потерять вес.

Сначала нужно найти содержательно подходящую цель.

Если её нет, нельзя изобрести релевантность ради ссылочного сигнала.

Представим, что популярная статья журнала ссылается на конкретный холодильник как на пример очень тихой модели.

Через пять лет модель снята.

Если магазин отправляет этот backlink на главную страницу, человек по ссылке получает вообще не тот материал.

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

Иногда лучший способ сохранить ценность URL — не перенаправлять его вообще.

Массовое снятие товаров — уже техническое SEO

Когда речь идёт не о пяти карточках, а о десятках тысяч SKU, задача становится частью полноценной технической архитектуры интернет-магазина.

Нужно одновременно контролировать:

• правила жизненного цикла;
• HTTP;
• canonical;
• structured data;
• feed;
• Sitemap;
• внутренние ссылки;
• фильтры;
• аналоги;
• поисковый спрос;
• внешние ссылки.

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

Один холодильник исправить несложно.

Сделать так, чтобы магазин правильно обрабатывал следующие 100 000 снятых товаров без ручного вмешательства, — уже архитектурная задача.

Главное

Когда товар заканчивается, первое желание — привязать решение к складу:

есть товар → 200
нет товара → удалить

Для реального интернет-магазина эта схема слишком примитивна.

Ноль на складе — это всего лишь состояние коммерческого предложения.

Он ничего не говорит о том, существует ли сам ресурс.

Холодильник, который вернётся через две недели, совершенно нормально остаётся страницей 200 со статусом OutOfStock.

Если магазин уже принимает заказ на подтверждённую будущую поставку, появляется BackOrder.

Если производитель окончательно заменил модель настоящим преемником, старый URL может постоянно перенаправляться через 301.

Если товар исчез и больше никакой задачи не решает, честные 404 или 410 лучше пустой карточки или редиректа на главную.

А если модель снята с производства, но люди ещё годами ищут характеристики, документацию и запчасти, карточка может продолжать жить как 200-архив с Discontinued.

Поэтому правильный вопрос звучит не так:

Какой код поставить, если остаток стал нулём?

А так:

Что произошло с самим товаром, есть ли у него реальная замена и остаётся ли этот URL полезным человеку?

И только после ответа выбирается 200, 301, 404 или 410.

Склад отвечает на вопрос, можно ли сейчас продать холодильник.

HTTP отвечает на совершенно другой вопрос: что произошло с его страницей.