В типовом разговоре с учебной частью вуза или колледжа всегда наступает момент, когда мы говорим: «Нам не нужны выгрузки из вашего 1С, не нужны интеграции с электронным журналом, не нужно ничего переделывать. Мы возьмём данные с того сайта, который у вас уже есть». Дальше — недоверие. Расскажем технически, как это работает.
Зачем вообще парсинг, а не интеграция
Стандартный подход к работе с расписанием выглядит так: «Давайте мы получим доступ к вашей системе планирования, выгрузим оттуда XML/JSON, импортируем к себе, синхронизируем при изменениях». Звучит правильно — но в реальности упирается в три проблемы.
Проблема 1: систем расписания у вузов десятки. Кто‑то на 1С:Колледж, кто‑то на самописной системе, кто‑то на Excel, кто‑то на бесплатных продуктах региональных министерств. Делать интеграцию под каждую — это месяцы работы перед запуском.
Проблема 2: получить доступ к системе непросто. Это IT‑отдел, согласования, договор о работе с базой, инструктаж, тестовые контуры. Реальные сроки на одно учреждение — от 2 до 6 месяцев.
Проблема 3: даже после интеграции вы дублируете данные. Учебная часть продолжает работать с исходной системой, у вас лежит копия, которая может «отставать». Конфликт версий обеспечен.
Парсинг сайта эти проблемы обходит. Сайт у вуза или колледжа уже есть. Сайт уже работает. Сайт уже обновляется в нужном темпе. Нам нужно только научиться его читать.
Что мы реально делаем технически
Шаг 1: понимание структуры
Мы открываем ваш сайт расписания и смотрим, как он устроен. Это ручная работа — на типичное учреждение уходит 2–4 часа аналитика. Цель — понять:
- где лежит расписание (URL‑паттерн, параметры);
- в каком формате (HTML‑таблица, JSON‑эндпоинт, PDF‑файл);
- как закодированы группы, преподаватели, аудитории, время;
- какие сокращения используются, чем заполняются «окна»;
- когда происходят обновления, как помечаются замены.
Если сайт нестандартный или с защитой от парсинга — обсуждаем с IT‑отделом учреждения, как корректно получать данные (whitelist нашего IP, выделенный read‑only эндпоинт и т. д.).
Шаг 2: написание адаптера
Под каждый тип сайта мы пишем небольшой адаптер — TypeScript‑модуль на 200–500 строк. Он отвечает за извлечение структурированных данных. Логика обычно простая:
- Достать HTML/JSON со страницы расписания.
- Раскрыть его по правилам конкретного сайта (Cheerio для HTML, стандартные парсеры для JSON, специальные библиотеки для PDF).
- Привести к единому формату — список занятий с полями: группа, день, время, предмет, тип (лекция/семинар), преподаватель, аудитория.
- Отловить аномалии: пропущенные поля, неизвестные сокращения, несовпадение типов.
Этот адаптер тестируется на всём диапазоне реальных страниц вашего сайта — каждая группа, каждый курс, каждая специальность. Если где‑то падает — дорабатываем.
Шаг 3: автоматическая синхронизация
После того как адаптер написан и проверен, мы настраиваем cron, который ходит на ваш сайт по расписанию (по умолчанию — раз в час, чаще не нужно, чтобы не нагружать). При изменении в исходном расписании наша внутренняя база обновляется автоматически.
Если кто‑то в учебной части в 23:50 утвердил замену и обновил сайт — через час максимум это окажется в боте. Если нужно быстрее — есть webhook‑вариант, при котором ваша система оповещает нас явно после обновления.
Шаг 4: мониторинг и алерты
Структура сайта может измениться. Учебная часть переименовала раздел, IT‑отдел поменял шаблоны страниц, кто‑то добавил CAPTCHA. Чтобы не оказаться в ситуации «бот молча отвечает старыми данными», мы мониторим работу адаптеров и алертим себя при ошибках:
- если адаптер не смог распарсить страницу — мы видим это в первые 5–10 минут;
- если в данных пропали группы или преподаватели — алерт о подозрительной потере данных;
- если сайт недоступен дольше часа — отдельное оповещение, потому что это либо сбой у вас, либо проблема инфраструктуры.
В каждом случае мы оперативно дорабатываем адаптер. В типичном учреждении — 1–3 правки в год, обычно после серьёзных изменений на сайте или в начале учебного года.
8 типов сайтов, которые мы видели
За полгода работы мы прошли через несколько архетипов сайтов расписания:
- HTML‑таблица, отрендеренная сервером. Самый простой случай: парсер на Cheerio, чистый CSS‑селектор → DOM → структура.
- JavaScript SPA, рендерится на клиенте. Нужен headless‑браузер (Playwright). Дольше, но решаемо.
- API endpoint, который отдаёт JSON. Идеально — парсер тривиальный. Только нужно понять, как его правильно вызывать.
- PDF, обновляемый раз в неделю. Парсим через pdf‑lib + распознавание таблиц. Сложно, но реально.
- Excel‑файл на FTP. Открываем через библиотеки, извлекаем по координатам ячеек.
- iframe со сторонним сервисом. Идём в сторонний сервис напрямую, иногда там есть открытый API.
- Раздел «Студенту» с несколькими URL на курс. Просто больше работы по составлению маппингов. Парсер тот же.
- Полностью кастомное. Бывает. Тогда — обсуждение с IT‑отделом и решение под конкретный кейс.
А что если сайт изменится
Самый частый страх: «Вы подключитесь, а наш IT‑отдел через полгода переделает сайт расписания». Реальность:
- Большие переделки бывают редко. Раз в 2–3 года у крупных вузов, реже у колледжей.
- Маленькие правки автоматически отлавливаются. Мы их видим за 5–10 минут и правим адаптер за день.
- Большие переделки требуют переписать адаптер. Это 1–3 дня работы, обычно укладывается в стандартное обслуживание без доп. оплаты.
- Если хотите подстраховаться — можно подключить второй источник данных (например, тот же XML‑экспорт из 1С как fallback). Тогда даже при поломке сайта бот будет работать.
Что в итоге
Подключить расписание через парсинг существующего сайта — технически правильное решение для большинства учебных заведений в 2026 году. Один адаптер, час работы аналитика, ноль изменений в инфраструктуре учреждения. Готовый бот за 1–2 недели «под ключ».
Если у вашего вуза или колледжа сайт расписания «странный» — это не блокер. У нас уже есть опыт с PDF, SPA, FTP, iframe и кастомными системами. Любая страница, которую можно открыть в браузере, — это страница, которую может прочитать наш парсер.
Оставьте заявку — обсудим конкретно ваш сайт. По первой ссылке сможем сказать, какой это тип, сколько займёт настройка и есть ли подводные камни.