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

Короткий ответ: для SEO не важно, есть ли у домена www. Важно выбрать один окончательный адрес и привести к нему остальные варианты. Если основным выбран https://example.ru/, то HTTP, HTTPS и адреса с www должны сразу направлять пользователя на соответствующую страницу этого хоста. Внутренние ссылки, canonical, sitemap.xml и внешние настройки тоже должны использовать один вариант.

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

Почему две версии сайта создают проблему

У домена может быть четыре точки входа:

• http://example.ru/;
• http://www.example.ru/;
• https://example.ru/;
• https://www.example.ru/.

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

Типичная картина: карта сайта собрана без www, в меню стоят ссылки с www, а canonical ведёт на третий вариант. Владельцу тогда сложнее проверять индексацию и поддерживать сайт.

Главное зеркало - единственный публичный адрес в навигации и метаданных. Другие варианты принимают старые переходы и перенаправляют на ту же страницу основного хоста.

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

Что лучше: с WWW или без WWW

Единственно правильного формата нет. Важнее стабильный конечный адрес и отсутствие противоречий между сигналами.

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

Перед решением ответьте на три вопроса:

1. Какой адрес уже стоит в меню, рекламе, профилях и письмах?
2. На какой хост ведут значимые внешние ссылки и приходят поисковые переходы?
3. Есть ли техническая или деловая причина менять текущую схему?

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

Смена зеркала - это перенос. Не объединяйте его без необходимости с массовой сменой URL: так проще найти источник сбоя.

Как определить действующее зеркало

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

Проверка страниц и редиректов

Возьмите главную, услугу, статью, категорию, карточку товара, если она есть, и заведомо несуществующий путь. Откройте каждый адрес в вариантах HTTP/HTTPS и с www/без www. Для каждого запроса зафиксируйте:

• первый код ответа;
• конечный адрес;
• число переходов;
• код финальной страницы;
• canonical на финальной странице.

Нормальная схема: альтернативный вариант отдаёт один постоянный редирект, финальная HTTPS-страница отвечает 200. Повод разобраться - две версии с 200, потеря пути, цепочка или цикл.

Чтобы корректно читать статусы, используйте материал о кодах HTTP 200, 301, 404 и 5xx. Проверять нужно не только главную: правило может работать для корня, но ошибаться на статьях или URL со слешем.

Проверка сигналов внутри сайта

На конечных страницах посмотрите canonical, меню, хлебные крошки, связанные статьи, Open Graph и структурированные данные. Они должны использовать один хост. Проверьте и sitemap.xml: в ней должны быть только финальные индексируемые URL с кодом 200. Порядок работы с этими файлами описан в статье про sitemap.xml, robots.txt и canonical.

Затем посмотрите аналитику, рекламу и интеграции: они покажут, какой адрес уже используется.

Пошаговый план настройки

1. Запишите итоговый формат URL

Зафиксируйте протокол, хост, правило завершающего слеша, регистр путей и параметры. Например: https://example.ru/service/. Это ориентир для настройки и контроля.

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

2. Подготовьте DNS и сертификат

Оба хоста должны разрешаться в DNS, чтобы сервер принял запрос и отдал редирект. Если альтернативное имя не открывается, перехода не будет.

Сертификат должен покрывать основной и альтернативный хост. Защищённое соединение устанавливается до HTTP-редиректа, поэтому предупреждение появится раньше перехода.

Не удаляйте DNS-запись альтернативного варианта: старые ссылки могут оставаться в закладках, письмах и документах.

3. Настройте прямой постоянный редирект

Каждый URL альтернативного хоста ведёт на тот же путь основного. Настройка зависит от веб-сервера, CDN и платформы, поэтому проверьте правило на типовых URL.

Ожидаемая логика:

• HTTP с www сразу ведёт на HTTPS без www, если основным выбран этот хост;
• HTTPS с www ведёт на такой же путь без www;
• конечная страница отдаёт 200;
• несуществующий путь после нормализации остаётся 404, а не превращается в главную.

Избегайте цепочек: неосновной вход лучше сразу направлять на окончательный URL.

4. Уберите старый хост из навигации

Редирект нужен для старых ссылок, но не для кликов на сайте. Меню, карточки, футер, хлебные крошки и связанные материалы ведут сразу на основной домен. Проверьте абсолютные URL в шаблонах, письмах, фидах и API. Для проверки связей между страницами пригодится материал о внутренней перелинковке.

5. Согласуйте canonical, sitemap и разметку

У индексируемой страницы на основном хосте canonical обычно указывает на её собственный итоговый URL. Sitemap.xml содержит только эти адреса. В Open Graph и JSON-LD тоже используйте выбранный домен.

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

6. Проверьте внешние настройки и путь пользователя

Обновите основной URL в аналитике, кабинетах вебмастеров, рекламе, профилях, CRM, коллтрекинге и webhook-настройках. Для форм и авторизации проверьте разрешённые источники, CORS, callback URL и cookies.

После проверки статусов пройдите путь как посетитель: откройте альтернативный адрес, перейдите на услугу, отправьте тестовую заявку. Страница может открываться правильно, а форма - оставаться привязанной к старому хосту.

Практический сценарий

Представим сайт услуг, доступный по https://example.ru/ и https://www.example.ru/. Обе версии отвечают 200. В sitemap уже стоят URL без www, реклама использует короткий адрес, но часть меню и canonical всё ещё ведёт на www.

Команда выбирает вариант без www, потому что он уже есть в важных точках. Затем проверяет DNS и сертификат, настраивает прямой редирект с www на те же пути, обновляет шаблоны и карту сайта.

Сценарий не обещает рост трафика или позиций. Его цель - убрать неоднозначность и оставить один понятный адрес.

Частые ошибки

Обе HTTPS-версии отвечают 200

Canonical может быть полезным сигналом, но две доступные копии остаются. Нужны единое правило редиректа и замена старого хоста во внутренних сигналах.

Все старые URL отправляют на главную

Человек не получает нужную страницу. Если есть прямой аналог, перенаправляйте на него. Если нет - выберите близкую замену или оставьте честный 404/410.

Цепочки и циклы

Отдельные правила для протокола, www, слеша и регистра могут конфликтовать. Проверьте все комбинации и сведите нормализацию к одному понятному маршруту.

Сертификат только на основном хосте

Посетитель альтернативного HTTPS-адреса увидит ошибку до редиректа. Покрытие обоих имён сертификатом - условие нормального перехода.

Забыты формы и интеграции

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

Зеркало меняют без причины

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

Чек-лист

• Выбран один полный формат основного URL.
• Учтены текущие ссылки, реклама и рабочие настройки.
• Оба хоста доступны через DNS.
• Сертификат покрывает оба хоста.
• Каждый альтернативный URL делает один прямой постоянный переход.
• Путь сохраняется; массового редиректа на главную нет.
• Финальные страницы отвечают 200, несуществующие - 404 или 410.
• Внутренние ссылки, canonical, Open Graph и разметка используют основной хост.
• Sitemap.xml содержит только финальные URL.
• Проверены аналитика, формы, авторизация и интеграции.
• Тестовая заявка или другой ключевой сценарий пройден.
• После запуска контролируются ошибки и остаточные ссылки.

FAQ

Влияет ли наличие WWW на позиции?

Само по себе - нет. Важны один основной адрес, прямые редиректы и согласованные ссылки, canonical и sitemap.

Можно ли оставить обе версии и поставить canonical?

Для одного сайта это ненадёжная схема. Canonical не перенаправляет пользователя и не исправляет навигацию. Если вторая версия не нужна отдельно, настройте редирект.

Какой код использовать для выбора зеркала?

Используйте постоянный редирект, который поддерживает инфраструктура. После настройки проверьте ответ сервера, число переходов и конечный URL.

Нужно ли добавлять обе версии в sitemap.xml?

Нет. В карте должны быть только канонические финальные URL основного хоста с кодом 200.

Нужно ли запрещать альтернативный хост в robots.txt?

Нет. Запрет обхода не нужен для редиректа и может помешать роботу увидеть перенаправление. Основной инструмент выбора зеркала - серверный редирект.

Как долго держать редирект?

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

Что делать, если после смены появились проблемы с трафиком?

Проверьте DNS, сертификат, коды, цепочки, сохранение путей, canonical, sitemap и внутренние ссылки. Затем формы и данные в кабинетах. Не меняйте всё одновременно: сначала найдите расхождение.

Итог

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

Если хотите разобрать зеркала, редиректы и индексацию применительно к своему проекту, напишите в Telegram. Для подготовки структуры, черновиков и FAQ под редакторским контролем можно использовать XelaGroup.