Domain & DNS

Site Info

Title, опис, stack і використані технології на сайті.

Про цей інструмент

Site Info завантажує головну сторінку сайту з нашого сервера у Франкфурті й повідомляє все, що ця сторінка про себе оголошує: HTML <title>, meta-опис, Open Graph і Twitter Card-метадані, URL favicon, canonical URL, мовні підказки та fingerprint технологічного стеку (server, CMS, фреймворки, аналітика, ad-мережі, CDN). Перевірка використовує справжній HTTPS-запит у стилі браузера — включно зі слідуванням до п'яти редиректів та читанням HTTP/2-відповідей — тож ви бачите те, що бачив би звичайний відвідувач.

Детекція стеку працює з підписами для ~1500 продуктів: server-заголовки (nginx, cloudflare, litespeed), HTML-маркери (generator-meta, framework-specific class-імена, шляхи до асетів) та JavaScript-глобали, доступні на першому рендері. Кожна детекція показана з рівнем впевненості та сніпетом, що тригернув матч. Деталі SSL/TLS, ланцюг відповідей (кожен редирект зі статус-кодом) та оцінка render-time входять у той самий звіт.

Коли використовувати цей інструмент

  • Конкурентна розвідка. Подивіться, які CMS, фреймворк, аналітику та ad-мережу використовує конкурент, не копаючись у його DOM вручну.
  • SEO-аудити. Підтвердіть, що title, description, Open Graph, canonical і language-теги присутні та коректно заповнені.
  • Археологія стеку. Визначте, коли сайт востаннє редизайнили, перевіривши версії детектованих бібліотек.
  • Due diligence вендора. Швидко переконайтесь, що провайдер справді працює на платформі, яку заявляє у своєму pitch.

Чого ми свідомо не робимо

Жодного виконання JavaScript. Ми завантажуємо сирий HTML-відгук і парсимо те, що в ньому є, включно з inline <script>-тегами — але сторінку не рендеримо. Це означає, що client-side-only фреймворки (чистий SPA з порожнім <body>) дадуть менше інформації; для них ми спираємось на response-заголовки та шляхи до bundle, щоб зробити fingerprint стеку. Сайти, що блокують bot-трафік на edge, можуть повернути чистішу сторінку, ніж справжній браузер — результат чесно відображає те, що нам віддав їхній сервер.

Часті запитання

Чим це відрізняється від «view source»?

View source показує сирий HTML; Site Info парсить його за вас, прогонить fingerprint-перевірку по ~1500 відомих продуктах і подає результат як охайний звіт. Те саме можна дістати вручну з терпінням — але треба пам'ятати, яке class-ім'я належить React, а яке Vue, який заголовок Cloudflare, а який Fastly, і який generator-тег означає Drupal 9 vs Drupal 10. Цю довідку ми робимо за вас.

Чому tech-список не показує те, що я точно бачу на сайті?

Три типові причини. (1) Воно вантажиться лише після виконання JavaScript — ми JS не виконуємо, тож client-only-віджети для нас невидимі. (2) Сайт за service worker, який переписує markup до показу користувачу. (3) Підпису цього продукту немає в нашій базі; якщо відомий продукт стабільно пропускається, повідомте нам. Зворотна проблема — false positives — рідкість, бо кожен підпис вимагає кількох збігів.

Чи слідує інструмент за редиректами?

Так, до п'яти хопів. Повний ланцюг показано у звіті — корисно для виявлення випадкових redirect-петель, змішаних HTTP/HTTPS-хопів або невідповідності canonical-тегу до фінальної URL. Якщо ваш сайт робить більше п'яти редиректів, ми зупиняємось і повідомляємо це як проблему ланцюга (шість і більше — майже завжди config-баг).

Чи можна використовувати на приватних/staging-сайтах?

Лише якщо вони публічно доступні. Запит виконується з нашого франкфуртського сервера, тож усе за VPN, IP-allowlist або basic-auth-стіною впаде. RFC 1918 приватні діапазони та link-local адреси відхиляються на SSRF-guard. Для внутрішнього staging запустіть локальний tech-detection-інструмент (наприклад, розширення Wappalyzer) зсередини своєї мережі.