About
A scanner that readsonly what a browser would
ScanlyFix checks a live site the way a stranger, a search engine and an answer engine all see it — then hands back the evidence and the exact prompt that fixes what it found. This page is what it does to your site, what it does not, and who is behind it.
- 85 checks
- 6 pillars
- Engine 1.24.12
- Read-only by default
- Free account, no card
What it does
One URL in,
one afternoon of work out
Four things happen between pasting an address and reading a report, and none of them involve installing anything.
01
You paste a URL
That is the entire setup. No agent to install, no certificate to generate, no DNS record to edit, nothing to send us beforehand. The only gate is an account, and the account is a code to your email rather than a password to invent.
02
One pass, not eighty
The scan fetches the page once and builds a shared picture of it: response headers, HTML, cookies, the TLS handshake, DNS, robots.txt, the mail records. Every check is then a pure function over that picture, which is why a complete scan costs your server roughly one page view.
03
85 questions, answered or abstained
Each check either says something about what it saw or stays quiet. One that cannot see enough to be sure does not guess and does not score you for a thing it never measured — it reports the limit instead.
04
Evidence, then the fix
Every finding carries the raw value behind it — the header, the record, the response code — so you can run the same lookup yourself and get the same string. The report ends in one prompt that groups the work by the file each change actually belongs in.
Coverage
Six things,
measured separately
A score is never one number pretending to be a judgement. Each pillar is scored on its own, from checks that ran, and the report says which of them it could not finish.
Security
49
Can a stranger read, hijack or impersonate this site?
SEO
17
Can a search engine crawl, understand and rank these pages?
AI answer engines
8
Can an answer engine read, resolve and cite this page?
Performance
4
How long does this take on a real phone, on a real network?
Accessibility
4
Can someone using a keyboard or a screen reader get through it?
Compliance
3
Does anything run before the visitor agreed to it?
The full list, one card per check with what it looks at and when it stays quiet, is on the checks page.
A finding you cannot verify is just an opinion.
Why it exists
Tools produce PDFs.
Nobody reads them.
The advice is not hard to find. It is scattered across a hundred blog posts, worded for people who already know what a CSP is, and it always arrives as a list of things to do rather than the one edit that closes fourteen findings.
Meanwhile the failures that actually bite are the invisible ones. Nobody sends an alert because a CNAME outlived the account behind it, because an API key got compiled into a bundle the browser can read, or because an AI crawler is blocked by a line in a file nobody has opened since 2019. Each of those is quiet, permanent, and one request away from being found.
So this is built for the person who ships the site and also has to fix it: a report you can read in two minutes, evidence you can hand to a developer or paste into an AI editor, and a prompt that finishes the job in whichever of those two directions you happen to be working.
What a scan touches
The whole answer,
including the awkward half
Almost every check is a read of something a visitor could already request. A handful are not, and they run only after you have proved the domain is yours. Here is the split, stated plainly.
On every scan
- Requests pages the way a browser and a crawler would — same origin, GET, a five-second cap on any one request, and a budget of 24 probes for the whole scan.
- Never logs in, never reads a cookie’s value, never submits anything of yours and never follows a redirect into a private address.
- Resolves every hostname through a guard that validates the address at connect time. Loopback, private ranges, link-local metadata endpoints and everything reserved are refused before a byte leaves — and each redirect hop is re-checked on the way through.
- A deep crawl obeys your robots.txt. Disallowed URLs are counted as disallowed, not fetched.
- Keeps findings to paths, names, counts and status codes. Response bodies do not leave the scanner, so nothing your site echoes can end up in a report.
Only on a domain you verified
Injection and JWT forgery
Authored requests to your own parameters and endpoints, read for the shape of the answer. Two endpoints, GET only, nothing extracted and no body kept.
The upload test
The one place this engine writes. A frozen marker file goes through a form your site already exposes and comes back over HTTP, so a server that stores anything without looking at it is visible.
Webhook receivers
Two byte-identical deliveries to a path your own code names, one of them carrying a signature that cannot be valid. An endpoint that accepts the second one is not verifying.
Rate limiting
Seven identical GETs at up to three API paths, which is the shape of a credential-stuffing run. Read honestly: a small burst proves little, and the finding says so.
Backend rules
Supabase row-level security and Firebase rules are asked directly, and the Firebase write test deletes a path the scan first proved was empty. Row counts and table names, never row data.
None of them exploit anything. They ask a question the site already knows how to answer, read the shape of what came back, and stop there.
Beyond one scan
The same engine,
pointed at six more things
A URL is the entry point, not the product boundary. The checks, the scoring rules and the fix prompts are shared across all of these.
Repositories
Install the GitHub app and the same engine reads the code rather than the response: secret scanning, dependency vulnerabilities ranked against known-exploited listings, a license policy that can fail the build, and a CycloneDX or SPDX bill of materials out of the other end.
Pull requests
A review of the lines the PR changed, not the whole repository re-audited on every push. Opt in per repo and the fix comes back as a pull request against your own branch.
Monitoring
A scan is a photograph; most of what matters changes on a day nobody looked. Monitors re-run the scan on the interval you set, probe uptime from outside your own network, and warn about a certificate with weeks left rather than hours.
Status pages
A public page assembled from the same uptime data your alerts use, with visitor subscriptions, incidents and maintenance windows — the link you send during an outage instead of writing one.
Backend connections
Connect Supabase or Firebase and the scan gets to ask the question a website scan never can: whether the key your frontend already holds can read every row in every table.
Agents, CI and runtime
An MCP server so Claude Code or Cursor can run the scan and apply the fixes itself, a CLI with JSON output so a deploy can fail on a finding, and a runtime layer that reports what the page does after it loads.
How it is built
Ordinary tools,
used strictly
Nothing here is a reason to trust us. It is a list of things you can go and check, which is the only kind of claim a security product gets to make.
Server components, static wherever it can be
The landing page, this page and the public report render to plain HTML on the server, so every word is in the document before a browser runs anything. The client side of this page is the nav and the fade-in as you scroll; turn JavaScript off and it still reads end to end.
Postgres, Drizzle, Inngest
One Postgres database with a typed schema layer over it, and every scan, monitor probe and alert delivered as a background function rather than a process that has to stay alive.
A separate scanner worker
Repository scanning runs in its own service behind a shared secret. It clones with a short-lived GitHub App installation token and shells out to open-source scanners pinned to exact versions — the downloaded ones checked against upstream SHA-256 checksums before the image builds. Nothing about that pipeline depends on the web app being trusted.
A real browser, when one is available
The accessibility pillar runs axe-core against the rendered, post-JavaScript page in a headless browser. When no browser tier ran, the static checks stand down rather than pretending they covered it.
Engine 1.24.12
Every scan records the engine version it was measured with, and no feature compares two scans across a change in it. Otherwise the day we ship new checks, every monitored site would get an email saying it had gotten worse.
What we will not tell you
Four things
this page refuses to say
The fastest way to read as a template is to fill every slot a template has. These four are empty because the content does not exist yet, and inventing it is the one thing a page like this must not do.
No logo strip, no testimonial, no user count
There is nothing to put in a press band yet, and a fabricated pull-quote on a security product’s homepage is a claim about a person who never made it. When someone says something worth pulling, it gets its own design rather than being poured into a template.
No severity theatre
A check that could not see enough abstains. A pillar it could not finish measuring is marked provisional rather than scored badly, and a check that errored is recorded as our failure, not your finding.
No blurred rectangles
Where a report withholds a finding it withholds the bytes and tells you the count and the severities. A frosted panel over text the browser already has is a bluff, and the first reader who opens dev tools finds out.
No data resale, no ad pixels, no session replay
The processors are the ones doing a job: the database, the mail sender, the queue, the payment provider. Nothing about you is sold, and no advertising or retargeting tag runs here. One exception, stated because this page has no business being vaguer than the scan: Google Analytics counts page views. That makes the honest claim "no tracking beyond a counter", and a counter is still a thing an SEO tool should name out loud.
Who runs it
One person,
answering the email
There is no team and no funded company behind this: the individual operating ScanlyFix, in India. That is a limitation and a feature at the same time: there is no queue between you and the person who can change the product, and there is also only one of them, so a check you ask for is a check that gets written on a schedule nobody can promise you.
The checks are written by reading the specification, not the summary of it, and by refusing to ship a claim the code cannot support. If that ever stops being true, the email below is the shortest path to someone who has to answer it.
Support, privacy and disputes
Terms and privacy policy are dated 28 August 2026, and the terms govern under India.
Enough about us.
About your site, then.
85 checks, the measured value behind every finding, and one prompt that fixes them. About a minute, and a free account.
ScanlyFix
Security, SEO and AI-answer-engine scanning for anything you put on the internet. Paste a URL, read the evidence, run the fix.
Home