Обсяг аудиту

Що робить сканер

FluxRadar виконує HTTP(S)-запити до публічного сайту й фіксує відповіді та DOM. Security у Complete також перевіряє TLS-сертифікати та публічні TXT-політики DNS. Знахідки посилаються на отримані докази; недоступні дані залишаються неперевіреними, а не вважаються успішним результатом.

Сканер дотримується директив robots.txt. Для безкоштовної перевірки головної сторінки завантажується лише кореневий URL. Платні перевірки поширюються на повʼязані публічні сторінки в межах налаштованої області.

SEO — що перевіряє FluxRadar

Модуль SEO виконує до 24 детермінованих перевірок, складених за документованими рекомендаціями пошукових систем (Google Search Central, Bing Webmaster Guidelines, schema.org). Усі перевірки засновані на правилах; жодного висновку моделі тут немає.

• Мобільний viewport — За статичним HTML повідомляємо про відсутній viewport або viewport без width=device-width.
• Ресурси відображення — Биті стилі, скрипти й попередньо завантажені шрифти свого сайту перевіряються окремо від медіа: до 100 проб. Зовнішні CDN і шрифти всередині CSS не входять; неперевірені ресурси не є знахідками.
• Тег title — наявність, довжина — у звіт потрапляє коротший за 10 або довший за 70 символів — та унікальність серед обійдених сторінок: заголовок, який уже має інша обійдена сторінка, потрапляє у звіт, якщо <link rel="canonical"> не пов’язує ці сторінки між собою.
• Meta description — наявність, довжина — у звіт потрапляє коротший за 50 або довший за 160 символів — та унікальність серед обійдених сторінок, за тим самим правилом, що й title.
• Ієрархія заголовків — рівно один H1 і жодного пропущеного рівня вниз (h1 → h3 без h2 між ними). Повернення до вищого рівня — норма і у звіт не потрапляє.
• Канонічний URL — <link rel="canonical"> присутній, не продубльований і вказує на саму сторінку.
• Сигнали індексації — noindex у meta robots або в заголовку X-Robots-Tag, і лише там, де сайт суперечить сам собі: сторінка є в мапі сайту або на неї ведуть інші сторінки. Свідомий noindex на сторінці, на яку ніщо не посилається, — рішення власника, а не знахідка. nofollow не перевіряється.
• robots.txt — чи доступний файл і чи блокує він Googlebot або Bingbot на стартовій сторінці. Відсутній файл і блокування пошуковиків — окремі перевірки.
• XML-мапа сайту — мапу сайту знайдено — за директивами robots.txt або за адресою /sitemap.xml — і вона дає хоча б один URL. Недосяжна, зіпсована й порожня на цьому рівні — один вердикт: сайт не дає жодного URL із мапи.
• Структуровані дані / JSON-LD — кожен блок <script type="application/ld+json"> розбирається як JSON, і хоча б один блок має і @context, і @type. Окремі типи schema.org та їхні обовʼязкові властивості не валідуються.
• Теги соціального перегляду — og:title, og:description, og:image, og:url і twitter:card присутні й не порожні у відданому HTML. Сам URL зображення не завантажується.
• Alt-текст зображень — змістовні зображення без непорожнього атрибута alt.
• Биті посилання — внутрішні href, чию ціль обхід справді завантажив і застав із відповіддю 4xx або 5xx. Посилання, за яким обхід не пішов — поза областю, за лімітом сторінок, закрите robots.txt, — має невідомий статус і не оцінюється.
• Ланцюжки редиректів — два й більше переходи до фінальної відповіді або цикл редиректів. Один 301 — звичайна канонізація і у звіт не потрапляє.
• Внутрішня перелінковка — сторінки, які є в XML-мапі сайту, але на які не веде жодна обійдена сторінка, і сторінки, доступні лише через одне внутрішнє посилання. Посилання з редиректом зараховується сторінці, на яку воно веде.
• Глибина кліків — скільки переходів за посиланнями відділяють сторінку від точки входу — за посиланнями, які прочитав обхід; чотири й більше позначаються.
• Коли ці три перевірки виконуються — лише тоді, коли обхід дочитав сторінки, які збирався прочитати. Обхід, зупинений лімітом сторінок або сторінкою, що не відповіла, не відрізнить сторінку без посилань від непрочитаної — і кожна перевірка так і повідомляє, замість вгадувати. Посилання, яке виключила сама область перевірки (інший хост, виключений шлях, крок за межею глибини), пропуском не вважається: такої сторінки в області й не було.
• Змішаний контент — скрипт, стиль, зображення, iframe або іконка з http://, вбудовані в HTTPS-сторінку. Чи редиректить сайт з HTTP на HTTPS, окремо не перевіряється.

AI SEO / Generative Engine Optimisation

AI-системи пошуку (ChatGPT, Gemini, Perplexity, Claude, Bing Copilot тощо) використовують публічний вміст вебу та власні індекси. FluxRadar перевіряє публічно спостережувані сигнали, які впливають на те, чи зрозуміють і чи процитують ваш сайт такі системи.

• Доступ AI-краулерів — robots.txt перевіряється для дванадцяти агентів. AI-пошук і відповіді: OAI-SearchBot, Claude-SearchBot, PerplexityBot, ChatGPT-User, Claude-User та Perplexity-User. Навчання моделей: GPTBot, ClaudeBot, Google-Extended, Applebot-Extended, CCBot і Bytespider. Блокування навчання не впливає на появу в AI-пошуку. Це політика, а не доказ доступу, індексації чи цитування; запити користувачів можуть ігнорувати robots.txt.
• Теги соціального перегляду — скільки обійдених сторінок мають повний набір тегів перегляду (og:title, og:description, og:image, og:url, twitter:card), за якими AI-система або месенджер складає опис посилання. Ті самі теги посторінково перевіряє модуль SEO.
• Структуровані дані для розуміння AI — скільки обійдених сторінок мають хоча б один блок JSON-LD одночасно з @context і @type — мінімум, за яким AI-система читає сторінку як сутність, а не як суцільний текст. Конкретні типи (Organization, Product, FAQPage тощо) окремо не вимагаються й не оцінюються.
• Сигнали ясності тексту — чи має сторінка щонайменше 200 символів видимого тексту разом із заголовком (<h1> або <h2>) і контейнером вмісту (<main>, <article> або <body>) — базовий мінімум, потрібний AI-краулеру, щоб узагалі щось видобути зі сторінки. Саму оцінку читабельності (Flesch Reading Ease для англійського тексту, адаптація Оборнєвої для українського) вимірює й показує перевірка «Оцінка читабельності» модуля «Якість контенту».
• Видимість у провайдерів (платно, із повідомленням перед оплатою) — у платному аудиті модуль AI SEO ставить ті самі запитання Claude (Anthropic) і ChatGPT (OpenAI) та перевіряє, чи згадують відповіді ваш бренд і чи цитують сайт; звіт показує джерела, якими скористалася кожна модель. На пошукові запитання про ваш ринок моделі відповідають з увімкненим власним вебпошуком. Фіксовані прямі запитання про ваш бренд ставляться closed-book — без пошуку й без інструментів, щоб відповідь показувала те, що модель уже знає, а не те, що вона щойно прочитала на вашому сайті. Gemini (Google) і Perplexity — необовʼязковий вибір перед оплатою, інакше вони не отримують нічого. У безкоштовній перевірці головної сторінки цей крок не виконується ніколи. Запити до API провайдерів підпорядковані їхнім власним умовам.
• Оцінка видимості за системами (платно, лише інформаційна) — кожна система, яка відповіла, отримує оцінку від 0 до 100, зібрану щонайбільше з двох сигналів: як часто вона згадувала ваш бренд (60%) і як часто вона посилалася на ваш домен (40%). Знаменник кожного — це не кількість відповідей, а кількість відповідей, у яких цей сигнал взагалі можна було зміряти. Питання, яке само назвало ваш бренд, або профіль, у якого бренд — це просто домен, нічого не доводять і не рахуються ні як згадка, ні як промах. Щоб сигнал зарахувався в оцінку, потрібно щонайменше 2 зміряні відповіді; якщо зарахувався лише один сигнал, оцінка складається тільки з нього; якщо жодного, звіт показує лічильники й прямо про це каже, а не друкує число. Ця оцінка лише інформаційна: це знімок одного прогону, вона ніколи не входить у загальну оцінку аудиту й не є рейтингом.
• Частка голосу (платно, лише інформаційна, необовʼязково) — якщо ви вкажете до 5 назв конкурентів у профілі сайту, картка кожної системи покаже ще й частку голосу: скільки згадали ваш бренд проти кожного конкурента, на тих самих зміряних відповідях, які вже використовує оцінка видимості вище. Назви конкурентів звіряються зі збереженими відповідями цього сканування лише на серверах FluxRadar і ніколи не надсилаються AI-провайдеру. Якщо конкурентів не вказано, звіт показує примітку замість частки.

Безпека — публічний профіль OWASP ASVS

FluxRadar читає публічний профіль OWASP Application Security Verification Standard (ASVS): ту частину сигналів ASVS, яку видно в публічній HTTP-відповіді. Він не намагається експлуатувати вразливості, досліджувати захищені входом поверхні чи виконувати активні атаки.

Ці вісім перевірок — це весь модуль безпеки. Сигнал, якого немає в списку — узгоджена версія TLS, селектори DKIM, відкриті файли, лістинг каталогів, debug-endpoint-и, секрети в клієнтському коді, версії залежностей, — не досліджується, і звіт про нього не каже нічого ні в той, ні в інший бік.

• TLS-сертифікати — Чинність, домен, довірений ланцюжок та завершення строку менш ніж за 14 днів для хоста і його доступної www/apex-пари. Таймаути означають «не перевірено».
• SPF і DMARC — Поштовий домен має один SPF без +all і запис DMARC. p=none — режим спостереження, не знахідка; таймаути DNS та SERVFAIL означають «не перевірено». DKIM не перевіряється.
• HSTS — Strict-Transport-Security із додатним max-age на HTTPS-джерелі. Відсутній заголовок або max-age=0 — це знахідка; конкретної довжини max-age і прапорця includeSubDomains правило не вимагає, а сама версія TLS не перевіряється.
• Базові заголовки безпеки — X-Content-Type-Options: nosniff, захист від вбудовування у фрейм (X-Frame-Options або директива frame-ancestors у CSP — досить будь-чого одного) і непорожній Referrer-Policy. Одна знахідка на сторінку з переліком того, чого з трьох бракує.
• Content-Security-Policy — у відповіді є непорожній заголовок Content-Security-Policy. Чи справді політика безпечна для кожного сценарію виконання, ззовні не визначається.
• Permissions-Policy — у відповіді є непорожній заголовок Permissions-Policy.
• Атрибути cookie — кожна cookie із заголовка Set-Cookie фінальної відповіді, яку прочитав обхід, — не лише на головній сторінці — перевіряється на Secure, HttpOnly і SameSite. Значення cookie у доказах не зʼявляється ніколи: воно може бути секретом.
• Надмірно дозвільний CORS — Access-Control-Allow-Origin: * разом із Access-Control-Allow-Credentials: true — суперечність, яку браузери відхиляють, а сервер не має заявляти.

Знахідки класифікуються як сигнал присутній або сигнал відсутній — а не як підтверджені вразливості. Відсутній заголовок є доказом того, що захисний механізм не розгорнуто, а не доказом того, що сайт можна зламати.

Змішаний контент перевіряється, але повідомляє про нього модуль SEO, а не цей.

Доступність — WCAG 2.2 AA / EN 301 549 / Section 508

Автоматичні перевірки DOM охоплюють ту частину WCAG 2.2 рівня AA, яку можна перевірити машинно. WCAG 2.2 AA є надмножиною розділів WCAG, на які посилаються EN 301 549 (ЄС, розділ 9 посилається на WCAG 2.1) і Section 508 (США, включає WCAG 2.0 AA). Зверніть увагу: обидва стандарти містять функціональні вимоги поза WCAG, які автоматичне сканування DOM не покриває. Автоматичні інструменти перевіряють приблизно 30–40 % критеріїв WCAG; решта потребує людської оцінки або тестування з допоміжними технологіями.

• Масштабування (WCAG 1.4.4) — Viewport user-scalable=no/0 або maximum-scale менше 2 заважає масштабу щонайменше 200%.
• Сприйнятність (WCAG 2.2, принцип 1) — відсутній alt-текст зображень (1.1.1) і контраст нижче 4.5:1 для звичайного тексту або 3:1 для великого (1.4.3). Контраст оцінюється лише за парою `color`/`background-color`, записаною в inline-атрибуті `style`: без браузера, який розкладе сторінку, підсумковий колір із зовнішньої таблиці стилів обчислити неможливо, тож вона чесно лишається зоною ручної перевірки, а не хибного «пройдено».
• Керованість (WCAG 2.2, принцип 2) — додатний tabindex або inline-обробник лише для миші, що створює ризик доступу з клавіатури (2.1.1), прибраний контур фокуса без видимої заміни (2.4.7) і посилання, кнопка, summary чи submit-подібний input без придатного доступного імені (2.4.4, 4.1.2).
• Зрозумілість (WCAG 2.2, принцип 3) — присутній <html lang> і структура заголовків із рівно одним h1 та без пропущених рівнів (3.1.1, 1.3.1); елементи <label> форм правильно повʼязані (3.3.2); контрол із aria-invalid, до якого не привʼязано опис помилки (3.3.1).
• Надійність (WCAG 2.2, принцип 4) — невідома роль ARIA, атрибут ARIA із посиланням на неіснуючий ID або фокусований вміст, схований під aria-hidden (4.1.2). Валідність HTML документа в цілому та озвучення live-регіонів не перевіряються.
• Орієнтири для допоміжних технологій — landmark main, назва у повторюваної навігації, title у кожного iframe і оголошені підписи до медіа. Це статичні докази з DOM про те, з чим довелося б працювати екранному читачеві, — жоден екранний читач не запускається, і якість озвучення не вимірюється.

Кожна знахідка з доступності містить посилання на критерій WCAG, селектор проблемного елемента та конкретне порушене правило, тож перевірку можна відтворити без повторного запуску сканування.

Чого автоматичні перевірки оцінити не можуть: пастки фокусу в динамічних віджетах, якість озвучення екранним читачем, когнітивне навантаження, чутливість до руху в анімаціях, автовідтворення медіа або відповідність критеріям, що потребують розуміння змісту (наприклад, 1.3.3 Sensory Characteristics).

Надійність і продуктивність

У цьому розділі два різні вимірювання. Надійність — це те, що побачив власний краулер FluxRadar, поки читав ваші сторінки. Продуктивність FluxRadar не вимірює взагалі: лабораторні метрики беруться з Google PageSpeed Insights (запуск Lighthouse на інфраструктурі Google), а польові — з Chrome UX Report (CrUX), тобто від справжніх користувачів Chrome.

Лабораторна вибірка навмисно обмежена: до 5 URL, підібраних так, щоб покрити різні шаблони сторінок, на 2 емульованих пристроях, по 2 виміри кожен. У звіт потрапляє median двох прогонів, а поряд публікується розкид між ними, щоб було видно різницю між «сторінка вантажиться 3.1 с» і «сторінка завантажилась за 1.4 с, а потім за 4.8 с». Метрика, якої провайдер не виміряв, не дає знахідки взагалі — ні успішної, ні невдалої.

• Core Web Vitals — LCP, CLS і Total Blocking Time з лабораторного прогону; INP і LCP з польових даних CrUX, якщо у вашого джерела досить трафіку, щоб Chrome їх показав. INP у лабораторному прогоні не вимірюється взагалі й буває лише польовим.
• Час відповіді сервера (TTFB) — два незалежні показники. У лабораторному прогоні TTFB вище 0.80 с потребує уваги, вище 1.80 с — поганий. Окремо від цього краулер повідомляє про будь-яку сторінку вашого сайту, яка відповідала йому довше за 1.8 с.
• Вага сторінки та кількість запитів — загальний обсяг передачі проти бюджету 2 МБ і кількість запитів проти бюджету 80 — обидва з прогону Lighthouse.
• Можливості з ресурсами — невикористаний JavaScript, відсутнє стиснення тексту та економія на зображеннях, які Lighthouse може виміряти; повідомляються лише понад порогом, з якого є сенс діяти.
• Кешування та блокування рендеру — статичні ресурси з коротким або відсутнім часом життя кешу та ресурси, які відчутно відкладають перший показ сторінки.
• Стабільність вимірювання — якщо два прогони одного URL розходяться більш ніж на 40% від свого median, вердикт публікується як нестабільний, а не як число, за яким варто діяти.
• Сигнал доступності — HTTP-статус кожного URL в області. Відповіді 5xx, помилки зʼєднання та таймаути повідомляються як проблеми надійності.
• API-endpoint-и, які ви вкажете — публічні endpoint-и GET / HEAD / OPTIONS, додані вручну, викликаються один раз і звіряються зі статусом, який ви оголосили очікуваним: очікувані 404 чи 503 проходять, неочікувані — ні. Облікові дані відхиляються: endpoint, у заголовках якого налаштовано Authorization, Cookie чи API-ключ, не викликається взагалі, і звіт про це каже.

Знахідки з продуктивності ніколи не змінюють оцінку модуля Performance. Ця оцінка — власна оцінка Lighthouse, яка вже враховує ці метрики; віднімати ще раз за той самий повільний LCP означало б оштрафувати двічі. Знахідки кажуть, що з оцінкою робити, а не переказують її.

Якість контенту — що перевіряє FluxRadar

Модуль якості контенту читає текст і медіа, які сторінка вже віддає. Він судить те, що можна виміряти — скільки тексту, чи завантажується медіа, чи не несе той самий текст інша обійдена сторінка, — і ніколи не оцінює, добре чи погано написано.

• Текст-заглушка — Канонічний lorem ipsum і типові тексти WordPress англійською, українською та російською; типові заголовки враховуються лише в title/H1. Приклади в code, pre і textarea виключені.
• Дубльований зміст сторінки — дві обійдені сторінки, чий видимий текст збігається знак у знак. Сторінка, чий <link rel="canonical"> вказує на іншу сторінку групи, у звіт не потрапляє: назвати канонічну версію і є розв’язанням, тому перевірка мовчить і про сторінку, яка це заявила, і про ту, яку вона назвала. Повідомляються лише точні збіги, майже-дублікати — ні.
• Порожні та малозмістовні сторінки — видимий текст body коротший за 200 символів; вміст script і style не враховується.
• Биті зображення та медіа — зображення, відео й аудіо, які обхід справді перевірив і застав недоступними, з помилкою HTTP або з HTML-сторінкою замість файла. Медіа, до якого обхід не дійшов, сторінці не зараховується.
• Оцінка читабельності — сторінка, чий <html lang> оголошує англійську чи українську (регіональні варіанти на кшталт en-GB теж рахуються) і яка має щонайменше 200 символів видимого тексту, отримує оцінку читабельності за шкалою 0–100 (що вище — то легше читати) — Flesch Reading Ease для англійського тексту; для українського — адаптація тієї самої формули за Оборнєвою, відкалібрована на російських текстах і застосована до українського як наближення. Читабельність вимірюється за текстом абзаців (елементи <p>, <blockquote> і <dd>, поза навігацією, списками й таблицями), чий алфавіт відповідає оголошеній мові щонайменше в 70% своїх літер; сторінці потрібно щонайменше 5 речень і 100 слів такого тексту абзаців, щоб отримати оцінку. Позначається, якщо оцінка нижче 30 за будь-якою шкалою («дуже складно»). Це механічний вимір довжини речень і слів, а не оцінка якості письма, і сторінка без оголошеної англійської чи української мови, чий алфавіт тексту абзаців не долає поріг у 70%, або чий текст узагалі не викладено в елементах абзаців (деякі конструктори сторінок), не отримує оцінки. Розділ AI SEO / GEO посилається сюди на ту саму оцінку.

Сигнали приватності та згоди

FluxRadar читає публічно видимі сигнали згоди та відстеження. Він не встановлює код відстеження, не ставить cookie від імені перевіреного сайту й не взаємодіє зі сторонньою інфраструктурою згоди поза читанням того, що вбудовано у сторінку.

• Сигнал згоди — упізнаваний трекер, завантажений у відданому HTML (Google Analytics, Tag Manager, Meta, DoubleClick, Hotjar, Clarity, Segment, Plausible, Matomo), і при цьому ніде в цьому HTML немає маркера згоди — сигнатури платформи на кшталт OneTrust, Cookiebot, Didomi, Usercentrics чи TrustArc або слів «cookie» / «consent». Це лише статичний сигнал: банер, що зʼявляється після виконання JavaScript, і юридична дійсність згоди у вашій юрисдикції потребують браузера або юриста, а не цієї перевірки.
• Інвентаризація cookie — cookie, які ставить сторінка: із заголовків Set-Cookie її фінальної відповіді та з присвоєнь document.cookie в inline-скриптах. Звіт показує імена cookie й те, звідки кожна зʼявилася; значення не записуються ніколи, бо значення може бути секретом. Чи має cookie Secure, HttpOnly і SameSite, повідомляє модуль безпеки.
• Сторонні скрипти — повний перелік зовнішніх хостів, з яких сторінка вантажить <script src>. Піддомен вашого ж сайту стороннім не вважається. Домени саме інвентаризуються, а не класифікуються: FluxRadar не позначає один як рекламу, а інший як фінгерпринтинг.
• Чи можна знайти політику приватності — на головній сторінці є посилання в межах того самого сайту, текст або адреса якого ідентифікують політику приватності чи cookie.

Як підтверджується кожна знахідка

Кожна проблема в Центрі проблем містить:

• URL — сторінку, на якій знахідку зафіксовано.
• Що спрацювало — конкретне поле HTTP-відповіді (назва заголовка, HTML-селектор або атрибут), яке активувало правило.
• Побачене значення — фактичне значення, скорочене для показу; повне є в експорті JSON.
• Правило — ідентифікатор правила та стандарт чи рекомендацію, до яких воно належить.
• Наступний крок — рекомендована дія для виправлення.

Експорт JSON і CSV (тариф Complete) містить повні сирі докази для кожної знахідки, тож перевірку можна відтворити самостійно.

Чого FluxRadar не сертифікує

FluxRadar — інструмент аудиту публічних сигналів. Є важливі речі, яких він робити не може:

• Він не сертифікує відповідність WCAG. Автоматичні перевірки охоплюють приблизно третину критеріїв WCAG. Висока оцінка доступності не означає, що сайт повністю доступний або відповідає закону.
• Він не сертифікує відповідність ASVS. Знахідки з безпеки стосуються лише спостережуваної публічної поверхні. Сторінки за входом, серверна логіка, доступ до бази даних, вразливості залежностей і конфігурація інфраструктури поза межами перевірки.
• Він не сертифікує відповідність GDPR, ePrivacy чи CCPA. Сигнали приватності показують, чи присутні поширені механізми; вони не є юридичною оцінкою законності обробки даних.
• Він не виконує активних тестів безпеки. Жодного фазингу, спроб інʼєкцій, перебору чи підстановки облікових даних не виконується.
• Результат — знімок на момент часу. Перевірка відображає те, що було публічно видно під час її запуску. Динамічний вміст, A/B-тести та відмінності між вузлами CDN можуть дати інший результат при одночасному відкритті в браузері.
• Він не отримує доступу до контенту за входом чи платною стіною. Аудит охоплює лише URL, доступні неавтентифікованому HTTP-клієнту.
• Видимість у провайдерів AI — опційна й не гарантована. API провайдерів AI часто змінюються; перевірка видимості відображає відповіді API на момент перевірки й може не відповідати поведінці реальних запитів користувачів.

Як FluxRadar проводить аудит і хто відповідає за сервіс

FluxRadar — онлайн-сервіс FluxLab для перевірки публічних сайтів. Він читає доступні сторінки без паролів до CMS, SSH чи бази даних. Complete також спостерігає публічні TLS-сертифікати та DNS TXT-політики. Це пасивні перевірки, а не тест на проникнення.

Обхід обмежений обраним пакетом, налаштуваннями, доступністю сайту та robots.txt. Звіт відокремлює знайдені проблеми від неперевірених і незастосовних сигналів. Для кожної знахідки він показує правило, доказ і рекомендоване виправлення; відсутність знахідок не є сертифікатом відповідності.

SEO-аудит описує технічні сигнали, а не гарантує індексацію чи позиції. Доступ AI-краулера та згадка бренду — різні вимірювання: відповіді моделей залежать від конкретних запитань, провайдера й часу запуску.

Basic: SEO, AI/GEO та план дій, до 5 000 URL. Complete: до 50 000 URL, додаткові модулі, історія й експорт. Це разова перевірка, а не автоматичний моніторинг.

• Приклад результату для вигаданого сайту
• Як читати покриття й оцінку
• Як перевірити видимість для AI без обіцянок цитування
• Власний кейс: що змінив повний HTML FluxRadar

Питання про методику або помилковий висновок: support@fluxradar.net. Оператор і обробка даних.

Питання про обсяг або докази: support@fluxradar.net