Every site hosted with Ultra Web Hosting answers to both www and non-www by default, which means search engines can see two versions of the same page. Picking one canonical hostname and forcing everything to it with a clean 301 redirect fixes duplicate content, consolidates your link equity, and keeps caching and cookies consistent. This guide shows the exact .htaccess rules for both directions, the combined host-plus-HTTPS block we recommend, and how to test that you land on a single redirect hop instead of a loop.
One Hostname, One 301, One Hop
Canonicalization is not complicated once you decide on a target. Choose www or non-www, put a single 301 redirect at the top of your .htaccess, and combine it with your HTTPS redirect so a visitor never bounces through two hops to get to the right URL.
- Pick www or non-www and stick with it site-wide
- Use a permanent 301, not a temporary 302, for canonical moves
- Combine host and HTTPS into one rule to avoid chained redirects
- Test with
curl -Iand confirm exactly one 301 hop
Never Chain Two Redirects
The most common mistake is redirecting non-www to www in one rule and HTTP to HTTPS in another, so a plain http://example.com request hops twice before it resolves. Two hops slow the page, waste crawl budget, and can weaken the signals a 301 is meant to pass. Section 05 shows the single combined block that does both in one redirect.
- Symptom:
curl -Ishows two 301 responses back to back - Cause: separate host and HTTPS rules stacked in .htaccess
- Fix: one
RewriteCondpair feeding oneRewriteRule
01. Why a Canonical Domain Matters
When both www.example.com and example.com serve the same site, you effectively have two addresses for every page. Left alone, that causes three real problems.
- Duplicate content in search. Search engines may index both versions of a page. That splits your ranking signals and forces the engine to guess which URL to show, instead of you telling it.
- Split link equity. If some sites link to your www version and others link to the bare domain, the value of those links is divided across two URLs rather than concentrated on one.
- Cookie and caching inconsistencies. A cookie set on
example.comis not automatically available onwww.example.com, and a CDN or browser cache keyed on hostname will store two copies of the same asset. Users who arrive on the "wrong" host can see stale content or get logged out.
Canonicalization solves all three at once: you nominate one hostname as the real one and 301-redirect the other to it, so every link, crawl, and cookie lands in the same place.
For canonicalization you always want a 301 (permanent) redirect. A 301 tells search engines the move is permanent and passes ranking signals to the target. A 302 (temporary) tells them the original URL will come back, so they keep indexing it. A 302 has its place for genuinely short-lived redirects, which we cover in our guide to temporary 302 redirects, but it is the wrong tool for a permanent canonical host.
02. Pick One: www or non-www
There is no SEO advantage to either choice on its own. What matters is that you pick one and enforce it everywhere. That said, there are practical trade-offs worth knowing before you commit, because switching later means re-establishing redirects and re-submitting to search engines.
The www Hostname
www is a real subdomain, which gives you flexibility at the DNS and cookie level. Larger and busier sites often prefer it.
- Can be a CNAME, so you can point it at a CDN without touching the root record
- Lets you serve static assets from a cookieless subdomain for faster caching
- Keeps cookies scoped away from other subdomains if you set them on www only
The Bare Domain
The root domain is shorter and cleaner in print and speech. Plenty of well-known sites use it.
- Simpler branding: shorter to type and say
- The root cannot be a CNAME, though our DNS handles CDN aliasing for the apex
- Any cookie set at the root is shared across every subdomain, which is sometimes not what you want
If you are undecided, most sites are fine with either. Choose the bare domain for simpler branding, or www if you expect to grow into a CDN and want a cookieless asset subdomain later. Whatever you pick, the rest of this guide enforces it.
03. Redirect non-www to www
If your canonical choice is www.example.com, this rule catches any request to the bare domain and 301-redirects it to the www version, preserving the path and query string. Place it near the top of your .htaccess file, before WordPress or other application rules.
RewriteEngine On
RewriteCond %{HTTP_HOST} ^example\.com [NC]
RewriteRule ^(.*)$ https://www.example.com/$1 [L,R=301]- Open cPanel and launch File Manager, then navigate to the document root for your site (usually
public_html). - Enable Show Hidden Files in File Manager settings so you can see
.htaccess. - Right-click
.htaccessand choose Edit. If the file does not exist, create it. - Add the three lines above at the top, replacing
example.comwith your own domain (keep the backslash before.com, it escapes the dot in the pattern). - Save, then load
http://example.comin a browser and confirm it lands onhttps://www.example.com.
The [NC] flag makes the host match case-insensitive, [L] stops rule processing once this one fires, and R=301 issues the permanent redirect. The $1 back-reference carries the original path so /blog/post is not lost.
04. Redirect www to non-www
If you chose the bare domain as canonical instead, flip the logic: match any request that arrives on the www host and send it to the root. This rule also preserves the path and query string.
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.example\.com [NC]
RewriteRule ^(.*)$ https://example.com/$1 [L,R=301]The structure mirrors the previous section. The only differences are the condition now matches the www. prefix and the target drops it. Do not add both this rule and the non-www-to-www rule at the same time, or you will create the redirect loop described in Section 10.
A more portable version uses %{HTTP_HOST} in the target so you do not hard-code the domain, which is handy if you reuse the same .htaccess across sites. For a single site, the explicit version above is easier to read and debug. For the full range of rewrite patterns, see our complete guide to htaccess.
05. Combine Canonical Host and Force HTTPS
This is the block we recommend. If you enforce the canonical host in one rule and force HTTPS in a separate rule, a request to http://example.com gets redirected to https://example.com, then redirected again to https://www.example.com: two hops. The block below does both in a single redirect, so every request resolves in exactly one 301.
For a canonical of www + HTTPS:
RewriteEngine On
RewriteCond %{HTTP_HOST} ^example\.com [NC,OR]
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://www.example.com/$1 [L,R=301]For a canonical of non-www + HTTPS:
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.example\.com [NC,OR]
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://example.com/$1 [L,R=301]The [OR] flag on the first condition means the rule fires if either the host is wrong or the connection is not HTTPS. Because the target always specifies the correct host and https://, one match sends the visitor straight to the final URL. No chaining.
On some stacks the %{HTTPS} variable does not reflect the visitor's real connection because TLS terminates upstream. If your force-HTTPS rule seems to loop, use RewriteCond %{HTTP:X-Forwarded-Proto} !https instead of the %{HTTPS} off line. Our platform handles this correctly for the standard pattern, but custom setups may need it. The dedicated walkthrough is in how to redirect HTTP to HTTPS.
06. Setting the Canonical in WordPress
WordPress has its own opinion about your canonical host, and it will fight your .htaccess if the two disagree. Before adding rewrite rules to a WordPress site, set the canonical inside WordPress itself.
- Log in to wp-admin and go to Settings > General.
- Set WordPress Address (URL) and Site Address (URL) to your chosen canonical, both with the same host and both using
https://. For example, both readhttps://www.example.comor both readhttps://example.com. - Save. WordPress will now issue its own canonical redirect for the front end, sending requests on the other host to your chosen one.
With both URLs set consistently, WordPress handles the canonical redirect at the application level, and your .htaccess rule from Section 05 backs it up at the server level for any request that reaches Apache before PHP runs. The two agree, so there is no loop. Keep the combined host-plus-HTTPS block above the # BEGIN WordPress marker in .htaccess. For everything else rewrite-related in WordPress, our complete guide to htaccess has the details.
If you switch an established WordPress site from www to non-www (or the reverse), the old host is baked into post content, image URLs, and serialized options. Changing the two Settings fields is not enough on its own. Run a proper search-and-replace across the database so internal links and media point at the new host, otherwise you will trigger mixed content and broken images.
07. Trailing Slashes and the rel=canonical Tag
Two smaller consistency issues round out canonicalization: trailing slashes and the canonical tag.
Trailing slashes. Just as www and non-www are two URLs for one page, so are /about and /about/. Most platforms, WordPress included, already normalize this for you by redirecting one form to the other. If yours does not, pick one convention and enforce it, but do not layer an aggressive slash-normalizing rule on top of an application that already handles it, or you risk a loop.
The rel=canonical tag. This HTML tag in your page head names the preferred URL for that specific page:
<link rel="canonical" href="https://www.example.com/about/" />Think of it as a complement to your redirects, not a replacement. The 301 redirect is for humans and crawlers arriving at the wrong URL: it physically moves them. The canonical tag is a backup hint for search engines when a redirect is not possible or not desirable, such as pages reachable through tracking parameters. On WordPress, SEO plugins like Yoast or Rank Math emit this tag automatically once your Site Address is set. Belt and braces: redirect where you can, tag everywhere.
08. Testing Your Redirects
Do not trust a redirect until you have watched the response headers. A browser hides the hops from you. The reliable check is curl -I, which prints the headers without following the redirect, so you can count the hops one at a time.
curl -I http://example.comA correct single-hop canonical looks like this:
HTTP/1.1 301 Moved Permanently
Location: https://www.example.com/To follow the whole chain and confirm there is only one hop, add -L and watch how many 301 lines appear:
curl -sIL http://example.com | grep -i "^HTTP\|^Location"- Run the command against
http://example.com(plain HTTP, bare domain) since that is the worst case: wrong host and wrong protocol. - Confirm you see one
301line, followed by a final200 OKon your canonical URL. - If you see two or more
301lines in a row, your host and HTTPS redirects are chained. Go back to Section 05 and combine them. - If
curlreports "Maximum (50) redirects followed" you have a loop. See Section 10. - Repeat for
http://www.example.comandhttps://variants to confirm every entry point lands on the same canonical URL.
Open your browser's developer tools, switch to the Network tab, enable Preserve log, and load the non-canonical URL. Each redirect shows as its own request with a 301 status. One row of 301 is what you want. More than one means a chain.
09. How Redirects Work on Our Stack
Sites on Ultra Web Hosting run Apache behind Nginx. Nginx sits in front as a reverse proxy and handles static files and caching, while Apache runs your .htaccess and PHP. For canonical and HTTPS redirects this arrangement is transparent: the standard RewriteCond and RewriteRule rules in this guide work exactly as written, because Apache still processes your .htaccess.
A few rewrite behaviors interact with the Nginx layer in ways that surprise people, mostly around caching of redirect responses and how the proxy passes protocol information to Apache. If a redirect you know is correct does not seem to take effect, or an old redirect appears to persist after you have removed it, that is usually the Nginx cache holding the previous response. Our notes on Nginx and htaccess redirect issues cover the specific cases and how to clear a cached redirect.
Because Nginx can cache a 301, always test with a fresh request after changing a redirect. Add a dummy query string such as curl -I "http://example.com/?nocache=1" to bypass a cached response while you confirm the new rule, then re-test the clean URL.
10. Common Pitfalls
Redirect loops from conflicting rules. The classic loop is having both a www-to-non-www and a non-www-to-www rule active at the same time, so each redirect triggers the other forever. Pick one direction and delete the other. A loop also happens when a plugin or WordPress setting redirects to a host that your .htaccess redirects away from, so make sure Section 06 and your rewrite rule agree.
Forgetting HTTPS or HSTS. If you canonicalize the host but leave HTTP working, you have only solved half the duplication. Combine the host and HTTPS redirect as in Section 05. Once every request lands on HTTPS reliably, consider adding an HSTS header so browsers skip the HTTP request entirely.
Mixed content after switching. When you move a site to HTTPS or change hosts, hard-coded http:// links to your own images, scripts, and stylesheets break the padlock. The browser blocks or warns on the insecure resources. Fix the source URLs rather than relying on the redirect to catch them. The full remedy is in how to fix mixed content after installing SSL.
Rule order in .htaccess. Canonical and HTTPS redirects must sit at the top of the file, above application rules like the WordPress block. Apache reads top to bottom, and the [L] flag stops processing, so a redirect placed below the WordPress front-controller rule may never run. When in doubt, canonical redirect first, everything else after.
A redirect chain, where one 301 leads to another before reaching the final URL, is worse than a single hop in two ways. Each extra hop adds a full round trip of latency before your page even starts loading, and search engines can dilute the ranking signals passed through a long chain. A redirect loop is worse still: the browser gives up and shows an error, so the page never loads at all. Always confirm one clean 301 with the tests in Section 08.
Want Us to Set Up the Redirect?
If you would rather not edit .htaccess yourself, tell us which host you want as canonical and we will add the combined host-plus-HTTPS block, confirm a single clean 301, and check for loops. We handle canonical redirects on shared, VPS, and dedicated plans.
Open a Support TicketQuick Recap: Canonical Redirects in Six Steps
If you only do six things from this guide, do these:
- Pick one hostname, www or non-www, and commit to it site-wide.
- Add the combined block from Section 05 so host and HTTPS are enforced in a single 301, never chained.
- Use a 301, not a 302, so search engines treat the canonical as permanent.
- Set WordPress Address and Site Address to the same canonical host so WordPress and .htaccess agree.
- Add rel=canonical tags as a backup hint, and keep trailing slashes consistent.
- Test with
curl -Iand confirm exactly one 301 hop, no chain and no loop, then re-submit your canonical site to search engines.
Last updated July 2026 · Browse all htaccess and Redirects articles
