Paste a URL. In under a minute, get 63 security, SEO, and AEO checks — each with a copy-paste fix prompt for your AI editor.
Free to scan. An account opens the findings.
[ 01 ] The report
Not a mockup — the components below are the report's own, rendered from a recorded scan of example.com. A screenshot would go stale; this cannot drift from what a visitor gets, because it is what a visitor gets.
example.com
Worst findings first
security.headers.cspNo CSP header or meta tag is set, so any injected script runs with full access to the page — CSP is the main defence-in-depth layer against XSS.
Fix: Add a Content-Security-Policy header to every HTML response. Start strict (default-src 'self') and loosen only for origins the site really uses.
security.tls.https-redirecthttp:// serves content (HTTP 200) instead of redirecting. Users and links that start on http never reach the encrypted site, and stay fully interceptable.
Observed
Fix: 301-redirect all http:// traffic to https:// and add HSTS once that works.
security.headers.hstsWithout HSTS the browser will still try plain HTTP on direct visits and typed URLs, leaving users open to SSL-stripping on hostile networks.
Fix: Send Strict-Transport-Security: max-age=31536000; includeSubDomains on all HTTPS responses.
…and 17 more, grouped by pillar.
[ 02 ] Coverage
One fetch builds a shared picture of the page — headers, HTML, cookies, TLS, DNS, robots.txt — and every check is a pure function over it. That is why a full scan costs your server one page view.
Can a stranger read, hijack or impersonate this site?
Can a search engine crawl, understand and rank these pages?
Can an answer engine read, resolve and cite this page?
How long does this take on a real phone, on a real network?
Can someone using a keyboard or a screen reader get through it?
Does anything run before the visitor agreed to it?
[ 03 ] Evidence
Every finding carries the raw observation behind it — the header, the record, the certificate, the response code. Nothing is inferred, and nothing is a generic best-practice bullet dressed up as a result.
The claim
DMARC record has no rua= reporting address
The policy is p=reject, so receivers are acting on failures — but with no rua= address the aggregate reports go nowhere. Legitimate mail that starts failing is quarantined with no signal to anyone.
security.email.dmarc
Observed
Read it yourself: dig +short TXT _dmarc.example.com returns the same string. Every finding in the report can be re-checked this way.
[ 04 ] Output
One prompt for the whole report, grouped by where the change is actually made — response headers in one edit, DNS records marked as not-code, page markup in the shared template. Paste it into Claude Code, Cursor, or your own agent.
fix-prompt.md
excerpt
Fix the issues below on example.com. The stack could not be identified from the response, so confirm where response headers and page templates live before editing. 15 issues, grouped by where the change is made. Work through the sections in order; within a section every change lands in the same place, so make them as one edit. ## 1. Response headers Set all of these in wherever response headers are set for this site: the web server config, the CDN, or the framework's header configuration. ### Missing Content-Security-Policy [high] Add a Content-Security-Policy header to all HTML responses in this project. Configure it in the web server or framework middleware (not a meta tag). Start from: default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'. ## 2. DNS records — NOT code These are changed at the DNS provider for the domain. Do NOT edit any file in the repository for them. If DNS is managed as code here (a zone file, Terraform, Pulumi, CDK), change it there; otherwise output the exact records to add and stop. ### DMARC record has no rua= reporting address [low] The DMARC record at "_dmarc.example.com" is "v=DMARC1;p=reject;sp=reject; adkim=s;aspf=s" and has no rua= tag, so nobody receives aggregate reports…
“Add a Content-Security-Policy header” is not actionable until you know whether that means next.config.ts, a _headers file or an nginx block. Fourteen findings that land in the same file become one edit.
A leaked credential is rotated first, because every later change is wasted if the key is already in someone’s hands.
ScanlyFix is also an MCP server. Point your editor at it and the agent runs the scan, reads the findings and applies the fixes without a report ever being opened.
[ 05 ] AI answer engines
Search is becoming answers, and an answer engine that cannot parse a page does not rank it lower — it never mentions it. Nothing in Search Console reports the citation you did not get.
The failures are mundane and invisible: the text arrives only after JavaScript runs, the robots file blocks the crawlers by name, there is no schema tying the page to a real entity, and no date to tell a model whether any of it is still true.
8 checks in this pillar
[ 06 ] Monitoring
A scan is a photograph. Most of what this engine measures — a certificate, a DNS record, a header set by a deploy — changes on a day nobody was looking.
97.78% over 90 days · 2 failed checks
[ 07 ] Safety
You are about to hand a security tool the address of something you own. These are the limits it is built to, not the ones it intends to keep.
[ 08 ] Pricing
All 63 checks run on every scan, free or paid. What a plan changes is how much of the report comes back — never how carefully the site was measured.
₹0 / month
₹1,499 / month
Scanning needs no account, and the score, the pillar breakdown and every finding’s title and severity are public without one. A free account opens the worst few in full — the evidence and the fix. You always know exactly what you are missing rather than being asked to guess.
[ 09 ] Questions
To scan, no — anyone can run one, and the score, the pillar breakdown and every finding’s title and severity are public on a shareable URL. To read the findings themselves you do: an account opens the worst of them in full, with the evidence behind each one and the fix. It is free, and there is no password to create.
No. A scan is a read: it requests pages the way a browser and a crawler would, never logs in, never submits a form, and never changes state. The two checks that touch a backend run only on a domain you have verified you own.
Lighthouse measures one page in a browser; an SEO tool reads the markup. This reads the response — headers, TLS, cookies, DNS, robots — across 63 checks in six pillars, shows the raw value behind every claim, and ends in a prompt an AI coding agent can execute.
Eight checks on whether an answer engine can read, resolve and cite your page: whether the text survives without JavaScript, whether AI crawlers are allowed, whether there is schema tying the page to a real entity, and whether anything dates the content. Search Console reports none of this.
Yes. There is a CLI with JSON output, and ScanlyFix is an MCP server — point Claude Code or Cursor at it and the agent runs the scan and applies the fixes itself.
It should not, and the engine is built so it cannot happen silently. Every scan records the engine version it was measured with, and no feature compares two scans across a change in it. If checks were added, coverage moved — and you are told so rather than emailed that your site got worse.
It is recorded as our error, not your finding, and the pillar it belongs to is marked provisional. A partly broken instrument is never presented as a measurement.
63 checks, the evidence behind every one, and a prompt that fixes them. About a second, and no account.