Post Scrapy ломается не на сайтах, а на мелочах в самом пауке

Scrapy ломается не на сайтах, а на мелочах в самом пауке Чаще всего проблемы не в парсинге, а в дисциплине проекта: — не отделён parsing от storage; — в item-processor тащат тяжёлую логику; — селекторы завязаны на один шаблон верстки; — retry и таймауты настроены «по умолчанию»; — логирование не показывает, где именно пропали данные. Для живого паука полезно держать три слоя: получение ответа, извлечение полей, запись результата. Если в spider уже есть нормализация, дедупликация и работа с БД — при первом изменении HTML вы чините сразу всё, а не один участок. Это особенно больно в проектах, где данные идут в ETL или CRM. Ещё одна типовая ошибка — ждать, что CSS/XPath селекторы будут жить вечно. Надёжнее собирать их по смысловым признакам: атрибуты, стабильные контейнеры, fallback-ветки для пустых блоков, проверка обязательных полей перед записью. Пустой item лучше залогировать и пропустить, чем сохранить мусор. Если Scrapy-проект начинает «сыпаться», первым делом режьте связность и добавляйте наблюдаемость: понятные имена полей, отдельные пайплайны, явные ошибки на пропавших данных. Тогда паук чинится за минуты, а не за вечер.