# www. y dominio Apex, ¿por qué deberíamos unificarlos? (La importancia de las redirecciones 301/308)


¿Ha observado detenidamente los navegadores modernos como Chrome, Edge o Safari últimamente? Si introduce `www.naver.com` o `www.google.com` en la barra de direcciones, notará que el `www` desaparece en algún momento, dejando solo el dominio principal (Dominio Apex). Incluso los dominios `m.` para móviles suelen ocultarse.

Esto se debe a la política de ocultación de **"subdominios triviales"** adoptada por los navegadores modernos para visualizar la barra de direcciones de forma más limpia. Desde la perspectiva del usuario, una dirección más corta puede resultar cómoda, pero como desarrollador web, es crucial ir un paso más allá. Esto se debe a que **"lo que el navegador oculta a la vista"** y **"lo que realmente funciona como un dominio separado"** son cuestiones completamente distintas.


![Flujo de comparación antes y después de aplicar la redirección](/media/whitedec/blog_img/77ecb43d3845413385e9e0ebf6cc351f.webp)


## DNS y los bots de búsqueda ven el 'www' con claridad {#sec-e0d49c76d3ea}

Para el proceso de DNS real o para los [[robots de los motores de búsqueda]] (como Googlebot), `www.example.com` y `example.com` son destinos estrictamente diferentes. Si ambas direcciones devuelven una respuesta `200 OK` y muestran el mismo contenido, es técnicamente como si se estuvieran operando dos sitios con 'contenido duplicado'.

Verifiquemos directamente cómo las empresas de TI globales resuelven este problema utilizando el comando `curl`.

**1. Caso de Yahoo Japan**
```bash
$ curl -I https://yahoo.co.jp/
HTTP/2 301 
location: https://www.yahoo.co.jp:443/
...
```
Yahoo Japan, al acceder a su dominio Apex, envía una redirección `301 Moved Permanently` a la dirección con `www`.

**2. Caso de 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 hace lo mismo. Al acceder a `google.com`, redirige a `www.google.com`, y finalmente, solo el dominio `www` devuelve una respuesta `200`.

## ¿Por qué es imprescindible redirigir a uno de los dos? {#sec-cf467e61a55d}

No es simplemente por una cuestión de "apariencia más limpia". Hay razones claras de SEO (optimización para motores de búsqueda) y de eficiencia operativa.

### 1. Límites de la etiqueta Canonical {#sec-9531d19b126b}
Muchos desarrolladores piensan que basta con configurar la etiqueta `<link rel="canonical" href="...">`. Sin embargo, la etiqueta canonical es solo una "pista" para los motores de búsqueda. El hecho de que los robots tengan que rastrear ambas URLs no cambia, y en este proceso, se desperdicia el **presupuesto de rastreo (Crawl Budget)**. Es como si el robot estuviera rastreando 'copias' de artículos ya existentes en lugar de indexar contenido nuevo de su sitio.

### 2. Dispersión del Link Juice {#sec-c445aae506c3}
Cuando otros sitios web enlazan a su contenido, algunos lo hacen con `www` y otros sin él. Si no se gestiona la redirección, la autoridad que debería acumular esa página se dispersa entre los dos dominios, lo que resulta en una desventaja en la competencia por el ranking de búsqueda.

---

## Solución: Redirección forzada a nivel de servidor web {#sec-e499a7960796}

Este procesamiento es más eficiente cuando se realiza a nivel de **servidor web (infraestructura)** como [[Nginx]] o Apache, en lugar de a nivel de código de aplicación (Django, Node.js, etc.). Redirigir la solicitud directamente desde el servidor antes de que llegue a la aplicación consume menos recursos y es más rápido.

A continuación, se muestra un ejemplo de configuración de Nginx para unificar todas las solicitudes al dominio Apex (`https://example.com`) cuando se opera `example.com`. (Si desea unificar a www, solo necesita cambiar la dirección de destino).

```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. Lógica de servicio real (Apex HTTPS 200 OK)
server {
    listen 443 ssl http2;
    server_name example.com;
    # ... configuración de servicio y Proxy Pass, etc.
}
```

> **Tip:** La razón por la que se utiliza el código de estado `308` en lugar de `301` es que `308 Permanent Redirect` es más seguro en el entorno web moderno, ya que mantiene el método HTTP (POST, PUT, etc.) sin cambios durante la redirección.

## Conclusión {#sec-ad06e7ff5f93}

Que el navegador oculte la dirección no significa que el servidor deba ignorarlo. Si sus dominios `www` y `Apex` coexisten y ambos devuelven `200`, verifique la configuración de su servidor web de inmediato. Una redirección clara a uno de los dos es la tarea más fundamental e importante para comunicar la identidad de su sitio a los motores de búsqueda.