Jedna doména, šesť rôznych právd: čo vidia DNS, TLS, prehliadač, Googlebot, sociálny crawler a bezpečnostný skener

https://example.com/artykul

a dostaneš šesť rôznych odpovedí:

• DNS tvrdí, že doména smeruje na dve IP adresy,
• vrstva TLS vidí certifikát, ktorý nezahŕňa www,
• tvoj prehliadač zobrazuje správnu, personalizovanú stránku,
• Googlebot indexuje starší názov,
• LinkedIn stále zobrazuje predchádzajúci obrázok,
• bezpečnostný skener udeľuje slabé hodnotenie pre chýbajúce hlavičky.

Žiadne z týchto pozorovaní nemusí byť nesprávne.

Každý systém sa pozerá na iný fragment zásobníka, používa inú vyrovnávaciu pamäť, posiela inú množinu hlavičiek, môže sa pripájať z inej lokality a nie vždy vykonáva JavaScript rovnakým spôsobom. „Pravda webovej stránky“ nie je jeden dokument. Je to súbor stavov viditeľných pre rôznych klientov.

Najdôležitejší záver: doména môže fungovať správne v prehliadači vlastníka a zároveň mať chybné DNS pre časť resolverov, nesprávny certifikát na jednom uzle CDN, neindexovateľný obsah pre Googlebota, starý sociálny náhľad a slabé zabezpečenie HTTP odpovedí.

Článok nepredpokladá, že každý rozdiel je chyba. Personalizácia, jazykové varianty, vyrovnávacia pamäť a distribuovaná infraštruktúra sú normálne. Problém sa začína vtedy, keď je rozdiel nezamýšľaný, neviditeľný v monitoringu alebo bráni konkrétnemu klientovi dostať sa k správnej verzii.

Dokumentácia a správanie opísaných systémov boli overené 23. júla 2026.

Šesť pohľadov v jednej tabuľke

„Tá istá doména“ nie vždy znamená ten istý test

Skôr než porovnáš výsledky, presne urči skúmaný zdroj:

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

Nie sú to technicky identické požiadavky. Môžu:

• viesť cez iné presmerovania,
• používať iných hostiteľov,
• smerovať na iný virtual host,
• mať iné pravidlá vyrovnávacej pamäte,
• odkazovať na rôzne canonicaly,
• vracať iné hlavičky,
• vyvolávať samostatné sociálne karty.

Audit by mal vždy zaznamenávať úplnú URL, čas, lokalitu testu, user-agent, konečný status a reťazec presmerovaní.

Pravda číslo 1: DNS vidí názov, nie stránku

DNS prekladá názov hostiteľa na údaje potrebné na nájdenie služby. V typickej požiadavke pre:

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

DNS zaujíma názov:

example.com

Neanalyzuje cestu /artykul, parametre ?id=42, názov HTML ani značku canonical. DNS je hierarchický systém názvov a záznamov o zdrojoch.

Čo môže vidieť diagnostika DNS?

Okrem iného:

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"

Môže tiež skontrolovať:

• servery NS,
• záznam SOA,
• poštu MX,
• údaje TXT,
• záznamy HTTPS a SVCB,
• podpisy DNSSEC.

Prečo môžu dvaja ľudia dostať rôzne odpovede?

Najjednoduchšou príčinou je vyrovnávacia pamäť. Resolver môže uchovávať odpoveď až do vypršania TTL. Negatívne odpovede, ako je NXDOMAIN, môžu byť tiež ukladané do vyrovnávacej pamäte.

Rozdiely môžu vyplývať aj z:

• rôznych resolverov,
• odlišných verzií vyrovnávacej pamäte,
• geografickej infraštruktúry alebo load balancingu DNS,
• samostatných odpovedí pre IPv4 a IPv6,
• migrácie medzi operátormi,
• nekonzistentných autoritatívnych serverov,
• poškodeného reťazca DNSSEC.

DNSSEC autentifikuje pôvod a integritu údajov DNS, ale samotnú požiadavku nešifruje. Chybný záznam DS môže spôsobiť, že validujúci resolver vráti SERVFAIL, zatiaľ čo resolver bez validácie stále zobrazí adresu.

Čo DNS nepotvrdzuje?

Správna odpoveď DNS nedokazuje, že:

• server funguje,
• port 443 je otvorený,
• certifikát je správny,
• aplikácia vracia kód 200,
• stránka je indexovateľná,
• bezpečnostné hlavičky sú nasadené.

DNS hovorí, kde sa má klient pokúsiť pripojiť. Nehovorí, čo nájde po pripojení.

Pravda číslo 2: TLS vidí identitu endpointu, nie obsah článku

Po nájdení adresy klient vytvorí spojenie so serverom a vyjednáva TLS. V prostredí, ktoré obsluhuje viacero domén na jednej adrese, rozšírenie SNI umožňuje klientovi uviesť názov servera, pre ktorý chce získať spojenie.

Vrstva TLS môže odhaliť okrem iného:

• podporované verzie protokolu,
• vyjednaný algoritmus,
• certifikát servera,
• názvy SAN,
• certifikačnú autoritu,
• dátum platnosti,
• sprostredkujúce certifikáty,
• výsledok vyjednávania ALPN, napríklad HTTP/2.

TLS 1.3 je definovaný v RFC 8446 a chráni prenos údajov medzi klientom a serverom.

Certifikát zodpovedá názvu, nie obsahu

Klient kontroluje, či názov hostiteľa zodpovedá identite zapísanej v certifikáte, predovšetkým v subjectAltName.

Certifikát pre:

example.com

nemusí zahŕňať:

www.example.com
api.example.com

Wildcard:

*.example.com

automaticky nezahŕňa hlavnú doménu example.com ani viacúrovňový www.eu.example.com.

Prečo jeden používateľ vidí správny certifikát a iný nie?

Možné scenáre:

• A a AAAA vedú na rôzne servery,
• jeden uzol CDN nedostal nový certifikát,
• konfigurácia SNI má chybný default virtual host,
• prevádzka z určitého regiónu smeruje na inú infraštruktúru,
• origin má iný certifikát ako verejný edge,
• časť serverov posiela neúplný chain.

Z pohľadu používateľa je to stále „tá istá doména“, ale z pohľadu siete to nie je ten istý endpoint.

Čo TLS nevie?

Správny TLS nedokazuje, že:

• stránka je bezpečná na úrovni aplikácie,
• JavaScript nemá XSS,
• používateľ má správne oprávnenia,
• canonical je správny,
• Google zaindexuje obsah,
• karta Open Graph má dobrý obrázok.

Zelený zámok znamená chránené spojenie s názvom, ktorý klient akceptoval. Nie je certifikátom kvality celej aplikácie.

Pravda číslo 3: prehliadač vidí výsledok fungovania celého prostredia

Prehliadač vykonáva oveľa viac práce než len prevzatie HTML. Typická navigácia zahŕňa DNS, transportné spojenie, TLS, HTTP požiadavku, analýzu HTML, prevzatie CSS a JavaScriptu, zostavenie DOM a CSSOM, layout a renderovanie pixelov.

To, čo používateľ vidí na obrazovke, môže byť iné než zdrojový kód odpovede.

Source HTML, DOM a obrazovka sú tri rôzne veci

HTML zo servera

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

DOM po vykonaní JavaScriptu

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

Obraz na obrazovke

Na konečný vzhľad vplývajú ešte CSS, fonty, veľkosť viewportu, dostupnosť obrázkov, systémové nastavenia a interakcie používateľa.

Čo personalizuje „pravdu prehliadača“?

• cookies a relácia,
• localStorage a sessionStorage,
• jazyk prehliadača,
• časové pásmo,
• šírka obrazovky,
• prefers-color-scheme,
• prefers-reduced-motion,
• oprávnenia,
• A/B experiment,
• odpovede API,
• stav prihlásenia.

Prehliadač má tiež súkromnú HTTP vyrovnávaciu pamäť. Odpoveď uložená ako čerstvá sa môže použiť bez opätovného prevzatia, v závislosti od direktív vyrovnávacej pamäte.

Service worker môže zachytávať požiadavky a vracať údaje z vlastnej vyrovnávacej pamäte alebo z neštandardnej offline stratégie. To vysvetľuje situácie, keď bežné obnovenie stále zobrazuje starú verziu, zatiaľ čo súkromný režim prezentuje novú.

Prečo je „u mňa to funguje“ slabý test?

Vlastník stránky môže mať:

• aktívnu reláciu administrátora,
• údaje vo vyrovnávacej pamäti,
• starý service worker,
• prístup k API, ktoré nie je verejne dostupné,
• iný jazyk a región,
• rozšírenia, ktoré upravujú stránku,
• preskočený banner alebo onboarding.

Test prehliadača by mal zahŕňať čistý profil, súkromný režim, mobilné zariadenie, IPv4, IPv6 a neprihláseného používateľa.

Pravda číslo 4: Googlebot vidí stránku určenú na crawlovanie, renderovanie a indexovanie

Google opisuje spracovanie JavaScriptových stránok ako tri hlavné fázy:

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

Googlebot preberá URL, analyzuje odpoveď a môže stránku odovzdať do Web Rendering Service. Google používa na renderovanie aktuálnu verziu Chrome, ale výsledok nemusí vzniknúť v tom istom momente ako prvé prevzatie.

Googlebot nie je bežný používateľ

Google má Googlebota Smartphone a Desktop a pre väčšinu stránok indexuje predovšetkým mobilnú verziu. Väčšina požiadaviek teda pochádza od mobilného crawlera.

Googlebot:

• sa neprihlasuje do tvojho konta,
• nemá tvoje cookies,
• nevidí súkromné údaje,
• nespráva sa ako používateľ, ktorý vykonáva všetky scenáre,
• môže preberať zdroje samostatne,
• podlieha robots.txt a kontrolám indexovania.

Google výslovne informuje, že nenačíta hlavný obsah vyžadujúci interakciu, ako je kliknutie, zadanie údajov alebo posunutie prvku.

Robots.txt nie je to isté ako noindex

robots.txt riadi, ktoré URL adresy môže crawler preberať. Google zdôrazňuje, že nejde o mechanizmus, ktorý zaručuje odstránenie URL adresy z výsledkov.

Aby noindex zafungoval, crawler musí byť schopný prevziať stránku a vidieť značku alebo hlavičku. Ak je URL adresa zároveň zablokovaná v robots.txt, Google nemusí noindex vidieť.

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

alebo:

X-Robots-Tag: noindex

Canonical je odporúčanie, nie bezpodmienečný príkaz

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

Google môže vybrať inú verziu canonical, než akú uviedol vlastník, pretože kanonizácia zohľadňuje mnoho signálov. Google označuje uvedenie canonical za pomôcku, nie pravidlo.

Čo môže vidieť používateľ, ale nie Googlebot?

• obsah až po kliknutí na „Zobraziť viac“,
• údaje dostupné len po prihlásení,
• prvok závislý od nedostupného API,
• obsah načítaný cez zablokovaný skript,
• desktopovú verziu bohatšiu než mobilnú,
• komponent, ktorý funguje len s údajmi uloženými v prehliadači.

Čo môže vidieť Googlebot, ale nie bežný používateľ?

Napríklad server môže vracať iný variant pre jeho user-agent. Samotné technické prispôsobenie nie je automaticky porušením, ale zámerné zobrazovanie zásadne iného obsahu vyhľadávaču než používateľom môže byť považované za cloaking.

Najbezpečnejšou praxou je sprístupniť ten istý podstatný obsah v počiatočnej odpovedi alebo v renderovaní, ktoré nevyžaduje interakciu používateľa.

Pravda číslo 5: sociálny crawler zostavuje kartu, nie plný zážitok zo stránky

Keď sa URL vloží do Facebooku, LinkedInu, Slacku alebo inej platformy, systém môže prevziať stránku a zostaviť náhľad. Netreba predpokladať, že každá platforma vykonáva JavaScriptovú aplikáciu presne tak ako plnohodnotný prehliadač používateľa.

Najprenositeľnejším spôsobom opisu stránky sú metadáta umiestnené v <head> počiatočného HTML.

Základné Open Graph

Špecifikácia Open Graph definuje štyri povinné vlastnosti:

<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">

V praxi sa oplatí pridať:

<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 odporúča používať tagy Open Graph, aby crawler mohol prevziať názov, opis a náhľadový obrázok. Dokumentácia Meta opisuje aj prevzatie a ukladanie metadát do vyrovnávacej pamäte pri zdieľaní URL adresy.

Znamená to, že zmena obrázka na serveri nemusí okamžite zmeniť existujúcu kartu. Platforma môže stále mať starší snapshot.

LinkedIn

LinkedIn informuje, že náhľady využívajú okrem iného Open Graph alebo oEmbed. Starý obrázok môže pochádzať z vyrovnávacej pamäte a Post Inspector umožňuje obnoviť údaje pre nové zdieľania.

Existujúce príspevky si môžu zachovať predchádzajúci náhľad aj po obnovení URL adresy.

Slack

Slack dokumentuje klasické unfurling ako proces, pri ktorom systém po zistení odkazu prehľadá stránku a vytvorí náhľad. Slack aplikácie môžu tiež poskytovať vlastné, programovateľné unfurly.

Je to dôležité rozlíšenie: karta v Slacku môže byť štandardným výsledkom crawlovania alebo neštandardným objektom vráteným integráciou.

Prečo platformy zobrazujú rôzne obrázky?

• jedna platforma má starú vyrovnávaciu pamäť,
• iná nemôže prevziať obrázok,
• URL adresa obrázka presmerúva,
• obrázok má nedostupný MIME alebo stavový kód,
• viacero og:image má iné poradie,
• stránka má samostatné tagy pre rôzne jazykové verzie,
• bot dostáva iný variant cez CDN alebo firewall,
• metadáta sa pridávajú až prostredníctvom JavaScriptu.

Najbezpečnejšie je umiestniť základné sociálne tagy priamo do HTML zo servera a uvádzať absolútne HTTPS adresy.

Pravda číslo 6: bezpečnostný skener vidí len rozsah, ktorý dokáže preskúmať

„Bezpečnostný skener“ môže označovať veľmi rôzne nástroje:

• analyzátor HTTP hlavičiek,
• skener konfigurácie TLS,
• DAST vykonávajúci požiadavky a testy zraniteľností,
• crawler aplikácie,
• SAST analyzujúci kód,
• skener závislostí,
• nástroj na testovanie infraštruktúry.

V tomto článku hovoríme najmä o externom skeneri, ktorý skúma verejne dostupnú stránku.

Čo vidí skener hlavičiek?

MDN HTTP Observatory hodnotí predovšetkým HTTP hlavičky a vybrané bezpečnostné konfigurácie.

Môže skontrolovať okrem iného:

• CSP,
• HSTS,
• ochranu pred framingom,
• X-Content-Type-Options,
• cookies,
• presmerovanie na HTTPS,
• vybrané cross-origin politiky.

Neznamená to, že prečítal kód backendu, používateľské roly, konfiguráciu databázy alebo všetky API endpointy.

Písmenkové hodnotenie nie je verdikt o celej bezpečnosti

Dokumentácia Observatory uvádza, že skóre má poukazovať na nevyužité bezpečnostné mechanizmy a potreba konkrétnej hlavičky môže závisieť od typu webu.

Stránka môže získať vysoké skóre hlavičiek a stále mať:

• IDOR,
• chybnú autorizáciu,
• SQL Injection,
• zraniteľný administračný panel,
• odhalené kľúče,
• biznes logiku umožňujúcu zneužitie.

Možná je aj opačná situácia: jednoduchý JSON endpoint dostane slabšie hodnotenie za chýbajúce hlavičky typické pre HTML dokument, hoci niektoré z nich preň nemajú rovnaký význam.

DAST má iný rozsah, ale tiež obmedzenia

OWASP opisuje web application vulnerability scanners ako nástroje, ktoré externe testujú aplikácie na zraniteľnosti a chybnú konfiguráciu.

ZAP upozorňuje, že automatické skenovanie má obmedzenia. Bez nakonfigurovanej autentifikácie neodhalí stránky za prihlásením a automatický spider nevykoná všetky realistické procesy používateľa.

Výsledok závisí od:

• konta a roly použitej v teste,
• dostupných URL adries,
• formulárov a testovacích údajov,
• rozsahu domén,
• user-agenta,
• limitov WAF,
• času skenovania,
• toho, či skener vykonáva JavaScript.

Skener hovorí: „v tomto rozsahu som našiel alebo nenašiel určité signály“. Nehovorí: „dokázal som neexistenciu všetkých zraniteľností“.

Jedna URL, šesť správnych reportov

Nasledujúci príklad je hypotetický, ale technicky realistický.

Skúmaná adresa:

https://example.com/raport

DNS

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

Záver: doména má dva možné endpointy.

TLS cez IPv4

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

TLS cez IPv6

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

Záver: časť klientov stránku neotvorí.

Prehliadač vlastníka

• používa IPv4,
• má aktívnu reláciu,
• service worker vracia verziu z vyrovnávacej pamäte,
• zobrazuje aktuálny report.

Záver používateľa: „všetko funguje“.

Googlebot Smartphone

• prichádza cez IPv6,
• nedokáže prejsť cez TLS,
• nepreberá stránku.

Záver SEO: nový obsah sa necrawluje.

LinkedIn

• má náhľad uložený týždeň predtým,
• zobrazuje predchádzajúci og:image.

Záver marketingu: karta je neaktuálna.

Skener hlavičiek

• testuje IPv4,
• preberá dokument bez prihlásenia,
• zisťuje chýbajúce CSP a HSTS.

Záver bezpečnosti: prenos funguje, ale hardening odpovede je neúplný.

Všetky reporty opisujú iný fragment systému.

Matica symptómov

Metodika úplného auditu

1. Zaznamenaj úplný reťazec URL

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

Všimni si:

• statusy,
• zmenu hostiteľa,
• prechod HTTP→HTTPS,
• konečnú URL,
• počet presmerovaní.

2. Skontroluj DNS z viacerých resolverov

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

Porovnaj odpovede s resolverom operátora, verejným resolverom a autoritatívnym serverom.

3. Skontroluj každý endpoint TLS

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

Zopakuj pre IPv6 a ďalšie adresy vrátené cez DNS.

4. Skontroluj HTTP odpoveď bez stavu používateľa

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

Over:

• stavový kód,
• Content-Type,
• vyrovnávaciu pamäť,
• CSP,
• HSTS,
• X-Robots-Tag,
• obsah <head>.

5. Porovnaj source HTML a DOM

V prehliadači skontroluj:

• View Source,
• panel Elements,
• Network,
• Application,
• aktívny service worker,
• cache storage,
• cookies.

6. Skontroluj Googlebota

Použi nástroj URL Inspection v Google Search Console a porovnaj:

• prevzatý HTML,
• renderovaný HTML,
• screenshot,
• zdroje, ktoré sa nepodarilo načítať,
• canonical uvedený a vybraný Googlom,
• možnosť indexovania.

Neidentifikuj Googlebota výlučne podľa user-agenta. Google odporúča overenie cez reverse DNS alebo oficiálne rozsahy IP.

7. Skontroluj sociálnu kartu

Analyzuj:

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

Následne použi obnovovacie nástroje konkrétnej platformy.

8. Spusti niekoľko tried bezpečnostných testov

• analýzu hlavičiek,
• test TLS,
• DAST v prostredí, ktoré je na to určené,
• testy autentifikácie a autorizácie,
• analýzu závislostí,
• revíziu kódu a konfigurácie.

Jedno hodnotenie nenahrádza ostatné.

Vzorový <head> dostupný pre rôznych klientov

<!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>

Najdôležitejšie metadáta sú v HTML odpovedi, a nie až po spustení aplikácie.

Praktický checklist „šiestich právd“

DNS

• A a AAAA vedú na aktívne endpointy.
• Všetky autoritatívne servery vracajú konzistentné údaje.
• TTL je zrozumiteľný a monitorovaný.
• DNSSEC prechádza validáciou.
• www a apex majú zamýšľané správanie.
• Test bol vykonaný z viacerých resolverov a lokalít.

TLS

• Každá IP adresa vracia správny certifikát.
• SAN zahŕňa každý používaný hostname.
• Chain je kompletný.
• IPv4 a IPv6 majú rovnakú kvalitu konfigurácie.
• SNI vyberá správny virtual host.
• CDN a origin majú správny TLS.

Prehliadač

• Stránka funguje v čistom profile.
• Bola skontrolovaná neprihlásená verzia.
• Source HTML obsahuje kľúčový obsah a metadáta.
• DOM po renderovaní zodpovedá očakávaniu.
• Service worker a vyrovnávacia pamäť nemaskujú nasadenie.
• Mobilná verzia obsahuje plný obsah.
• Chyby API sú ošetrené.

Googlebot

• robots.txt umožňuje prevziať stránku a zdroje.
• noindex je v súlade so zámerom.
• Canonical je konzistentný s presmerovaniami a sitemapou.
• Hlavný obsah nevyžaduje kliknutie.
• Mobilný render obsahuje ten istý podstatný obsah.
• URL Inspection zobrazuje správny HTML a screenshot.
• Zdroje CSS a JS sú dostupné.

Sociálny crawler

• Základné Open Graph sa nachádza v počiatočnom HTML.
• og:url odkazuje na správnu trvalú URL.
• og:image je absolútna HTTPS adresa.
• Obrázok vracia 200 a správny MIME.
• Rozmery obrázka sú deklarované.
• Každá jazyková verzia má správne metadáta.
• Vyrovnávacia pamäť platformy bola po zmene obnovená.

Bezpečnosť

• Boli otestované hlavičky konečnej odpovede.
• Test zahŕňa viac než len homepage.
• Boli skontrolované endpointy po prihlásení.
• Používateľské roly boli otestované samostatne.
• Automatické výsledky overil človek.
• DAST bol doplnený o SAST a analýzu závislostí.
• Slabé alebo vysoké hodnotenie bolo interpretované v kontexte.

Nástroje POLPROG užitočné pri takomto audite

• Inšpektor DNS a SSL zobrazuje záznamy domény a údaje certifikátu.
• Open Graph Preview kontroluje metadáta a kartu zdieľania.
• Inšpektor bezpečnostných hlavičiek analyzuje hardening HTTP odpovedí.
• Kondícia webu spája signály SEO, výkonu, dostupnosti a bezpečnosti.
• FlowTrace vizualizuje cestu od udalosti v prehliadači cez DNS, TLS, CDN, backend a renderovanie.

Najčastejšie mýty

„Ak stránka funguje u mňa, funguje všade“

Nie. Tvoj resolver, IP protokol, vyrovnávacia pamäť, cookies a uzol CDN môžu byť iné.

„Google vidí presne to isté ako Chrome“

Google renderuje stránky pomocou Chrome, ale Googlebot má iný stav, mobile-first user-agent, samostatné fázy crawlovania a renderovania a nevykonáva obsah vyžadujúci interakciu.

„Robots.txt odstraňuje stránku z Google“

Nie. Robots.txt obmedzuje crawling. Na kontrolu indexovania slúži noindex, ktorý musí byť viditeľný pre crawler.

„Canonical núti Google použiť vybranú URL adresu“

Nie. Je to dôležitý signál, ale Google môže vybrať iný canonical.

„Zmenil som og:image, takže karta je už nová“

Nie vždy. Platforma môže používať uloženú verziu a vyžadovať opätovné prevzatie URL adresy.

„A+ v skeneri znamená, že aplikácia je bezpečná“

Nie. Znamená vysoké skóre v konkrétnej sade testov. Nedokazuje správnu autorizáciu, biznes logiku ani bezpečnosť kódu.

Verdikt

Jedna doména nemá jednu technickú „tvár“.

• DNS vidí názov a záznamy.
• TLS vidí endpoint a identitu certifikátu.
• Prehliadač vidí renderovaný zážitok konkrétneho používateľa.
• Googlebot vidí zdroj dostupný na crawlovanie, renderovanie a indexovanie.
• sociálny crawler vidí metadáta potrebné na zostavenie karty.
• bezpečnostný skener vidí výlučne povrch pokrytý jeho testami.

Zrelý audit sa teda nepýta len: „Funguje stránka?“

Pýta sa:

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?

Až odpovede na tieto otázky vytvárajú konzistentný obraz systému.