Skip to content
VDHome
Request a quote

What does a visitor of your website see?

Any visitor can use their browser's developer tools (F12) to see which cookies your website sets, what it fetches from others and how your domain protects your e-mail. Below is how to check it yourself in five minutes, without installing anything.

Did you get an e-mail from me? It named one point I saw as an ordinary visitor. Here is the full list, with the steps to check it yourself: you do not have to take my word for it.

Try the browser steps on www.vdhome.be first: that is what it looks like when everything is in order. Then on your own website.

Steps checked on 16 October 2026.

First: open the developer tools

  • Open your website in a private window and do not click anything yet, not even the cookie banner.
  • Chrome and Edge: press F12 or Ctrl+Shift+I (on a Mac: Cmd+Option+I).
  • Firefox: press F12 or Ctrl+Shift+I (on a Mac: Cmd+Option+I).
  • Safari: first turn on the features for web developers in Safari > Settings > Advanced. Then: Develop > Show Web Inspector, or Cmd+Option+I.

1. Cookies before consent

Look on the home page, before you answer the cookie banner.

Chrome and Edge

  1. Choose the Application tab.
  2. On the left under Storage, open Cookies > your domain. Local storage, Session storage and IndexedDB are listed there too.

Firefox

  1. Choose the Storage tab.
  2. Open Cookies > your domain. The same tab also shows Local Storage, Session Storage and Indexed DB.

Safari

  1. Choose the Storage tab.
  2. Open Cookies for your domain. The same tab also shows Local Storage and Session Storage.

What you should see: Only cookies the site really needs to work. Names such as _ga, _gid, _gcl_au, _fbp or hubspotutk are analytics or marketing cookies: they should only appear after the visitor accepts them.

Why it matters: According to the Belgian Data Protection Authority, non-essential cookies require the visitor's consent beforehand.

Data Protection Authority on cookies (in Dutch)

2. Content from other parties

Keep the developer tools open and reload the page, so every request appears in the list. Below, replace yourdomain.be with the domain in your address bar.

Chrome and Edge

  1. Choose the Network tab and reload the page (Ctrl+R, on a Mac Cmd+R).
  2. Type in the filter box: -domain:yourdomain.be

Firefox

  1. Choose the Network tab and reload the page.
  2. Type in the Filter URLs box: -domain:yourdomain.be

Safari

  1. Choose the Network tab and reload the page.
  2. Safari has no such filter: show the Domain column (right-click a column title) and sort on it.

What you should see: An empty list, or only parties the visitor has already consented to. You often see fonts.googleapis.com (fonts), maps.googleapis.com (a map), www.google.com/recaptcha or youtube.com: each time, the visitor's IP address goes to that party.

Why it matters: An IP address is personal data. You can put fonts on your own server; a map or video can load only after a click.

3. A privacy and cookie policy

You do not need the developer tools for this.

In any browser

  1. Look at the bottom of the home page for a link such as Privacy, Privacy notice or Cookie policy.

What you should see: A link on every page, to a text that says which data you process, why, for how long and whom the visitor can contact.

Why it matters: Anyone who collects personal data, for example through a contact form, must explain this beforehand (GDPR, article 13).

4. Always a secure connection

Keep the Network tab open.

In any browser

  1. Type http://yourdomain.be (without the s) in the address bar.
  2. In Network, choose the first request to https:// and look at the response headers.

What you should see: You land on https:// automatically, and the headers contain Strict-Transport-Security.

Why it matters: Without a redirect a visitor can stay on an unsecured connection; HSTS tells the browser to always open your site over https from then on.

5. A contact point for security problems

You do not need the developer tools for this either.

In any browser

  1. Open https://yourdomain.be/.well-known/security.txt.

What you should see: A short text file with a Contact: line and an Expires: date.

Why it matters: Whoever finds a flaw on your site then knows whom to report it to. It is an international standard (RFC 9116).

RFC 9116

6. Your e-mail domain: SPF and DMARC

This is not done in the browser but with one DNS lookup. Type the two lines one after the other.

Windows (Command Prompt)

  1. nslookup -type=TXT _dmarc.yourdomain.be
  2. nslookup -type=TXT yourdomain.be

Mac and Linux (Terminal)

  1. dig +short TXT _dmarc.yourdomain.be
  2. dig +short TXT yourdomain.be

What you should see: For _dmarc, a line that starts with v=DMARC1 and contains p=quarantine or p=reject. p=none means: only watching. For the domain itself, a line v=spf1 ... that ends in -all or ~all.

Why it matters: Without DMARC someone else can send mail that appears to come from your domain, for example a fake invoice to your customers, and you do not notice. Use the domain of your e-mail address, even if your website has a different domain.

How is a domain without DMARC misused?

Why it is possible

E-mail was designed without checking the sender. The line "From: info@yourdomain.be" the recipient sees is plain text that the sending server fills in itself, like the return address on the back of an envelope.

What SPF, DKIM and DMARC each do

  • SPF says which servers may send for your domain, but it checks a hidden technical sender address, not the visible From line.
  • DKIM puts a digital signature on the mail, but any domain may sign, including the forger's own.
  • Only DMARC requires the domain in the visible From line to match a domain that passed SPF or DKIM. It tells the receiver what to do otherwise: deliver anyway (p=none), spam folder (p=quarantine) or refuse (p=reject), and it sends you reports on who mails in your name.

How it is misused in practice

  • Fake invoices: a mail that seems to come from your accounts department, saying your bank account number has changed.
  • Phishing of your customers and suppliers: a link to a fake login page, under your name.
  • Damage to your reputation: your domain lands on spam lists, and your real mail ends up in spam folders more often.
  • You notice nothing: without DMARC reports you cannot see who sends in your name.

How big is the risk?

Large providers such as Gmail and Microsoft 365 often put unverified mail in the spam folder, but not always. Smaller mail servers often check less. p=none protects as little as no DMARC: it is a good first step to learn who mails in your name, not the end point.

What DMARC does not solve

Domains that look like yours (an l instead of an i, or another extension) and a hacked mailbox. A domain that never sends mail is protected with v=spf1 -all and DMARC p=reject.

One step further, free

NIS2 check

Does NIS2 apply to your business? About ten questions, with the article of law at every step.

Start the NIS2 check

Free scan

Where is your data? Ten questions, a report straight away.

Start the scan

Cookie-consent self-check

Does declining your cookies actually work? I load your site in a real browser; first I verify an e-mail address at your domain.

Request it for your domain

The NIS2 check and the scan compute entirely in your browser: nothing is sent.

Rather have me take a look?

That is the Trust Report: a written overview of what a visitor and a mail server see of your organisation, with the evidence and what you can do about it.

Fixed price EUR 250, delivered in 5 working days; launch price EUR 150 for orders up to and including 31/12/2026; delivery may fall in 2027.

See the Trust Report See a sample report (PDF in Dutch, fictitious office)

This page is not legal advice. A website says little about how well your organisation is secured; NIS2 is about much more than that.