Migrar a HTTPS y unificar el www en una sola versión del dominio es la canonicalización de raíz: las cuatro combinaciones posibles, con y sin www, con y sin cifrado, deben converger en una sola con redirecciones permanentes, la versión única donde todas las señales se concentran, y el lugar del trabajo es el .htaccess, el archivo de reglas del servidor donde el bloque correcto resuelve todo y el incorrecto fabrica bucles y cadenas. Esta guía entrega el método probado en producción: el bloque compatible con Cloudflare que el stack KOM usa, el orden de reglas que evita los saltos dobles, y la verificación de cadenas de redirección que confirma el destino en un solo brinco, porque la unificación bien hecha es invisible y la mal hecha es el sitio caído un domingo.
Tabla de Contenidos
¿Por qué unificar y qué pasa si no?
Las cuatro versiones del dominio son cuatro sitios para los buscadores: el con www y el sin, el HTTP y el HTTPS, cada combinación una URL distinta del mismo contenido, el duplicado de raíz que diluye señales cuando las versiones conviven sin redirección, los enlaces externos repartidos entre variantes, las posiciones fragmentadas, y la unificación lo resuelve de una vez, la versión canónica elegida, el HTTPS sin www o con él según la historia del dominio, las otras tres redirigiendo permanente hacia ella, el embudo de señales que concentra todo. El costo de no hacerlo es silencioso y constante: la dilución que nadie ve en un informe pero que pesa en cada evaluación, y el costo de hacerlo mal es ruidoso, los bucles infinitos del SSL mal coordinado, las cadenas de tres saltos que desperdician rastreo, los clásicos que el método de esta guía evita. El marco vive en la guía maestra de SEO local y el servicio en consultoría SEO.
Paso 1: elige tu versión canónica y prepara el terreno
La decisión previa define todo: la versión única elegida con criterio de historia, el dominio que siempre fue con www la conserva, el que vivió sin él sigue sin él, las señales acumuladas mandan sobre la estética, el cambio de versión histórica es una migración con costos que solo se paga con razones, y para el dominio nuevo la elección es libre, el sin www como la tendencia limpia del stack. La preparación evita sustos: el certificado SSL activo y válido en el servidor de origen, el requisito del Full Strict de Cloudflare de esta serie, el respaldo del .htaccess actual antes de tocar, la copia que permite revertir en segundos, la revisión de las reglas existentes, los bloques previos de plugins y configuraciones pasadas entendidos antes de sumar, porque el .htaccess es secuencial y las reglas viejas interactúan con las nuevas, el inventario que el paso dos ordena. La coordinación con Cloudflare se anota: el proxy activo cambia cómo llegan las peticiones, la cabecera del visitante que las reglas deben leer, el detalle que separa el bloque compatible del que entra en bucle.
Paso 2: el bloque .htaccess compatible con Cloudflare
El bloque del stack resuelve en un salto: las reglas que detectan el protocolo real detrás del proxy, la cabecera de visitante de Cloudflare leída para saber si la petición original fue HTTP, la condición que evita el bucle clásico, el servidor que no ve el HTTPS del borde y redirige infinito, y la redirección combinada hacia la versión canónica, el HTTP y el www incorrecto resueltos en una sola regla hacia el destino final, el salto único que las cadenas de reglas separadas no logran, [DATO-KOM: el bloque .htaccess exacto probado por KOM con Cloudflare, las líneas del manual interno con sus comentarios]. El orden de reglas manda en el archivo: el bloque de canonicalización temprano, antes de las reglas de WordPress, las redirecciones específicas de contenido después, la secuencia que el servidor evalúa de arriba abajo respetada, y las duplicaciones evitadas, la redirección de HTTPS que algunos plugins también intentan desactivada en un solo lugar, la regla de esta serie, cada trabajo en una sola capa, el .htaccess o el plugin, no ambos peleando.
Paso 3: verifica los saltos únicos y las cuatro rutas
La verificación prueba las cuatro combinaciones: cada versión del dominio consultada con herramientas de cabeceras, el HTTP sin www, el HTTP con www, el HTTPS con la versión incorrecta, cada una respondiendo con su redirección permanente directa al destino canónico, el código correcto y el salto único confirmados, y las cadenas cazadas, la versión que llega en dos brincos delatando reglas en serie, el HTTP a HTTPS y luego al sin www, la cadena que se corrige combinando hacia el destino final directo. Las pruebas cubren rutas internas además de la portada: la página profunda consultada en sus versiones, la redirección conservando la ruta completa, el artículo viejo en HTTP llegando a su HTTPS exacto y no a la home, el error de redirección genérica que mata el valor de los enlaces históricos, y las herramientas en línea de cadenas de redirección como el verificador cómodo, la URL probada con su secuencia de saltos visible, el diagnóstico de un minuto por ruta que confirma el trabajo limpio.
Paso 4: el post-migración y la vigilancia
El cierre actualiza el ecosistema: la consola de búsqueda con la propiedad de la versión canónica operando, los sitemaps regenerados apuntando todo a la versión única, las canónicas del sitio verificadas coherentes, la guía de esta serie aplicada, los enlaces internos auditados, los absolutos viejos con HTTP o el www incorrecto reescritos, la cadena interna evitada, y las herramientas externas al día, el perfil de Google, las citations de esta serie, los enlaces que controlas migrados a la versión final. La vigilancia de las semanas siguientes cierra: la consola monitoreada, los errores de rastreo atendidos, el informe de indexación mostrando la consolidación, las versiones viejas saliendo y la canónica concentrando, y la prueba de contenido mixto donde el HTTPS es nuevo, los recursos internos cargando cifrados, las imágenes y scripts sin las URLs HTTP que rompen el candado, la revisión que completa la migración de verdad, porque el HTTPS con contenido mixto es el candado roto que asusta visitantes, el detalle final del trabajo bien terminado que el visitante percibe como el candado intacto.
Preguntas frecuentes
¿Por qué mi sitio entró en bucle al activar la redirección HTTPS?
El clásico del proxy: Cloudflare entrega al servidor la petición ya procesada, el servidor no ve HTTPS y vuelve a redirigir infinito, y la solución es el bloque compatible, la condición que lee la cabecera del visitante para conocer el protocolo original, más el SSL Full Strict coordinado. El bucle se corta corrigiendo la condición: la regla ciega reemplazada por la que entiende el borde.
¿La redirección 301 pierde algo de autoridad?
La permanente moderna transfiere completo: los buscadores confirmaron hace años que el 301 pasa las señales íntegras, la mudanza sin impuesto, y la pérdida real está en las cadenas y los errores, los saltos múltiples que diluyen rastreo, las redirecciones a destinos genéricos que tiran el valor de la ruta. El método de esta guía protege eso: el salto único a la URL exacta equivalente.
¿Cambio mi versión con www a sin www por estética?
Solo con razones que paguen la migración: la versión histórica acumula señales y enlaces, el cambio es una mudanza completa con su riesgo y su reacomodo, y la estética no lo amerita. La regla práctica del stack: el dominio establecido conserva su versión, la unificación se hace hacia lo que ya eres, y el cambio de versión se reserva para las refundaciones con motivo real.
¿KOM ejecuta esta migración como servicio?
Dentro de la base técnica: el bloque compatible implementado, las cuatro rutas verificadas en salto único, el post-migración completo con consola, sitemaps y enlaces internos, dentro de la consultoría cotizada en el cotizador online con los precios públicos de siempre. La canonicalización de raíz se hace una vez y bien: la base única sobre la que todas las demás señales de esta serie construyen.
Tu siguiente paso: prueba tus cuatro versiones del dominio con un verificador de redirecciones y cuenta los saltos, el diagnóstico de cinco minutos que revela bucles y cadenas. La migración completa se cotiza en el cotizador online: tu dominio tiene cuatro puertas y debe tener una sola, y el bloque correcto en el .htaccess es la diferencia entre la unificación invisible y el domingo de sitio caído.
