The site opens both with www and without, but search engines see two different addresses with identical content. Page duplicates, diluted link equity, confusion in Search Console. Sound familiar?

Neither Grav nor WordPress solve this problem out of the box. The .htaccess file and exactly one code block fix everything in five minutes. Below are tested lines for Apache servers: universal, without hardcoded domains, with HTTPS and without. Plus a way to verify that the redirect works beyond just the browser.

💡 Quick overview:

• Choose a canonical version (with www or without) and add a universal 301 redirect to .htaccess
• Check the redirect chain via curl -I or an online checker: browsers cache 301s and can lie
• One code block simultaneously solves the www problem and forces HTTPS

Why choose between www and non-www at all

Google does not prefer one variant over the other; the official position has remained unchanged for years. But you need to pick one and stick with it. Without a redirect, www.site.ru/page and site.ru/page get indexed as different URLs, link equity splits in half, and analytics counts the same traffic twice.

What to choose? For large projects, www is more convenient: cookies don't leak to subdomains like cdn. and api., and DNS records are easier to configure. For smaller sites, there is almost no difference. Focus on what's already indexed: type site:yourdomain.ru into search and see which variant appears more often in results. Make that one canonical.

Technical note: Grav doesn't generate redirects on its own. WordPress does only if siteurl in settings explicitly matches the desired variant, but even that works inconsistently. The solution is one: mod_rewrite in Apache via .htaccess.

Where.htaccess lives and how not to break it

The .htaccess file is located in the site root, alongside index.php or the wp-admin folder. If the file doesn't exist (Grav without a ready template, fresh hosting), create a text file named .htaccess with the leading dot required.

Before any edits, download the current version to your computer. A syntax error in .htaccess crashes the site with a 500 error instantly. Iron rule: one backup copy locally, another with a different name right on the server (.htaccess.backup). You can restore even without admin panel access, via FTP or the hosting file manager.

For Grav and WordPress, the rule is the same: if the file already contains RewriteEngine On, don't duplicate that line. Add the new redirect block after it. In the standard Grav .htaccess, this line is present by default.

301 redirect from www to non-www: universal code

The code below works for any domain; you don't need to substitute example.com manually. Convenient if you manage multiple sites or transfer rules between projects. Add to .htaccess after RewriteEngine On:

1
RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
2
RewriteRule ^(.*)$ http://%1/$1 [R=301,L]

Line by line: RewriteCond catches any host starting with www. and captures the domain in parentheses. RewriteRule redirects the request to the same path without www, substituting the captured domain via %1. The flag R=301 means permanent redirect. L tells the server "stop, don't apply further rules." NC makes the check case-insensitive.

If the site runs on HTTPS, replace http:// with https:// in RewriteRule. Better yet, use a combined block that solves both www and HTTPS in one pass:

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

The first condition triggers on HTTP requests, the second on www. If either is true ([OR]), the request goes to https://domain-without-www/path. One block, two problems solved.

Reverse scenario: from non-www to www

If you need the address bar to always show www, use the mirror variant:

1
RewriteCond %{HTTP_HOST} !^www\. [NC]
2
RewriteRule ^(.*)$ http://www.%{HTTP_HOST}/$1 [R=301,L]

The logic is the same, only the condition is inverted: if the host does not start with www, we add www. at the beginning. %{HTTP_HOST} substitutes the current host in full, unlike the previous block where we stripped www. via parentheses capture.

Version with HTTPS:

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

Use one of the four blocks, whichever matches your canonical domain variant and HTTPS presence. Two blocks in a row are unnecessary and will create an extra hop in the redirect chain.

How to verify that the redirect works

Don't rely on the browser; it caches 301 redirects and shows the old picture even after editing .htaccess. Three ways to find the truth:

• curl** -I.** In the terminal: curl -I http://www.example.com. A correct response starts with HTTP/1.1 301 Moved Permanently, and the Location: header contains the target URL. Check both variants, with www and without.
• Online checkers. Redirect Checker or HTTP Status Code Checker: paste the URL, see the full redirect chain and final response code.
• Google Search Console. After changing the canonical domain, go to property settings and specify the preferred version. This doesn't replace .htaccess but gives the search engine an additional signal.

A separate tip for Grav: after editing .htaccess, clear the CMS cache via Admin → Configuration → Performance → Clear Cache. Grav caches pages aggressively, and without clearing, the redirect may not apply to already generated copies.

⁉️🤔 Frequently asked questions

Which variant is better for SEO, with www or without?

Google officially states: there is no difference. Choose either and stick with it. The key factor is consistency: internal links, sitemap, and canonical tags should point to one variant. According to an Ahrefs survey, about 55% of top-100 sites use the non-www version, but both variants rank equally well.

What happens if you don't set up a redirect at all?

Search engines will see two independent duplicate sites. Link equity will split, pages will start competing with each other in results, and analytics reports will spread the same traffic across two hosts. After a few months, the typical picture: half the pages indexed with www, half without, rankings unstable.

Can you get by without.htaccess?

Yes, but alternatives are either more complex or slower. WordPress plugins like Redirection and Rank Math work at the PHP level; every request passes through the WordPress core, creating load. For high-traffic sites, .htaccess at the Apache level is noticeably faster. For Grav, redirect plugins are practically nonexistent, so .htaccess remains the primary path. On NGINX servers, the equivalent is return 301 directives in the server {} block.

Do you need to set up a redirect for each page separately?

No, the rules provided are universal; they apply to all site URLs automatically. One block covers the homepage, internal pages, images, and CSS files. Separate redirects from old URLs to new ones are configured additionally with Redirect 301 /old-page /new-page lines, but they have nothing to do with the www problem.

500 error after editing.htaccess, what to do?

Copy .htaccess.backup back via FTP or the hosting file manager; the site will come back instantly. Check the code for typos: a missing space, an extra slash, unmatched parentheses. Add rules one at a time and test after each change. And never edit .htaccess on production without a current backup at hand.

The redirect works, but Google keeps showing the old version in results. Why?

Reindexing takes from a few days to a couple of weeks. Make sure canonical tags on pages point to the chosen variant and the sitemap contains URLs without the old host. In Search Console, you can request a recrawl via the URL Inspection tool; this speeds up the process but doesn't guarantee instant results.

Which variant to set: the short verdict

If the site is new, go with non-www and HTTPS. Fewer characters in the address bar, easier to dictate out loud, no cookie issues with subdomains. For most projects, this is more than enough.

Already indexed with www? Don't break what works. Set up a redirect from non-www to www, update canonical tags, and carry on.

The entire process: open .htaccess, add one of the four blocks above, clear the CMS cache, verify via curl -I. Five minutes, and duplicates are gone from the search landscape. Other .htaccess techniques are collected in the server configuration guide; check it out if you're configuring a site comprehensively.