Website address variations

Silktide checks that the common variations of your website's address all work. Visitors may type your domain with or without "www", and their browser may try a secure or insecure connection, so all four combinations should load your site.

For a website at example.com, the four variations are:

http:\/\/example.com\/
https:\/\/example.com\/
http:\/\/www.example.com\/
https:\/\/www.example.com\/

A common mistake is to configure only one of these. Each variation should respond, ideally by redirecting to your one preferred (canonical) address - see Duplicate website addresses for why serving the same content at several addresses is its own problem.

Why this matters

Visitors do not know which convention you chose. Someone typing www.example.com when only example.com is configured sees a connection error, assumes your site is down, and leaves - and you get no error report, because the failure happens before your website is ever reached. Links in print, emails, and word of mouth spread every variation of your address, so all of them carry real traffic.

How to fix it

Make sure your domain's DNS has entries for both the bare domain and the "www" subdomain, pointing at your web server.
Make sure your certificate covers both names, so the secure variations connect without errors.
Configure your web server or to redirect every variation to your one canonical address with a permanent (301) redirect. Hosting providers often expose this as a "redirect www" or "force HTTPS" setting.

How Silktide tests this

Build the four variations of your website's domain: http:\/\/ and https:\/\/, each with and without the "www" prefix. Websites on a custom subdomain (such as blog.example.com) are not tested.
Attempt to download each variation, following any redirects.
Report each variation that fails to load - because the address does not resolve, the connection fails, or the response is an error.

Troubleshooting

A variation works in my browser but fails the check

Some browsers hide this problem by silently retrying other variations when one fails. Test the exact address with a tool that does not, or from a device outside your network. Also check that your HTTPS certificate covers both the bare and "www" names: a certificate mismatch fails this check even though a browser may only show a warning.

We deliberately don't serve one variation

Some organisations choose not to respond on http:\/\/, for example. If that is a deliberate policy, the finding - though redirecting to your canonical address is usually better than refusing the connection, because visitors typing that variation still reach you.