One Domain, Six Different Truths: What DNS, TLS, the Browser, Googlebot, a Social Crawler and a Security Scanner See

https://example.com/article

and receive six different reports:

• DNS returns two IP addresses,
• the TLS endpoint presents a certificate that does not cover www,
• your browser shows the correct personalized page,
• Googlebot indexes an older title,
• LinkedIn still displays the previous image,
• a security scanner gives the site a weak grade because important headers are missing.

None of those observations has to be false.

Each system sees a different part of the stack, uses a different cache, sends different request headers, may connect from another network and does not necessarily execute JavaScript in the same way. A website does not have one universal visible state. It has a collection of states observed by different clients.

The central point: a site can work correctly in its owner’s browser while some resolvers still return old DNS, one CDN edge serves the wrong certificate, Googlebot cannot reach the rendered content, a social platform uses stale metadata and a scanner detects weak HTTP hardening.

The phrase “six truths” is a metaphor for six valid observations, not six contradictory realities. Personalization, language variants, caching and distributed infrastructure are normal. The problem begins when a difference is unintended, unmonitored or prevents a specific client from reaching the intended result.

The behaviour and documentation described here were verified on 23 July 2026.

Six perspectives at a glance

Observer	What it evaluates	What it normally does not know	What may change the result
DNS	hostname, records, delegation, cache and DNSSEC	HTML, URL path, page title	resolver, TTL, region, IPv4/IPv6
TLS	endpoint, SNI, certificate, SAN, chain and protocol	content and SEO metadata	IP address, CDN edge, virtual-host setup
Browser	DNS, TLS, HTTP, HTML, CSS, JavaScript, cookies, cache and DOM	the state seen by other clients	user, viewport, locale, storage, service worker
Googlebot	crawl access, robots, HTTP, HTML, resources, rendering, canonical and noindex	content behind login or required interactions	mobile-first crawling, crawl cache, render queue
Social crawler	URL, redirects, metadata, preview image and platform cache	the full interactive application	platform, cache, Open Graph and image availability
Security scanner	the public attack surface within its configured scope	all business logic, source code and user roles	scanner type, authentication, path and test configuration

“The same domain” is often not the same request

Before comparing results, record the exact resource:

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

These requests may use different redirects, hosts, virtual servers, cache keys, canonicals, response headers and social-preview identities.

A reproducible audit records the complete URL, time, test region, user-agent, final status and redirect chain.

Truth 1: DNS sees a name, not a web page

For:

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

DNS resolves:

example.com

It does not inspect /article, ?id=42, the HTML title or the canonical element. DNS is a hierarchical naming system built around names and resource records.

A DNS inspection may find:

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"

It can also inspect NS, SOA, MX, TXT, HTTPS, SVCB and DNSSEC data.

Why can two clients receive different answers?

The simplest reason is caching. A resolver may retain an answer until its TTL expires. Negative answers such as NXDOMAIN can also be cached.

Other causes include:

• different recursive resolvers,
• cache entries created at different times,
• geographic DNS or load balancing,
• separate IPv4 and IPv6 paths,
• an in-progress provider migration,
• inconsistent authoritative servers,
• a broken DNSSEC chain.

DNSSEC authenticates the origin and integrity of DNS data, but it does not encrypt the query. An incorrect DS record may cause a validating resolver to return SERVFAIL while a non-validating resolver still returns an address.

What DNS cannot prove

A correct DNS answer does not prove that:

• the server is healthy,
• port 443 is reachable,
• the certificate is valid,
• the application returns 200,
• the page is indexable,
• security headers are configured.

DNS tells the client where to try. It does not describe what happens after the connection.

Truth 2: TLS sees endpoint identity, not article content

After resolving an address, the client negotiates TLS. When several domains share an IP address, Server Name Indication lets the client indicate the requested server name.

TLS inspection can reveal:

• protocol support,
• the negotiated connection,
• the server certificate,
• SAN hostnames,
• issuer and validity,
• intermediate certificates,
• ALPN negotiation.

TLS 1.3 is defined by RFC 8446 and protects data in transit between the endpoints.

The certificate belongs to names, not content

The client checks whether the requested hostname matches an identity in subjectAltName.

A certificate for:

example.com

does not automatically cover:

www.example.com
api.example.com

Likewise, *.example.com does not cover the apex example.com or a deeper name such as www.eu.example.com.

Why can users see different certificates?

• A and AAAA reach different servers,
• one CDN edge did not receive the new certificate,
• SNI maps to a wrong default virtual host,
• a region is served by another infrastructure cluster,
• the origin certificate differs from the public edge,
• one node sends an incomplete chain.

The user considers it one domain, while the network has reached different endpoints.

What TLS does not prove

Valid TLS does not establish that:

• application authorization is correct,
• JavaScript is free from XSS,
• canonical metadata is correct,
• Google will index the page,
• the Open Graph image is current,
• the backend is secure.

The lock icon indicates a protected connection to an accepted identity. It is not a certificate for the quality of the entire application.

Truth 3: the browser sees the outcome of the whole environment

A browser performs DNS resolution, transport and TLS setup, HTTP requests, HTML parsing, CSS and JavaScript loading, DOM and CSSOM construction, layout and painting.

The visible page can therefore differ from the original server HTML.

Source HTML, DOM and pixels are different layers

Server response:

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

DOM after JavaScript:

<div id="app">
  <h1>Report for the signed-in user</h1>
</div>

The final pixels also depend on CSS, fonts, viewport, image availability, device settings and interaction.

What personalizes the browser’s truth?

• session cookies,
• localStorage and sessionStorage,
• language and time zone,
• viewport width,
• prefers-color-scheme,
• accessibility preferences,
• A/B tests,
• API results,
• authentication state.

A browser also has a private HTTP cache and may reuse a fresh response without downloading it again.

A service worker can intercept requests and return cached or synthetic responses according to an application-defined strategy. That can explain why a normal reload displays old content while a private window shows the latest deployment.

Why “it works for me” is weak evidence

The owner may have an administrator session, cached assets, a stale service worker, privileged API access, a different locale or browser extensions that modify the page.

A browser test should include a clean profile, private mode, mobile viewport, signed-out state, IPv4 and IPv6.

Truth 4: Googlebot sees a resource prepared for crawling, rendering and indexing

Google describes JavaScript processing in three main phases:

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

Googlebot fetches a URL and may later pass it to the Web Rendering Service. Google uses a recent version of Chrome, but crawling and rendering are not guaranteed to occur as one immediate action.

Googlebot is not an ordinary user

Google operates Smartphone and Desktop crawlers. For most sites, indexing primarily uses the mobile version, and most crawl requests come from Googlebot Smartphone.

Googlebot does not have your login session or private browser storage. Google also states that it will not load primary content that requires user interactions such as clicking, swiping or typing.

Robots.txt is not noindex

robots.txt controls which URLs a crawler may request. Google explicitly says it is not a reliable mechanism for keeping a URL out of Search.

For noindex to work, Google must be allowed to fetch the page and see the directive.

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

or:

X-Robots-Tag: noindex

Blocking the same page in robots.txt can prevent Google from discovering that noindex.

Canonical is a hint

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

Google may choose another canonical because it evaluates several signals. Its documentation describes canonical preference as a hint, not a rule.

What can users see that Googlebot may not?

• content loaded only after a click,
• signed-in content,
• data from an API unavailable to the crawler,
• components dependent on blocked JavaScript,
• richer desktop content missing from mobile,
• state stored only in the user’s browser.

The safest implementation makes important content available without requiring user interaction and keeps essential CSS and JavaScript crawlable.

Truth 5: a social crawler builds a card, not the complete application

When a URL is pasted into Facebook, LinkedIn, Slack or another platform, the system may fetch it and build a preview. Do not assume that every platform runs the application exactly like a full user browser.

The most portable approach is to put the key metadata directly in the initial HTML <head>.

Open Graph basics

The Open Graph protocol defines four required properties:

<meta property="og:title" content="Article title">
<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/article">

Useful additions include og:description, image dimensions and og:image:alt.

Meta/Facebook

Meta recommends Open Graph tags so its crawler can retrieve a title, description and preview image. Meta also documents scraping and caching metadata when a URL is shared.

Changing an image on the origin therefore does not guarantee that every existing preview changes immediately.

LinkedIn

LinkedIn says link previews may rely on Open Graph or oEmbed. An old image can come from cache, and Post Inspector can refresh the URL for new shares.

Existing posts may retain the old card.

Slack

Slack documents classic unfurling as crawling a posted link and attaching a preview. Slack apps may also provide custom unfurls through its APIs.

A Slack card can therefore be either a standard crawl result or an application-generated preview.

Why do platforms show different images?

• one platform has stale cache,
• another cannot retrieve the image,
• the image URL redirects or returns a wrong status,
• MIME type is incorrect,
• several og:image values appear in a different order,
• language variants use different metadata,
• a CDN or firewall serves a different bot response,
• metadata is added only after JavaScript runs.

Publish essential social metadata in server HTML and use absolute HTTPS URLs.

Truth 6: a security scanner sees only the scope it can test

“Security scanner” may refer to a header analyzer, TLS scanner, DAST crawler, SAST tool, dependency scanner or infrastructure scanner.

Here we focus mainly on external tools that inspect a publicly reachable site.

What does a header scanner see?

MDN HTTP Observatory assesses HTTP headers and selected security configurations. It can evaluate CSP, HSTS, framing controls, X-Content-Type-Options, cookies and HTTPS behaviour.

It does not automatically read backend source code, database permissions, internal roles or every API endpoint.

A grade is not a verdict on the whole application

Observatory’s documentation explains that scores are intended to alert developers to missing modern protections and that the relevance of a particular header may depend on the site.

A site can earn a strong header grade and still contain:

• broken access control,
• IDOR,
• SQL injection,
• exposed secrets,
• vulnerable administration flows,
• exploitable business logic.

A JSON API may also score poorly for missing controls primarily designed for HTML documents, without that grade accurately describing the complete API posture.

DAST has wider reach and still has limits

OWASP describes web vulnerability scanners as automated external tools that search for vulnerabilities and insecure configuration.

ZAP warns that automated scans have limitations. Without configured authentication, pages behind login are not discovered, and a spider does not reproduce every realistic user workflow.

Results depend on the account, role, URL scope, forms, test data, user-agent, WAF limits, scan duration and JavaScript support.

A scanner says: “within this scope, these signals were or were not found.” It does not prove the absence of every vulnerability.

One URL, six valid reports

The following example is hypothetical but technically realistic.

URL:

https://example.com/report

DNS

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

Two possible endpoints exist.

TLS over IPv4

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

TLS over IPv6

SAN: old.example.net
TLS: 1.2
Chain: valid, hostname wrong

Some clients cannot open the page.

Owner’s browser

• uses IPv4,
• has an active session,
• receives content from a service-worker cache,
• displays the current report.

The owner concludes that everything works.

Googlebot Smartphone

• reaches IPv6,
• fails TLS,
• cannot fetch the page.

The new content is not crawled.

LinkedIn

• retains a preview fetched one week earlier,
• displays the old og:image.

The social card is stale.

Header scanner

• tests IPv4,
• fetches the public signed-out page,
• finds no CSP or HSTS.

The transport works, but HTTP hardening is incomplete.

Every report describes a different slice of the same system.

Symptom matrix

Symptom	Likely perspective	First check
Site fails only for some users	DNS, IPv6 or TLS	compare A, AAAA and both endpoints
Certificate belongs to another domain	TLS/SNI	openssl s_client -servername
Old page remains after deployment	browser cache or service worker	clean profile and Application panel
Google shows an older title	crawl/index cache or canonical	URL Inspection and rendered HTML
Page is missing from Search	robots, noindex or crawl errors	robots.txt and Search Console
LinkedIn shows the old image	platform cache	Post Inspector
Scanner reports no HSTS although HTTPS works	HTTP response headers	curl -I on the final URL
Scanner grade is high but access control fails	business logic outside scanner scope	role and authorization tests
Google receives reduced content	mobile-first difference	inspect mobile rendered output
noindex does not work	URL blocked in robots.txt	allow crawling and recrawl

A complete audit workflow

1. Record the redirect chain

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

Record status codes, host changes and the final URL.

2. Inspect DNS from more than one resolver

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

Compare recursive and authoritative answers.

3. Test every TLS endpoint

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

Repeat for IPv6 and every returned address.

4. Fetch the public response without browser state

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

Check status, Content-Type, cache controls, CSP, HSTS, X-Robots-Tag and the HTML <head>.

5. Compare source and rendered DOM

Inspect View Source, Elements, Network, Application, service workers, cache storage and cookies.

6. Inspect Google’s view

Use URL Inspection in Search Console to compare fetched HTML, rendered HTML, screenshot, unavailable resources, user-declared canonical and Google-selected canonical.

Do not identify Googlebot only by its user-agent. Google recommends reverse DNS verification or matching official Googlebot IP ranges.

7. Inspect social metadata

Check:

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

Then refresh the URL with the platform’s official tool.

8. Use several security test classes

Combine header analysis, TLS testing, DAST in a suitable environment, authorization testing, dependency analysis and code/configuration review.

A baseline <head> for different clients

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

  <title>One Domain, Six Different Truths</title>
  <meta
    name="description"
    content="How DNS, TLS, browsers, Googlebot, social crawlers and security scanners see the same domain."
  >

  <link rel="canonical" href="https://example.com/one-domain-six-truths">
  <meta name="robots" content="index,follow">

  <meta property="og:title" content="One Domain, Six Different Truths">
  <meta property="og:type" content="article">
  <meta property="og:url" content="https://example.com/one-domain-six-truths">
  <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="Six technical observers examining one domain">
</head>

Essential metadata is present in the initial response rather than being added only after the application starts.

Six-truth checklist

DNS

• A and AAAA reach active endpoints.
• Authoritative servers return consistent data.
• TTL is understood and monitored.
• DNSSEC validates.
• Apex and www behave intentionally.
• Tests run from several resolvers and regions.

TLS

• Every IP returns the correct certificate.
• SAN covers every hostname.
• The chain is complete.
• IPv4 and IPv6 have equivalent TLS quality.
• SNI selects the right virtual host.
• CDN and origin both have valid TLS.

Browser

• The page works in a clean profile.
• Signed-out behaviour is tested.
• Source HTML contains critical content and metadata.
• Rendered DOM is correct.
• Cache and service workers do not hide deployment problems.
• Mobile contains the same essential content.
• API failures are handled.

Googlebot

• robots.txt permits the page and required resources.
• noindex matches the intended policy.
• Canonical agrees with redirects and sitemap signals.
• Primary content does not require a click.
• Mobile rendering contains essential content.
• URL Inspection shows correct HTML and screenshot.
• CSS and JavaScript resources are accessible.

Social crawler

• Open Graph is present in initial HTML.
• og:url is the intended permanent URL.
• og:image uses an absolute HTTPS URL.
• The image returns 200 and a correct MIME type.
• Dimensions and alt text are declared.
• Language variants contain correct metadata.
• Platform cache is refreshed after major changes.

Security

• Final-response headers are tested.
• More than the homepage is covered.
• Authenticated endpoints are included.
• User roles are tested separately.
• Automated findings receive human review.
• DAST is supplemented with SAST and dependency analysis.
• Grades are interpreted in context.

Useful POLPROG tools

• DNS & SSL Inspector checks records and certificate details.
• Open Graph Preview inspects share metadata and preview cards.
• Security Headers Inspector evaluates HTTP hardening.
• Website Health Check combines SEO, performance, accessibility and security signals.
• FlowTrace visualizes the route through DNS, TLS, CDN, backend and browser rendering.

Common myths

“If it works for me, it works everywhere”

Your resolver, IP protocol, cache, cookies and CDN edge may be different.

“Google sees exactly what Chrome sees”

Google renders with Chrome technology, but Googlebot has another state, primarily mobile crawling, separate crawl/render stages and no user interactions for loading primary content.

“Robots.txt removes a page from Google”

It controls crawling. noindex controls indexing and must be visible to the crawler.

“Canonical forces Google to select my URL”

It is an important signal, not an unconditional command.

“I changed og:image, so every card is updated”

Platforms may continue using cached metadata.

“An A+ scanner grade means the application is secure”

It means the site performed well in that scanner’s tests. It does not prove correct authorization, business logic or secure source code.

Verdict

One domain does not have one technical face.

• DNS sees names and records.
• TLS sees an endpoint and certificate identity.
• A browser sees one user’s rendered experience.
• Googlebot sees a crawlable, renderable and indexable resource.
• A social crawler sees metadata used to build a card.
• A security scanner sees only the surface included in its tests.

A mature audit does not ask only, “Does the site work?”

It asks:

For whom?
From which network?
Over IPv4 or IPv6?
With what cache state?
With which user-agent?
Before or after JavaScript?
Signed in or signed out?
Within what test scope?

Only those answers produce a coherent view of the system.