Tu sitio web funciona sin WWW, pero falla con WWW: corrige ambas direcciones antes del lanzamiento

Un electricista local lanza un sitio web en example.com e incluye www.example.com en mil tarjetas de presentación. La página de inicio se ve bien cuando el propietario la revisa, pero los clientes que escriben la dirección impresa ven un error. El sitio web existe. El dominio está registrado. Una pequeña diferencia en la dirección es suficiente para que la publicidad resulte ineficaz.

Este problema es común porque example.com y www.example.com son nombres de host separados, aunque generalmente forman parte del mismo sitio web comercial. Uno puede tener DNS, hosting y HTTPS funcionando mientras que el otro no se ha configurado.

Normalmente no es necesario comprar un segundo dominio para solucionar este problema. Debes decidir qué nombre de host deben ver los clientes, hacer que ambas direcciones sean accesibles y dirigirlos a un destino coherente. A continuación se presenta una forma práctica de hacerlo sin interrumpir accidentalmente el correo electrónico comercial u otros servicios.

Comprende por qué WWW es un nombre de host separado

Cuando registras example.com, controlas ese dominio registrado y puedes configurar nombres de host debajo de él. www.example.com es uno de esos nombres de host. No es un dominio de nivel superior diferente y el prefijo www no es otra extensión.

El nombre de la raíz, a menudo llamado ápice, es example.com. El nombre de host www se encuentra debajo. DNS puede publicar diferentes respuestas para los dos nombres, y se puede configurar un servidor web o plataforma de alojamiento para aceptar uno pero no el otro.

Un pequeño taller de muebles puede publicar su sitio web en el dominio raíz, mientras que una antigua cuenta de hosting todavía tiene un registro www apuntando a otra parte. Una nueva panadería podría conectar el nombre raíz a un creador de sitios web, pero olvidarse del paso separado para www. Un consultor puede tener un certificado HTTPS válido para un nombre de host pero no para el otro.

Los síntomas pueden ser similares a los de un cliente: una página no disponible, una pantalla de bienvenida de alojamiento, una advertencia de certificado o una redirección inesperada. Las causas subyacentes son diferentes, por lo que la primera tarea es identificar qué capa está fallando.

Decide qué versión será la dirección pública

Tanto `https://example.com` como `https://www.example.com` pueden ser direcciones primarias legítimas. Ninguna ortografía es automáticamente más profesional, más rápida o mejor para la visibilidad de búsqueda simplemente porque incluye u omite www.

Elige una versión según los requisitos de la plataforma del sitio web, los enlaces existentes de la empresa y lo que ya se ha impreso. Un pequeño restaurante que ha utilizado el www durante años puede preferir conservarlo. Un salón nuevo sin materiales publicados puede preferir la dirección del dominio raíz más corta. El punto importante es la coherencia.

Una vez que elijas la versión principal, configura la otra para redirigir a ella. Esto brinda a los clientes una experiencia que admite ambas formas de escribir la dirección cuando agregan u omiten www en una tarjeta de presentación, factura, perfil social o firma de correo electrónico.

Registra la decisión en las notas del sitio web de la empresa. Los miembros del personal que preparan folletos no deberían tener que adivinar qué dirección es oficial. Utiliza la misma versión preferida en menús, folletos, confirmaciones de reservas y plantillas de atención al cliente.

Una redirección es apropiada aquí porque los dos nombres de host representan el mismo sitio web. No es motivo para registrar dominios adicionales o crear copias duplicadas de cada página.

Diagnostica las cuatro direcciones por separado

Un cliente puede llegar a través de cuatro puntos de partida comunes:

La tabla utiliza un dominio ilustrativo. Reemplázalo con tu dominio comercial real cuando realices la prueba.

Abre cada dirección en una ventana privada del navegador y anota la URL final. No asumas que un navegador que se actualiza automáticamente a HTTPS ha demostrado que la ruta subyacente HTTP está configurada correctamente. Prueba con herramientas que muestren la respuesta real y la cadena de redirecciones cuando sea necesario.

Para cada caso, registra si el nombre se resuelve, si la conexión HTTPS se realiza correctamente, si se produce una redirección y qué página se carga finalmente. Un resultado útil es un único destino esperado, no simplemente una pestaña del navegador que finalmente muestra algo.

Un contador local puede utilizar esta sencilla prueba antes de enviar un paquete de bienvenida a un nuevo cliente. Un florista puede ejecutarlo antes de pedir etiquetas impresas. Es mucho más económico corregir la dirección web antes de que los clientes comiencen a utilizarla.

Comprueba el DNS antes de editar el sitio web

Las respuestas DNS le indican al navegador dónde conectarse. Si example.com funciona pero www.example.com no se resuelve, el registro faltante o incorrecto puede ser la causa inmediata.

El dominio raíz (apex) suele utilizar registros A o AAAA que apuntan al servicio del sitio web, aunque la configuración exacta depende del proveedor. Un nombre de host www comúnmente usa un CNAME que apunta a otro nombre de host, o puede usar registros A o AAAA especificados por el proveedor. Sigue las instrucciones de la plataforma de alojamiento o sitio web en lugar de adivinar las direcciones IP.

Un CNAME convencional no puede coexistir con los registros requeridos en el vértice de la zona. Algunos proveedores de DNS ofrecen funciones de aplanamiento de ALIAS, ANAME o CNAME para admitir un comportamiento similar a un alias allí. Esas son soluciones específicas del proveedor, no prueba de que cada servicio DNS acepte la misma configuración principal.

Primero verifica los servidores de nombres autoritativos. Editar registros en un panel de alojamiento antiguo no logrará nada si otro proveedor de DNS presta servicio actualmente al dominio. Si no sabes qué servicio tiene autoridad, inspecciona la delegación del servidor de nombres antes de realizar cambios.

Mantén una copia de la zona actual. No elimines registros MX, registros TXT de autenticación de correo electrónico ni entradas de servicios no relacionados mientras repara www. Un problema con el nombre de host de un sitio web no debería convertirse en una interrupción del correo electrónico.

Confirma que la plataforma de alojamiento acepta ambos nombres

Un registro DNS puede dirigir a los visitantes a un servidor al que nunca se le ha dicho que proporcione el nombre de host solicitado. En ese caso, el servidor puede mostrar una página predeterminada, devolver un error o enviar visitantes a un sitio no relacionado.

Muchos creadores de sitios web y paneles de alojamiento requieren que agregue tanto el dominio raíz como el nombre de host www como dominios aceptados o conectados. La terminología exacta varía: dominios personalizados, alias, nombres de host adicionales, dominios estacionados o enlaces de dominio.

Una cafetería que utilice un servicio de sitio web administrado debe buscar las instrucciones de conexión al dominio de la plataforma. Un taller que utilice hosting cPanel debe confirmar que el dominio y sus alias esperados están configurados en la cuenta de hosting. Una aplicación personalizada puede requerir que el host virtual del servidor web o la configuración de enrutamiento incluyan ambos nombres.

No soluciones este problema duplicando todo el sitio web en dos carpetas. Esto crea dos copias para actualizar y puede generar contenido inconsistente, formularios rotos y señales de búsqueda confusas. Normalmente, una aplicación debería manejar el nombre de host preferido mientras que el nombre de host alternativo redirige.

Si la plataforma de alojamiento no admite la disposición del nombre de host solicitado, pregunta a su equipo de soporte qué se requiere antes de volver a cambiar el DNS.

Haz que HTTPS funcione antes de la redirección

Es fácil pasar por alto un detalle importante: cuando un cliente ingresa `https://www.example.com`, el navegador establece una conexión segura con ese nombre de host antes de poder recibir una redirección HTTP normal.

Si el servidor no tiene un certificado válido que cubra www.example.com, el cliente puede ver una advertencia de certificado antes de que la redirección pueda ayudar. Un certificado para example.com por sí solo no cubre necesariamente el www.example.com; inspecciona la cobertura real del nombre de host del certificado.

Para una zapatería, esa advertencia puede parecer alarmante incluso si el sitio web final previsto es seguro. Los clientes no saben que la empresa tenía la intención de enviarlos a otra parte. Ven una advertencia del navegador y pueden irse.

Configura HTTPS para ambos nombres de host públicos y luego prueba la redirección. El certificado podrá ser emitido por la plataforma de hosting o gestionado por separado, según el servicio. No compres un certificado sin comprobar qué incluye ya el plan de hosting seleccionado y qué nombres cubre.

Comprueba también que la página final no cargue scripts, imágenes o formularios inseguros. HTTPS en la barra de direcciones es un control de transporte necesario, no una evaluación completa de la seguridad del sitio web.

Redirige el nombre de host alternativo de forma permanente

Para un sitio web público estable, una redirección permanente generalmente es apropiada cuando el nombre de host alternativo siempre debe conducir al preferido. Las opciones comunes son HTTP 301 o 308. Un 308 conserva el método y el cuerpo de la solicitud; 301 se usa ampliamente para la navegación normal de páginas, pero las aplicaciones deben considerar el comportamiento de manejo de métodos antes de redirigir solicitudes que no sean GET.

Por ejemplo, si la dirección preferida es `https://example.com`, una solicitud de `https://www.example.com/services` normalmente debería llegar a `https://example.com/services` no simplemente a la página de inicio. El camino importa cuando los clientes siguen un enlace a un servicio o producto en particular.

Conserva las cadenas de consulta cuando corresponda, especialmente cuando el sitio las utiliza para filtros de productos o seguimiento de campañas. Al mismo tiempo, evita reglas de redireccionamiento que expongan accidentalmente información confidencial o realicen bucles entre los dos nombres de host.

No crees una regla que envíe el vértice a www y otra que envíe www de regreso al vértice. Eso provoca un bucle de redireccionamiento. Mantén la dirección principal elegida en un solo lugar y prueba el resultado después de cada cambio.

Una empresa de jardinería con enlaces impresos a /estimate debe asegurarse de que esos enlaces continúen llegando a la página de estimación independientemente del nombre de host que escriban los clientes.

Evita soluciones comunes que crean nuevos problemas

El primer error es agregar registros DNS aleatorios hasta que el navegador parezca funcionar. Un registro A incorrecto puede señalar un nombre de host a un servidor obsoleto mientras que el otro sigue siendo correcto. Copiar una configuración de una plataforma diferente no es un atajo seguro.

El segundo error es tratar un CNAME de DNS como una redirección web. Un CNAME ayuda a que un nombre de host se resuelva a través de otro nombre de host; no le dice al navegador que cambie la dirección que se muestra en la barra de URL. El servicio web aún debe aceptar el nombre de host y emitir la redirección HTTP deseada.

El tercer error es utilizar una redirección temporal para una decisión de marca permanente sin ningún motivo. Las redirecciones temporales tienen una semántica diferente y pueden complicar la indexación y el almacenamiento en caché consistentes. Elige el estado que coincida con el comportamiento previsto.

El cuarto error es habilitar políticas estrictas de HTTPS antes de que se hayan probado tanto los nombres de host como los subdominios relevantes. HSTS puede ser valioso, pero una configuración amplia o prematura puede dificultar la recuperación de problemas de certificados. No habilites una política includeSubDomains casualmente cuando puedan existir servicios no relacionados debajo del dominio.

Finalmente, no asumas que una prueba de página de inicio verde significa que el formulario de contacto, el flujo de reserva, el inicio de sesión del cliente y el proceso de pago funcionan. Prueba los recorridos importantes del cliente una vez implementada la redirección.

Verifica las señales de búsqueda y los materiales orientados al cliente

Los motores de búsqueda pueden encontrar ambas versiones del nombre de host a través de enlaces antiguos, marcadores y navegación del sitio. Los redireccionamientos permanentes ayudan a consolidar la dirección pública, mientras que los enlaces internos consistentes y las señales de URL canónicas refuerzan la versión preferida.

Actualiza la navegación del sitio web, el mapa del sitio XML, las etiquetas canónicas y otras URL base configuradas al nombre de host preferido cuando corresponda. Una etiqueta canónica no reemplaza una redirección funcional, especialmente cuando un cliente escribe la dirección alternativa y encuentra un error.

Revisa perfiles sociales, listados de directorios, firmas de correo electrónico, tarjetas de presentación, facturas y materiales impresos. No es necesario volver a imprimir todo simplemente porque contiene el nombre de host alternativo si esa dirección funciona correctamente y redirige. Pero los nuevos materiales deberían utilizar una versión pública coherente.

Un hotel pequeño puede tener años de folletos que contengan www. Una redirección funcional puede preservar las visitas de los clientes mientras la empresa utiliza la dirección más corta en materiales futuros. Un consultorio dental puede tener recordatorios de citas apuntando al ápice. Ambas rutas deberían seguir siendo fiables.

Después de un cambio, revisa los análisis del sitio web y los informes de búsqueda para detectar errores inesperados. Una caída repentina en las visitas a un nombre de host puede ser normal si esas solicitudes se redirigen correctamente; un aumento en las solicitudes fallidas no lo es.

Ejecuta una prueba práctica el día del lanzamiento

Utiliza esta secuencia antes de anunciar el sitio web:

1. Confirma que el dominio registrado esté activo y que los servidores de nombres autoritativos sean correctos.
2. Verifica las respuestas DNS para los nombres de host apex y www.
3. Confirma que la plataforma de alojamiento acepte ambos nombres.
4. Verifica los certificados HTTPS válidos para ambos nombres de host.
5. Prueba las cuatro direcciones iniciales HTTP y HTTPS.
6. Verifica que las redirecciones lleguen al nombre de host preferido sin bucles.
7. Prueba una página profunda, un formulario de contacto y cualquier flujo de reserva o pago.
8. Confirma que el correo electrónico comercial aún se envía y recibe normalmente.
9. Actualiza los nuevos materiales impresos y digitales a la dirección preferida.
10. Registra la configuración final de DNS y redirecciones para cambios futuros.

Una simple verificación de línea de comando puede ayudar a un asistente técnico a ver los encabezados de respuesta:

curl -I https://www.example.com/services

Mira el estado de HTTP y cualquier encabezado de Location. El comando es un ejemplo de diagnóstico, no una prueba completa de seguridad o disponibilidad. Es posible que no revele todos los comportamientos de las aplicaciones, y los errores de certificado deben investigarse en lugar de omitirse para que una prueba parezca exitosa.

Si no administras los servidores tú mismo, envía los resultados de la prueba a tu proveedor de sitio web. Un informe preciso como "el apex funciona con HTTPS, pero www devuelve un certificado que no coincide" es mucho más procesable que "el dominio no funciona".

Cómo te ayudamos en SoxDomains con DNS, alojamiento y HTTPS

En SoxDomains, proporcionamos registro y administración de dominios junto con alojamiento web y opciones de certificado SSL. Estos servicios pueden admitir la configuración de DNS, el sitio web y HTTPS detrás de una dirección comercial consistente.

Si tu dominio ya está registrado, generalmente no necesitas comprarlo nuevamente para solucionar un problema de www. Comienza verificando dónde se administra el DNS y qué nombres de host acepta el servicio del sitio web. Nuestra información de administración de dominio puede ayudarte a comprender el lado del registro, mientras que la configuración del proveedor de alojamiento determina cómo responde el sitio.

Para una nueva empresa, compara opciones de dominio antes de elegir la dirección que aparecerá en los carteles y facturas. Luego configura ambas variaciones de nombre de host antes de publicar el sitio web. El mejor dominio es de poca utilidad cuando la mitad de los hábitos de escritura de los clientes conducen a un error.

Verifica el plan de hosting específico y la cobertura del certificado antes de comprar productos adicionales. La solución adecuada puede ser una pequeña corrección de DNS, un alias de alojamiento, una actualización de certificado o una regla de redireccionamiento en lugar de un nuevo servicio.

Haz que todas las versiones de tu dirección comercial funcionen

Los clientes no deberían tener que entender DNS para encontrar una panadería, reservar una cita o solicitar un presupuesto. Si tu dominio está impreso con www, esa dirección debe funcionar. Si un cliente lo omite, eso también debería funcionar.

Elige un nombre de host principal, configura DNS y HTTPS para ambos y redirige la versión alternativa limpiamente. Prueba el recorrido real del cliente antes de imprimir o publicar tu próxima campaña.

¿Necesita un dominio confiable y una base de alojamiento para un nuevo sitio web? Explora el alojamiento y el registro de dominio SoxDomains y deja la dirección correctamente configurada antes de que los clientes comiencen a escribirla.