https://example.com/artykul
en je krijgt zes verschillende antwoorden:
- DNS beweert dat het domein naar twee IP-adressen leidt,
- de TLS-laag ziet een certificaat dat
wwwniet dekt, - je browser toont de juiste, gepersonaliseerde pagina,
- Googlebot indexeert een oudere titel,
- LinkedIn toont nog steeds de vorige afbeelding,
- een beveiligingsscanner geeft een lage score vanwege ontbrekende headers.
Geen van deze waarnemingen hoeft onjuist te zijn.
Elk systeem kijkt naar een ander deel van de stack, gebruikt een andere cache, verstuurt een andere set headers, kan vanaf een andere locatie verbinding maken en voert JavaScript niet altijd op dezelfde manier uit. “De waarheid van een website” is niet één document. Het is een verzameling toestanden die zichtbaar zijn voor verschillende clients.
Belangrijkste conclusie: een domein kan correct werken in de browser van de eigenaar en tegelijkertijd verkeerde DNS hebben voor een deel van de resolvers, een ongeldig certificaat op één CDN-node, niet-indexeerbare content voor Googlebot, een oude sociale preview en zwakke beveiliging van de HTTP-respons.
Dit artikel gaat er niet van uit dat elk verschil een fout is. Personalisatie, taalvarianten, cache en gedistribueerde infrastructuur zijn normaal. Het probleem begint wanneer een verschil onbedoeld is, onzichtbaar in de monitoring, of een bepaalde client belet de juiste versie te bereiken.
De documentatie en het gedrag van de beschreven systemen zijn geverifieerd op 23 juli 2026.
Zes perspectieven in één tabel
| Waarnemer | Wat het werkelijk controleert | Wat het meestal niet kent | Wat het resultaat kan veranderen |
|---|---|---|---|
| DNS | de hostnaam, records, delegatie, cache, DNSSEC | HTML-content, het URL-pad, de paginatitel | resolver, TTL, regio, IPv4/IPv6 |
| TLS | endpoint, SNI, certificaat, SAN, chain, protocol | de content van de pagina en de SEO ervan | IP-adres, CDN-node, virtualhostconfiguratie |
| Browser | DNS, TLS, HTTP, HTML, CSS, JavaScript, cookies, cache, DOM | de intentie van de auteur en de toestand van andere clients | gebruiker, viewport, locale, storage, service worker |
| Googlebot | beschikbaarheid, robots, HTTP, HTML, resources, rendering, canonical, noindex | content die login of interactie vereist | mobile-first, crawl cache, render queue, resourceblokkeringen |
| Sociale crawler | URL, redirect, metadata, preview-afbeelding, platformcache | de volledige app-ervaring | platform, cache, Open Graph, beschikbaarheid van de afbeelding |
| Beveiligingsscanner | het publieke oppervlak en de tests binnen zijn bereik | de volledige bedrijfslogica, de code en de gebruikersrollen | type scanner, autorisatie, pad, testconfiguratie |
“Hetzelfde domein” betekent niet altijd dezelfde test
Voordat je resultaten vergelijkt, bepaal precies welke resource je onderzoekt:
http://example.com
https://example.com
https://www.example.com
https://example.com/
https://example.com/artykul
https://example.com/artykul?utm_source=test
Dit zijn technisch gezien geen identieke verzoeken. Ze kunnen:
- via andere redirects verlopen,
- andere hosts gebruiken,
- op een andere virtual host terechtkomen,
- andere cacheregels hebben,
- naar verschillende canonicals verwijzen,
- andere headers retourneren,
- aparte sociale kaarten oproepen.
Een audit moet altijd de volledige URL, het tijdstip, de testlocatie, de user-agent, de eindstatus en de redirectketen vastleggen.
Waarheid nummer 1: DNS ziet de naam, niet de pagina
DNS vertaalt de hostnaam naar de gegevens die nodig zijn om de service te vinden. Bij een typische query voor:
https://example.com/artykul?id=42
is DNS geïnteresseerd in de naam:
example.com
Het analyseert niet het pad /artykul, de parameters ?id=42, de HTML-titel of de canonical-tag. DNS is een hiërarchisch systeem van namen en resource-records.
Wat kan DNS-diagnostiek zien?
Onder andere:
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"
Het kan ook controleren:
- de
NS-servers, - het
SOA-record, - de
MX-mail, - de
TXT-gegevens, - de
HTTPS- enSVCB-records, - de DNSSEC-handtekeningen.
Waarom kunnen twee personen verschillende antwoorden krijgen?
De eenvoudigste oorzaak is cache. Een resolver kan een antwoord bewaren totdat de TTL verloopt. Negatieve antwoorden, zoals NXDOMAIN, kunnen ook worden gecachet.
Verschillen kunnen ook voortkomen uit:
- verschillende resolvers,
- afwijkende cacheversies,
- geografische infrastructuur of DNS-loadbalancing,
- aparte antwoorden voor IPv4 en IPv6,
- migratie tussen providers,
- inconsistente autoritatieve servers,
- een beschadigde DNSSEC-keten.
DNSSEC authenticeert de herkomst en integriteit van DNS-gegevens, maar versleutelt de query zelf niet. Een onjuist DS-record kan ervoor zorgen dat een valideerende resolver SERVFAIL retourneert, terwijl een resolver zonder validatie het adres nog steeds toont.
Wat bevestigt DNS niet?
Een correct DNS-antwoord bewijst niet dat:
- de server werkt,
- poort 443 open is,
- het certificaat geldig is,
- de applicatie code
200retourneert, - de pagina indexeerbaar is,
- de beveiligingsheaders geïmplementeerd zijn.
DNS zegt waar de client verbinding moet proberen te maken. Het zegt niet wat de client na de verbinding aantreft.
Waarheid nummer 2: TLS ziet de identiteit van het endpoint, niet de content van het artikel
Na het vinden van het adres maakt de client verbinding met de server en onderhandelt TLS. In een omgeving die meerdere domeinen op één adres bedient, stelt de SNI-extensie de client in staat de servernaam op te geven waarvoor hij een verbinding wil opzetten.
De TLS-laag kan onder andere onthullen:
- de ondersteunde protocolversies,
- het onderhandelde algoritme,
- het servercertificaat,
- de SAN-namen,
- de certificeringsautoriteit,
- de vervaldatum,
- de tussenliggende certificaten,
- het resultaat van de ALPN-onderhandeling, bijvoorbeeld HTTP/2.
TLS 1.3 is gedefinieerd in RFC 8446 en beschermt het datatransport tussen client en server.
Het certificaat correspondeert met de naam, niet met de inhoud
De client controleert of de hostnaam overeenkomt met de identiteit die in het certificaat is vastgelegd, vooral in subjectAltName.
Een certificaat voor:
example.com
hoeft niet te dekken:
www.example.com
api.example.com
Een wildcard:
*.example.com
dekt niet automatisch het hoofddomein example.com of het meerlaagse www.eu.example.com.
Waarom ziet de ene gebruiker een geldig certificaat en de andere niet?
Mogelijke scenario's:
AenAAAAleiden naar verschillende servers,- één CDN-node heeft het nieuwe certificaat niet ontvangen,
- de SNI-configuratie heeft een verkeerde default virtual host,
- verkeer uit een bepaalde regio komt op een andere infrastructuur terecht,
- de origin heeft een ander certificaat dan de publieke edge,
- een deel van de servers verstuurt een onvolledige chain.
Vanuit het perspectief van de gebruiker is dit nog steeds “hetzelfde domein”, maar vanuit het perspectief van het netwerk niet hetzelfde endpoint.
Wat weet TLS niet?
Correcte TLS bewijst niet dat:
- de pagina op applicatieniveau veilig is,
- de JavaScript geen XSS bevat,
- de gebruiker de juiste rechten heeft,
- de canonical correct is,
- Google de content zal indexeren,
- de Open Graph-kaart een goede afbeelding heeft.
Een groen hangslot betekent een beveiligde verbinding met een naam die door de client is geaccepteerd. Het is geen kwaliteitskeurmerk voor de hele applicatie.
Waarheid nummer 3: de browser ziet het resultaat van de werking van de hele omgeving
De browser verricht veel meer werk dan alleen het ophalen van HTML. Een typische navigatie omvat DNS, de transportverbinding, TLS, het HTTP-verzoek, het parsen van HTML, het ophalen van CSS en JavaScript, het opbouwen van DOM en CSSOM, layout en het renderen van pixels.
Wat de gebruiker op het scherm ziet, kan afwijken van de broncode van de respons.
Source-HTML, DOM en het scherm zijn drie verschillende dingen
HTML van de server
<div id="app"></div>
<script src="/app.js"></script>
DOM na uitvoering van JavaScript
<div id="app">
<h1>Raport dla zalogowanego użytkownika</h1>
</div>
Het beeld op het scherm
De uiteindelijke weergave wordt verder beïnvloed door CSS, fonts, de grootte van de viewport, de beschikbaarheid van afbeeldingen, systeeminstellingen en interacties van de gebruiker.
Wat personaliseert de “browserwaarheid”?
- cookies en sessie,
localStorageensessionStorage,- de browsertaal,
- de tijdzone,
- de schermbreedte,
prefers-color-scheme,prefers-reduced-motion,- rechten,
- A/B-experiment,
- API-antwoorden,
- de inlogstatus.
De browser heeft ook een private HTTP-cache. Een respons die als vers is opgeslagen, kan zonder opnieuw op te halen worden gebruikt, afhankelijk van de cachedirectieven.
Een service worker kan verzoeken onderscheppen en gegevens retourneren uit zijn eigen cache of via een aangepaste offlinestrategie. Dat verklaart situaties waarin een gewone vernieuwing nog steeds de oude versie toont, terwijl de privémodus de nieuwe laat zien.
Waarom is “bij mij werkt het” een zwakke test?
De eigenaar van de pagina kan het volgende hebben:
- een actieve beheerderssessie,
- gegevens in de cache,
- een oude service worker,
- toegang tot een API die niet publiek beschikbaar is,
- een andere taal en regio,
- extensies die de pagina wijzigen,
- een overgeslagen banner of onboarding.
Een browsertest moet een schoon profiel, de privémodus, een mobiel apparaat, IPv4, IPv6 en een niet-ingelogde gebruiker omvatten.
Waarheid nummer 4: Googlebot ziet een pagina bedoeld om te crawlen, te renderen en te indexeren
Google beschrijft de verwerking van JavaScript-pagina's als drie hoofdfasen:
- crawling,
- rendering,
- indexing.
Googlebot haalt de URL op, analyseert de respons en kan de pagina doorgeven aan de Web Rendering Service. Google gebruikt voor het renderen een actuele versie van Chrome, maar het resultaat hoeft niet op hetzelfde moment te ontstaan als het eerste ophalen.
Googlebot is geen gewone gebruiker
Google heeft Googlebot Smartphone en Desktop, en voor de meeste sites indexeert het vooral de mobiele versie. De meeste verzoeken komen dus van de mobiele crawler.
Googlebot:
- logt niet in op je account,
- heeft je cookies niet,
- ziet geen privégegevens,
- gedraagt zich niet als een gebruiker die alle scenario's doorloopt,
- kan resources afzonderlijk ophalen,
- valt onder robots.txt en indexeringscontroles.
Google geeft uitdrukkelijk aan dat het geen hoofdcontent laadt die interactie vereist, zoals klikken, gegevens invoeren of een element verslepen.
Robots.txt is niet hetzelfde als noindex
robots.txt bepaalt welke URL's een crawler mag ophalen. Google benadrukt dat dit geen mechanisme is dat verwijdering van een URL uit de resultaten garandeert.
Om noindex te laten werken, moet de crawler de pagina kunnen ophalen en de tag of header kunnen zien. Als de URL tegelijkertijd in robots.txt geblokkeerd is, ziet Google noindex mogelijk niet.
<meta name="robots" content="noindex">
of:
X-Robots-Tag: noindex
Canonical is een aanwijzing, geen onvoorwaardelijk commando
<link rel="canonical" href="https://example.com/artykul">
Google kan een andere canonical-versie kiezen dan de eigenaar heeft aangegeven, omdat canonicalisatie veel signalen meeweegt. Google omschrijft de canonical-aanwijzing als een hint, niet als een regel.
Wat kan een gebruiker zien, maar Googlebot niet?
- content pas na het klikken op “Meer weergeven”,
- gegevens die alleen na inloggen beschikbaar zijn,
- een element dat afhankelijk is van een niet-beschikbare API,
- content die door een geblokkeerd script wordt geladen,
- een desktopversie die rijker is dan de mobiele,
- een component dat alleen werkt met gegevens die in de browser zijn opgeslagen.
Wat kan Googlebot zien, maar een typische gebruiker niet?
De server kan bijvoorbeeld een andere variant retourneren voor zijn user-agent. Een technische aanpassing op zichzelf is niet automatisch een overtreding, maar het opzettelijk aan de zoekmachine tonen van content die wezenlijk anders is dan aan gebruikers, kan als cloaking worden aangemerkt.
De veiligste praktijk is dezelfde belangrijke content beschikbaar te stellen in de eerste respons of in een rendering die geen interactie van de gebruiker vereist.
Waarheid nummer 5: de sociale crawler bouwt een kaart, niet de volledige pagina-ervaring
Wanneer een URL in Facebook, LinkedIn, Slack of een ander platform wordt geplakt, kan het systeem de pagina ophalen en een preview opbouwen. Ga er niet van uit dat elk platform de JavaScript-applicatie precies zo uitvoert als de volledige browser van de gebruiker.
De meest overdraagbare manier om een pagina te beschrijven is metadata die in de <head> van de initiële HTML is geplaatst.
Basis-Open Graph
De Open Graph-specificatie definieert vier vereiste eigenschappen:
<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 de praktijk is het nuttig om toe te voegen:
<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 raadt aan Open Graph-tags te gebruiken, zodat de crawler de titel, beschrijving en preview-afbeelding kan ophalen. De documentatie van Meta beschrijft ook het ophalen en cachen van metadata bij het delen van een URL.
Dit betekent dat het wijzigen van de afbeelding op de server niet direct de bestaande kaart hoeft te veranderen. Het platform kan nog steeds een oudere snapshot hebben.
LinkedIn geeft aan dat previews onder andere Open Graph of oEmbed gebruiken. Een oude afbeelding kan uit de cache komen, en met Post Inspector kun je de gegevens voor nieuwe deelacties vernieuwen.
Bestaande posts kunnen de vorige preview behouden, zelfs na het vernieuwen van de URL.
Slack
Slack documenteert klassieke unfurling als een proces waarbij het systeem na het detecteren van een link de pagina crawlt en een preview maakt. Slack-apps kunnen ook hun eigen programmeerbare unfurls leveren.
Dat is een belangrijk onderscheid: een kaart in Slack kan een standaardresultaat van het crawlen zijn of een aangepast object dat door een integratie wordt geretourneerd.
Waarom tonen platforms verschillende afbeeldingen?
- het ene platform heeft een oude cache,
- een ander kan de afbeelding niet ophalen,
- de URL van de afbeelding verwijst door,
- de afbeelding heeft een niet-beschikbaar MIME-type of statuscode,
- meerdere
og:imagehebben een andere volgorde, - de pagina heeft aparte tags voor verschillende taalversies,
- de bot krijgt een andere variant via de CDN of firewall,
- de metadata wordt pas door JavaScript toegevoegd.
Het veiligst is de basis sociale tags rechtstreeks in de HTML van de server te plaatsen en absolute HTTPS-adressen op te geven.
Waarheid nummer 6: de beveiligingsscanner ziet alleen het bereik dat hij kan onderzoeken
“Beveiligingsscanner” kan zeer uiteenlopende tools betekenen:
- een analyzer van HTTP-headers,
- een scanner van de TLS-configuratie,
- een DAST die verzoeken en kwetsbaarheidstests uitvoert,
- een applicatiecrawler,
- een SAST die code analyseert,
- een dependency-scanner,
- een tool voor het testen van infrastructuur.
In dit artikel hebben we het vooral over een externe scanner die een publiek toegankelijke pagina onderzoekt.
Wat ziet een header-scanner?
MDN HTTP Observatory beoordeelt vooral HTTP-headers en geselecteerde beveiligingsconfiguraties.
Het kan onder andere controleren:
- CSP,
- HSTS,
- bescherming tegen framing,
X-Content-Type-Options,- cookies,
- de redirect naar HTTPS,
- geselecteerde cross-origin-beleidsregels.
Dat betekent niet dat het de backendcode, de gebruikersrollen, de databaseconfiguratie of alle API-endpoints heeft gelezen.
Een lettercijfer is geen oordeel over de volledige beveiliging
De documentatie van Observatory geeft aan dat de scoring bedoeld is om onbenutte beveiligingsmechanismen aan te wijzen, en dat de noodzaak van een specifieke header kan afhangen van het type site.
Een pagina kan een hoge headerscore behalen en toch het volgende bevatten:
- IDOR,
- verkeerde autorisatie,
- SQL Injection,
- een kwetsbaar beheerderspaneel,
- blootgestelde sleutels,
- bedrijfslogica die misbruik mogelijk maakt.
De omgekeerde situatie is ook mogelijk: een eenvoudig JSON-endpoint krijgt een lagere score vanwege het ontbreken van headers die typisch zijn voor een HTML-document, ook al hebben sommige daarvan voor dat endpoint niet dezelfde betekenis.
DAST heeft een ander bereik, maar ook beperkingen
OWASP beschrijft web application vulnerability scanners als tools die applicaties extern testen op kwetsbaarheden en verkeerde configuratie.
ZAP waarschuwt dat automatisch scannen beperkingen heeft. Zonder geconfigureerde authenticatie ontdekt het geen pagina's achter een login, en een automatische spider doorloopt niet alle realistische gebruikersprocessen.
Het resultaat hangt af van:
- het account en de rol die in de test worden gebruikt,
- de beschikbare URL's,
- de formulieren en testgegevens,
- het domeinbereik,
- de user-agent,
- de limieten van de WAF,
- de scantijd,
- of de scanner JavaScript uitvoert.
De scanner zegt: “binnen dit bereik heb ik bepaalde signalen wel of niet gevonden”. Hij zegt niet: “ik heb bewezen dat er geen enkele kwetsbaarheid is”.
Eén URL, zes correcte rapporten
Het onderstaande voorbeeld is hypothetisch, maar technisch realistisch.
Het onderzochte adres:
https://example.com/raport
DNS
A: 192.0.2.10
AAAA: 2001:db8::20
TTL: 300
Conclusie: het domein heeft twee mogelijke endpoints.
TLS via IPv4
SAN: example.com, www.example.com
TLS: 1.3
Chain: poprawny
TLS via IPv6
SAN: old.example.net
TLS: 1.2
Chain: poprawny, ale zła nazwa
Conclusie: een deel van de clients opent de pagina niet.
De browser van de eigenaar
- gebruikt IPv4,
- heeft een actieve sessie,
- de service worker retourneert een versie uit de cache,
- toont het actuele rapport.
Conclusie van de gebruiker: “alles werkt”.
Googlebot Smartphone
- komt binnen via IPv6,
- kan TLS niet doorlopen,
- haalt de pagina niet op.
SEO-conclusie: de nieuwe content wordt niet gecrawld.
- heeft een preview die een week eerder is opgeslagen,
- toont de vorige
og:image.
Marketingconclusie: de kaart is verouderd.
Header-scanner
- test IPv4,
- haalt het document op zonder in te loggen,
- detecteert het ontbreken van CSP en HSTS.
Beveiligingsconclusie: het transport werkt, maar de hardening van de respons is onvolledig.
Alle rapporten beschrijven een ander deel van het systeem.
Symptomenmatrix
| Symptoom | Meest waarschijnlijke perspectief | Eerste test |
|---|---|---|
| De pagina werkt maar voor een deel van de gebruikers | DNS, IPv6 of TLS | dig A/AAAA, test van beide adressen |
| Certificaat van een ander domein | TLS/SNI | openssl s_client -servername |
| Na deployment is nog steeds de oude pagina te zien | browsercache of service worker | schoon profiel, DevTools Application |
| Google toont een oude titel | crawl-/index-cache of een andere canonical | URL Inspection, controle van de gerenderde HTML |
| De pagina staat niet in de index | robots, noindex, crawlfouten | robots.txt, Search Console |
| Facebook of LinkedIn toont een oude afbeelding | cache van de sociale crawler | debugger of Post Inspector |
| De scanner toont het ontbreken van HSTS, terwijl de browser HTTPS gebruikt | responsheaders | curl -I voor de uiteindelijke URL |
| Het scannerresultaat is goed, maar een functie heeft een toegangsfout | applicatielogica buiten het bereik van de scanner | test van autorisatie en rollen |
| De mobiele content is armer in Google | mobile-first en afwijkende content | vergelijking van de mobiele rendering |
noindex werkt niet |
URL geblokkeerd in robots.txt | crawlen toestaan en opnieuw testen |
Methodiek van een volledige audit
1. Leg de volledige URL-keten vast
curl -IL https://example.com/artykul
Let op:
- de statussen,
- de hostwijziging,
- de overgang HTTP→HTTPS,
- de uiteindelijke URL,
- het aantal redirects.
2. Controleer DNS via meerdere resolvers
dig example.com A
dig example.com AAAA
dig example.com NS
dig example.com CAA
dig example.com A +dnssec
Vergelijk de antwoorden van de resolver van de provider, een publieke resolver en de autoritatieve server.
3. Controleer elk TLS-endpoint
openssl s_client \
-connect 192.0.2.10:443 \
-servername example.com \
-showcerts
Herhaal dit voor IPv6 en andere adressen die door DNS worden geretourneerd.
4. Controleer de HTTP-respons zonder gebruikersstatus
curl -sS -D headers.txt https://example.com/artykul -o page.html
Verifieer:
- de statuscode,
Content-Type,- cache,
- CSP,
- HSTS,
X-Robots-Tag,- de inhoud van
<head>.
5. Vergelijk source-HTML en DOM
Controleer in de browser:
- View Source,
- het paneel Elements,
- Network,
- Application,
- de actieve service worker,
- cache storage,
- cookies.
6. Controleer Googlebot
Gebruik de tool URL Inspection in Google Search Console en vergelijk:
- de opgehaalde HTML,
- de gerenderde HTML,
- de screenshot,
- de resources die niet konden worden geladen,
- de canonical die is aangegeven en die door Google is gekozen,
- de indexeerbaarheid.
Identificeer Googlebot niet uitsluitend op basis van de user-agent. Google raadt verificatie aan via reverse DNS of de officiële IP-reeksen.
7. Controleer de sociale kaart
Analyseer:
<title>
<meta name="description">
<meta property="og:title">
<meta property="og:description">
<meta property="og:image">
<meta property="og:url">
Gebruik vervolgens de vernieuwingstools van het specifieke platform.
8. Voer meerdere klassen beveiligingstests uit
- analyse van de headers,
- TLS-test,
- DAST in een daarvoor bestemde omgeving,
- tests van authenticatie en autorisatie,
- dependency-analyse,
- review van code en configuratie.
Eén beoordeling vervangt de andere niet.
Een voorbeeld-<head> beschikbaar voor verschillende clients
<!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>
De belangrijkste metadata staat in de HTML-respons en niet pas na het starten van de applicatie.
Praktische checklist van de “zes waarheden”
DNS
-
AenAAAAleiden naar actieve endpoints. - Alle autoritatieve servers retourneren consistente gegevens.
- De TTL is begrijpelijk en wordt gemonitord.
- DNSSEC doorstaat de validatie.
-
wwwen de apex hebben het beoogde gedrag. - De test is uitgevoerd vanaf meerdere resolvers en locaties.
TLS
- Elk IP-adres retourneert het juiste certificaat.
- De SAN dekt elke gebruikte hostname.
- De chain is compleet.
- IPv4 en IPv6 hebben dezelfde configuratiekwaliteit.
- SNI kiest de juiste virtual host.
- CDN en origin hebben correcte TLS.
Browser
- De pagina werkt in een schoon profiel.
- De niet-ingelogde versie is gecontroleerd.
- De source-HTML bevat de belangrijkste content en metadata.
- De DOM na rendering komt overeen met de verwachting.
- De service worker en cache maskeren de deployment niet.
- De mobiele versie bevat de volledige content.
- API-fouten worden afgehandeld.
Googlebot
- robots.txt staat toe de pagina en resources op te halen.
-
noindexis in overeenstemming met de bedoeling. - De canonical is consistent met de redirects en de sitemap.
- De hoofdcontent vereist geen klik.
- De mobiele rendering bevat dezelfde belangrijke content.
- URL Inspection toont correcte HTML en screenshot.
- De CSS- en JS-resources zijn beschikbaar.
Sociale crawler
- De basis-Open Graph bevindt zich in de initiële HTML.
-
og:urlverwijst naar de juiste vaste URL. -
og:imageis een absoluut HTTPS-adres. - De afbeelding retourneert
200en een correct MIME-type. - De afmetingen van de afbeelding zijn gedeclareerd.
- Elke taalversie heeft de juiste metadata.
- De cache van het platform is na de wijziging vernieuwd.
Beveiliging
- De headers van de uiteindelijke respons zijn getest.
- De test omvat meer dan de homepage.
- De endpoints na inloggen zijn gecontroleerd.
- De gebruikersrollen zijn afzonderlijk getest.
- De automatische resultaten zijn door een mens geverifieerd.
- DAST is aangevuld met SAST en dependency-analyse.
- Een lage of hoge score is in context geïnterpreteerd.
POLPROG-tools die nuttig zijn bij zo'n audit
- DNS- en SSL-inspecteur toont de domeinrecords en certificaatgegevens.
- Open Graph Preview controleert de metadata en de deelkaart.
- Inspecteur voor beveiligingsheaders analyseert de hardening van de HTTP-respons.
- Websitegezondheid combineert signalen van SEO, prestaties, toegankelijkheid en beveiliging.
- FlowTrace visualiseert de route van een gebeurtenis in de browser via DNS, TLS, CDN, backend en rendering.
De meest voorkomende mythes
“Als de pagina bij mij werkt, werkt hij overal”
Nee. Je resolver, IP-protocol, cache, cookies en CDN-node kunnen anders zijn.
“Google ziet precies hetzelfde als Chrome”
Google rendert pagina's met Chrome, maar Googlebot heeft een andere toestand, een mobile-first user-agent, aparte fasen voor crawlen en renderen, en voert geen content uit die interactie vereist.
“Robots.txt verwijdert een pagina uit Google”
Nee. Robots.txt beperkt het crawlen. Voor het beheersen van de indexering dient noindex, dat zichtbaar moet zijn voor de crawler.
“Canonical dwingt Google de gekozen URL te gebruiken”
Nee. Het is een belangrijk signaal, maar Google kan een andere canonical kiezen.
“Ik heb og:image gewijzigd, dus de kaart is nu nieuw”
Niet altijd. Het platform kan een opgeslagen versie gebruiken en vereisen dat de URL opnieuw wordt opgehaald.
“A+ in de scanner betekent dat de applicatie veilig is”
Nee. Het betekent een hoge score in een specifieke reeks tests. Het bewijst geen correcte autorisatie, bedrijfslogica of codebeveiliging.
Eindoordeel
Eén domein heeft niet één technisch “gezicht”.
- DNS ziet de naam en de records.
- TLS ziet het endpoint en de identiteit van het certificaat.
- De browser ziet de gerenderde ervaring van een specifieke gebruiker.
- Googlebot ziet een resource beschikbaar om te crawlen, te renderen en te indexeren.
- de sociale crawler ziet de metadata die nodig is om een kaart op te bouwen.
- de beveiligingsscanner ziet uitsluitend het oppervlak dat door zijn tests wordt gedekt.
Een volwassen audit vraagt dus niet alleen: “Werkt de pagina?”
Hij vraagt:
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?
Pas de antwoorden op deze vragen vormen een samenhangend beeld van het systeem.
