Site Info
Title, опис, stack і використані технології на сайті.
No known technologies detected from the response.
Що означає кожне поле?
Опис полів
HTTP-статус
Статус-код фінального URL у redirect-ланцюжку. 200 OK — здоровий стан; 301/302 — є ще hop (див. redirect chain); 403/404/500 — проблеми з доступністю.
Сервер
Вільний рядок, який сервер сам про себе анонсує — <code>nginx</code>, <code>cloudflare</code>, <code>Apache/2.4</code>, <code>caddy</code>. Деякі сервери приховують або підробляють заголовок з міркувань безпеки; відсутність — не проблема.
Затримка
Round-trip + TLS handshake + час до першого байта сервера. Вимірюється з однієї точки (наш сервер), тому географічна відстань і edge-кеш впливають. Використовуйте як грубий сигнал свіжості.
Ланцюжок редиректів
Послідовність 3xx-редиректів. Два стрибки (HTTP → HTTPS → www) — нормально; три і більше — зазвичай misconfiguration. Кожен hop додає RTT і шкодить SEO.
Мова
Читається з <code><html lang="..."></code>. Браузери використовують для hyphenation та підказок перекладу, пошукові — для locale-targeting, screen reader — для вимови. Відсутні чи неправильні значення шкодять доступності.
Meta-теги
Title видно у вкладці браузера та як заголовок у Google SERP (~50–60 символів). Meta description показується нижче (~150–160 символів). Обидва мають бути унікальні per page; generic чи duplicate metadata шкодить CTR.
Open Graph
Open Graph теги (<code>og:title</code>, <code>og:description</code>, <code>og:image</code>, <code>og:url</code>) керують виглядом сторінки при шарингу в соцмережі. Відсутні або low-res картинки = порожні чи негарні preview.
Виявлені технології
Wappalyzer-стиль детекції: WordPress, Drupal, Next.js, Cloudflare, Google Analytics тощо. Сигнали: response headers, generator meta, well-known asset-шляхи, inline-скрипти. Корисно для конкурентної розвідки та security recon (знаючи стек, легше планувати аудит).
Про цей інструмент
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, можуть повернути чистішу сторінку, ніж справжній браузер — результат чесно відображає те, що нам віддав їхній сервер.