WHAT IS CHECKED
Four Entrances.
One Target.
The home page itself can be perfectly protected: if the way there runs over unencrypted HTTP, the protection is gone for some of the visitors. The check shows the whole way, step by step.
- 01
Four Variants
http:// and https://, each with and without www. Every chain is followed hop by hop and shown with its status code. Variants without a DNS record do not count.
- 02
Encrypted Target
If a variant ends on HTTP or a redirect falls back from HTTPS to HTTP, that is critical: visitors browse there without encryption.
- 03
No Intermediate Step over HTTP
The first jump from HTTP should go directly to HTTPS of the same host. A detour via a second HTTP address runs unencrypted and costs HSTS.
- 04
Loops and Detours
Redirects in circles end in the browser with an error message. More than two redirects to the target slow down page loading.
- 05
Permanent Instead of Temporary
A change of scheme or host needs 301 or 308. With 302 or 307, browsers and search engines keep the old address.
- 06
Certificate and HSTS per Host
Every HTTPS step needs a valid certificate and should send HSTS, including the one that only redirects. Otherwise the host without www remains unprotected.
HOW TO SET IT UP
Two Steps.
Both Permanent.
First to HTTPS of the same host, then to the preferred host. This way the browser sees every host once encrypted and can learn HSTS. Afterwards, check the certificate and headers with the SSL/TLS check and the security header check; our glossary explains what HTTP is.
nginx
A server block for port 80 redirects everything to HTTPS of the same host. The HTTPS block without www sets HSTS and redirects to the preferred host.
# Port 80: everything permanently to HTTPS of the same host server { listen 80; server_name example.com www.example.com; return 301 https://$host$request_uri; } # HTTPS without www: set HSTS, then redirect to the preferred host server { listen 443 ssl; server_name example.com; add_header Strict-Transport-Security "max-age=31536000" always; return 301 https://www.example.com$request_uri; }Apache
With mod_rewrite and mod_headers in the VirtualHosts. In .htaccess, the lines only take effect if AllowOverride permits it.
# VirtualHost on port 80 RewriteEngine On RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L] # VirtualHost on port 443 for example.com Header always set Strict-Transport-Security "max-age=31536000" RewriteEngine On RewriteCond %{HTTP_HOST} ^example\.com$ [NC] RewriteRule ^ https://www.example.com%{REQUEST_URI} [R=301,L]
QUESTIONS
Good to Know.
Why does the check test four addresses instead of one?
Visitors reach your website in different ways: by typing without https://, through old links with http:// or with and without www. Each of these four variants has its own chain of redirects. The check follows each one separately, shows the status code and target of every step and checks whether all of them arrive at the same target encrypted. If a variant has no DNS record, it does not count towards the grade.
Why should HTTP first redirect to HTTPS of the same host?
If http://example.com first redirects to http://www.example.com, this intermediate step also runs unencrypted and can be diverted on the way. In addition, the browser only learns HSTS from HTTPS responses (RFC 6797, Section 8.1): if it never reaches https://example.com, this host remains unprotected. RFC 6797 recommends a permanent redirect to HTTPS for requests over HTTP (Section 7.2). The clean way is therefore http://example.com → https://example.com → https://www.example.com.
301 or 302: which redirect is right?
For the change to HTTPS and to the preferred host, a permanent one: 301 or 308. According to RFC 9110, 302 and 307 mean that the address is only temporarily elsewhere; clients should keep using the old address (Sections 15.4.3 and 15.4.8). Google only treats permanent redirects as a signal that the target is the canonical address. Redirects only within the path, such as from / to /de/, may be temporary; the check does not rate them.
How many redirects are too many?
Every redirect costs a request before the page loads. Google Lighthouse rates a page with two or more redirects as having room for improvement. Two are useful if they handle HTTP → HTTPS and then the host; from three on, the check shows a detour. The check follows at most ten redirects per variant, as many as Google’s crawlers do by default. Browsers abort after 20 at the latest (WHATWG Fetch).
Does HSTS also protect the very first request?
No. A browser only knows HSTS after it has received the header once over HTTPS. The first request without https:// therefore remains vulnerable (RFC 6797, Section 14.6). The browsers’ preload list helps here (Section 12.3); but inclusion is hard to undo and requires HTTPS on all subdomains. For most websites, HSTS with a one-year lifetime on every HTTPS host, including the one that only redirects, is enough.
Does TOMORIS store my input or the result?
No, not permanently. Our server fetches the addresses of the redirect chain, each at most once, with GET and without loading the content of the pages; the website checked sees our server, not your IP address. The result stays in memory for five minutes so that repeated requests do not put load on the website again, and it is deleted after six minutes at the latest. Details are in the privacy statement.
TOOLBOX
More
Tools.
Website security check
Everything at a glance, with an overall grade
View (German)Security Header Check
Checks HTTPS, HSTS, Content-Security-Policy, clickjacking protection and other headers of your website. With a grade from A+ to F and ready-made configuration.
ViewSSL/TLS Check
Checks the certificate, chain and remaining validity, which TLS versions your server accepts and whether the encryption offers forward secrecy. With a grade and configuration.
View
YOUR NEXT STEP
You Have the Result.
What Comes Next?
We assess findings, prioritize by risk and put changes into practice on request: as a project with EXPERTS or as ongoing operations with GRID.