Saltar al contenido
DevLab

⚙️ Generador .htaccess

Activa o desactiva opciones para generar un .htaccess Apache listo para producción: redirección HTTPS, HSTS, gzip / brotli, caché, bloqueo de archivos sensibles y WordPress.

100% Gratis Sin registro Solo navegador 5 idiomas Modo oscuro

🔒 Sobre la privacidad

🧩 Selecciona funciones

📄 .htaccess generado


        
    






    
📖 Dónde se suele tropezar


        
Genera un .htaccess que combina redireccion a HTTPS, canonicalizacion de www, seleccion de version de PHP, control de cache, cabeceras de seguridad y restricciones de acceso. Todo se ejecuta en el navegador. Un .htaccess tiene una propiedad peligrosa que ningun otro archivo de configuracion comparte: una linea equivocada y todo lo que cuelga de ese directorio devuelve 500 al instante. Y la pagina de error no te dice la causa. Si tu panel de administracion vive en el mismo arbol, no podras arreglarlo desde alli: antes de editar, asegurate de tener una via de vuelta.

    
        

        

            
                

                    Caso
                    Qué ocurre
                    Qué hacer
                

            
            
                                

                    Una linea erronea convierte todo el sitio en un 500
                    Un .htaccess se relee en cada peticion, de modo que un error afecta a todas las peticiones desde el instante en que guardas. La causa mas frecuente es una directiva de un modulo que no esta cargado: escribe Header set ... donde mod_headers esta desactivado y Apache no puede interpretar la linea, asi que devuelve 500 Internal Server Error. Lo incomodo es que no se trata de "la sintaxis esta bien pero no funciona", sino de "la configuracion es ilegible y por tanto todo se detiene". Lo unico que ves es una pagina de error generica, y no indica que linea ni que hay mal en ella: esa informacion solo existe en el registro de errores del servidor. En un alojamiento compartido donde no puedes ver el registro, aislar la causa se convierte en prueba y error.
                    Envuelve siempre las directivas dependientes de modulo en <IfModule>. Metelas dentro de <IfModule mod_headers.c> y un entorno sin el modulo simplemente las ignora en lugar de devolver 500: solo con eso se evitan la mayoria de los incidentes. En cuanto al procedimiento, haz siempre una copia antes de editar y edita por una via que siga funcionando con el sitio en 500, como SSH o FTP: editarlo desde el panel de WordPress es demoler el suelo que pisas. Anade en trozos pequenos y comprueba en el navegador tras cada uno: anade diez lineas de golpe, encuentrate un 500 y quedaras reducido a una busqueda binaria. En alojamiento compartido, averigua de antemano si puedes leer el registro de errores, para no quedarte atascado cuando haga falta.
                

                                

                    Bucles de redireccion y un 301 que no puedes retirar
                    Escribir a la vez el forzado de HTTPS y la canonicalizacion de www produce un bucle infinito segun el orden de las condiciones. Sobre todo cuando delante hay un balanceador o una CDN: la peticion llega siempre al servidor por HTTP, de modo que %{HTTPS} permanece en off para siempre y la redireccion se repite sin fin; el sintoma es ERR_TOO_MANY_REDIRECTS. Y la naturaleza del 301 lo agrava: 301 significa permanente, asi que los navegadores lo cachean con fuerza y siguen ejecutando la redireccion antigua incluso despues de que arregles la configuracion. El resultado es ese estado en el que lo has arreglado y sigue roto, y sigues tocando la configuracion y empeoras las cosas: el patron que mas tiempo cuesta en esta clase de problemas.
                    Si estas detras de un proxy, mira %{HTTP:X-Forwarded-Proto}. Escribir RewriteCond %{HTTP:X-Forwarded-Proto} !https da una decision correcta incluso a traves de una CDN. Y verifica siempre con curl -I en lugar de con un navegador: curl no cachea redirecciones, asi que siempre ves el resultado de la configuracion actual. Mientras construyes, usa 302, confirma que el comportamiento es el que pretendias y solo entonces cambialo a 301: ese orden por si solo evita practicamente todos los incidentes causados por la cache. Si ya has servido un 301 equivocado, el unico remedio es servir un nuevo 301 hacia el destino correcto: no puedes vaciar desde tu lado la cache del navegador de nadie. Y manten las reglas de redireccion en un solo sitio: repartidas entre varios .htaccess y la configuracion de la aplicacion, el origen de un bucle se vuelve imposible de rastrear.
                

                                

                    Un .htaccess de subdirectorio anula las reglas del padre
                    Un .htaccess se aplica de forma jerarquica, pero las reglas de mod_rewrite se sustituyen en lugar de heredarse. En cuanto escribes una sola RewriteRule en un subdirectorio, las reglas de reescritura del padre dejan de aplicarse en ese directorio: el forzado de HTTPS y la canonicalizacion de www quedan muertos alli y solo alli. Lo que lo hace dificil de notar es que las demas directivas (autenticacion, cache, cabeceras) se heredan con normalidad, lo que produce el comportamiento contraintuitivo de que solo algunas cosas se heredan. En relacion con esto, un subdirectorio puede necesitar un RewriteBase, y olvidarlo hace que las rutas relativas se resuelvan contra la ruta del padre, provocando 404 o bucles.
                    Si puedes, no uses .htaccess en absoluto: escribe la configuracion en la del servidor. En un VPS o un servidor dedicado puedes ponerla en un bloque <Directory>, lo que ademas es mas rapido, porque desaparece la busqueda y lectura del archivo en cada peticion (con AllowOverride None, Apache ni siquiera lo busca). Si el alojamiento compartido solo te deja .htaccess, consolida las reglas de reescritura en un unico archivo padre y evita colocar cualquier RewriteRule en subdirectorios. Si de verdad necesitas una, RewriteOptions Inherit arrastra las reglas del padre, pero cambia el orden en que se aplican, asi que verifica cada patron solicitandolo de verdad.
                

                            
        

    

    
        
Las cabeceras de seguridad no te vuelven seguro por el mero hecho de estar. X-Frame-Options y Content-Security-Policy cierran tecnicas de ataque concretas y no hacen nada frente a las vulnerabilidades de tu aplicacion: subir la puntuacion de un escaner y ser realmente seguro son cosas distintas. En particular, Content-Security-Policy rompera tu propio JavaScript si lo configuras mal: empieza con Content-Security-Policy-Report-Only, observa lo que informa y solo entonces pasa a la cabecera que aplica. Ademas, las restricciones de acceso en .htaccess solo valen cuando el archivo se sirve a traves de Apache: en un montaje donde nginx sirve los estaticos directamente por delante, el .htaccess no se lee jamas. Guardar los archivos confidenciales fuera del directorio publico es la respuesta correcta; ocultarlos con una regla de acceso es el recurso de reserva. Y, cosa que se olvida con facilidad: manten el propio .htaccess bajo control de versiones: un archivo de configuracion en el que nadie sabe quien anadio que ni cuando acaba siendo uno que nadie se atreve a tocar.

    









    
📖 Cómo usar

    
    
                
  1. 
            1
            
    
                
    Elige funciones
    
                
    Marca las casillas de las funciones deseadas. La vista previa se actualiza en vivo.
    
            
    
        
    2. 
                
  2. 
            2
            
    
                
    Introduce el dominio
    
                
    Si usas canonicalización www, indica tu dominio. No es necesario para solo HTTPS.
    
            
    
        
    3. 
                
  3. 
            3
            
    
                
    Copia o descarga
    
                
    Usa los botones para copiar o descargar como archivo. Revísalo antes de subirlo.
    
            
    
        
    4. 
                
  4. 
            4
            
    
                
    Sube al servidor
    
                
    Coloca el archivo como .htaccess en la raíz del documento. Haz copia de seguridad si ya existe.
    
            
    
        
    5. 
            






    
❓ Preguntas frecuentes

    

                

            
                ¿Funciona .htaccess fuera de Apache?
                
            
            
No. Es solo de Apache. LiteSpeed es compatible, pero nginx necesita un server block. Usa nuestro generador para nginx.

        

                

            
                ¿Qué hacer si aparece un error 500?
                
            
            
Puede ser un módulo no disponible. Los bloques están envueltos en IfModule, pero si persiste, comenta bloque por bloque y revisa error_log.

        

                

            
                ¿Funciona en hosting compartido (Xserver / Sakura)?
                
            
            
Sí. La mayoría permiten .htaccess y AddHandler. Algunos requieren habilitar mod_deflate / mod_expires desde el panel.

        

            






    

        
🔗 Herramientas relacionadas

        
    






    

        
            🐛 ¿Encontró un problema con esta herramienta?
            
        

        

            Gratis, sin registro. Incluso solo los pasos para reproducir ayudan. Los informes van directamente al operador y se usan para corregir.
        


        

                        

            

                
                
            


            

                
                
                

                    * Se envía automáticamente la info del navegador (UA / pantalla / idioma / URL) para reproducir