ТЗ на парсер сайтов: источники, схема данных и приёмка

Требования к парсеру: разрешённые источники, поля, обновление, контроль ошибок, выгрузка и проверка качества. Скачиваемый шаблон ТЗ.

Авторский цветной постер: «ДАННЫЕ ПО ПРАВИЛАМ»
Авторский цветной постер: «ДАННЫЕ ПО ПРАВИЛАМ»Редакция Малевич · 8 мин

Сначала определите результат сбора

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

Укажите, кто получает выгрузку, куда она загружается и что происходит при отсутствии свежих данных. Отдельно определите допустимость работы с выбранными источниками: условия использования, разрешения, ограничения доступа и состав информации. Открытость страницы сама по себе не означает разрешения на любое дальнейшее использование её содержимого. Для спорного источника сначала получите согласование, затем включайте его в объём разработки.

Паспорт источника и границы доступа

Для каждого домена запишите владельца, тип страниц, доступный API или экспорт, необходимость авторизации и действующие ограничения. Если есть официальный интерфейс получения данных, сравните его с разбором HTML. API не обязательно содержит все нужные поля, но может дать более устойчивую структуру и понятный договор доступа. Решение должно опираться на проверку конкретного источника.

robots.txt описывает правила обхода для роботов; RFC 9309 отдельно указывает, что этот механизм не является авторизацией доступа. В требованиях учитывайте и технические правила, и условия использования. Парсер не должен обходить CAPTCHA, закрытую область или запрет доступа. При неожиданном ограничении предусмотрите остановку и обращение к владельцу источника, а не бесконечное увеличение числа запросов.

Согласуйте частоту, параллельность, интервалы повторов и контакт для технических вопросов. Ответ об ограничении частоты должен уменьшать нагрузку согласно правилам источника. Учтите часы работы и объём страниц, а не только желаемую скорость полного обхода. Устойчивый сбор предполагает контролируемую нагрузку и понятные причины остановки.

Схема записи и значение пустого поля

Для каждого поля нужны название, тип, единица измерения, обязательность, источник и пример. Цена без валюты, срока действия и указания варианта товара часто непригодна для сравнения. Остаток «доступно» не равен точному количеству. Дата должна иметь понятный часовой пояс, а числовое значение — правила десятичного разделителя и округления.

Различайте «поле отсутствует на странице», «не удалось извлечь», «не применимо» и «значение действительно пустое». Если записать во всех случаях ноль, система может принять ошибку сбора за бесплатный товар или отсутствие остатка. Храните статус извлечения рядом с данными и не подменяйте неудачу правдоподобным значением по умолчанию.

У записи должны быть устойчивый идентификатор, исходный URL и время наблюдения. Название товара редко подходит на роль ключа: оно меняется и повторяется. Опишите варианты, комплекты и связь карточки с предложениями. Для объединения нескольких источников отдельно задайте уверенность сопоставления и ручную проверку спорных пар; совпадение похожих заголовков не является достаточным доказательством.

Обновление, исчезновение и повторный обход

Решите, хранится ли только последнее состояние или история изменений. Для мониторинга цены важны дата наблюдения и прежнее значение; для одноразового каталога история может быть избыточной. Отдельно задайте срок хранения сырого ответа и возможность воспроизвести спорную запись, учитывая объём и допустимость хранения источника.

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

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

Контроль изменений страницы

Разметка источника может измениться без предупреждения. Проверяйте не только HTTP 200, но и наличие ключевых признаков нужного типа страницы. Вместо карточки сервер иногда возвращает сообщение об ограничении или пустой шаблон. Такой ответ нельзя считать успешной записью только потому, что сетевой запрос завершился.

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

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

Формат выгрузки и проверка потребителем

Согласуйте CSV, JSON, базу или API, кодировку, разделитель, заголовки, порядок полей и версию схемы. Пример файла должен открываться в системе получателя. Для табличного экспорта учитывайте строки, начинающиеся со специальных символов: внешние значения не должны неожиданно исполняться как формулы при открытии. Правило обработки таких данных фиксируется явно.

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

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

Учебный пример приёмки

Возьмите разрешённый контрольный набор карточек: обычная цена, старая и новая цена, несколько вариантов и отсутствующая цена. Для каждой карточки вручную зафиксируйте ожидаемые поля. Сравните результат парсера построчно. Ошибка выбора старой цены вместо текущей должна обнаруживаться отдельно от ошибки валюты и отдельно от пропуска всей карточки.

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

Измеряйте полноту по согласованному набору, корректность полей, свежесть и долю ошибок, а не просто число скачанных страниц. В знаменателе каждой метрики укажите, какие записи учитываются. Стабильное извлечение названий не компенсирует неверную цену, если именно цена определяет бизнес-решение. Критические поля оцениваются отдельно.

Что передать для оценки разработки

Подготовьте перечень источников и разрешений, схему записи, примеры страниц, объём, частоту, формат результата и контрольный набор. Отдельно обозначьте динамическую загрузку, историю изменений, сопоставление между источниками и поддержку после изменения разметки. Эти обстоятельства влияют на объём сильнее, чем общее название «парсер сайта».

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

Источники

  1. RFC 9309: Robots Exclusion Protocol

    IETF / RFC Editor / доступ 2026-10-07

    Стандарт правил обхода; robots.txt не является механизмом авторизации.

  2. CSV Injection

    OWASP Foundation / доступ 2026-10-07

    Риски формул при экспорте внешних значений в электронные таблицы.

  3. Скачать шаблон брифа / ТЗ (.txt)

    Малевич — практическое приложение / доступ 2026-10-07

    Заполняемый авторский шаблон к этой статье. Сохраните текстовый файл и внесите исходные данные проекта.

FAQ

Можно ли считать HTTP 200 успешным сбором?

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

Что делать при CAPTCHA или запрете доступа?

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

Как принимать полноту выгрузки?

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

Сделайте следующий шаг.

Разберём, как применить выводы из материала к вашему продукту, процессу или системе.

Обсудить проект