Durante aproximadamente 20 años, se ha debatido si se debe usar www en el nombre de host canónico (CNAME) de su sitio web. Entonces, ¿qué usar o no?
Aunque muchas personas usan los términos "nombre de dominio" y "nombre de host" indistintamente, hay una diferencia entre ellos, y esto no es solo una cuestión de semántica. Simplificaré un poco esta descripción para centrarme en el punto.
Para usted, como administrador de TI, su dominio será su red. Es razonable darle un nombre al dominio. El sistema DNS está adaptado para esto, por lo que registra un nombre de dominio, por ejemplo,
example.com . Ahora, bajo este dominio, tendrá sus propios hosts. Cada máquina con una conexión de red se considera un host. La máquina de servicio de documentos WWW obtendrá naturalmente el nombre de host
www en su dominio, por lo que su nombre de dominio completo (FQDN) será
www.example.com . Hará lo mismo para el resto de los hosts en su red, tenga o no un servidor web. Entonces limpias tu red.
Para ir al servidor web en el dominio
example.com , debe ir al host llamado
www.example.com . Por cierto, en aquellos días en que los dinosaurios deambulaban por la Web, los hosts virtuales no existían. Cada servidor web sirvió solo un sitio web (al menos una dirección IP). El nombre de host no importaba si apuntaba a la dirección IP correcta.
"Nombre de dominio desnudo", es decir un nombre de dominio sin 'www', como
example.com , en términos de DNS, se llama origen. A medida que la World Wide Web creció en popularidad a mediados de la década de 1990, algunos administradores comenzaron a especificar la misma dirección IP que el host www como origen. Esto permite a los visitantes del sitio web ingresar solo
example.com en el navegador en lugar del nombre de host completo.
Luego vino SEO
Como
example.com y
www.example.com pueden apuntar a diferentes direcciones IP, y desde enero de 1997 a diferentes sitios web en la misma dirección IP, los especialistas en SEO comenzaron a decirnos que deberíamos elegir un nombre de host canónico, y el resto debe apuntar allí (con el código de estado HTTP 301).
Tenía sentido elegir un nombre. Pero cual? Para SEO, realmente no importa. Lo principal es tener uno. Pero además del SEO hay otros problemas. Sigue leyendo.
¿Cómo entienden las personas la URL?
Cuando trabajé en una agencia de marketing a principios de siglo, me preocupaba que la gente no entendiera que tenían la dirección de la World Wide Web frente a nosotros si omitimos la parte 'www'. Quiero decir, acabamos de empezar a omitir "http: //". Además, por razones históricas, personalmente elegí usar el nombre de host completo "correcto", es decir
www.example.com .
Hoy no creo que sea importante. La gente entenderá que esta es una dirección web, ya sea que www esté allí o no, cuando frente a ellos se encuentre un dominio de nivel superior bien conocido. Dado que una versión todavía se redirige a otra, no importa que su nombre de host canónico sea
www.example.com , y use
example.com para anuncios impresos solo por el bien de la belleza. Al mismo tiempo, si tiene uno de los miles de nuevos dominios de nivel superior como .beer, entonces tiene sentido agregar www por las mismas razones que tenía en marketing a principios de siglo.
Sin www es más simple y más hermoso.
Debo admitir que
example.com más rápido de escribir, más fácil de leer y solo ahorra espacio. Es comprensible que las personas comenzaron a abandonar www, y simplemente especificar el origen como el nombre de host canónico.
Entonces, ¿por qué siguen discutiendo sobre esto?
¿Por qué seguimos discutiendo el uso de 'www' o no? Que todos usen lo que quieran, ¿no es posible?
Por supuesto que puedes.
Pero si usted es administrador de un sitio web, entonces probablemente quiera tomar una decisión informada y pensar en algunas cosas con anticipación. Por ejemplo, las cookies.
Las cookies se pasan a subdominios
Las cookies establecidas en nombre del host también se establecerán para todos los subdominios. Es decir, si el sitio en
example.com establece una cookie, el navegador también enviará este archivo cuando visite
www.example.com . Suena bien, es el mismo sitio, ¿verdad? Pero las cookies también irán a
cdn.example.com ,
email.example.com ,
intranet.example.com ,
thirdpartyservice.example.com y así sucesivamente. Y muchos servicios de terceros le permiten usar su dominio de esta manera.
La cookie establecida desde el host
www.example.com * no * se enviará a ningún host "fraternal" como el anterior. Su navegador entiende que estos no son "subservicios", sino servicios completamente diferentes que no deberían acceder a sus cookies.
Las cookies innecesarias perjudican el rendimiento
La forma en que funcionan las cookies y HTTP es que se envían desde el navegador con cada solicitud al servidor web. Esto significa que si su sitio establece cookies para el origen (example.com), este archivo también debe enviarse para cada solicitud que realice, por ejemplo, a
email.example.com o
intranet.example.com . Esto ralentiza la conexión.
Las cookies pueden ser leídas por terceros
Entonces, si el sitio web es el mismo que origin (example.com) y usa el sistema CMS, luego de la autorización emitirá cookies a su navegador para mantener abierta la sesión. Luego, cuando visite
someinternalservice.example.com , el administrador de este servicio puede leer esta cookie, copiarla y usarla para iniciar sesión en el CMS corporativo por
example.com en su nombre. Lo mismo se aplica al proveedor de correo electrónico cuando visita
email.example.com o el proveedor de CDN que descarga recursos, como
static.example.com , etc.
Si le preocupa la seguridad de al menos algo en
example.com , asegúrese de incluir 'www' antes. Incluso si esto no te convence de usar 'www', entonces no sé qué puede convencer. Ni HTTPS ni 2FA ayudarán, ya que esta cookie es una ficha mágica. Sin embargo, otras medidas de seguridad, como
las restricciones de IP , pueden ayudar.
Las cookies de los subdominios se pueden compartir si lo desea
Si tiene un servicio en un subdominio, por ejemplo,
sso.example.com , entonces RFC 6265 le permite establecer cookies de origen y hacerlo común con
example.com o
www.example.com . Por lo tanto, abandonar el "dominio simple" como nombre de host, de hecho, le brinda más flexibilidad.
Restricción de DNS
Hablando de flexibilidad, necesitamos volver a hablar sobre DNS.
Hay una limitación en el DNS de que el origen debe ser un registro A, es decir, apuntar a una dirección IP fija.
Cuando su sitio se agrande y lo mueva a un hosting o desee dirigirlo a un firewall o un servicio de protección DDoS, use el registro CNAME para dirigir el nombre de host a otro nombre de host inconsistente, que el proveedor controla dependiendo de su tráfico y necesidades.
Pero si el sitio está alojado en un dominio desnudo (example.com), no puede hacer esto. Sin embargo, no hay problema al especificar el nombre de host con 'www' en CNAME. Entonces, si desea alguna escalabilidad, ahora o en el futuro, debe configurar el nombre de host desde 'www' desde el principio.
Conclusión: elija www
Esto es importante si usa www o no. Estoy de acuerdo en que los dominios desnudos se ven más bonitos, pero esta es solo una pregunta práctica para la barra de direcciones del navegador. Puede usar
www.example.com como el nombre de host canónico, y en otros lugares simplemente use el dominio simple. Los usuarios seguirán siendo redirigidos cuando sea necesario.
Pero argumentos importantes hablan a favor del uso del nombre de host totalmente calificado con 'www': por rendimiento, seguridad y flexibilidad.
Así que de una vez por todas ponga fin a la discusión: ¡opte por 'www'!