Enter a page address for up to 11 checks of what your website shows publicly. See your score and first findings straight away, then enter your email to open the full report.
Check your website
Sources: the page’s public response, php.net, WordPress.org and the public domain record
These checks look at browser protections, visible software versions and domain renewal. They help you decide what to discuss with your host or developer, without needing access to your hosting account.
We check that the page loads over HTTPS and that its plain HTTP address redirects there. HTTPS encrypts traffic between the visitor and the website. If plain HTTP does not answer, we do not treat that as a missing redirect.
HSTS tells browsers to use HTTPS on future visits. We look for a Strict-Transport-Security header that lasts at least 180 days. A shorter period needs attention, and a missing or disabled header fails this check. We only check HSTS on HTTPS pages.
A Content Security Policy tells the browser which sources of scripts and other content the page allows. We look for a policy in the response headers or HTML. Its presence passes this check, but we do not judge whether its rules are strong enough.
We look for X-Content-Type-Options with the value nosniff. This asks browsers to respect the stated content type rather than guess what a file contains. A missing header is a suggested improvement, rather than proof of a flaw.
We look for rules that limit who can embed your page inside another website. These can appear in X-Frame-Options or the frame-ancestors part of a Content Security Policy header. They help prevent visitors from clicking your page through a misleading overlay.
A Referrer-Policy header controls how much of a page address travels with a visitor when they follow a link. We check whether the header exists. We do not assess its value, and a missing header does not mean the browser shares everything.
If X-Powered-By reveals a PHP version, we check whether its branch still receives fixes and compare its patch release with php.net. Hosts sometimes backport fixes without changing the visible version. Ask your host about applied patches before treating an old number as a confirmed flaw.
The Server header can reveal the software and version that answers a request. We flag a visible version number because it gives outsiders more information about your setup. Hiding it reduces that detail, but does not replace installing updates.
We look for WordPress paths and a version in the page HTML, then compare a visible version with WordPress.org. A missing version passes this check without proving WordPress is current. If the release lookup fails, we flag the visible version without claiming it is outdated.
On HTTPS pages, we look for resources loaded through plain HTTP. Scripts, stylesheets and embedded frames get a Fix result, while images and media get Improve. This reads the HTML only, so resources added later by JavaScript are outside the check.
We look for an expiry date in the domain’s public registration record. Fewer than 30 days gets Fix, and 30 to 60 days gets Improve. More time gets Good. If the lookup fails or supplies no date, we leave this check out of the score.
Each finding has a text label as well as a color. Read the detail before deciding what to change, because some findings need your host to confirm the facts.
The score weighs checks by their impact, rather than counting them equally. HTTPS, PHP versions and mixed content carry the most weight. Checks we cannot run are left out, so compare the findings as well as the number.
Start with Fix results and ask who owns each change. Hosting settings usually belong to your host or developer, while domain renewal belongs to the person who manages your registration account.
We request the address you enter over HTTPS and plain HTTP, following public redirects. We read the response headers and page HTML without running JavaScript. We never probe hidden files, admin paths, login pages or known exploits.
We also request the domain’s public record through rdap.org, which directs the lookup to the registry. When a PHP or WordPress version is visible, we request release information from php.net or WordPress.org. These are the only additional lookups.
A failed release lookup does not stop the report. PHP uses a stored support table, and WordPress reports the visible version without comparing releases. If domain expiry is unavailable, that check is omitted and a note explains the limit.
Ask your host or developer to make plain HTTP redirect to HTTPS. Confirm that HTTPS works across the site before enabling HSTS, since browsers remember that setting. Check subdomains before applying a policy that includes them.
Your developer can set response headers at the server or through Cloudflare. Build a Content Security Policy around the scripts, forms and embedded content your site actually uses. Review the policy before enforcing it, so it does not break working features.
Send your host the visible version and ask whether its branch receives security fixes. Ask about backported patches before assuming a missing release number means a missing fix. If an upgrade is needed, test your site on the supported branch before switching production.
Back up the site, then have your maintenance team update WordPress and check that key pages and forms still work. Remove unnecessary version disclosures afterward. Hiding a version alone does not fix outdated software, plugins or themes.
Update HTTP resource links in your content, theme or settings to working HTTPS addresses. Replace resources whose providers do not support HTTPS. Check the browser console afterward, since scripts can load more resources than the initial HTML reveals.
Check the expiry date in your registrar account and renew before the deadline. Turn on auto-renew, keep the payment method current and send renewal notices to an address someone monitors. Public records can lag behind changes, so your registrar should confirm the renewal.
Check your mobile Core Web Vitals and see what is slowing your site down.
Run the checkCheck the on-page SEO basics of any page, from the title tag to structured data, in one pass.
Run the checkCheck SPF, DKIM, DMARC and MX records for common email setup issues.
Run the check