Site is OK is a website infrastructure health checker. It scans any domain for common issues across HTTP, HTTPS, SSL certificates, DNS, email configuration (SPF/DMARC/DKIM), mail server blacklist reputation, domain registration, and security headers — then gives you a score out of 100.
You can run a check without an account. Just type a domain name and click Analyze.
Creating a free account lets you save domains, track their scores over time, and get a dashboard overview.
↑ Back to topexample.com in the search box on the home page.https:// or www. — just the domain name is enough.8.8.8.8, 2606:4700:4700::1111) is a valid scan target too — the scan covers its web endpoints, TLS certificate (matched by IP SAN), reverse DNS (PTR), network registration, and blocklist reputation. DNS-record, mail and domain-registration checks don't apply to an address and are skipped. Private or reserved addresses can't be scanned.The overall score (0–100) reflects the health of your domain across all checked categories:
max-age ≥ 15552000 (180 days, PCI DSS 4.2.1) and reports includeSubDomains/preload directives and preload eligibility.~all vs -all), and DNS lookup count (max 10 per RFC 7208).p=none/quarantine/reject), subdomain policy (sp=), DKIM/SPF alignment mode (adkim=/aspf=), reporting addresses (rua=/ruf=), enforcement percentage (pct=), and validates external report URI authorization (_report._dmarc TXT record) per RFC 7489._mta-sts. and fetches the policy file at https:///.well-known/mta-sts.txt . MTA-STS enforces TLS for inbound mail to prevent downgrade attacks._smtp._tls.. TLS-RPT specifies where receiving mail servers should send daily reports about TLS delivery failures, and pairs naturally with MTA-STS.default._bimi.. BIMI (Brand Indicators for Message Identification) allows brand logos to appear in recipients' inboxes. It extracts the logo URL (l=) and VMC authority URL (a=), and notes that BIMI requires DMARC enforcement at p=quarantine or p=reject.autodiscover. CNAME/A record (Microsoft Outlook) and autoconfig. A record (Mozilla Thunderbird). These DNS records allow email clients to automatically discover incoming/outgoing server settings, simplifying setup for users.'unsafe-inline'/'unsafe-eval' in the effective script-src, * and data: script sources, 'unsafe-inline' styles, and a missing default-src/script-src fallback. A policy with these gaps still lets injected scripts run. PCI DSS Req 6.5.10.Access-Control-Allow-Origin/Allow-Credentials on the homepage response: flags the spec-invalid * + credentials combination, notes bare * as informational, and flags origin-allowlist + credentials without Vary: Origin (shared-cache risk). No Origin probe is sent, so reflected-origin configs are out of scope.Cache-Control/ETag/Last-Modified on the homepage response: missing explicit policy, public combined with Set-Cookie, day-plus max-age on HTML, cacheable responses lacking both validators and max-age. Informational, unscored.Secure, HttpOnly, and SameSite attributes? Missing flags expose session cookies to interception, XSS theft, and cross-site request forgery (CSRF). PCI DSS Req 6.5.10..git/, .env, backup.sql, .htaccess, composer.json, wp-config.php, xmlrpc.php, phpinfo.php, .svn/, .DS_Store. Exposed files can leak credentials, source code, and configuration. Findings are tiered by what a response actually disclosed: files serving secrets/source are scored problems, low-value config text is a warning, and platform files like wp-config.php — which PHP executes normally, so a request leaks nothing — are reported as informational hardening notes with per-file fix advice. PCI DSS Req 2.2..bak, .old, .orig, .swp, ~, .save, .tmp) of known files like index.php, .env, config.json, wp-config.php. These files often contain source code or credentials left behind by editors or deployment processes.Server, X-Powered-By, X-AspNet-Version, X-Runtime, X-Version, X-Generator), enabled directory listings, and verbose error pages. These leaks help attackers choose exploits. PCI DSS Req 2.2.Alt-Svc header. Informational — does not affect the score.robots.txt, sitemap.xml, and informative .well-known/ endpoints (OpenID configuration, nodeinfo, host-meta, AI-plugin manifest). The files existing is normal — the finding is when they list sensitive-looking paths, because a public Disallow: rule advertises the very path it hides. Warning on sensitive entries, informational otherwise, unscored.Some checks are marked ⚠ Intrusive because they actively probe the target server by requesting many paths (e.g. .git/HEAD, .env, index.php.bak). These checks are not run by default and are completely separated into their own ⚠ Intrusive tab. The scan page has two tabs — Standard and ⚠ Intrusive — placed above the scan input. Standard scans run by default; intrusive checks are a separate, manual action.
To run intrusive checks you must first prove control of the domain on the Verify page — publish your per-account token at /.well-known/siteisok-verify.txt (recommended; the file may hold several tokens, one per line, for teammates), as an HTML meta tag, or as a DNS TXT record at _siteisok-verify.<domain>, then run the check. Verification is per account and is re-checked before each intrusive run — removing the token revokes access. Anonymous users cannot see or run intrusive checks, and cached intrusive results are only shown for domains you have verified. A confirmation dialog then explains the risks (extra requests, server stress, and the possibility that our scanner may be firewalled or blocked by WAF/CDN providers) and requires explicit consent before proceeding. Results appear in the same tab with a separate Intrusive Security score (out of 100) and categorized check sections with icons, similar to the standard scan.
Intrusive checks include:
Origin header and checks whether the server echoes it back — especially alongside Access-Control-Allow-Credentials: true, which lets any website read your pages with a visitor's logged-in session.readme.html or the generator meta tag, REST API user enumeration at /wp-json/wp/v2/users (scored separately — a returned user list is a verified username disclosure), a publicly readable debug.log, a reachable installer, and the state of wp-login.php/xmlrpc.php. Reachable platform endpoints are reported as informational hardening notes — only verified disclosures (debug log, live installer, user list) affect the score. Non-WordPress sites get no card.:6379, Memcached :11211, MongoDB :27017, Elasticsearch :9200, MySQL/MariaDB :3306, etcd :2379, Docker API :2375 + :2376, Kubernetes API :6443, kubelet :10250, VNC :5900, RDP :3389, SMB :445, Telnet :23. Each gets one minimal handshake (or just a listen — MySQL and Telnet speak first; VNC and Docker TLS get a short negotiation to see whether they demand credentials) — no writes, no auth attempts. A service answering without credentials is a critical finding; answering-but-locked is a warning; a refused connection is verified closed; a timeout means filtered (unverifiable, not "clean").swagger.json/openapi.json/api-docs schemas, Swagger UI, Spring Boot Actuator (/actuator/health, /actuator/env, /actuator/heapdump, /actuator/configprops) and GraphQL at /graphql — including one introspection query when an endpoint answers. Every 200 must prove the artifact by content shape before it counts as a finding. An env dump or heap dump is a scored problem (server internals served); a public schema/console or enabled introspection is a warning.:587 (STARTTLS), submissions :465 (implicit TLS), IMAP :993/:143, and POP3 :995/:110. Flags open ports where TLS fails, certificates that are expired or don't match the hostname, and cleartext-only services that expose login passwords.Intrusive checks can trigger WAF alerts or rate limits on the target server, which may result in our scanner being firewalled or blocked. That is why they are gated behind ownership verification — only run them on domains you control. If our scanner gets blocked because of your scans, your account and anything connected to it may be banned from the site.
Intrusive checks are never run by scheduled (cron) checks — they are always a manual, one-time action. Intrusive results are stored separately from standard checks, so they persist independently. Cached intrusive results are only shown to logged-in users for domains they have verified on the Verify page.
To stay polite, intrusive probes are paced (a short delay between requests, sent a few at a time) and the scan stops early if the target repeatedly refuses or drops our requests — in that case some checks show as not run rather than the scanner hammering your server. A 429 rate-limit answer is retried once if the server asks us to wait. If nearly every probe — including a guaranteed-nonexistent control path — is answered with the same refusal (403/406), the check is reported as blocked / indeterminate rather than "no files found", and it does not affect the intrusive score.
Checks distinguish "the site is down" from "the site blocked our scanner":
If our scanner was blocked mid-scan (the site answered, then everything went silent), the result is marked as filtered rather than down, and no "site down" alert is sent.
The tool also detects what technologies your site is built with (CMS, web server, etc.). Detected technologies are shown with a confidence badge:
At the top of the results, you'll see a summary of recommendations — actionable items sorted by severity. Click any recommendation to jump to the relevant check section for details.
↑ Back to topClick your email in the top right to access the Account Settings page, where you can:
Each domain in the dashboard shows a colored score badge on the right:
At the top of the dashboard, a summary bar shows how many of your domains are healthy, warning, or critical, plus your average score across all checked domains. Use the filter tabs (All / Critical / Warning / Healthy) to quickly find domains that need attention. Domains are automatically sorted by urgency — critical issues appear first.
Click the Graphs button on any domain to view visual trends over time:
Charts use server-rendered SVG — no JavaScript libraries — so they load instantly and work everywhere. The graphs page also shows an uptime percentage and average response time summary at the top.
When issues are detected during scheduled checks, alert badges appear next to the domain name:
Email notifications use escalation tiers so you get reminded as the deadline approaches: SSL at 30, 14, 7, and 1 day(s); domain at 60, 30, 14, 7, and 1 day(s). Each tier crossing sends a new email.
These indicators update automatically after each scheduled check. Click the domain row to see full details.
↑ Back to topTo avoid repeatedly pinging servers, the tool uses a caching system:
When email sending is enabled, the system sends automatic alerts for issues detected during scheduled checks:
Alerts are sent at most once per domain per alert type within a 24-hour window to avoid duplicate notifications. You'll receive an email at the address registered on your account.
You can customize how alerts are delivered from the Account Settings → Notifications section:
There are three plans available. The plan determines how many domains you can save and monitor:
Anyone can scan any domain for free without an account. The tier limit only affects how many domains you can save for ongoing monitoring.
Plan details and prices are on the Pricing page; once signed in, your current plan, domain usage, and billing history are on the Billing page. You can upgrade, switch, or cancel your subscription at any time. Payments are processed securely via our payment provider.
When you reach your domain limit, the Add Domain form is disabled and an upgrade prompt appears on the My Domains dashboard.
Upgrading (Free → Paid): Click the "Upgrade" button on any paid plan card, choose monthly or yearly billing, and complete checkout on our payment provider's secure page.
Switching plans (Paid → different Paid): If you already have an active subscription, clicking "Switch to" or "Upgrade to" on another plan triggers an instant plan switch — no checkout page. The proration is handled automatically: upgrades charge the prorated difference immediately, downgrades refund unused time. You can switch plans at most once every 6 hours.
Cancelling: Use the "Cancel Subscription" button in the Manage Subscription section. Your subscription remains active until the end of the current billing period, then your account is automatically downgraded to the Free plan.
You will receive a confirmation email from us for each billing event: new subscription, plan switch, and cancellation. (Our payment provider also sends their own receipt and refund emails.)
Paid subscriptions have an expiration date. If your subscription expires or is cancelled, your account is automatically downgraded to the Free plan (1 domain). If you have more than 1 domain saved, the extra domains remain in your list but you won't be able to add new ones until you upgrade again.
Pro and Business plans also include change history — a timeline of what changed between checks for each domain (SSL issuer, DNS records, security headers, score, and more). Click the "History" button on any domain in your dashboard to view it.
The Business plan also includes weekly email reports — every Monday you receive a summary of all your monitored domains: current scores, SSL/HTTP/HTTPS/DNS status, any expiring certificates or domains, and all changes detected in the past 7 days. The report is sent to your notification email (or account email if no override is set).
↑ Back to topNo. You can run one-off checks without registering. An account is only needed to save domains and track them over time.
No. Your account and saved domains are private. Check results are stored only for your reference.
Saved domains are checked automatically once a day via a scheduled job. You can also run a live check manually at any time from the dashboard or the scan page. Email alerts are sent automatically when issues like SSL expiration, domain expiration, DNS problems, or site downtime are detected.
Scores reflect real-time conditions. SSL certificates expire, DNS records change, servers go down temporarily. A lower score on a live check vs a cached one usually means something changed since the last check.
This means the domain doesn't exist or has no DNS configured. Double-check the spelling — make sure you entered the domain without http:// or paths.
Your server answered our request with a denial code (usually 403 or 429). The site is fine for regular visitors, but its firewall, WAF, or bot-protection is rejecting automated clients like ours. If you want our scanner allowed, whitelist its requests in your firewall/CDN rules — otherwise the warning is expected and harmless.
Your domain (or its mail/DNS servers) points at an IP address that isn't publicly reachable — a private range (10.x, 192.168.x), loopback (127.x), link-local, or reserved space. That happens with internal-only hostnames, development names like localtest.me, or split-horizon DNS that hands out internal addresses. Our scanner only connects to public IPs — it can't reach those addresses, and connecting to them could touch infrastructure that isn't yours. If the site is meant to be public, the DNS record is likely misconfigured.
You entered a name that can never be a real public site — either a reserved/documentation name like example.com, an internal-space ending (.test, .invalid, .localhost, .local, .internal), a single word with no dot, or a name that provably resolves to a private or reserved IP address (like localtest.me or private-IP nip.io aliases — see the question above). Scanning one would produce a meaningless report, so we refuse it up front. Enter the public domain you actually want checked.
Email contact@siteisok.com with the details — affected page or endpoint, steps to reproduce, and any relevant logs. Please give us a reasonable window to investigate and fix before disclosing publicly. We do not run a bug bounty program, but we take reports seriously and will acknowledge your report.
If a scheduled check found the domain unreachable, later runs first send a minimal probe (a connection attempt and a single request) instead of the full scan. When the domain starts answering again, the full scan resumes automatically. This avoids hammering a dead host or a firewall that blocked us.
If a site's firewall actively blocked our scanner, the domain is additionally backed off: we stop probing it entirely for a growing interval (starting at one hour, doubling each time the block persists, capped at 24 hours). A blocked domain shows "Scanner blocked" on the dashboard instead of "Site down". If it's your site, allowlist our scanner via the bot info page — the next probe that gets through clears the block and normal scanning resumes.
↑ Back to top