Archivo .htaccess en WordPress: configuraciones básicas de optimización

¡CON UN 20% DE DESCUENTO!

Archivo .htaccess: ¿qué podemos conseguir con él?

Cuando montamos un sitio web o un blog, nos centramos principalmente en sus aspectos más visibles y evidentes, tomando decisiones acerca del diseño de las páginas, su distribución o el tipo de contenido que vamos a incluir, entre otros. En definitiva, cómo queremos que los usuarios vean y naveguen a través de nuestros contenidos, productos o servicios.

Desde el punto de vista tecnológico, también debemos tomar decisiones pero, para webs de tamaño medio, las modernas y potentes herramientas de gestión actuales reducen su rango prácticamente a las dos siguientes:

• La selección de la plataforma de gestión de contenidos, como WordPress, Prestashop o Drupal, sobre la que construir el sitio web e incorporar los contenidos y servicios.
• La selección del proveedor de hosting que alojará el sitio web para que pueda accederse libremente a través de Internet.

Una vez montado y operativo el sitio web, toda la administración, gestión y mantenimiento del sitio web gira al gestor de contenidos, pues a través de él actualizamos los contenidos y servicios del sitio web. Mientras que al servidor de alojamiento se le suele prestar poca o ninguna atención, confiando toda su gestión al proveedor.

Sin embargo, también tenemos capacidad de administración y configuración del servidor de alojamiento. No del servidor físico como tal (esto es, el ordenador), sino del servidor web que sirve las páginas web a los navegadores bajo petición de los usuarios.

En servidores equipados con el servidor web Apache, esta administración se realiza a través del archivo .htaccess (“hypertext access”), consistente en un fichero de texto con comandos e instrucciones que determinan el comportamiento o la respuesta que debe tener el servidor ante las peticiones de los usuarios, condiciones externas, tipos de páginas, etc.

Si bien las instrucciones por defecto del fichero .htacces son suficientes para garantizar el perfecto funcionamiento del sitio web, podemos (y deberíamos) modificarlo para optimizar el rendimiento y la seguridad (y, por extensión, del sitio web en WordPress u otro gestor), de una forma tal que no podríamos conseguir tan eficazmente con otros mecanismos, como el fichero robots.txt u optimizaciones del gestor de contenidos.

Cómo modificar el archivo htaccess en WordPress sin riesgos

Dado que influye directamente en la respuesta del servidor web, un archivo .htaccess mal configurado puede provocar un funcionamiento anómalo de nuestro sitio web, impidiendo que el usuario pueda navegar libremente a través de él o incluso haciendo que el sitio no responda en absoluto (por ejemplo, un error interno de servidor HTTP 500).

Por este motivo, no sólo debemos tener cuidado de escribir los comandos correctamente y sin erratas, sino tomar algunas precauciones básicas tanto para restaurar el fichero como para localizar un error en caso de que se produzca algún problema:

• Hacer una copia del archivo .htaccess actualmente en uso antes de modificarlo, añadiendo un número de versión al nombre del fichero que lo distinga de otras copias.
• Incluir comentarios para cada comando o grupo relacionado de comandos utilizado en el fichero, para que cuando lo revisemos en el futuro podamos recordar su cometido sin tener que descifrar los comandos.
• Incluir la fecha de modificación como un comentario en la primera línea del fichero, por si fuera necesario rastrear los errores y los cambios realizados.
• ¡Muy importante! Si vamos a cambiar varios comandos o parámetros, aplicar las modificaciones una a una, comprobando cada vez que el sitio web responde normalmente y podemos navegar por él sin problemas. Si hiciéramos todos los cambios de una vez y se produjera un comportamiento anómalo, no sabríamos cuál lo habría provocado.

Con estas precauciones, podemos modificar el archivo .htacces de tres formas:

• A través del panel de control del servidor de alojamiento. Por ejemplo, cPanel o Plesk incluyen un administrador de archivos que nos permite movernos a través de la estructura de carpetas del servidor y editar directamente los ficheros de texto. Debes consultar con tu proveedor de hosting los datos de acceso a tu panel de control.
• A través de un cliente FTP. La mejor opción, pues nos descargamos el fichero en nuestro equipo y podemos modificarlo tranquilamente hasta que terminemos y lo volvamos a subir. También hace muy fácil la creación Y gestión de copias de seguridad. FileZilla es un cliente FTP gratuito y fácil uso idóneo para esta tarea.
• A través del gestor de contenidos. En el caso de WordPress, no se puede hacer directamente, sino que necesita un plugin, como File Manager o Yoast SEO para WordPress. No recomiendo esta opción, porque la creación de copias de seguridad puede ser engorrosa y porque un error en el .htaccess puede impedir que podamos siquiera acceder al gestor de contenidos para deshacer el error.

Como el archivo .htaccess es un simple fichero de texto, lo que en caso de error tanto solo hay  que borrarlo o, mejor, cambiarlo de nombre para poder revisarlo después tranquilamente. Entonces, basta con cambiar el nombre de la última copia para que sea de nuevo el .htaccess en funcionamiento.

Configuraciones recomendadas de .htaccess

La configuración del fichero .htaccess puede ser muy compleja, dada su diversidad de comandos e instrucciones. Afortunadamente, existe un conjunto de configuraciones que son válidas para prácticamente todos los sitios web y que, con pequeñas modificaciones para adaptarlas a nuestro sitio web, podemos incorporarla a nuestro .htaccess.

Aun siendo configuraciones probadas y seguras, no deberíamos copiarlas todas de un vez en el fichero .htaccess de nuestro servidor, sino seguir las precauciones descritas en el punto anterior. Es decir, añadirlas de una en una y asegurarnos cada vez que el sitio web sigue funcionando con normalidad.

A continuación vamos a ver estas configuraciones, agrupadas en función del tipo de mejora que aportan o del área del servidor que afectan.

En las líneas donde aparezca el texto “mi-dominio.com”, sustituidla por el dominio correcto de vuestro sitio web.

Requerido para el funcionamiento del gestor de contenidos

Los gestores de contenidos pueden añadir varias líneas de instrucciones en el archivo .htaccess, necesarias para que operen correctamente o según los configuremos. Estas instrucciones están debidamente señalizadas mediante comentarios en el fichero y no debemos modificarlas en ningún caso, bajo riesgo de que el sitio web deje de responder.

Por ejemplo, en el caso de WordPress, para dar soporte a la configuración de los enlaces permanentes, añade las siguientes instrucciones (puede haber variaciones según la versión del WordPress y el tipo de enlace permanente seleccionado):

# BEGIN WordPress
<IfModule mod_rewrite.c>
rewriteEngine On
rewriteBase /
rewriteRule ^index\.php$ - [L]
rewriteCond %{REQUEST_FILENAME} !-f
rewriteCond %{REQUEST_FILENAME} !-d
rewriteRule . /index.php [L]
</IfModule>
# END WordPress

En general, no deberíamos modificar ninguno de los comandos del .htaccess tal como nos lo entrega el proveedor de alojamiento y limitarnos a añadir nuestros propios comandos después de este bloque..

Mejorando la seguridad del sitio web

1. Proteger el fichero .htaccess (y derivados)

Impedir que nadie pueda acceder a nuestro archivo .htaccess y ver su contenido. De esta forma, estamos impidiendo que se pueda leer desde Internet y alguien saque alguna información sobre nuestro servidor a partir de sus comandos.

El siguiente fragmento no sólo protege el fichero .htaccess, sino todo aquel que empiece por “.hta”, por si tuviéramos más copias, para proteger todas ellas:

## Proteger ficheros .hta*
<Files ~ "^.*\.([Hh][Tt][Aa])">
order allow,deny
deny from all
satisfy all
</Files>

2. Proteger el fichero wp-config.php

El fichero wp-config.php forma parte de la instalación de WordPress y contiene información muy sensible del gestor de contenidos, como datos de configuración y conexión a la base de datos de WordPress, y debemos impedir que se pueda acceder desde el exterior:

## Proteger fichero wp-config.php
<Files wp-config.php>
order allow,deny
deny from all
</Files>

3. Proteger ficheros de una determinada extensión

La misma operación de protección que hemos hecho con los archivos .htaccess y wpconfig.php la podemos hacer con otros ficheros, utilizando sus respectivos nombres. Pero también podemos proteger ficheros a partir de sus extensiones:

## Proteger ficheros con extensiones .php, .inc, .ini o .log
<FilesMatch "\.(php|inc|ini|log)$">
order allow,deny
deny from all
satisfy All
</FilesMatch>

Cuidado con incluir las extensiones .css y .js (hojas de estilo y ficheros javascript, respectivamente), porque entonces los rastreadores de los buscadores no podrían acceder a estos ficheros para renderizar las páginas y podría penalizar nuestro posicionamiento SEO.

4. Proteger ficheros y directorios ocultos

El servidor web Apache se ejecuta en sistemas Unix/Linux, en los que los ficheros y directorios que empiezan por un punto (“.”) son ocultos o ficheros de sistema y que, en general, no deberían ser de acceso libre. Podemos protegerlos con este fragmento:

## Proteger ficheros y directorios ocultos
rewriteCond %{SCRIPT_FILENAME} -d [OR]
rewriteCond %{SCRIPT_FILENAME} -f
rewriteRule "(^|/)\." - [F]

Observad que el fichero .htaccess (y copias con nombre similar) también quedaría protegido utilizando este fragmento.

5. Impedir que se vea el listado de ficheros de los directorios

Con este fragmento, evitamos que nadie pueda navegar a través de la estructura de directorios de nuestro sitio web ni vea los ficheros que hay en cada directorio, sino que debe acceder necesariamente a una página web existente:

## Bloquear la navegación por directorios
options All -Indexes

6. Evitar el HotLinking (robo de ancho de banda)

El HotLinking se produce cuando alguien enlaza las imágenes u otros recursos de tu servidor desde sus propias páginas, por lo que se descargan consumiendo de nuestro ancho de banda cuando alguien accede a las páginas de este intruso.

Con este fragmento evitamos este atropello y, además, podemos devolver una imagen con algún mensaje para reivindicar nuestros derechos (podéis ver un ejemplo muy bueno en este artículo sobre plagio de contenidos):

## Impedir que se descarguen imágenes GIF, JPG, JPEG o PNG desde webs externas
rewriteEngine On
rewriteCond %{HTTP_REFERER} !^$
rewriteCond %{HTTP_REFERER} !^http://(www\.)?mi-dominio.com/.*$ [NC]
rewriteRule .*\.(gif|jpg|jpeg|png)$ http://www.mi-dominio.com/mira-que-eres-pillo.gif [R,L]

7. Proteger contra algunos ataques XST y XSS

Los ataques XST (“Cross Site Tracing”) y XSS (“Cross Site Scripting”) pueden utilizar algunos métodos especiales del protocolo HTTP (utilizado para descargar páginas web) para intentar acceder a información protegida del servidor. El siguiente fragmento lo evita desactivando estos métodos (aunque es probable que el proveedor de hosting ya lo haya hecho por defecto):

## Desactivar los métodos TRACE y TRACK de HTTP
rewriteEngine on
rewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
rewriteRule .* - [F]

8. Proteger el fichero xmlrpc.php contra ataques de fuerza bruta

El fichero xmlrpc.php se utiliza para la notificación de los pingbacks y trackbacks de nuestros artículos; es decir, nos avisa cuando alguien enlaza desde el exterior con un artículo. Pero también puede ser utilizado por hackers para hacer ataques de fuerza bruta, colapsar nuestro servidor web e incluso acceder a información confidencial almacenada en el servidor.

A costa de dejar de recibir estas notificaciones, podemos impedir el acceso al xmlrpc.php para evitar este tipo de ataques:

## Proteger el fichero xmlrpc.php
<files xmlrpc.php>
order allow,deny
deny from all
</files>

¡CON UN 20% DE DESCUENTO!

Mejorando el rendimiento y tiempo de respuesta del sitio web

1. Comprimir páginas y otros archivos

Cuando un usuario solicita una página o cualquier otro archivo al servidor web, éste se la sirve tal cual se encuentra en su sistema de ficheros (junto con información adicional del protocolo HTTP, pero ésa es otra historia).

Si el servidor web tiene instalado algún módulo de compresión de datos (que es lo habitual), podemos activarlo en el .htacces para que páginas y archivos sean comprimidos antes de ser entregados al usuario.

De esta forma, al tener menos tamaño, tardan menos en transmitirse y el usuario percibe una navegación más rápida, con el consiguiente beneficio en la experiencia de usuario y el posicionamiento orgánico.

El servidor web Apache dispone de dos módulos para hacer esta compresión, GZIP y DEFLATE, y en el .htaccess debemos comprobar cuál está instalado para indicar que se compriman los datos:

## Comprimir los textos con GZIP (si está instalado)
<IfModule mod_gzip.c>
mod_gzip_on Yes
mod_gzip_dechunk Yes
mod_gzip_item_include file .(html?|txt|css|js|php|pl)$
mod_gzip_item_include handler ^cgi-script$
mod_gzip_item_include mime ^text/.*
mod_gzip_item_include mime ^application/x-javascript.*
mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.*
</IfModule>

## Comprimir los tectos con DEFLATE (si está instalado)
<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/text
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE text/javascript
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/x-javascript
AddOutputFilterByType DEFLATE application/xml application/xhtml+xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/x-httpd-php
AddOutputFilterByType DEFLATE application/x-httpd-fastphp
</IfModule>

Observad que no he incluido ficheros de imagen. Las imágenes suelen ser los ficheros más grandes y como parte de nuestra tarea siempre deberíamos procurar que todas las imágenes de nuestro sitio web estén optimizadas, por lo que no es necesario que el servidor web las comprima (lo que, al tratarse de ficheros grandes, consumiría recursos del servidor).

2. Modificar el tiempo de expiración del caché en el navegador

Cuando un usuario navega a través de un sitio web, las páginas y recursos que visita se almacenan temporalmente en una memoria temporal del navegador, la caché. De esta forma, si el usuario vuelve a visitar esos recursos, el navegador no necesita descargarlo sino que le muestra lo que tiene en caché, mejorando la velocidad de navegación.

Desde el archivo .htacces podemos controlar el tiempo máximo que un recurso puede permanecer en la caché del navegador. Normalmente, los servidores web establecen por defecto un tiempo de expiración a todos los ficheros pero, según el uso que hagamos de cada tipo de fichero, nos puede interesar cambiarlo y aumentar el tiempo de expiración para los recursos estáticos o casi estáticos (como imágenes o documentos).

De esta forma, el usuario seguirá disfrutando de un tiempo de respuesta rápido aunque pasen varias semanas desde su anterior visita (siempre y cuando el navegador no haya borrado los ficheros de su caché).

## Tiempo de expiración en caché de navegador (por cada tipo de recurso)
<IfModule mod_expires.c>
ExpiresActive On
## Tiempos de expiración distintos para cada tipo de fichero
ExpiresByType image/jpg "access 1 year"
ExpiresByType image/jpeg "access 1 year"
ExpiresByType image/gif "access 1 year"
ExpiresByType image/png "access 1 year"
ExpiresByType image/x-icon "access 1 year"
ExpiresByType text/css "access 1 month"
ExpiresByType text/x-javascript "access 1 month"
ExpiresByType application/x-shockwave-flash "access 1 month"
ExpiresByType application/pdf "access 1 month"
## Tiempo por defecto para todos los demás ficheros (1 semana)
ExpiresDefault "access plus 1 week"
</IfModule>

No es imprescindible que indiquemos el tiempo de expiración para cada tipo de recurso y bastaría con que solo incluyéramos el tiempo de expiración por defecto (en este fragmento, de 1 semana). En general, salvo que tengamos un sitio web bastante grande, con muchas visitas (miles diarias), una semana es un tiempo suficiente para todos los ficheros que, además, es el tiempo mínimo de caché de navegador que recomienda Google para sus tests de PageSpeed Insights.

3. Redirecciones 301 rápidas

Cuando reorganizamos nuestro sitio web, puede ocurrir que algunas páginas cambien de nombre o de localización. Para no perder el ranking de esas páginas ni los enlaces entrantes a sus direcciones originales, utilizamos redirecciones 301 a sus nuevas localizaciones.

Lo habitual, como usuarios de un gestor de contenidos, es utilizar plugins para hacer estas redirecciones. Sin embargo, como este sistema se ejecuta dentro del entorno gestor de contenidos, no es la solución más eficiente.

Hay varios sistemas para hacer redirecciones 301 en el archivo .htaccess sin necesidad de depender del gestor de contenidos, pero desde el punto de vista de rendimiento, la siguiente solución proporciona la mejor respuesta:

## Redirección 301 de páginas por cambio de nombre/localización
RewriteEngine On
RewriteRule ^/AntiguaCarpeta/NombrePagina.?$ "http://www.MiDominio.com/NuevaCarpeta/NuevoNombre" [R=301,L]

Es importante indicar el camino completo de la página original (esto, todas los directorios para llegar a esa página), puesto que si solo indicamos su nombre, entraríamos en un flujo infinito de redirecciones 301 de la página a sí misma.

También podemos utilizar esta solución para cualquier otro tipo de redirecciones (3xx), sustituyendo el número 301 por la redirección correspondiente.

Bloqueando el acceso a los bots maliciosos o abusones

1. Contra los Referrer Spam

Sin entrar en detalles técnicos, los referrer spam son bots que recorren los enlaces de nuestras páginas con el único propósito de que sus visitas queden registradas en el servidor, de forma que las direcciones URL así registradas sean rastreadas por los buscadores como si fueran enlaces entrantes (“backlinks”) que beneficien su posicionamiento SEO.

En lo que a nosotros respecta, nos producen tres graves perjuicios:

• Interfieren el análisis estadístico de los informes de Google Analytics, o cualquier otra herrameinta de Web Analytics que utilicemos, puesto que recorren todas las páginas de un sitio web con visitas de cero segundos de duración.
• Si son muy insistentes o numerosos pueden interferir el rendimiento del servidor web, puesto que debe servirles páginas web, aunque no las utilicen para nada.
• Los backlinks artificiales así creados pueden afectar a nuestro propio posicionamiento orgánico y a nuestra estrategia de Link Building (por ejemplo, apuntando desde nuestra web a sitio de dudosa reputación).

A través del fichero .htaccess podemos indicar al servidor web que bloquea las peticiones cuyas direcciones de referencia (“referrer”) correspondan con algún referrer spammer conocido:
Bloquear el acceso a referrer spammers conocidos

<IfModule mod_rewrite.c>
rewriteEngine on
rewriteCond %{HTTP_REFERER} ^http://.*spammer1\.com/ [NC,OR]
rewriteCond %{HTTP_REFERER} ^http://.*spammer2.\.ru/ [NC,OR]
## ... añadir una línea “rewriteCond” con la URL de cada spammer
rewriteCond %{HTTP_REFERER} ^http://.*spammer3\.com/ [NC]
rewriteRule ^(.*)$ – [F,L]
</IfModule>

Una vez añadido este código, no olvidemos que hay que revisarlo periódicamente, pues los referrer spammers cambian con el tiempo, precisamente para sortear estos bloqueos 🙁

2. Contra los spambots en los comentarios WordPress

Aunque posiblemente tengamos un plugin o complemento en nuestro gestor de contenidos para controlar el spam en los comentarios, también es posible hacer un primer filtrado en el archivo .htaccess, con lo que descargamos de trabajo al WordPress.

En concreto, este fragmento impide el acceso directo al formulario de comentarios de WordPress cuando la visita se produce por un spambot. Normalmente, estos bots no han navegado previamente por el sitio web para llegar al formulario (como haría un usuario humano) y este fragmento lo detecta:

rewriteEngine On
rewriteCond %{REQUEST_METHOD} POST
rewriteCond %{REQUEST_URI} \.wp-comments-post\.php*
rewriteCond %{HTTP_REFERER} !\.*mi-dominio.com\.* [OR]
rewriteCond %{HTTP_USER_AGENT} ^$
rewriteRule (\.*) ^http://%{REMOTE_ADDR}/$ [R=301,L]

3. Contra las visitas de bots “abusones”

Existen bots y aplicaciones que, sin ser maliciosos, pueden provocar una merma del rendimiento y tiempo de respuesta de nuestro servidor; por ejemplo, los bots asociados a aplicaciones que descargan el sitios web completo, con el consiguiente consumo de nuestro ancho de banda (megas y megas y megas…), o rastreadores de buscadores que no nos interesen (por ejemplo, Baidu, el buscador chino).

Podemos impedir el acceso a estos bots identificándolos a través de su “user-agent” (el nombre del bot) en el siguiente fragmento del .htaccess:

## Bloquear bots abusones
SetEnvIfNoCase user-Agent “^Offline.Explorer” bots_abusones
SetEnvIfNoCase user-Agent “^baidu.” bots_abusones
## Añadir una línea por cada bot abusón
SetEnvIfNoCase user-Agent “^bandit” bots_abusones
order allow, deny
allow from all
deny from env=bad_abusones

Conclusiones

Dado que la principal plataforma de interacción con nuestros sitios webs o blogs la realizamos a través del gestor de contenidos, la mayor parte de nuestros esfuerzos de optimización del rendimiento y la seguridad del servidor (y, por extensión, del posicionamiento orgánico) los abordamos también en ella.

Sin embargo, el proceso de servir una página al usuario en su navegador consta de dos pasos:

1. El primer paso lo constituye el servidor web, que recoge y procesa las peticiones de los usuarios, trasladándolas al gestor de contenidos cuando sea necesario para contestarles con las páginas o recursos solicitados.
2. En base a la petición del usuario recogida por el servidor web, el gestor de contenidos genera las páginas necesarias y se las entrega.

Obviar la existencia de ese primer paso se traduce en que no aprovechamos su potencial para realizar determinadas tareas que, sin embargo, sí estamos haciendo en el entorno del gestor de contenidos con mucha menor eficacia y consumiendo más recursos del servidor de alojamiento y del gestor de contenidos.

Con la adecuada configuración del archivo .htaccess, estas tareas se llevarían a cabo cuanto antes, con un menos tiempo de recursos, dejando al gestor de contenidos para que se dedique a su principal labor, generar páginas, y consiguiendo un comportamiento general del sistema mucho más eficiente.

Hemos visto algunas de las configuraciones más efectivas para la seguridad y el rendimiento de un servidor web, que no requieren un conocimiento avanzado de .htaccess. ¿Conoces otras configuraciones básicas que se puedan aplicar a la mayoría de sitios web? ¿O prefieres utilizar plugins del gestor de contenidos? ¿Por qué?

Imágenes: apache, elaboración propia.

Twitter

Facebook

email