www, dominio raíz y wildcard forwarding sin romper SEO
Normalizar el host parece simple hasta que raíz, www, subdominios, rutas y query strings obedecen reglas distintas. Una policy clara mantiene estable la URL canónica.
Normalizar un host parece una tarea menor hasta que recibe tráfico real.
Una marca usa dominio raíz. El sitio viejo usa www. Una tienda, blog o landing vive en un subdominio. Una agencia pide wildcard forwarding. Un link de campaña todavía necesita conservar path y UTMs. Si esas decisiones se toman por separado, aparece una cadena de redirects.
La discusión no es si www o raíz es siempre mejor. La discusión es cuál será el host canónico y cómo lo seguirán las demás variantes.
Si esto forma parte de una migración mayor, empieza por la checklist de redirects para migración de sitio. Este artículo se enfoca en la capa de host.
El host es parte de la policy de URL
example.com, www.example.com y *.example.com no son iguales en operación.
- El dominio raíz se ve limpio en marketing.
wwwpuede ser práctico en stacks antiguos.- Un subdominio puede ser producto, docs, soporte o tienda.
- Wildcard forwarding ayuda cuando muchos hosts comparten regla.
Lo importante es elegir una forma canónica y hacer que las demás la sigan.
Decide el host canónico antes del lanzamiento
Responde temprano:
| Pregunta | Por qué importa |
|---|---|
¿El sitio vive en raíz o www? | Define la URL canónica visible |
| ¿Qué subdominios son alias? | Algunos subdominios no deben fusionarse |
| ¿Las rutas se preservan? | SEO, favoritos y deep links dependen de eso |
| ¿Las query strings sobreviven? | UTMs, cupones e IDs pueden perderse |
| ¿Hay excepciones temporales? | Campañas y lanzamientos pueden necesitar otra lógica |
Si las respuestas quedan abiertas, varios sistemas intentarán ayudar a la vez.
DNS no resuelve toda la policy
DNS indica dónde enviar tráfico. No decide por sí solo el cambio visible de URL.
Modelo limpio:
http://www.marca-vieja.example/precios?utm_source=email
-> https://marca-nueva.example/precios?utm_source=emailModelo frágil:
http://www.marca-vieja.example/precios
-> https://www.marca-vieja.example/precios
-> https://marca-vieja.example/precios
-> https://marca-nueva.example/preciosUn hop es más fácil de auditar y mantener.
Wildcard forwarding funciona si la estructura acompaña
Una regla wildcard ayuda cuando los paths siguen alineados:
old.example.com/* -> new.example.com/$1Sirve cuando:
- hay muchas URLs viejas que conservar
- la estructura no cambió demasiado
- no quieres escribir una regla por página
- los subdominios son alias reales
Si la arquitectura cambió mucho, las URLs con tráfico y ranking necesitan mappings explícitos.
Preserva path y query cuando el link todavía importa
La normalización de host no debe borrar el contexto.
http://old.example.com/docs/api?ref=partner&utm_source=newsletterdebería terminar, si corresponde, en:
https://new.example.com/docs/api?ref=partner&utm_source=newsletterEso importa para:
- páginas SEO
- documentación
- campañas pagadas
- afiliados
- links guardados por usuarios
Si el path o la query desaparecen, el redirect puede verse correcto y aun así perder valor.
Evita la cadena
El error común es repartir responsabilidades:
- HTTP a HTTPS en un lugar
wwwa raíz en otro- cambio de dominio en CDN o hosting
- app agrega una regla canónica más
Resultado: http -> https -> www -> final.
Si tu stack ya tiene esa forma, revisa Redirect chains and loops.
Matriz de QA antes de mover tráfico
Prueba variantes reales:
| Test | Ejemplo |
|---|---|
| Raíz | https://example.com/ |
www | https://www.example.com/ |
| Path profundo | https://example.com/precios |
| Path con query | https://example.com/precios?utm_source=email |
| Host viejo con path | https://old.example.com/blog/post-1 |
| Subdominio wildcard | https://docs.example.com/guide |
Confirma:
- host final correcto
- path preservado
- query preservada
- status code adecuado
- sin hop extra
Dónde encaja UrlEdge
UrlEdge ayuda cuando la normalización de host debe manejarse como policy de routing, no como snippet suelto.
- Free Redirect Service para HTTPS automático y wildcard forwarding
- Advanced Redirect Rules para lógica condicional
- Redirect Checker para inspeccionar hops reales
- Redirigir dominio sin perder path ni query para el patrón completo
La ventaja es tener un lugar responsable del host canónico, las variantes, paths, queries y status codes.
FAQ
¿Siempre conviene usar raíz en lugar de www?
No. Ambos pueden funcionar. Lo importante es elegir uno como canónico y hacer que las demás variantes lo sigan.
¿Puedo cubrir subdominios wildcard con una regla?
Sí, si la estructura sigue alineada. Si cambió mucho, usa mappings explícitos para las URLs importantes.
¿DNS alcanza?
No. DNS no reemplaza una policy HTTP de redirect visible para el usuario.
¿Debo preservar parámetros de campaña?
Normalmente sí, salvo que tengas una razón explícita para borrarlos. La atribución perdida es difícil de recuperar.
Referencias
Define el host canónico una sola vez
Redirige raíz, www y subdominios wildcard con HTTPS automático, preservación de ruta y un destino canónico.
Probar Free Redirect ServiceArtículos relacionados
Ver todo
Link firewall para tráfico paid y afiliados: bots, proxys y clics malos
No todo clic malo es fraude, pero todo clic malo puede costar presupuesto, atribución o comisiones. Un link firewall decide qué debe pasar antes de que el tráfico llegue al destino.
Servir archivos de verificación en el edge: ads.txt, security.txt, AASA y assetlinks.json
Algunos archivos deben vivir en la raíz o bajo /.well-known/. Si tu CMS o tienda no los maneja bien, una respuesta edge puede servirlos con status y Content-Type correctos.