You paid for a website. See what you actually got.
When someone builds a site for you, you see the pages. You don't see whether they left a copy of your database where anyone can download it, left the passwords and keys sitting in a file on the site, or skipped the basic settings that keep you out of trouble with Google and email providers. This gives you a plain report on what is wrong, so you can go back to whoever built it with something specific.
What you can't see from the front page
The visible part of a website and the safe part of a website are two different things. A site can look finished, load quickly and work perfectly on your phone while being wide open in ways no page will ever show you. None of what follows is visible to a visitor, and none of it is something you could reasonably be expected to spot yourself.
- Whether the connection is properly secured. Not just the padlock, but whether the certificate is valid for the whole time it needs to be, whether anyone visiting over plain HTTP is actually moved to the secure version, and whether parts of the page still load insecurely. (How the certificate check works)
- Whether the browser is told to protect your visitors. A handful of settings sent with every page decide whether a browser will block common attacks or shrug at them. They cost nothing to add and are skipped constantly. (The headers in question)
- Whether the code running your site is current. Websites are assembled from parts, those parts get security fixes, and a site handed over a year ago is running whatever was current then. (How known vulnerabilities are matched)
- Whether files that were never meant to be public are being served anyway. Configuration files, backups, database exports and developer folders that got uploaded with everything else. (The files worth checking for)
Common things left behind by a rushed build
None of these mean you were cheated. They are what a deadline looks like from the inside: the site got finished, the tidying did not, and nobody went back because nothing appeared to be wrong. They are also all straightforward to fix once somebody knows they are there.
- A database export left in the web root. Often called backup.sql or dump.sql, sitting at a guessable address. If your site stores customer details, this is a copy of them that anyone can download.
- Configuration files with the passwords still in them, including the copies an editor leaves behind: config.php.bak, wp-config.php.old, files ending in a tilde.
- The developer's repository folder, uploaded with the rest. It contains the full source code and every password anyone ever committed, including ones that were later removed. (What that exposes)
- Folders that list their own contents. Open one address and the server shows you everything inside, which turns a folder of backups into a menu. (Directory listing explained)
- Missing email protection. Without the right DNS records, anyone can send mail that looks like it came from your domain, and your own mail is more likely to land in spam.
- A staging copy of the site still live somewhere, usually on a subdomain, still holding real data and rarely updated.
What to send back to your developer or agency
You do not need to understand the fix to ask for it. The report names each problem, where it is, and what has to change, which is enough to turn an awkward conversation into a work item. Send the report link and ask for three things:
- Confirmation of what will be fixed and by when. Anything marked critical or high is worth treating as this week, not next quarter.
- For any exposed file: confirmation that the passwords and keys inside it have been changed, not just that the file was deleted. A deleted file does not un-copy itself.
- A re-scan afterwards, so the fix is confirmed rather than reported. The link stays the same, so you can compare the same page before and after.
Check the site you paid for
Enter the address and the free scan reads the site from the outside in about thirty seconds. Nothing is installed, nothing is changed, and you do not need access to the server or anyone's permission to look at a public page.
Scan the site, freeFAQ
- Can I scan a site I don't have logins for?
- Yes. The free scan only reads what the site already shows every visitor, so it needs no access and no cooperation from whoever built it. The deeper pass, which goes looking for files that are not linked from anywhere, runs only after the domain is verified as yours.
- Will this break anything or annoy my developer?
- It cannot break anything. The free scan makes a handful of ordinary requests, the same as any visitor. Most developers would rather hear about an exposed backup from you than from somebody who found it first.
- The site was built years ago and nobody maintains it. Is it worth scanning?
- That is the case most worth scanning. Certificates expire, the components a site is built from accumulate known vulnerabilities, and a site nobody has touched has had the longest time for all of it to happen quietly.
- What if I don't understand the results?
- Every finding is written for the person who owns the site, not for a security team: what it is, what it costs and what has to change. If a fix needs a developer, the report says what to ask for.
Related checks
- Exposed secrets and API keysThe files a rushed handover leaves behind: config files, backups, database exports and private keys.
- Core security headersThe settings that cost nothing to add and are skipped more often than any other, plus how to ask for them.
- SSL/TLS certificateExpiry, hostname coverage and the chain: the padlock is not the whole story, and a lapse takes the site down.
- How to tell if a site has been hackedIf something already looks wrong rather than merely unchecked, start here instead.