Durante años, una pequeña guerra de pedantería se ha desatado en nuestras barras de direcciones. En una esquina hay marcas como Google, Instagramy Facebook. Este grupo ha optado por redirigir example.com a www.example.com. En la esquina opuesta: GitHub, Pato Pato a ganary Discord. Este grupo ha optado por hacer lo contrario y redirigir www.example.com a example.com.
¿"WWW" pertenece a una URL? Algunos desarrolladores tienen fuertes opiniones sobre el tema. Exploraremos los argumentos a favor y en contra después de un poco de historia.
¿Qué pasa con las W?
Las tres W representan "World Wide Web", un invento de finales de la década de 1980 que presentó al mundo los navegadores y los sitios web. La práctica de usar "WWW" se deriva de la tradición de nombrar los subdominios según el tipo de servicio que brindan:
- un servidor web en www.example.com
- un servidor FTP en ftp.ejemplo.com
- un servidor IRC en irc.ejemplo.com
Problema 1 de dominio sin WWW: fuga de cookies a subdominios
Los críticos de los dominios "sin WWW" han señalado que en ciertas situaciones, Subdomain.example.com sería capaz de leer las cookies establecidas por example.com. Esto puede no ser deseable si, por ejemplo, es un proveedor de alojamiento web que permite a los clientes operar subdominios en su dominio. Si bien la preocupación es válida, el comportamiento era específico de Internet Explorer.
RFC 6265 estandariza cómo los navegadores tratan las cookies y señala explícitamente este comportamiento como incorrecto.
Otra fuente potencial de fugas es el Domain propuesta de de cualquier cookie establecida por example.com. Si el Domain el valor se establece explícitamente en example.com, las cookies también estarán expuestas a sus subdominios.
| valor de la galleta | Expuesto a example.com | Expuesto a Subdomain.example.com |
|---|---|---|
secret=data |
✅ | ❌ |
secret=data; Domain=example.com |
✅ | ✅ |
En conclusión, siempre que no establezca explícitamente un Domain value y sus usuarios no utilizan Internet Explorer, no deberían producirse fugas de cookies.
Problema 2 de dominio sin WWW: dolores de cabeza de DNS
A veces, un dominio "sin WWW" puede complicar la configuración de su sistema de nombres de dominio (DNS).
Cuando un usuario escribe example.com en la barra de direcciones de su navegador, el navegador necesita saber la dirección del Protocolo de Internet (IP) del servidor web que están tratando de visitar. El navegador solicita esta dirección IP de los servidores de nombres de su dominio, generalmente indirectamente a través de los servidores DNS del proveedor de servicios de Internet (ISP) del usuario. Si sus servidores de nombres están configurados para responder con un Un registro que contenga la dirección IP, un dominio "sin WWW" funcionará bien.
En algunos casos, es posible que desee utilizar en su lugar un Nombre canónico (CNAME) registro para su sitio web. Dicho registro puede declarar que www.example.com es un alias de ejemplo123.somecdnprovider.com, que le dice al navegador del usuario que, en su lugar, busque la dirección IP de ejemplo123.somecdnprovider.com y envíe la solicitud HTTP allí.
Tenga en cuenta que el ejemplo anterior utilizó un subdominio WWW. No es posible definir un registro CNAME para example.com. Según RFC 1912, los registros CNAME no pueden coexistir con otros registros. Si intentó definir un registro CNAME para example.com, los registros del servidor de nombres (NS) para example.com que contenga las direcciones IP de los servidores de nombres del dominio no podría existir. Como resultado, los navegadores no podrán averiguar dónde están sus servidores de nombres.
Algunos proveedores de DNS le permitirán sortear esta limitación. Cloudflare llama a su solución Aplanamiento de CNAME. Con esta técnica, los administradores de dominio configuran un registro CNAME, pero sus servidores de nombres expondrán un registro A.
Por ejemplo, si el administrador configura un registro CNAME para example.com señalando a ejemplo123.somecdnprovider.com, y un récord A para ejemplo123.somecdnprovider.com existe apuntando a 1.2.3.4, entonces Cloudflare expondría un registro A para example.com señalando a 1.2.3.4.
En conclusión, si bien la preocupación es válida para los propietarios de dominios que deseen utilizar registros CNAME, algunos proveedores de DNS ahora ofrecen una solución alternativa adecuada.
Beneficios sin WWW
La mayor parte del argumentos en contra WWW son prácticas o cosméticas. Los defensores de "No-WWW" han argumentado que es más fácil decir y escribir example.com que www.example.com (que puede ser menos confuso para los usuarios menos expertos en tecnología).
Quienes se oponen al subdominio WWW también han señalado que eliminarlo conlleva una humilde ventaja de rendimiento. Los propietarios de sitios web podrían eliminar 4 bytes de cada solicitud HTTP al hacerlo. Si bien estos ahorros podrían sumar para sitios web de alto tráfico como Facebook, el ancho de banda generalmente no es un recurso escaso.
beneficios web
Un argumento práctico a favor de WWW es en situaciones con dominios de nivel superior más nuevos. Por ejemplo, www.ejemplo.miami es inmediatamente reconocible como una dirección web cuando ejemplo.miami no lo es Esto es menos preocupante para los sitios que tienen dominios de nivel superior reconocibles como .com.
Impacto en la clasificación de su motor de búsqueda
El consenso actual es que su elección no influye en el rendimiento de su motor de búsqueda. Si desea migrar de uno a otro, deberá configurar redireccionamientos permanentes (HTTP 301) en lugar de temporales (HTTP 302). Las redirecciones permanentes aseguran que el valor SEO de sus URL antiguas se transfiera a las nuevas.
Consejos para apoyar a ambos
Los sitios normalmente eligen example.com or www.example.com como su sitio web oficial y configurar redireccionamientos HTTP 301 para el otro. En teoría, es posible admitir ambos www.example.com y example.com. En la práctica, los costos pueden ser mayores que los beneficios.
Desde una perspectiva técnica, querrá verificar que su stack tecnológico pueda manejarlo. Su sistema de administración de contenido (CMS) o sitio generado estáticamente tendría que generar enlaces internos como URL relativas para preservar el nombre de host preferido del visitante. Sus herramientas de análisis pueden registrar el tráfico en ambos nombres de host por separado, a menos que pueda configurar los nombres de host como alias.
Por último, deberá dar un paso más para salvaguardar el rendimiento de su motor de búsqueda. Google considerará las versiones "WWW" y "no WWW" de una URL como contenido duplicado. Para deduplicar el contenido en su índice de búsqueda, Google mostrará cualquiera de los dos que crea que el usuario preferirá, para bien o para mal.
Para mantener el control sobre cómo aparece en Google, recomienda insertar etiquetas de enlace canónicas. Primero, decida qué nombre de host será el oficial (canónico).
Por ejemplo, si elige www.example.com, tendrás que insertar el siguiente fragmento en el etiquetar en https://example.com/my-article:
Este fragmento indica a Google que la variante "sin WWW" representa el mismo contenido. En general, Google preferirá la versión que marcó como canónica en los resultados de búsqueda, que sería la variante "WWW" en este ejemplo.
Conclusión
A pesar de la intensa campaña de ambos lados, ambos enfoques siguen siendo válidos siempre y cuando conozca los beneficios y las limitaciones. Para cubrir todas sus bases, asegúrese de configurar redireccionamientos permanentes de uno a otro y ya está todo listo.
