El archivo .htaccess es el punto de control por directorio de Apache: permite forzar HTTPS, crear redirecciones 301, activar compresión, definir cabeceras de seguridad y bloquear archivos sensibles sin tocar la configuración global del servidor. Es también una de las fuentes de error más habituales en hosting compartido, porque una sola directiva mal escrita devuelve un error 500 en todo el sitio. Este generador de .htaccess construye un archivo coherente y comentado a partir de opciones sencillas, y todo se genera en tu navegador sin enviar nada a ningún servidor.
Qué es .htaccess y cuándo lo lee Apache
Apache lee .htaccess en cada petición, recorriendo el árbol de directorios desde la raíz del sitio hasta la carpeta del recurso solicitado. Esa es su ventaja (los cambios se aplican al instante, sin recargar el servicio) y su coste (una penalización de rendimiento por petición). Para que las directivas se apliquen, el VirtualHost debe declarar AllowOverride All (o al menos las categorías que uses: FileInfo, Options, Limit, Indexes). Si tienes acceso al VirtualHost, mover estas reglas allí y usar AllowOverride None es siempre más rápido: para ese caso, usa el generador de VirtualHost de Apache.
Forzar HTTPS y dominio canónico sin bucles de redirección
La forma correcta de forzar HTTPS es una condición sobre %{HTTPS} seguida de una RewriteRule con [R=301,L]. El problema clásico aparece detrás de un proxy inverso o un CDN (Cloudflare, un balanceador): ahí Apache recibe la conexión en HTTP y %{HTTPS} nunca vale on, provocando un bucle infinito. En esos escenarios la condición debe evaluar la cabecera %{HTTP:X-Forwarded-Proto}. El segundo bloque importante es el dominio canónico: elige www o sin www y redirige el otro con un 301 único, nunca en cadena. Cada salto extra de redirección añade latencia y diluye la señal de enlaces hacia tu URL final.
Redirecciones 301 y 302: cuál usar en cada caso
Un 301 es permanente: transfiere la práctica totalidad de la autoridad de enlaces y los navegadores lo cachean de forma agresiva, así que un 301 equivocado es difícil de revertir en los clientes ya afectados. Un 302 es temporal y no consolida la nueva URL en el índice. Regla práctica: 301 para cambios de estructura, migraciones de dominio y unificación de www/HTTPS; 302 para mantenimientos, pruebas A/B y redirecciones dependientes de sesión. Al migrar URLs, redirige siempre al equivalente más cercano; enviar todo a la home genera soft 404 y Google lo trata como pérdida de contenido.
Rendimiento: gzip, caché del navegador y Core Web Vitals
mod_deflate comprime HTML, CSS, JavaScript, JSON y SVG, reduciendo la transferencia entre un 60% y un 80%. No comprimas imágenes JPEG/PNG/WebP ni vídeo: ya vienen comprimidos y sólo gastarías CPU. mod_expires marca los recursos estáticos con cabeceras de caché largas (un año para assets con hash en el nombre) y deja el HTML sin caché para que los despliegues sean inmediatos. Esta combinación mejora directamente el LCP, una de las métricas de Core Web Vitals que Google usa como señal de experiencia de página.
Endurecer la seguridad desde .htaccess
Con mod_headers puedes añadir en una línea las cabeceras que cierran clases enteras de ataques: X-Content-Type-Options: nosniff evita el MIME sniffing, X-Frame-Options: SAMEORIGIN impide el clickjacking, Referrer-Policy limita la fuga de URLs internas y Permissions-Policy desactiva APIs del navegador que tu sitio no usa. Añade Strict-Transport-Security sólo cuando HTTPS ya funcione en todo el dominio, porque el navegador recordará la política durante el max-age indicado. Complementa con un bloque FilesMatch que deniegue el acceso a .env, .git, backups .sql, .log y ficheros de dependencias: en hosting compartido son el vector de filtración más común.
Fallback para SPA y URLs limpias
Una aplicación React, Vue o Angular con rutas de cliente necesita que cualquier ruta desconocida sirva index.html, pero sólo cuando el recurso no existe en disco. Eso se consigue con las dos condiciones !-f y !-d antes de la regla de fallback: si pones la regla sin ellas, romperás las imágenes y los assets. Para sitios PHP clásicos, la variante habitual es eliminar index.php de la URL con un 301 y enrutar internamente hacia el front controller.
Depurar un .htaccess que no funciona
Sigue este orden: 1) comprueba que el archivo se llama exactamente .htaccess y está en la raíz del sitio; 2) verifica AllowOverride All en el VirtualHost; 3) confirma que los módulos están cargados (apachectl -M); 4) revisa el error log, que indica la línea exacta de una directiva inválida; 5) prueba las reglas de reescritura por separado, comentando el resto. Un RewriteRule que no encaja casi siempre falla por la barra inicial: en .htaccess el patrón se evalúa sin el / de la ruta. Valida tus expresiones con el tester de regex antes de pegarlas.
Casos de uso comunes
- Migrar un sitio a HTTPS y unificar www/sin www con un único 301.
- Redirigir URLs antiguas tras rediseñar la estructura sin perder posiciones.
- Servir una SPA desde hosting compartido con rutas de cliente.
- Añadir cabeceras de seguridad y caché en un WordPress o PrestaShop sin plugins.
- Bloquear el acceso público a .env, backups SQL y logs.
Buenas prácticas
- Haz copia del .htaccess actual antes de sustituirlo: un error de sintaxis devuelve 500 en todo el sitio.
- Evita cadenas de redirecciones; apunta siempre directamente a la URL final.
- Activa HSTS sólo cuando HTTPS funcione en todos los subdominios servidos.
- Si controlas el VirtualHost, mueve las reglas allí y usa AllowOverride None por rendimiento.
- Cachea assets con hash un año y deja el HTML sin caché.