HTTP to HTTPS and www redirects: consolidating to one address.

Redirecting from HTTP to HTTPS and between the www and non-www address is done to consolidate four different address forms of the same site into a single primary address: the http and https, www and non-www forms are sent to one address with a permanent 301 redirect, and every page declares that address as canonical. This is not a domain change; Google’s Change of Address tool is not used for it.

A domain looks like a single site, but to a search engine it carries four starting points: http://example.com, http://www.example.com, https://example.com and https://www.example.com. If all four serve the same content with a 200 code, Google sees four copies of the same page and decides on its own which one to show. The links other sites give you are spread across these four forms, and the crawling effort is split four ways. Tidying this up is one of the first steps of every site redesign and stands as a separate line within the scope of website redesign and migration.

What should be done when moving to HTTPS?

Moving to HTTPS is a change of the address scheme: the prefix http:// becomes https:// in every page’s address. Google’s site move documentation also treats a protocol change as a move with URL changes; so the principle is the same: every old address should go to its new form in a single step with a permanent redirect.

• First install a valid certificate and see that the site opens via https on every page.
• Leave no images, scripts or fonts loaded via http inside the pages; the browser may block them or show a warning.
• Regenerate internal links, canonical tags, hreflang links and the sitemap with https addresses.
• Send every request arriving via http to the https counterpart of the same path with a 301.
• If you have no https property in Search Console, add one; a domain-level property covers both schemes together.
• Do NOT use the Change of Address tool: the Search Console help page lists the move from http to https as outside the scope of this tool.

Should it be www or non-www?

In terms of search, neither has an advantage over the other; what matters is choosing one and permanently redirecting the other to it. The choice is often decided by technical details: some hosting and content delivery services offer less flexibility on the root domain, which is why the www address is often preferred. Whichever you choose, canonical tags, the sitemap, internal links and the redirect should all point to the same address. If the redirect and the canonical tag point to different addresses, the search engine chooses on its own which one to believe.

A www change does not count as a domain change either. The Search Console help page says that for moving between www and non-www forms, a redirect and the canonical address should be used, not the Change of Address tool. If you really are moving to another domain, that is a separate job: domain change guide.

How do you write the HTTPS and www redirect on Apache?

The .htaccess lines below send every request that arrives via http or without www to the https www address in a single step. If either of the two conditions is true, the rule fires and the path is preserved exactly. The domain is an example.

1. RewriteEngine On
2. RewriteCond %{HTTPS} off [OR]
3. RewriteCond %{HTTP_HOST} !^www\. [NC]
4. RewriteRule ^(.*)$ https://www.example.com/$1 [R=301,L]

A warning: if your site sits behind a content delivery network or a reverse proxy, your server may see the request as http even when it arrived via https. In that case this rule creates a loop and the page never opens. Before writing the rule, find out how the layer in between forwards the request to your server.

How do you write the HTTPS and www redirect on Nginx?

On Nginx each form is caught in a separate server block: everything arriving on port 80 and non-www requests arriving on 443 are sent to the primary address in a single step. The primary address’s own server block carries the site’s normal configuration.

1. server {
2. listen 80;
3. server_name example.com www.example.com;
4. return 301 https://www.example.com$request_uri;
5. }
6. server {
7. listen 443 ssl;
8. server_name example.com;
9. return 301 https://www.example.com$request_uri;
10. }

What is HSTS, and should it be enabled after moving to HTTPS?

HSTS is a response header in which the server tells the browser “from now on, open this site only via https.” A browser that has seen the header once will not send http requests to that domain for the specified period; it converts the address to https itself. This removes the first redirect hop from http to https for returning visitors. The price is that going back becomes harder: if a long period was chosen and a problem occurs on https, those browsers refuse to open the site via http. A setting that also covers subdomains locks in a subdomain that is not ready for https as well. That is why HSTS is enabled only after https has been seen to work flawlessly on all pages and all subdomains, and at first with a short period.

Should trailing-slash and index.html forms be consolidated too?

Yes. If the same page can be opened at /hizmetler, /hizmetler/ and /hizmetler/index.html, that is a smaller version of the same problem. Choose one as the primary form, redirect the others to it, and have the page’s canonical tag point to the primary form. Upper- and lowercase differences and tracking parameters belong to the same family; the canonical address exists precisely for these cases.

How many addresses were consolidated into one page on this site?

On 22 August 2026 Search Console knew 93 addresses for this site; the site had 58 pages. The 35 addresses in between were not separate pages: they were the non-www, http, no-trailing-slash and /index.html versions of the same pages. When we tested on the live site, all of them went to a single address with a 301 or 307. The day before, the situation was different: on 21 August the non-www address served the content directly with a 200 instead of a redirect, meaning the same site was live at two separate addresses. A 301 was written on the server that sends every non-www request to the www address with its path unchanged.

On 23 September 2026 we measured the chain again, hop by hop. A request arriving via http and without www arrives in two hops: first from http to https, then from the non-www address to the www address. The first hop is not made by our server code but by the hosting layer in front of it. When an old page address is also involved, the longest path is three hops. The no-trailing-slash and /index.html forms are consolidated by the hosting platform with a 307. All of this is within the limit Google recommends — the site move documentation recommends keeping chains to at most three hops — but it is not a single hop. On our own site we know and measure this difference; in a client map, the goal is for every old address to arrive in a single hop. Why chains are kept short is explained in the redirect chain entry.

We also looked at the same question from a wider sample. This site’s open dataset, the Measurement Observatory, went to the root address of 160 sites from Türkiye and the EU via https and followed the chain to the end. In the 31 August 2026 measurement, of the 131 live sites, 34 answered directly, 84 reached the final address in one redirect hop and 13 in two. 83 of the same 131 sites sent the HSTS header, which tells the browser to open the site only via https. The names of the sites are not published; only the totals.

The number of addresses Google knows is always higher than your site’s page count.

What do you see in Search Console after the redirects?

The consolidated forms appear in Search Console’s page indexing report as “Page with redirect.” This is not an error: the report states that non-canonical addresses that redirect to another address are not indexed and that this is the expected state. On 22 August this site had 4 addresses in that row. The row that really needs attention is “Redirect error”: overly long chains, loops or empty targets show up there. What to monitor in the weeks after launch is covered in the post-migration monitoring guide.

If you don’t want to lose traffic while relaunching your site, website redesign and migration inventories the old addresses, builds a chain-free 301 map and monitors the site for 90 days after the move.