Closing the obvious gaps.

The site isn't served over HTTPS

What it means. HTTPS encrypts everything between a visitor's browser and your server, and uses a certificate (often still called an SSL certificate) to prove the site is really yours. Your page loads from an http:// address, so it has neither.

Why it matters. Browsers label http pages "Not secure", which is the last thing you want beside a contact form or a price. Anything typed into the page travels unencrypted, so someone on the same public Wi-Fi could read or change it. Google has said it prefers secure pages, although HTTPS alone won't lift you up the results.

How to fix it. Most hosts include a free certificate; turn it on in your hosting control panel, or ask your host to. Then:

• Once the certificate works, change the site's own address to https://. In WordPress, that's the WordPress Address and Site Address in the General settings. Changing them before https works can make the site unreachable.
• Wix, Squarespace and Shopify provide HTTPS for connected domains. If yours still loads on http, check the platform's domain or SSL settings.
• Redirect http:// to https://, and fix any files or forms still using http://.

How the check spots it: the check follows any redirects from the address you entered. If the page finally loads from an http:// address, it lists this under Fix first.

The http:// address doesn't switch to https://

What it means. Your site works on https, but the http:// version of the same address still shows a page, or an error, instead of redirecting (automatically sending visitors on) to the secure one.

Why it matters. People type addresses without the https, and old links, business cards and directory listings often use http://. Without a redirect, those visitors land on an insecure copy marked "Not secure", or on an error. Google can also end up with two copies of each page.

How to fix it. Add a permanent redirect (a 301 or 308) from every http:// address to the same page on https://, so http://example.com.au/contact/ goes to https://example.com.au/contact/.

• Many hosts have a "force HTTPS" switch in the control panel. A server setting covers every file, not just the pages your platform makes.
• On Cloudflare, the "Always Use HTTPS" setting covers the whole domain.
• Wix, Squarespace and Shopify normally redirect for you once HTTPS is on. If not, ask their support.
• Once it works everywhere, consider HSTS.

How the check spots it: when you enter an https:// address, the check also requests its http:// version, following up to four redirects. It passes if that ends on https://, or if the server doesn't answer on http at all. Ending on an http:// page is listed under Fix first, and ending on an error under Worth fixing. If the server turns the check away as a bot, there's no verdict.

Files on a secure page load over insecure http://

What it means. Your page is on https, but some of the files it pulls in (scripts, stylesheets, embedded frames or images) have http:// addresses. This is called mixed content.

Why it matters. Browsers block scripts, stylesheets and frames loaded over http on a secure page, so menus, sliders, forms or the whole design can quietly break. For images, browsers try the https address instead; if the image's server doesn't offer https, the image doesn't appear.

How to fix it. Change each address in your report to https://, or to a path on your own site such as /images/logo.png, and check the file still loads. MDN's guide to mixed content explains what browsers block.

• On WordPress, old http:// addresses often stay stored in pages, widgets and theme settings after a switch to https. A search-and-replace tool made for WordPress can update them; take a backup first.
• Old embed codes for maps, videos and booking widgets are a common source. Get fresh code from the service.
• Cloudflare's "Automatic HTTPS Rewrites" setting fixes addresses it knows work on https. A Content-Security-Policy with upgrade-insecure-requests is another safety net, but this check will still list the addresses as written.

How the check spots it: on an https page, the check reads the HTML for scripts, stylesheets and frames with http:// addresses, listed under Fix first. If there are none, it lists images with them (including in srcset) under Nice to have. Files that scripts or stylesheets load aren't seen, but Google's test in the report may catch them.

A form sends what people type over insecure http://

What it means. The page is secure, but a form on it (a contact, quote, newsletter or search form) sends its answers to an http:// address, set in the form's action.

Why it matters. What people type travels unencrypted, where it could be read or changed on the way. Chrome warns people that the form isn't secure before it sends, and many stop there. That's an enquiry you never receive.

How to fix it. Change the action to https://, or to a path on your own site such as /contact/. The usual causes:

• Old embed code from a newsletter, booking or form service. Get fresh code from the service.
• A theme, plugin or page-builder setting holding your old http:// address. Update it, and check your platform's own site address uses https.
• A service with no https at all. It's time to replace it.

How the check spots it: on an https page, the check reads every <form> in the HTML and lists any whose action starts with http:// under Fix first. A form with no action, or with a path, sends to your own secure address. Forms that scripts add after the page loads aren't seen.

A login form puts the password in the web address

What it means. Forms send what people type in one of two ways. GET adds it to the next page's address, like ?user=sam&password=…; POST sends it out of sight. A form with a password box on this page uses GET, which is also what browsers do when a form doesn't say.

Why it matters. Web addresses are recorded all over the place: browser history, server logs, analytics tools. Anyone who later sees those records sees the password too. HTTPS doesn't help, because the address is stored after it arrives.

How to fix it. Set method="post" on the form's <form> tag. WordPress's own login page already uses POST, so the culprit is usually a custom form, or one from a theme, plugin or page builder; update it or ask its maker. Some forms are sent by a script and never use the method, but the browser falls back to it if the script fails, so set it anyway. If people have logged in through this form, consider asking them to change their passwords.

How the check spots it: the check finds the forms in the page's HTML that have a password field, and lists any whose method isn't POST under Fix first. A form with no method counts as GET.

The page redirects to an address that isn't a public website

What it means. When the check opened your page, the server redirected it to an address that isn't an ordinary public web address: a bare IP address (the numbers behind a domain name), one with a port number such as :8080 or a login built in, or a name that only works inside a private network.

Why it matters. Visitors who follow it usually get an error or a certificate warning instead of your site, and Google can't follow it either. It's most often a leftover: the server's own address, or a test copy's, in a redirect rule or a site setting.

How to fix it. Find where the redirect comes from and point it at your real https:// address. If it's intentional, this doesn't apply.

• On WordPress, check the WordPress Address and Site Address in the General settings. After a move to a new host they sometimes still name the old server's IP address or a test address.
• Check the redirect rules in your hosting control panel, server settings or Cloudflare.
• If the site sits behind a proxy or load balancer, it may be handing out its own internal address. Ask whoever set it up.

How the check spots it: the check follows each redirect itself and only visits ordinary public web addresses. When a redirect leads anywhere else, it stops there and lists this under Fix first.

The server runs a PHP version that no longer gets security fixes

What it means. PHP is the programming language WordPress and many other sites run on, installed on your hosting server. Each version gets security fixes for a set time, then stops. Your server says it's running a version past that date.

Why it matters. New holes found in an unsupported version don't get fixed, and automated attacks scan for old software. Plugins and themes also drop support for old PHP over time, so the move gets harder the longer you wait.

How to fix it. Most hosts let you choose the PHP version in the control panel, or will change it if you ask. Before you switch:

• Take a full backup.
• Update WordPress (or your platform), the theme and every plugin. Out-of-date add-ons are the usual reason a site breaks on a newer PHP.
• Try the new version on a staging copy if your host offers one, then switch the live site and test the main pages and forms.

How the check spots it: the check reads the PHP version from the X-Powered-By or Server header (a note the server sends with every page, such as PHP/8.1) and compares it with php.net's list of supported versions. In October 2026, when this was written, 8.1 and older were past their end date and 8.2 reaches it at the end of 2026. It's listed under Worth fixing. A server that doesn't announce its version can't be checked, so no finding doesn't mean your PHP is current.

The site uses an old version of jQuery with known security holes

What it means. jQuery is a widely used script library: ready-made code that many themes, plugins and sliders rely on. Your page loads a version older than 3.5, and those have published flaws (CVE-2020-11022 and CVE-2020-11023) that in some situations let an attacker run their own script on your page, known as cross-site scripting.

Why it matters. Whether the flaws can be used on your site depends on how its code uses jQuery, so an old version doesn't mean you're exposed. But published flaws are what automated tools look for, and updating is usually quicker than finding out.

How to fix it. Find what loads it, update that, then test the menus, sliders, forms and pop-ups.

• Current WordPress includes an up-to-date jQuery, so an old one usually means WordPress is out of date, or a theme or plugin loads its own copy. Update all three, and replace any that still bring in an old copy.
• On a hand-built site, move to a current version. jQuery's 3.5 upgrade guide lists what changed.

How the check spots it: the check reads the version from each script's address: the file name (jquery-1.12.4.min.js), a script host's folder (/jquery/1.12.4/ or jquery@1.12.4/), or the ?ver= on WordPress's own copy. Anything before 3.5 is listed under Worth fixing. Add-ons such as jQuery Migrate and jQuery UI don't count here (see out-of-date libraries), and an address with no version gets no verdict.

The site uses an out-of-date script library

What it means. Script libraries are ready-made code that themes, plugins and developers build on. Your page loads a file the check takes to be an out-of-date version: jQuery UI before 1.13; Bootstrap before 4 (versions 2 and 3 are unmaintained, and those before 3.4.1 have published holes); AngularJS 1, which reached the end of its life in January 2022; Lodash before 4.17.21; or Prototype.js, MooTools or script.aculo.us, none updated in years.

Why it matters. Known holes come with public write-ups, and unmaintained code won't be fixed when new ones are found. As with old jQuery, it doesn't mean the site is exposed; that depends on how the library is used.

How to fix it. The address in your report often names the theme or plugin that brings the library in. Update it, or plan to replace it if it's been abandoned. If a developer added the library, they can update it and test the site. Moving on from Bootstrap 3 or AngularJS changes how the code is written, so it's often part of a redesign rather than a quick update.

How the check spots it: the check looks at each script's address for the library's file name and a version number (in the file name, the folder, after an @, or, for WordPress's own copies in /wp-includes/, in ?ver=). Elsewhere a ?ver= number is usually the theme's or plugin's version, so it's ignored. Where only old versions are a problem, no version means no finding. Prototype.js, MooTools and script.aculo.us are reported whatever the version. It's listed under Worth fixing, or under Nice to have when only those three are found.

Comments in the page's code mention a password or read like internal notes

What it means. HTML comments are notes in a page's code between <!-- and -->. Browsers don't show them, but anyone can read them with "view source". Some on this page mention a password, secret or key, or look like notes for developers: to-dos, debug notes, server folder paths, or local and staging addresses.

Why it matters. They tell outsiders things they don't need to know, such as your software and folders, or where a test copy lives. A real password or key in a comment is a serious leak, because web archives and other services keep copies of pages.

How to fix it. Look at the examples in your report.

• If one holds a real password, key or token, change it first, then remove the comment. Copies of the page may already exist.
• Remove developer notes from the templates; they belong in the project's code or notes.
• Many come from themes, plugins or page builders. A caching or optimisation setting that minifies HTML usually strips comments out.

How the check spots it: the check reads the first 200 comments in the page's HTML, outside scripts and styles. Mentions of a password, secret, API or access key, private key, auth token or bearer token are listed under Worth fixing. Otherwise, notes containing TODO, FIXME, XXX, hack, bug or debug, server paths, localhost, staging, .local or dev. addresses, or "username" are listed under Nice to have. It matches words, so it's marked as a potential issue: "password reset form" counts too.

Browsers aren't told to always use https (no HSTS)

What it means. HSTS (HTTP Strict Transport Security) is a header, a short instruction your server sends with each page, telling browsers to use only https for your site for a set time. Your site doesn't send it, or sets a short time.

Why it matters. Even with a redirect to https, the first request can go out over plain http when someone types your address or taps an old link. On public Wi-Fi, that moment is when a connection can be tampered with. Once a browser has seen HSTS, it skips http for as long as you set.

How to fix it. Turn it on only when https works on every page, because browsers will refuse http for the whole period. A typical header is Strict-Transport-Security: max-age=31536000, one year in seconds. MDN's guide to the header covers the options.

• Many hosts and Cloudflare have an HSTS setting; on WordPress, a security plugin can also add it.
• On Wix, Squarespace and Shopify the platform controls it, so if there's no option, it isn't yours to change.
• includeSubDomains covers every subdomain too, so add it only if all of them work on https. Leave preload off unless you've read its requirements; it's slow to undo.

How the check spots it: on an https page, the check reads the Strict-Transport-Security header. No header, or a max-age under 15,552,000 seconds (180 days, about six months), is listed under Nice to have.

Security headers are missing

What it means. Headers are short instructions your server sends with each page; visitors never see them. The check looks for three that switch on protections in the browser. Content-Security-Policy lists where scripts may come from, so an injected script is less likely to run (see a weak policy). X-Frame-Options, or frame-ancestors in the policy, stops other sites showing your page inside theirs to trick people into clicking things (clickjacking). X-Content-Type-Options: nosniff stops browsers guessing a file's type and running it as a script.

Why it matters. They're defences for when something else has gone wrong, which is exactly when you want them, and they cost almost nothing to send.

How to fix it. Common values are X-Content-Type-Options: nosniff and X-Frame-Options: SAMEORIGIN.

• Many hosts, and Cloudflare, can add response headers without touching the site. On WordPress, the host's settings or a security plugin are the usual place.
• A Content-Security-Policy needs care: too strict, and it blocks your own analytics, chat or embeds. Test with Content-Security-Policy-Report-Only, which only reports; this check still lists the policy as missing meanwhile.
• On Wix, Squarespace and Shopify you generally can't set your own headers, so this may not be yours to fix.

How the check spots it: the check reads the page's response headers and lists any of the three that are missing in one finding, under Nice to have. A policy set in a <meta> tag isn't counted.

The Content-Security-Policy doesn't stop injected scripts

What it means. Your site sends a Content-Security-Policy, a header listing where the browser may load scripts from. Its main job is stopping scripts an attacker injects into a page (cross-site scripting), but yours leaves a gap: it doesn't cover scripts, it allows 'unsafe-inline' (any script written into the page), or it allows scripts from any website or from data: addresses.

Why it matters. With that gap, the policy can't do its main job, though it may still do others, such as stopping framing. Many policies start loose so nothing breaks, and never get tightened.

How to fix it. Tightening it is a developer's job, since every script the site uses must be allowed and nothing else. web.dev explains the "strict" approach.

• Replace broad sources such as https: or * with the places your scripts actually come from.
• Instead of 'unsafe-inline', allow inline scripts by hash (a fingerprint of the exact script) or nonce (a random code the server adds to the header and its own script tags on each page load). Browsers then ignore 'unsafe-inline'.
• Test with Content-Security-Policy-Report-Only before switching over.

How the check spots it: the check reads the policy's script-src, or default-src if there's none. It flags neither being there, 'unsafe-inline' without a nonce or hash, or a source of *, http:, https: or data: (unless 'strict-dynamic' comes with a nonce or hash). If several policies are sent, one strict one is enough. It's listed under Nice to have.

Cookies are set without basic protection

What it means. Cookies are small pieces of information your site asks the browser to keep, such as a login or a cart. Flags protect them: Secure means a cookie is only sent over https, and HttpOnly means scripts on the page can't read it. Some cookies on this page lack one.

Why it matters. Without Secure, a cookie can travel over a plain http connection, say through an old http:// link, where it could be read on a shared network. Without HttpOnly, a login cookie can be read by any script on the page, so a malicious one (see injected scripts) could copy it and take over the session.

How to fix it. Whatever creates the cookie sets the flags, and the cookie's name in your report usually shows what that is. For PHP's own session cookie (often named PHPSESSID), your host can turn both flags on in the PHP settings. For a plugin's or app's cookie, update it or ask its maker. Platforms, hosts and security plugins often have a setting that adds the flags.

How the check spots it: the check reads the cookies the server sets with the page (the Set-Cookie header), not ones scripts set later. On an https page, any cookie without Secure is listed. A cookie whose name suggests a login or session (containing sess, auth, login, token or sid, for example) is also listed if it lacks HttpOnly, unless it's named as CSRF protection, a security code scripts must read. It's listed under Nice to have.

The server announces its software versions

What it means. With each page, your server sends headers (notes visitors don't see) naming the software it runs. Yours include version numbers, in the style of Server: Apache/2.4 or X-Powered-By: PHP/8.2.

Why it matters. The numbers don't weaken the site by themselves, but they save automated attacks a step: bots scan for versions with known holes. Hiding them helps a little; keeping the software updated is what counts.

How to fix it. Ask your host to stop sending version numbers. For whoever manages the server, Apache's ServerTokens, nginx's server_tokens and PHP's expose_php settings control them. If the version named is an old PHP, deal with the PHP version first.

How the check spots it: the check reads the Server and X-Powered-By headers. A Server header with a slash followed by a number, or any number in X-Powered-By, is listed under Nice to have.

The page shows which WordPress version it runs

What it means. WordPress adds a "generator" tag to each page's code, <meta name="generator" content="WordPress …">, naming its exact version. Visitors don't see it, but anyone reading the code does.

Why it matters. Attack bots look for versions with known holes, and this tells them in one line. Hiding it helps a little, but the version can often be worked out other ways, such as from the addresses of WordPress's own files. Keeping WordPress, the theme and plugins updated is what really counts.

How to fix it. Many SEO, security and performance plugins can remove the tag, and some themes already do; a developer can remove it with one line in the theme. While you're there, check that WordPress's automatic minor (security) updates haven't been switched off. They're on by default.

How the check spots it: the check looks for a <meta name="generator"> tag naming WordPress and a version number, and lists it under Nice to have. Other platforms' generator tags aren't reported.