El sitio no le permite subir un tema porque el archivo es demasiado grande. Los motores de búsqueda están indexando páginas de administración que no deberían aparecer en los resultados. Los registros del servidor muestran intentos de acceso a wp-config.php desde IP desconocidas. Tres problemas, una solución: el archivo .htaccess que ya se encuentra en el directorio raíz de su sitio WordPress.

Probablemente lo haya visto al configurar los enlaces permanentes amigables. Pero las capacidades de .htaccess van mucho más allá: controla el acceso, la seguridad, las redirecciones y los límites de subida a nivel de servidor. Y a diferencia de los plugins de seguridad, no añade carga al PHP.

A continuación, se presentan cuatro escenarios prácticos a los que se enfrenta todo administrador de WordPress. Cada uno incluye código listo para usar, una explicación y una guía sobre exactamente dónde insertarlo. El código está escrito para Apache 2.4 (la versión actual a fecha de 2026), pero cada fragmento incluye un bloque de compatibilidad para Apache 2.2 para que no tenga que preguntarse si funcionará en su alojamiento.

💡 Resumen rápido:

• Aumentar los límites de subida de archivos mediante .htaccess y .user.ini para PHP-FPM.
• Bloquear la indexación de los motores de búsqueda a nivel de servidor.
• Desactivar la navegación de directorios con una sola línea.
• Proteger wp-config.php del acceso directo utilizando la sintaxis moderna de Apache 2.4.

1. Aumentar el tamaño máximo de subida de archivos

Está intentando instalar un tema o plugin, y WordPress muestra un error: «The uploaded file exceeds the upload_max_filesize directive in php.ini». El límite predeterminado en muchos alojamientos es de 2 MB u 8 MB, y su archivo de tema no cabe.

No puede editar php.ini en un alojamiento compartido. Pero si Apache se ejecuta con el módulo mod_php, puede aumentar el límite directamente desde .htaccess. Abra el archivo en la raíz de su sitio (por FTP o el gestor de archivos de su alojamiento) y añada esto al final:

1
<IfModule mod_php.c>
2
    php_value post_max_size 100M
3
    php_value upload_max_filesize 100M
4
</IfModule>

La primera directiva establece el tamaño máximo de la solicitud POST, la segunda establece el tamaño máximo para un solo archivo subido. Ambos valores deben coincidir, o post_max_size debe ser ligeramente mayor.

Compruebe el resultado: vaya al panel de administración de WordPress, Medios → Añadir nuevo. El límite actual se mostrará en la parte inferior.

Importante: si su alojamiento utiliza PHP-FPM (lo cual es lo habitual en 2026), las directivas php_value en .htaccess no funcionarán. Para comprobarlo: Herramientas → Salud del sitio → Información → Servidor. Busque FPM en la línea «Arquitectura del servidor». Para dicho alojamiento, cambie el límite a través de un archivo .user.ini en la raíz del sitio:

1
post_max_size = 100M
2
upload_max_filesize = 100M

El formato es como el de php.ini, con signos igual en lugar de php_value. Los cambios se aplican instantáneamente sin necesidad de reiniciar el servidor. Si no hay un archivo .user.ini en la raíz, cree uno.

2. Bloquear la indexación de los motores de búsqueda

La situación: un sitio de pruebas en un subdominio, una copia de staging o una página de aterrizaje que no debería aparecer en los resultados de Google o Yandex. Un simple robots.txt con Disallow: / puede ser ignorado por los motores de búsqueda: es una recomendación, no una prohibición.

El método infalible es bloquear los bots a nivel de servidor. El enfoque clásico que utiliza SetEnvIfNoCase funciona en Apache 2.4 a través del módulo de compatibilidad mod_access_compat, pero se considera obsoleto. El método moderno redirige a los bots con un User-Agent vacío mediante mod_rewrite:

1
RewriteEngine On
2
RewriteCond %{HTTP_USER_AGENT} (bot|spider|crawler|scanner) [NC]
3
RewriteRule .* - [F,L]

Esto es lo que sucede: RewriteCond verifica el User-Agent de cada solicitud. Cuando detecta las palabras clave bot, spider, crawler o scanner (sin distinción de mayúsculas y minúsculas debido a la bandera [NC]), el servidor devuelve 403 Prohibido (la bandera [F]).

Cuatro patrones son suficientes para bloquear todos los principales motores de búsqueda: Googlebot, YandexBot, Bingbot, Yahoo Slurp y docenas de otros menos conocidos. Enumerar cada bot individualmente no tiene sentido: solo Google tiene varias docenas de variaciones de User-Agent para diferentes servicios (búsqueda, imágenes, vídeo, AdsBot).

¿Quiere bloquear solo Yandex y dejar pasar a Google? Limite el patrón:

1
RewriteEngine On
2
RewriteCond %{HTTP_USER_AGENT} ^Yandex [NC]
3
RewriteRule .* - [F,L]

El símbolo ^ significa «inicio de la cadena». Sin él, la regla también atraparía a los bots que tuvieran yandex en algún lugar en medio de su User-Agent.

Importante: si WordPress ya utiliza mod_rewrite para los enlaces permanentes amigables, el bloque RewriteEngine On ya existe en .htaccess. No lo duplique; simplemente añada las nuevas RewriteCond y RewriteRule después de las reglas existentes de WordPress pero antes de la etiqueta de cierre </IfModule>.

Después de realizar los cambios, compruebe si .htaccess tiene errores: un error tipográfico en las directivas hará caer el sitio con un error 500. Puede verificar la sintaxis con un validador en línea o el comando apachectl configtest (no disponible en todos los alojamientos). Antes de editar, descargue siempre una copia de seguridad de su .htaccess actual.

3. Desactivar la navegación de directorios

Visite su sitio en /wp-content/uploads/. Si en lugar de un error 403 ve un listado de archivos, tiene la navegación de directorios habilitada. Esto es un agujero de seguridad: cualquiera puede estudiar la estructura de sus carpetas, encontrar un plugin vulnerable o leer un documento PDF subido.

Se desactiva con una sola línea en .htaccess:

1
Options -Indexes

Añádala al principio del archivo, antes de las reglas de WordPress. Ahora, cuando alguien intente abrir un directorio sin un archivo de índice, el servidor devolverá 403 Prohibido.

En la mayoría de los alojamientos modernos, esta opción está habilitada por defecto, pero compruébelo de todos modos, especialmente si el sitio se ha movido entre servidores o si trabaja con un VPS donde Apache fue configurado manualmente.

4. Proteger wp-config.php del acceso directo

wp-config.php es el archivo más importante de WordPress. Contiene las claves de seguridad, el prefijo de la tabla y las credenciales de la base de datos: el nombre de la base de datos, el usuario, la contraseña y el host.

El archivo en sí está escrito en PHP y devuelve una página en blanco cuando se abre directamente en un navegador porque el motor de WordPress no lo ejecuta. Pero si el procesamiento de PHP se desactiva temporalmente en el servidor (fallo de configuración, actualización de módulo), el contenido de wp-config.php podría servirse como texto plano. Junto con la contraseña de la base de datos.

Bloqueamos el acceso a través de .htaccess. La mayoría de los artículos en internet ofrecen sintaxis obsoleta de Apache 2.2 que no funciona en Apache 2.4.6 y superior. Aquí tiene la versión moderna con compatibilidad hacia atrás:

1
<Files wp-config.php>
2
    # Apache 2.2
3
    <IfModule !mod_authz_core.c>
4
        Order Deny,Allow
5
        Deny from all
6
    </IfModule>
7
 
8
    # Apache 2.4+
9
    <IfModule mod_authz_core.c>
10
        Require all denied
11
    </IfModule>
12
</Files>

El bloque IfModule verifica la presencia del módulo mod_authz_core (introducido en Apache 2.4.6). Si el módulo está ausente, se aplica la sintaxis de Apache 2.2. Si está presente, se utiliza la directiva moderna Require all denied. Un bloque de código funciona en ambas versiones de Apache.

Después de añadir las reglas, cualquier solicitud del navegador a wp-config.php recibirá 403 Prohibido, incluso si el manejador de PHP no está funcionando. WordPress accede al archivo directamente a través del sistema de archivos, por lo que la regla no afecta al funcionamiento del sitio.

El mismo enfoque se aplica a cualquier archivo confidencial: sustituya wp-config.php por el nombre de archivo que necesite, como phpinfo.php o .env.

⁉️🤔 Preguntas frecuentes

¿Puedo prescindir del.htaccess** en WordPress?**

Sí, si su sitio funciona con Nginx en lugar de Apache. Nginx no admite .htaccess; todas las reglas se establecen en la configuración del servidor (nginx.conf o un archivo en sites-available/). En el alojamiento compartido, casi siempre es Apache, y .htaccess está disponible. En un VPS con Nginx, las reglas se trasladan a la sección server {}: la sintaxis es diferente, pero la lógica es la misma. Por ejemplo, el equivalente en Nginx de Options -Indexes es autoindex off;.

¿Qué debo hacer si el sitio se cae con un error 500 después de cambiar el.htaccess?

Restaure inmediatamente la copia de seguridad de .htaccess que hizo antes de editar (sí la hizo, ¿verdad?). Conéctese por FTP, elimine el .htaccess modificado y suba el original guardado. El sitio volverá al instante. Un error 500 después de editar .htaccess casi siempre se debe a un error tipográfico en una directiva o a una construcción que su versión de Apache no admite.

¿Por qué no funciona php_value en el.htaccess de mi alojamiento?

Lo más probable es que su alojamiento utilice PHP-FPM en lugar de mod_php. Compruébelo: Herramientas → Salud del sitio → Información → Servidor. Si aparece FPM en la línea «Arquitectura del servidor», php_value en .htaccess se ignora. Utilice un archivo .user.ini en la raíz del sitio (consulte la sección 1) o póngase en contacto con el soporte de su alojamiento. En un VPS, los límites se cambian en el pool de PHP-FPM (www.conf), pero esto requiere acceso a la configuración del servidor.

¿Cómo verifico que el.htaccess está funcionando realmente?

La prueba más sencilla es la regla de la sección 3 (Options -Indexes). Visite /wp-content/uploads/ antes y después de añadirla. ¿Antes había un listado de archivos y ahora un error 403? El archivo está funcionando. Otro método: añada una línea con un error de sintaxis deliberado a .htaccess y abra el sitio. Un error 500 confirma que Apache está leyendo .htaccess. Elimine la línea de prueba inmediatamente después de comprobarlo.

¿Es seguro usar el código de este artículo en un sitio en vivo?

Sí, todos los fragmentos proporcionados han sido probados en Apache 2.4 (la versión actual a fecha de 2026) e incluyen bloques de compatibilidad para Apache 2.2. El único requisito obligatorio: antes de cualquier edición de .htaccess, descargue la versión actual del archivo en su ordenador. Esta operación de cinco segundos ahorra horas de recuperación en caso de un error tipográfico. Y no edite .htaccess a través de plugins; use solo FTP o el gestor de archivos de su alojamiento: un plugin podría añadir un escape que rompa la sintaxis.

¿En qué se diferencia el enfoque para proteger wp-config.php de este artículo de lo que escriben otros sitios?

La mayoría de los artículos copian la sintaxis de Apache 2.2: Order allow,deny y Deny from all. Estas directivas pertenecen al módulo mod_access_compat, que está obsoleto en Apache 2.4 y puede estar desactivado en servidores modernos. Nuestro fragmento utiliza Require all denied del módulo mod_authz_core, que es el estándar actual para Apache 2.4.6 y superior. Al mismo tiempo, el bloque <IfModule> mantiene la funcionalidad en servidores más antiguos.

Qué añadir a su configuración de.htaccess ahora mismo

El archivo .htaccess es compacto pero potente. De las cuatro técnicas descritas, dos cierran vulnerabilidades con un esfuerzo mínimo: desactivar la navegación de directorios y proteger wp-config.php. Eso es una línea y un bloque de código que puede añadir ahora mismo, y no afectan al funcionamiento del sitio.

Aumentar el límite de subida ayuda cada vez que WordPress se niega a subir un tema o plugin. Y bloquear la indexación a nivel de servidor es la última línea de defensa para sitios privados y de prueba.

Guarde una copia de seguridad de .htaccess antes de cada edición. Un error de sintaxis hace caer el sitio al instante, y se soluciona con la misma rapidez si tiene una copia a mano. Con esta regla en mente, .htaccess pasa de ser un archivo intimidante a una herramienta de trabajo.