410 это ответ самого донора, а не блокировка парсера, поэтому настройками кеша его не обойти: модуль отбрасывает страницу по коду ответа ещё до разбора, хотя тело ответа уже сохранил в кеш.
Сначала стоит посмотреть, что именно лежит в кеше. Откройте тот файл, который он пишет (cache_page/4/800f435c....txt). Дальше два разных случая.
1. В файле полный HTML товара, с названием, ценой, характеристиками. Тогда донор отдаёт архивную страницу с кодом 410, но с нормальным содержимым, так часто помечают снятые с продажи позиции. Данные у вас уже на руках, мешает только код ответа.
2. В файле заглушка, редирект или короткая страница "товар удалён". Тогда донор действительно отдаёт разное содержимое роботу и браузеру.
Проверить, отличается ли ответ для браузера, можно прямо с сервера:
curl -s -o /dev/null -w "%{http_code}\n" "https://донор/product/355940/..."
curl -s -o /dev/null -w "%{http_code}\n" -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126 Safari/537.36" -e "https://донор/" "https://донор/product/355940/..."
Если во втором случае придёт 200, вопрос решается заголовками: подставьте в настройках модуля тот же User-Agent и Referer. Если 410 приходит в обоих случаях, а тело при этом полное, настройками парсера это не лечится: нужно либо чтобы модуль принимал 410 как валидный ответ, это уже к автору модуля, либо промежуточный скрипт, который забирает страницу и отдаёт её же с кодом 200, а модулю вы скармливаете ссылку на него.
И ещё вариант в обход всей истории: если архивные товары видны через поиск по сайту, страницы результатов поиска обычно отдают 200. Иногда проще собрать нужные позиции со страниц выдачи, чем воевать с кодом на карточке товара.
