Сайт відкривається і з www, і без, а пошуковик бачить дві різні адреси з однаковим вмістом. Дублі сторінок, розмазана вага посилань, плутанина в Search Console. Знайомо?

Ні Grav, ні WordPress не вирішують цю проблему з коробки. Файл .htaccess і рівно один блок коду за п’ять хвилин усе виправляють. Далі, перевірені рядки для Apache-серверів: універсальні, без жорстко прописаного домену, з HTTPS і без. Плюс спосіб переконатися, що редірект працює не лише в браузері.

💡 Швидкий огляд:

• Виберіть канонічний варіант (з www або без) і додайте універсальний 301-редірект у .htaccess
• Перевірте ланцюжок редіректів через curl -I або онлайн-чекер: браузер кешує 301 і може брехати
• Один блок коду одночасно вирішує проблему www і примусового HTTPS

Навіщо взагалі вибирати між www і без www

Google не віддає переваги жодному з варіантів, офіційна позиція незмінна роками. Але вибрати потрібно один і дотримуватися його. Без редіректу www.site.ru/page і site.ru/page індексуються як різні URL, вага посилань ділиться навпіл, а в аналітиці той самий трафік обліковується двічі.

Що вибрати? Для великих проєктів www зручніше: cookie не витікають на піддомени на кшталт cdn. і api., простіше налаштовувати DNS-записи. Для невеликих сайтів різниці майже немає. Орієнтуйтеся на те, що вже проіндексовано: введіть site:вашдомен.ru у пошук і подивіться, який варіант частіше у видачі. Його і робіть канонічним.

Технічний нюанс: Grav не генерує редірект сам. WordPress, лише якщо siteurl у налаштуваннях явно збігається з бажаним варіантом, але й це працює нестабільно. Рішення одне, mod_rewrite в Apache через .htaccess.

Де лежить.htaccess і як його не покласти

Файл .htaccess знаходиться в корені сайту, там само, де index.php або папка wp-admin. Якщо файлу немає (Grav без готового шаблону, свіжий хостинг), створіть текстовий файл з іменем .htaccess, крапка на початку обов’язкова.

Перед будь-яким редагуванням завантажте поточну версію на комп’ютер. Синтаксична помилка в .htaccess кладе сайт із помилкою 500 миттєво. Залізне правило: одна резервна копія локально, друга, з іншим іменем прямо на сервері (.htaccess.backup). Відновити можна навіть без доступу до адмінки, через FTP або файловий менеджер хостингу.

Для Grav і WordPress правило спільне: якщо у файлі вже є RewriteEngine On, не дублюйте цей рядок. Додавайте новий блок редіректу після нього. У стандартному .htaccess Grav він присутній за замовчуванням.

301 Редірект з www на без www: універсальний код

Код нижче працює для будь-якого домену, не потрібно підставляти example.com вручну. Зручно, якщо ведете кілька сайтів або переносите правила між проєктами. Додайте в .htaccess після RewriteEngine On:

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

Порядково: RewriteCond ловить будь-який хост, що починається з www., і захоплює домен у дужки. RewriteRule перенаправляє запит на той самий шлях без www, підставляючи захоплений домен через %1. Прапор R=301 означає постійний редірект. L каже серверу «стоп, далі правила не застосовувати». NC робить перевірку без урахування регістру.

Якщо сайт працює за HTTPS, замініть http:// на https:// у RewriteRule. А краще, використовуйте комбінований блок, який за один прохід вирішує і www, і HTTPS:

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

Перша умова спрацьовує на HTTP-запити, друга, на www. Якщо істинне будь-яке з двох ([OR]), запит відлітає на https://домен-без-www/путь. Один блок, дві проблеми закрито.

Зворотний сценарій: з без www на www

Якщо потрібно, щоб в адресному рядку завжди був www, використовуйте дзеркальний варіант:

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

Логіка та сама, тільки умова інвертована: якщо хост не починається з www, додаємо www. на початок. %{HTTP_HOST} підставляє поточний хост цілком, на відміну від попереднього блоку, де ми відрізали www. через захоплення в дужки.

Версія з HTTPS:

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

Використовуйте один із чотирьох блоків, той, що відповідає вашому варіанту канонічного домену та наявності HTTPS. Два блоки підряд не потрібні й створять зайвий хоп у ланцюжку редіректів.

Як перевірити, що редірект працює

Не покладайтеся на браузер, він кешує 301-редіректи й показує стару картинку навіть після редагування .htaccess. Три способи дізнатися правду:

• curl** -I.** У терміналі: curl -I http://www.example.com. Коректна відповідь починається з HTTP/1.1 301 Moved Permanently, а заголовок Location: містить цільовий URL. Перевірте обидва варіанти, з www і без.
• Онлайн-чекери. Redirect Checker або HTTP Status Code Checker: вставляєте URL, бачите повний ланцюжок редіректів і підсумковий код відповіді.
• Google Search Console. Після зміни канонічного домену зайдіть у налаштування властивості та вкажіть бажану версію. Це не замінює .htaccess, але дає додатковий сигнал пошуковику.

Окрема порада для Grav: після редагування .htaccess скиньте кеш CMS, Admin → Configuration → Performance → Clear Cache. Grav агресивно кешує сторінки, і без скидання редірект може не застосуватися до вже згенерованих копій.

⁉️🤔 Часті запитання

Який варіант кращий для SEO, з www чи без?

Google офіційно заявляє: різниці немає. Вибирайте будь-який і дотримуйтеся його. Ключовий фактор, консистентність: внутрішні посилання, карта сайту й canonical-теги мають вказувати на один варіант. За даними опитування Ahrefs, близько 55% сайтів із топ-100 використовують версію без www, але обидва варіанти ранжуються однаково успішно.

Що буде, якщо взагалі не налаштовувати редірект?

Пошукові системи побачать два незалежні сайти-дублі. Вага посилань розділиться, сторінки почнуть конкурувати одна з одною у видачі, а у звітах аналітики той самий трафік розмажеться по двох хостах. Через кілька місяців типова картина: половина сторінок в індексі з www, половина без, позиції нестабільні.

Чи можна обійтися без.htaccess?

Так, але альтернативи або складніші, або повільніші. Плагіни для WordPress на кшталт Redirection і Rank Math працюють на рівні PHP, кожен запит проходить через ядро WordPress, що створює навантаження. Для високонавантажених сайтів .htaccess на рівні Apache помітно швидший. Для Grav плагінів-редіректорів практично немає, тому .htaccess залишається основним шляхом. На NGINX-серверах аналогом слугують директиви return 301 у блоці server {}.

Чи потрібно прописувати редірект для кожної сторінки окремо?

Ні, наведені правила універсальні, вони застосовуються до всіх URL сайту автоматично. Один блок покриває головну, внутрішні сторінки, зображення й CSS-файли. Окремі редіректи зі старих URL на нові налаштовуються додатково рядками Redirect 301 /old-page /new-page, але до www-проблеми вони стосунку не мають.

Помилка 500 після редагування.htaccess, що робити?

Скопіюйте .htaccess.backup назад через FTP або файловий менеджер хостингу, сайт оживе миттєво. Перевірте код на одруки: пропущений пробіл, зайвий слеш, непарні дужки. Додавайте правила по одному й тестуйте після кожної зміни. І ніколи не редагуйте .htaccess на продакшені без актуального бекапу під рукою.

Редірект працює, але Google продовжує показувати стару версію у видачі, чому?

Переіндексація займає від кількох днів до пари тижнів. Переконайтеся, що canonical-теги на сторінках вказують на вибраний варіант, а карта сайту містить URL без старого хосту. У Search Console можна запросити переобхід через інструмент перевірки URL — це пришвидшує процес, але не гарантує миттєвого результату.

Який варіант поставити: короткий вердикт

Якщо сайт новий, беріть варіант без www і HTTPS. Менше символів в адресному рядку, простіше диктувати вголос, жодних проблем із cookie на піддоменах. Для більшості проєктів цього вистачає із запасом.

Уже проіндексувалися з www, не ламайте те, що працює. Налаштуйте редірект із без-www на www, оновіть canonical і живіть спокійно.

Весь процес: відкрили .htaccess, додали один із чотирьох блоків вище, скинули кеш CMS, перевірили через curl -I. П’ять хвилин, і дублі зникли з пошукової картини. Інші прийоми для .htaccess зібрані в добірці з налаштування сервера, зазирніть, якщо налаштовуєте сайт комплексно.