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

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

Чаще всего проблемы не в парсинге, а в дисциплине проекта:
— не отделён parsing от storage;
— в item-processor тащат тяжёлую логику;
— селекторы завязаны на один шаблон верстки;
— retry и таймауты настроены «по умолчанию»;
— логирование не показывает, где именно пропали данные.

Для живого паука полезно держать три слоя: получение ответа, извлечение полей, запись результата. Если в spider уже есть нормализация, дедупликация и работа с БД — при первом изменении HTML вы чините сразу всё, а не один участок. Это особенно больно в проектах, где данные идут в ETL или CRM.

Ещё одна типовая ошибка — ждать, что CSS/XPath селекторы будут жить вечно. Надёжнее собирать их по смысловым признакам: атрибуты, стабильные контейнеры, fallback-ветки для пустых блоков, проверка обязательных полей перед записью. Пустой item лучше залогировать и пропустить, чем сохранить мусор.

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