Jedna domena, sześć różnych prawd: co widzą DNS, TLS, przeglądarka, Googlebot, crawler społecznościowy i skaner bezpieczeństwa

https://example.com/artykul

i otrzymujesz sześć różnych odpowiedzi:

• DNS twierdzi, że domena prowadzi do dwóch adresów IP,
• warstwa TLS widzi certyfikat, który nie obejmuje www,
• Twoja przeglądarka pokazuje poprawną, spersonalizowaną stronę,
• Googlebot indeksuje starszy tytuł,
• LinkedIn nadal wyświetla poprzedni obraz,
• skaner bezpieczeństwa przyznaje słabą ocenę z powodu brakujących nagłówków.

Żadna z tych obserwacji nie musi być fałszywa.

Każdy system patrzy na inny fragment stosu, korzysta z innego cache, wysyła inny zestaw nagłówków, może łączyć się z innej lokalizacji i nie zawsze wykonuje JavaScript w taki sam sposób. „Prawda strony internetowej” nie jest jednym dokumentem. Jest zbiorem stanów widocznych dla różnych klientów.

Najważniejszy wniosek: domena może działać poprawnie w przeglądarce właściciela, a jednocześnie mieć błędne DNS dla części resolverów, nieprawidłowy certyfikat na jednym węźle CDN, nieindeksowalną treść dla Googlebota, stary podgląd społecznościowy i słabe zabezpieczenia odpowiedzi HTTP.

Artykuł nie zakłada, że każda różnica jest błędem. Personalizacja, warianty językowe, cache i infrastruktura rozproszona są normalne. Problem zaczyna się wtedy, gdy różnica jest niezamierzona, niewidoczna w monitoringu albo uniemożliwia określonemu klientowi dotarcie do właściwej wersji.

Dokumentację i zachowanie opisanych systemów zweryfikowano 23 lipca 2026 roku.

Sześć perspektyw w jednej tabeli

Obserwator	Co rzeczywiście sprawdza	Czego zwykle nie zna	Co może zmienić wynik
DNS	nazwę hosta, rekordy, delegację, cache, DNSSEC	treść HTML, ścieżkę URL, tytuł strony	resolver, TTL, region, IPv4/IPv6
TLS	endpoint, SNI, certyfikat, SAN, chain, protokół	treść strony i jej SEO	adres IP, węzeł CDN, konfiguracja virtual host
Przeglądarka	DNS, TLS, HTTP, HTML, CSS, JavaScript, cookies, cache, DOM	intencję autora i stan innych klientów	użytkownik, viewport, locale, storage, service worker
Googlebot	dostępność, robots, HTTP, HTML, zasoby, renderowanie, canonical, noindex	treść wymagającą logowania lub interakcji	mobile-first, crawl cache, render queue, blokady zasobów
Crawler społecznościowy	URL, redirect, metadata, obraz podglądu, cache platformy	pełne doświadczenie aplikacji	platforma, cache, Open Graph, dostępność obrazu
Skaner bezpieczeństwa	publiczną powierzchnię i testy w swoim zakresie	całą logikę biznesową, kod i role użytkowników	typ skanera, autoryzacja, ścieżka, konfiguracja testu

„Ta sama domena” nie zawsze oznacza ten sam test

Zanim porównasz wyniki, ustal dokładnie badany zasób:

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

To nie są technicznie identyczne żądania. Mogą:

• prowadzić przez inne przekierowania,
• używać innych hostów,
• trafić do innego virtual hosta,
• mieć inne reguły cache,
• wskazywać różne canonicale,
• zwracać inne nagłówki,
• wywoływać osobne karty społecznościowe.

Audyt powinien zawsze zapisywać pełny URL, czas, lokalizację testu, user-agent, status końcowy i łańcuch przekierowań.

Prawda numer 1: DNS widzi nazwę, nie stronę

DNS tłumaczy nazwę hosta na dane potrzebne do odnalezienia usługi. W typowym zapytaniu dla:

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

DNS interesuje nazwa:

example.com

Nie analizuje ścieżki /artykul, parametrów ?id=42, tytułu HTML ani znacznika canonical. DNS jest hierarchicznym systemem nazw i rekordów zasobów.

Co może zobaczyć diagnostyka DNS?

Między innymi:

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"

Może również sprawdzić:

• serwery NS,
• rekord SOA,
• pocztę MX,
• dane TXT,
• rekordy HTTPS i SVCB,
• podpisy DNSSEC.

Dlaczego dwie osoby mogą otrzymać różne odpowiedzi?

Najprostsza przyczyna to cache. Resolver może przechowywać odpowiedź do czasu wygaśnięcia TTL. Negatywne odpowiedzi, takie jak NXDOMAIN, również mogą być cache’owane.

Różnice mogą wynikać także z:

• różnych resolverów,
• odmiennych wersji cache,
• infrastruktury geograficznej lub load balancingu DNS,
• osobnych odpowiedzi dla IPv4 i IPv6,
• migracji między operatorami,
• niespójnych serwerów autorytatywnych,
• uszkodzonego łańcucha DNSSEC.

DNSSEC uwierzytelnia pochodzenie i integralność danych DNS, ale nie szyfruje samego zapytania. Błędny rekord DS może sprawić, że resolver walidujący zwróci SERVFAIL, podczas gdy resolver bez walidacji nadal pokaże adres.

Czego DNS nie potwierdza?

Poprawna odpowiedź DNS nie dowodzi, że:

• serwer działa,
• port 443 jest otwarty,
• certyfikat jest poprawny,
• aplikacja zwraca kod 200,
• strona jest indeksowalna,
• nagłówki bezpieczeństwa są wdrożone.

DNS mówi, gdzie klient ma spróbować się połączyć. Nie mówi, co znajdzie po połączeniu.

Prawda numer 2: TLS widzi tożsamość endpointu, nie treść artykułu

Po odnalezieniu adresu klient tworzy połączenie z serwerem i negocjuje TLS. W środowisku obsługującym wiele domen na jednym adresie rozszerzenie SNI pozwala klientowi podać nazwę serwera, dla której chce uzyskać połączenie.

Warstwa TLS może ujawnić między innymi:

• obsługiwane wersje protokołu,
• wynegocjowany algorytm,
• certyfikat serwera,
• nazwy SAN,
• urząd certyfikacji,
• datę ważności,
• certyfikaty pośrednie,
• wynik negocjacji ALPN, na przykład HTTP/2.

TLS 1.3 jest zdefiniowany w RFC 8446 i chroni transport danych pomiędzy klientem a serwerem.

Certyfikat odpowiada nazwie, nie zawartości

Klient sprawdza, czy nazwa hosta pasuje do tożsamości zapisanej w certyfikacie, przede wszystkim w subjectAltName.

Certyfikat dla:

example.com

nie musi obejmować:

www.example.com
api.example.com

Wildcard:

*.example.com

nie obejmuje automatycznie domeny głównej example.com ani wielopoziomowego www.eu.example.com.

Dlaczego jeden użytkownik widzi poprawny certyfikat, a inny nie?

Możliwe scenariusze:

• A i AAAA prowadzą do różnych serwerów,
• jeden węzeł CDN nie otrzymał nowego certyfikatu,
• konfiguracja SNI ma błędny default virtual host,
• ruch z określonego regionu trafia do innej infrastruktury,
• origin ma inny certyfikat niż publiczny edge,
• część serwerów wysyła niepełny chain.

To nadal jest „ta sama domena” z perspektywy użytkownika, ale nie ten sam endpoint z perspektywy sieci.

Czego TLS nie wie?

Poprawny TLS nie dowodzi, że:

• strona jest bezpieczna aplikacyjnie,
• JavaScript nie ma XSS,
• użytkownik ma właściwe uprawnienia,
• canonical jest prawidłowy,
• Google zindeksuje treść,
• karta Open Graph ma dobry obraz.

Zielona kłódka oznacza chronione połączenie z nazwą zaakceptowaną przez klienta. Nie jest certyfikatem jakości całej aplikacji.

Prawda numer 3: przeglądarka widzi wynik działania całego środowiska

Przeglądarka wykonuje znacznie więcej pracy niż zwykłe pobranie HTML. Typowa nawigacja obejmuje DNS, połączenie transportowe, TLS, żądanie HTTP, analizę HTML, pobieranie CSS i JavaScriptu, budowę DOM i CSSOM, layout oraz renderowanie pikseli.

To, co użytkownik widzi na ekranie, może być inne niż kod źródłowy odpowiedzi.

Source HTML, DOM i ekran to trzy różne rzeczy

HTML z serwera

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

DOM po wykonaniu JavaScriptu

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

Obraz na ekranie

Na końcowy wygląd wpływają jeszcze CSS, fonty, rozmiar viewportu, dostępność obrazów, ustawienia systemowe i interakcje użytkownika.

Co personalizuje „prawdę przeglądarki”?

• cookies i sesja,
• localStorage oraz sessionStorage,
• język przeglądarki,
• strefa czasowa,
• szerokość ekranu,
• prefers-color-scheme,
• prefers-reduced-motion,
• uprawnienia,
• eksperyment A/B,
• odpowiedzi API,
• stan logowania.

Przeglądarka ma również prywatny cache HTTP. Odpowiedź zapisana jako świeża może zostać użyta bez ponownego pobrania, zależnie od dyrektyw cache.

Service worker może przechwytywać żądania i zwracać dane z własnego cache albo z niestandardowej strategii offline. To tłumaczy sytuacje, w których zwykłe odświeżenie nadal pokazuje starą wersję, a tryb prywatny prezentuje nową.

Dlaczego „u mnie działa” jest słabym testem?

Właściciel strony może mieć:

• aktywną sesję administratora,
• dane w cache,
• stary service worker,
• dostęp do API niedostępnego publicznie,
• inny język i region,
• rozszerzenia modyfikujące stronę,
• pominięty baner lub onboarding.

Test przeglądarkowy powinien obejmować czysty profil, tryb prywatny, urządzenie mobilne, IPv4, IPv6 oraz użytkownika niezalogowanego.

Prawda numer 4: Googlebot widzi stronę przeznaczoną do crawlowania, renderowania i indeksowania

Google opisuje obsługę stron JavaScriptowych jako trzy główne fazy:

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

Googlebot pobiera URL, analizuje odpowiedź i może przekazać stronę do Web Rendering Service. Google używa do renderowania aktualnej wersji Chrome, ale wynik nie musi powstać w tym samym momencie co pierwsze pobranie.

Googlebot nie jest zwykłym użytkownikiem

Google ma Googlebota Smartphone i Desktop, a dla większości stron indeksuje przede wszystkim wersję mobilną. Większość żądań pochodzi więc od crawlera mobilnego.

Googlebot:

• nie loguje się do Twojego konta,
• nie ma Twoich cookies,
• nie widzi prywatnych danych,
• nie zachowuje się jak użytkownik wykonujący wszystkie scenariusze,
• może pobierać zasoby osobno,
• podlega robots.txt i kontrolom indeksowania.

Google wyraźnie informuje, że nie załaduje głównej treści wymagającej interakcji, takiej jak kliknięcie, wpisanie danych lub przesunięcie elementu.

Robots.txt nie jest tym samym co noindex

robots.txt kontroluje, które URL-e crawler może pobierać. Google podkreśla, że nie jest to mechanizm gwarantujący usunięcie URL-a z wyników.

Aby noindex zadziałał, crawler musi móc pobrać stronę i zobaczyć tag lub nagłówek. Jeżeli URL jest jednocześnie zablokowany w robots.txt, Google może nie zobaczyć noindex.

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

lub:

X-Robots-Tag: noindex

Canonical jest wskazówką, nie bezwarunkowym poleceniem

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

Google może wybrać inną wersję canonical niż wskazana przez właściciela, ponieważ canonicalizacja uwzględnia wiele sygnałów. Google określa wskazanie canonical jako podpowiedź, nie regułę.

Co może zobaczyć użytkownik, ale nie Googlebot?

• treść dopiero po kliknięciu „Pokaż więcej”,
• dane dostępne tylko po zalogowaniu,
• element zależny od niedostępnego API,
• content ładowany przez zablokowany skrypt,
• desktopową wersję bogatszą od mobilnej,
• komponent działający tylko z danymi zapisanymi w przeglądarce.

Co może zobaczyć Googlebot, ale nie typowy użytkownik?

Na przykład serwer może zwracać inny wariant dla jego user-agenta. Samo dostosowanie techniczne nie jest automatycznie naruszeniem, ale celowe pokazywanie wyszukiwarce treści zasadniczo innej niż użytkownikom może być traktowane jako cloaking.

Najbezpieczniejsza praktyka to udostępnienie tej samej istotnej treści w początkowej odpowiedzi lub w renderowaniu, które nie wymaga interakcji użytkownika.

Prawda numer 5: crawler społecznościowy buduje kartę, nie pełne doświadczenie strony

Kiedy URL zostaje wklejony do Facebooka, LinkedIna, Slacka lub innej platformy, system może pobrać stronę i zbudować podgląd. Nie należy zakładać, że każda platforma wykonuje aplikację JavaScript dokładnie tak jak pełna przeglądarka użytkownika.

Najbardziej przenośnym sposobem opisania strony jest metadata umieszczona w <head> początkowego HTML.

Podstawowe Open Graph

Specyfikacja Open Graph definiuje cztery wymagane właściwości:

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

W praktyce warto dodać:

<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 zaleca używanie tagów Open Graph, aby crawler mógł pobrać tytuł, opis i obraz podglądu. Dokumentacja Meta opisuje również pobieranie i cache’owanie metadanych przy udostępnieniu URL-a.

Oznacza to, że zmiana obrazu na serwerze nie musi natychmiast zmienić istniejącej karty. Platforma może nadal posiadać starszy snapshot.

LinkedIn

LinkedIn informuje, że podglądy wykorzystują między innymi Open Graph lub oEmbed. Stary obraz może pochodzić z cache, a Post Inspector pozwala odświeżyć dane dla nowych udostępnień.

Istniejące posty mogą zachować poprzedni podgląd nawet po odświeżeniu URL-a.

Slack

Slack dokumentuje klasyczne unfurling jako proces, w którym po wykryciu linku system crawluje stronę i tworzy podgląd. Aplikacje Slack mogą również dostarczać własne, programowalne unfurle.

To ważne rozróżnienie: karta w Slacku może być standardowym wynikiem crawlowania albo niestandardowym obiektem zwróconym przez integrację.

Dlaczego platformy pokazują inne obrazy?

• jedna platforma ma stary cache,
• inna nie może pobrać obrazu,
• URL obrazu przekierowuje,
• obraz ma niedostępny MIME lub kod statusu,
• kilka og:image ma inną kolejność,
• strona ma osobne tagi dla różnych wersji językowych,
• bot otrzymuje inny wariant przez CDN lub firewall,
• metadata jest dodawana dopiero przez JavaScript.

Najbezpieczniej umieszczać podstawowe tagi społecznościowe bezpośrednio w HTML z serwera i podawać absolutne adresy HTTPS.

Prawda numer 6: skaner bezpieczeństwa widzi tylko zakres, który potrafi zbadać

„Skaner bezpieczeństwa” może oznaczać bardzo różne narzędzia:

• analizator nagłówków HTTP,
• skaner konfiguracji TLS,
• DAST wykonujący żądania i testy podatności,
• crawler aplikacji,
• SAST analizujący kod,
• skaner zależności,
• narzędzie do testowania infrastruktury.

W tym artykule mówimy głównie o skanerze zewnętrznym, który bada publicznie dostępną stronę.

Co widzi skaner nagłówków?

MDN HTTP Observatory ocenia przede wszystkim nagłówki HTTP i wybrane konfiguracje bezpieczeństwa.

Może sprawdzić między innymi:

• CSP,
• HSTS,
• ochronę przed framingiem,
• X-Content-Type-Options,
• cookies,
• przekierowanie do HTTPS,
• wybrane polityki cross-origin.

Nie oznacza to, że odczytał kod backendu, role użytkowników, konfigurację bazy danych lub wszystkie endpointy API.

Ocena literowa nie jest werdyktem o całym bezpieczeństwie

Dokumentacja Observatory zaznacza, że scoring ma wskazywać niewykorzystane mechanizmy bezpieczeństwa, a potrzeba konkretnego nagłówka może zależeć od rodzaju witryny.

Strona może uzyskać wysoki wynik nagłówków, a nadal posiadać:

• IDOR,
• błędną autoryzację,
• SQL Injection,
• podatny panel administracyjny,
• ujawnione klucze,
• logikę biznesową pozwalającą na nadużycia.

Możliwa jest też sytuacja odwrotna: prosty endpoint JSON otrzyma słabszą ocenę za brak nagłówków typowych dla dokumentu HTML, mimo że niektóre z nich nie mają dla niego takiego samego znaczenia.

DAST ma inny zakres, ale również ograniczenia

OWASP opisuje web application vulnerability scanners jako narzędzia zewnętrznie testujące aplikacje pod kątem podatności i błędnej konfiguracji.

ZAP ostrzega, że automatyczne skanowanie ma ograniczenia. Bez skonfigurowanego uwierzytelnienia nie odkryje stron za logowaniem, a automatyczny spider nie wykona wszystkich realistycznych procesów użytkownika.

Wynik zależy od:

• konta i roli użytej w teście,
• dostępnych URL-i,
• formularzy i danych testowych,
• zakresu domen,
• user-agenta,
• limitów WAF,
• czasu skanowania,
• tego, czy skaner wykonuje JavaScript.

Skaner mówi: „w tym zakresie znalazłem lub nie znalazłem określone sygnały”. Nie mówi: „udowodniłem brak wszystkich podatności”.

Jeden URL, sześć poprawnych raportów

Poniższy przykład jest hipotetyczny, ale technicznie realistyczny.

Badany adres:

https://example.com/raport

DNS

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

Wniosek: domena ma dwa możliwe endpointy.

TLS po IPv4

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

TLS po IPv6

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

Wniosek: część klientów nie otworzy strony.

Przeglądarka właściciela

• korzysta z IPv4,
• ma aktywną sesję,
• service worker zwraca wersję z cache,
• pokazuje aktualny raport.

Wniosek użytkownika: „wszystko działa”.

Googlebot Smartphone

• trafia po IPv6,
• nie może przejść TLS,
• nie pobiera strony.

Wniosek SEO: nowa treść nie jest crawlowana.

LinkedIn

• ma podgląd zapisany tydzień wcześniej,
• pokazuje poprzedni og:image.

Wniosek marketingowy: karta jest nieaktualna.

Skaner nagłówków

• testuje IPv4,
• pobiera dokument bez logowania,
• wykrywa brak CSP i HSTS.

Wniosek bezpieczeństwa: transport działa, ale hardening odpowiedzi jest niepełny.

Wszystkie raporty opisują inny fragment systemu.

Macierz symptomów

Symptom	Najbardziej prawdopodobna perspektywa	Pierwszy test
Strona działa tylko części użytkowników	DNS, IPv6 lub TLS	dig A/AAAA, test obu adresów
Certyfikat innej domeny	TLS/SNI	openssl s_client -servername
Po wdrożeniu nadal widać starą stronę	cache przeglądarki lub service worker	czysty profil, DevTools Application
Google pokazuje stary tytuł	crawl/index cache lub inny canonical	URL Inspection, sprawdzenie rendered HTML
Strony nie ma w indeksie	robots, noindex, błędy crawlowania	robots.txt, Search Console
Facebook lub LinkedIn pokazuje stary obraz	cache crawlera społecznościowego	debugger lub Post Inspector
Skaner pokazuje brak HSTS, a przeglądarka używa HTTPS	nagłówki odpowiedzi	curl -I dla finalnego URL-a
Wynik skanera jest dobry, ale funkcja ma błąd dostępu	logika aplikacji poza zakresem skanera	test autoryzacji i ról
Mobilna treść jest uboższa w Google	mobile-first i różny content	porównanie mobilnego renderu
noindex nie działa	URL zablokowany w robots.txt	umożliwienie crawlowania i ponowny test

Metodyka pełnego audytu

1. Zapisz pełny łańcuch URL

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

Zwróć uwagę na:

• statusy,
• zmianę hosta,
• przejście HTTP→HTTPS,
• końcowy URL,
• liczbę przekierowań.

2. Sprawdź DNS z kilku resolverów

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

Porównaj odpowiedzi z resolverem operatora, publicznym resolverem i autorytatywnym serwerem.

3. Sprawdź każdy endpoint TLS

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

Powtórz dla IPv6 i innych adresów zwróconych przez DNS.

4. Sprawdź odpowiedź HTTP bez stanu użytkownika

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

Zweryfikuj:

• kod statusu,
• Content-Type,
• cache,
• CSP,
• HSTS,
• X-Robots-Tag,
• treść <head>.

5. Porównaj source HTML i DOM

W przeglądarce sprawdź:

• View Source,
• panel Elements,
• Network,
• Application,
• aktywny service worker,
• cache storage,
• cookies.

6. Sprawdź Googlebota

Użyj narzędzia URL Inspection w Google Search Console i porównaj:

• HTML pobrany,
• HTML wyrenderowany,
• screenshot,
• zasoby, których nie udało się załadować,
• canonical wskazany i wybrany przez Google,
• możliwość indeksowania.

Nie identyfikuj Googlebota wyłącznie po user-agencie. Google zaleca weryfikację przez reverse DNS lub oficjalne zakresy IP.

7. Sprawdź kartę społecznościową

Przeanalizuj:

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

Następnie użyj narzędzi odświeżających konkretnej platformy.

8. Uruchom kilka klas testów bezpieczeństwa

• analizę nagłówków,
• test TLS,
• DAST na środowisku do tego przeznaczonym,
• testy uwierzytelnienia i autoryzacji,
• analizę zależności,
• przegląd kodu i konfiguracji.

Jedna ocena nie zastępuje pozostałych.

Wzorcowy <head> dostępny dla różnych klientów

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

Najważniejsze metadane są w odpowiedzi HTML, a nie dopiero po uruchomieniu aplikacji.

Praktyczna checklista „sześciu prawd”

DNS

• A i AAAA prowadzą do aktywnych endpointów.
• Wszystkie serwery autorytatywne zwracają spójne dane.
• TTL jest zrozumiały i monitorowany.
• DNSSEC przechodzi walidację.
• www i apex mają zamierzone zachowanie.
• Test wykonano z kilku resolverów i lokalizacji.

TLS

• Każdy adres IP zwraca właściwy certyfikat.
• SAN obejmuje każdy używany hostname.
• Chain jest kompletny.
• IPv4 i IPv6 mają tę samą jakość konfiguracji.
• SNI wybiera właściwy virtual host.
• CDN i origin mają poprawny TLS.

Przeglądarka

• Strona działa w czystym profilu.
• Sprawdzono wersję niezalogowaną.
• Source HTML zawiera kluczową treść i metadata.
• DOM po renderowaniu jest zgodny z oczekiwaniem.
• Service worker i cache nie maskują wdrożenia.
• Wersja mobilna zawiera pełną treść.
• Błędy API są obsługiwane.

Googlebot

• robots.txt pozwala pobrać stronę i zasoby.
• noindex jest zgodny z zamiarem.
• Canonical jest spójny z redirectami i sitemapą.
• Główna treść nie wymaga kliknięcia.
• Mobilny render zawiera tę samą istotną treść.
• URL Inspection pokazuje poprawny HTML i screenshot.
• Zasoby CSS i JS są dostępne.

Crawler społecznościowy

• Podstawowe Open Graph znajduje się w początkowym HTML.
• og:url wskazuje właściwy stały URL.
• og:image jest absolutnym adresem HTTPS.
• Obraz zwraca 200 i poprawny MIME.
• Wymiary obrazu są zadeklarowane.
• Każda wersja językowa ma właściwą metadata.
• Cache platformy został odświeżony po zmianie.

Bezpieczeństwo

• Przetestowano nagłówki finalnej odpowiedzi.
• Test obejmuje więcej niż homepage.
• Sprawdzono endpointy po zalogowaniu.
• Role użytkowników zostały przetestowane osobno.
• Wyniki automatyczne zweryfikował człowiek.
• DAST uzupełniono SAST i analizą zależności.
• Słaba lub wysoka ocena została zinterpretowana w kontekście.

Narzędzia POLPROG przydatne w takim audycie

• Inspektor DNS i SSL pokazuje rekordy domeny i dane certyfikatu.
• Open Graph Preview sprawdza metadata i kartę udostępniania.
• Inspektor nagłówków bezpieczeństwa analizuje hardening odpowiedzi HTTP.
• Kondycja witryny łączy sygnały SEO, wydajności, dostępności i bezpieczeństwa.
• FlowTrace wizualizuje drogę od zdarzenia w przeglądarce przez DNS, TLS, CDN, backend i renderowanie.

Najczęstsze mity

„Jeżeli strona działa u mnie, działa wszędzie”

Nie. Twój resolver, protokół IP, cache, cookies i węzeł CDN mogą być inne.

„Google widzi dokładnie to samo co Chrome”

Google renderuje strony za pomocą Chrome, ale Googlebot ma inny stan, mobile-first user-agent, osobne fazy crawlowania i renderowania oraz nie wykonuje treści wymagającej interakcji.

„Robots.txt usuwa stronę z Google”

Nie. Robots.txt ogranicza crawling. Do kontroli indeksowania służy noindex, który musi być widoczny dla crawlera.

„Canonical zmusza Google do użycia wybranego URL-a”

Nie. Jest ważnym sygnałem, ale Google może wybrać inny canonical.

„Zmieniłem og:image, więc karta jest już nowa”

Nie zawsze. Platforma może używać zapisanej wersji i wymagać ponownego pobrania URL-a.

„A+ w skanerze oznacza, że aplikacja jest bezpieczna”

Nie. Oznacza wysoki wynik w konkretnym zestawie testów. Nie dowodzi poprawnej autoryzacji, logiki biznesowej ani bezpieczeństwa kodu.

Werdykt

Jedna domena nie ma jednej technicznej „twarzy”.

• DNS widzi nazwę i rekordy.
• TLS widzi endpoint i tożsamość certyfikatu.
• Przeglądarka widzi wyrenderowane doświadczenie konkretnego użytkownika.
• Googlebot widzi zasób dostępny do crawlowania, renderowania i indeksowania.
• crawler społecznościowy widzi metadata potrzebną do zbudowania karty.
• skaner bezpieczeństwa widzi wyłącznie powierzchnię objętą jego testami.

Dojrzały audyt nie pyta więc tylko: „Czy strona działa?”

Pyta:

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?

Dopiero odpowiedzi na te pytania tworzą spójny obraz systemu.