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

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

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


![Изображение, сравнивающее поток до и после применения редиректа](/media/whitedec/blog_img/77ecb43d3845413385e9e0ebf6cc351f.webp)


## DNS и поисковые роботы прекрасно видят 'www' {#sec-e0d49c76d3ea}

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

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

**1. Пример Yahoo Japan**
```bash
$ 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**
```bash
$ 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`.

## Почему обязательно нужно выполнять редирект на один из доменов? {#sec-cf467e61a55d}

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

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

### 2. Распределение Link Juice {#sec-c445aae06c3}
Когда другие сайты ссылаются на ваш контент, одни используют `www`, другие — нет. Если редирект не настроен, авторитет (Authority), который должна накапливать страница, будет распределяться между двумя разными доменами. Это ослабляет ваши позиции в конкурентной борьбе за высокие места в поисковой выдаче.

---

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

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

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

```nginx
# 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 и т.д.) без изменений при перенаправлении.

## Заключение {#sec-ad06e7ff5f93}

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