Security & data

What happens to your data when you audit a page

This is not a page of reassurances. It is a description of what our system actually does with the address you paste, written from the code that does it.

If you are weighing us up before submitting a client's URL, or you need something to forward to a security team, this is the page to send. It answers one question: what exactly do you keep about my site, why, and for how long?

What we do to the page you submit

Requests a visitor's browser could make — and nothing a visitor could not.

The free sample reads what your site returns to the public at the address you submit: the response headers and the HTML. Around that page it makes a few small requests any browser could make: one with a test Origin header, to read the cross-origin (CORS) policy, and the favicon when the HTML declares none.
The paid audit also opens the page in a real browser, as a visitor would, including as a phone, and loads it three more times on a simulated phone to measure performance. It reads the files the page itself loads, a limited number of addresses the page itself points to (for example its privacy notice, its canonical address and its app icons), /robots.txt, the source maps its scripts publish, and the DNS records and TLS certificates of the hosts on the way. To measure responsiveness it may open a menu, a tab or an accordion on the page.
The analysis is passive. We do not log in, submit forms, inject payloads, try credentials, scan ports, or crawl the site beyond the addresses above. One URL, one report: links found in the markup are read as data, never followed as new audits. Requests from our servers identify themselves in the user agent as SiteMeritBot; the browser presents itself as an ordinary browser, because what it measures is what a visitor gets.
When our servers follow a redirect, they re-resolve the destination at every hop, checking the IP address before connecting. That check keeps our engine from being pointed at a private network — a protection for you as much as for us.

What we store, record by record

The records below, and a counter. This is the whole list.

	What it holds	How long we keep it
The audit result	The URL you submitted, the language of the report, whether it is a paid report, the engine version, the timestamp, and the full result: every check with its verdict and the score. Paid reports also hold what was observed while the page executed in a browser — accessibility findings, the cookies and third-party domains seen during the initial load, and the execution signals matched against our technology signature catalog, with the catalog version — and the written guidance that was generated.	A free audit is created with an expiry stamp seven days out. A paid report carries no expiry.
The purchase	Written only when a payment completes: the audited address as submitted, which modules were bought, the amount and currency, and the timestamp. Never your card details — those go to Stripe and never reach us — and not your e-mail address: it stays with Stripe, and we read it from there only to send your report.	No expiry is set on this record: it is the accounting record of the sale.
The purchase observation	Written only for a paid audit, in private storage: what our servers and the browser observed on the page — headers, HTML, the files it loaded, screenshots and performance measurements — and the package of findings sent to the AI provider to write the analysis and the fix guide.	Deleted automatically 30 days after it is written. The report built from it stays, as above.
The delivery record	Written for a paid audit while it is produced: the address being audited, the progress and timing of each step, and why a step failed, so that a delivery that stalls can be resumed or cancelled — never charged without being delivered.	No expiry is set on this record: it is the trace of how the purchase was delivered.
The page events	Written only if you accept in the cookie banner: the name of the event (a page view, a click on a call to action or on an internal link, the start of an audit), the page, the language, the version of the page's content, the event's parameters, a deduplication key and the date. No IP address, no cookie and no visitor identifier: this record can say how many times a page was opened, and never who opened it.	No expiry is set on this record.
The rate-limit counter	A count of requests per hour, so that a single source cannot exhaust the service. Your IP address is not stored: it is reduced to an irreversible SHA-256 hash that serves as the counter's key.	The counter is stamped to expire two hours after the window it belongs to.

The reason we store results at all is the very thing you paid for. A paid report lives at a permanent link you can return to, reload, and send to a client. Deleting the result would mean the deliverable does not survive closing the tab — so the persistence is not a slip we are confessing to, it is the feature.

Questions about your own data, including removal, go to privacy@sitemerit.com, which is the queue meant for exactly that.

What we never ask you for

You can run an audit without creating an account. There is no registration, no password, no login, and no profile of you. On a free audit, the only thing you hand over is the address you want checked. An e-mail address enters the picture at one moment only: when you pay, because Stripe's checkout collects it along with the payment.

Who else receives the data

We do not sell, rent, or trade data. Five companies do receive some of it, because the product cannot work otherwise — and it would be dishonest to leave them off this page.

Stripe — processes the payment. You enter your card details on Stripe's own checkout, not on our site. We receive the confirmation and the e-mail you gave them; the card number never reaches us.
OpenAI — receives data at one moment. For the written analysis and the fix guide in paid reports: the findings of your audit, with excerpts of what was observed on the page (credentials found on it are masked first), are sent to OpenAI for AI-assisted interpretation, and the text that comes back is stored with your report.
Resend — sends the e-mails about your purchase: the link to your report, or the notice that the order was cancelled. It receives your e-mail address and the message; the report itself stays with us.
Google — hosts the records. Everything in the table above is stored in Google Cloud, in a project we operate: the records in Firestore, the purchase observation in Cloud Storage. Google holds it as our storage provider; we send it nothing for any other purpose.
Vercel — runs the service. Every request to our site and to our API is served by Vercel, which executes the code this page describes and keeps the request logs any hosting platform keeps, under its own retention. Our code does not read them.

What we do not have

Stated here, before you have to ask for it.

We are not SOC 2 certified, and we are not ISO 27001 certified.
We have not been through a third-party penetration test.
We do not run a bug bounty programme, and we do not pay for reports.
We do not claim that your data is never stored. It is stored, and the sections above say where and for how long. Any audit tool that claims otherwise while handing you a permanent report link is describing something other than its own architecture.
We do not certify anyone's compliance, our own included. Our reports detect signals of risk; that is not a certificate, and no automated tool can issue one.

What "security" means inside the report

So that the word is not left doing vague work, this is the exact list our engine looks at in the security category — 18 checks, every one of them read from what your site already shows the public: its response and its certificate:

Strict-Transport-Security (HSTS)
Content-Security-Policy (CSP)
X-Frame-Options
X-Content-Type-Options
Referrer-Policy
Permissions-Policy
Cookies: whether the session and login cookies the site sets carry Secure, HttpOnly and a declared SameSite, read from the server's headers, the files the page loads and what the browser recorded, including cookies written by JavaScript — long lifetimes and third-party cookies sent without Secure are flagged as warnings; cookies of other domains are counted, not judged
Whether the page links to a privacy policy — we look for the link, not at what the policy says
Server and technology details exposed in the headers
CORS configuration
The TLS certificate of the final page: in date, issued for the site's name, sent with its intermediate certificates and chaining to a trusted authority
Mixed content: whether the https page asks for an image, script, stylesheet, font, frame or other subresource over plain http
Subresource integrity: whether fixed-version scripts and stylesheets loaded from another site carry a valid integrity hash that matches the file
Exposed credentials and source code: whether the page, its own scripts, a published source map or an address the browser asks for hands a secret or the server's code to any visitor — we report the type, the place and the size, never the value
Vulnerable JavaScript libraries: whether a library the page loads, in a version identifiable from the file or its address, has a public vulnerability advisory for that version (Retire.js database, dated copy) — we name the advisory and the fixed version; an advisory is about the version, not about how the site uses it
Tracking before consent: whether the page already contacts advertising, analytics or social media services, stores a tracking cookie or storage key, starts a session recorder or fetches Google Fonts from Google before the visitor chooses anything — we detect signals of tracking before the choice, as seen from the United States, never a claim that it is unlawful
Reverse tabnabbing on outbound links
Protocol downgrade: whether any step from the address requested to the final page — a redirect, a meta refresh, a Refresh header or JavaScript — sends the visitor from a secure https page to an insecure http address

All 18 are observations of what your site shows the public. None of them requires touching anything private, and none of them is a penetration test.

One of these 18 — the Content-Security-Policy check — is one our own site failed, on August 1, 2026. We tightened the policy, and on August 30, 2026 our own audit returned a pass. The dated record of both: Read our own audit record

Reporting a security problem

If you find a vulnerability in SiteMerit itself, write to security@sitemerit.com

There is no guaranteed response window. We are a small team, and we would rather say so than publish a service level we cannot hold to — a 48-hour promise is the easiest sentence on this page to write and the hardest to keep.
There is no bug bounty and no reward. We are not going to imply otherwise by staying quiet about it.
What we do commit to is what a small team can actually deliver: we read everything that arrives at that address.
And we will not set lawyers on anyone who reports a problem in good faith.

See what it reads on your own site

The free sample runs against the page you choose, with no account and nothing to cancel.

Start audit