Los bugs más raros de WordPress (y cómo resolverlos)
WordPress tiene bugs raros. No los raros simpáticos que encontrás en documentación, sino esos que te hacen perder dos horas pensando que el problema es tu configuración, tu hosting, o tu cordura. En 2026, con WordPress 6.8 en camino y el editor de bloques madurando, algunos problemas de siempre siguen apareciendo — y algunos nuevos se sumaron.
En 30 segundos
- Los problemas raros de WordPress suelen tener causas no tan raras: conflictos de caché, plugins que tocan el mismo hook, permisos de archivos mal seteados o PHP deprecado.
- El editor de bloques (Gutenberg) introdujo una nueva categoría de bugs que no existían con el editor clásico: problemas de serialización de bloques y conflictos de atributos.
- El 60% de los sitios WordPress corre versiones de PHP ya sin soporte activo, lo que amplifica cualquier problema de compatibilidad.
- La mayoría de los “bugs raros” se pueden aislar desactivando plugins en orden y usando un tema por defecto — el proceso lleva menos de 10 minutos pero poca gente lo hace primero.
- Algunos problemas son específicos del entorno de hosting y no van a aparecer en local ni en staging si el servidor es diferente.
WordPress es el gestor de contenidos más usado del mundo, con más del 43% del total de sitios web activos corriendo sobre él. Con esa escala vienen los beneficios del ecosistema, pero también vienen los problemas de compatibilidad, los plugins que se pisan entre sí y los bugs que aparecen en producción y no en local. Este artículo recorre los problemas más frecuentes y menos documentados que aparecen en 2026.
El loop de redirección que no termina nunca
Ponele que publicás un cambio en las URLs permanentes (permalinks), recargás la página y el navegador te tira “Esta página web tiene un bucle de redirección”. Clásico. Y sin embargo, cada vez que pasa, uno duda de sí mismo.
La causa más frecuente en 2026 es un conflicto entre el archivo .htaccess mal generado y un plugin de caché que sirve la versión vieja. El proceso para resolverlo es siempre el mismo: desactivar el plugin de caché, regenerar los permalinks, vaciar la caché del servidor (si tenés caché a nivel servidor en tu hosting), y recién ahí reactivar el plugin.
Si seguís viendo el loop después de eso, el problema está en el .htaccess. WordPress necesita escribir ahí, y si el archivo tiene permisos 444 (solo lectura), no puede hacerlo. ¿Cuándo pasa eso? Cuando alguien “securizó” el servidor y olvidó que WordPress necesita escribir ese archivo en ciertas circunstancias.
Bloques de Gutenberg que se “invalidan” solos
Este es nuevo, o más visible desde 2023. Abrís un post en el editor y aparece el aviso: “Este bloque contiene contenido inesperado o no válido”. El bloque ya no carga en modo visual — solo te muestra el HTML crudo y te pregunta si querés recuperarlo o convertirlo. Ya lo cubrimos antes en si tu sitio está en varios idiomas.
Lo que pasó es un problema de serialización. Cada bloque de Gutenberg guarda sus atributos en comentarios HTML dentro del contenido del post. Si un plugin filtró ese HTML (para limpiar tags “peligrosos”, por ejemplo), o si actualizaste un plugin que cambió el schema de sus bloques sin migración, el comentario serializado ya no matchea con lo que el bloque espera.
La “solución” oficial de WordPress es recuperar el bloque clásico y convertirlo, pero eso implica perder la estructura. La solución real es identificar qué plugin tocó el contenido y cuándo — que no siempre es trivial. Si tenés revisiones activadas (y deberías), podés comparar el HTML de antes y después para encontrar qué cambió.
Ojo con esto: algunos plugins de seguridad con filtros de XSS agresivos mutan el contenido al guardarlo. Si el plugin filtra atributos data-*, y tu bloque usa data-* para guardar configuración, cada save va a “limpiar” los atributos del bloque y eventualmente va a romperlo.
El admin que carga pero el front que no
Cualquiera que haya administrado WordPress por más de tres años se topó con esto: el admin funciona perfecto, publicás un post, vas a verlo en el front y te tira un error 500, una pantalla blanca, o una versión de la página que ignora el último cambio.
Hay tres causas principales y una trampa.
La causa 1 es la caché de página completa. Si tenés W3 Total Cache, WP Super Cache, o caché a nivel servidor (como Nginx FastCGI cache en donweb.com), el front puede estar sirviendo una versión cacheada que ignora los cambios nuevos. La caché del admin no se toca — por eso el admin muestra la versión correcta. Solución: vaciar todos los niveles de caché en orden (plugin, servidor, CDN si usás Cloudflare).
La causa 2 es un hook que corre en el front y no en el admin. Un plugin que hace algo en wp_head o template_redirect puede romper el front sin afectar el panel. Para identificarlo, agregá define('WP_DEBUG', true); y define('WP_DEBUG_LOG', true); al wp-config.php, reproducí el error, y revisá el archivo debug.log.
La causa 3 es una condición de PHP que solo se dispara con ciertos contenidos. Si el post nuevo tiene un shortcode o bloque que el post viejo no tenía, y ese shortcode llama a código con un error, solo ese post va a romperse. El resto del sitio funciona bien (lo que confunde mucho). Lo explicamos a fondo en cuando cambies la estructura del sitio.
La trampa: si el problema es de permisos de archivos, puede afectar al front sin afectar al admin porque el admin usa cookies de autenticación que en algunos setups de servidor anulan las restricciones.
WooCommerce y el stock que no actualiza
Para los que corren tiendas: el stock marca 5 unidades en el admin, el cliente compra 5 unidades, y el contador sigue en 5. O baja a 4 cuando debería ir a 0. Esto pasa más de lo que se reconoce públicamente y en 2026 WooCommerce todavía no tiene una solución universal.
¿Por qué pasa? WooCommerce usa un sistema de “stock reservation” que opera con cron de WordPress. Si el cron de WP no corre correctamente (porque el sitio tiene poco tráfico, porque el hosting mata los procesos de PHP antes de que terminen, o porque hay un conflicto con otro plugin que usa el mismo cron), las actualizaciones de stock pueden quedar en cola indefinidamente.
La solución probada es reemplazar el cron de WordPress con un cron real del sistema operativo. En la mayoría de los planes de hosting managed podés pedirle al soporte que configure un cron job de servidor que llame a wp-cron.php cada minuto. Después, agregás define('DISABLE_WP_CRON', true); al wp-config.php para desactivar el cron interno y evitar duplicaciones.
El problema del encoding UTF-8 que aparece de la nada
Publicás un post con tildes y eñes, todo bien. Unos días después, o después de una migración, esas tildes se convierten en caracteres raros: “é” en vez de “é”, “ñ” en vez de “ñ”. El contenido se ve bien en el admin pero roto en el front, o roto en ambos.
Esto es un problema de doble encoding: el texto estaba en UTF-8, se leyó como Latin-1, y se guardó de nuevo en UTF-8. El resultado es UTF-8 con caracteres Latin-1 adentro. El daño ya está en la base de datos. Tema relacionado: problemas relacionados con hosting.
¿Alguien lo verificó de forma independiente en tiempo real? Muchas veces no, porque el proceso de migración pasa rápido y el problema se nota días después cuando alguien reporta que “las letras están raras”.
La detección es simple: abrís phpMyAdmin o usás WP-CLI, revisás una fila de wp_posts con contenido afectado, y buscás “Ô en el campo post_content. Si aparece, tenés el problema. La corrección manual con SQL es posible pero riesgosa sin backup. Hay plugins como “WP-DBManager” que pueden ayudar, pero primero el backup.
Errores comunes al diagnosticar problemas raros
Error 1: Buscar en Google sin desactivar plugins primero. El 80% de los “bugs raros” de WordPress son conflictos entre plugins o entre un plugin y el tema. Antes de buscar soluciones específicas, desactivá todos los plugins y activá un tema por defecto (Twenty Twenty-Four). Si el problema desaparece, lo causaba uno de esos. Activá de a uno hasta encontrar el culpable.
Error 2: Ignorar los logs de PHP. WordPress tiene modo debug desactivado por defecto — y eso está bien para producción — pero cuando hay un problema, activar WP_DEBUG_LOG te da el error exacto en 30 segundos. Sin eso, estás adivinando.
Error 3: Asumir que el problema está en WordPress cuando puede estar en el servidor. Un PHP desactualizado, un límite de memoria insuficiente (memory_limit en 64MB cuando algunos plugins necesitan 256MB), o un timeout de PHP corto pueden manifestarse como comportamientos raros de WordPress. Revisá la pantalla de “Salud del sitio” en el admin — WordPress 6.x tiene diagnósticos bastante completos ahí.
Error 4: Actualizar plugins en producción sin staging. Si tenés un sitio de cierta importancia y no tenés un entorno de staging, la próxima actualización de plugin puede ser la que rompa algo en producción. La mayoría de los proveedores de hosting managed incluyen staging con un clic. Te puede servir nuestra cobertura de aspectos técnicos de SEO.
Preguntas Frecuentes
¿Por qué WordPress rompe el formato de mi contenido al guardar?
El editor de bloques (Gutenberg) serializa el contenido como HTML con comentarios especiales. Si un plugin de seguridad, un filtro de sanitización o un proceso de exportación/importación modifica ese HTML, los bloques quedan inválidos. El primer paso es identificar qué plugin tiene filtros sobre content_save_pre o wp_kses y ajustar su configuración.
¿Cómo sé si el problema es un plugin o mi tema?
Activá el tema Twenty Twenty-Four (viene por defecto en WordPress 6.x) y desactivá todos los plugins. Si el problema desaparece, el culpable estaba en lo que quitaste. Reactivá plugins de a uno, probando después de cada activación. Si el problema persiste con el tema por defecto, puede ser el core de WordPress o un problema de servidor.
¿Qué hago si el sitio tira pantalla blanca y no puedo entrar al admin?
Activá el modo debug agregando estas líneas al wp-config.php directamente desde el servidor (FTP o panel de hosting): define('WP_DEBUG', true); y define('WP_DEBUG_DISPLAY', true);. Si el error es de un plugin, podés renombrarlo desde el servidor (sin FTP, desde el explorador de archivos del hosting) y WordPress lo desactiva automáticamente al no encontrarlo.
¿Por qué los cambios no aparecen aunque limpié la caché?
Hay múltiples capas de caché: el plugin de caché de WordPress, la caché a nivel servidor (OPcache de PHP, Nginx FastCGI cache), la caché del CDN si usás uno, y la caché del navegador. Si limpiás el plugin pero no el servidor, la versión vieja puede persistir. El proceso correcto es limpiar en orden: plugin, servidor, CDN, y forzar recarga en el navegador con Ctrl+Shift+R.
¿Cuánta memoria PHP necesita WordPress?
WordPress base funciona con 64MB, pero con plugins de constructores de páginas, WooCommerce o SEO, necesitás mínimo 256MB. Podés ver el límite actual en Herramientas → Salud del sitio → Info → Servidor. Para cambiarlo, agregás define('WP_MEMORY_LIMIT', '256M'); al wp-config.php, aunque el límite real lo pone el servidor, no WordPress.
Conclusión
Los problemas raros de WordPress casi nunca son raros de verdad. Son conflictos de caché, plugins que se pisan, PHP desactualizado, o permisos mal configurados — pero presentados de una manera que hace difícil identificar la causa a primera vista. El diagnóstico sistemático (logs, desactivación de plugins, tema por defecto) resuelve el 90% de los casos en menos tiempo del que lleva buscar una solución específica en Stack Overflow.
Si tu sitio está en un hosting que no te da acceso a los logs de PHP, dificultad para cambiar permisos de archivos o límites de memoria inflexibles, esos problemas van a seguir apareciendo. Elegir bien el hosting no es un detalle menor en la ecuación.
