Суть
1. Что это за аудит и зачем он нужен
SitePravo нужен в тот момент, когда владелец сайта уже понимает, что проблема может быть не в одной отдельной форме, а во всей связке сразу: документы, consent, внешние сервисы, cookie, реквизиты, обещания на главной и договорный контур. По отдельности это выглядит как «мелочи», а вместе превращается в реальный риск: жалобы, спорные лиды, слабый trust перед оплатой, претензии и неприятные вопросы при ручной проверке.
Поэтому сервис устроен как first-line аудит публичного контура. Он не притворяется персональной юридической консультацией и не маскирует автоматический слой проверки под глубокий технический аудит. Его задача другая: быстро и честно показать, что сайт обещает пользователю, что реально делает, где между этим появляется разрыв и какой следующий шаг даст наибольший эффект.
Для владельца сайта
Сервис помогает быстро понять, где у сайта юридические, compliance и trust-риски, и что исправить в первую очередь без долгой ручной расшифровки.
Для команды
Отчёт удобно передавать по ролям: юристу, разработчику, владельцу или маркетингу, без лишней ручной расшифровки findings и бесконечных «а что именно имелось в виду».
Для повторной проверки
Аудит фиксирует versioning, checked pages и findingSource, чтобы можно было сравнивать состояние сайта до и после исправлений и видеть, что реально изменилось.
Pipeline
2. Как SitePravo превращает URL в отчёт
Аудит начинается не с оценки, а со сбора фактов. Сначала нормализуется URL, проверяется доступность домена, выбирается канонический старт, собирается список checked pages и фиксируется crawl manifest. Уже на этом этапе важно не «угадывать» состояние сайта, а понять, какие страницы и сценарии реально попали в обход.
Дальше включается browser/runtime слой: он нужен не для красивой симуляции браузера, а для тех случаев, где HTML сам по себе недостаточен. Например, consent-баннер может быть в коде, но не управлять аналитикой; форма может выглядеть статичной, но отправляться через скрытый XHR-маршрут; policy может говорить одно, а public script contour — другое. После этого facts из документов, страниц, DNS, TLS и external services сопоставляются между собой, и только затем превращаются в signals, problem zones и top actions.
URL и обход
Стартовый адрес, каноникализация, ключевые страницы, checked pages и crawl manifest.
Browser и документы
Runtime-поведение cookies и форм, документы, внешние сервисы, публичные страницы.
Сигналы и problem zones
Rule engine собирает сигналы, группирует их в problem zones и показывает top actions.
Fix package
После отчёта пользователь получает отдельный слой с инструкциями, snippet-ами и post-fix checklist.
Процесс
3. Как проходит аудит
Нормализация и старт
Система определяет канонический URL, снимает базовые заголовки и формирует стартовый набор ключевых страниц. Это важно, чтобы не смешивать `http/https`, зеркала, старые пути и служебные редиректы.
Обход публичного контура
Движок обходит главную, документы, контакты, тарифы, отзывы, FAQ, блог и видимые service/account/checkout-сценарии. Мы сознательно остаёмся в публичной зоне и не пытаемся «выламывать» сайт изнутри.
Browser-level сценарий
Отдельный runtime-слой проверяет consent, cookies, storage, actionless/XHR-формы, внешние скрипты и поведение интерфейса. Это позволяет видеть не только текст на странице, но и то, как страница действительно ведёт себя для пользователя.
Сопоставление сигналов
Факты не оцениваются по одному. Документы, формы, реквизиты, DNS, TLS, cookies, claims и внешние сервисы сверяются между собой, чтобы отчёт ловил не только отсутствие чего-то, но и внутренние противоречия сайта.
Сборка отчёта
На выходе формируются summary, problem zones, top actions, checked pages и reproducibility-блок. Пользователь видит не просто найденный signal, а его место в общей картине сайта.
Архитектура
4. Какие слои есть у движка
Внутри SitePravo несколько разных слоёв, и это важно для качества результата. Если бы сервис опирался только на текст страниц, он пропускал бы runtime-проблемы форм и cookies. Если бы он смотрел только на browser-слой, ему было бы сложнее объяснять юридические и договорные противоречия. Поэтому текущая архитектура — это не один «большой детектор», а сочетание слоёв, у каждого из которых есть своя роль.
Rule-based ядро
Основной контур SitePravo. Именно он отвечает за детерминированные проверки, scoring и explainability.
- формы, согласия, privacy и legal-links;
- requisites, terms, e-commerce и cross-document consistency по оператору, email и реквизитам;
- Disify — верификация email-адресов на сайте: одноразовые/временные адреса (disposable) в реквизитах снижают доверие и нарушают требования к публичности контактных данных;
- language, marketing, content-risks и отраслевые ограничения;
- отдельные checks на marketing-consent split, English CTA / offer language и cross-document consistency.
Browser / runtime слой
Нужен там, где HTML недостаточно и важна реальная работа страницы.
- cookie-banner и consent paths;
- cookies, localStorage, sessionStorage;
- XHR-submit, hidden routes и runtime-формы.
Phase 5-6 stack
Этот слой усиливает текущие правила новыми источниками evidence и новыми deterministic-модулями legal-first проверки. Он не подменяет собой ruleset, а делает существующие выводы точнее, воспроизводимее и полезнее для внедрения.
- HTTP truth layer, WAF-awareness и URL-discovery;
- Исторические URL и поддомены — проверяем прошлое публичного контура;
- Извлечение текста из связанных PDF/DOCX — privacy policy, оферта, пользовательское соглашение;
- Маркировка рекламы (ERID) — deterministic проверка по 38-ФЗ: наличие токена и валидация формата (8–50 символов, alphanumeric + буквы); фиктивный токен — отягчающее по ФАС;
- Cookie dark patterns — проверка асимметричного дизайна: «Принять» кнопка vs «Отклонить» только ссылка (152-ФЗ ст.9, EDPB Guidelines 03/2022, п.40);
- Честный Знак — применимость для e-commerce с категориями маркированных товаров.
AI слой
Подключается точечно, когда нужен лучший контекстный анализ текста или спорных legal/compliance fragments.
- не заменяет rule engine;
- не нужен для простых deterministic checks;
- если AI недоступен, аудит продолжается и это явно помечается;
- все решения ИИ-слоя (confirm/downgrade/needs_manual_check) фиксируются в
aiReviewLog— полный audit trail для воспроизводимости.
Knowledge / reasoning слой
Phase 10 уже усилил движок слоем классификации сайта, контуром официальных источников и матрицей обязательности, чтобы отчёт не путал прямые обязанности, сценарные требования и рекомендации.
- business-type classification: `leadgen`, `catalog`, `ecommerce`, `services`, `content/media`, `saas`;
- requirement typing: `hard legal`, `scenario legal`, `technical`, `recommendation`;
- evidence typing: `text`, `registry`, `header`, `runtime`, `inference`, `manual check`;
- слой официальных источников: `152-ФЗ`, `ЗоЗПП`, fragment-level legal refs и factual РКН/registry reasoning;
- отдельная логика для ситуации, когда документ существует, но слабый, шаблонный или противоречит фактическому сайту;
- Wave 2 document provenance: quality-ladder для linked PDF/DOCX, OCR fallback и extraction trust вместо безымянного “документ найден”.
Отчётный слой
Результат должен быть не dump finding-ов, а документ, с которым можно идти в работу.
- web/PDF parity;
- problem zones и top actions;
- checked pages и evidence-база;
- fix package для следующего шага после аудита.
Направления
5. Что именно мы проверяем
Текущие 16 направлений удобнее читать не как длинную простыню правил, а через несколько product-кластеров. Так проще понять и владельцу бизнеса, и юристу, и разработчику, где именно лежит риск: в документах, в форме, в cookies, в trust-claims, в оферте, в корпоративном статусе или в публичных обещаниях сайта.
Документы, формы и ПДн
- policy, consent, legal freshness и legal-link resilience;
- data minimization by form purpose;
- публикация людей, отзывы, кейсы и распространение ПДн;
- requisites, operator identity и RKN-contour.
Здесь аудит проверяет не только наличие документа или checkbox, но и связность: совпадает ли policy с фактическим сайтом, виден ли оператор, описаны ли внешние сервисы, не собирает ли форма больше данных, чем нужно для своей цели.
Cookie и внешние сервисы
- consent paths и storage до/после выбора;
- analytics, maps, chat, CRM, payment и embed services;
- foreign processors и трансграничный след;
- AI/LLM-processors в публичном контуре.
В этом кластере особенно важен runtime: баннер может выглядеть аккуратно, но фактически не управлять загрузкой аналитики, рекламных скриптов или storage-ключей после выбора пользователя.
Продажа, trust и claims
- оферта, checkout, subscription и возвратный контур;
- marketing claims, dark patterns и pricing transparency;
- единообразие trust-контура: главная, методология, FAQ и публичные страницы;
- public promise vs technical reality.
Этот слой нужен не только для юриста. Он помогает увидеть, не обещает ли сайт одно, а фактически не делает другое, и не превращается ли продающий контур в источник спорных возвратов и недоверия перед оплатой.
Контент, отрасль и язык
- контентные правовые риски, официальные claims и trust-фразы;
- отраслевые ограничения, лицензии и обязательные предупреждения;
- язык интерфейса, англицизмы и brand-like формулировки в оффере;
- публичная коммуникация, которая может бить по доверию и прозрачности.
Этот слой нужен, чтобы сайт не создавал лишние претензионные, репутационные и регуляторные риски в текстах, офферах, карточках услуг и публичных обещаниях.
Безопасность и инфраструктура
- SSL-grade (A+/A/B/C/F) через SSL Labs API;
- TLS-версия, алгоритмы, срок истечения сертификата;
- security headers: HSTS, CSP, X-Frame, X-Content-Type, Referrer, Permissions-Policy;
- HSTS preload и cross-origin isolation;
- DNS-защита: SPF, DKIM, DMARC (политика основного домена и поддоменов), MTA-STS, DNSSEC, CAA;
- открытые сетевые порты и опасные службы (SSH, FTP, RDP, MongoDB и др.);
- репутация IP-адреса сервера по международным базам злоупотреблений;
- утечки секретов в публичном JS-коде (энтропийный анализ);
- JWT-токены с слабыми алгоритмами в публичном коде;
- качество security.txt по RFC 9116;
- Core Web Vitals: LCP, CLS, INP, FCP, TBT, Performance Score.
Слабая инфраструктура — это не только технический риск. Отсутствие HTTPS-enforce, открытые порты баз данных или слабая DNS-защита напрямую влияют на доверие пользователя, SEO и соответствие требованиям регулятора.
Корпоративный статус и публичные реестры
- ликвидация, процедура ликвидации и банкротство по ЕГРЮЛ (ФНС);
- дисквалифицированные руководители — реестр ФНС;
- cross-check ИНН на сайте с данными DaData/ФНС;
- реестр ОРИ, СМИ-ИА и новостных агрегаторов (РКН).
Сайт может работать от имени ликвидированной компании — критический риск для покупателей. Нахождение в реестре ОРИ накладывает отдельные обязательства, о которых владелец нередко не знает.
Домен и цифровая идентичность
- дата истечения домена (RDAP);
- регистратор и актуальность WHOIS-контактов;
- historical reputation и Safe Browsing статус;
- соответствие доменного имени и юридической идентичности оператора.
Истекающий домен — неочевидный, но высокий риск для доверия и непрерывности бизнеса. Проверка добавляет сигналы, которые владелец часто не отслеживает в рутине.
Финансовый сектор
- банки: лицензия ЦБ, информация АСВ;
- МФО: реестр ЦБ, ПСК, предупреждение о рисках;
- страхование, лизинг: лицензии и регуляторные реестры;
- кредитные брокеры: признаки мошенничества, реквизиты;
- коллекторы: реестр ФССП (230-ФЗ); ломбарды: реестр ЦБ.
Финансовый сектор — одна из самых жёстко регулируемых ниш. Отсутствие лицензии ЦБ или реестровых номеров — сигнал уголовной ответственности за незаконную финансовую деятельность (УК ст.172).
Медицина и здравоохранение
- клиники и медцентры: лицензия Росздравнадзора;
- косметология: инъекции (ботокс, филлеры) = медицинская лицензия;
- телемедицина: лицензия + информированное согласие пациента;
- аптеки: фармлицензия, запрет дистанционной продажи Rx;
- ветеринария: лицензия Россельхознадзора.
Медицинская деятельность без лицензии — УК ст.235. Инъекционная косметология и телемедицина требуют отдельных разрешений, о которых многие не знают.
Возраст и запрещённый контент
- алкоголь, табак, казино: обязательная верификация 18+;
- ссылки на ресурсы из реестра РКН;
- медицинские гарантии (лечит рак, без рецепта);
- финансовые пирамиды, бинарные опционы (запрещены ЦБ);
- товары для взрослых: возрастной гейт, дискретность.
Самые высокорисковые находки: ссылки на заблокированные ресурсы, продажа рецептурных препаратов онлайн или незаконные финансовые схемы могут привести к блокировке сайта и уголовной ответственности.
Специальные отрасли
- онлайн-образование: лицензия при выдаче сертификатов (273-ФЗ);
- туроператоры: реестр ФАТТ (РТО-ХXXX), финансовое обеспечение;
- гостиницы: классификация и звёзды (215-ФЗ);
- маркетплейсы: оферта продавца, комиссии, возвраты (закон 2024);
- застройщики: 214-ФЗ, эскроу, наш.дом.рф.
Образование, туризм, стройка и маркетплейсы — отрасли с отдельными законодательными требованиями, которые часто нарушаются по незнанию.
Маркировка и локализация данных
- интернет-реклама: обязательная маркировка erid (38-ФЗ, с 2022);
- товары Честный Знак: лекарства, молочка, обувь, одежда, табак;
- локализация ПДн (242-ФЗ): иностранный хостинг + формы = сигнал;
- платёжные системы: 54-ФЗ, ОФД, самозанятые и Мой налог.
Маркировка рекламы erid — массовое нарушение 2022-2026, о котором многие сайты ещё не знают. Штраф до 500 000 руб. за каждый немаркированный материал.
Отчёт
6. Как читать результат аудита
Старый формат «длинная лента finding-ов» редко помогает владельцу сайта что-то внедрить. Из него трудно понять, какие проблемы связаны между собой, что даст быстрый эффект, кому именно это передать и что можно закрыть одним большим решением. Поэтому в Report V2 логика чтения меняется: сначала summary и problem zones, потом top actions, а уже затем checked pages, evidence-база и полный список сигналов.
Сначала диагноз
Отчёт начинается с summary, общего балла, количества сигналов, problem zones и top actions. Это верхний уровень для владельца и управленческого чтения.
Потом приоритет
Вместо длинного списка однотипных finding-ов сервис сначала показывает крупные проблемные зоны и действия, которые закрывают несколько рисков сразу.
Потом приложение
Checked pages и evidence-база остаются доступными для разработчика, юриста и повторного контроля, но больше не ломают читаемость отчёта и не мешают первому решению.
Аудитируемость
7. Что сохраняем для повторной проверки и explainability
Прозрачность для нас — это не только красивое объяснение текста finding-а. Важно, чтобы пользователь понимал, что именно было проверено, на каких страницах, каким способом и из какого источника пришёл сигнал. Поэтому audit-result хранит не только итоговые выводы, но и слой воспроизводимости: checked pages, crawl manifest, findingSource, версии движка и ruleset, а для части сигналов — extraction method. Начиная с текущего runtime slice Волны 2, document-heavy evidence получает и нормализованный provenance-слой: `documentParsingProfile`, `trustBand`, `confidenceBand`, `parserReason`, `ocrUsed`, `ocrMode`.
Checked pages
Показывают, какие URL реально попали в обход. Это помогает понять, был ли найденный сигнал взят с продающей страницы, policy, FAQ, технического маршрута или просто типового alias-path.
Finding source
Показывает, из какого контура пришёл вывод: browser runtime, HTML, headers, DNS, WHOIS, historical discovery, subdomain discovery, PDF extraction или document parsing. Для linked legal docs теперь доезжают и trust/confidence поля extraction-контура. Это снижает ощущение «чёрного ящика» и помогает вручную перепроверять сложные случаи.
Crawl manifest
Фиксирует, сколько страниц было найдено, обойдено, отклонено лимитом, заблокировано robots/noindex/canonical или не успело ответить. Для бизнеса это не просто техничка: так видно, не спрятан ли важный документ или раздел слишком глубоко.
Версии движка
В результате сохраняются engineVersion и rulesetVersion. Это делает сравнение «до и после исправлений» честнее и не смешивает выводы разных версий движка в один безымянный балл.
После аудита
8. Как выводы переходят в реальные задачи
Смысл аудита не в том, чтобы выдать красивый список проблем, а в том, чтобы сократить путь до внедрения. Поэтому после summary и problem zones пользователь получает следующий слой: fix package. Он раскладывает задачи по ролям, показывает, что можно копировать почти как есть, где нужна адаптация под стек, а где лучше не обходиться без юрпроверки.
Fix package
- полный пакет исправлений после аудита;
- problem-zone grouping и role-based blocks;
- статусы: готово к вставке, нужна адаптация, требует юрпроверки;
- post-fix checklist и точечные переходы из finding-ов.
Deterministic templates
Для типовых проблем сервис подбирает remediation snippets: consent blocks, legal footer scaffolds, privacy inserts, cookie-инструкции и другие опорные шаблоны для legal-first исправлений.
Переход по ролям
Юрист получает документы, consent и operator-blocks. Разработчик — forms, cookies, integrations и routes. Владелец — очередность шагов и бизнес-эффект. Маркетинг — claims, реклама, language и trust consistency.
Повторная проверка
После внедрения аудит можно повторить и сравнить problem zones, checked pages и оставшиеся сигналы. Это закрывает цикл от диагностики к проверке результата.
Ограничения
9. Где граница автоматической проверки
- автоматический аудит не заменяет персональную юридическую экспертизу;
- закрытые кабинеты, внутренние процессы и договоры без доступа не видны автоматике;
- часть legal и content-выводов требует ручного контекстного просмотра;
- регистрация в реестрах, внутренние согласия сотрудников, внутренняя логика хранения логов и договорная база требуют ручную проверку;
- мы не проводим brute force, не эксплуатируем уязвимости и не делаем pentest.
Итог: SitePravo нужен для того, чтобы быстро и честно показать владельцу сайта, где у него риски, почему они важны и что исправить первым. Дальше — либо повторный аудит, либо ручной разбор с юристом и разработчиком по уже собранным evidence и checked pages.
Связанные материалы
10. Где почитать подробнее
Версия
11. Текущая версия движка
650+ параметров, 16 направлений. Движок охватывает правовой и договорный контур, cookie и внешние сервисы, реквизиты и корпоративный статус, отраслевые ограничения (финансы, медицина, возраст, образование, туризм, строительство, маркетплейсы), маркировку рекламы и локализацию данных. Каждому нарушению присваивается Trust Grade (A+/A/B/C/D/Критический) с описанием закона, возможного штрафа и следующего шага.
Движок работает в несколько слоёв: статический анализ страниц и документов, браузерный runtime (формы, consent, cookies, storage), внешние проверки (реестры ФНС, РКН, доменная идентичность, SSL, безопасность ссылок), база знаний с 429+ правилами (КоАП, 152-ФЗ, ЗоЗПП, отраслевые НПА) и AI-слой для спорных legal/compliance мест. Для форм, связанных HTML/PDF/DOCX-документов и публичных реестров используются специализированные парсеры. Все выводы сопровождаются источником сигнала и уровнем уверенности. Отчёт не является юридическим заключением.
Ключевые улучшения (02.06.2026): +5 новых проверок (mobile viewport zoom, adaptive images, BreadcrumbList, H2-вопросы, TL;DR). SSL-INFO: срок SSL теперь всегда виден в отчёте. Исправлен ложный positive Bitrix. CSP: только script-src unsafe-inline снижает оценку. Улучшены фильтры Nikto.
Ключевые улучшения (03.06.2026): ENG-RKN-LIVE — живой сетевой зонд на блокировки РКН/ТСПУ (DNS poisoning, TCP reset, TLS DPI по SNI, ISP stub-страница). Дополняет статический реестр РКН. Исправлено 3 ложных срабатывания: X-Frame-Options при наличии CSP frame-ancestors, /404 как сломанная страница, дублирующий чек llms.txt. Запущена staging-среда (общая с AuditGuard): патчи проходят тестирование на staging перед релизом в prod. P1-SP (03.06.2026): расширена ФАС-маркировка — новый finding при ERID в коде без видимого текста «Реклама» рядом с RTB-блоком; добавлены паттерны Adfox, Criteo, Programmatic. ОКВЭД из dadata — при лицензируемой отрасли (медицина, финансы, строительство, образование) и отсутствии лицензионных документов на сайте — medium-finding.
Обновление (03.06.2026, сессия 6): Инфраструктурные улучшения общего движка: стабилизация nginx-конфигурации (удалены дублирующие server-блоки и устаревшие bak-конфиги), диагностика и верификация всех P0/P1 фич (16/16 проверок прошли). Staging-среда подтверждена: /staging-api/ работает по HTTPS. Параметров в движке: 578+ (добавлены P1-SP-1 и P1-SP-2 как самостоятельные направления проверки).
Обновление (03.06.2026, сессия 7): WCAG 2.2 коды критериев — доступность теперь отображает конкретные номера WCAG 2.2 (1.4.4, 2.4.11, 2.5.7 и др.) для каждого нарушения в отчёте SitePravo. Коды выводятся синими чипами в карточках рисков. JS-фреймворк fingerprinting — движок определяет не только платформу (Next.js, Vue SPA, React SPA, Angular SPA, WordPress и др.), но и версию фреймворка, сохраняет в поле jsFramework результата для снижения ложных срабатываний. NVD API 2.0 CVSS v3 — при наличии CVE из CISA KEV или Shodan, движок автоматически запрашивает CVSS v3 баллы из базы NVD (services.nvd.nist.gov) и добавляет их в тексты находок (например: «CVE-2023-1234 [CVSS 3.1=9.8]»). Версионирование методологии — каждый аудит теперь сохраняет methodology_version и engine_version в БД для аудиторского следа. Версия методологии: 2026.06.1.
Обновление (03.06.2026, сессия 8): Legal diff v2 (P2-SP-2) — добавлена проверка 4 обязательных структурных разделов в политике обработки ПДн по 152-ФЗ/GDPR: «Цели обработки», «Сроки хранения», «Права субъекта», «Правовое основание». Отсутствие 2+ разделов → high[documents], 1 раздел → low[documents]. Cookie scanner v2 (P2-SP-3) — классификация cookie по категориям: аналитические (_ga, _gid, _ym, hjid...), маркетинговые (_fbp, _tt_, gcl_...), функциональные (lang, currency, theme...), необходимые (session, csrf, auth...). При наличии аналитических/маркетинговых без разделения категорий в баннере → medium[cookies]. Consent Mode v2 (P2-SP-4) — если обнаружены Google Analytics/GTM, но отсутствует gtag('consent','default',{ad_storage:'denied',...}) до загрузки скриптов → medium[cookies]. Аналогично для Meta Pixel и Яндекс Метрика. Confidence contract (P2-AG-9) — все findings теперь содержат businessImpact, effort, falsePositiveRisk.
Обновление (04.06.2026, сессия 11): Законодательные риски — новое 16-е направление. Добавлено 4 новых проверки: P3-SP-22 «Спецкатегория ПДн» — медицинские сайты, собирающие данные о здоровье без отдельного согласия по ст. 10 152-ФЗ — high[legal]. P3-SP-25 «ПСК/полная стоимость кредита» — кредитные и МФО-сайты без раскрытия диапазона ПСК по ФЗ-353 (ст. 6) — medium[legal]. P3-SP-26 «Предупреждение об инвест-рисках» — инвестиционные/брокерские/крипто-сайты с обещанием доходности без дисклеймера по 39-ФЗ (ст. 3) — medium[legal]. P3-SP-24 «Навязывание допуслуг» — pre-checked чекбоксы в checkout/cart/product (страховка, гарантия, экспресс-доставка) без явного согласия по ЗоПП ст.16 + ПП РФ №2463 — high[marketing]. Регрессионные тесты: 52. Параметров: 610+. Версия методологии: 2026.06.2.
Обновление (04.06.2026, сессия 12): Тематический классификатор + 6 отраслевых блоков. Добавлен автоматический топик-профиль сайта (по ОКВЭД, ключевым словам, домену) → 6 score-оценок: medical / finance / ecommerce / adult / media / advertising. На его основе запускаются отраслевые блоки проверок: P6-MEDICAL — 323-ФЗ + 38-ФЗ ст.24 (лицензия клиники, предупреждение о противопоказаниях, гарантии излечения, реклама Rx-препаратов) — 4 проверки legal[high/critical]. P7-ERID — 38-ФЗ ст.18.1 (маркировка интернет-рекламы: ERID-токен ОРД, пометка «Реклама») — 2 проверки. P8-ADULT — 436-ФЗ + 394-ФЗ (age-gate 18+, возрастная маркировка, LGBT-пропаганда) — 3 проверки legal[medium/critical]. P9-ECOMMERCE — 2300-1-ФЗ + ПП №612 (публичная оферта, политика возврата, страна производителя, сроки доставки, цены в рублях) — 5 проверок legal[medium/high]. P10-MEDIA — 2124-1 (главный редактор, учредитель, маркировка иноагента, возрастная маркировка контента) — 4 проверки. P11-FINANCE — 353-ФЗ + 38-ФЗ ст.28 (лицензия ЦБ РФ / реестр МФО, ПСК, ложный 0%, гарантии доходности) — 4 проверки. Итого новых проверок: 22. Параметров: 650+. Версия методологии: 2026.06.4.
Обновление (04.06.2026, сессия 12б): Улучшения по ТЗ 2.x. 2.1 — Логирование согласия: finding переработан в рекомендацию с пометкой «Сервер может фиксировать IP/дату/версию согласия на своей стороне — это не проверяется автоматически». 2.2 — Геолокация сервера (152-ФЗ ст.18): основной IP вне РФ при наличии форм сбора ПД → legal[high]; CDN/edge вне РФ → legal[medium] (с manualReview). 2.4 — Отзыв согласия (152-ФЗ ст.9 ч.2): нет выделенного механизма → legal[medium]; только упоминание без формы → legal[low]. 2.5 — Дата политики ПД: политика старше 2024 г. → documents[medium]; дата не указана → documents[low]. Итого 5 новых проверок. 2.3 — SPA Playwright: в tryPlaywrightRenderedSnapshot добавлен waitForSelector("footer, .footer, [role=contentinfo]") до парсинга футера; в tryPlaywrightFormConsentAudit добавлена эмуляция ввода в первое поле формы (click + keyboard.type) для появления ленивых чекбоксов согласия. Параметров: 650+. Версия методологии: 2026.06.4.