Eine Domain, sechs verschiedene Wahrheiten: Was DNS, TLS, Browser, Googlebot, Social Crawler und Sicherheitsscanner sehen

https://example.com/artykul

und du erhältst sechs verschiedene Antworten:

• DNS behauptet, dass die Domain auf zwei IP-Adressen verweist,
• die TLS-Schicht sieht ein Zertifikat, das www nicht abdeckt,
• dein Browser zeigt eine korrekte, personalisierte Seite an,
• Googlebot indexiert einen älteren Titel,
• LinkedIn zeigt weiterhin das vorherige Bild an,
• der Sicherheitsscanner vergibt eine schlechte Bewertung wegen fehlender Header.

Keine dieser Beobachtungen muss falsch sein.

Jedes System betrachtet einen anderen Ausschnitt des Stacks, nutzt einen anderen Cache, sendet einen anderen Satz von Headern, verbindet sich möglicherweise von einem anderen Standort aus und führt JavaScript nicht immer auf dieselbe Weise aus. Die „Wahrheit einer Website“ ist kein einzelnes Dokument. Sie ist eine Sammlung von Zuständen, die für verschiedene Clients sichtbar sind.

Wichtigste Erkenntnis: Eine Domain kann im Browser des Eigentümers korrekt funktionieren und gleichzeitig für einen Teil der Resolver fehlerhaftes DNS haben, ein ungültiges Zertifikat an einem CDN-Knoten, für Googlebot nicht indexierbaren Inhalt, eine veraltete Social-Media-Vorschau und schwache Sicherheitsvorkehrungen der HTTP-Antwort.

Der Artikel geht nicht davon aus, dass jeder Unterschied ein Fehler ist. Personalisierung, Sprachvarianten, Cache und verteilte Infrastruktur sind normal. Das Problem beginnt dann, wenn ein Unterschied unbeabsichtigt ist, im Monitoring nicht sichtbar ist oder einen bestimmten Client daran hindert, die richtige Version zu erreichen.

Die Dokumentation und das Verhalten der beschriebenen Systeme wurden am 23. Juli 2026 überprüft.

Sechs Perspektiven in einer Tabelle

Beobachter	Was er tatsächlich prüft	Was er in der Regel nicht kennt	Was das Ergebnis verändern kann
DNS	Hostnamen, Records, Delegierung, Cache, DNSSEC	HTML-Inhalt, URL-Pfad, Seitentitel	Resolver, TTL, Region, IPv4/IPv6
TLS	Endpoint, SNI, Zertifikat, SAN, Chain, Protokoll	Seiteninhalt und dessen SEO	IP-Adresse, CDN-Knoten, Virtual-Host-Konfiguration
Browser	DNS, TLS, HTTP, HTML, CSS, JavaScript, Cookies, Cache, DOM	die Absicht des Autors und den Zustand anderer Clients	Nutzer, Viewport, Locale, Storage, Service Worker
Googlebot	Erreichbarkeit, robots, HTTP, HTML, Ressourcen, Rendering, Canonical, noindex	Inhalte, die Login oder Interaktion erfordern	Mobile-First, Crawl-Cache, Render-Queue, Ressourcensperren
Social-Media-Crawler	URL, Redirect, Metadaten, Vorschaubild, Plattform-Cache	das vollständige App-Erlebnis	Plattform, Cache, Open Graph, Bildverfügbarkeit
Sicherheitsscanner	die öffentliche Angriffsfläche und Tests in seinem Umfang	die gesamte Geschäftslogik, den Code und die Nutzerrollen	Scanner-Typ, Autorisierung, Pfad, Testkonfiguration

„Dieselbe Domain“ bedeutet nicht immer denselben Test

Bevor du Ergebnisse vergleichst, lege genau die untersuchte Ressource fest:

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

Das sind technisch keine identischen Anfragen. Sie können:

• über andere Weiterleitungen führen,
• andere Hosts verwenden,
• zu einem anderen Virtual Host gelangen,
• andere Cache-Regeln haben,
• auf unterschiedliche Canonicals verweisen,
• andere Header zurückgeben,
• separate Social-Media-Karten auslösen.

Ein Audit sollte immer die vollständige URL, den Zeitpunkt, den Teststandort, den User-Agent, den finalen Status und die Weiterleitungskette festhalten.

Wahrheit Nummer 1: DNS sieht den Namen, nicht die Seite

DNS übersetzt den Hostnamen in die Daten, die zum Auffinden des Dienstes benötigt werden. Bei einer typischen Abfrage für:

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

interessiert sich DNS für den Namen:

example.com

Es analysiert weder den Pfad /artykul, die Parameter ?id=42, den HTML-Titel noch das Canonical-Tag. DNS ist ein hierarchisches System von Namen und Ressourcen-Records.

Was kann die DNS-Diagnostik sehen?

Unter anderem:

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"

Sie kann außerdem prüfen:

• die NS-Server,
• den SOA-Record,
• die MX-Mailserver,
• die TXT-Daten,
• die HTTPS- und SVCB-Records,
• die DNSSEC-Signaturen.

Warum können zwei Personen unterschiedliche Antworten erhalten?

Die einfachste Ursache ist der Cache. Ein Resolver kann eine Antwort bis zum Ablauf der TTL speichern. Negative Antworten wie NXDOMAIN können ebenfalls gecacht werden.

Unterschiede können außerdem entstehen durch:

• verschiedene Resolver,
• abweichende Cache-Versionen,
• geografische Infrastruktur oder DNS-Load-Balancing,
• separate Antworten für IPv4 und IPv6,
• Migration zwischen Anbietern,
• inkonsistente autoritative Server,
• eine beschädigte DNSSEC-Kette.

DNSSEC authentifiziert die Herkunft und Integrität von DNS-Daten, verschlüsselt aber nicht die Abfrage selbst. Ein fehlerhafter DS-Record kann dazu führen, dass ein validierender Resolver SERVFAIL zurückgibt, während ein Resolver ohne Validierung weiterhin die Adresse anzeigt.

Was bestätigt DNS nicht?

Eine korrekte DNS-Antwort beweist nicht, dass:

• der Server läuft,
• Port 443 geöffnet ist,
• das Zertifikat gültig ist,
• die Anwendung den Code 200 zurückgibt,
• die Seite indexierbar ist,
• die Sicherheits-Header implementiert sind.

DNS sagt, wo der Client versuchen soll, sich zu verbinden. Es sagt nicht, was er nach dem Verbinden vorfindet.

Wahrheit Nummer 2: TLS sieht die Identität des Endpoints, nicht den Inhalt des Artikels

Nachdem die Adresse gefunden wurde, baut der Client eine Verbindung zum Server auf und handelt TLS aus. In einer Umgebung, die mehrere Domains auf einer Adresse betreibt, erlaubt die SNI-Erweiterung dem Client, den Servernamen anzugeben, für den er die Verbindung herstellen möchte.

Die TLS-Schicht kann unter anderem offenlegen:

• die unterstützten Protokollversionen,
• den ausgehandelten Algorithmus,
• das Serverzertifikat,
• die SAN-Namen,
• die Zertifizierungsstelle,
• das Gültigkeitsdatum,
• die Zwischenzertifikate,
• das Ergebnis der ALPN-Aushandlung, zum Beispiel HTTP/2.

TLS 1.3 ist in RFC 8446 definiert und schützt den Datentransport zwischen Client und Server.

Das Zertifikat entspricht dem Namen, nicht dem Inhalt

Der Client prüft, ob der Hostname zur im Zertifikat hinterlegten Identität passt, vor allem im subjectAltName.

Ein Zertifikat für:

example.com

muss nicht abdecken:

www.example.com
api.example.com

Ein Wildcard:

*.example.com

deckt weder automatisch die Hauptdomain example.com noch das mehrstufige www.eu.example.com ab.

Warum sieht ein Nutzer ein gültiges Zertifikat und ein anderer nicht?

Mögliche Szenarien:

• A und AAAA verweisen auf verschiedene Server,
• ein CDN-Knoten hat das neue Zertifikat nicht erhalten,
• die SNI-Konfiguration hat einen falschen Default Virtual Host,
• Traffic aus einer bestimmten Region gelangt zu einer anderen Infrastruktur,
• der Origin hat ein anderes Zertifikat als das öffentliche Edge,
• ein Teil der Server sendet eine unvollständige Chain.

Aus Nutzersicht ist das weiterhin „dieselbe Domain“, aber aus Netzwerksicht nicht derselbe Endpoint.

Was weiß TLS nicht?

Korrektes TLS beweist nicht, dass:

• die Seite auf Anwendungsebene sicher ist,
• das JavaScript kein XSS enthält,
• der Nutzer die richtigen Berechtigungen hat,
• das Canonical korrekt ist,
• Google den Inhalt indexiert,
• die Open-Graph-Karte ein gutes Bild hat.

Das grüne Schloss steht für eine geschützte Verbindung mit einem vom Client akzeptierten Namen. Es ist kein Qualitätszertifikat für die gesamte Anwendung.

Wahrheit Nummer 3: Der Browser sieht das Ergebnis der gesamten Umgebung

Ein Browser leistet deutlich mehr Arbeit als das bloße Abrufen von HTML. Eine typische Navigation umfasst DNS, den Transportaufbau, TLS, die HTTP-Anfrage, das Parsen von HTML, das Laden von CSS und JavaScript, den Aufbau von DOM und CSSOM, das Layout sowie das Rendern der Pixel.

Was der Nutzer auf dem Bildschirm sieht, kann sich vom Quellcode der Antwort unterscheiden.

Source-HTML, DOM und Bildschirm sind drei verschiedene Dinge

HTML vom Server

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

DOM nach der Ausführung von JavaScript

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

Das Bild auf dem Bildschirm

Das endgültige Erscheinungsbild wird zusätzlich von CSS, Schriftarten, der Viewport-Größe, der Bildverfügbarkeit, Systemeinstellungen und Nutzerinteraktionen beeinflusst.

Was personalisiert die „Wahrheit des Browsers“?

• Cookies und Session,
• localStorage und sessionStorage,
• die Browsersprache,
• die Zeitzone,
• die Bildschirmbreite,
• prefers-color-scheme,
• prefers-reduced-motion,
• Berechtigungen,
• ein A/B-Experiment,
• API-Antworten,
• der Login-Status.

Der Browser hat außerdem einen privaten HTTP-Cache. Eine als frisch gespeicherte Antwort kann je nach Cache-Direktiven ohne erneuten Abruf verwendet werden.

Ein Service Worker kann Anfragen abfangen und Daten aus seinem eigenen Cache oder aus einer benutzerdefinierten Offline-Strategie zurückgeben. Das erklärt Situationen, in denen ein einfaches Neuladen weiterhin die alte Version zeigt, während der private Modus die neue anzeigt.

Warum ist „bei mir funktioniert es“ ein schwacher Test?

Der Eigentümer der Seite kann Folgendes haben:

• eine aktive Administrator-Session,
• Daten im Cache,
• einen alten Service Worker,
• Zugriff auf eine nicht öffentlich verfügbare API,
• eine andere Sprache und Region,
• Erweiterungen, die die Seite verändern,
• einen übersprungenen Banner oder Onboarding.

Ein Browsertest sollte ein sauberes Profil, den privaten Modus, ein mobiles Gerät, IPv4, IPv6 sowie einen nicht angemeldeten Nutzer umfassen.

Wahrheit Nummer 4: Googlebot sieht eine Seite, die zum Crawlen, Rendern und Indexieren bestimmt ist

Google beschreibt die Verarbeitung von JavaScript-Seiten als drei Hauptphasen:

1. Crawling,
2. Rendering,
3. Indexing.

Googlebot ruft die URL ab, analysiert die Antwort und kann die Seite an den Web Rendering Service weiterleiten. Google verwendet zum Rendern eine aktuelle Chrome-Version, aber das Ergebnis muss nicht zum selben Zeitpunkt wie der erste Abruf entstehen.

Googlebot ist kein gewöhnlicher Nutzer

Google hat Googlebot Smartphone und Desktop und indexiert für die meisten Seiten vor allem die mobile Version. Die meisten Anfragen stammen daher vom mobilen Crawler.

Googlebot:

• meldet sich nicht bei deinem Konto an,
• hat deine Cookies nicht,
• sieht keine privaten Daten,
• verhält sich nicht wie ein Nutzer, der alle Szenarien durchläuft,
• kann Ressourcen separat abrufen,
• unterliegt der robots.txt und den Indexierungssteuerungen.

Google weist ausdrücklich darauf hin, dass es Hauptinhalte, die eine Interaktion erfordern, wie einen Klick, eine Eingabe oder das Verschieben eines Elements, nicht lädt.

Robots.txt ist nicht dasselbe wie noindex

robots.txt steuert, welche URLs ein Crawler abrufen darf. Google betont, dass dies kein Mechanismus ist, der die Entfernung einer URL aus den Ergebnissen garantiert.

Damit noindex wirkt, muss der Crawler die Seite abrufen und das Tag oder den Header sehen können. Wenn die URL gleichzeitig in der robots.txt blockiert ist, sieht Google noindex möglicherweise nicht.

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

oder:

X-Robots-Tag: noindex

Canonical ist ein Hinweis, kein bedingungsloser Befehl

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

Google kann eine andere Canonical-Version als die vom Eigentümer angegebene wählen, da die Canonicalisierung viele Signale berücksichtigt. Google bezeichnet die Canonical-Angabe als Hinweis, nicht als Regel.

Was kann ein Nutzer sehen, Googlebot aber nicht?

• Inhalte erst nach einem Klick auf „Mehr anzeigen“,
• Daten, die nur nach dem Login verfügbar sind,
• ein Element, das von einer nicht verfügbaren API abhängt,
• Content, der über ein blockiertes Skript geladen wird,
• eine Desktop-Version, die umfangreicher ist als die mobile,
• eine Komponente, die nur mit im Browser gespeicherten Daten funktioniert.

Was kann Googlebot sehen, ein typischer Nutzer aber nicht?

Zum Beispiel kann der Server für seinen User-Agent eine andere Variante zurückgeben. Eine rein technische Anpassung ist nicht automatisch ein Verstoß, aber das gezielte Anzeigen von Inhalten für die Suchmaschine, die sich grundlegend von denen für Nutzer unterscheiden, kann als Cloaking gewertet werden.

Die sicherste Praxis besteht darin, denselben wesentlichen Inhalt in der ersten Antwort oder in einem Rendering bereitzustellen, das keine Nutzerinteraktion erfordert.

Wahrheit Nummer 5: Ein Social-Media-Crawler baut eine Karte, nicht das vollständige Erlebnis der Seite

Wenn eine URL in Facebook, LinkedIn, Slack oder eine andere Plattform eingefügt wird, kann das System die Seite abrufen und eine Vorschau erstellen. Man sollte nicht davon ausgehen, dass jede Plattform eine JavaScript-Anwendung genau so ausführt wie der vollständige Browser eines Nutzers.

Die portabelste Art, eine Seite zu beschreiben, sind Metadaten, die im <head> des ursprünglichen HTML platziert sind.

Grundlegende Open-Graph-Tags

Die Open-Graph-Spezifikation definiert vier erforderliche Eigenschaften:

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

In der Praxis lohnt es sich, hinzuzufügen:

<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 empfiehlt die Verwendung von Open-Graph-Tags, damit der Crawler Titel, Beschreibung und Vorschaubild abrufen kann. Die Dokumentation von Meta beschreibt außerdem das Abrufen und Cachen von Metadaten beim Teilen einer URL.

Das bedeutet, dass eine Bildänderung auf dem Server eine bestehende Karte nicht sofort ändern muss. Die Plattform kann weiterhin einen älteren Snapshot besitzen.

LinkedIn

LinkedIn gibt an, dass Vorschauen unter anderem Open Graph oder oEmbed nutzen. Ein altes Bild kann aus dem Cache stammen, und der Post Inspector erlaubt es, die Daten für neue Freigaben zu aktualisieren.

Bestehende Posts können die vorherige Vorschau selbst nach dem Aktualisieren der URL beibehalten.

Slack

Slack dokumentiert das klassische Unfurling als Prozess, bei dem das System nach dem Erkennen eines Links die Seite crawlt und eine Vorschau erstellt. Slack-Apps können außerdem eigene, programmierbare Unfurls bereitstellen.

Das ist eine wichtige Unterscheidung: Eine Karte in Slack kann das Standardergebnis des Crawlens oder ein benutzerdefiniertes, von einer Integration zurückgegebenes Objekt sein.

Warum zeigen Plattformen unterschiedliche Bilder?

• eine Plattform hat einen alten Cache,
• eine andere kann das Bild nicht abrufen,
• die Bild-URL leitet weiter,
• das Bild hat einen nicht verfügbaren MIME-Typ oder Statuscode,
• mehrere og:image haben eine andere Reihenfolge,
• die Seite hat separate Tags für verschiedene Sprachversionen,
• der Bot erhält über CDN oder Firewall eine andere Variante,
• die Metadaten werden erst durch JavaScript hinzugefügt.

Am sichersten ist es, die grundlegenden Social-Media-Tags direkt in das HTML vom Server einzubetten und absolute HTTPS-Adressen anzugeben.

Wahrheit Nummer 6: Ein Sicherheitsscanner sieht nur den Bereich, den er untersuchen kann

„Sicherheitsscanner“ kann sehr unterschiedliche Werkzeuge bezeichnen:

• einen Analysator für HTTP-Header,
• einen Scanner für die TLS-Konfiguration,
• ein DAST, das Anfragen und Schwachstellentests durchführt,
• einen Anwendungs-Crawler,
• ein SAST, das den Code analysiert,
• einen Abhängigkeits-Scanner,
• ein Werkzeug zum Testen der Infrastruktur.

In diesem Artikel sprechen wir hauptsächlich von einem externen Scanner, der eine öffentlich zugängliche Seite untersucht.

Was sieht ein Header-Scanner?

Das MDN HTTP Observatory bewertet vor allem HTTP-Header und ausgewählte Sicherheitskonfigurationen.

Es kann unter anderem prüfen:

• CSP,
• HSTS,
• Schutz vor Framing,
• X-Content-Type-Options,
• Cookies,
• die Weiterleitung zu HTTPS,
• ausgewählte Cross-Origin-Richtlinien.

Das bedeutet nicht, dass er den Backend-Code, die Nutzerrollen, die Datenbankkonfiguration oder alle API-Endpoints gelesen hat.

Eine Buchstabenbewertung ist kein Urteil über die gesamte Sicherheit

Die Observatory-Dokumentation weist darauf hin, dass das Scoring ungenutzte Sicherheitsmechanismen aufzeigen soll und der Bedarf an einem bestimmten Header von der Art der Website abhängen kann.

Eine Seite kann eine hohe Header-Bewertung erzielen und dennoch Folgendes aufweisen:

• IDOR,
• fehlerhafte Autorisierung,
• SQL Injection,
• ein angreifbares Administrationspanel,
• offengelegte Schlüssel,
• eine Geschäftslogik, die Missbrauch ermöglicht.

Auch der umgekehrte Fall ist möglich: Ein einfacher JSON-Endpoint erhält eine schlechtere Bewertung, weil ihm für ein HTML-Dokument typische Header fehlen, obwohl einige davon für ihn nicht dieselbe Bedeutung haben.

DAST hat einen anderen Umfang, aber ebenfalls Grenzen

OWASP beschreibt Web Application Vulnerability Scanner als Werkzeuge, die Anwendungen von außen auf Schwachstellen und Fehlkonfigurationen testen.

ZAP warnt, dass automatisches Scannen Grenzen hat. Ohne konfigurierte Authentifizierung entdeckt es keine Seiten hinter dem Login, und ein automatischer Spider führt nicht alle realistischen Nutzerprozesse aus.

Das Ergebnis hängt ab von:

• dem im Test verwendeten Konto und der Rolle,
• den verfügbaren URLs,
• den Formularen und Testdaten,
• dem Umfang der Domains,
• dem User-Agent,
• den WAF-Limits,
• der Scan-Dauer,
• davon, ob der Scanner JavaScript ausführt.

Der Scanner sagt: „In diesem Umfang habe ich bestimmte Signale gefunden oder nicht gefunden.“ Er sagt nicht: „Ich habe das Fehlen aller Schwachstellen bewiesen.“

Eine URL, sechs korrekte Berichte

Das folgende Beispiel ist hypothetisch, aber technisch realistisch.

Die untersuchte Adresse:

https://example.com/raport

DNS

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

Fazit: Die Domain hat zwei mögliche Endpoints.

TLS über IPv4

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

TLS über IPv6

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

Fazit: Ein Teil der Clients kann die Seite nicht öffnen.

Der Browser des Eigentümers

• nutzt IPv4,
• hat eine aktive Session,
• der Service Worker gibt die Version aus dem Cache zurück,
• zeigt den aktuellen Bericht an.

Fazit des Nutzers: „Alles funktioniert.“

Googlebot Smartphone

• gelangt über IPv6 dorthin,
• kann TLS nicht durchführen,
• ruft die Seite nicht ab.

Fazit SEO: Der neue Inhalt wird nicht gecrawlt.

LinkedIn

• hat eine Vorschau, die eine Woche zuvor gespeichert wurde,
• zeigt das vorherige og:image an.

Fazit Marketing: Die Karte ist veraltet.

Header-Scanner

• testet IPv4,
• ruft das Dokument ohne Login ab,
• erkennt das Fehlen von CSP und HSTS.

Fazit Sicherheit: Der Transport funktioniert, aber das Hardening der Antwort ist unvollständig.

Alle Berichte beschreiben einen anderen Ausschnitt des Systems.

Symptommatrix

Symptom	Wahrscheinlichste Perspektive	Erster Test
Die Seite funktioniert nur für einen Teil der Nutzer	DNS, IPv6 oder TLS	dig A/AAAA, Test beider Adressen
Zertifikat einer anderen Domain	TLS/SNI	openssl s_client -servername
Nach dem Deployment ist weiterhin die alte Seite sichtbar	Browser-Cache oder Service Worker	sauberes Profil, DevTools Application
Google zeigt einen alten Titel	Crawl-/Index-Cache oder anderes Canonical	URL Inspection, Prüfung des gerenderten HTML
Die Seite ist nicht im Index	robots, noindex, Crawling-Fehler	robots.txt, Search Console
Facebook oder LinkedIn zeigt ein altes Bild	Cache des Social-Media-Crawlers	Debugger oder Post Inspector
Der Scanner meldet fehlendes HSTS, während der Browser HTTPS verwendet	Antwort-Header	curl -I für die finale URL
Das Scanner-Ergebnis ist gut, aber eine Funktion hat einen Zugriffsfehler	Anwendungslogik außerhalb des Scanner-Umfangs	Test von Autorisierung und Rollen
Der mobile Inhalt ist bei Google spärlicher	Mobile-First und abweichender Content	Vergleich des mobilen Renderings
noindex funktioniert nicht	URL in robots.txt blockiert	Crawling ermöglichen und erneut testen

Methodik eines vollständigen Audits

1. Erfasse die vollständige URL-Kette

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

Achte auf:

• die Statuscodes,
• den Wechsel des Hosts,
• den Übergang HTTP→HTTPS,
• die finale URL,
• die Anzahl der Weiterleitungen.

2. Prüfe DNS mit mehreren Resolvern

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

Vergleiche die Antworten des Anbieter-Resolvers, eines öffentlichen Resolvers und eines autoritativen Servers.

3. Prüfe jeden TLS-Endpoint

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

Wiederhole dies für IPv6 und andere von DNS zurückgegebene Adressen.

4. Prüfe die HTTP-Antwort ohne Nutzerzustand

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

Überprüfe:

• den Statuscode,
• Content-Type,
• den Cache,
• CSP,
• HSTS,
• X-Robots-Tag,
• den Inhalt von <head>.

5. Vergleiche Source-HTML und DOM

Prüfe im Browser:

• View Source,
• das Elements-Panel,
• Network,
• Application,
• den aktiven Service Worker,
• den Cache-Storage,
• die Cookies.

6. Prüfe Googlebot

Verwende das URL-Inspection-Tool in der Google Search Console und vergleiche:

• das abgerufene HTML,
• das gerenderte HTML,
• den Screenshot,
• die Ressourcen, die nicht geladen werden konnten,
• das angegebene und das von Google gewählte Canonical,
• die Indexierbarkeit.

Identifiziere Googlebot nicht ausschließlich anhand des User-Agent. Google empfiehlt die Verifizierung über Reverse-DNS oder offizielle IP-Bereiche.

7. Prüfe die Social-Media-Karte

Analysiere:

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

Verwende anschließend die Aktualisierungswerkzeuge der jeweiligen Plattform.

8. Führe mehrere Klassen von Sicherheitstests durch

• eine Header-Analyse,
• einen TLS-Test,
• ein DAST in einer dafür vorgesehenen Umgebung,
• Tests von Authentifizierung und Autorisierung,
• eine Abhängigkeitsanalyse,
• eine Überprüfung von Code und Konfiguration.

Eine einzelne Bewertung ersetzt nicht die anderen.

Ein vorbildlicher <head>, der für verschiedene Clients zugänglich ist

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

Die wichtigsten Metadaten befinden sich in der HTML-Antwort und nicht erst nach dem Start der Anwendung.

Praktische Checkliste der „sechs Wahrheiten“

DNS

• A und AAAA verweisen auf aktive Endpoints.
• Alle autoritativen Server geben konsistente Daten zurück.
• Die TTL ist nachvollziehbar und wird überwacht.
• DNSSEC besteht die Validierung.
• www und Apex verhalten sich wie beabsichtigt.
• Der Test wurde mit mehreren Resolvern und Standorten durchgeführt.

TLS

• Jede IP-Adresse gibt das richtige Zertifikat zurück.
• SAN umfasst jeden verwendeten Hostnamen.
• Die Chain ist vollständig.
• IPv4 und IPv6 haben dieselbe Konfigurationsqualität.
• SNI wählt den richtigen Virtual Host.
• CDN und Origin haben korrektes TLS.

Browser

• Die Seite funktioniert in einem sauberen Profil.
• Die nicht angemeldete Version wurde geprüft.
• Das Source-HTML enthält die wesentlichen Inhalte und Metadaten.
• Das DOM nach dem Rendering entspricht der Erwartung.
• Service Worker und Cache verdecken das Deployment nicht.
• Die mobile Version enthält den vollständigen Inhalt.
• API-Fehler werden behandelt.

Googlebot

• robots.txt erlaubt das Abrufen der Seite und der Ressourcen.
• noindex entspricht der Absicht.
• Das Canonical ist mit Weiterleitungen und Sitemap konsistent.
• Der Hauptinhalt erfordert keinen Klick.
• Das mobile Rendering enthält denselben wesentlichen Inhalt.
• URL Inspection zeigt korrektes HTML und einen Screenshot.
• Die CSS- und JS-Ressourcen sind verfügbar.

Social-Media-Crawler

• Die grundlegenden Open-Graph-Tags befinden sich im ursprünglichen HTML.
• og:url verweist auf die richtige, dauerhafte URL.
• og:image ist eine absolute HTTPS-Adresse.
• Das Bild gibt 200 und einen korrekten MIME-Typ zurück.
• Die Bildabmessungen sind deklariert.
• Jede Sprachversion hat die passenden Metadaten.
• Der Plattform-Cache wurde nach der Änderung aktualisiert.

Sicherheit

• Die Header der finalen Antwort wurden getestet.
• Der Test umfasst mehr als die Homepage.
• Die Endpoints nach dem Login wurden geprüft.
• Die Nutzerrollen wurden separat getestet.
• Die automatischen Ergebnisse wurden von einem Menschen verifiziert.
• DAST wurde durch SAST und eine Abhängigkeitsanalyse ergänzt.
• Eine schlechte oder hohe Bewertung wurde im Kontext interpretiert.

POLPROG-Werkzeuge, die bei einem solchen Audit nützlich sind

• DNS- und SSL-Inspektor zeigt die Domain-Records und die Zertifikatsdaten.
• Open Graph Preview prüft die Metadaten und die Sharing-Karte.
• Inspektor für Sicherheits-Header analysiert das Hardening der HTTP-Antwort.
• Website-Zustandsprüfung vereint Signale aus SEO, Performance, Barrierefreiheit und Sicherheit.
• FlowTrace visualisiert den Weg von einem Ereignis im Browser über DNS, TLS, CDN, Backend bis zum Rendering.

Die häufigsten Mythen

„Wenn die Seite bei mir funktioniert, funktioniert sie überall“

Nein. Dein Resolver, dein IP-Protokoll, dein Cache, deine Cookies und dein CDN-Knoten können unterschiedlich sein.

„Google sieht genau dasselbe wie Chrome“

Google rendert Seiten mit Chrome, aber Googlebot hat einen anderen Zustand, einen Mobile-First-User-Agent, separate Phasen für Crawling und Rendering und führt keine Inhalte aus, die eine Interaktion erfordern.

„Robots.txt entfernt die Seite aus Google“

Nein. Robots.txt beschränkt das Crawling. Zur Steuerung der Indexierung dient noindex, das für den Crawler sichtbar sein muss.

„Canonical zwingt Google zur Verwendung der gewählten URL“

Nein. Es ist ein wichtiges Signal, aber Google kann ein anderes Canonical wählen.

„Ich habe og:image geändert, also ist die Karte jetzt neu“

Nicht immer. Die Plattform kann eine gespeicherte Version verwenden und einen erneuten Abruf der URL erfordern.

„A+ im Scanner bedeutet, dass die Anwendung sicher ist“

Nein. Es bedeutet eine hohe Bewertung in einem konkreten Testsatz. Es beweist weder korrekte Autorisierung noch Geschäftslogik oder die Sicherheit des Codes.

Fazit

Eine Domain hat kein einziges technisches „Gesicht“.

• DNS sieht den Namen und die Records.
• TLS sieht den Endpoint und die Identität des Zertifikats.
• Der Browser sieht das gerenderte Erlebnis eines konkreten Nutzers.
• Googlebot sieht eine Ressource, die zum Crawlen, Rendern und Indexieren verfügbar ist.
• Der Social-Media-Crawler sieht die Metadaten, die zum Erstellen der Karte nötig sind.
• Der Sicherheitsscanner sieht ausschließlich die von seinen Tests erfasste Angriffsfläche.

Ein reifes Audit fragt also nicht nur: „Funktioniert die Seite?“

Es fragt:

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?

Erst die Antworten auf diese Fragen ergeben ein stimmiges Bild des Systems.