Corrección de errores web

Corregir la causa, no el síntoma

Un formulario de contacto deja de enviar. La solución rápida es instalar otro plugin de formularios y el formulario vuelve a funcionar un tiempo. La causa real, casi siempre, es que el sitio envía el correo a través del servidor web en lugar de un servicio de correo adecuado, y los servidores receptores han empezado a rechazarlo. Cambie el plugin y el problema vuelve en un mes, ahora con dos plugins de formularios instalados.

Buscamos primero esa causa subyacente. Los registros de errores del servidor, la consola del navegador y la lista de actualizaciones recientes suelen señalarla directamente. Muchos errores web resultan tener las mismas pocas raíces: una actualización que cambió el comportamiento de un plugin, una capa de caché que sirve una versión antigua, un tema que se editó directamente y luego se sobrescribió, o un límite de hosting que se ha alcanzado.

Por qué corregimos primero en una copia

Cambiar un sitio en producción para encontrar un error es como un problema pequeño se convierte en una caída. Un ajuste que se toca para probar una teoría puede romper el pago de todos los visitantes mientras dura la prueba. Así que, siempre que el proveedor lo permita, hacemos una copia de staging, reproducimos el error ahí y demostramos la solución antes de tocar el sitio en producción.

Cada trabajo empieza con una copia de seguridad completa y termina con un registro: qué fallaba, qué lo causó, qué cambiamos y dónde. Ese registro es útil mucho después de que terminemos. Cuando el mismo síntoma reaparece tras una actualización, quien lo mire después parte de la respuesta en lugar de empezar de cero.

• Formularios que no envían: normalmente es la entrega de correo, no el formulario en sí
• Diseño roto tras una actualización: normalmente un cambio de versión del tema o del constructor
• Cambios que no aparecen: normalmente caché a nivel de servidor, plugin o CDN
• Pantalla blanca o error 500: normalmente una versión de PHP o un límite de memoria