El .htaccess es uno de los archivos protagonistas en entornos web, un archivo original de Apache que también entienden otros servidores web como LiteSpeed (el que usamos en Raiola Networks).
A través del archivo .htaccess le damos “instrucciones” al servidor web sobre cómo tiene que comportarse, sin necesidad de realizar parametrizaciones sobre los archivos de configuración del propio servicio.
En resumen, la posibilidad que nos ofrece el archivo .htaccess es la de que cualquier usuario pueda configurar algunas cosas básicas en el servidor directamente desde su cuenta de hosting y para su cuenta de hosting.
En este post vamos a hablar de algunas cosas que podemos configurar en el .htaccess de nuestro hosting y que van a influir en la forma de funcionar de nuestro WordPress.
Algunos tweaks que voy a comentar aquí son recomendables solo para algunas situaciones. Quiero dejar claro que no debes aplicarlos todos sin control y sin estar seguro de que los necesitas y de que no van a causar conflictos entre ellos.
Empecemos por el principio. Este es el .htaccess predeterminado de un WordPress recién instalado con los enlaces permanentes o URL amigables activos:
| 1 2 3 4 5 6 7 8 9 10 11 12 13 | RewriteEngine On RewriteBase / RewriteRule ^index\.php$ - [L] # add a trailing slash to /wp-admin RewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L] RewriteCond %{REQUEST_FILENAME} -f [OR] RewriteCond %{REQUEST_FILENAME} -d RewriteRule ^ - [L] RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L] RewriteRule ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L] RewriteRule . index.php [L] |
Hago especial hincapié en “.htaccess predeterminado”, ya que los plugins que vamos instalando en nuestro WordPress van añadiendo cosas al .htaccess y parametrizando el funcionamiento del servidor web.
A continuación, listaré todos los “tweaks” que podemos usar en el .htaccess y una explicación de para qué se utilizan.
¿Quieres
recibir mis articulos?
No te pierdas todos mis trucos para WordPress, CMS, Marketing Digital y WPO.
Activar la compresión GZIP / DEFLATE
Si el servidor Apache tiene mod_deflate activado y listo para usarse, podemos activar la compresión GZIP o Deflate simplemente utilizando el siguiente código en el .htaccess.
| 1 2 3 4 5 6 7 8 9 10 | <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 mime ^image/.* mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.* </ifModule> |
Aunque ahora mismo el formato Brotli impulsado por Google es la “novedad”, la base de compresión sigue siendo o GZIP o Deflate. Muchos plugins de cache o WPO para WordPress realizan directamente las modificaciones en el .htaccess. En caso contrario, debemos hacerlo nosotros con el código anterior.
Para que te hagas una idea de lo útil que es la compresión, existe un caso de éxito de Netflix relacionado con la compresión GZIP. Puedes verlo aquí: https://alvarofontela.com/casos-reales-wpo-velocidad-carga/
Activar Keep Alive en Apache
El parámetro Keep Alive permite que la conexión entre el servidor y el navegador del visitante no se cierre. Como resultado, si hay que realizar varias peticiones consecutivas, al mantener la conexión abierta se realizarán mucho más rápidamente. Es lo que comúnmente se llama “conexión persistente”.
Podemos activar Keep Alive siempre y cuando el servidor web lo tenga activo y utilizando este código:
| 1 2 3 4 5 6 7 8 | # Activar Keep Alive KeepAlive On # Conexiones maximas persistentes por Keep Alive MaxKeepAliveRequests 100 # Keep Alive Timeout de cada conexion KeepAliveTimeout 100 |
¿Qué razones existen para tener Keep Alive desactivado? Pues el consumo de recursos en el servidor, ya que un servidor con Keep Alive consume bastantes más recursos que uno con la misma opción desactivada debido a la gran cantidad de peticiones que hay que mantener abiertas.
Solucionar “Specy a Vary: Accept-Encoding Header”
Este error suele aparecer en Pingdom Tools y en GTMetrix. Antes también aparecía en Google PageSpeed Insights, pero desde hace algún tiempo lo he dejado de ver.
Se trata de una cabecera que se envía desde el servidor al visitante. Se utiliza para que el servidor y el navegador del visitante se entiendan en cuanto a la codificación del contenido y la compresión.
En Apache puedes especificar esto en el .htaccess con el siguiente código:
| 1 2 3 4 5 | <IfModule mod_headers.c> <FilesMatch ".(js|css|xml|gz|html)$"> Header append Vary: Accept-Encoding </FilesMatch> </IfModule> |
Aunque las herramientas de WPO marcan esto como un fallo relacionado con la velocidad de carga, puede causar más un problema de funcionalidad que de rendimiento.
Activar cache de navegador o browser cache
La cache de navegador es una de las cosas más útiles que me he encontrado en los 10 años que llevo metido en esto del WPO. Y eso que al principio la infravaloraba.
El browser cache nos permite ahorrar recursos en el servidor web y también ancho de banda en el hosting o servidor.
Puedes activar la cache de navegador para los tipos de archivos más comunes con este código en el .htaccess:
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | <IfModule mod_expires.c> ExpiresActive On ExpiresByType image/jpeg "access plus 1 year" ExpiresByType image/gif "access plus 1 year" ExpiresByType image/png "access plus 1 year" ExpiresByType image/webp "access plus 1 year" ExpiresByType image/svg+xml "access plus 1 year" ExpiresByType image/x-icon "access plus 1 year" ExpiresByType video/mp4 "access plus 1 year" ExpiresByType video/mpeg "access plus 1 year" ExpiresByType text/css "access plus 1 month" ExpiresByType text/javascript "access plus 1 month" ExpiresByType application/javascript "access plus 1 month" ExpiresByType application/pdf "access plus 1 month" ExpiresByType application/x-shockwave-flash "access plus 1 month" </IfModule> |
Esto sí que está directamente relacionado con el WPO y con el rendimiento web.
Como en el caso de la compresión GZIP / Deflate, la mayoría de plugins de cache ya se encargan de configurar la cache de navegador, aunque si queremos hacerlo de forma más “configurable” tenemos disponible este código.
Desactivar la etiqueta Etag
Las etiquetas ETag son identificadores únicos que se marcan en cada archivo enviado del servidor al navegador web. La utilidad del ETag es marcar esos archivos para se distingan las versiones cacheadas de las no cacheadas (siempre dentro del cache de navegador).
Podemos desactivar las etiquetas ETag simplemente poniendo esto en el .htaccess:
| 1 2 3 4 5 | <IfModule mod_headers.c> Header unset ETag Header set Connection keep-alive </IfModule> FileETag None |
Las etiquetas ETag no hacen milagros de cara al WPO, pero pueden ayudar a resolver problemas de cache de navegador o browser cache.
Deshabilitar el listado de carpetas
De forma predeterminada, en muchas ocasiones el servidor web envía un listado de carpetas y archivos al navegador del visitante si este introduce una URL que no está disponible.
Esto es un problema de seguridad, ya que permite que cualquier visitante vea todos los archivos subidos a nuestro hosting.
Con este código en el .htaccess podemos deshabilitar el listado de directorios si está activado.
| 1 | Options -Indexes |
En principio, este snippet funciona solo en Apache. Creo que no es válido para LiteSpeed.
Recuerda: esto es un básico para la seguridad de cualquier sitio web.
Desactivar el acceso a los tipos de archivos NO listados
Con este código mejoramos la seguridad, aunque de una forma bastante radical, ya que bloqueamos los accesos a todos los tipos de archivos menos los especificados en el .htaccess:
| 1 2 3 4 5 | Order deny,allow Deny from all <Files ~ ".(xml|css|js|jpeg|png|gif|pdf|docx|rtf|odf|zip|rar)$"> Allow from all </Files> |
Debemos personalizar el código de acuerdo a nuestras necesidades, aunque los del ejemplo son los tipos de archivo más comunes.
Desactivar la ejecución de PHP en Uploads
Este código es algo diferente. Debemos utilizarlo en un archivo .htaccess dentro de la carpeta UPLOADS de WordPress con el fin de que no se pueda ejecutar PHP dentro de esa carpeta.
¿Cuál es la razón para hacer esto? Pues que, en la práctica, no tiene por qué haber ningún archivo PHP dentro de UPLOADS. Con este código, evitamos que se pueda ejecutar uno en caso de que se use algún “exploit” para subirlo.
| 1 2 3 | <Files *.php> deny from all </Files> |
Recuerda: no lo utilices en el .htaccess principal del sitio web o lo que conseguirás es que falle.
Bloquear el acceso a los archivos importantes
Con este snippet en el .htaccess de un WordPress, mejoramos la seguridad de la instalación al bloquear el acceso externo a ciertos archivos importantes de WordPress que, en condiciones normales, no necesitan ser descargados nunca desde el navegador del visitante.
| 1 2 3 4 | <FilesMatch "^.*(error_log|wp-config|install|wp-login|xmlrpc\.php|php.ini|\.[hH][tT][aApP].*)$"> Order deny,allow Deny from all </FilesMatch> |
Una vez más, te recuerdo que para casos específicos debes personalizar este archivo y entenderlo. El motivo es que incluye comodines y, en ciertos casos, pueden llegar a dar problemas con algún plugin o componente de la instalación WordPress.
Bloquear AUTORES en WordPress
En versiones antiguas de WordPress y en ciertas circunstancias, es posible saber el nombre de usuario de un autor simplemente probando IDs.
Ahora verás cómo solucionarlo bloqueando de raíz, sobre todo si no utilizas los autores de WordPress para nada.
| 1 2 3 4 5 6 7 8 9 | RewriteEngine On RewriteBase / RewriteCond %{QUERY_STRING} (author=\d+) [NC] RewriteRule .* - [F] RewriteEngine on RewriteBase / RewriteCond %{QUERY_STRING} author=d RewriteRule ^ /? [L,R=301] |
Esto es una mejora importante para la seguridad de un WordPress y creo que deberíamos bloquearlo siempre.
¿Quieres
recibir mis articulos?
No te pierdas todos mis trucos para WordPress, CMS, Marketing Digital y WPO.
Bloquear el acceso a WP-INCLUDES de WordPress
La carpeta WP-INCLUDES de WordPress es una de las más importantes, ya que guarda librerías y componentes internos necesarios para que WordPress funcione.
Sin embargo, a la carpeta WP-INCLUDES no se tiene que acceder para nada desde fuera, es decir, desde el navegador del visitante. Por eso, podemos bloquear el acceso mediante el .htaccess con este código:
| 1 2 3 4 5 6 7 8 9 | <IfModule mod_rewrite.c> RewriteEngine On RewriteBase / RewriteRule ^wp-admin/includes/ - [F,L] RewriteRule !^wp-includes/ - [S=3] RewriteRule ^wp-includes/[^/]+\.php$ - [F,L] RewriteRule ^wp-includes/js/tinymce/langs/.+\.php - [F,L] RewriteRule ^wp-includes/theme-compat/ - [F,L] </IfModule> |
Es una manera de mejorar la seguridad, aunque tampoco hay muchos “ataques” contra esta carpeta excepto si por alguna razón ya existe previamente una brecha de seguridad.
Código para prevenir posibles inyecciones de código
Con este código en el .htaccess podemos llegar a bloquear algunas inyecciones de código básicas realizadas desde bots.
| 1 2 3 4 5 6 | Options +FollowSymLinks RewriteEngine On RewriteCond %{QUERY_STRING} (<|%3C).*script.*(>|%3E) [NC,OR] RewriteCond %{QUERY_STRING} GLOBALS(=|[|%[0-9A-Z]{0,2}) [OR] RewriteCond %{QUERY_STRING} _REQUEST(=|[|%[0-9A-Z]{0,2}) RewriteRule ^(.*)$ index.php [F,L] |
Ten cuidado con el efecto de este código, ya que puede provocar problemas y conflictos con algunos plugins para WordPress. En teoría ayuda a solucionar problemas, pero es importante estar preparados para los fallos que pueda llegar a dar. Es posible que tengamos que personalizar el código para adaptarlo a nuestro sitio web.
Protección contra HOTLINKING en WordPress
El hotlink puede llegar a dar muchos problemas en sitios web pequeños, ya que si te enlazan una imagen desde un sitio web grande con mucho tráfico puede llegar a “reventarte” el tráfico o ancho de banda de tu hosting rápidamente.
Podemos protegernos del hotlinking de una forma bastante “rastrera” pero eficaz con el siguiente código en el .htaccess:
| 1 2 3 4 5 6 | <IfModule mod_rewrite.c> RewriteEngine on RewriteCond %{HTTP_REFERER} !^$ RewriteCond %{HTTP_REFERER} !^https://(www\.)?midominio\.com/.*$ [NC] RewriteRule .*\.(gif|jpg)$ [R,NC,L] </ifModule> |
Aunque esto también es para nosotros, es decir, no podremos enlazar una imagen de nuestro sitio web y cargarla desde otro, ya que nos va a dar error. Incluso Google Images va a tener problemas con esto, ya que realmente Google Images hace bastante hotlinking.
Si quieres protegerte contra esto de otra forma, también puedes configurar un CDN como CloudFlare para servir las imágenes y no tener que preocuparte por el tema del ancho de banda en el hosting.
Modificar configuración de PHP
En algunos entornos (no en todos), podemos modificar el comportamiento del intérprete PHP directamente desde el .htaccess. Eso quiere decir que podemos modificar los límites.
Como he dicho esto no siempre es así, pero por si lo necesitas y quieres probar, te dejo el código que tienes que poner en el .htaccess:
| 1 2 3 4 | php_value upload_max_filesize 64M php_value post_max_size 64M php_value max_execution_time 300 php_value max_input_time 300 |
Aunque existe la opción, esto es más recomendable hacerlo desde un php.ini o desde el panel de control, como ocurre en todos los servidores cPanel o VestaCP de Raiola Networks.
Bloquear el XML-RPC.PHP en WordPress
El tweak del functions.php de WordPress no es la única forma de desactivar el XMLRPC, un protocolo que actualmente es objeto de bastantes ataques.
Con el .htaccess también puedes bloquear el funcionamiento del XML-RPC.PHP para evitar ataques de fuerza bruta contra él:
| 1 2 3 4 | <Files xmlrpc.php> order deny,allow deny from all </Files> |
Esto es solo un parche. Si quieres hacerlo bien, debes hacerlo con un plugin o con el functions.php. Si buscas un plugin para hacer esto, tal vez te interese probar el plugin Perfmatters.
Redirecciones desde el .htaccess
Sobra decir que desde el .htaccess podemos hacer todo tipo de redirecciones. Como no es el objetivo de este artículo, no voy a explicar todas las opciones que existen para esto.
Solo quiero recomendarte que, si tienes que hacer muchas redirecciones y quieres llevar más control sobre esto, puedes hacerlo mejor con un plugin de redirecciones como el de RankMath.
¿Quieres
recibir mis articulos?
No te pierdas todos mis trucos para WordPress, CMS, Marketing Digital y WPO.
20 Responses
hola alvaro en los hostings compartidos de raiola networks se puede hacer con lit speed lo de keep alive y en que apartado del htaccess???
Hola Marcos, en LiteSpeed no funciona tal y como he puesto en el articulo. Por otro lado, también tendríamos que tenerlo activo y no lo tenemos por motivos de recursos.
Por ponerte un ejemplo, si alojamos a los clientes en un hosting compartido con keep alive activo, el hosting debería ser el doble de caro, ya que el servidor seria mucho menos estable.
Hola ,
Escribo este mensaje ya por que no sé ni como hacer y a ver si tu puedes ayudarme por que ya me tiene desesperado…
He instalado limpio 5 veces wordpress, siempre lo instalo en una carpeta predeterminada (wp), osea que el dominio tira : (https)://dominio(.)tld/wp
Eso bien ahora quiero que se vea todo pues sin la carpeta /wp .
He modificado todo en wordpress para que en enlaces permanentes sea la misma dirección sin el /wp, te genera un htaccess, y bueno cuando creo links todo me sale : Internal Server Error
Sé que es por los enlaces …
Un saludo y espero que puedas.
Internal Server Error
Buff, Matias, la verdad es que…lo que quieres hacer es posible, pero…es lo que viene siendo una “ñapa” y que en actualizaciones puede reventar todo…
Aunque si que he visto instalaciones configuradas así, no son estables y suelen dar bastantes problemas. Tampoco nunca me he puesto a mirar exactamente que configuración realizar, ya que yo personalmente nunca lo he hecho…
Hola Álvaro
Espero que estés bien, con la que está cayendo.
Tengo dudas sobre mi file .htaccess
No he tocado el archivo porque no me atrevo, solo lo he ido viendo a medida que leía tu post. Veo que en mi archivo hay cosas que me hacen pensar que puede que tenga restos de plugins antiguos o cosas que, se me ocurre, podrían estar creando algunos conflictos (como que haya órdenes incompatibles entre ellas y cosas así. Por ejemplo hay restos de plugins que ya no tengo, como W3TC Browser Cache). El caso es que el archivo .htaccess me parece larguísimo (261 líneas ¿no es excesivo? Tal vez no, pero yo pregunto, por si acaso) y no sé si es que hay cosas innecesarias, otras que no me beneficien o incluso me estén perjudicando, como te decía.
Con la información que te doy, ¿me aconsejarías ponerme en contacto con Raiola para que me den presupuesto de revisión de esto los chicos de WordPress? Si quieres, te puedo enviar el archivo por email, no para que lo revises ni nada, solo que de un vistazo verás si hay posibles conflictos o no.
Gracias por el post. Siempre despiertas mi curiosidad con tus artículos y llevo años aprendiendo contigo y con Raiola.
Abrazo y cuídate
Esther
Hola Esther, ¿que tal?
Es normal que los plugins que vamos instalando vayan dejando rastros, sobretodo los de cache, aunque solo suelen dejar los comentarios.
Un .htaccess de 261 lineas no tiene por que ser demasiado, tambien depende mucho de lo que tengas instalado.
El tema, es que para que te hagas una idea, en muchos casos a la hora de resolver un problema en WordPress basta solo con resetear el .htaccess vaciandolo y obligando a WordPress a volverlo a generar.
¿Como se hace esto? Pues lo borras y después vas a la config de enlaces permanentes, reguardas para que vuelva a configurar los permalinks, y vas haciendo lo mismo con todos los plugins que escriban en el .htaccess y que tengas instalados. En algunos casos tendrás que cambiar algo y volver a configurarlo, para que detecte una configuración distinta y te la guarde.
Si quieres enviame el archivo por email a traves del form de contacto, pero vamos…tampoco soy infalible, puede que muchas “lineas” ni las reconozca. Si lo haces, mandame también el listado de plugins instalados actualmente.
Hola Álvaro!
Pero qué sol eres.
No sé si me atreveré a hacer esos tweaks que me dices (borrar etc.) por lo que dices que después tendré que cambiar y volver a configurar. Tocar archivos me da pánico, ya sabes que yo de esto soy una completa ignorante.
Te paso el archivo y el listado de plugins y me dices si debo contactar con tus compañeros de Raiola Wordpress.
Abrazo y cuídate.
Esther
Buenas Álvaro:
Tenemos la web en vuestros servidores.
Teneis el Gzip o Deflate activados por defecto? o tenemos que meter el código?
Hemos hecho un check en ésta página: https://www.giftofspeed.com/gzip-test/ (el enlace que tu has puesto está roto) y nos pone que esta activado.
Sin embargo nosotros no hemos programado nada.
Pues no te puedo decir con exactitud, ya que no me ocupo de ese tema.
Lo que si que puedo decirte es que si utilizas algún plugin de cache como WP Rocket, te lo activa por defecto.
Gracias por responder tan pronto.
Lo del enlace roto, no era de este post, si no de uno que tenéis publicado en Raiola sobre GZip de 2014 -2015 creo recordar.
Utilizamos principalmente código, y si no sabemos tiramos de plugins.
De chaché usamos wp-optimize. (principalmente para tema de bases de datos)
Entonces si nos aparece que está activado, no metemos nada en el htaccess, no?
Un saludo
Hola Rafa, no uso WP-Optimize ya que no me gusta, pero acabo de mirar su ficha en el repositorio de plugins de WordPress y si que te activa GZIP, por lo que posiblemente sea cosa del plugin.
Vuelvo a escribir otra vez
Hemos estado comprobando la web y lo que tenemos instalado es la comprensión por br.
Dejamos está o la cambiamos a Gzip?
Saludos
Mejor brotli que gzip, es mucho mas potente. Si tienes activo brotli, déjalo así.
Muchas gracias Álvaro por tu ayuda.
Un saludo
Hola Álvaro, tengo problemas con lectura de tipografía de iconos (adjunto error que aparece en consola)
Access to font at ‘https://secureservercdn.net/166.62.108.196/j7i.576.myftpupload.com/wp-content/themes/Impreza/fonts/fa-solid-900.woff2’ from origin ‘https://cirugiacabezaycuello.cl’ has been blocked by CORS policy: No ‘Access-Control-Allow-Origin’ header is present on the requested resource.
Me dicen en godaddy que deshabilite CDN en htacces, pero pregunto.. será eso??…
gracias u salduos!
Hola Kalko, es un problema de CORS, claro, si desactivas el CDN claro que lo vas a solucionar, pero no es el origen del problema.
Es como si me dices que te duele un brazo y te digo que no lo utilices…igual lo solucionas, pero no es el origen del problema.
La directiva CORS controlan la carga de scripts desde orígenes de terceros, es una directiva de seguridad, depende del CDN tendrás que implementar una solución u otra.
¿Cual es el CDN?
si me pudieran ayudar gracias .eso muestra al momento de selecionar enlaces permanentes pero el .htaccess ya esta creado.
Si tu archivo .htaccess tuviera permisos de escritura los cambios se harían automáticamente. Al no ser así, a continuación tienes las reglas de mod_rewrite que debes agregar manualmente a tu archivo .htaccess. Haz clic en el área de texto y pulsa CTRL + e para seleccionarlo todo.
Hola Linder, pues el plugin en cuestion que te muestra eso simplemente te dice que tu archivo .htaccess no tiene los permisos CHMOD correspondientes o que tiene problemas de permisos.
Puedes ajustar los permisos (https://raiolanetworks.es/blog/permisos-chmod-archivos-carpetas-wordpress/) o realizar los cambios manualmente con un cliente FTP como Filezilla.
Hola Álvaro! Qué tal? Quería hacerte una pregunta. En el supuesto de “Deshabilitar el listado de carpetas” el snippet es de una sola línea, muy cortito. Es así? Donde lo pondría? Antes de finalizar el htaccess?
Es decir, en mi caso se vería así? El era otra orden que ya tenía puesta.
Options -Indexes
# END WordPress
Gracias!!! 😀
Yo lo pondría debajo del #END WordPress