Большинство команд до сих пор лечат null как баг реализации. Это удобная ложь.

Большинство команд до сих пор лечат null как баг реализации. Это удобная ложь.

null — не ошибка кода. Это дизайн-решение, которое до сих пор разъедает продукт, аналитику и SEO-процессы: битые поля в фидах, пустые title, кривые canonical, разваленные entity graphs, неверные статусы в CRM и сквозной атрибуции.

Контринтуитивный вывод: дорогие сбои чаще рождаются не там, где «плохо написали», а там, где систему спроектировали под «авось значения не будет». В международном SEO это особенно заметно: один null в data layer может обнулить качество сигналов для десятков рынков сразу.

Что с этим делать практично:
— не считать отсутствие значения нейтральным состоянием;
— явно различать missing / empty / unknown / not applicable;
— валидировать поля до публикации, а не после индексации;
— строить отчёты так, чтобы пустота была событием, а не мусором.

Если в вашей архитектуре null допустим по умолчанию, у вас уже есть скрытый debt. И он почти всегда дороже, чем кажется.