All 30 checks Site not served over HTTPS

Site not served over HTTPS

Updated

If the address a visitor ends up on after redirects starts with http:// instead of https://, everything on the page travels unencrypted, browsers label the site Not secure, and Skewcheck treats it as a launch blocker.

Fails: Request that ends on plain HTTP
$ curl -sIL http://example.com | grep -iE '^(HTTP|location)'
HTTP/1.1 200 OK
# no redirect: the final URL is http://example.com/
Fix: Redirect everything to HTTPS (nginx)
server {
  listen 80;
  server_name example.com www.example.com;
  return 301 https://example.com$request_uri;
}

What goes wrong without HTTPS

HTTPS encrypts the connection between the visitor and your server and proves the server really belongs to your domain. Without it, anyone on the same network path, such as a shared Wi-Fi hotspot, can read what the visitor submits and can alter the page on its way through. Contact forms, logins, and anything a visitor types are exposed, and so is every script the page loads.

Browsers make the problem visible. Chrome, Firefox and Safari mark a page served over plain HTTP as Not secure, and they show a warning before a visitor types into a password or payment field on one. Clients notice that label immediately, and visitors who see it tend to leave. Search engines have also treated HTTPS as a ranking signal for years, and several modern browser features only work on secure origins.

How Skewcheck detects it

Skewcheck requests the URL you enter and follows up to five redirects. It then looks only at the address it finally landed on. If that address starts with https://, the check passes, which means a correct http to https redirect passes too. If it starts with http://, the check fails with high severity and removes 12 points from the score.

This is one of five launch blockers. While a blocker stands, the overall score is capped at 49 however well everything else scores, so a site that is not on HTTPS never looks nearly ready. Skewcheck does not inspect the certificate itself: a valid-looking https:// address passes even if the certificate is close to expiry, and an address whose certificate is broken cannot be fetched at all, so the audit reports a connection problem instead of this check.

See where an http:// address ends up
curl -sIL -o /dev/null -w '%{url_effective}\n' http://example.com

Getting to HTTPS on common platforms

Most hosts issue a free certificate once your domain points at them. Vercel, Netlify, Cloudflare and Cloudflare Pages do it automatically for a connected domain. Webflow and Framer provision a certificate for custom domains you connect through their settings, so if a custom domain still loads over http://, look at the domain section of the site settings and confirm the domain finished connecting. On WordPress, install the certificate through your host, then set both the WordPress Address and the Site Address under Settings, General to the https:// version.

On your own server, obtain a certificate (Let's Encrypt is a free option many hosts support), serve the site on port 443, and add a permanent 301 redirect from port 80 so that every http:// path lands on the same path over https://. Redirect to the one hostname you want to keep, with or without www, so the result is a single hop. After that, add the Strict-Transport-Security header so browsers stop trying HTTP at all, and look for leftover http:// files on the page, which browsers block.

Before and after

Before
GET http://example.com/pricing
HTTP/1.1 200 OK
After
GET http://example.com/pricing
HTTP/1.1 301 Moved Permanently
location: https://example.com/pricing

Check your page

Run all 30 checks on any URL. Free, no account.