Arreglar redirección a www o sin www en WordPress

Qué significa www y por qué importa

Cuando hablamos de “www” frente a “sin www”, en realidad hablamos de dos hostnames distintos. Para un navegador, www.ejemplo.com y ejemplo.com no son exactamente lo mismo, aunque para una persona lo parezca. Esa diferencia técnica es suficiente para provocar comportamientos extraños si no se decide una versión principal y se fuerza la otra a redirigir correctamente.

En WordPress, esto se nota especialmente por dos razones. La primera es que WordPress guarda una URL base en su configuración y la utiliza para generar enlaces internos, rutas de recursos, llamadas a la API y redirecciones de seguridad. La segunda es que muchos entornos añaden una capa extra, por ejemplo Cloudflare, un plugin de seguridad, el panel del hosting, o reglas en el servidor. Si cada capa empuja la URL hacia un lado distinto, aparecen redirecciones dobles, cambios de hostname inesperados o bucles.

Elegir “www” o “sin www” no es una cuestión de “mejor o peor” en SEO por sí sola. Lo importante es la consistencia. Si Google ve el mismo contenido en ambas versiones sin una redirección 301 clara y un canonical coherente, puede interpretar que hay duplicidad. Eso puede repartir señales de relevancia, diluir enlaces y complicar el rastreo.

Antes de tocar nada, piense en su contexto. Si su dominio ya tiene enlaces entrantes históricos apuntando a una versión, suele ser más cómodo adoptarla como principal. Si está empezando, puede elegir la que prefiera. En cualquier caso, el objetivo de este artículo es que pueda arreglar la redirección a www o sin www en WordPress sin perder el control del SEO, sin romper el SSL y sin quedarse con un sitio “que a veces entra y a veces no”.

Cómo identificar el problema de redirección

Un error habitual es empezar a cambiar cosas sin haber medido el síntoma exacto. En redirecciones, el detalle importa. No es lo mismo que siempre le envíe a www, que a veces alterne entre www y sin www, o que haya un bucle infinito. Para identificarlo, la clave es observar la cadena de redirecciones completa y localizar quién la está provocando.

Empiece por una prueba simple en modo incógnito. Abra https://ejemplo.com y https://www.ejemplo.com en pestañas distintas. Anote dónde termina cada una. Después repita con HTTP: http://ejemplo.com y http://www.ejemplo.com. Si una de ellas termina en un hostname distinto, ya sabe que existe un redirect. Si termina varias veces, verá cambios sucesivos en la barra del navegador. Si el navegador le muestra “demasiadas redirecciones”, casi seguro hay dos reglas enfrentadas.

Para una comprobación más técnica, es útil usar herramientas que muestren los códigos 301, 302, 307 y el orden. Puede hacerlo con extensiones del navegador, con herramientas online de “redirect checker”, o desde su propio equipo con comandos como curl si está familiarizada. Lo importante no es la herramienta, sino la evidencia: la lista de saltos y el encabezado Location que indica a qué URL manda cada salto.

Cuando el problema se presenta solo en algunos dispositivos o solo a veces, la causa suele ser caché. Puede ser caché del navegador, del plugin, del servidor, o de Cloudflare. Por eso conviene probar también desde una conexión distinta o con datos móviles. Si el resultado cambia, no significa que esté “arreglado”, sino que la capa de caché está en medio y puede ocultar la regla real.

Con esa información en la mano, ya puede avanzar con orden. En la práctica, la mayoría de conflictos se concentran en cuatro lugares: configuración de WordPress, DNS, reglas del servidor (Apache o Nginx) y Cloudflare. El resto suele ser secundario, aunque plugins de seguridad y cambios de hosting también entran a veces en la ecuación.

Configuración correcta en WordPress: Site URL y Home

WordPress tiene dos ajustes críticos: la “Dirección de WordPress (URL)” y la “Dirección del sitio (URL)”. Si están mal, WordPress intentará corregirlos con redirecciones internas, y eso puede chocar con el servidor. Este paso es el primero que debe revisar, porque si WordPress cree que su sitio “vive” en www, lo empujará hacia ahí aunque usted haya configurado otra cosa fuera.

Revise estos valores en Ajustes, Generales. Deben coincidir entre sí y deben reflejar su versión elegida. Si su versión principal es sin www, ambos deberían ser https://ejemplo.com. Si su versión principal es con www, ambos deberían ser https://www.ejemplo.com. Además, confirme que usan HTTPS si ya tiene certificado activo. Mezclar uno en HTTP y otro en HTTPS es una receta bastante segura para un bucle.

Si no puede entrar al panel por culpa del bucle, hay alternativas. Puede editar wp-config.php y definir las constantes WP_HOME y WP_SITEURL. Esto fuerza a WordPress a usar esas URLs sin depender de la base de datos. También puede corregirlo directamente en la tabla de opciones en la base de datos, cambiando “home” y “siteurl”. Estas acciones deben hacerse con cuidado y con copia de seguridad, sobre todo si hay multisite o si el sitio está en producción.

No se olvide de revisar la configuración del plugin de caché y del plugin de seguridad, si existen. Algunos añaden redirecciones “de fuerza” a HTTPS o a una URL concreta. También es habitual que un plugin de “migración” o “optimización” haya dejado ajustes antiguos tras un cambio de dominio. Si encuentra un ajuste llamado “Force canonical”, “Force www” o similar, desactívelo temporalmente hasta que la lógica principal sea estable. Después se puede volver a activar si aporta valor, pero solo si no duplica reglas ya existentes.

Una vez que WordPress tenga coherentes sus URLs internas, el siguiente punto es el DNS. Si el DNS no apunta bien, puede estar llegando a un servidor distinto según use www o no, y eso hace imposible que una redirección se comporte de forma consistente.

Revisar DNS: registros A, AAAA y CNAME

El DNS decide dónde vive cada hostname. Es decir, “ejemplo.com” puede apuntar a una IP y “www.ejemplo.com” a otra. Si su “www” está configurado como CNAME hacia un servicio distinto, o si hay un registro AAAA apuntando a una IPv6 que no corresponde, el comportamiento puede parecer aleatorio. En realidad, está yendo a destinos diferentes.

Compruebe su zona DNS y confirme, como mínimo, estos puntos. Primero, que el dominio raíz (apex), normalmente “@”, tenga un registro A (IPv4) apuntando a su servidor o a su proveedor. Segundo, que el “www” tenga un CNAME apuntando al dominio raíz o un A apuntando al mismo servidor. Lo importante es que ambos terminen en el mismo entorno. Si uno pasa por un proxy como Cloudflare y el otro no, también puede haber diferencias de comportamiento.

Un error frecuente es tener registros duplicados o conflictivos. Por ejemplo, varios A para “@” con IPs antiguas, o un AAAA activo cuando el servidor no responde por IPv6. Algunos navegadores y redes prefieren IPv6 si está disponible, y eso puede provocar que unas personas vean una cosa y otras otra. Si no usa IPv6 de forma explícita, desactivar el AAAA suele simplificar la depuración.

También debe considerar la propagación. Un cambio de DNS no se refleja siempre al instante. Depende del TTL y de la caché de resolvers. Por eso es habitual corregir un registro y seguir viendo el fallo durante horas desde algunas ubicaciones. Para evitar confusiones, anote la hora exacta del cambio y reduzca el TTL solo si sabe lo que hace. Si ya hay un problema activo, lo habitual es que el TTL esté fijado y usted tenga que convivir con la transición.

Una vez confirmados DNS y WordPress, el tercer punto es el servidor. Aquí hay dos caminos típicos: Apache con .htaccess o Nginx con bloques server. Si está en hosting compartido, suele ser Apache. En VPS o contenedores, a menudo es Nginx. A veces hay ambos, con Nginx como proxy delante de Apache, y entonces conviene decidir dónde vive la redirección para no duplicarla.

Apache y .htaccess: reglas 301 sin bucles

Si su WordPress está bajo Apache, la redirección suele resolverse en el archivo .htaccess, en la raíz del sitio. Ahí conviven las reglas del core de WordPress (rewrite para enlaces permanentes) con reglas personalizadas. El objetivo es simple: si alguien entra por la versión no preferida, se le debe enviar una sola vez a la versión preferida, con código 301 y conservando ruta y query string.

Antes de editar, haga copia del archivo. Un cambio pequeño puede dejar la web inaccesible. Después, revise si ya existe alguna regla que fuerce www o fuerce sin www. También revise si hay reglas para HTTPS. Es habitual tener una regla que fuerza HTTPS y otra que fuerza el hostname, y si están mal ordenadas, crean dos saltos. Eso no es el fin del mundo, pero puede ser mejorable. Lo grave es cuando se contradicen y generan un bucle.

Un enfoque sólido es consolidar ambas cosas en una sola lógica. Por ejemplo, si quiere forzar HTTPS y además forzar sin www, puede hacer una condición que detecte si no está en HTTPS o si el host empieza por www, y redirigir a la URL final en un único salto. A la inversa, si quiere forzar HTTPS y con www, lo mismo. Lo importante es que su regla apunte siempre a la versión final, no a una intermedia.

Si utiliza Cloudflare u otro proxy, puede que Apache no reciba la petición como HTTPS aunque el usuario sí esté en HTTPS. En ese caso, hay que considerar cabeceras como X-Forwarded-Proto. Muchos plugins y configuraciones de WordPress ya lo contemplan, pero reglas manuales no siempre. Si su .htaccess fuerza HTTPS basándose solo en “HTTPS off”, puede redirigir de forma incorrecta cuando hay proxy. Esto se manifiesta como bucle: Cloudflare entrega HTTPS, Apache cree que es HTTP y redirige a HTTPS, Cloudflare vuelve a entregar, y así sucesivamente.

Una vez ajustado .htaccess, limpie caché y pruebe de nuevo las cuatro URLs: http y https con y sin www. Si el resultado final coincide siempre en una sola URL final, va por buen camino. Si su servidor es Nginx, el punto correcto no es .htaccess, sino la configuración del bloque server.

Nginx: redirects y canonical sin romper SSL

En Nginx no existe .htaccess por directorio. La redirección se define en la configuración del servidor, normalmente en un bloque server. Si su WordPress está detrás de Nginx, lo más limpio es resolver el hostname ahí, y dejar a WordPress centrarse en su contenido. Al igual que en Apache, la meta es una única redirección hacia la versión principal, conservando la ruta completa.

El patrón habitual es tener un server para el dominio no preferido que simplemente redirige al preferido. Por ejemplo, si su versión principal es sin www, un bloque server que escuche para “www.ejemplo.com” y devuelva un 301 a “https://ejemplo.com$request_uri”. Si la principal es con www, se invierte. Así se evita mezclar lógica dentro del bloque que sirve el sitio real.

Con HTTPS, Nginx suele tener un server por el puerto 443 con los certificados. Aquí conviene ser muy meticuloso: si redirige desde un server 443 a otro, asegúrese de que el destino también tiene certificado válido y responde sin error. Si el certificado solo cubre una versión del hostname, redirigir a la otra puede disparar alertas. Lo correcto es que el certificado cubra tanto el dominio raíz como el www, o que la versión no preferida esté atendida por un certificado válido al menos durante el redirect.

Otro foco de problemas en Nginx es cuando hay un balanceador, un proxy o un panel que genera configuraciones. Puede terminar con dos redirecciones: una en el panel y otra en el archivo. Si cada una fuerza una cosa, el resultado es un bucle. Por eso, cuando arregle esto, decida un único lugar donde vivirán las reglas. Si su hosting tiene un “force www” en su panel, desactívelo y haga la redirección en Nginx, o al revés. Lo que no conviene es duplicar.

Finalmente, recuerde que WordPress también puede redirigir si cree que la URL no coincide. Si su Nginx fuerza sin www pero WordPress está configurado con www, la web puede entrar en una pelea. Por eso el orden de trabajo que estamos siguiendo es importante: primero WordPress, luego DNS, luego servidor. Cuando todo eso esté alineado, Cloudflare y la caché dejan de ser una fuente de sorpresas.

Cloudflare: redirecciones, reglas y caché

Cloudflare puede resolver su redirección sin tocar el servidor, pero también puede ser la razón por la que el comportamiento se vuelve confuso. Si Cloudflare está en modo proxy (nube naranja), actúa como intermediario y puede aplicar reglas propias: redirecciones, reescrituras, forzado de HTTPS, y cacheado de respuestas 301. Esto es potente, pero exige orden.

Si decide gestionar la redirección de www a sin www (o al revés) en Cloudflare, lo ideal es hacerlo con una regla única, clara y fácil de mantener. Hoy en día, Cloudflare ofrece varias opciones según el plan y la configuración, pero el concepto es el mismo: si el host coincide con el no preferido, redirigir a la URL preferida conservando la ruta. Evite reglas múltiples que se solapen con “Always Use HTTPS” u opciones similares si ya fuerza HTTPS en el servidor.

Un problema muy habitual es tener, a la vez, el ajuste de “Always Use HTTPS”, una regla que fuerza www, y otra regla en el servidor que fuerza sin www. Cada una por separado “tiene sentido”, pero juntas generan una cadena extra o un bucle. En estos casos, la solución no es añadir otra regla para “arreglarlo”, sino quitar las duplicadas y dejar una sola autoridad para cada cosa.

También tenga presente la caché. Cloudflare puede cachear redirecciones. Si hoy la redirección era a www y mañana la cambia a sin www, puede seguir viendo resultados antiguos durante un tiempo. Para depurar, conviene purgar caché en Cloudflare y, si usa “Cache Everything” en algunas rutas, revisar si está aplicándose también a respuestas 301.

Por último, revise el modo SSL de Cloudflare. Si está en “Flexible”, Cloudflare sirve HTTPS al visitante pero conecta por HTTP al servidor. Eso suele provocar bucles cuando WordPress o el servidor fuerzan HTTPS por su cuenta. Para WordPress, lo más estable suele ser un modo que permita HTTPS también hacia el origen. Si su sitio debe ser HTTPS de verdad, “Flexible” suele ser una fuente constante de problemas. Ajustar esto correctamente suele ser el punto de inflexión para que desaparezcan los bucles de redirección.

Errores frecuentes: SSL, HTTP a HTTPS y bucles

Cuando alguien dice “me redirige solo a veces” o “me sale demasiadas redirecciones”, casi siempre hay una combinación de reglas que fuerzan cosas distintas. El caso más típico es el triángulo: una regla fuerza HTTPS, otra fuerza www, y WordPress cree otra cosa. El resultado es un bucle en el que la URL cambia, pero nunca llega a estabilizarse.

Otro caso frecuente es que el certificado SSL solo cubra una versión del dominio. Si el usuario entra por la versión sin certificado, el navegador bloquea la conexión antes de que la redirección se ejecute. Esto crea la sensación de “la web no entra”, pero en realidad la web final podría estar bien. La solución pasa por emitir un certificado que incluya ambos hostnames, o por servir un certificado válido también en la versión que solo va a redirigir.

Los bucles también aparecen con proxys. Si hay un proxy delante (Cloudflare, un balanceador, un WAF), el servidor puede recibir peticiones como HTTP aunque el visitante esté en HTTPS. Si su regla se basa en “si no es HTTPS, redirigir a HTTPS”, se activará siempre, incluso cuando ya está en HTTPS para el usuario. Esto es muy común en instalaciones donde no se ha configurado correctamente la cabecera que indica el protocolo original.

Hay, además, una fuente menos evidente: la redirección de login y cookies. WordPress establece cookies de sesión con dominio asociado. Si cambia el hostname sin que WordPress lo espere, puede ver comportamientos raros, como volver a la home tras iniciar sesión o no mantener la sesión. Esto no siempre es un problema de credenciales. A veces es una consecuencia directa de una URL base inconsistente.

Para arreglarlo, la estrategia más eficaz es reducir el sistema a lo esencial. Desactive temporalmente plugins que gestionen redirecciones, quite reglas duplicadas en el servidor o en Cloudflare, y deje solo la redirección mínima necesaria. Cuando todo funcione con una única cadena de redirección, entonces reintroduzca elementos como caché avanzada o reglas de seguridad. Si lo hace al revés, suele terminar persiguiendo síntomas.

Impacto SEO: canonical, Search Console y migración

Arreglar la redirección a www o sin www en WordPress no es solo “que cargue la web”. También es que Google entienda cuál es la URL principal. Si no, puede indexar ambas versiones, mezclar señales y mostrar resultados inconsistentes. Para evitarlo, hay tres pilares: redirección 301, etiqueta canonical y coherencia interna.

La redirección 301 debe ir desde la versión no preferida a la preferida para todas las rutas. Es decir, no solo para la home. Si alguien entra por http://www.ejemplo.com/categoria/post debe terminar en https://ejemplo.com/categoria/post si esa es su opción final. Si solo redirige la home, el resto queda duplicado.

El canonical es la señal que va en el HTML y le dice a los buscadores cuál es la URL que debe considerarse principal para esa página. La mayoría de instalaciones con Yoast, Rank Math u otros plugins lo gestionan, pero depende de que WordPress esté bien configurado. Si WordPress cree que la base es www, el canonical tenderá a salir con www. Si el servidor fuerza sin www, ahí ya tiene una incoherencia.

La coherencia interna incluye menús, enlaces dentro del contenido, sitemap y recursos. Si su sitio enlaza a ambas versiones, aunque haya redirección 301, está generando saltos innecesarios. Por eso conviene, tras el cambio, buscar y reemplazar URLs antiguas en contenido si procede, regenerar el sitemap y limpiar cachés.

En Search Console, lo más importante tras el cambio es observar cobertura e indexación. Si tenía la propiedad configurada para una versión y ahora consolida en otra, conviene asegurarse de que controla ambas a nivel de propiedad de dominio. Eso facilita ver si Google sigue rastreando la versión antigua. Además, revise si hay picos de errores 404 o soft 404 tras la consolidación, sobre todo si antes existían URLs con redirecciones raras.

Si la web es grande o tiene mucho tráfico, trate el cambio como una mini migración controlada. No hace falta dramatizar, pero sí actuar con método: cambios medidos, verificación de redirecciones, purga de cachés y monitorización de logs. Con esto, el ajuste www o sin www se convierte en una mejora técnica, no en una fuente de pérdidas de tráfico.

Checklist final y pruebas rápidas para validar

Una vez haya aplicado cambios, el objetivo es validar de forma rápida que todo queda estable y que no hay sorpresas por caché. Esta lista le ayuda a revisar lo esencial sin perderse en detalles. Si completa el checklist y todo encaja, lo normal es que el problema quede resuelto de forma duradera.

• WordPress: “Dirección de WordPress” y “Dirección del sitio” coinciden y están en la versión final.
• DNS: “@” y “www” apuntan al mismo entorno, sin IPs antiguas ni registros conflictivos.
• Servidor: existe una sola regla de redirección de hostname, preferiblemente en un único lugar.
• HTTPS: el certificado cubre el dominio raíz y www, o al menos la versión que se usa para redirigir responde con SSL válido.
• Cloudflare: no hay reglas duplicadas con el servidor, caché purgada tras el cambio.
• Plugins: no hay dos plugins intentando forzar URL o HTTPS a la vez.
• Sitemap: contiene URLs finales y se ha regenerado si procede.

Después, haga pruebas concretas. Pruebe las cuatro combinaciones principales: HTTP y HTTPS con y sin www. En todas, la URL final debe ser exactamente la misma. Si hay dos saltos, valore si puede reducirlos a uno, aunque dos saltos estables no siempre son un problema grave. Lo que sí conviene evitar es un tercer salto o una alternancia.

También es útil probar una URL interna, por ejemplo una entrada y una página, en las dos versiones. Esto confirma que la regla conserva la ruta y no rompe enlaces permanentes. Si al entrar por la URL interna le manda siempre a la home, algo está reescribiendo mal o la regla está incompleta.

Finalmente, deje pasar un pequeño margen para que la caché global se estabilice. Si ha tocado DNS, puede haber resolvers que aún apunten al destino antiguo. Si ha tocado Cloudflare, puede haber edge nodes con respuestas antiguas cacheadas. Lo importante es que, en su servidor y en WordPress, la configuración sea coherente. Con eso, el sistema tenderá a estabilizarse a medida que se renueve la caché externa.

Preguntas frecuentes