[Publicada el 18 de mayo de 2015. Revisada en octubre de 2026]
Esta entrada arrastra ya unos cuántos años a sus espaldas y varias cosas se habían quedado desfasadas. He conservado lo que sigue teniendo sentido técnico y he corregido el resto. Había ejemplos de código que directamente no funcionaban y Apache ha metido cambios de peso en este tiempo. Cuando alguna directiva sea distinta de lo que escribí en 2015, te lo comento en su correspondiente apartado.
En su momento, cuando hablé sobre qué pasos dar tras instalar Drupal, comentaba que una de las primeras tareas debía ser configurar bien el fichero .htaccess. Aprovecho ahora para examinar con más detalle este archivo, un elemento fundamental dentro de cualquier servidor web Apache.
El fichero *hypertext access*, más conocido como [.htaccess], es una de las piezas centrales dentro de un servidor Apache, para el que fue diseñado en exclusiva. En 2015 sostuve que con el tiempo su uso se había extendido al resto de servidores web, pero la realidad me ha llevado la contraria: Nginx, muy habitual hoy en día, no lo lee en absoluto. LiteSpeed sí lo interpreta, aunque lo hace por pura compatibilidad con Apache. Si tu proveedor de alojamiento no utiliza Apache, este texto no te servirá de mucho.
En la mayoría de alojamientos compartidos resulta imposible que nos den acceso al fichero de configuración principal del servidor, el conocido *httpd.conf*. Por suerte, casi todas las modificaciones se pueden aplicar mediante el *.htaccess* de forma muy directa, ya que permite definir instrucciones de configuración para cada directorio y para todos los subdirectorios que dependan de él. La propia documentación de Apache aconseja recurrir al .htaccess únicamente cuando carecemos de acceso a la configuración global.
Contar con un fichero .htaccess en cada carpeta del servidor aporta una ventaja clara: permite ajustar los permisos y las reglas de acceso con bastante precisión dentro de esa estructura. Sin embargo, trae consigo un inconveniente que conviene no pasar por alto: perjudica la velocidad de carga de la web. En cada petición que realiza el navegador, el servidor rastrea la presencia de este archivo en cada nivel de la ruta del recurso, exista o no, para comprobar si debe aplicar alguna norma. Eso se traduce en un impacto medible en el rendimiento.
Para que el servidor reconozca estos archivos es imprescindible que la directiva AllowOverride lo autorice en la configuración global de Apache. Su valor por defecto es None, lo que inhabilita los ficheros .htaccess por completo. Si tu hosting los tiene desactivados de raíz, poco podrás hacer. Determinadas órdenes requieren un permiso concreto: para emplear la instrucción Options en un .htaccess, por ejemplo, hace falta declarar AllowOverride Options.
Veamos a continuación sus aplicaciones prácticas, cómo darlo de alta y qué medidas tomar para protegerlo.
Usos concretos del fichero .htaccess
Las posibilidades de ajuste que ofrece este archivo son enormes. Voy a detenerme en las más habituales. Ten en cuenta que la mayoría de estos bloques requieren que el servidor tenga cargado el módulo correspondiente (mod_rewrite, mod_headers, etc.). Si el módulo no está activo, el servidor responderá con un error 500 de entrada.
Autorización y control de acceso
El uso más extendido consiste en limitar el acceso a una carpeta específica o a varias secciones de la web. Sin la contraseña adecuada, el servidor deniega la lectura del directorio. El principal inconveniente de gestionar el acceso por este canal —frente a hacerlo desde el panel del hosting o con el propio CMS— es que exige un segundo archivo, denominado .htpasswd, donde se almacenan las identidades y las claves. Esto resta flexibilidad a la administración (el usuario no puede cambiar su contraseña ni solicitar un recordatorio; únicamente puede modificarla el administrador del sistema) y genera algún problema de seguridad si no se configura bien. La documentación de Apache explica el procedimiento paso a paso. El archivo .htaccess adopta esta estructura:
AuthType Basic AuthName "Zona restringida" AuthUserFile /home/usuario/.htpasswd Require valid-user
El fichero .htpasswd se genera desde la línea de comandos con la utilidad htpasswd de Apache. Conviene emplear el parámetro -B para guardar las contraseñas cifradas con bcrypt (la opción -c crea el fichero la primera vez):
htpasswd -B -c /home/usuario/.htpasswd ana
Procura guardar ese archivo fuera del directorio público de la web (public_html o www). Y no olvides que la autenticación básica transmite las credenciales codificadas en Base64, no cifradas, de modo que solo resulta segura si la web funciona bajo HTTPS.
Crear URLs amigables
Aunque no existen pruebas concluyentes de que las URLs amigables mejoren por sí solas el posicionamiento en buscadores, es innegable que facilitan la interacción con el usuario. Una dirección limpia resulta más comprensible y lógica que una cadena repleta de parámetros incoherentes. Para activar esta función es necesario que el módulo mod_rewrite de Apache se encuentre habilitado. El siguiente bloque en el fichero .htaccess permite gestionar este comportamiento:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^ index.php [L]
</IfModule>
La última línea ejecuta el trabajo principal. Las dos condiciones previas comprueban que la petición no se corresponde con un directorio ni con un fichero real existente en el disco. Si la ruta no existe físicamente, el servidor deriva la solicitud a index.php, que se encarga de procesarla. En el texto de 2015 esa línea faltaba y la regla resultaba inútil. Si utilizas un gestor de contenidos como WordPress o Drupal, el propio sistema ya genera estas instrucciones de forma automática en su fichero .htaccess, por lo que no debes duplicarlas.
Limitar el acceso por IP
Otra opción muy práctica consiste en restringir la entrada a la web, a una carpeta o a un archivo específico basándote en la dirección IP del visitante. Resulta muy útil cuando sufres ataques sistemáticos desde un origen concreto o cuando quieres acotar la consulta de un área de trabajo a un rango de red determinado. La siguiente directiva:
<RequireAll> Require all granted Require not ip 1.1.1.1 </RequireAll>
bloquea el acceso a la máquina con la IP 1.1.1.1 y permite la navegación al resto de usuarios. Por su parte, la regla:
<Files index.php> Require ip 1.2.3.4 </Files>
concede acceso al fichero index.php únicamente a la dirección 1.2.3.4. En la versión de 2015 afirmé que esta última instrucción la bloqueaba, cuando en realidad hace exactamente lo contrario.
La sintaxis ha cambiado sustancialmente en las versiones recientes. Las instrucciones Order, Allow, Deny y Limit, habituales en manuales antiguos y presentes en mi primera versión del artículo, están quedando en desuso desde Apache 2.4 en favor de Require. Aunque siguen funcionando si el servidor mantiene activo el módulo de compatibilidad, la documentación oficial desaconseja mezclar ambos esquemas.
Control de la caché
Permite gestionar el almacenamiento temporal en el navegador del usuario o en servidores proxy intermediarios, optimizando el ancho de banda y aligerando las solicitudes hacia el servidor web. Aunque varios CMS permiten administrar estas cabeceras, aplicarlas desde el .htaccess suele ofrecer un rendimiento más consistente. El siguiente código establece un periodo de validez de una semana para los recursos gráficos:
<FilesMatch "\.(jpg|jpeg|png|gif|webp|avif|svg|ico)$"> Header set Cache-Control "max-age=604800, public" </FilesMatch>
Esta regla requiere el módulo mod_headers. He eliminado de la lista los formatos obsoletos como SWF e introducido extensiones modernas como WebP y AVIF.
Obligar a usar una conexión segura
Si dispones de un certificado SSL/TLS, lo razonable es forzar a que todo el tráfico transite por un canal cifrado. Los navegadores actuales marcan como no seguras las conexiones HTTP y los motores de búsqueda priorizan las direcciones bajo HTTPS. Puedes implantar esta redirección con las siguientes líneas:
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
En la versión original omití las banderas R=301 y L, lo que provocaba que la respuesta se interpretase como una redirección temporal (302). Si la web se encuentra detrás de un proxy inverso o de una red de distribución de contenidos (CDN), la variable %{HTTPS} puede no detectar el tráfico seguro y generar un bucle infinito. En ese caso conviene evaluar la cabecera X-Forwarded-Proto.
Cuando la web funcione sin incidencias en HTTPS, puedes indicar a los navegadores que no intenten conectar por HTTP durante un año mediante la cabecera HSTS:
Header always set Strict-Transport-Security "max-age=31536000"
Aplica esta directiva solo cuando tengas la certeza de que ningún recurso dependiente del sitio requiere HTTP, ya que revertir esta orden en los clientes lleva tiempo.
Control de los tipos MIME
Sirve para determinar el modo en que el servidor web entrega cada tipo de archivo atendiendo a su definición MIME. Por ejemplo, se puede forzar la descarga de los ficheros de filtros y estilos del gestor bibliográfico EndNote:
AddType application/x-endnote-style ens AddType application/x-endnote-filter enf
Indicar la página por defecto
Aunque Apache suele buscar por defecto archivos como index.html o index.php, es posible modificar este comportamiento y establecer otro documento de entrada:
DirectoryIndex welcome.html
Página de error 404
El aviso clásico cuando un recurso no se encuentra en la ruta indicada. Es recomendable configurar el .htaccess para mostrar una plantilla propia en lugar del mensaje estándar del servidor:
ErrorDocument 404 /error404.html
Del mismo modo se pueden personalizar las respuestas para otros códigos de estado HTTP:
ErrorDocument 403 /error403.html ErrorDocument 401 /error401.html
En 2015 señalé que un error 404 constituía una de las principales causas de penalización en motores de búsqueda. Conviene matizar esa afirmación: el código 404 es una respuesta estándar del protocolo HTTP y no perjudica el posicionamiento de forma automática. El verdadero problema radica en perder visitantes que se tropiezan con un callejón sin salida, por lo que resulta oportuno integrar en esa página un buscador interno o enlaces de navegación hacia las secciones principales. Utiliza siempre rutas relativas a la raíz del servidor. Si introduces una URL completa (http://…), Apache realizará una redirección 302 y la respuesta original de error 404 se perderá por el camino.
Redirección 301
Para redirigir de forma permanente una URL antigua a su nueva ubicación:
Redirect 301 /index.html /nuevo/index.html
Conviene diferenciar la redirección 301 (permanente) de la 302 (temporal). La primera comunica a los rastreadores que la dirección ha cambiado definitivamente y transmite la autoridad acumulada por el enlace original hacia la nueva ruta. Te recuerdo que publiqué, hace algún tiempo, una entrada en la que explicaba lo que implicaban los códigos de respuesta del servidor HTTP desde el punto de vista de la arquitectura de la información.
Redirigir a otro dominio
Suele emplearse durante la migración de un sitio web hacia un dominio distinto para conservar los enlaces entrantes y el tráfico acumulado. El bloque necesario es el siguiente:
RewriteEngine On
RewriteCond %{HTTP_HOST} ^(www\.)?web-antigua\.com$ [NC]
RewriteRule ^ https://nueva-web.com%{REQUEST_URI} [L,R=301]
El código publicado en 2015 reenviaba todo el tráfico a la portada del nuevo sitio y contenía un fallo de sintaxis en el nombre del dominio. Esta formulación mantiene la estructura de la ruta, de manera que cada página antigua deriva a su equivalente en el nuevo dominio.
URLs canónicas
Los motores de búsqueda identifican como direcciones independientes las variantes con www y sin www, así como las respuestas HTTP y HTTPS. Si todas ellas entregan el mismo contenido, se generan duplicidades que obligan al buscador a determinar por su cuenta cuál es la versión de referencia. Resulta más aconsejable fijar un criterio propio y redirigir las demás combinaciones. Si disponemos del dominio www.hola.com y queremos consolidar las peticiones, podemos establecer la versión sin www como principal y aplicar cifrado al mismo tiempo:
RewriteEngine On
RewriteCond %{HTTPS} !=on [OR]
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteRule ^ https://hola.com%{REQUEST_URI} [L,R=301]
Esta regla sustituye a la directiva de conexión segura comentada anteriormente, por lo que no deben combinarse ambas. Se trata de una variante de la redirección 301 orientada a unificar el tráfico. Esta redirección debe complementarse con la etiqueta rel=»canonical» en el código HTML de cada página.
Evitar el listado de ficheros
Impide que un usuario pueda consultar el índice de contenidos de una carpeta que carezca de un documento por defecto. Es una medida básica de seguridad para evitar la exposición de archivos internos:
Options -Indexes
Recuerda que para emplear la instrucción Options en un fichero .htaccess, la configuración del servidor debe incluir la directiva AllowOverride Options.
Limitar el tamaño máximo de los ficheros
Permite fijar un límite al volumen de los archivos que se suben al servidor para prevenir abusos en el almacenamiento y en el consumo de transferencia:
LimitRequestBody 10485760
El valor se expresa en bytes, por lo que este ejemplo establece un tope de 10 MB. En la versión de 2015 recurrí a variables de entorno de PHP:
php_value upload_max_filesize 10M php_value max_execution_time 200 php_value max_input_time 200
Esas instrucciones solo son válidas cuando PHP se ejecuta como módulo integrado en Apache. Con arquitecturas como PHP-FPM o FastCGI, habituales en los alojamientos actuales, provocan un error interno 500. En esas configuraciones, los ajustes de PHP deben realizarse mediante un archivo .user.ini o desde el panel de control del hosting.
Cabeceras para los buscadores
El módulo mod_headers permite inyectar cabeceras HTTP dirigidas a los motores de búsqueda sin alterar el contenido visible para los usuarios. La más habitual es X-Robots-Tag, útil para impedir la indexación de documentos no HTML, como los archivos PDF:
<FilesMatch "\.pdf$"> Header set X-Robots-Tag "noindex" </FilesMatch>
Cómo crear el fichero .htaccess
El fichero .htaccess no presenta peculiaridades en cuanto a su formato de texto. Se trata de un archivo plano cuyo nombre comienza por un punto, lo que lo identifica dentro de los sistemas Unix/Linux como un fichero oculto que no aparece en los listados convencionales de carpeta.
Para crearlo basta con utilizar cualquier editor de texto sin formato (Gedit, VS Code, Notepad) y guardarlo provisionalmente como htaccess.txt. Una vez transferido al servidor mediante FTP o SFTP, se renombra a .htaccess. También se puede generar directamente desde el administrador de archivos del panel del hosting.
Otra opción consiste en recurrir a generadores en línea. De los recomendados en 2015, únicamente .htaccessEditor se mantiene operativo. Conviene revisar siempre el código resultante antes de subirlo al servidor para evitar introducir reglas no deseadas.
Cómo proteger el fichero .htaccess
Dada la capacidad de control que ofrece este fichero sobre el comportamiento del servidor web, resulta imprescindible limitar su manipulación no autorizada. Para ello conviene aplicar un par de salvaguardas:
Para restringir la lectura externa del .htaccess desde un navegador web, aunque la configuración por defecto de Apache suele denegar las consultas a archivos que comienzan por .ht, es aconsejable reforzar la protección incluyendo en el propio archivo las siguientes directivas:
# Protege los archivos de configuración sensible <FilesMatch "^\.ht"> Require all denied </FilesMatch>
Esta expresión regular protege tanto el propio .htaccess como el fichero .htpasswd o cualquier otro recurso que comience con ese prefijo.
A nivel de sistema de archivos, asigna permisos de lectura 644 (rw-r–r–) mediante el cliente FTP para impedir que usuarios no autorizados puedan modificar su contenido desde el servidor.
Consejos de uso
- Evita sobrecargar la estructura con múltiples archivos .htaccess. Distribuir ficheros de configuración por cada carpeta del sitio mejora el aislamiento, pero incrementa el tiempo de procesamiento de cada petición en el servidor.
- Mantén una estructura ordenada dentro del fichero. Introducir instrucciones de forma desorganizada dificulta la localización de errores y el mantenimiento a largo plazo.
- Documenta las reglas mediante comentarios precedidos por el símbolo #. Explicar la función de cada bloque facilita la revisión del archivo meses después de su creación.
- Ten en cuenta que las instrucciones aplicadas en un directorio se heredan automáticamente en todos sus subdirectorios.
- Realiza siempre una copia de seguridad del archivo antes de aplicar modificaciones. Un error de sintaxis en el .htaccess provocará de inmediato un error 500 en la web, cuya causa deberá comprobarse en el registro de errores (error.log) de Apache.
Deja una respuesta