Зачем объединять домены www и Apex? (О важности 301/308 редиректов)

Вы обращали внимание на то, как ведут себя современные браузеры, такие как Chrome, Edge или Safari? Введите в адресную строку www.naver.com или www.google.com, и вы заметите, что через мгновение www исчезает, оставляя только корневой домен (Apex Domain). Иногда даже префикс m. для мобильных версий сайтов скрывается.

Это результат политики современных браузеров по скрытию «тривиальных поддоменов» (Trivial Subdomains), призванной сделать адресную строку более лаконичной. Хотя для пользователей короткий адрес может быть удобным, веб-разработчикам необходимо смотреть глубже. Ведь «то, что браузер скрывает», и «то, что на самом деле функционирует как отдельный домен» — это две совершенно разные вещи.

Изображение, сравнивающее поток до и после применения редиректа

DNS и поисковые роботы прекрасно видят 'www'

Для реального процесса обработки DNS и поисковых роботов (например, Googlebot) www.example.com и example.com — это совершенно разные пункты назначения. Если оба адреса возвращают ответ 200 OK и отображают идентичный контент, это технически означает, что у вас работают два сайта с 'дублирующимся контентом'.

Давайте на примере команды curl посмотрим, как крупные IT-компании решают эту проблему.

1. Пример Yahoo Japan

$ curl -I https://yahoo.co.jp/
HTTP/2 301 
location: https://www.yahoo.co.jp:443/
...

При доступе к Yahoo Japan через Apex домен, происходит 301 Moved Permanently редирект на адрес с www.

2. Пример Google

$ curl -I https://google.com/
HTTP/2 301 
location: https://www.google.com/
...

$ curl -I https://www.google.com/
HTTP/2 200 
...

Google поступает аналогично. При переходе на google.com он перенаправляет на www.google.com, и только с домена www в конечном итоге возвращается ответ 200 OK.

Почему обязательно нужно выполнять редирект на один из доменов?

Дело не только в том, что это 'выглядит аккуратнее'. За этим стоят веские причины, связанные с SEO (поисковой оптимизацией) и операционной эффективностью.

1. Ограничения Canonical Tag

Многие разработчики ошибочно полагают, что установка тега <link rel="canonical" href="..."> полностью решает проблему. Однако канонический тег — это лишь «подсказка» для поисковых систем. Это не отменяет того факта, что роботам все равно приходится сканировать оба URL, и в этом процессе бюджет сканирования (Crawl Budget) расходуется впустую. Получается, что вместо индексации новых материалов на вашем сайте, роботы тратят время на сканирование «копий» уже существующих страниц.

2. Распределение Link Juice

Когда другие сайты ссылаются на ваш контент, одни используют www, другие — нет. Если редирект не настроен, авторитет (Authority), который должна накапливать страница, будет распределяться между двумя разными доменами. Это ослабляет ваши позиции в конкурентной борьбе за высокие места в поисковой выдаче.

Решение: Принудительный редирект на уровне веб-сервера

Эту обработку наиболее эффективно выполнять не на уровне кода приложения (Django, Node.js и т.д.), а на уровне веб-сервера (инфраструктуры), такого как Nginx или Apache. Перенаправление запроса непосредственно на сервере, до того как он достигнет приложения, потребляет меньше ресурсов и происходит значительно быстрее.

Ниже представлен пример конфигурации Nginx, который унифицирует все запросы к Apex домену (https://example.com) при работе с example.com. (Если требуется унифицировать на www, достаточно просто изменить целевой адрес.)

# 1. www (HTTP) -> Apex (HTTPS)
server {
    listen 80;
    listen [::]:80;
    server_name www.example.com;
    return 308 https://example.com$request_uri;
}

# 2. www (HTTPS) -> Apex (HTTPS)
server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name www.example.com;

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

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

# 3. Apex (HTTP) -> Apex (HTTPS)
server {
    listen 80;
    listen [::]:80;
    server_name example.com;
    return 308 https://example.com$request_uri;
}

# 4. 실제 서비스 로직 (Apex HTTPS 200 OK)
server {
    listen 443 ssl http2;
    server_name example.com;
    # ... 서비스 설정 및 Proxy Pass 등
}

Совет: Причина использования кода состояния 308 вместо 301 заключается в том, что 308 Permanent Redirect более безопасен в современной веб-среде, так как он сохраняет HTTP-метод (POST, PUT и т.д.) без изменений при перенаправлении.

Заключение

Тот факт, что браузер скрывает адрес, не означает, что сервер должен бездействовать. Если домены www и Apex сосуществуют и оба возвращают статус 200 OK, немедленно проверьте настройки вашего веб-сервера. Надежный редирект на один из них — это базовая, но крайне важная задача для четкого определения идентичности вашего сайта для поисковых систем.