Www или без www: влияние на SEO, риски и практические рекомендации

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

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

Что выбрать: сайт с WWW или без WWW

Для нового сайта выбор в основном определяется архитектурой и брендингом.

Критерий	С WWW	Без WWW
SEO-преимущество само по себе	Нет подтверждённого	Нет подтверждённого
Внешний вид адреса	Длиннее	Короче
Работа с отдельным хостом	Явный поддомен www	Корневой домен
Подходит для нового проекта	Да	Да
Стоит ли менять уже работающий сайт только ради этого	Обычно нет	Обычно нет

На небольшом корпоративном сайте вариант без WWW часто выбирают просто потому, что адрес короче. На крупной инфраструктуре отдельный www-хост иногда удобнее вписывается в существующую DNS-, CDN- или балансировочную архитектуру. Это техническое соображение, а не SEO-фактор.

Главный критерий для действующего проекта — не эстетика адресной строки, а цена смены. Если тысячи страниц уже индексируются как https://www.example.com/..., внутренние и внешние ссылки ведут туда, а аналитика работает стабильно, перевод на https://example.com/... без другой причины создаёт миграцию там, где её можно было избежать.

Почему проблема начинается с двух доступных версий

Допустим, одна страница отвечает кодом 200 OK сразу по двум адресам: https://www.example.com/catalog и https://example.com/catalog

Если содержимое одинаковое, поисковой системе приходится определить, какой URL считать представительным. Google прямо относит перенаправления и rel="canonical" к сильным сигналам каноникализации, а наличие URL в Sitemap — к более слабым.

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

Важно именно соответствие страниц. Запрос к /catalog/item-a/ должен вести на /catalog/item-a/, а не на главную страницу.

В терминологии Яндекса разные адреса одного ресурса могут группироваться вокруг главного адреса. С этим связан и более широкий вопрос склейка зеркал: WWW/non-WWW — лишь один из случаев, когда один и тот же контент оказывается доступен через несколько адресов.

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

Как проверить WWW или без WWW на сайте

Начните не с настроек CMS, а с фактических HTTP-ответов. Возьмите главную и несколько внутренних страниц разных типов: статью, категорию, услугу, карточку товара.

Например:

curl -I https://www.example.com/catalog/item/
curl -I https://example.com/catalog/item/

Если основным выбран адрес без WWW, нормальный сценарий для альтернативного хоста выглядит примерно так:

HTTP/2 301
location: https://example.com/catalog/item/

А конечный URL уже должен отдавать рабочую страницу:

HTTP/2 200

Далее проверьте пять вещей:

1. rel="canonical" указывает на тот же вариант хоста, который выбран основным.
2. В XML Sitemap находятся канонические URL, а не смесь WWW и non-WWW.
3. Внутренние ссылки ведут сразу на основной вариант без промежуточного редиректа.
4. В Google Search Console для важных страниц выбранная Google каноническая версия соответствует ожидаемой.
5. В Яндекс Вебмастере главным определяется тот адрес, который вы действительно хотите показывать в поиске.

Для Search Console есть полезный нюанс. Domain property охватывает протоколы и поддомены, включая WWW и вариант без него, тогда как URL-prefix property привязана к конкретному префиксу. Поэтому при диагностике важно понимать, какой тип ресурса вы открыли: агрегированные данные домена не означают, что обе версии страниц настроены правильно.

Как правильно настроить основной адрес

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

Например, если конечный адрес — https://example.com, HTTP-запросы можно сразу направлять туда:

server {
    listen 80;
    server_name example.com www.example.com;

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

Для HTTPS-версии альтернативного WWW-хоста нужен отдельный доступный TLS-контур, способный принять соединение до выполнения редиректа:

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

    ssl_certificate     /path/to/fullchain.pem;
    ssl_certificate_key /path/to/privkey.pem;

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

Основной виртуальный хост example.com после этого обслуживает конечные страницы с кодом 200.

Здесь важна последовательность. Не стоит строить цепочку:

http://www.example.com/
→ http://example.com/
→ https://example.com/

Если архитектура позволяет, исходный вариант лучше сразу отправить на конечный канонический HTTPS-адрес.

Если одновременно меняется и протокол, тема https seo ru становится отдельным слоем миграции: нужно проверить сертификаты, HTTP→HTTPS, содержимое Sitemap, внутренние ссылки и отсутствие смешанных сигналов.

rel="canonical" при этом не следует рассматривать как замену серверному редиректу для двух взаимозаменяемых хостов. Он помогает поисковой системе понять предпочтительный URL, но не переводит на него пользователя и не устраняет доступность альтернативного адреса.

Практический сценарий: стоит ли убирать WWW с работающего сайта

Представим проект, который несколько лет работает на https://www.example.com. В индексе находятся URL с WWW, внутренние ссылки используют тот же вариант, Sitemap согласован, внешние сайты преимущественно ссылаются на него.

Владелец хочет перейти на адрес без WWW только потому, что тот выглядит короче.

В такой ситуации технической SEO-проблемы пока нет. Наоборот, её можно создать самой миграцией. Google предупреждает, что при существенном изменении URL возможны временные колебания, пока новые адреса повторно обходятся и обрабатываются.

Если бизнес-причины всё же есть, переход выполняют как миграцию: заранее обеспечивают доступность обоих хостов по HTTPS, настраивают соответствие URL один к одному, обновляют canonical, Sitemap и внутренние ссылки, а затем контролируют индексацию.

При простой смене www.example.com на example.com Google не требует Change of Address в Search Console. У Яндекса другой рабочий процесс: для переезда с WWW и обратно существует соответствующий сценарий в Яндекс Вебмастере.

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

Ошибки, из-за которых выбор хоста превращается в SEO-проблему

Самая очевидная ошибка — обе версии возвращают 200 OK, а каждая страница ссылается через canonical на себя. Владелец фактически сообщает, что оба адреса самостоятельны.

Вторая проблема — массовое перенаправление всех внутренних URL альтернативного хоста на главную. Правильное соответствие должно сохранять путь: старая страница переезжает на эквивалентную новую страницу.

Третья — цепочки редиректов, когда WWW сначала меняется на non-WWW, затем HTTP на HTTPS или наоборот. Такие переходы обычно можно свести к одному.

Четвёртая — альтернативный HTTPS-хост настроен только как редирект, но сертификат его не покрывает. TLS-соединение устанавливается раньше HTTP-перенаправления, поэтому пользователь может получить ошибку ещё до того, как сервер отправит 301.

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

Что считать нормальной настройкой

Для нового сайта выбор WWW или без WWW можно делать исходя из удобства бренда и инфраструктуры. Отдельного подтверждённого SEO-бонуса у одного из вариантов нет.

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

Если всё это уже работает, менять WWW только ради внешнего вида URL обычно незачем. Если смена действительно нужна, относитесь к ней как к миграции адресов и подтверждайте результат по HTTP-ответам, каноникализации и данным поисковых систем, а не по тому, какой вариант кажется «более SEO».