¿WWW sigue perteneciendo a las URL? | trucos CSS
Desde hace años se libra una pequeña guerra de pedantes en nuestras barras de direcciones, en una esquina hay marcas como Google, Instagramy FacebookEste grupo ha seleccionado una redirección example.com
a www.example.com
.En la esquina opuesta: GitHub, Pato Pato a ganary DiscordiaEste 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 pros y los contras de esto 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:
- servidor web en www.ejemplo.com
- servidor FTP en ftp.ejemplo.com
- servidor IRC en irc.ejemplo.com
Inquietud 1 sobre dominios que no son WWW: Fuga de cookies a subdominios
Los críticos de los dominios que no son WWW han señalado que en ciertas situaciones, subdominio.ejemplo.com podrá leer las cookies establecidas por ejemplo.comEsto puede no ser deseable si, por ejemplo, es un proveedor de alojamiento web que permite a los clientes administrar subdominios dentro de 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 establece explícitamente este comportamiento como incorrecto.
Otra fuente potencial de fugas es Domain
valor de todas las cookies configuradas por ejemplo.com.Si Domain
el valor se establece explícitamente en ejemplo.comlas cookies también estarán expuestas a sus subdominios.
valor de la galleta | Expuesto a ejemplo.com | Expuesto a subdominio.ejemplo.com |
---|---|---|
secret=data |
✅ | ❌ |
secret=data; Domain=example.com |
✅ | ✅ |
En conclusión, siempre que no establezca explícitamente un Domain
valor y sus usuarios no utilizan Internet Explorer, no debería haber fugas de cookies.
Problema 2 sin un dominio WWW: dolores de cabeza DNS
A veces, un dominio que no es WWW puede complicar la configuración de su sistema de nombres de dominio (DNS).
Cuando un usuario escribe ejemplo.com en la barra de direcciones del navegador, el navegador debe conocer la dirección del Protocolo de Internet (IP) del servidor web que está intentando 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 Registro que contenga la dirección IP, un dominio que no sea WWW funcionará bien.
En algunos casos, es posible que desee utilizar un en su lugar Nombre canónico (CNAME) entrada para su sitio web. Tal registro puede declarar que www.ejemplo.com es un seudónimo de ejemplo123.somecdnprovider.comque le dice al navegador del usuario que busque la dirección IP en su lugar ejemplo123.somecdnprovider.com y envíe la solicitud HTTP allí.
Tenga en cuenta que el ejemplo anterior utiliza el subdominio WWW. No se puede definir un registro CNAME para ejemplo.com. De acuerdo a RFC 1912Los registros CNAME no pueden coexistir con otros registros. Si intentó definir un registro CNAME para ejemplo.comlos registros del servidor de nombres (NS) para ejemplo.com que contenga las direcciones IP de los servidores de nombres de dominio no podrán existir. Como resultado, los navegadores no podrán averiguar dónde están sus servidores de nombres.
Algunos proveedores de DNS le permitirán eludir esta restricción. Cloudflare llama a su solución Alineación CNAMECon esta técnica, los administradores de dominio configuran un registro CNAME, pero sus servidores de nombres expondrán un registro A.
Por ejemplo, si un administrador configura un registro CNAME para ejemplo.com apuntando a ejemplo123.somecdnprovider.comy la entrada A para ejemplo123.somecdnprovider.com existe apuntando a 1.2.3.4entonces Cloudflare expondrá un registro A para ejemplo.com apuntando 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 ya ofrecen una solución adecuada.
Beneficios sin WWW
Más que argumentos en contra WWW son prácticas o cosméticas. Los defensores de "no WWW" argumentan que es más fácil decir y escribir ejemplo.com que www.ejemplo.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 modesta ventaja de rendimiento. Los propietarios de sitios web podrían ahorrar 4 bytes de cada solicitud HTTP de esta manera. Si bien estos ahorros pueden sumarse a sitios web de alto tráfico como Facebook, el ancho de banda no es un recurso escaso.
Beneficios de la WWW
Un argumento práctico a favor de WWW es en situaciones con dominios de nivel superior más nuevos. www.ejemplo.miami se reconoce inmediatamente como una dirección web cuando por ejemplo.miami no lo es. Esto es menos preocupante para los sitios que tienen dominios de nivel superior reconocibles como .com.
Impacto en el ranking de su motor de búsqueda
El consenso actual es que sus elecciones no afectan 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). Los redireccionamientos constantes aseguran que el valor SEO de sus URL antiguas se transfiera a las nuevas.
Consejos para mantener ambos
Los sitios suelen elegir uno de los dos ejemplo.com o www.ejemplo.com como su sitio web oficial y configurar redireccionamientos HTTP 301 para el otro. En teoría, es posible admitir ambos www.ejemplo.com y ejemplo.com.En la práctica, los costos pueden exceder los beneficios.
Desde un punto de vista técnico, querrá verificar que su pila tecnológica pueda manejar esto. Su sistema de administración de contenido (CMS) o sitio generado de forma estática deberá mostrar los enlaces internos como URL relativas para conservar el nombre de host preferido del visitante. Sus herramientas de análisis pueden registrar el tráfico en los dos 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 proteger el rendimiento de su motor de búsqueda. Google considerará las versiones "WWW" y "no WWW" de las URL como contenido duplicadoPara eliminar el contenido duplicado 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 apareces en Google, recomienda insertar etiquetas de enlace canónicas. Primero decida qué nombre de host será el nombre de host oficial (canónico).
Por ejemplo, si elige www.ejemplo.comtendrá que insertar el siguiente fragmento en el <head>
etiqueta en https://ejemplo.com/mi-articulo:
<link href="https://www.example.com/my-article" rel="canonical">
Este fragmento muestra a Google que la variante "no WWW" representa el mismo contenido. Por lo 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 que se conozcan las ventajas y limitaciones. Para cubrir todas sus bases, asegúrese de configurar redireccionamientos constantes de uno a otro y estará listo para comenzar.
Deja una respuesta