Esta página está destinada a los Web Masters que buscan información sobre si usar o no www en sus URL del sitio web canónico.

Primero, un poco de terminología. El nombre de dominio sin www a veces se conoce como un dominio desnudo, y me referiré a él como tal aquí.

¿Por qué debería usar www?

Debe utilizar www porque hoy tienes un pequeño sitio web, y mañana quieres un gran sitio Web. Muy grande.

Las razones técnicas para utilizar www principalmente se aplican a los sitios web más grandes que reciben millones (o más) de vistas de página por día, sitios web con un gran número de servicios a través de varios subdominios, y prácticamente cualquier sitio web alojado en "la nube" por un proveedor de servicios de aplicaciones.

Heroku, por ejemplo, recomienda encarecidamente contra el uso de dominios desnudos. Cuando se utiliza un proveedor como Heroku o Akamai para hospedar su sitio web, el proveedor desea poder actualizar los registros DNS en caso de que necesite redirigir el tráfico de un servidor que falle a un servidor sano. Se configura mediante registros DNS CNAME y el dominio desnudo no puede tener un registro CNAME. Esto es sólo un problema si su sitio obtiene lo suficientemente grande como para requerir un hosting altamente redundante con un servicio de este tipo. Pero, ¿quién no quiere que su sitio para conseguir tan grande? Para no utilizar www, tendrá que ejecutar sus propias granjas de servidores y no podrá utilizar dichos servicios en su máxima medida. (Véase también: ¿Por qué Heroku advierte contra nombres de dominio "desnudos"?)

Otra razón tiene que ver con las galletas. Una optimización del sitio web común es servir contenido estático de un subdominio, como static.example.com. Si está utilizando www, entonces esto no es ningún problema; las cookies de su sitio no se enviarán a la static subdominio (a menos que se hayan configurado explícitamente para hacerlo). Si utiliza el dominio desnudo, las cookies se envían a todos los subdominios (por los navegadores recientes que implementan RFC 6265), ralentizando el acceso al contenido estático y posiblemente causando que el almacenamiento en caché no funcione correctamente. La única manera de solucionar este problema y mantener el dominio desnudo es comprar un segundo nombre de dominio sólo para su contenido estático. Twitter, por ejemplo, que no utiliza www, tenía que comprar nuevos nombres de dominio sólo para contenido estático. Por supuesto, si usted comparte explícitamente sus cookies en todos sus subdominios, por ejemplo, para implementar un solo signo-on a través de varios servicios en los subdominios de su sitio (Google hace esto), entonces usted también tendría que comprar un nuevo nombre de dominio en esta circunstancia de todos modos. (Véase también: ¿Cuál es el punto de tener "www" en una URL?)

Hablando de cookies, si decide utilizar el dominio desnudo, pero quiere poner los servicios en los subdominios y compartir las cookies entre ellos, rápidamente se enterará de que no funciona bien en todos los casos a menos que tenga un subdominio establecer la cookie-y entonces no funciona para el na dominio KED. La solución para esto es utilizar RFC 6265 (anteriormente RFC 2965) cookies, que se pueden compartir entre el dominio desnudo y los subdominios, pero algunos paquetes de aplicaciones web populares todavía no implementan RFC 2965 correctamente o en absoluto, por no hablar de RFC 6265. (Véase también: ¿Puede subdomain.example.com establecer una cookie que pueda ser leída por example.com?)

Es posible que no se haya topado con ninguno de estos problemas hoy en día, pero a medida que su sitio web crezca, eventualmente lo hará. Usando www hoy en día y en el futuro te hace más preparado para manejar los desafíos de crecer un sitio web más allá de un solo servidor. Se puede hacer sin usar www en muchas circunstancias, pero es mucho más fácil con.

¿Debo redirigir no-www a www?

Sí.

El redireccionamiento garantiza que los visitantes que ingresen su URL le alcancen independientemente de la forma que utilicen, y también aseguran que los buscadores indexan correctamente sus URLs canónicas.