Auditoría de .htaccess: por qué el sitio devuelve 500 y qué reglas no funcionan
Arrastre el archivo: la herramienta encontrará el BOM, las directivas muertas, las reglas con alto riesgo de error 500 y los indicios de una intervención ajena. El archivo se lee en su navegador y no se envía a ningún sitio.
El texto se ha pegado a mano, por lo que se ha omitido el bloque de comprobaciones de bytes. Para ver el BOM, los CRLF y los caracteres invisibles, arrastre el propio archivo.
Un .htaccess limpio no cura un hackeo. Si el sitio está comprometido, el código malicioso vive en el PHP y el .htaccess es solo su consecuencia: el dropper reescribirá el archivo a los pocos minutos de que usted lo limpie. El orden es el inverso: primero encontrar el código ejecutable y después ordenar la configuración.
Aquí aparecerá el archivo original con los números de línea.
Las líneas con hallazgos se marcan con !: rojas para errores, ámbar para avisos. Los caracteres invisibles y no imprimibles se muestran con un punto ·; en el archivo, en su lugar no hay nada.
La limpieza elimina el BOM, pasa los saltos de línea a LF, quita los caracteres no imprimibles, sustituye los espacios de no separación por espacios normales y añade un salto de línea final. Las directivas no se modifican. El archivo se guarda como htaccess-clean.txt: renómbrelo a .htaccess antes de subirlo al servidor.
# BEGIN WordPress
# The directives (lines) between "BEGIN WordPress" and "END WordPress" are
# dynamically generated, and should only be modified via WordPress filters.
# Any changes to the directives between these markers will be overwritten.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
Esto es exactamente lo que escribe WordPress por su cuenta. Ponga sus propias reglas por encima de la línea # BEGIN WordPress: todo lo que hay entre los marcadores se reescribe cada vez que guarda los ajustes de enlaces permanentes.
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
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]
</IfModule>
# END WordPress
Para un multisitio en subdominios el bloque es el mismo, pero sin el prefijo ^([_0-9a-zA-Z-]+/)? en las tres últimas reglas: RewriteRule ^(wp-(content|admin|includes).*) $1 [L] y RewriteRule ^(.*\.php)$ $1 [L].
Sustituir el bloque no restaura los enlaces permanentes por sí solo: tras la edición, vaya a Ajustes → Enlaces permanentes y pulse «Guardar»: WordPress comprobará el bloque y lo reescribirá si hace falta.
El archivo se lee en su navegador: su contenido no se envía a ningún sitio ni se guarda.
Por qué un archivo y no texto pegado
La causa más frecuente de un error 500 tras editar .htaccess no se ve en el texto. Es el BOM: tres bytes invisibles al principio del fichero que añade el Bloc de notas de Windows al guardar en UTF-8. Apache los considera parte de la primera directiva y no puede analizarla. Por eso la herramienta pide el fichero en sí: solo así se pueden leer los bytes y ver el BOM, los saltos de línea al estilo de Windows y los caracteres invisibles dentro de las líneas. El segundo grupo de problemas son las directivas que no hacen nada pero parecen operativas. mod_gzip_on es sintaxis de Apache 1.3; en los servidores actuales se ignora en silencio mientras uno lleva años creyendo que la compresión está activada. Un bloque ExpiresByType envuelto en una comprobación de mod_headers.c en lugar de mod_expires.c tampoco funcionará, y sin un aviso no se nota. En tercer lugar, php_value y php_flag. Solo funcionan cuando PHP está cargado como módulo de Apache. En los alojamientos modernos con PHP-FPM esa línea o se ignora o devuelve un 500 de inmediato. Y aparte, sobre seguridad: si en el fichero hay reglas que redirigen a los visitantes según el buscador del que vienen, o que ocultan la redirección al administrador, es una señal típica de compromiso. Pero un .htaccess limpio no cura el hackeo: casi siempre hay en algún lugar de los ficheros un script PHP que volverá a escribirlo.