HTTP 500 indica que el servidor no pudo completar la petición y decidió no mostrar el error subyacente. Después de actualizar, las causas habituales son un error fatal de PHP, una extracción incompleta, permisos incorrectos, una regla de reescritura dañada o código incompatible.
La coincidencia con la actualización es una pista, no una prueba de que el nuevo paquete sea defectuoso. Conserva los registros antes de deshacer varios cambios a la vez.
Determina qué peticiones devuelven 500
Prueba la portada, un recurso estático, wp-login.php, la administración y la página que falló originalmente. Anota hora, host, estado y si la respuesta procede de un proxy o del servidor de origen.
Compara:
estado de las peticiones HTML/PHP
estado de CSS e imágenes
administración frente a web pública
usuario conectado frente a anónimo
respuesta del origen frente a la CDNNo repitas actualizaciones ni acciones sobre la base de datos durante el diagnóstico.
Consulta los registros del servidor y PHP
Relaciona la hora de la petición con los registros de Apache o Nginx, PHP-FPM y WordPress. Un 500 generado por el proxy puede dejar pruebas diferentes de un fallo de la aplicación PHP.
Guarda el primer error fatal y su pila de llamadas. Los avisos posteriores pueden ser simples consecuencias.
Protege los registros: pueden revelar rutas internas, datos de consultas o credenciales mostradas accidentalmente por una extensión.
Busca una actualización incompleta
Comprueba si WordPress dejó el archivo .maintenance, si el directorio del plugin o tema contiene archivos parciales y si se alcanzó el límite de disco o de inodos durante la extracción.
Compara la versión instalada con el paquete y con los checksums oficiales cuando existan. Reinstala exactamente la versión fiable, sin copiar archivos sueltos desde otra web.
Al reinstalar el núcleo conserva wp-content, la configuración y las subidas.
Revisa permisos y propietario
Una actualización ejecutada con otro usuario del sistema puede impedir que PHP lea archivos o escriba en los directorios necesarios. Compara propietario y grupo con archivos cercanos que funcionen.
Los permisos adecuados dependen del alojamiento y del controlador PHP. Sigue la documentación de cPanel, Plesk o el proveedor. No apliques 777 recursivamente para silenciar un acceso denegado: crearías un problema de seguridad.
Antes de cambiar permisos de forma amplia, localiza la línea concreta de «permission denied».
Prueba la configuración de reescritura
Una actualización o un plugin de seguridad puede modificar .htaccess o las directivas del servidor. Haz una copia y renombra únicamente el archivo sospechoso; después prueba una entrada PHP directa.
En Apache, cuando recuperes el acceso, regenera las reglas estándar desde Ajustes > Enlaces permanentes. En Nginx la configuración está fuera de WordPress y debe corregirse en el servidor o mediante el proveedor.
No pegues directivas de Apache en Nginx ni a la inversa.
Aísla el componente actualizado
Si el registro señala un plugin, renombra su directorio. Si señala el tema, cámbialo solo después de confirmar que hay un tema predeterminado instalado.
Reproduce el caso en pruebas con la versión anterior y la nueva. Lee los cambios publicados y los requisitos de PHP y WordPress.
Evita desactivar todos los plugins de una web comercial salvo que el 500 no proporcione ninguna prueba útil y tengas un orden documentado para reactivarlos.
Revierte sin perder datos
Revierte los archivos del componente responsable desde un paquete fiable o una copia. No restaures toda la base de datos solo para revertir código: podrías perder entradas, ajustes o pedidos nuevos.
Si la actualización migró el esquema de datos, consulta las instrucciones del fabricante antes de bajar de versión. Algunos esquemas no son compatibles hacia atrás.
Documenta el riesgo de seguridad de mantener una versión anterior y prepara una solución actualizada que ya hayas probado.
Verifica y vigila
Prueba la parte pública y administrativa, el guardado en el editor, las tareas programadas y la función original. Limpia OPcache y la caché de página solo cuando corresponda y vuelve a probar con la caché ya calentada.
Comprueba las cabeceras de CDN y navegador para descartar que se siga sirviendo un 500 almacenado aunque el origen ya funcione. Prueba tanto con caché como sin ella.
Vigila la tasa de errores 500 y los errores fatales de PHP al reabrir la web. El mantenimiento recurrente debería probar las actualizaciones de riesgo, comprobar disco e inodos y conservar paquetes de reversión para que la próxima actualización no se convierta en otra urgencia.