Как настроить редирект с non-www на www в WordPress

Если сайт открывается и по адресу site.ru, и по www.site.ru, для поисковиков это два разных адреса. Без редиректа и канонизации легко получить дубли страниц, размывание ссылочного веса и путаницу в аналитике. Решение здесь одно: выбрать основной вариант домена и принудительно отправлять все запросы на него.

Для схемы с www это обычно означает, что site.ru должен всегда перенаправлять на www.site.ru, а WordPress — быть настроен именно на канонический адрес с www.

Что нужно сделать в первую очередь

Редирект с non-www на www состоит из двух частей:

  • в WordPress должны быть указаны правильные адреса сайта;
  • на уровне веб-сервера должен работать постоянный редирект 301 со всех вариантов без www на вариант с www.

Если изменить только настройки WordPress, но не настроить сервер, часть запросов всё равно будет открываться по старому адресу. Если сделать только редирект на сервере, но оставить в WordPress неверный адрес сайта, можно получить циклы перенаправлений или проблемы с входом в админку.

Перед изменениями проверьте, какой вариант домена вы хотите считать основным. Для SEO это должен быть один и тот же адрес во всех местах: в WordPress, в редиректе, в sitemap, в Search Console и в ссылках на сайте.

Настройка адреса сайта в WordPress

Сначала задайте канонический домен в самой системе. Это можно сделать через админку, если она доступна.

  1. Откройте Настройки → Общие.
  2. В полях Адрес WordPress (URL) и Адрес сайта (URL) укажите адрес с www, например https://www.site.ru.
  3. Сохраните изменения.

Оба адреса должны совпадать, если у вас нет отдельной технической причины разделять их. Для обычного сайта это правильный вариант.

Если после сохранения админка начала перенаправлять не туда или сайт стал недоступен, значит редирект на сервере уже работает не так, как нужно, либо в настройках указан другой протокол — например, http вместо https. В таком случае сначала проверьте, какой адрес реально открывается в браузере.

Как настроить редирект на уровне сервера

Самый надёжный вариант — сделать 301-редирект на веб-сервере. Это лучше, чем полагаться только на плагины: редирект срабатывает раньше, не зависит от темы и работает даже если WordPress временно недоступен.

Ниже — рабочие варианты для Apache и Nginx. Используйте только тот, который соответствует вашему хостингу.

Apache: .htaccess

Если сайт работает на Apache, откройте файл .htaccess в корне сайта и добавьте правило выше стандартного блока WordPress или сразу перед ним. Перед правкой сделайте резервную копию файла: ошибка в .htaccess может уронить сайт с 500-й ошибкой.

RewriteEngine On
RewriteCond %{HTTP_HOST} ^site\.ru$ [NC]
RewriteRule ^(.*)$ https://www.site.ru/$1 [L,R=301]

Что здесь важно:

  • RewriteCond %{HTTP_HOST} ^site\.ru$ [NC] — правило срабатывает только для домена без www;
  • RewriteRule отправляет запрос на тот же путь, но уже с www;
  • R=301 означает постоянный редирект, который нужен для SEO.

Если сайт работает по https, редирект должен вести сразу на HTTPS-версию с www, как в примере выше. Не делайте цепочку вида http://site.ru → http://www.site.ru → https://www.site.ru, если можно сразу отправлять на конечный адрес.

Nginx: конфигурация сервера

На Nginx редирект обычно настраивают в конфигурации виртуального хоста. Если у вас обычный shared-хостинг, доступ к этому уровню может быть закрыт — тогда нужно обращаться в поддержку хостинга.

Пример отдельного server-блока для домена без www:

server {
    server_name site.ru;
    return 301 https://www.site.ru$request_uri;
}

Если у вас уже есть основной серверный блок для сайта, редирект можно сделать в отдельном блоке, который отвечает только за site.ru. Это безопаснее, чем пытаться смешивать редирект и обработку сайта в одном месте без понимания текущей конфигурации.

После изменения конфигурации не забудьте проверить её и перезагрузить Nginx. На практике это обычно делает администратор сервера или хостинг-поддержка.

Когда можно использовать плагин

Плагин для редиректов удобен, если у вас нет доступа к .htaccess или конфигу Nginx. Но для постоянного канонического редиректа это запасной вариант, а не основной.

Минусы плагина простые:

  • он зависит от WordPress и не сработает, если сайт недоступен;
  • лишний плагин добавляет ещё один слой логики, который может конфликтовать с кешированием или другими правилами;
  • при переносе сайта редирект легко забыть перенести вместе с настройками.

Если всё же используете плагин, убедитесь, что он делает именно 301-редирект на https://www.site.ru, а не временный 302. Для SEO это принципиально.

Как проверить, что редирект работает правильно

Проверка нужна не только после настройки, но и после смены темы, хостинга или SSL-сертификата. Самый простой тест — открыть в браузере адрес без www и посмотреть, куда он переходит. Но лучше проверить ещё и код ответа.

Если у вас есть доступ к консоли, можно использовать такую команду:

curl -I https://site.ru

В ответе должен быть статус 301 и заголовок Location: https://www.site.ru/.... Если вместо этого вы видите 200, значит редиректа нет. Если видите несколько последовательных перенаправлений, стоит упростить схему и убрать лишнее звено.

Ещё один практический тест — открыть:

  • http://site.ru
  • https://site.ru
  • http://www.site.ru

Все три варианта должны приводить к одному итоговому адресу: https://www.site.ru. Если хотя бы один вариант остаётся без редиректа, канонизация настроена не полностью.

Типичные ошибки, из-за которых появляются дубли

Чаще всего проблема возникает не из-за самого редиректа, а из-за несогласованности настроек.

  • WordPress и сервер смотрят на разные домены. В админке указан www, а на сервере редирект ведёт на без www или наоборот.
  • Редирект сделан только для главной страницы. Тогда внутренние URL продолжают открываться по двум версиям.
  • Используется 302 вместо 301. Поисковики воспринимают это как временное перенаправление, а не как постоянный переезд.
  • Есть цепочка редиректов. Например, сначала с http на https, потом с без www на www. Лучше свести всё к одному финальному переходу.
  • Внутренние ссылки на сайте ведут на старый вариант домена. Даже при рабочем редиректе это лишняя нагрузка и лишний шаг для пользователя и робота.

Если сайт уже проиндексирован в двух версиях, после настройки редиректа поисковики обычно постепенно склеивают адреса. Но это происходит только если основной домен везде один и тот же, а страницы не продолжают отдавать разные версии контента.

Что ещё стоит проверить после настройки

После редиректа убедитесь, что сайт везде использует один домен:

  • в меню и контенте нет старых абсолютных ссылок на site.ru без www;
  • в XML-карте сайта указан канонический адрес;
  • в Search Console добавлен и подтверждён именно основной вариант домена;
  • SSL-сертификат покрывает и site.ru, и www.site.ru, если вы принимаете запросы на оба адреса до редиректа.

Если у вас уже есть большой сайт, после смены канонического домена полезно пройтись по внутренним ссылкам и заменить старые абсолютные URL на новый вариант. Это не обязательно для работы редиректа, но убирает лишние обращения и ускоряет загрузку страниц.

Для сайтов на WordPress, где нужно не только настроить редирект, но и убрать другие технические дубли, иногда помогает отдельный SEO-плагин с функциями очистки и канонизации. Но сам редирект с non-www на www всё равно лучше держать на уровне сервера или хостинга, а не в интерфейсе плагина.

Если сделать всё в правильном порядке — выбрать основной домен, прописать его в WordPress и настроить 301-редирект на сервере — сайт перестанет отдавать дубли, а поисковым системам будет проще понять, какой адрес считать главным.

Как отключить XML-RPC в WordPress и не сломать внешние сервисы
30.08.2026
Как закрыть от индексации теги в WordPress
06.10.2026
Как сделать отложенный запуск задач в WordPress с помощью WP-Cron
26.09.2026
Как отключить дублирующиеся meta robots в WordPress и убрать лишние noindex
18.08.2026
Как убрать пагинацию из индексации в WordPress
10.10.2026