Duplicate website addresses

Silktide checks that your website is served from a single web address. A common mistake is for the same site to be available at several addresses, such as with and without "www", or over both secure and insecure connections, without redirecting to one preferred version.

For example, all four of these can serve the same site:

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

A website should have a single canonical address, with the other variations redirecting to it. When they do not, each variation acts as a separate copy of your site.

Why this matters

Serving identical content from several addresses splits your site's reputation and causes practical problems:

People link to whichever version they landed on, diluting the search value of your backlinks across the copies.
Shares on social media split the same way, spreading likes and share counts across duplicate URLs.
Search engines must guess which version is authoritative and may index the one you did not intend.
Cookies set on one version may not be readable on another, which can break logins and shopping carts when visitors cross between them.
Versions served without leave visitors on an insecure connection.

How to fix it

Choose one canonical address - typically the https:\/\/ version, with or without "www" as you prefer.
Configure your web server or to permanently redirect (HTTP status 301) every other variation to it. Your hosting provider's control panel often has a setting for this; otherwise it is a small server configuration change, for example:

# Apache: redirect everything to https:\/\/www.example.com
RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^ https:\/\/www.example.com%{REQUEST_URI} [L,R=301]

Update internal links and your sitemap to use the canonical address so visitors and crawlers are not bounced through redirects.

How Silktide tests this

Build 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.
Request each variation directly, following any redirects, and record the final address it lands on. Auto-generated query strings and fragments are ignored so they do not look like different destinations.
If every responding variation ends at the same address, the check passes.
Otherwise, retest each responding variation in a real web browser (some sites redirect using , which only a browser can follow) and report each variation with the address it leads to, for both kinds of request.

Troubleshooting

My site redirects, but the check still fails

Check that every variation redirects. A frequent gap is redirecting http:\/\/example.com but not http:\/\/www.example.com, or redirecting to different destinations (one variation to the homepage, another to a language picker).

The redirect works in my browser

Redirects done with JavaScript work in browsers but are slower, less reliable for crawlers, and treated less favourably by search engines than server-side redirects. Silktide shows both what a direct request and a browser saw so you can spot this: use a server-side 301 redirect instead.