WordPress
Entender .htaccess en KapsuleHost
Kapsule serves every website with a high performance web server that does not read .htaccess, so rules you add to that file have no effect: this guide explains what that means for a WordPress site…
Entender .htaccess en KapsuleHost
Kapsule sirve cada sitio web con un servidor web de alto rendimiento que no lee .htaccess, por lo que las reglas que agregues a ese archivo no tienen efecto: esta guía explica qué significa eso para un sitio WordPress y muestra la configuración de KPanel que hace cada trabajo en su lugar.
Si has migrado desde un host compartido cPanel, .htaccess probablemente era donde ponías redirecciones, forzado HTTPS, páginas de error personalizadas y bloqueos de bots. Todas esas cosas aún funcionan en Kapsule. Simplemente se configuran en KPanel en lugar de en un archivo de texto, y como se aplican a nivel de servidor son más rápidas y no pueden romper tu sitio con un error tipográfico.
Por qué .htaccess no hace nada aquí
.htaccess es un archivo de configuración por directorio para el servidor web Apache. Apache lo relee en cada solicitud, lo que lo hace conveniente y también lo que lo hace lento.
Kapsule no ejecuta Apache. Tu sitio es servido por un servidor web basado en eventos que carga su configuración una sola vez al iniciarse, que es una gran parte de por qué los sitios aquí responden más rápido bajo carga. Ese servidor no tiene equivalente de un archivo de anulación por directorio, por lo que nunca abre .htaccess.
Agregar reglas a .htaccess en un sitio Kapsule falla silenciosamente. Nada genera errores, nada advierte, y el archivo permanece exactamente donde lo dejaste. Las reglas simplemente nunca se ejecutan. Si estás siguiendo un tutorial de WordPress que dice "agrega esto a tu .htaccess", encuentra el equivalente de KPanel en la tabla a continuación.
La buena noticia es lo opuesto de la historia habitual de horror con .htaccess: un error de sintaxis en el archivo no puede tumbar tu sitio aquí, porque nada lo analiza.
Qué aún funciona sin él
Enlaces permanentes. La razón más común por la que un sitio WordPress necesita .htaccess en Apache son los enlaces permanentes bonitos. En Kapsule la reescritura está integrada en la configuración del servidor de tu sitio, por lo que /2026/07/my-post/ se resuelve a través de WordPress sin un bloque .htaccess en absoluto. Si los enlaces permanentes devuelven 404s, la causa es otra: consulta Solucionar problemas de enlaces permanentes de WordPress.
WordPress escribiendo en el archivo. WordPress y algunos plugins aún escriben bloques # BEGIN/# END en .htaccess porque asumen Apache. Eso es inofensivo. El archivo es real, es escribible, y lo verás en el administrador de archivos. Simplemente no tiene lector.
Plugins de seguridad que reportan "endurecimiento aplicado". Los plugins que afirman haber bloqueado xmlrpc.php o wp-config.php editando .htaccess no han protegido realmente nada en esta plataforma. Usa la pestaña Security del sitio, que aplica las reglas equivalentes en el servidor.
Equivalentes de KPanel para reglas comunes de .htaccess
Cada uno de estos se encuentra en el sitio mismo: Websites, luego tu sitio, luego la pestaña que se muestra.
| Lo que hubieras escrito en .htaccess | Dónde vive en KPanel |
|---|---|
RewriteCond %{HTTPS} off para forzar HTTPS | Settings, luego Force HTTPS bajo Behavior |
Redirect 301 /old /new | Advanced, luego Redirects |
ErrorDocument 404 /404.html | Advanced, luego Error pages |
AuthType Basic para proteger una carpeta con contraseña | Advanced, luego Password protection |
Require not ip 203.0.113.4 para bloquear una dirección | WordPress, luego Security |
RewriteCond %{HTTP_USER_AGENT} (BadBot) para bloquear rastreadores | Performance, luego Crawlers |
DirectoryIndex index.php index.html | Settings, luego Directory index bajo Serving |
mod_deflate / mod_expires para compresión y almacenamiento en caché | Ya activo. La compresión y los encabezados de caché se configuran en el servidor |
Dos de estos hacen más que la versión .htaccess nunca pudo hacer. Los redireccionamientos admiten rutas exactas, prefijos de barra diagonal final y comodines como /blog/*, y KPanel verifica el redireccionamiento en vivo después de guardarlo. Las páginas de error se sirven con su código de estado verdadero, por lo que una página 404 personalizada sigue siendo un verdadero 404 para los motores de búsqueda en lugar de un 200 con una disculpa.

Encontrar y leer el archivo
Aún puedes querer buscar en .htaccess, generalmente para ver qué un plugin ha escrito en él o para copiar reglas antes de recrearlas en KPanel.
Desde la pestaña WordPress
- Inicia sesión en KPanel y haz clic en Websites en la barra lateral izquierda.
- Haz clic en el sitio que deseas.
- Abre la pestaña WordPress, luego la sección wp-config.
- Desplázate al panel
.htaccess. El contenido se muestra de solo lectura, con un botón Edit si necesitas cambiarlos.
Desde el administrador de archivos
- Abre el sitio, luego Files, luego File Manager.
- Haz clic en Show Hidden en la barra de herramientas. Los archivos que comienzan con un punto están ocultos por defecto, por lo que
.htaccessno aparecerá hasta que lo hagas. - Haz clic en
.htaccesspara abrirlo en el editor integrado.
El archivo se encuentra en la raíz de tu sitio, junto a wp-config.php y wp-content. Los detalles completos sobre el editor y sus controles de permisos están en Using the File Manager.
Haz una copia de seguridad antes de editar cualquier cosa en la raíz del sitio, incluso un archivo que no está siendo leído. No cuesta nada y significa que un clic te devuelve. Consulta Taking a Backup.
El bloque WordPress por defecto
Para referencia, este es el bloque que WordPress escribe para sí mismo. En un host Apache impulsa los enlaces permanentes. En Kapsule es inerte, y eliminarlo no romperá nada:
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
Déjalo en su lugar si podrías mover el sitio a un host Apache más tarde. WordPress lo reescribirá de todos modos la próxima vez que guardes la configuración de enlaces permanentes.
Si estás migrando reglas
Cuando traes un sitio desde cPanel, abre el antiguo .htaccess antes de cancelar el alojamiento antiguo y trabaja en él línea por línea:
- Redireccionamientos. Recrea cada
RedirectoRewriteRuleen Advanced, luego Redirects. Una fila por regla. Elige 301 para un movimiento permanente, 302 si el cambio podría revertirse. - Forzado HTTPS. Elimínalo. Activa Force HTTPS en Settings del sitio en su lugar.
- Bloqueos de IP. Recrea en WordPress, luego Security, en el panel de bloqueo de IP.
- Encabezados de caché y compresión. Elimínalos. Se manejan para ti, y las reglas
mod_expiresantiguas de un host anterior son una fuente común de comportamiento de caché confuso. - Cualquier cosa que un plugin haya escrito. Ignóralo. Reinstala el plugin en el nuevo sitio y déjalo hacer su propia cosa.
Tu migración mantiene el archivo en sí, por lo que nada se pierde mientras trabajas en la lista. Tutorial de migración completo: Migrating a Website From cPanel.
Solución de problemas
"Agregué un redireccionamiento a .htaccess y nada sucedió." Esperado. Agrégalo en Advanced, luego Redirects. La columna Status ahí te dice si el redireccionamiento fue verificado en vivo.
"Un plugin dice que mi sitio está endurecido pero un escáner no está de acuerdo." El plugin escribió reglas .htaccess que no están siendo leídas. Revisa la pestaña Security del sitio para ver las protecciones que se aplican genuinamente.
"El .htaccess del antiguo host tenía reglas que no entiendo." No las copies a ciegas. Abre un ticket con el archivo adjunto y te diremos cuáles tienen un equivalente de Kapsule y cuáles solo compensaban un host Apache compartido.
"Los enlaces permanentes están rotos." Esto no es un problema .htaccess aquí. Ve a Fixing WordPress Permalink Issues, o vacía las reglas de reescritura desde la pestaña WordPress del sitio, luego Quick Actions, luego Flush Rewrites.