{"id":73,"date":"2026-10-27T09:30:23","date_gmt":"2026-10-27T08:30:23","guid":{"rendered":"http:\/\/tecnologiasweb.jsenso.es\/?p=73"},"modified":"2026-10-28T09:21:41","modified_gmt":"2026-10-28T08:21:41","slug":"el-fichero-htaccess","status":"publish","type":"post","link":"https:\/\/blogs.ugr.es\/tecweb\/el-fichero-htaccess\/","title":{"rendered":"La importancia del fichero .htaccess [actualizaci\u00f3n 2026]"},"content":{"rendered":"<p>[Publicada el 18 de mayo de 2015. Revisada en octubre de 2026]<\/p>\n<p>Esta entrada arrastra ya unos cu\u00e1ntos a\u00f1os a sus espaldas y varias cosas se hab\u00edan quedado desfasadas. He conservado lo que sigue teniendo sentido t\u00e9cnico y he corregido el resto. Hab\u00eda ejemplos de c\u00f3digo que directamente no funcionaban y Apache ha metido cambios de peso en este tiempo. Cuando alguna directiva sea distinta de lo que escrib\u00ed en 2015, te lo comento en su correspondiente apartado.<\/p>\n<p>En su momento, cuando habl\u00e9 sobre <a href=\"https:\/\/blogs.ugr.es\/tecweb\/ya-he-instalado-drupal-y-ahora-que\/\">qu\u00e9 pasos dar tras instalar Drupal<\/a>, comentaba que una de las primeras tareas deb\u00eda ser configurar bien el fichero .htaccess. Aprovecho ahora para examinar con m\u00e1s detalle este archivo, un elemento fundamental dentro de cualquier servidor web Apache.<\/p>\n<p>El fichero *hypertext access*, m\u00e1s conocido como [<a href=\"http:\/\/httpd.apache.org\/docs\/2.4\/howto\/htaccess.html\" target=\"_blank\" rel=\"noopener\">.htaccess<\/a>], es una de las piezas centrales dentro de un servidor <a href=\"http:\/\/httpd.apache.org\/\" target=\"_blank\" rel=\"noopener\">Apache<\/a>, para el que fue dise\u00f1ado en exclusiva. En 2015 sostuve que con el tiempo su uso se hab\u00eda extendido al resto de servidores web, pero la realidad me ha llevado la contraria: Nginx, muy habitual hoy en d\u00eda, no lo lee en absoluto. LiteSpeed s\u00ed lo interpreta, aunque lo hace por pura compatibilidad con Apache. Si tu proveedor de alojamiento no utiliza Apache, este texto no te servir\u00e1 de mucho.<\/p>\n<p>En la mayor\u00eda de alojamientos compartidos resulta imposible que nos den acceso al fichero de configuraci\u00f3n 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\u00f3n para cada directorio y para todos los subdirectorios que dependan de \u00e9l. La propia documentaci\u00f3n de Apache aconseja recurrir al .htaccess \u00fanicamente cuando carecemos de acceso a la configuraci\u00f3n global.<\/p>\n<p>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\u00f3n 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\u00f3n 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.<\/p>\n<p>Para que el servidor reconozca estos archivos es imprescindible que la directiva <a href=\"http:\/\/httpd.apache.org\/docs\/trunk\/mod\/core.html#allowoverride\" target=\"_blank\" rel=\"noopener\">AllowOverride<\/a> lo autorice en la configuraci\u00f3n 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\u00edz, poco podr\u00e1s hacer. Determinadas \u00f3rdenes requieren un permiso concreto: para emplear la instrucci\u00f3n Options en un .htaccess, por ejemplo, hace falta declarar AllowOverride Options.<\/p>\n<p>Veamos a continuaci\u00f3n sus aplicaciones pr\u00e1cticas, c\u00f3mo darlo de alta y qu\u00e9 medidas tomar para protegerlo.<\/p>\n<p>&nbsp;<\/p>\n<h2>Usos concretos del fichero .htaccess<\/h2>\n<p>Las posibilidades de ajuste que ofrece este archivo son enormes. Voy a detenerme en las m\u00e1s habituales. Ten en cuenta que la mayor\u00eda de estos bloques requieren que el servidor tenga cargado el m\u00f3dulo correspondiente (mod_rewrite, mod_headers, etc.). Si el m\u00f3dulo no est\u00e1 activo, el servidor responder\u00e1 con un error 500 de entrada.<\/p>\n<h3>Autorizaci\u00f3n y control de acceso<\/h3>\n<p>El uso m\u00e1s extendido consiste en limitar el acceso a una carpeta espec\u00edfica o a varias secciones de la web. Sin la contrase\u00f1a adecuada, el servidor deniega la lectura del directorio. El principal inconveniente de gestionar el acceso por este canal \u2014frente a hacerlo desde el panel del hosting o con el propio CMS\u2014 es que exige un segundo archivo, denominado .htpasswd, donde se almacenan las identidades y las claves. Esto resta flexibilidad a la administraci\u00f3n (el usuario no puede cambiar su contrase\u00f1a ni solicitar un recordatorio; \u00fanicamente puede modificarla el administrador del sistema) y genera alg\u00fan problema de seguridad si no se configura bien. <a href=\"https:\/\/httpd.apache.org\/docs\/2.4\/howto\/auth.html\" target=\"_blank\" rel=\"noopener\">La documentaci\u00f3n de Apache explica el procedimiento paso a paso<\/a>. El archivo .htaccess adopta esta estructura:<\/p>\n<pre>AuthType Basic\r\nAuthName \"Zona restringida\"\r\nAuthUserFile \/home\/usuario\/.htpasswd\r\nRequire valid-user<\/pre>\n<p>El fichero .htpasswd se genera desde la l\u00ednea de comandos con la utilidad htpasswd de Apache. Conviene emplear el par\u00e1metro -B para guardar las contrase\u00f1as cifradas con bcrypt (la opci\u00f3n -c crea el fichero la primera vez):<\/p>\n<pre>htpasswd -B -c \/home\/usuario\/.htpasswd ana<\/pre>\n<p>Procura guardar ese archivo fuera del directorio p\u00fablico de la web (public_html o www). Y no olvides que la autenticaci\u00f3n b\u00e1sica transmite las credenciales codificadas en Base64, no cifradas, de modo que solo resulta segura si la web funciona bajo HTTPS.<\/p>\n<h3>Crear URLs amigables<\/h3>\n<p>Aunque no existen pruebas concluyentes de que las URLs amigables mejoren por s\u00ed solas el posicionamiento en buscadores, es innegable que facilitan la interacci\u00f3n con el usuario. Una direcci\u00f3n limpia resulta m\u00e1s comprensible y l\u00f3gica que una cadena repleta de par\u00e1metros incoherentes. Para activar esta funci\u00f3n es necesario que el m\u00f3dulo <a href=\"https:\/\/httpd.apache.org\/docs\/current\/mod\/mod_rewrite.html\" target=\"_blank\" rel=\"noopener\">mod_rewrite<\/a> de Apache se encuentre habilitado. El siguiente bloque en el fichero .htaccess permite gestionar este comportamiento:<\/p>\n<pre>&lt;IfModule mod_rewrite.c&gt;\r\nRewriteEngine On\r\nRewriteBase \/\r\nRewriteCond %{REQUEST_FILENAME} !-d\r\nRewriteCond %{REQUEST_FILENAME} !-f\r\nRewriteRule ^ index.php [L]\r\n&lt;\/IfModule&gt;<\/pre>\n<p>La \u00faltima l\u00ednea ejecuta el trabajo principal. Las dos condiciones previas comprueban que la petici\u00f3n no se corresponde con un directorio ni con un fichero real existente en el disco. Si la ruta no existe f\u00edsicamente, el servidor deriva la solicitud a index.php, que se encarga de procesarla. En el texto de 2015 esa l\u00ednea faltaba y la regla resultaba in\u00fatil. Si utilizas un gestor de contenidos como WordPress o Drupal, el propio sistema ya genera estas instrucciones de forma autom\u00e1tica en su fichero .htaccess, por lo que no debes duplicarlas.<\/p>\n<p>&nbsp;<\/p>\n<h3>Limitar el acceso por IP<\/h3>\n<p>Otra opci\u00f3n muy pr\u00e1ctica consiste en restringir la entrada a la web, a una carpeta o a un archivo espec\u00edfico bas\u00e1ndote en la direcci\u00f3n IP del visitante. Resulta muy \u00fatil cuando sufres ataques sistem\u00e1ticos desde un origen concreto o cuando quieres acotar la consulta de un \u00e1rea de trabajo a un rango de red determinado. La siguiente directiva:<\/p>\n<pre>&lt;RequireAll&gt;\r\nRequire all granted\r\nRequire not ip 1.1.1.1\r\n&lt;\/RequireAll&gt;<\/pre>\n<p>bloquea el acceso a la m\u00e1quina con la IP 1.1.1.1 y permite la navegaci\u00f3n al resto de usuarios. Por su parte, la regla:<\/p>\n<pre>&lt;Files index.php&gt;\r\nRequire ip 1.2.3.4\r\n&lt;\/Files&gt;<\/pre>\n<p>concede acceso al fichero index.php \u00fanicamente a la direcci\u00f3n 1.2.3.4. En la versi\u00f3n de 2015 afirm\u00e9 que esta \u00faltima instrucci\u00f3n la bloqueaba, cuando en realidad hace exactamente lo contrario.<\/p>\n<p>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\u00f3n del art\u00edculo, est\u00e1n <a href=\"https:\/\/httpd.apache.org\/docs\/mod\/mod_access_compat.html\" target=\"_blank\" rel=\"noopener\">quedando en desuso desde Apache 2.4<\/a> en favor de Require. Aunque siguen funcionando si el servidor mantiene activo el m\u00f3dulo de compatibilidad, la documentaci\u00f3n oficial desaconseja mezclar ambos esquemas.<\/p>\n<p>&nbsp;<\/p>\n<h3>Control de la cach\u00e9<\/h3>\n<p>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\u00e1s consistente. El siguiente c\u00f3digo establece un periodo de validez de una semana para los recursos gr\u00e1ficos:<\/p>\n<pre>&lt;FilesMatch \"\\.(jpg|jpeg|png|gif|webp|avif|svg|ico)$\"&gt;\r\nHeader set Cache-Control \"max-age=604800, public\"\r\n&lt;\/FilesMatch&gt;<\/pre>\n<p>Esta regla requiere el m\u00f3dulo mod_headers. He eliminado de la lista los formatos obsoletos como SWF e introducido extensiones modernas como WebP y AVIF.<\/p>\n<p>&nbsp;<\/p>\n<h3>Obligar a usar una conexi\u00f3n segura<\/h3>\n<p>Si dispones de un certificado SSL\/TLS, lo razonable es forzar a que todo el tr\u00e1fico transite por un canal cifrado. Los navegadores actuales marcan como no seguras las conexiones HTTP y los motores de b\u00fasqueda priorizan las direcciones bajo HTTPS. Puedes implantar esta redirecci\u00f3n con las siguientes l\u00edneas:<\/p>\n<pre>RewriteEngine On\r\nRewriteCond %{HTTPS} !=on\r\nRewriteRule ^ https:\/\/%{HTTP_HOST}%{REQUEST_URI} [L,R=301]<\/pre>\n<p>En la versi\u00f3n original omit\u00ed las banderas R=301 y L, lo que provocaba que la respuesta se interpretase como una redirecci\u00f3n temporal (302). Si la web se encuentra detr\u00e1s de un proxy inverso o de una red de distribuci\u00f3n de contenidos (CDN), la variable %{HTTPS} puede no detectar el tr\u00e1fico seguro y generar un bucle infinito. En ese caso conviene evaluar la cabecera X-Forwarded-Proto.<\/p>\n<p>Cuando la web funcione sin incidencias en HTTPS, puedes indicar a los navegadores que no intenten conectar por HTTP durante un a\u00f1o mediante la cabecera HSTS:<\/p>\n<pre>Header always set Strict-Transport-Security \"max-age=31536000\"<\/pre>\n<p>Aplica esta directiva solo cuando tengas la certeza de que ning\u00fan recurso dependiente del sitio requiere HTTP, ya que revertir esta orden en los clientes lleva tiempo.<\/p>\n<p>&nbsp;<\/p>\n<h3>Control de los tipos MIME<\/h3>\n<p>Sirve para determinar el modo en que el servidor web entrega cada tipo de archivo atendiendo a su <a href=\"https:\/\/www.ietf.org\/rfc\/rfc2045.txt\" target=\"_blank\" rel=\"noopener\">definici\u00f3n MIME<\/a>. Por ejemplo, se puede forzar la descarga de los ficheros de filtros y estilos del gestor bibliogr\u00e1fico <a href=\"http:\/\/www.endnote.com\/\" target=\"_blank\" rel=\"noopener\">EndNote<\/a>:<\/p>\n<pre>AddType application\/x-endnote-style ens\r\nAddType application\/x-endnote-filter enf<\/pre>\n<p>&nbsp;<\/p>\n<h3>Indicar la p\u00e1gina por defecto<\/h3>\n<p>Aunque Apache suele buscar por defecto archivos como index.html o index.php, es posible modificar este comportamiento y establecer otro documento de entrada:<\/p>\n<pre>DirectoryIndex welcome.html<\/pre>\n<p>&nbsp;<\/p>\n<h3>P\u00e1gina de error 404<\/h3>\n<p>El aviso cl\u00e1sico 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\u00e1ndar del servidor:<\/p>\n<pre>ErrorDocument 404 \/error404.html<\/pre>\n<p>Del mismo modo se pueden personalizar las respuestas para otros c\u00f3digos de estado HTTP:<\/p>\n<pre>ErrorDocument 403 \/error403.html\r\nErrorDocument 401 \/error401.html<\/pre>\n<p>En 2015 se\u00f1al\u00e9 que un error 404 constitu\u00eda una de las principales causas de penalizaci\u00f3n en motores de b\u00fasqueda. Conviene matizar esa afirmaci\u00f3n: el c\u00f3digo 404 es una respuesta est\u00e1ndar del protocolo HTTP y no perjudica el posicionamiento de forma autom\u00e1tica. El verdadero problema radica en perder visitantes que se tropiezan con un callej\u00f3n sin salida, por lo que resulta oportuno integrar en esa p\u00e1gina un buscador interno o enlaces de navegaci\u00f3n hacia las secciones principales. Utiliza siempre rutas relativas a la ra\u00edz del servidor. Si introduces una URL completa (http:\/\/&#8230;), Apache realizar\u00e1 una redirecci\u00f3n 302 y la respuesta original de error 404 se perder\u00e1 por el camino.<\/p>\n<p>&nbsp;<\/p>\n<h3>Redirecci\u00f3n 301<\/h3>\n<p>Para redirigir de forma permanente una URL antigua a su nueva ubicaci\u00f3n:<\/p>\n<pre>Redirect 301 \/index.html \/nuevo\/index.html<\/pre>\n<p>Conviene diferenciar la redirecci\u00f3n 301 (permanente) de la 302 (temporal). La primera comunica a los rastreadores que la direcci\u00f3n ha cambiado definitivamente y transmite la autoridad acumulada por el enlace original hacia la nueva ruta. Te recuerdo que publiqu\u00e9, hace alg\u00fan tiempo, una entrada en la que explicaba lo que implicaban <a href=\"https:\/\/blogs.ugr.es\/tecweb\/los-codigos-respuesta-del-servidor-http-claves-arquitectura\/\" target=\"_blank\" rel=\"noopener\">los c\u00f3digos de respuesta del servidor HTTP desde el punto de vista de la arquitectura de la informaci\u00f3n<\/a>.<\/p>\n<p>&nbsp;<\/p>\n<h3>Redirigir a otro dominio<\/h3>\n<p>Suele emplearse durante la migraci\u00f3n de un sitio web hacia un dominio distinto para conservar los enlaces entrantes y el tr\u00e1fico acumulado. El bloque necesario es el siguiente:<\/p>\n<pre>RewriteEngine On\r\nRewriteCond %{HTTP_HOST} ^(www\\.)?web-antigua\\.com$ [NC]\r\nRewriteRule ^ https:\/\/nueva-web.com%{REQUEST_URI} [L,R=301]<\/pre>\n<p>El c\u00f3digo publicado en 2015 reenviaba todo el tr\u00e1fico a la portada del nuevo sitio y conten\u00eda un fallo de sintaxis en el nombre del dominio. Esta formulaci\u00f3n mantiene la estructura de la ruta, de manera que cada p\u00e1gina antigua deriva a su equivalente en el nuevo dominio.<\/p>\n<p>&nbsp;<\/p>\n<h3>URLs can\u00f3nicas<\/h3>\n<p>Los motores de b\u00fasqueda identifican como direcciones independientes las variantes con www y sin www, as\u00ed 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\u00e1l es la versi\u00f3n de referencia. Resulta m\u00e1s aconsejable fijar un criterio propio y redirigir las dem\u00e1s combinaciones. Si disponemos del dominio <a href=\"https:\/\/www.hola.com\">www.hola.com<\/a> y queremos consolidar las peticiones, podemos establecer la versi\u00f3n sin www como principal y aplicar cifrado al mismo tiempo:<\/p>\n<pre>RewriteEngine On\r\nRewriteCond %{HTTPS} !=on [OR]\r\nRewriteCond %{HTTP_HOST} ^www\\. [NC]\r\nRewriteRule ^ https:\/\/hola.com%{REQUEST_URI} [L,R=301]<\/pre>\n<p>Esta regla sustituye a la directiva de conexi\u00f3n segura comentada anteriormente, por lo que no deben combinarse ambas. Se trata de una variante de la redirecci\u00f3n 301 orientada a unificar el tr\u00e1fico. Esta redirecci\u00f3n debe complementarse con la etiqueta rel=\u00bbcanonical\u00bb en el c\u00f3digo HTML de cada p\u00e1gina.<\/p>\n<p>&nbsp;<\/p>\n<h3>Evitar el listado de ficheros<\/h3>\n<p>Impide que un usuario pueda consultar el \u00edndice de contenidos de una carpeta que carezca de un documento por defecto. Es una medida b\u00e1sica de seguridad para evitar la exposici\u00f3n de archivos internos:<\/p>\n<pre>Options -Indexes<\/pre>\n<p>Recuerda que para emplear la instrucci\u00f3n Options en un fichero .htaccess, la configuraci\u00f3n del servidor debe incluir la directiva AllowOverride Options.<\/p>\n<p>&nbsp;<\/p>\n<h3>Limitar el tama\u00f1o m\u00e1ximo de los ficheros<\/h3>\n<p>Permite fijar un l\u00edmite al volumen de los archivos que se suben al servidor para prevenir abusos en el almacenamiento y en el consumo de transferencia:<\/p>\n<pre>LimitRequestBody 10485760<\/pre>\n<p>El valor se expresa en bytes, por lo que este ejemplo establece un tope de 10 MB. En la versi\u00f3n de 2015 recurr\u00ed a variables de entorno de PHP:<\/p>\n<pre>php_value upload_max_filesize 10M\r\nphp_value max_execution_time 200\r\nphp_value max_input_time 200<\/pre>\n<p>Esas instrucciones solo son v\u00e1lidas cuando PHP se ejecuta como m\u00f3dulo 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.<\/p>\n<p>&nbsp;<\/p>\n<h3>Cabeceras para los buscadores<\/h3>\n<p>El m\u00f3dulo mod_headers permite inyectar cabeceras HTTP dirigidas a los motores de b\u00fasqueda sin alterar el contenido visible para los usuarios. La m\u00e1s habitual es X-Robots-Tag, \u00fatil para impedir la indexaci\u00f3n de documentos no HTML, como los archivos PDF:<\/p>\n<pre>&lt;FilesMatch \"\\.pdf$\"&gt;\r\nHeader set X-Robots-Tag \"noindex\"\r\n&lt;\/FilesMatch&gt;<\/pre>\n<p>&nbsp;<\/p>\n<h2>C\u00f3mo crear el fichero .htaccess<\/h2>\n<p>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.<\/p>\n<p>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\u00e9n se puede generar directamente desde el administrador de archivos del panel del hosting.<\/p>\n<p>Otra opci\u00f3n consiste en recurrir a generadores en l\u00ednea. De los recomendados en 2015, \u00fanicamente <a href=\"https:\/\/www.htaccesseditor.com\/es.html\" target=\"_blank\" rel=\"noopener\">.htaccessEditor<\/a> se mantiene operativo. Conviene revisar siempre el c\u00f3digo resultante antes de subirlo al servidor para evitar introducir reglas no deseadas.<\/p>\n<p>&nbsp;<\/p>\n<h2>C\u00f3mo proteger el fichero .htaccess<\/h2>\n<p>Dada la capacidad de control que ofrece este fichero sobre el comportamiento del servidor web, resulta imprescindible limitar su manipulaci\u00f3n no autorizada. Para ello conviene aplicar un par de salvaguardas:<\/p>\n<p>Para restringir la lectura externa del .htaccess desde un navegador web, aunque la configuraci\u00f3n por defecto de Apache suele denegar las consultas a archivos que comienzan por .ht, es aconsejable reforzar la protecci\u00f3n incluyendo en el propio archivo las siguientes directivas:<\/p>\n<pre># Protege los archivos de configuraci\u00f3n sensible\r\n&lt;FilesMatch \"^\\.ht\"&gt;\r\nRequire all denied\r\n&lt;\/FilesMatch&gt;<\/pre>\n<p>Esta expresi\u00f3n regular protege tanto el propio .htaccess como el fichero .htpasswd o cualquier otro recurso que comience con ese prefijo.<\/p>\n<p>A nivel de sistema de archivos, asigna permisos de lectura 644 (rw-r&#8211;r&#8211;) mediante el cliente FTP para impedir que usuarios no autorizados puedan modificar su contenido desde el servidor.<\/p>\n<p>&nbsp;<\/p>\n<h2>Consejos de uso<\/h2>\n<ul>\n<li>Evita sobrecargar la estructura con m\u00faltiples archivos .htaccess. Distribuir ficheros de configuraci\u00f3n por cada carpeta del sitio mejora el aislamiento, pero incrementa el tiempo de procesamiento de cada petici\u00f3n en el servidor.<\/li>\n<li>Mant\u00e9n una estructura ordenada dentro del fichero. Introducir instrucciones de forma desorganizada dificulta la localizaci\u00f3n de errores y el mantenimiento a largo plazo.<\/li>\n<li>Documenta las reglas mediante comentarios precedidos por el s\u00edmbolo #. Explicar la funci\u00f3n de cada bloque facilita la revisi\u00f3n del archivo meses despu\u00e9s de su creaci\u00f3n.<\/li>\n<li>Ten en cuenta que las instrucciones aplicadas en un directorio se heredan autom\u00e1ticamente en todos sus subdirectorios.<\/li>\n<li>Realiza siempre una copia de seguridad del archivo antes de aplicar modificaciones. Un error de sintaxis en el .htaccess provocar\u00e1 de inmediato un error 500 en la web, cuya causa deber\u00e1 comprobarse en el registro de errores (error.log) de Apache.<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"<p>[Publicada el 18 de mayo de 2015. Revisada en octubre de 2026] Esta entrada arrastra ya unos cu\u00e1ntos a\u00f1os a sus espaldas y varias cosas se hab\u00edan quedado desfasadas. He conservado lo que sigue teniendo sentido t\u00e9cnico y he corregido el resto. Hab\u00eda ejemplos de c\u00f3digo que directamente no funcionaban y Apache ha metido cambios [&hellip;]<\/p>\n","protected":false},"author":65,"featured_media":1393,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_genesis_hide_title":false,"_genesis_hide_breadcrumbs":false,"_genesis_hide_singular_image":false,"_genesis_hide_footer_widgets":false,"_genesis_custom_body_class":"","_genesis_custom_post_class":"","_genesis_layout":"","footnotes":""},"categories":[43],"tags":[40,41,42],"class_list":["post-73","post","type-post","status-publish","format-standard","has-post-thumbnail","category-software-de-clase","tag-administrador-del-sitio","tag-apache","tag-servidores-web","entry"],"_links":{"self":[{"href":"https:\/\/blogs.ugr.es\/tecweb\/wp-json\/wp\/v2\/posts\/73","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blogs.ugr.es\/tecweb\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.ugr.es\/tecweb\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.ugr.es\/tecweb\/wp-json\/wp\/v2\/users\/65"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.ugr.es\/tecweb\/wp-json\/wp\/v2\/comments?post=73"}],"version-history":[{"count":2,"href":"https:\/\/blogs.ugr.es\/tecweb\/wp-json\/wp\/v2\/posts\/73\/revisions"}],"predecessor-version":[{"id":1392,"href":"https:\/\/blogs.ugr.es\/tecweb\/wp-json\/wp\/v2\/posts\/73\/revisions\/1392"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blogs.ugr.es\/tecweb\/wp-json\/wp\/v2\/media\/1393"}],"wp:attachment":[{"href":"https:\/\/blogs.ugr.es\/tecweb\/wp-json\/wp\/v2\/media?parent=73"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.ugr.es\/tecweb\/wp-json\/wp\/v2\/categories?post=73"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.ugr.es\/tecweb\/wp-json\/wp\/v2\/tags?post=73"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}