www vs non-www, HTTPS and Trailing Slash: One URL

If one page opens from several addresses, your site may be quietly circulating four or five duplicate URLs. The www vs non-www choice, HTTP against HTTPS, a trailing slash or none: each can act as a separate entrance at server level. This article shows how to pick one version, tie it together with a single-step server 301 and prove that it works.

One Page, Four URL Variants

An address looks single, but on most sites the same content is reachable along several axes:

• Protocol: the http:// and https:// versions.
• Subdomain: the www and non-www versions.
• Path ending: with and without a trailing slash.
• Letter case and file names: uppercase against lowercase, and extra paths such as "index.php".

The axes multiply: protocol and subdomain alone give four home page addresses, and adding the path ending makes eight distinct URLs. If all of them show the same page, a visitor will not notice. Crawlers, analytics reports and sites that link to you may count each one as a separate address.

This article stays at domain level and path ending. Tag conflicts are covered in the canonical tag audit, and chains and loops in the redirect chains guide. The question here is narrower: which version becomes the single target, and how do we prove it?

Which Version Google Prefers: Consistency Matters

Google's documentation on consolidating duplicate URLs (Opens in a new tab) says that if you do not state a preferred version, Google decides which version is the most suitable to show users. It also reminds us that a canonical preference is a hint, not a rule. The clearer and less contradictory your choice, the more predictable the outcome.

The document declares no winner between www and non-www and promises no ranking edge on this question. So no absolute verdict such as "www is better" or "non-www is better" can be given. What it does recommend is clear: choose one address, and send the other variants to it with permanent redirects, which it describes as a strong signal for the target that should be canonical.

For HTTP and HTTPS the document is more specific: Google generally prefers HTTPS as the canonical. Redirecting HTTP to HTTPS, a canonical link from the HTTP page to HTTPS, or HSTS can reinforce that preference. An invalid certificate and redirects from HTTPS to HTTP push the preference toward HTTP, and HSTS alone will not repair that.

In short, the rest of this article rests on one principle: choose the preference once, then make every signal (redirect, canonical, sitemap, internal link) point the same way.

www vs non-www: What to Weigh

Since the documentation grants no advantage, the decision rests on your own conditions. These questions help:

• Current state: Which version is already dominant? Which one do most inbound links, email signatures and printed materials use? Matching the existing weight means the fewest redirects.
• Infrastructure: Pointing the bare domain at a CDN or DNS provider can need extra configuration in some setups. Check the limits with your hosting and DNS team.
• Subdomains: How cookies and sessions are shared with subdomains can affect the www choice; confirm this with the application team.
• Brand use: How is the address written in ads and on business cards? Keep the visible form consistent with the real address.

Once you choose, Search Console needs a small adjustment too. A domain property groups protocol and subdomain versions in one property, which makes the switch easier to monitor. If you use URL-prefix properties instead, verify every version separately, as Google's site move documentation (Opens in a new tab) advises. The same document says that switching between www and non-www within one domain does not require the Change of Address tool. If your plan goes further, for example onto a new domain, the steps in preserving backlink value during site migration also apply.

Example scenario: imagine a small publisher site that finds most inbound links pointing to the non-www address. The decision is easy: make non-www the target and redirect www to it. The opposite choice would also have been possible; what matters is that the choice is written down and then never changes.

HTTPS Migration and Mixed Content Checks

HTTPS migration begins before the redirect: make sure a valid certificate works for both the preferred version and the versions being redirected. web.dev's guide to enabling HTTPS (Opens in a new tab) advises redirecting HTTP to HTTPS only after HTTPS works, and using a 301 to tell search engines and browsers that the HTTPS version is canonical.

The most skipped part of the move is mixed content. If an HTTPS page loads HTTP resources, the browser may warn or block them. The checklist is short:

1. Are images, stylesheets and scripts loaded over HTTPS?
2. Do internal links use relative paths or the preferred HTTPS address?
3. Do embedded items (video, maps, forms) support HTTPS?
4. Do the sitemap and canonical tags show the HTTPS address?
5. Do content security policy or redirect rules still depend on the old HTTP address?

This checklist is not a one-time job. A newly added third-party script, a theme update or an editor pasting an old image can bring mixed content back. The browser's developer console shows mixed content warnings, and one look per page template catches most problems.

Trailing Slash Rules: Folders, Files and the Root

A trailing slash behaves differently at the root and at the end of a path. At the root, "https://example.com" and "https://example.com/" are the same request, because browsers always send the path as "/", so there is nothing to be inconsistent about. At the end of a path it changes: "/services" and "/services/" can technically count as two separate addresses, and if the server answers both with the same page, a duplicate exists. This comes from how HTTP works in general; official documentation does not set out a preferred form here.

The convention is that folder-like pages (a subsection of content) end with a slash and file-like addresses (such as "page.html") do not. In practice your system's default weighs heavily: if the links it generates already use one form, choosing the opposite means a redirect on every link.

The rule works like this: choose one form, redirect the other to it with a 301, and use only the chosen form in internal links. Internal link consistency matters more than leaning on the redirect, since running a redirect on every click is an extra request for nothing.

Uppercase, Lowercase and index.php Variants

Google's URL structure documentation says URL paths are treated as case sensitive, and that if your server handles different cases as the same page, you should convert everything to one case. The domain part is unaffected by case, but in the path "/Services" and "/services" can be counted as separate. The remedy is to choose one form (most often lowercase) and 301 the uppercase request to it.

File name variants follow the same logic. If the home page also opens from "/index.php" or "/index.html", those should redirect to the root ("/"). Old home page paths such as "/home" should likewise reach the single target. One caution: write the redirect at server level, not inside the application, because an application-level rule may not fire for every request.

Two checks close this section:

• Does an uppercase request for a main path return a 301?
• Do "/index.php" and similar file names go to the root?
• Do broken entries such as a double slash ("//") or a trailing dot return the clean address?

Slug writing and folder layout are outside this article's scope; here we only cover the domain and path-ending standard. For parameter duplicates, filter URLs and faceted navigation applies.

A Single-Step 301 Rule at Server Level

Writing three separate rules (HTTP to HTTPS first, then non-www to www, then adding the slash) produces a redirect chain: the visitor reaches the target in two or three hops. The right design is to move in one jump to the final address whichever variant arrives.

The logic goes like this: define the final address (for example https, non-www, no trailing slash). If a request is not exactly in that form, send it with one 301 to that address. The rule is written as a single set of conditions, not as separate rules that run one after another. A generic Apache pattern could look like this:

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

The principle is the same on nginx: a separate server block listening for the non-preferred addresses sends every request, with its path, to the target through "return 301". Note that port 443 also needs a valid certificate for the non-preferred version, or the browser shows a certificate error before it ever sees the redirect. Try the rule in a test environment before going live.

The 301 and 308 codes signal a permanent move, while temporary codes such as 302 and 307 do not make the target canonical, so use a permanent code here.

When and How to Add HSTS

HSTS is a response header that tells the browser to open the site only over HTTPS; once a browser has stored it, even a typed HTTP address returns to HTTPS without going out on the network. Google's documentation also lists HSTS among the methods that reinforce the HTTPS preference.

The web.dev guide gives two warnings: do not enable HSTS until you are sure your site operation is robust, and start with a low max-age, raising it gradually as you gain confidence. The reason is simple: a browser that has stored HSTS cannot reach the site over HTTP either when your certificate breaks.

A safe order could be:

1. Finish the HTTPS and mixed content checks, and automate certificate renewal.
2. Add the header with a small max-age (a few minutes, for instance) and monitor.
3. If nothing breaks, raise the value over days, weeks and months.
4. Once settled, move toward the one-year value (31536000 seconds) commonly shown in examples.

The includeSubDomains directive extends protection to all subdomains; even a single subdomain without HTTPS support can break, so list your subdomains first.

Aligning Signals: Canonical, Sitemap, Internal Links and Search Console

A redirect alone does not finish the job, because crawlers learn addresses from other routes too. Google's documentation lists redirects, the canonical tag and the sitemap together among canonical signals, describing the canonical tag as a strong signal and the sitemap as a weaker one. If one signal points at a different version, Google's choice can differ from your preference.

The alignment list:

• Canonical: Each page shows its own final address as an absolute URL with the preferred protocol and subdomain.
• Sitemap: Only final addresses belong there; no redirected or HTTP entries. The checking steps are in the sitemap audit article.
• Internal links: Menu, content and footer links use the final address.
• Hreflang and language links: If present, they should be written with the same protocol and subdomain.
• Search Console: Make sure the preferred version is being monitored in its new form.

Requests to redirected addresses also add crawl load; see the crawl budget guide for large sites. On small sites the real gain is being able to read reports through a single address.

Testing and Monitoring the Redirects

Test in a few concrete steps. First, check the response code and target for every variant: http with www, http without, https with www, https without, and the path with and without a slash. The expected result is a single 301 for every variant other than the final address, and a 200 for the final address.

The second step is a chain check: see how many hops a request needs. If it takes more than one, merge the rules. The third step is a Search Console check: inspect sample pages with the URL Inspection tool and compare the canonical you declared with the one Google selected.

A light routine is enough for monitoring:

1. At the start of each month, test all variants by hand on a sample page.
2. Repeat the test when the CMS, theme or CDN changes.
3. Crawl to see whether non-final addresses appear in the sitemap or internal links.
4. Put the certificate expiry date in a calendar; with HSTS on, it is a critical date.

On how long to keep redirects, Google's site move documentation recommends keeping them as long as possible, generally at least a year.

Sample Template: URL Variant, Target and Check Table

A sample table for documenting a site's version standard follows. The values are example values and example.com is a placeholder domain; fill it in with your own domain and decision. In the example, the target version is https, non-www and no trailing slash.

As an example scenario, picture a small online shop: the team fills in the table for three main page types and runs the six-row test before and after the redirect change. On the first run it sees the https www address reach the target in two hops and merges the rules; on the second run it gets one hop.

Frequently Asked Questions

Does www vs non-www matter for SEO?

Official documentation does not declare either version superior; what matters is choosing one and using it consistently. Redirect the unchosen version with a 301 and make the canonical, sitemap and internal links point to the same one. No ranking advantage is promised either way.

How do I redirect non-www to www?

Write a single permanent 301 rule at server level so every non-www request goes to the www version with the same path and parameters. Combine the HTTP-to-HTTPS step in the same rule to avoid a chain. Then update canonical tags, sitemap and internal links to the www address and test every variant.

How do I redirect HTTP to HTTPS?

First finish the valid certificate and mixed content checks, then redirect every HTTP request in a single 301 step to the preferred HTTPS address. Canonical tags, sitemap and internal links should also show the HTTPS address. Try the rule in a test environment and confirm that no chain appears.

Should URLs end with a trailing slash?

At the root there is no difference; at the end of a path, versions with and without a slash can technically count as separate URLs. Choose one, redirect the other with a 301 and use only the chosen form in internal links. Which form you pick matters less than applying it consistently.

What is HSTS and is it safe to enable?

HSTS is a response header that forces browsers to open the site only over HTTPS. Because a certificate problem can block access entirely, make sure HTTPS is solid first, start with a small max-age and raise it gradually while you monitor the site.

How can I see which URL version Google indexed?

Inspect the address with the URL Inspection tool in Search Console and check the page indexing report. There you can compare the canonical you declared with the one Google selected. If they differ, look for a conflicting signal in the redirect, canonical tag, sitemap or internal links.

Conclusion and Next Step

The single-version decision looks small, but it sets the common ground for reports, links and crawling. It takes choosing the target version in writing, setting up a single-step 301 rule on the server, aligning canonical, sitemap and internal links to the same version, and running the test from the table. HSTS is added only once HTTPS works well, and with a small value.

When you plan to commission content for pages built to this standard, the ordering page for written content covers the route: a product is chosen, cart and payment are completed, the seller approves, delivery is reported and an objection process applies if something goes wrong. Still, fill in the table for your own domain first; if the target address is unclear, ordered content can end up linked to the wrong variant.