A clean site, and the means to prove it
An antivirus has triggered on a customer's machine. A browser is putting a warning screen in front of your page. A reputation list has included you. You look at your site, and it's fine. You now find yourself in the most uncomfortable position there is: proving an absence, to someone for whom your word is precisely the one that counts for least.
This page does two things. It sets out the possible causes and the order of steps to find out which one is yours. Then it explains how the answer is delivered: as a document your counterpart verifies for themselves, on our systems, free of charge, without having to take your word for it or ours.
Where a flag comes from when the site is fine
A flag rarely concerns "your site" as a whole. It concerns an address, a domain, a page, a resource or a code pattern — and any one of those can be at fault while your files are exactly the ones you published. Six causes come up again and again, and each one leaves your files untouched.
A reputation carried by the address
Many reputation lists judge an IP address first, and your domain name inherits that judgement. If the address was used for something else before you, or if it's still associated with bulk email sending, the flag targets the address and catches your domain along the way. Your files themselves are entirely in the clear.
The neighbourhood on shared hosting
On a shared hosting plan, hundreds of sites sit behind the same address. A neighbour gets caught out, the address is called into question, and the whole building wears the label. It's a common cause of a flag that seems to come out of nowhere, and one of the few where the answer is a single call to your host.
The domain name's past
A second-hand domain comes with a history. If it was used for something else in the past, reputation lists remember it longer than you will. The flag is then perfectly grounded in fact — it's just that those facts predate your very first file.
A third-party resource your pages load
A font, a video player, an ad network, an analytics tool, a chat widget: your pages often call on several domains that aren't yours. It only takes one of them to be flagged for the page calling it to be flagged too. Your site is then the messenger, and the cause lives with someone else.
An overly broad pattern match
An antivirus recognises patterns. A slightly broad pattern catches legitimate code that resembles it: a file compressed by your publishing tool, a minified library, a perfectly ordinary encrypted excerpt. The recognised pattern really does exist; it's the conclusion drawn from it that goes too far.
An outbound link to a flagged site
A long-standing link to a partner, a directory, an article: the destination site has changed hands since, and today it's flagged. Some lists pass part of that judgement back to those who point to it. Here again, every one of your files is exactly the one you published.
The order of steps to find out which one it is
This order exists for a reason: each step rules out causes and narrows the scope of the next. The first four you can do alone, with what you already have on hand. The fifth is where the human eye stops. The sixth is the one that puts an end to the story.
Copy the report word for word
First things first: the exact wording, the date, the time, and WHO is speaking — an antivirus on a customer's machine, a browser, a reputation list, an email from your host. Ask the customer who alerted you for a screenshot. Most reports name the thing they saw: a third-party domain, a file path, a pattern family. That one word points the way for everything else.
Look at your site through the visitor's eyes
Open your pages from an ordinary machine, on a network other than the office one, and while logged out of your admin area. A conditional redirect shows itself to certain visitors only, and the owner is almost always the one it hides from. If your pages are identical in every case, you've just ruled out half the possibilities.
List what your pages call out to
Your browser's network tab lists every domain contacted when a page loads. Compare that list against what you believe you've installed: on a site that's been around, surprises are common. A domain you don't recognise is either a forgotten third-party resource, or the very thing that triggered the flag.
Look at the address, the neighbourhood and the history
Your host can tell you whether your site shares its address, and with how many others. Public records tell you how long the domain has existed and how many hands it has passed through. These two questions often settle causes 01, 02 and 03 on the right side, and they take only moments to ask.
Ask every file to account for its presence
This is where the human eye reaches its limit, and the one step on this list you'll struggle to do alone. A live site carries tens of thousands of files; reading through them one by one is out of reach, and eyeballing them amounts to confirming what you hope to find. The question that can actually be answered is the reverse one: how many files can account for their presence, and which ones cannot?
Respond with evidence, and request a review
Every party that flags a site offers a route to review: a form, a contact address, a console for site owners. What shortens the exchange is what you attach to it. A dated, signed document naming the number of files examined and the number of files accounted for, one your counterpart can verify themselves, carries weight that your word alone cannot.
A document your counterpart can verify themselves
The analysis answers point 05 by turning it around: instead of looking for what is known to be bad, it asks every file to justify its presence, by comparing it with the authentic code published by its publisher. Whatever is justified is counted. The rest is named, one by one, with its date and location.
That's exactly what a healthy site needs: a number, rather than an opinion. "I assure you everything is fine" and "here is the number of files examined, the number of files matched against their publishers' code, and the date" are two very different kinds of statement. The second one can be forwarded, attached to a file, and re-read later.
You receive the full diagnosis, the dating, the likely point of entry if there is one, and three signed documents: the findings report, the certificate of the resulting state, and the document you hand to a third party — your client, your host, or whoever flagged the issue to you.
One caveat, written here as it is on every document: a fully accounted-for site is a site where every file has been justified — which is already a great deal, and is still not the same as a secure site. A weak password, or an up-to-date but vulnerable extension, remains beyond the reach of a file comparison. Any page promising you "your site is clean" without this caveat would be lying to you.
Anyone who has doubts can verify the document themselves
This is the point that changes everything, and it fits in one sentence: verifying one of our documents is free, for everyone, forever. Your client, whoever flagged the issue to you, an insurer, a judge: each one opens the verification page, enters the document, and reads the result with no account, without asking our permission, and without having to take your word for it.
That is what makes our documents admissible as evidence. An attestation that only its issuer can confirm is worth only as much as the issuer. An attestation that the sceptic can verify for themselves needs nothing from us — and that is precisely when it starts to be useful.
The analysis itself is paid, and that is deliberate. A free analysis would almost always answer "nothing found" — the expected good news, delivered without proof, to people who didn't need it. We sell certainty, not anxiety. And in your case specifically, the distinction is everything: what you are buying is not the good news — you already have that. It's the PROOF that the good news is true, and that a third party can verify it without you.
Record: €99 per site, one-off payment — the full diagnosis, the dating, the likely point of entry, and the three signed documents. With restoration, Record + Restore: €199.
When the report is right
This has to be said plainly, because it is the very point of a verification: sometimes the analysis does find something. A file added to an uploads folder, an extension abandoned by its developer, a page template modified one evening. The site works, the pages load, the orders come in — and yet this site differs from the one that was attested.
This is the best possible moment to find out: before the report spreads, before a host suspends the account, before a customer walks away. The report you wanted to refute then becomes the favour someone did you. An honest analysis has to be able to return both answers — otherwise the first one is worthless.
In that case, the first-hour steps are written out in full elsewhere on this site: what to copy before anything else, what to timestamp, when to reset access credentials.
Staying demonstrable the following month
An attestation states the condition of a single day. What holds over time is knowing the very same day that something has changed: the first executable file that changes breaks the attestation, and you are notified. Monitoring also picks things up on days when your site itself stays identical — a version fallen behind, an extension pulled from its publisher's official repository, a vulnerability published since.
It speaks with precision: when the attestation breaks, it means that this site differs from the one that was attested. Your own deployment breaks it in exactly the same way — which is why you re-attest after every release. Watch: €99 per site per year, one-off payment, no auto-renewal; with restoration, €199.
How many files on your site can justify their presence?
You'll get the exact number, every file named, the date, and three signed documents that whoever flagged you can verify themselves, free of charge.