Un tema WordPress roto es aquel que, al activarse, genera errores de código o conflictos que impiden que el sitio funcione con normalidad, ya sea por incompatibilidad con la versión de WordPress o PHP, archivos corruptos, o dependencias faltantes. Si instalaste un tema y de repente tu sitio muestra pantalla blanca o errores críticos, lo que tenés es exactamente eso: un tema roto.
En 30 segundos
- Un tema incompatible puede dejar tu sitio inaccesible con pantalla blanca o error crítico: el problema más común es incompatibilidad con PHP 8.x o WordPress 6.8.
- Si perdiste acceso al panel, renombrá la carpeta del tema por FTP y WordPress va a volver al tema por defecto automáticamente.
- WordPress 5.2+ tiene Modo de Recuperación integrado: revisá el mail del administrador del sitio para el link de acceso.
- Siempre hacé backup antes de instalar un tema nuevo; WPVivid o cualquier plugin de backup en tu panel alcanza.
- Los temas de fuentes no verificadas (sitios de descarga «gratis») son la causa número uno de temas rotos con código malicioso o desactualizado.
WordPress es un sistema de gestión de contenidos (CMS) de código abierto desarrollado por Matt Mullenweg y mantenido por la Fundación WordPress, utilizado para crear y administrar sitios web, blogs y tiendas en línea.
Qué significa «un tema WordPress roto»
Un tema WordPress roto es cualquier tema que, al activarse, hace que el sitio deje de funcionar como se espera. No hablamos de «se ve raro» o «el logo está corrido» (eso es un tema problemático). Hablamos de pantalla en blanco, errores fatales PHP, o CSS que no carga y deja todo el contenido sin formato. La diferencia importa porque el diagnóstico y la solución son distintos.
Los síntomas clásicos son tres: la pantalla blanca de la muerte (WSOD), el mensaje «Ha habido un error crítico en este sitio web», o un frontend que carga el contenido pero sin ningún estilo, como si estuvieras leyendo HTML puro de los años 90. En todos los casos el tema es el primer sospechoso.
Causas principales de un tema dañado
La causa más frecuente en 2026 es la incompatibilidad con PHP 8.x. WordPress 6.8 recomienda PHP 8.3 (aunque el mínimo técnico es 7.2.24, ese número ya está deprecado según los requisitos oficiales de WordPress.org). Si instalás un tema hecho para PHP 7.2 en un servidor que corre 8.3, las chances de que algo se rompa son altas, porque PHP 8.x eliminó funciones que en versiones anteriores andaban sin problema.
Después viene la incompatibilidad con la versión de WordPress. Un tema que funcionaba perfecto en WordPress 6.0 puede tener problemas en 6.8 si el desarrollador no lo actualizó. Y si el tema tiene tres años sin actualizarse y lo descargaste de algún sitio de temas «premium gratis» (entre comillas, porque ya sabés lo que eso implica), las probabilidades de que tenga código roto o directamente código malicioso son considerables.
Otras causas, en orden de frecuencia: conflictos con plugins de seguridad o caché que interfieren con los assets del tema, cambios manuales al código del tema sin usar child theme, y archivos corruptos durante la subida por FTP con un cliente que transfería en modo ASCII en vez de binario (sí, sigue pasando).
Síntomas: cómo saber si es el tema
Ponele que activás un tema nuevo, la página se recarga, y donde antes estaba tu sitio ahora hay nada. O un mensaje que dice «Ha habido un error crítico». ¿Cómo sabés que es el tema y no un plugin? La lógica es simple: si pasó justo después de cambiar el tema, el tema es el culpable hasta que se demuestre lo contrario. Ya lo cubrimos antes en alternativas a los page builders temáticos.
| Síntoma | Causa probable | Dónde se ve |
|---|---|---|
| Pantalla blanca (WSOD) | Error fatal PHP en el tema | Frontend y/o admin |
| «Error crítico en este sitio» | Función de PHP deprecada o faltante | Frontend y/o admin |
| CSS completamente roto | Ruta de assets incorrecta o conflicto de caché | Solo frontend |
| Menús desordenados o ausentes | Incompatibilidad con walker de navegación | Solo frontend |
| Imágenes que no cargan | Rutas hardcodeadas o permisos de archivo | Frontend |
| Admin inaccesible | Error fatal en functions.php | Solo admin |
El detalle que muchos pasan por alto: si el admin sigue funcionando pero el frontend no, el problema es más acotado (probablemente CSS o template tags). Si ni siquiera podés entrar al panel de administración, el error está en functions.php o en algún archivo que carga en el init de WordPress.
Soluciones rápidas sin acceso al panel
Esta es la situación más estresante: instalaste un tema, todo se rompió, y el panel de WordPress no abre. La solución más directa es por FTP o SFTP.
El procedimiento es este: entrás al servidor con tu cliente FTP (FileZilla, WinSCP, lo que uses), navegás a /wp-content/themes/, y renombrás la carpeta del tema problemático. Si el tema se llama mi-tema-premium, lo renombrás a mi-tema-premium_old. Nada más. WordPress, al no encontrar el tema activo, va a volver automáticamente al tema por defecto (Twenty Twenty-Four en instalaciones actuales). Esto no borra nada, no rompe nada adicional, y es completamente reversible.
Después de eso, el panel debería estar accesible de nuevo. Desde ahí podés ver el error exacto que generó el tema (Herramientas → Salud del Sitio tiene más detalle) y decidir qué hacer.
Si no tenés acceso FTP y el sitio está alojado en donweb.com u otro proveedor con panel de hosting, muchos tienen un administrador de archivos web desde donde podés hacer exactamente lo mismo sin instalar nada.
Soluciones desde el panel de administración
Si todavía tenés acceso al panel (el tema rompió el frontend pero el admin funciona), el camino es más sencillo. Apariencia → Temas → activás Twenty Twenty-Four o cualquier otro tema que tengas instalado. Listo. El sitio vuelve a cargar y tenés tiempo para diagnosticar sin apuro.
Ahora bien, si sospechas que hay un conflicto con un plugin (y no con el tema en sí), el método estándar es desactivar plugins de a uno hasta encontrar el que genera el problema. Primero los de seguridad y caché, porque son los que más interfieren con el sistema de templates. Te puede servir nuestra cobertura de crear soluciones personalizadas con plugins.
WordPress 5.2 introdujo el Modo de Recuperación, que sigue activo en 6.8. Cuando hay un error fatal, WordPress manda un mail al administrador del sitio con un link especial para entrar al panel en modo seguro. Si instalaste el tema y recibiste ese mail, usá ese link antes de entrar por FTP, porque te da acceso directo al panel sin que los plugins carguen.
Verificar compatibilidad antes de instalar
¿Y qué pasó con la verificación previa? Exacto, la mayoría la saltea.
Para saber si un tema es compatible con tu instalación, necesitás tres datos: la versión de WordPress que tenés (Escritorio → Actualizaciones te lo dice), la versión de PHP del servidor (Herramientas → Salud del Sitio → Información → Servidor), y los requisitos del tema (en la página del repositorio o en el changelog del desarrollador).
WordPress 6.8 lista PHP 8.3 como la versión recomendada. Si tu hosting te ofrece actualizar PHP a 8.3, hacelo, pero primero verificá que tus plugins y temas existentes sean compatibles con esa versión. El plugin gratuito PHP Compatibility Checker, disponible en el repositorio oficial de WordPress.org, escanea tu instalación y te dice qué archivos tienen funciones incompatibles con la versión de PHP que elegís. No es perfecto, pero captura el 80% de los problemas.
Cómo prevenir temas rotos en el futuro
La regla de oro, y la que más gente ignora: backup antes de tocar nada. WPVivid (instalado acá en seguridadenwordpress.com, por ejemplo), UpdraftPlus, o el backup automático de tu hosting alcanzan. Un backup de hace 24 horas puede salvarte horas de trabajo.
Después, la fuente del tema importa mucho. Los temas del repositorio oficial de WordPress.org pasan por revisión de código (aunque no son infalibles). Los de marketplaces como Envato Elements tienen sus propios controles de calidad. Los temas de sitios de descarga sin nombre, esos que te ofrecen temas premium «gratis», son prácticamente ruleta rusa: código desactualizado, funciones deprecadas, y en muchos casos backdoors directamente.
Si vas a modificar el código de un tema, usá siempre un child theme. Si editás el tema padre directamente, cada actualización del tema pisa tus cambios y volvés a folio cero (o peor: la actualización mezcla tu código modificado con el nuevo y genera exactamente el tipo de error del que estamos hablando). Para más detalles técnicos, mirá proteger formularios tras cambios temáticos.
Por último, si tenés la posibilidad de testear en un entorno de staging antes de tocar producción, hacelo. La mayoría de los planes de hosting modernos lo incluyen.
Restaurar desde backup si nada funciona
Hay casos donde el tema no solo rompe el frontend: mezcla archivos, modifica la base de datos a través de su propio proceso de instalación, o genera un estado del que es difícil salir sin revertir todo. Para eso están los backups.
Si WPVivid está instalado y tenés un backup reciente, la restauración es desde el propio plugin (o desde su interfaz de recuperación si el panel no carga). Si el backup está en el hosting, el proveedor generalmente ofrece restauración desde el panel de control. Si ninguna de las dos opciones está disponible y el sitio está completamente caído, el camino es contactar al soporte del hosting con el backup manual más reciente que tengas.
La lección acá no es técnica, es operativa: un backup del que no sabés que existe o que no sabés cómo restaurar no es un backup, es una ilusión de seguridad.
Errores comunes
Error 1: instalar el tema en producción directamente. El impulso de «lo pruebo acá que es más rápido» termina exactamente así, con el sitio caído. Staging existe para esto.
Error 2: borrar la carpeta del tema en vez de renombrarla. Si renombrás, podés revertir. Si borrás y resulta que la base de datos tenía configuraciones guardadas del tema, vas a necesitar reinstalarlo y volver a configurarlo desde cero. El renombrado es siempre reversible. Cubrimos ese tema en detalle en opciones gratuitas para restaurar funcionalidades.
Error 3: actualizar PHP sin verificar compatibilidad previa. La actualización de PHP rompe más sitios que los temas en sí. Antes de cambiar la versión de PHP en tu hosting, usá el PHP Compatibility Checker y revisá la documentación de tus plugins más críticos (WooCommerce, Elementor, los de seguridad).
Preguntas Frecuentes
¿Cómo reparar un tema WordPress que arruinó mi sitio?
El primer paso es desactivarlo. Si tenés acceso al panel, cambiá a cualquier otro tema desde Apariencia → Temas. Si no tenés acceso, conectate por FTP, navegá a /wp-content/themes/ y renombrá la carpeta del tema problemático agregando _old al final. WordPress va a volver al tema por defecto automáticamente y vas a recuperar el acceso al panel.
¿Qué hago si instalé un tema y todo dejó de funcionar?
Verificá primero si llegaste a recibir un mail del sistema con un link de Modo de Recuperación (WordPress 5.2+). Si tenés ese link, entrá al panel en modo seguro y desactivá el tema desde ahí. Si no, usá FTP para renombrar la carpeta del tema. En ningún caso borres archivos sin antes intentar el renombrado, que es reversible.
¿Cómo desactivar un tema de WordPress sin acceso al panel?
Por FTP o SFTP: entrás al servidor, vas a /wp-content/themes/, y renombrás la carpeta del tema activo (por ejemplo, de mi-tema a mi-tema_bak). WordPress detecta que el tema activo no existe y vuelve al tema por defecto instalado. También podés hacerlo desde el administrador de archivos de tu panel de hosting si no tenés cliente FTP.
¿Por qué mi tema WordPress causa pantalla blanca?
La pantalla blanca de la muerte (WSOD) casi siempre es un error fatal de PHP. Los motivos más frecuentes son: una función de PHP usada por el tema que fue eliminada en PHP 8.x (como create_function() o each()), un archivo del tema que tiene un error de sintaxis, o un conflicto con algún plugin que carga antes del tema. Activá el log de errores de PHP o revisá el archivo de log de tu servidor para ver el error exacto.
¿Es reversible el daño de un tema incompatible?
En la gran mayoría de los casos, sí. Desactivar el tema (por FTP si es necesario) revierte el sitio al estado anterior. La excepción son los temas que instalan tablas propias en la base de datos o que modifican opciones del sitio durante la activación: en esos casos puede quedar «basura» en la base de datos, pero rara vez genera daño funcional real. Si el sitio quedó en un estado raro después de desactivar el tema, restaurar desde un backup es la opción más limpia.
Conclusión
Un tema WordPress roto no es el fin del mundo, pero sí puede serlo para alguien que no sabe cómo salir de la situación. El diagnóstico es simple: si el sitio se rompió justo después de activar un tema, ese tema es el problema. La solución también es simple, ya sea desde el panel o por FTP. Lo que cambia el resultado a largo plazo es el hábito: backup antes de instalar, verificar compatibilidad de versiones, y nunca tocar código de producción sin una red de seguridad. Si aplicás esas tres cosas, la próxima vez que un tema se rompa vas a tardar tres minutos en resolverlo, no tres horas.