Cómo forzar para que WordPress cargue con HTTPS (servidor Apache)

Siempre debe cargar tu sitio con HTTPS. Además de proteger la integridad de los datos entre tus sitios y los usuarios de tu sitio, HTTPS es un requisito para muchas API’s nuevas. Por ejemplo, las API’s de geolocalización.

HTTPS también tiene cierto peso al momento de la clasificación en las SERP de Google. Por lo tanto, asegurarte de que tu sitio siempre se cargará desde HTTPS es crucial. Te mostraremos cómo hacerlo con Apache en este tutorial.

Ten en cuenta que antes de continuar con este paso, asegúrate de tener el certificado SSL instalado y cargado en el servidor. De lo contrario, debes consultar nuestro tutorial sobre la guía para principiantes de certificados SSL en sitios web.

Si todo está configurado, puedes continuar con el siguiente paso.

HTTP a HTTPS

Si puedes acceder a tu sitio web de WordPress directamente en http://www.domain.com y deseas dirigir a todos los visitantes de HTTP a HTTPS, intenta con cualquiera de los siguientes códigos .htaccess.

Opción 1:

Opción 2:

Explicación

Ambas opciones 1 y 2 redirigirán a cualquiera que acceda a http://www.domain.com a https://www.domain.com

Los códigos de la opción 1 verificarán si la conexión es TLS/SSL, mientras que los códigos de la opción 2 verificarán si el sitio se ejecuta en un puerto 80 que, de forma predeterminada, es el número de puerto de HTTP.

Nota: En general, es preferible usar los códigos de la Opción 1. La sintaxis es más expresiva y redirigirá a HTTPS independientemente del número de puerto porque el sitio puede cargar con un puerto HTTP 80 externo.

“no www” > “www” y HTTP> HTTPS

Si deseas forzar “no www” a “www” y HTTP a HTTPS, entonces los códigos .htaccess anteriores no serán suficientes.

Para poner las cosas en perspectiva, si tu objetivo es redirigir las siguientes URL’s:

http://www.domain.com

http://domain.com

A

https://www.domain.com

Entonces deberá usar los códigos .htaccess a continuación.

Explicación

Primero, redirige cualquier “no www” a “www”, luego verifica si hay HTTPS, asegurándose de que el resultado final sea: www + HTTPS.

“no www” > “www” y HTTP > HTTPS (en subcarpeta)

Ahora, si tú, como nosotros, alojas tu sitio de WordPress en una subcarpeta (es decir www.domain.com/blog/), entonces los códigos .htaccess mencionados anteriormente no funcionarán perfectamente.

El objetivo aquí es redirigir todas las URL’s (independientemente de si es la página de inicio o las páginas de publicación) a una URL www + HTTPS.

Echemos un vistazo a todas las posibilidades de URL que necesitaremos para redirigir ” desde ” y redirigir ” a “.

Condición 1

Necesitamos redirigir todas las siguientes URL desde:

  • http://domain.com
  • http://www.domain.com
  • http://domain.com/blog/
  • http://www.domain.com/blog/

a una URL unificada de:

  • https://www.domain.com/blog/

Condición 2

y publicar URL de:

  • http://domain.com/blog/example-page/
  • http://www.domain.com/blog/example-page/

a:

  • https://www.domain.com/blog/example-page/

Cuando tu WordPress está alojado en una subcarpeta (por ejemplo /blog/), es probable que tenga dos archivos .htaccess. Es decir, un archivo .htaccess fuera de la subcarpeta y uno dentro de la subcarpeta donde está instalado WordPress. Y tendremos que alterarlos a ambos.

.htaccess fuera de la subcarpeta

Inserta los siguientes códigos en .htaccess fuera de la subcarpeta.

Esto es lo que hace esta parte del código. Primero, se asegura de que el dominio se redirija a www con HTTPS, luego se redirige a la subcarpeta. Esto satisfará la condición # 1 mencionada anteriormente, pero no funcionará para la condición # 2, al menos no todavía.

.htaccess dentro de la subcarpeta

A continuación, tendremos que modificar el código .htaccess dentro de la subcarpeta.

Por defecto, debería verse así:

Debes colocar el siguiente código .htaccess en la parte superior, y antes de “# BEGIN WordPress”.

Con estos dos conjuntos de códigos, te asegurarás de que cualquier URL ingresada se incluya con www y HTTPS.

Insto a que no implemente esto en su sitio en vivo. Pruébalo varias veces en un sitio de ensayo/prueba, asegurándote de obtener los resultados que desea antes de implementarlo en vivo.

Una cosa más, para garantizar que tu redirección sea precisa, asegúrate de borrar las cookies del navegador y el caché antes de comenzar cada prueba.