Un fallo de una sola página suele depender de su contenido, plantilla, bloque, shortcode, recurso condicional o hook de esa ruta. Desactivar todos los plugins demuestra un conflicto amplio, pero elimina el contexto que explica por qué únicamente falla allí.
Conserva contenido y pruebas de petición y compáralos con una página que funcione.
Define el síntoma específico
Anota URL, ID, plantilla, estado del usuario, dispositivo y si es error PHP, salida equivocada, fallo JavaScript o problema de guardado.
Compara página fallida y correcta:
plantilla, bloques y shortcodes
CSS y JavaScript cargados
peticiones HTTP, REST y AJAX
clases del body
errores PHP y de consola
estado de cachéUsa staging privado para contenido no público.
Inspecciona el primer error
Relaciona la hora de carga con PHP, Consola y Red. Un error fatal nombra el componente de servidor; una excepción del navegador señala un script, pero puede derivar de una respuesta inválida.
Lee el primer error cronológico, no la cascada mayor. Oculta nonces, cookies y contenido personal.
No muestres errores PHP públicamente.
Compara contenido y plantilla
Duplica la página en staging y elimina la mitad de bloques o shortcodes. Continúa por mitades hasta encontrar el contenido mínimo que reproduce.
Revisa bloques reutilizables, patrones, campos y condiciones de plantilla. Un shortcode puede llamar a una integración solo en esa página.
No edites destructivamente la única copia; conserva revisiones o exportación.
Examina recursos condicionales
Los plugins cargan scripts solo cuando existe un bloque o shortcode. Compara handles y versiones con una página correcta.
La optimización puede combinar recursos en otro orden. Desactiva minificación o retraso en staging y regenera.
No excluyas permanentemente todos los scripts; encuentra el handle o dependencia incompatible.
Compara la consulta de WordPress
Una página puede alterar la consulta principal mediante taxonomía, paginación, idioma o campos. Revisa pre_get_posts, the_content y callbacks de plantilla.
Un callback que presupone un objeto de entrada puede fallar en archivos o páginas especiales. Añade comprobaciones de contexto en código propio; no retires filtros globalmente.
Separa CSS del conflicto funcional
Si los botones funcionan pero no se ven, revisa estilos calculados, capas y reglas responsive. Los plugins pueden reutilizar clases genéricas como .modal, .active o .button.
Limita los selectores propios al contenedor del componente. Prueba foco y overlays: una corrección visual no debe dejar una capa invisible capturando clics.
Aísla parejas de plugins
Usa una copia o modo de diagnóstico que cambie plugins solo para tu sesión. Mantén activo el sospechoso y desactiva candidatos uno a uno.
Si A funciona sin B, prueba B sin A y ambos con un tema predeterminado. Anota combinación mínima y versiones.
No hagas pruebas aleatorias en una web comercial en vivo.
Revisa hooks y namespaces
Los conflictos pueden ser nombres duplicados, filtros competidores o salida en otra prioridad. PHP puede mostrar «Cannot redeclare», mientras un conflicto visual exige rastrear callbacks.
has_filter( 'the_content' );Usa herramientas de depuración en staging. El código debe usar namespaces o prefijos y retirar solo sus callbacks, no todos los filtros.
Construye la reparación mínima
Actualiza componentes incompatibles, corrige código propio, ajusta una prioridad compatible o carga recursos solo donde proceda. Prefiere APIs del proveedor.
Si una exclusión temporal desactiva un plugin en la página, documenta qué función se pierde y conserva seguridad y privacidad.
No edites archivos del proveedor.
Verifica rutas vecinas
Prueba la página como anónimo, cliente o editor y en móvil; comprueba previsualización, REST o AJAX, caché caliente y plantillas relacionadas.
Vigila errores PHP y JavaScript después del despliegue. El mantenimiento recurrente debería conservar una página de regresión con bloques importantes; los conflictos específicos se detectan con pruebas de contenido, no con uptime de portada.