Один домен, шість різних правд: що бачать DNS, TLS, браузер, Googlebot, соціальний crawler і сканер безпеки

https://example.com/artykul

і отримуєш шість різних відповідей:

• DNS стверджує, що домен веде до двох IP-адрес,
• рівень TLS бачить сертифікат, який не охоплює www,
• твій браузер показує коректну, персоналізовану сторінку,
• Googlebot індексує старіший заголовок,
• LinkedIn досі показує попереднє зображення,
• сканер безпеки виставляє низьку оцінку через відсутні заголовки.

Жодне з цих спостережень не обов'язково є хибним.

Кожна система дивиться на інший фрагмент стеку, використовує інший кеш, надсилає інший набір заголовків, може з'єднуватися з іншого місця і не завжди виконує JavaScript однаково. «Правда вебсторінки» не є одним документом. Це набір станів, видимих для різних клієнтів.

Найважливіший висновок: домен може працювати коректно у браузері власника і водночас мати помилковий DNS для частини резолверів, неправильний сертифікат на одному вузлі CDN, неіндексований вміст для Googlebot, старий соціальний попередній перегляд і слабкий захист HTTP-відповідей.

Стаття не припускає, що кожна відмінність є помилкою. Персоналізація, мовні варіанти, кеш і розподілена інфраструктура - це нормально. Проблема починається тоді, коли відмінність є ненавмисною, невидимою в моніторингу або унеможливлює конкретному клієнту доступ до правильної версії.

Документацію та поведінку описаних систем перевірено 23 липня 2026 року.

Шість перспектив в одній таблиці

Спостерігач	Що дійсно перевіряє	Чого зазвичай не знає	Що може змінити результат
DNS	ім'я хоста, записи, делегування, кеш, DNSSEC	вміст HTML, шлях URL, заголовок сторінки	резолвер, TTL, регіон, IPv4/IPv6
TLS	endpoint, SNI, сертифікат, SAN, chain, протокол	вміст сторінки та її SEO	IP-адреса, вузол CDN, конфігурація virtual host
Браузер	DNS, TLS, HTTP, HTML, CSS, JavaScript, cookies, кеш, DOM	намір автора та стан інших клієнтів	користувач, viewport, locale, storage, service worker
Googlebot	доступність, robots, HTTP, HTML, ресурси, рендеринг, canonical, noindex	вміст, що потребує входу або взаємодії	mobile-first, crawl cache, render queue, блокування ресурсів
Соціальний краулер	URL, redirect, metadata, зображення попереднього перегляду, кеш платформи	повний досвід застосунку	платформа, кеш, Open Graph, доступність зображення
Сканер безпеки	публічну поверхню та тести у своєму обсязі	усю бізнес-логіку, код і ролі користувачів	тип сканера, авторизація, шлях, конфігурація тесту

«Той самий домен» не завжди означає той самий тест

Перш ніж порівнювати результати, точно визнач досліджуваний ресурс:

http://example.com
https://example.com
https://www.example.com
https://example.com/
https://example.com/artykul
https://example.com/artykul?utm_source=test

Це технічно не ідентичні запити. Вони можуть:

• проходити через інші перенаправлення,
• використовувати інші хости,
• потрапляти на інший virtual host,
• мати інші правила кешування,
• вказувати на різні canonical,
• повертати інші заголовки,
• викликати окремі соціальні картки.

Аудит завжди повинен фіксувати повний URL, час, місце проведення тесту, user-agent, кінцевий статус і ланцюжок перенаправлень.

Правда номер 1: DNS бачить ім'я, а не сторінку

DNS перекладає ім'я хоста на дані, потрібні для пошуку сервісу. У типовому запиті для:

https://example.com/artykul?id=42

DNS цікавить ім'я:

example.com

Він не аналізує шлях /artykul, параметри ?id=42, заголовок HTML чи тег canonical. DNS - це ієрархічна система імен та записів ресурсів.

Що може побачити діагностика DNS?

Зокрема:

example.com.      IN A      192.0.2.10
example.com.      IN AAAA   2001:db8::10
www.example.com.  IN CNAME  edge.example.net.
example.com.      IN CAA    0 issue "letsencrypt.org"

Також може перевірити:

• сервери NS,
• запис SOA,
• пошту MX,
• дані TXT,
• записи HTTPS і SVCB,
• підписи DNSSEC.

Чому дві людини можуть отримати різні відповіді?

Найпростіша причина - це кеш. Резолвер може зберігати відповідь до завершення TTL. Негативні відповіді, такі як NXDOMAIN, також можуть кешуватися.

Відмінності також можуть виникати через:

• різні резолвери,
• відмінні версії кешу,
• географічну інфраструктуру або балансування навантаження DNS,
• окремі відповіді для IPv4 та IPv6,
• міграцію між операторами,
• неузгоджені авторитетні сервери,
• пошкоджений ланцюжок DNSSEC.

DNSSEC автентифікує походження та цілісність даних DNS, але не шифрує сам запит. Помилковий запис DS може призвести до того, що резолвер із валідацією поверне SERVFAIL, тоді як резолвер без валідації все одно покаже адресу.

Чого DNS не підтверджує?

Коректна відповідь DNS не доводить, що:

• сервер працює,
• порт 443 відкритий,
• сертифікат коректний,
• застосунок повертає код 200,
• сторінка індексується,
• заголовки безпеки впроваджені.

DNS каже, куди клієнт має спробувати під'єднатися. Він не каже, що клієнт знайде після з'єднання.

Правда номер 2: TLS бачить ідентичність endpoint, а не вміст статті

Після знаходження адреси клієнт створює з'єднання із сервером і узгоджує TLS. У середовищі, що обслуговує багато доменів на одній адресі, розширення SNI дозволяє клієнту вказати ім'я сервера, для якого він хоче отримати з'єднання.

Рівень TLS може розкрити, зокрема:

• підтримувані версії протоколу,
• узгоджений алгоритм,
• сертифікат сервера,
• імена SAN,
• центр сертифікації,
• термін дії,
• проміжні сертифікати,
• результат узгодження ALPN, наприклад HTTP/2.

TLS 1.3 визначено в RFC 8446, і він захищає передавання даних між клієнтом та сервером.

Сертифікат відповідає імені, а не вмісту

Клієнт перевіряє, чи ім'я хоста збігається з ідентичністю, записаною в сертифікаті, насамперед у subjectAltName.

Сертифікат для:

example.com

не обов'язково охоплює:

www.example.com
api.example.com

Wildcard:

*.example.com

не охоплює автоматично кореневий домен example.com ані багаторівневий www.eu.example.com.

Чому один користувач бачить коректний сертифікат, а інший ні?

Можливі сценарії:

• A та AAAA ведуть до різних серверів,
• один вузол CDN не отримав нового сертифіката,
• конфігурація SNI має помилковий default virtual host,
• трафік з певного регіону потрапляє до іншої інфраструктури,
• origin має інший сертифікат, ніж публічний edge,
• частина серверів надсилає неповний chain.

Це все ще «той самий домен» з перспективи користувача, але не той самий endpoint з перспективи мережі.

Чого TLS не знає?

Коректний TLS не доводить, що:

• сторінка безпечна на рівні застосунку,
• JavaScript не має XSS,
• користувач має відповідні дозволи,
• canonical правильний,
• Google проіндексує вміст,
• картка Open Graph має гарне зображення.

Зелений замок означає захищене з'єднання з іменем, прийнятим клієнтом. Це не сертифікат якості всього застосунку.

Правда номер 3: браузер бачить результат роботи всього середовища

Браузер виконує значно більше роботи, ніж просте завантаження HTML. Типова навігація охоплює DNS, транспортне з'єднання, TLS, HTTP-запит, аналіз HTML, завантаження CSS та JavaScript, побудову DOM і CSSOM, layout та рендеринг пікселів.

Те, що користувач бачить на екрані, може відрізнятися від вихідного коду відповіді.

Source HTML, DOM та екран - це три різні речі

HTML із сервера

<div id="app"></div>
<script src="/app.js"></script>

DOM після виконання JavaScript

<div id="app">
  <h1>Raport dla zalogowanego użytkownika</h1>
</div>

Зображення на екрані

На кінцевий вигляд впливають ще CSS, шрифти, розмір viewport, доступність зображень, системні налаштування та взаємодії користувача.

Що персоналізує «правду браузера»?

• cookies та сесія,
• localStorage та sessionStorage,
• мова браузера,
• часовий пояс,
• ширина екрана,
• prefers-color-scheme,
• prefers-reduced-motion,
• дозволи,
• експеримент A/B,
• відповіді API,
• стан входу.

Браузер також має приватний HTTP-кеш. Відповідь, збережена як свіжа, може бути використана без повторного завантаження, залежно від директив кешування.

Service worker може перехоплювати запити та повертати дані з власного кешу або з нестандартної офлайн-стратегії. Це пояснює ситуації, у яких звичайне оновлення все ще показує стару версію, а приватний режим показує нову.

Чому «у мене працює» є слабким тестом?

Власник сторінки може мати:

• активну сесію адміністратора,
• дані в кеші,
• старий service worker,
• доступ до API, недоступного публічно,
• іншу мову та регіон,
• розширення, що модифікують сторінку,
• пропущений банер або онбординг.

Тест у браузері повинен охоплювати чистий профіль, приватний режим, мобільний пристрій, IPv4, IPv6 та неавторизованого користувача.

Правда номер 4: Googlebot бачить сторінку, призначену для сканування, рендерингу та індексації

Google описує обробку JavaScript-сторінок як три основні фази:

1. crawling,
2. rendering,
3. indexing.

Googlebot завантажує URL, аналізує відповідь і може передати сторінку до Web Rendering Service. Google використовує для рендерингу актуальну версію Chrome, але результат не обов'язково постає в той самий момент, що й перше завантаження.

Googlebot не є звичайним користувачем

Google має Googlebot Smartphone і Desktop, а для більшості сторінок індексує насамперед мобільну версію. Тож більшість запитів походить від мобільного краулера.

Googlebot:

• не входить у твій обліковий запис,
• не має твоїх cookies,
• не бачить приватних даних,
• не поводиться як користувач, що виконує всі сценарії,
• може завантажувати ресурси окремо,
• підпорядковується robots.txt та засобам керування індексацією.

Google чітко повідомляє, що не завантажить основний вміст, який потребує взаємодії, такої як клік, введення даних або переміщення елемента.

Robots.txt не є тим самим, що noindex

robots.txt контролює, які URL краулер може завантажувати. Google наголошує, що це не механізм, який гарантує видалення URL з результатів.

Щоб noindex спрацював, краулер повинен мати змогу завантажити сторінку і побачити тег або заголовок. Якщо URL водночас заблокований у robots.txt, Google може не побачити noindex.

<meta name="robots" content="noindex">

або:

X-Robots-Tag: noindex

Canonical є підказкою, а не безумовною командою

<link rel="canonical" href="https://example.com/artykul">

Google може вибрати іншу версію canonical, ніж вказана власником, оскільки канонікалізація враховує багато сигналів. Google визначає вказівку canonical як підказку, а не правило.

Що може побачити користувач, але не Googlebot?

• вміст лише після натискання «Показати більше»,
• дані, доступні лише після входу,
• елемент, залежний від недоступного API,
• контент, що завантажується заблокованим скриптом,
• десктопну версію, багатшу за мобільну,
• компонент, що працює лише з даними, збереженими в браузері.

Що може побачити Googlebot, але не типовий користувач?

Наприклад, сервер може повертати інший варіант для його user-agent. Саме собою технічне пристосування не є автоматично порушенням, але навмисне показування пошуковій системі вмісту, суттєво відмінного від того, що бачать користувачі, може розцінюватися як cloaking.

Найбезпечніша практика - надати той самий важливий вміст у початковій відповіді або в рендерингу, який не потребує взаємодії користувача.

Правда номер 5: соціальний краулер будує картку, а не повний досвід сторінки

Коли URL вставляється у Facebook, LinkedIn, Slack чи іншу платформу, система може завантажити сторінку та побудувати попередній перегляд. Не слід припускати, що кожна платформа виконує JavaScript-застосунок точно так, як повноцінний браузер користувача.

Найбільш переносний спосіб опису сторінки - це metadata, розміщена в <head> початкового HTML.

Базовий Open Graph

Специфікація Open Graph визначає чотири обов'язкові властивості:

<meta property="og:title" content="Tytuł artykułu">
<meta property="og:type" content="article">
<meta property="og:image" content="https://example.com/og/article.jpg">
<meta property="og:url" content="https://example.com/artykul">

На практиці варто додати:

<meta property="og:description" content="Opis artykułu">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">
<meta property="og:image:alt" content="Opis grafiki">

Meta/Facebook

Meta рекомендує використовувати теги Open Graph, щоб краулер міг отримати заголовок, опис та зображення попереднього перегляду. Документація Meta також описує завантаження та кешування метаданих під час поширення URL.

Це означає, що зміна зображення на сервері не обов'язково одразу змінить наявну картку. Платформа може все ще мати старіший snapshot.

LinkedIn

LinkedIn повідомляє, що попередні перегляди використовують, зокрема, Open Graph або oEmbed. Старе зображення може походити з кешу, а Post Inspector дозволяє оновити дані для нових поширень.

Наявні дописи можуть зберігати старий попередній перегляд навіть після оновлення URL.

Slack

Slack документує класичний unfurling як процес, у якому після виявлення посилання система сканує сторінку та створює попередній перегляд. Застосунки Slack також можуть надавати власні, програмовані unfurl.

Це важливе розрізнення: картка в Slack може бути стандартним результатом сканування або нестандартним об'єктом, повернутим інтеграцією.

Чому платформи показують різні зображення?

• одна платформа має старий кеш,
• інша не може завантажити зображення,
• URL зображення перенаправляє,
• зображення має недоступний MIME або код статусу,
• кілька og:image мають інший порядок,
• сторінка має окремі теги для різних мовних версій,
• бот отримує інший варіант через CDN або firewall,
• metadata додається лише через JavaScript.

Найбезпечніше розміщувати базові соціальні теги безпосередньо в HTML із сервера та вказувати абсолютні HTTPS-адреси.

Правда номер 6: сканер безпеки бачить лише той обсяг, який здатний дослідити

«Сканер безпеки» може означати дуже різні інструменти:

• аналізатор HTTP-заголовків,
• сканер конфігурації TLS,
• DAST, що виконує запити та тести вразливостей,
• краулер застосунку,
• SAST, що аналізує код,
• сканер залежностей,
• інструмент для тестування інфраструктури.

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

Що бачить сканер заголовків?

MDN HTTP Observatory оцінює насамперед HTTP-заголовки та вибрані конфігурації безпеки.

Може перевірити, зокрема:

• CSP,
• HSTS,
• захист від framing,
• X-Content-Type-Options,
• cookies,
• перенаправлення на HTTPS,
• вибрані політики cross-origin.

Це не означає, що він прочитав код бекенду, ролі користувачів, конфігурацію бази даних чи всі endpoint API.

Літерна оцінка не є вироком щодо всієї безпеки

Документація Observatory зазначає, що scoring має вказувати на невикористані механізми безпеки, а потреба в конкретному заголовку може залежати від типу сайту.

Сторінка може отримати високий результат за заголовками, але все ще мати:

• IDOR,
• помилкову авторизацію,
• SQL Injection,
• вразливу адміністративну панель,
• розкриті ключі,
• бізнес-логіку, що дозволяє зловживання.

Можлива також зворотна ситуація: простий JSON-endpoint отримає слабшу оцінку за відсутність заголовків, типових для HTML-документа, хоча деякі з них не мають для нього такого самого значення.

DAST має інший обсяг, але також обмеження

OWASP описує web application vulnerability scanners як інструменти, що зовні тестують застосунки на вразливості та неправильну конфігурацію.

ZAP попереджає, що автоматичне сканування має обмеження. Без налаштованої автентифікації воно не виявить сторінок за входом, а автоматичний spider не виконає всіх реалістичних процесів користувача.

Результат залежить від:

• облікового запису та ролі, використаних у тесті,
• доступних URL,
• форм та тестових даних,
• обсягу доменів,
• user-agent,
• обмежень WAF,
• часу сканування,
• того, чи сканер виконує JavaScript.

Сканер каже: «у цьому обсязі я знайшов або не знайшов певні сигнали». Він не каже: «я довів відсутність усіх вразливостей».

Один URL, шість коректних звітів

Наведений нижче приклад є гіпотетичним, але технічно реалістичним.

Досліджувана адреса:

https://example.com/raport

DNS

A:    192.0.2.10
AAAA: 2001:db8::20
TTL:  300

Висновок: домен має два можливі endpoint.

TLS через IPv4

SAN: example.com, www.example.com
TLS: 1.3
Chain: poprawny

TLS через IPv6

SAN: old.example.net
TLS: 1.2
Chain: poprawny, ale zła nazwa

Висновок: частина клієнтів не відкриє сторінку.

Браузер власника

• використовує IPv4,
• має активну сесію,
• service worker повертає версію з кешу,
• показує актуальний звіт.

Висновок користувача: «все працює».

Googlebot Smartphone

• потрапляє через IPv6,
• не може пройти TLS,
• не завантажує сторінку.

Висновок SEO: новий вміст не сканується.

LinkedIn

• має попередній перегляд, збережений тиждень тому,
• показує попередній og:image.

Висновок маркетингу: картка неактуальна.

Сканер заголовків

• тестує IPv4,
• завантажує документ без входу,
• виявляє відсутність CSP та HSTS.

Висновок безпеки: транспорт працює, але hardening відповіді неповний.

Усі звіти описують інший фрагмент системи.

Матриця симптомів

Симптом	Найімовірніша перспектива	Перший тест
Сторінка працює лише для частини користувачів	DNS, IPv6 або TLS	dig A/AAAA, тест обох адрес
Сертифікат іншого домену	TLS/SNI	openssl s_client -servername
Після впровадження все ще видно стару сторінку	кеш браузера або service worker	чистий профіль, DevTools Application
Google показує старий заголовок	crawl/index cache або інший canonical	URL Inspection, перевірка rendered HTML
Сторінки немає в індексі	robots, noindex, помилки сканування	robots.txt, Search Console
Facebook або LinkedIn показує старе зображення	кеш соціального краулера	debugger або Post Inspector
Сканер показує відсутність HSTS, а браузер використовує HTTPS	заголовки відповіді	curl -I для фінального URL
Результат сканера хороший, але функція має помилку доступу	логіка застосунку поза обсягом сканера	тест авторизації та ролей
Мобільний вміст бідніший у Google	mobile-first та різний контент	порівняння мобільного рендеру
noindex не працює	URL заблокований у robots.txt	дозвіл на сканування та повторний тест

Методика повного аудиту

1. Запиши повний ланцюжок URL

curl -IL https://example.com/artykul

Зверни увагу на:

• статуси,
• зміну хоста,
• перехід HTTP→HTTPS,
• кінцевий URL,
• кількість перенаправлень.

2. Перевір DNS із кількох резолверів

dig example.com A
dig example.com AAAA
dig example.com NS
dig example.com CAA
dig example.com A +dnssec

Порівняй відповіді резолвера оператора, публічного резолвера та авторитетного сервера.

3. Перевір кожен endpoint TLS

openssl s_client \
  -connect 192.0.2.10:443 \
  -servername example.com \
  -showcerts

Повтори для IPv6 та інших адрес, повернутих DNS.

4. Перевір HTTP-відповідь без стану користувача

curl -sS -D headers.txt https://example.com/artykul -o page.html

Перевір:

• код статусу,
• Content-Type,
• кеш,
• CSP,
• HSTS,
• X-Robots-Tag,
• вміст <head>.

5. Порівняй source HTML та DOM

У браузері перевір:

• View Source,
• панель Elements,
• Network,
• Application,
• активний service worker,
• cache storage,
• cookies.

6. Перевір Googlebot

Використай інструмент URL Inspection у Google Search Console та порівняй:

• завантажений HTML,
• відрендерений HTML,
• знімок екрана,
• ресурси, які не вдалося завантажити,
• canonical, вказаний і вибраний Google,
• можливість індексації.

Не ідентифікуй Googlebot виключно за user-agent. Google рекомендує перевірку через reverse DNS або офіційні діапазони IP.

7. Перевір соціальну картку

Проаналізуй:

<title>
<meta name="description">
<meta property="og:title">
<meta property="og:description">
<meta property="og:image">
<meta property="og:url">

Потім використай інструменти оновлення конкретної платформи.

8. Запусти кілька класів тестів безпеки

• аналіз заголовків,
• тест TLS,
• DAST на призначеному для цього середовищі,
• тести автентифікації та авторизації,
• аналіз залежностей,
• перегляд коду та конфігурації.

Одна оцінка не замінює інших.

Зразковий <head>, доступний для різних клієнтів

<!doctype html>
<html lang="pl">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">

  <title>Jedna domena, sześć różnych prawd</title>
  <meta
    name="description"
    content="Jak DNS, TLS, przeglądarka, Googlebot, social crawler i skaner bezpieczeństwa widzą tę samą domenę."
  >

  <link
    rel="canonical"
    href="https://example.com/jedna-domena-szesc-prawd"
  >

  <meta name="robots" content="index,follow">

  <meta
    property="og:title"
    content="Jedna domena, sześć różnych prawd"
  >
  <meta property="og:type" content="article">
  <meta
    property="og:url"
    content="https://example.com/jedna-domena-szesc-prawd"
  >
  <meta
    property="og:image"
    content="https://example.com/images/six-truths-1200x630.jpg"
  >
  <meta property="og:image:width" content="1200">
  <meta property="og:image:height" content="630">
  <meta
    property="og:image:alt"
    content="Schemat sześciu warstw obserwujących jedną domenę"
  >
</head>

Найважливіші метадані містяться у HTML-відповіді, а не лише після запуску застосунку.

Практичний чек-лист «шести правд»

DNS

• A та AAAA ведуть до активних endpoint.
• Усі авторитетні сервери повертають узгоджені дані.
• TTL зрозумілий і моніториться.
• DNSSEC проходить валідацію.
• www та apex мають заплановану поведінку.
• Тест виконано з кількох резолверів та місць.

TLS

• Кожна IP-адреса повертає правильний сертифікат.
• SAN охоплює кожен використовуваний hostname.
• Chain повний.
• IPv4 та IPv6 мають однакову якість конфігурації.
• SNI вибирає правильний virtual host.
• CDN та origin мають коректний TLS.

Браузер

• Сторінка працює в чистому профілі.
• Перевірено неавторизовану версію.
• Source HTML містить ключовий вміст та metadata.
• DOM після рендерингу відповідає очікуванням.
• Service worker та кеш не маскують впровадження.
• Мобільна версія містить повний вміст.
• Помилки API опрацьовуються.

Googlebot

• robots.txt дозволяє завантажити сторінку та ресурси.
• noindex відповідає наміру.
• Canonical узгоджений із перенаправленнями та картою сайту.
• Основний вміст не потребує кліку.
• Мобільний рендер містить той самий важливий вміст.
• URL Inspection показує коректний HTML та знімок екрана.
• Ресурси CSS та JS доступні.

Соціальний краулер

• Базовий Open Graph міститься в початковому HTML.
• og:url вказує на правильний сталий URL.
• og:image є абсолютною HTTPS-адресою.
• Зображення повертає 200 та коректний MIME.
• Розміри зображення задекларовані.
• Кожна мовна версія має правильну metadata.
• Кеш платформи оновлено після зміни.

Безпека

• Протестовано заголовки фінальної відповіді.
• Тест охоплює більше, ніж homepage.
• Перевірено endpoint після входу.
• Ролі користувачів протестовано окремо.
• Автоматичні результати перевірила людина.
• DAST доповнено SAST та аналізом залежностей.
• Низьку або високу оцінку інтерпретовано в контексті.

Інструменти POLPROG, корисні в такому аудиті

• Інспектор DNS та SSL показує записи домену та дані сертифіката.
• Open Graph Preview перевіряє metadata та картку поширення.
• Інспектор заголовків безпеки аналізує hardening HTTP-відповіді.
• Стан сайту поєднує сигнали SEO, продуктивності, доступності та безпеки.
• FlowTrace візуалізує шлях від події в браузері через DNS, TLS, CDN, бекенд та рендеринг.

Найпоширеніші міфи

«Якщо сторінка працює в мене, вона працює всюди»

Ні. Твій резолвер, IP-протокол, кеш, cookies та вузол CDN можуть бути іншими.

«Google бачить точно те саме, що й Chrome»

Google рендерить сторінки за допомогою Chrome, але Googlebot має інший стан, mobile-first user-agent, окремі фази сканування та рендерингу і не виконує вмісту, який потребує взаємодії.

«Robots.txt видаляє сторінку з Google»

Ні. Robots.txt обмежує сканування. Для керування індексацією служить noindex, який має бути видимим для краулера.

«Canonical змушує Google використати вибраний URL»

Ні. Це важливий сигнал, але Google може вибрати інший canonical.

«Я змінив og:image, тож картка вже нова»

Не завжди. Платформа може використовувати збережену версію та вимагати повторного завантаження URL.

«A+ у сканері означає, що застосунок безпечний»

Ні. Це означає високий результат у конкретному наборі тестів. Це не доводить коректної авторизації, бізнес-логіки чи безпеки коду.

Вердикт

Один домен не має єдиного технічного «обличчя».

• DNS бачить ім'я та записи.
• TLS бачить endpoint та ідентичність сертифіката.
• Браузер бачить відрендерений досвід конкретного користувача.
• Googlebot бачить ресурс, доступний для сканування, рендерингу та індексації.
• соціальний краулер бачить metadata, потрібну для побудови картки.
• сканер безпеки бачить виключно поверхню, охоплену його тестами.

Тож зрілий аудит не питає лише: «Чи працює сторінка?»

Він питає:

Dla kogo?
Z jakiej lokalizacji?
Po IPv4 czy IPv6?
Z jakim stanem cache?
Z jakim user-agentem?
Przed czy po wykonaniu JavaScriptu?
Z logowaniem czy bez?
W jakim zakresie testu?

Лише відповіді на ці запитання створюють цілісну картину системи.