Arreglar redirección a www o sin www en WordPress

Qué significa elegir www o sin www y por qué debes ser consistente

Tu web puede funcionar con www o sin www, pero conviene que solo una sea la URL principal del sitio. A efectos técnicos y SEO, ambas versiones son hosts distintos. Si WordPress muestra una, el servidor fuerza otra y Cloudflare reescribe una tercera, puede producirse un conflicto de reglas.

La decisión entre una u otra no suele afectar al posicionamiento por sí misma; lo importante es la consistencia. La versión elegida debe coincidir en la URL principal, en la redirección, en las etiquetas canonical y en los recursos servidos por caché o CDN.

Cómo identificar dónde se está produciendo la redirección

Antes de cambiar nada, revisa la secuencia real. Lo importante es saber si el salto ocurre en WordPress, en Apache, en Nginx, en Cloudflare o en una combinación de capas. Normalmente, los problemas aparecen cuando hay más de una redirección intentando resolver lo mismo.

• Comprueba si http pasa a https y después a www, o al revés.
• Detecta si existe una cadena de redirección en lugar de un salto único.
• Si aparece un error de demasiadas redirecciones, suele haber un bucle HTTP HTTPS o reglas duplicadas entre servidor y CDN.

Revisar WordPress: WordPress Address y Site Address

Empieza por Ajustes > Generales. Ahí debes revisar WordPress Address y Site Address. La primera apunta a dónde está instalado WordPress; la segunda define la URL pública del sitio. En muchas webs coinciden, pero no siempre.

Si una URL está con www y la otra sin www, WordPress puede generar enlaces, recursos o redirecciones inconsistentes. También conviene revisar si estas constantes están fijadas en wp-config.php, porque en ese caso el panel no tendrá prioridad.

Una vez definida la URL principal correcta, no pases aún a editar reglas si antes no confirmas que DNS y proxy apuntan donde deben.

Comprobar DNS, servidor y CDN antes de tocar reglas

Aquí conviene separar capas, porque no son equivalentes.

DNS

Revisa los registros A/AAAA del dominio raíz y el CNAME o registro equivalente de www. Ambos deben resolver de forma coherente hacia tu infraestructura. Un DNS correcto no hace la redirección por sí mismo, pero una resolución incorrecta puede enviar cada host a un destino distinto.

Apache/.htaccess

Si tu servidor usa Apache, revisa .htaccess y confirma que no existan reglas repetidas para forzar www, quitar www y además forzar https por separado. Lo más estable suele ser una única lógica de redirección, adaptada al entorno.

Nginx

En Nginx, la revisión debe hacerse en los bloques de servidor. Conviene comprobar qué server_name responde y dónde se aplica la redirección. Si hay varios bloques para HTTP y HTTPS, una diferencia mínima entre ellos puede crear saltos inesperados.

Cloudflare

Si usas Cloudflare, revisa reglas de redirección, modo SSL y caché. Un Cloudflare redirect puede entrar en conflicto con reglas del origen. Además, el modo SSL influye mucho: una configuración inadecuada puede provocar bucles entre el proxy y el servidor.

Cómo configurar la redirección 301 sin crear bucles

La regla práctica es simple: aplica una sola redirección 301 hacia la versión final del dominio, preferiblemente en la capa más adecuada de tu arquitectura. Evita repartir la misma lógica entre varias capas.

DNS

DNS no sustituye una redirección 301. Su función es resolver el host correcto para que la petición llegue al punto donde sí se aplicará la redirección.

Apache/.htaccess

Si trabajas con Apache, una regla orientativa puede ser útil, pero debe adaptarse a tu hosting, a tu proxy y a si el HTTPS se termina en origen o delante del servidor. No añadas una regla nueva sin eliminar antes las antiguas que hagan lo mismo.

Nginx

En Nginx, normalmente se define el host secundario para devolver 301 a la versión canónica. Si además fuerzas HTTPS, conviene que el salto sea directo a la URL final para evitar cadenas.

Cloudflare

Si eliges hacer la redirección en Cloudflare, evita duplicarla en origen salvo necesidad clara. En entornos con proxy activo, suele ser mejor centralizar la política de host y protocolo para reducir inconsistencias y facilitar el diagnóstico de problemas como el error 404 en WordPress tras migración.

Errores frecuentes con HTTPS, SSL y canonical en WordPress

El fallo más común no es elegir mal entre www y sin www, sino mezclarlo con el SSL redirect. Si Cloudflare entrega HTTPS al visitante pero el origen no interpreta bien esa cabecera, WordPress o el servidor pueden intentar redirigir otra vez.

También conviene revisar la canonical en WordPress. Si la web redirige a una versión pero las canonical apuntan a otra, enviarás señales contradictorias. Lo mismo puede ocurrir con plugins de SEO, sistemas de caché o ajustes antiguos guardados en base de datos.

Si necesitas validar criterios base de URL del sitio, la documentación oficial de WordPress sobre direcciones del sitio puede servir como referencia técnica.

Qué revisar después del cambio para no perjudicar el SEO

• Que la versión no canónica responda con 301 en un solo salto.
• Que no haya mezcla entre http/https ni entre www/sin www en menús, imágenes o scripts.
• Que la etiqueta canonical apunte a la URL final correcta.
• Que la caché del servidor y la caché de Cloudflare estén purgadas tras el cambio.
• Que no existan reglas heredadas en plugins, panel de hosting o CDN.

El criterio correcto es elegir una única versión canónica del dominio y hacer que WordPress, DNS, servidor, HTTPS y CDN apunten a ella sin contradicciones. Tocar varias capas a la vez aumenta el riesgo de bucles y cadenas de redirección. Si el problema persiste, el siguiente paso razonable es auditar la configuración completa antes de seguir cambiando reglas.