SEO для малого бизнеса

Склейка www и без www: как выбрать главное зеркало и не потерять трафик

Почему сайт доступен по двум адресам, чем это вредит, как настроить редирект и канонические ссылки и что сделать в Вебмастере.

13 минут чтения 0 Дмитрий Акиндинов
Содержание
  1. Откуда вообще берётся второй адрес
  2. Чем это вредит, а чем не вредит
  3. Какое зеркало выбрать главным
  4. Настройка 301 редиректа
  5. Настройки внутри CMS
  6. Канонические ссылки: зачем они, если есть 301
  7. Что сделать в Вебмастере и Search Console
  8. Соседние склейки, которые обычно забывают
  9. Проверка: один скрипт на все варианты
  10. Чек-лист
  11. Сколько это занимает
  12. Частые вопросы

Для человека адреса с www и без одинаковы, для поисковика это два сайта с полностью совпадающим содержимым. Склейка нужна, чтобы весь накопленный вес лежал на одном адресе. Настраивается 301 редиректом, на типовом сайте это 30-60 минут вместе с проверками.

Открываете сайт как example.ru, потом как www.example.ru, и обе версии показывают одно и то же. Человек разницы не заметит, поисковая система видит два разных сайта с полностью совпадающим содержимым. Склейка www и без www нужна ровно затем, чтобы ссылочный вес и накопленные сигналы лежали на одном адресе, а не делились пополам. Ниже: откуда берётся вторая версия, как выбрать главное зеркало, как настроить 301 на Apache, nginx и в панели хостинга, зачем при этом ещё и канонические ссылки, и что сделать в Яндекс Вебмастере.

Два адреса сайта сходятся в один через редирект

Я разбираю такие случаи регулярно. Обычно приходят не с формулировкой «у меня не склеены зеркала», а с жалобой «позиции просели после переезда на хостинг» или «Метрика показывает половину визитов». Копаешь, а там два живых хоста и полтора года разброда.

Откуда вообще берётся второй адрес

Исторически www был именем конкретной машины в домене: почта на mail, файлы на ftp, веб на www. К 2026 году от этого осталась привычка и одна техническая деталь, о которой ниже.

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

  • панель хостинга при добавлении домена автоматически создаёт две DNS-записи: A на голый домен и CNAME на www;
  • конфиг веб-сервера пишется с ServerAlias www.example.ru, то есть один и тот же сайт отвечает на оба имени;
  • регистратор при делегировании домена по умолчанию тоже прописывает обе записи.

Посмотреть, что реально настроено в DNS, можно одной командой:

nslookup example.ru
nslookup www.example.ru
# или, если есть dig
dig +short example.ru A
dig +short www.example.ru CNAME

Если оба имени резолвятся и оба отдают 200, у вас два зеркала. Дальше вопрос только в том, знает ли об этом поиск и что он с этим сделал.

Чем это вредит, а чем не вредит

Начну с честной оговорки: и Яндекс, и Google умеют склеивать зеркала самостоятельно. Полной катастрофы от нерасклеенных www обычно не происходит. Проблема в другом: выбирают они сами, по своим сигналам, и не всегда выбирают тот адрес, который вы считаете основным.

Что ломается на практике:

  • Дубли. Каждая страница существует в двух экземплярах. Для сайта на 200 страниц это 400 URL в обходе, лишний расход краулингового бюджета и вероятность, что в выдаче окажется не та версия. Как их находить и чем это ещё чревато, разбирал в статье про дубли страниц.
  • Ссылочный вес делится. Часть внешних ссылок ведёт на www, часть на голый домен. Если склейки нет, вес не суммируется.
  • Аналитика. В Метрике счётчик стоит на обоих хостах, но отчёты по внутренним переходам ломаются: переход с www.example.ru на example.ru считается внешним. Клиенты потом удивляются «источнику трафика: сайты», где сам сайт себе донор.
  • SSL. Самая болезненная штука. Бесплатный Let’s Encrypt выпускается на конкретные имена. Если в сертификате только example.ru, то заход на https://www.example.ru даёт браузерное предупреждение об опасном соединении. Сертификат надо запрашивать сразу на оба имени, даже если один из них будет только редиректить.
  • Куки и авторизация. Залогинились в админку на www, потом открыли ссылку без www и вас не пускает. На WordPress это классика жанра.

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

Какое зеркало выбрать главным

Спойлер: технически почти всё равно. Разница между example.ru и www.example.ru для ранжирования нулевая, и любые рассуждения «без www ранжируется лучше» это фольклор.

Практические аргументы:

КритерийБез wwwС www
Длина и вид в рекламе, на визиткеКороче, читается лучшеЛишние четыре символа
CNAME на корень домена (нужен для части CDN)Нельзя по стандарту DNS, только ALIAS/ANAME у продвинутых DNS-провайдеровМожно, обычный CNAME
Изоляция кук от поддоменовКуки корневого домена уезжают на все поддоменыКуки живут только на www
Смена хостинга без правки A-записиПридётся менять AДостаточно переставить CNAME
Привычка аудитории в РФ в 2026Основной вариантВстречается у старых сайтов и банков

Для типовой визитки, корпоративного сайта или магазина малого бизнеса я выбираю вариант без www. Если у вас крупный проект с CDN, множеством поддоменов и вопросами изоляции кук, www даёт больше свободы в DNS.

Но главный критерий не в таблице. Смотрите, что уже проиндексировано и куда ведут внешние ссылки. Если пять лет в выдаче висел www.example.ru, все каталоги и справочники ссылаются на него, а на визитках напечатан он же, то менять зеркало ради красоты значит устраивать себе мини-переезд с временной просадкой. Тогда лучше оставить www главным и склеить всё на него.

Как проверить, что сейчас считает главным поиск:

  1. В Яндекс Вебмастере: раздел «Индексирование» — «Страницы в поиске», посмотреть, с каким хостом URL в списке.
  2. Запросом site:example.ru и site:www.example.ru в поиске, сравнив количество страниц.
  3. В логах доступа: какой хост чаще запрашивают боты. На shared-хостинге логи обычно лежат в ~/logs/ или доступны из панели.

Настройка 301 редиректа

Правильный редирект: 301 Moved Permanently, одним прыжком, с сохранением пути и query-строки. Не 302, не 307, не мета-refresh, не JavaScript.

Apache и LiteSpeed, файл .htaccess

Самый частый случай на shared-хостинге. Правило кладётся в .htaccess в корне сайта, до правил CMS.

Склейка на адрес без www, заодно с переводом на HTTPS:

RewriteEngine On

# http без www, http с www, https с www -> https без www, одним прыжком
RewriteCond %{HTTPS} !=on [OR]
RewriteCond %{HTTP_HOST} ^www.(.+)$ [NC]
RewriteRule ^ https://example.ru%{REQUEST_URI} [R=301,L]

Обратный вариант, если главным выбран www:

RewriteEngine On

RewriteCond %{HTTPS} !=on [OR]
RewriteCond %{HTTP_HOST} !^www. [NC]
RewriteRule ^ https://www.example.ru%{REQUEST_URI} [R=301,L]

Два момента, на которых спотыкаются чаще всего. Первый: правило должно стоять выше блока # BEGIN WordPress, иначе фронт-контроллер CMS перехватит запрос раньше. Второй: %{REQUEST_URI} уже содержит начальный слеш и путь, дописывать /$1 не нужно, иначе получите двойной слеш. Про то, как вообще устроен этот файл и что в него класть помимо редиректов, писал отдельно в материале про кэширование через .htaccess.

Если хостинг за прокси или балансировщиком, условие %{HTTPS} !=on может не срабатывать, потому что до Apache запрос доходит уже расшифрованным. Тогда проверяют заголовок:

RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^ https://example.ru%{REQUEST_URI} [R=301,L]

nginx

На VPS или у хостинга с nginx редирект делается отдельным server-блоком. Так правильнее, чем через if внутри основного блока.

server {
    listen 443 ssl;
    server_name www.example.ru;

    ssl_certificate     /etc/letsencrypt/live/example.ru/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.ru/privkey.pem;

    return 301 https://example.ru$request_uri;
}

server {
    listen 80;
    server_name example.ru www.example.ru;
    return 301 https://example.ru$request_uri;
}

Обратите внимание: у редиректящего server-блока тоже должен быть сертификат, покрывающий www. Браузер сначала устанавливает TLS-соединение и только потом получает редирект. Без сертификата пользователь увидит предупреждение и до 301 не доедет.

Сертификат на оба имени запрашивается так:

certbot --nginx -d example.ru -d www.example.ru

Панель хостинга

У большинства российских хостингов есть готовый переключатель. В ISPmanager это «Сайты» — карточка домена — псевдонимы и галка перенаправления. В cPanel раздел Domains, колонка Redirect. У Timeweb в настройках домена пункт про основное зеркало.

Пользоваться этим можно, но проверяйте результат руками: панели любят ставить 302 вместо 301 или собирать цепочку из двух прыжков (http://www в http:// без www, потом в https://).

Что не надо делать

  • Редирект в PHP. header('Location: ...') в index.php работает, но выполняется после загрузки половины CMS. На каждый лишний хит вы тратите ресурсы PHP и добавляете 100-300 мс. На уровне веб-сервера это стоит доли миллисекунды.
  • Директива Host в robots.txt. Яндекс перестал её учитывать ещё в 2018 году. Если она у вас там осталась, просто удалите, вреда от неё нет, пользы тоже.
  • Цепочки. http://www.example.ru должен попадать на https://example.ru за один прыжок, а не за три. Каждое звено это потеря части сигнала и лишний round-trip для пользователя.

Настройки внутри CMS

Редиректа мало. Если внутри CMS прописан старый адрес, вы получите бесконечную генерацию ссылок на неглавное зеркало и, в худшем случае, цикл редиректов.

WordPress. Адрес хранится в двух опциях, siteurl и home. Через WP-CLI:

wp option get home
wp option get siteurl
wp search-replace 'https://www.example.ru' 'https://example.ru' --precise --report-changed-only --dry-run
wp search-replace 'https://www.example.ru' 'https://example.ru' --precise --report-changed-only

Сначала обязательно с --dry-run, потом без. Ключ --precise нужен, чтобы корректно обработать сериализованные массивы в опциях и метаполях, иначе часть настроек тем и плагинов превратится в тыкву. После замены сбросьте кэш и, если стоит плагин кэширования, почистите его отдельно.

Если WP-CLI недоступен, адреса можно прибить константами в wp-config.php (тогда поля в админке станут неактивными):

define('WP_HOME',    'https://example.ru');
define('WP_SITEURL', 'https://example.ru');

Битрикс. Проверяются SITE_SERVER_NAME в bitrix/php_interface/dbconn.php или в настройках модуля «Управление структурой», плюс поле «Адрес сайта» в списке сайтов. Отдельно посмотрите настройки почтовых шаблонов, там адрес часто зашит вручную.

OpenCart. Константы HTTP_SERVER и HTTPS_SERVER в config.php и admin/config.php.

Tilda. Домен привязывается в настройках проекта, второе зеркало отдаётся площадкой автоматически и настраивается там же. Своего .htaccess у вас нет, поэтому всё делается в панели.

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

Канонические ссылки: зачем они, если есть 301

Частый вопрос от клиентов: поставили редирект, нужен ли rel=canonical. Ответ: нужен, но он решает другую задачу.

Редирект физически не даёт открыть неглавное зеркало. Канонический тег говорит поиску, какая версия страницы основная, когда обе версии доступны и обе должны оставаться доступными. Для www-зеркала канонический тег не заменяет 301, он подстраховывает: если завтра редирект слетит при обновлении CMS или переносе хостинга, канонические ссылки некоторое время удержат ситуацию.

Что должно быть в исходном коде каждой страницы:

<link rel="canonical" href="https://example.ru/uslugi/podderzhka/" />

Абсолютный URL, с протоколом, с главным хостом, с тем же завершающим слешем, что и в реальном адресе. Самая частая ошибка: canonical генерируется с относительным путём или с хостом из переменной $_SERVER['HTTP_HOST'], то есть на www-версии он честно указывает сам на себя. Толку ноль.

В WordPress канонические ссылки ставит Rank Math или Yoast, в Битриксе это делается через свойство страницы или шаблон компонента. Подробный разбор тонкостей, включая пагинацию и фильтры, лежит в статье про канонические ссылки.

Заодно проверьте, что в sitemap.xml все URL идут с главным хостом. Карта сайта со ссылками на www, пока редирект гонит всех обратно, это прямой конфликт сигналов.

Что сделать в Вебмастере и Search Console

Яндекс Вебмастер. Добавьте и подтвердите оба хоста, они там считаются разными сайтами. Затем в неглавном откройте «Индексирование» — «Переезд сайта» и укажите, что главным зеркалом становится другой адрес. Яндекс проверит наличие 301 и поставит задачу на склейку.

Сроки: обычно от двух недель до полутора месяцев. Первые дни в выдаче будут висеть обе версии, это нормально. Если через месяц ничего не сдвинулось, первым делом проверяйте, что редирект отдаёт именно 301 и что робот его видит (инструмент «Проверка ответа сервера» прямо в Вебмастере).

Google Search Console. Инструмента смены основного домена там нет с 2019 года, Google определяет каноническую версию сам по редиректам и тегам. Что стоит сделать: добавить ресурс типа «Домен» (Domain property, подтверждение через DNS TXT-запись), он покрывает сразу оба хоста и все поддоменты. Дальше в отчёте «Индексирование страниц» появится категория про страницы с редиректом, туда и уедет www-версия.

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

Соседние склейки, которые обычно забывают

Зеркала www это только один вид дублей по адресу. Пока правите .htaccess, закройте остальные, они лечатся теми же правилами.

ДубльПримерРешение
http и httpshttp://example.ru/301 на https, одним прыжком вместе с www
Слеш на конце/uslugi и /uslugi/Выбрать один вариант, второй редиректить
index.php и index.html/index.php, /uslugi/index.php301 на путь без имени файла
Регистр/Uslugi/ и /uslugi/301 на нижний регистр либо 404
Порт в адресеexample.ru:80Редирект на канонический хост
Мусорные параметры/?utm_source=..., /?fbclid=...canonical без параметров, в robots.txt не закрывать

Правило для index.php в Apache:

RewriteCond %{THE_REQUEST} s/+(.*/)?index.php[s?] [NC]
RewriteRule ^ /%1 [R=301,L]

С регистром аккуратнее: если исторически часть страниц действительно жила по адресам с заглавными буквами и на них есть ссылки, слепой редирект в нижний регистр сломает их. Сначала выгрузите список проиндексированных URL, потом принимайте решение.

Отдельно про параметры: закрывать ?utm_* в robots.txt не надо, это популярный вредный совет. Робот тогда просто не увидит canonical на странице. Правильно оставить страницу открытой и указать канонический адрес без параметров.

Проверка: один скрипт на все варианты

После правок не надо кликать по браузеру. Прогоните набор адресов через curl и посмотрите коды ответа с целями редиректа.

DOMAIN=example.ru
for u in 
  "http://$DOMAIN/" 
  "http://www.$DOMAIN/" 
  "https://www.$DOMAIN/" 
  "https://$DOMAIN/" 
  "http://www.$DOMAIN/uslugi/" 
  "https://www.$DOMAIN/index.php" ; do
  printf '%-40s ' "$u"
  curl -s -o /dev/null -w '%{http_code} -> %{redirect_url}n' "$u"
done

Что должно получиться:

ЗапросОжидаемый ответ
http://example.ru/301 на https://example.ru/
http://www.example.ru/301 на https://example.ru/
https://www.example.ru/301 на https://example.ru/
https://example.ru/200
http://www.example.ru/uslugi/301 на https://example.ru/uslugi/
https://www.example.ru/index.php301 на https://example.ru/

Обратите внимание на четвёртую строку в первом столбце таблицы: путь /uslugi/ обязан сохраниться. Редирект, который сваливает все внутренние страницы на главную, встречается сплошь и рядом и убивает позиции надёжнее, чем отсутствие склейки вообще. Проверять надо минимум три внутренних URL, а не только корень.

Полную цепочку с заголовками показывает такой вызов:

curl -sIL http://www.example.ru/uslugi/ | grep -Ei '^(HTTP|location)'

В выводе должно быть ровно две строки HTTP: одна с 301, одна с 200. Три и больше означают цепочку, её надо схлопывать.

Чек-лист

Короткий список, по которому я прохожу на каждом таком проекте:

  1. Определить текущее главное зеркало по данным Вебмастера и внешним ссылкам.
  2. Выпустить или перевыпустить SSL-сертификат сразу на оба имени.
  3. Поставить 301 на уровне веб-сервера, одним прыжком, с сохранением пути.
  4. Проверить, что правило стоит выше правил CMS в .htaccess.
  5. Заменить адрес внутри CMS (siteurl, home, константы конфига, почтовые шаблоны).
  6. Проверить rel=canonical на трёх типах страниц: главная, внутренняя, страница пагинации.
  7. Убедиться, что sitemap.xml отдаёт URL только с главным хостом.
  8. Удалить директиву Host из robots.txt, если она там осталась.
  9. Подтвердить оба хоста в Яндекс Вебмастере, запустить переезд с неглавного.
  10. Добавить ресурс типа «Домен» в Search Console.
  11. Обновить адрес в счётчике Метрики, в рекламных кампаниях, в справочниках и карточках организаций.
  12. Прогнать curl-скрипт и убедиться, что цепочек нет.
  13. Через две недели проверить «Страницы в поиске» в Вебмастере: старый хост должен уходить в исключённые как редирект.

Пункт 11 забывают почти всегда. Реклама, которая годами вела на www, после склейки продолжает работать, но каждый клик получает лишний редирект и небольшую потерю по скорости. На мобильном это заметные 200-400 мс.

Сколько это занимает

Техническая часть на типовом сайте: 30-60 минут вместе с проверками. Если сайт на shared-хостинге, с одним .htaccess и WordPress, укладываюсь в полчаса. Если это Битрикс с самописными модулями и захардкоженными адресами в шаблонах писем и в базе, уходит два-три часа, потому что приходится вычищать хвосты по всей базе.

Дальше просто ждём. Яндекс склеивает за две недели в среднем, Google переваривает быстрее, но полное исчезновение старого хоста из отчётов занимает до двух месяцев. Позиции при корректной склейке не проседают. Если проседают, значит редирект сделан не 301, или потерялись пути, или каноникал указывает не туда.

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

Частые вопросы

Какое зеркало выбрать главным

То, что уже стоит в индексе и в ссылках. Технической разницы между вариантами нет. А смена главного зеркала на работающем сайте стоит просадки, так что без причины его не трогают.

Как склеить www и без www

Постоянным редиректом с неглавного варианта на главный на уровне сервера, плюс правильный адрес сайта в настройках CMS, плюс канонические ссылки. Три слоя нужны потому, что каждый закрывает свой случай.

Зачем canonical, если есть редирект

Редирект закрывает вход снаружи, канонический адрес закрывает ситуации внутри сайта, когда ссылка сформирована с другим вариантом написания. Один лишний переход это ещё и потерянные миллисекунды.

Что ещё склеивают заодно

Протокол, слеш на конце адреса и регистр букв. Эти варианты дают тот же эффект дублей, а забывают о них чаще, чем о www.

Передайте техническую часть в надёжные руки.

Слежу за хостингом, бэкапами и обновлениями. Когда что-то пойдёт не так – звоните мне, не своему программисту, не в спортзал и не маме.

Короткие вопросы по теме

Все вопросы по теме "SEO для малого бизнеса"

Заявка

Обсудим задачу

Напишите имя и телефон, выберите удобный канал. Перезвоню или напишу в течение часа в рабочее время.

Куда удобнее ответить?