Hace unos días os hablaba de cómo realizar una migración web hacia un servidor NGINX, pero no todo van a ser location; no podemos olvidarnos de los servidores Apache. Si bien la mayoría de pasos ante una migración ya los compartí en el anterior artículo, la sintaxis de las expresiones regulares para realizar redirecciones en Apache cambian un poco, al igual que el archivo dónde incluimos las mismas. Seguramente os suene ese archivo que encontramos generalmente en la raíz de nuestro alojamiento que se llama .htaccess, pues resulta clave cuando hablamos de redirecciones en este tipo de servidor web, ya que será aquí donde las incluyamos posteriormente.
Vamos a hablar de...
¿Qué es un servidor Apache?
Al igual que NGINX, se trata de un servidor HTTP de código abierto muy extendido. Según nuestra amiga la Wikipedia, su nombre se debe al deseo de tener connotaciones relacionadas con la firmeza propias de la tribu Apache, que fue la última en rendirse ante el futuro gobierno de Estados Unidos. Al margen de todo esto, como decía, es uno de los servidor más extendidos, siendo realmente el más utilizado y jugando un papel clave en el desarrollo de Internet. Fue en 2005 cuando alcanzó su cuota de utilización más alta, con un 70% de los sitios web de la red. Pero vamos a lo que nos interesa…
¿Qué es eso de .htaccess?
El archivo hypertext access, .htaccess para los amigos, es el lugar donde los servidores Apache encuentran las órdenes personalizadas para la web en cuestión. Debemos tener en cuenta que un archivo .htaccess aplica todas sus directivas al directorio en el que se encuentra y a todos su subdirectorios, solo pudiendo aplicar reglas específicas a un directorio en concreto si incluimos un nuevo .htaccess en el mismo. A nivel de permisos, siempre nos va a interesar que tenga un 644 para que se pueda leer y únicamente pueda escribir el propietario del alojamiento. Como último punto para añadir sobre este archivo, debemos asegurarnos siempre de guardarlo con una codificación UTF-8 sin BOM.
Debo hacer hincapié también en el hecho de que se trata de un archivo sensible, pues si no sabemos demasiado de su control lo más seguro es que podamos causar un buen estropicio en nuestra web. Y aquí he de confesar que yo no soy ningún experto, pero te garantizo que las directivas de redirección son especialmente sencillas y nos resultará muy difícil de equivocarnos, más allá de provocar algún que otro bucle infinito si no hemos afinado lo suficiente.
¿Cómo hago redirecciones en el .htaccess?
Al igual que os decía cuando hablaba de NGINX, las redirecciones más comunes van a ser la 301 (permanente) y la 302 (temporal). Pero entre estas dos, deberemos también tener en cuenta cuál es el objetivo de nuestras redirecciones. ¿Cambiamos de dominio? ¿Solo queremos establecer equivalencias? ¿Nos mudamos a https?
Pues bien, la redirección tanto de un dominio a otro como de un directorio a otro comparten una misma sintaxis, que es la siguiente:
Redirect 301 /directorio-viejo/ http://www.dominio.com/directorio-nuevo/
De esta manera, indicamos que estamos haciendo una redirección 301 (la 302 se hace cambiando el número, vamos) de http://www.dominio.com/directorio-viejo/ a http://www.dominio.com/directorio-nuevo/. Sencillo, ¿verdad? Vamos a complicarlo.
Redirect 301 /viejo-directorio/ http://www.dominio.com/nuevo-directorio/hijo/
La fórmula es la misma, pero lo que hemos hecho es llevar un directorio de primer nivel a uno de segundo, y así podemos hacer hasta donde queramos. Lo complico un poco más.
RedirectMatch 301 ^/viejo-directorio/(.*)$ http://www.dominio.com/nuevo-directorio
Vaya, aquí la regla ha cambiado un poco. Usamos RedirectMatch en este caso para especificar que TODAS las páginas que comiencen por /viejo-directorio/ se dirijan a http://www.dominio.com/nuevo-directorio/. Un caso muy útil cuando nos vemos obligados a redirigir multitud de productos a una nueva categoría, por ejemplo. Y ahora lo hago más rebuscado.
RedirectMatch 301 ^/pagina/prod(.*)$ http://www.dominio.com/
¿Qué hago aquí? Pues básicamente hacer que todas las url que cuelguen de /pagina/ y comiencen por la cadena «prod» vayan a http://www.dominio.com/. Y ahora surge otro caso…
RedirectMatch 301 /pagina/prod(.*)$ http://www.dominio.com/
¿Cuál es la diferencia con respecto a la anterior? Pues que le hemos quitado el carácter ^ previo a la url antigua. Esto lo que provoca es un caso sensitivo, lo que quiere decir que quitamos la exactitud de que comience con esa cadena y lo que le estamos diciendo es que CUALQUIER coincidencia, independientemente de en qué nivel de la url se encuentre, con /pagina/prod llevará a http://www.dominio.com. En resumen, si pusiéramos en el navegador http://www.dominio.com/pagina-inventada/hola/pagina/producto.html nos llevaría a http://www.dominio.com/ porque localiza la url anterior como caso sensitivo. ¿Lo vas pillando?
¿Cómo fuerzo el https en un servidor Apache?
Si queremos que todas nuestras url tengan https en lugar de http, podemos hacer una a una todas las url o realizar un forzado:
<IfModule mod_rewrite.c>
RewriteCond %{HTTPS} off
RewriteRule (.*) https://www.dominio.com/$1 [R=301,L,QSA]
</IfModule>
Y esto es todo. No me quiero extender demasiado en este artículo porque ya expliqué cómo hacer la migración en un artículo anterior, de modo que espero que os haya servido para aplicarlo en el caso de un servidor Apache. Desde mi punto de vista, este tipo de servidores y redirecciones son mucho más amables con los inexpertos, con una sintaxis algo más sencilla. ¡A probarlo!
