Configuración de redirecciones 301 a nivel de DNS vs servidor web

Las redirecciones 301 son una herramienta fundamental para migraciones, canonicalización de dominios y preservación de SEO. Sin embargo, existe confusión sobre si deben configurarse a nivel de DNS o en el servidor web. En este artículo analizo, desde la infraestructura y el SEO técnico, qué hace cada opción, limitaciones, ejemplos prácticos y una checklist para elegir la mejor estrategia.

Qué es una redirección 301 y dónde se ejecuta

Una redirección 301 es un código de estado HTTP que indica que un recurso ha sido trasladado de forma permanente a otra URL. El comportamiento y la interpretación por parte de navegadores y motores de búsqueda están definidos por el protocolo HTTP. Para entender las capas involucradas conviene distinguir:

• DNS: resuelve nombres de dominio a direcciones/IP o gestiona registros especiales (A, AAAA, CNAME, ALIAS). DNS opera en la capa de resolución y no conoce estados HTTP.
• Servidor web / CDN / proxy: maneja solicitudes HTTP/HTTPS y puede responder con códigos 301 desde la capa de aplicación.

En consecuencia, una redirección 301 estrictamente hablando no puede ser realizada por un servidor DNS puro sin soporte adicional: el DNS no emite respuestas HTTP. No obstante, proveedores DNS y CDNs ofrecen mecanismos que imitan redirecciones al combinar resolución DNS con servicios de HTTP.

Redirecciones “a nivel de DNS”: qué son y cuándo aparecen

Cuando se habla de redirecciones a nivel de DNS, normalmente se hace referencia a uno de estos escenarios:

• Uso de registros CNAME/ALIAS para apuntar un dominio a otro (esto no devuelve 301, solo resuelve la dirección).
• Servicios gestionados por proveedores DNS/CDN que ofrecen un “HTTP redirect” como característica, donde su infraestructura HTTP responde con 301/302 en nombre del dominio.
• Reglas en la configuración de una CDN (Cloudflare, por ejemplo) que interceptan la petición y devuelven una redirección.

Ventajas de este enfoque:

• Simples de configurar desde el panel DNS sin acceso al servidor de origen.
• Útiles para redirigir un dominio entero (ej. domain-old.com → domain-new.com) sin gestionar servidores.
• Rápida propagación de la regla en la red del proveedor, con baja latencia si el proveedor tiene una red global.

Limitaciones:

• No es una funcionalidad del protocolo DNS puro; depende del proveedor. Si migras de proveedor, debes replicar la regla.
• Control limitado sobre cabeceras, cookies o lógica por URL. Para redirecciones complejas por rutas, parámetros o condiciones, el servidor web es más flexible.
• Si la redirección no soporta HTTPS adecuadamente (certificados para el dominio origen), puede haber errores de seguridad o bloqueos por HSTS.

Para documentación de cómo funcionan las redirecciones a nivel de CDN, revisa la documentación de Cloudflare: Cloudflare Docs y su sección sobre page rules y redirects.

Redirecciones a nivel de servidor web (Apache / NGINX)

El servidor web es el lugar natural para emitir una redirección HTTP. Ahí puedes devolver un 301 con control total sobre la URL destino, cabeceras, condiciones por user-agent, cookies o respuestas dinámicas.

Ejemplos prácticos

• Apache (archivo .htaccess o configuración virtualhost):

  Redirect 301 /old-page https://example.com/new-page

• NGINX (bloque server):

  server {\n    listen 80;\n    server_name old.example.com;\n    return 301 https://new.example.com$request_uri;\n}

La ventaja técnica principal es la flexibilidad: puedes redirigir rutas específicas, conservar query strings, condicionar por encabezados y mantener control de certificados TLS en servidores que gestionan HTTPS. NGINX documenta buenas prácticas de rewrite y redirects en su sitio: NGINX.

Comparativa técnica y efecto en SEO

Desde el punto de vista de los motores de búsqueda, lo relevante es que el cliente HTTP reciba un 301 permanente y siga la redirección. Los factores que afectan al SEO incluyen:

• Latencia y disponibilidad: redirects rápidos y fiables preservan mejor la experiencia y evitan pérdida de rastreo.
• Cadenas de redirección: cada salto puede consumir presupuesto de rastreo y diluir señales de enlace. Evita múltiples 301 encadenados.
• HTTPS y certificados: si la redirección interrumpe la conexión segura (por ejemplo, al no servir cert válido en el dominio origen) puede provocar que el bot no siga la redirección.
• Consistencia de host (www vs sin www) y canonicalización: redireccionar consistentemente evita contenido duplicado.

En la práctica, una redirección gestionada por un CDN/DNS que devuelve correctamente 301 sobre HTTPS es equivalente para SEO a una hecha en el servidor, siempre que cumpla estos puntos. Para entender el comportamiento HTTP considera consultar la referencia de códigos de estado en MDN Web Docs.

Casos de uso y recomendaciones

Usar redirecciones a nivel DNS/CDN cuando:

• No tienes acceso al servidor de origen (sitios antiguos, dominios que abandonas).
• Rediriges un dominio completo a otro sin reglas por ruta.
• Necesitas una solución rápida administrada desde el panel DNS con alta disponibilidad.

Usar redirecciones a nivel servidor cuando:

• Necesitas lógica por ruta, parámetros o condiciones avanzadas (por ejemplo, migraciones parciales).
• Gestionas certificados TLS y quieres controlar HSTS/OCSP/headers de seguridad.
• Deseas minimizar pasos intermedios y mantener la lógica junto a la aplicación (WordPress, frameworks, etc.).

Checklist práctica para implementar 301 sin errores

• Verificar que la redirección devuelve 301 a través de curl: curl -I -L https://origen.example.com.
• Asegurar soporte HTTPS en el dominio origen (certificado válido). Si usas CDN, habilita “Full SSL” o equivalente.
• Evitar redirecciones encadenadas: planifica mapeos directos origen → destino.
• Actualizar enlaces internos y sitemap.xml para apuntar al destino definitivo.
• Comprobar en Search Console / herramientas SEO que el cambio se indexa correctamente.
• Si usas proveedores DNS/CDN, documenta la regla en tu control de cambios para cuando migres proveedor.

Ejemplo real: migración de dominio con CDN

Escenario: tienes example-old.com y quieres redirigir todo a example-new.com. Si no quieres tocar servidores, puedes:

• Apuntar los registros A/AAAA al proxy del proveedor CDN y crear una regla que devuelva 301 con destino example-new.com$request_uri.
• Habilitar HTTPS en example-old.com en el panel (obtener certificado o usar la gestión del CDN).
• Comprobar con herramientas y luego actualizar sitemaps y enlaces canónicos.

Alternativa: configurar en el servidor de origen (NGINX):

server {\n    listen 80;\n    server_name example-old.com www.example-old.com;\n    return 301 https://example-new.com$request_uri;\n}

Riesgos comunes y cómo mitigarlos

• Redirecciones mal configuradas que generan bucles: probar antes de aplicar en producción.
• Pérdida temporal de tráfico por tiempo de propagación DNS o caché CDN: planificar ventanas y notificar stakeholders.
• Errores de HTTPS: validar certificados y políticas HSTS para no bloquear bots.

Conclusión

No existe una única respuesta universal: la decisión entre redireccionar a nivel DNS/CDN o en el servidor web depende de acceso, complejidad de reglas, control sobre TLS y requisitos SEO. Para redirecciones simples y dominios enteros, un servicio DNS/CDN es rápido y fiable; para reglas por ruta, control de cabeceras o lógica avanzada, el servidor web (NGINX/Apache) es la opción correcta. En todos los casos, prioriza HTTPS válido, evita cadenas de redirección y valida el comportamiento con herramientas (curl, Search Console). Si necesitas un enfoque híbrido, combina CDN para la capa pública y servidor para la lógica interna, documentando claramente las reglas en tu inventario de infraestructura.

Fuentes y lecturas recomendadas: la referencia de códigos HTTP en MDN y la documentación de servidores como NGINX ayudan a implementar redirecciones seguras y eficientes.