Error 500 en WordPress: 11 soluciones efectivas para recuperar tu página web en 2026

El Error 500 en WordPress significa que el servidor encontró una condición inesperada y no pudo completar la solicitud. El código confirma que existe un fallo interno, pero no revela por sí solo qué plugin, archivo, proceso o configuración lo produjo.

Puede aparecer después de actualizar WordPress, instalar un complemento, modificar PHP, editar una página con Elementor, procesar una compra en WooCommerce o importar información. También puede afectar únicamente wp-admin, una URL, un formulario, la API REST o una acción AJAX.

La solución correcta no consiste en probar cambios al azar. Primero debemos identificar dónde ocurre, revisar los registros y aplicar una modificación a la vez. El estándar HTTP define el código 500 precisamente como una condición inesperada que impide al servidor atender la petición.

Cómo se presenta el error interno del servidor

El mensaje puede cambiar según el hosting, navegador, servidor o CDN:

• 500 Internal Server Error.
• HTTP Error 500.
• Internal Server Error.
• The server encountered an internal error.
• Pantalla blanca.
• Error crítico de WordPress.
• Respuesta 500 en una petición AJAX.
• Fallo 500 en la consola o pestaña Network.
• Página en blanco después de guardar.

Una respuesta 500 no debe confundirse con otros códigos de servidor:

Código	Significado general	Diferencia principal
500	Error interno no especificado	El servidor encontró una condición inesperada
502	Respuesta incorrecta de un servidor intermedio	Fallo entre proxy, gateway o servidor superior
503	Servicio temporalmente no disponible	Mantenimiento, saturación o falta de capacidad
504	Tiempo de espera agotado	El servidor superior tardó demasiado

Todos pertenecen al grupo de errores 5xx, pero sus diagnósticos y soluciones pueden ser distintos.

Identifica dónde ocurre el fallo

Síntoma	Posible origen	Primera comprobación
Toda la página muestra Error 500 en WordPress	Servidor, PHP, reglas o archivos principales	Logs y cambios recientes
Solo falla wp-admin	Plugin, tema o memoria administrativa	Plugins y registros
Solo falla una página	Widget, shortcode, consulta o plantilla	Duplicar y revisar contenido
Aparece después de actualizar	Incompatibilidad o actualización incompleta	Versiones y logs
Falla al subir archivos	Límites PHP, permisos o firewall	Configuración y almacenamiento
Falla en WooCommerce	Pasarela, plugin, consulta o recursos	Logs y staging
Falla al guardar Elementor	Memoria, AJAX, seguridad o addons	Network y registros
Es intermitente	PHP-FPM, workers, CPU o hosting	Monitorización
Solo afecta la API REST	Seguridad, plugin o regla del servidor	Salud del sitio
Solo afecta Googlebot	Firewall, CDN o disponibilidad	Logs y Search Console

Definir el alcance reduce el número de hipótesis. Si solamente falla una acción, no tiene sentido comenzar reinstalando todo WordPress.

Qué revisar antes de tocar archivos

Antes de modificar plugins, temas, .htaccess, wp-config.php, permisos, PHP, base de datos o configuración del servidor, crea una copia de seguridad completa. Si la página está publicada, realiza las pruebas en staging siempre que sea posible.

El respaldo debe incluir archivos y base de datos, pero también debe poder restaurarse. Una copia que nunca se ha verificado es más una esperanza que un plan de recuperación.

Checklist inicial:

1. Confirma la hora aproximada del fallo.
2. Registra las últimas actualizaciones.
3. Comprueba frontend y escritorio.
4. Prueba una ventana de incógnito.
5. Revisa el estado del hosting.
6. Comprueba espacio e inodos.
7. Consulta los correos de recuperación.
8. Abre Herramientas > Salud del sitio.
9. Guarda capturas.
10. Crea un respaldo.
11. Prepara staging.
12. Registra cada cambio.

Limpiar caché puede retirar una respuesta almacenada, pero no corrige un error fatal de PHP, falta de memoria o una regla defectuosa del servidor.

Desactivar plugins puede interrumpir formularios, pagos o integraciones. Cambiar el tema puede alterar el diseño. Utiliza SFTP en lugar de FTP cuando el proveedor lo permita.

Cómo encontrar la causa mediante los registros

Los registros son la fuente más útil para saber qué ocurrió exactamente.

Revisa:

• Error log del hosting.
• Registros de Apache o Nginx.
• PHP error log.
• PHP-FPM log.
• Logs del CDN y firewall.
• wp-content/debug.log.
• Correos de recuperación de WordPress.
• Consola y pestaña Network del navegador.

Configuración segura de depuración

Estas constantes se colocan en wp-config.php, antes de la línea final que indica detener la edición:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

No dupliques constantes que ya existen. WP_DEBUG_LOG almacena los mensajes normalmente en wp-content/debug.log, mientras WP_DEBUG_DISPLAY en false evita mostrarlos dentro de la página pública. WordPress recomienda desactivar la depuración al finalizar el diagnóstico.

El registro puede contener rutas, nombres de archivos y otra información sensible. No debe publicarse ni enviarse a personas no autorizadas.

Mensajes frecuentes:

• Allowed memory size exhausted: memoria agotada.
• Uncaught Error: error fatal no controlado.
• Call to undefined function: función inexistente.
• Class not found: dependencia o clase ausente.
• Parse error: error de sintaxis.
• Permission denied: permisos o propiedad.
• Maximum execution time exceeded: proceso demasiado largo.

El archivo y la línea señalados suelen indicar qué componente debe revisarse.

Error 500 en WordPress: 11 causas y soluciones efectivas

1. Un plugin está generando un conflicto

Qué significa: un complemento contiene un error, consume demasiados recursos o no es compatible con WordPress, PHP u otro plugin.

Síntomas: el fallo apareció después de instalar o actualizar un plugin, solamente afecta una función concreta o desaparece al desactivarlo.

Solución con acceso al escritorio:

1. Ve a Plugins > Plugins instalados.
2. Identifica los cambios recientes.
3. Desactiva el plugin sospechoso.
4. Prueba nuevamente.
5. Si continúa, desactiva los demás en staging.
6. Reactívalos uno por uno.
7. Prueba después de cada activación.

Sin acceso a WordPress, entra mediante SFTP o el administrador de archivos, abre wp-content/plugins y renombra la carpeta sospechosa. Si no sabes cuál es, puedes renombrar temporalmente la carpeta plugins.

Los mu-plugins deben revisarse por separado, porque se cargan automáticamente y no aparecen como plugins convencionales. WordPress recomienda probar los complementos individualmente para aislar incompatibilidades.

Dificultad: básica o intermedia.
Riesgo: medio.
Evita: borrar la carpeta antes de confirmar la causa.
Resultado esperado: el sitio carga al desactivar el componente conflictivo.

2. El tema o tema hijo contiene un error

El origen puede estar en functions.php, una plantilla personalizada, un hook, código heredado o una incompatibilidad con la versión actual de PHP.

Procedimiento:

1. Crea un respaldo.
2. Realiza la prueba en staging.
3. Activa temporalmente un tema oficial.
4. Comprueba frontend y escritorio.
5. Revisa el log.
6. Restaura el tema original.
7. Corrige el archivo identificado.

Sin acceso al panel, puedes renombrar la carpeta del tema activo dentro de wp-content/themes, siempre que exista otro tema válido instalado.

Cambiar el tema puede modificar menús, widgets, encabezados, pies de página y funciones particulares. Los temas de WordPress pueden incluir archivos PHP y controlar tanto presentación como comportamientos del sitio.

Dificultad: intermedia.
Riesgo: medio.
Evita: hacer la prueba directamente durante horario comercial.
Resultado esperado: el fallo desaparece con un tema alternativo.

3. .htaccess está dañado o tiene reglas incorrectas

Esta solución corresponde principalmente a Apache. Nginx no utiliza .htaccess de forma nativa y requiere revisar la configuración del servidor. IIS puede utilizar web.config.

En Apache, el archivo puede dañarse por redirecciones, plugins de seguridad, caché, migraciones o reglas copiadas de otra instalación. WordPress utiliza .htaccess para administrar configuraciones por directorio y enlaces permanentes.

Procedimiento en Apache:

1. Entra mediante SFTP.
2. Activa la visualización de archivos ocultos.
3. Descarga una copia de .htaccess.
4. Renómbralo como .htaccess_old.
5. Prueba el sitio.
6. Entra a Ajustes > Enlaces permanentes.
7. Guarda nuevamente.
8. Recupera solo las reglas personalizadas necesarias.

En Nginx deben revisarse try_files, el bloque del servidor, PHP-FPM y los registros. La documentación de WordPress advierte que Nginx y Apache no son configuraciones intercambiables.

Dificultad: intermedia.
Riesgo: alto.
Evita: eliminar el archivo sin conservar copia.
Resultado esperado: Apache vuelve a procesar las solicitudes correctamente.

4. WordPress agotó memoria o recursos

El proceso puede superar la memoria PHP, el tiempo de ejecución, la CPU, RAM, cantidad de workers, consultas o límites del hosting.

Esto ocurre con frecuencia durante:

• Importaciones.
• Copias de seguridad.
• Acciones masivas.
• Edición con constructores.
• Procesos de WooCommerce.
• Generación de imágenes.
• Consultas complejas.

Revisa Salud del sitio, panel del hosting, registros, memory_limit, WP_MEMORY_LIMIT, WP_MAX_MEMORY_LIMIT, max_execution_time y disponibilidad de PHP-FPM.

WordPress utiliza WP_MEMORY_LIMIT para solicitar memoria en frontend y WP_MAX_MEMORY_LIMIT para procesos administrativos, pero el servidor puede imponer un límite inferior. Aumentar una constante no obliga al hosting a conceder ese recurso.

Solución:

1. Identifica el mensaje exacto del log.
2. Solicita al hosting los límites reales.
3. Ajusta recursos cuando esté justificado.
4. Repite la operación.
5. Investiga consumos anormales.

Dificultad: intermedia.
Riesgo: medio.
Evita: aumentar memoria indefinidamente para ocultar un plugin defectuoso.
Resultado esperado: el proceso termina sin agotar recursos.

5. La versión de PHP es incompatible

Puede aparecer después de actualizar PHP, cambiar de hosting, restaurar una copia antigua o instalar código obsoleto.

WordPress recomienda actualmente PHP 8.3 o superior, MariaDB 10.11 o MySQL 8.0, además de HTTPS. Aunque puede ejecutarse en versiones heredadas desde PHP 7.4, estas han llegado al final de su vida útil y representan riesgos de compatibilidad y seguridad.

Procedimiento:

1. Crea un respaldo.
2. Revisa los requisitos de plugins y tema.
3. Prueba la versión en staging.
4. Cambia PHP desde el panel del hosting.
5. Reinicia PHP si corresponde.
6. Limpia caché.
7. Prueba formularios, pagos y administración.
8. Revisa los registros.

Volver temporalmente a una versión anterior puede ayudar a recuperar el acceso, pero no debe convertirse en la solución permanente. El componente incompatible debe actualizarse, reemplazarse o corregirse.

Dificultad: intermedia.
Riesgo: alto.
Evita: cambiar PHP sin revisar extensiones y compatibilidad.
Resultado esperado: WordPress y sus componentes funcionan en un entorno compatible.

6. Existe un error fatal en código personalizado

El fallo puede encontrarse en:

• Tema hijo.
• functions.php.
• Plugin personalizado.
• Plugin de snippets.
• mu-plugins.
• Integración API.
• Webhook.
• Código agregado manualmente.

Un punto y coma ausente, una función duplicada, una clase inexistente o una dependencia no cargada pueden detener completamente PHP.

Solución:

1. Consulta debug.log.
2. Identifica archivo y línea.
3. Desactiva el snippet o componente.
4. Restaura la versión anterior.
5. Corrige el código en staging.
6. Prueba con la misma versión de PHP.
7. Documenta el cambio.
8. Publica nuevamente.

No edites código desde el editor interno de WordPress cuando el sitio ya se encuentra inestable. Trabaja con control de versiones o una copia descargable.

Dificultad: avanzada.
Riesgo: alto.
Evita: comentar líneas al azar hasta que la web abra.
Resultado esperado: desaparece el error fatal señalado por el registro.

7. El núcleo está dañado o la actualización quedó incompleta

Una actualización interrumpida, falta de espacio, permisos deficientes, malware o transferencia incompleta pueden dejar archivos principales ausentes.

WordPress permite reinstalar el núcleo desde Escritorio > Actualizaciones. Si no existe acceso, puede realizarse una actualización manual, conservando wp-content y wp-config.php. La documentación oficial recomienda respaldar archivos y base de datos antes del procedimiento.

Procedimiento general:

1. Descarga WordPress desde su sitio oficial.
2. Confirma la versión.
3. Reemplaza wp-admin y wp-includes.
4. Sustituye los archivos principales necesarios.
5. Conserva wp-content.
6. Conserva wp-config.php.
7. Elimina .maintenance si quedó bloqueado.
8. Prueba el sitio.

Reinstalar el núcleo no repara automáticamente plugins, temas ni tablas.

Dificultad: avanzada.
Riesgo: alto.
Evita: reemplazar la carpeta de contenidos.
Resultado esperado: se recuperan archivos oficiales dañados o incompletos.

8. Los permisos o propietarios son incorrectos

El servidor necesita permiso para leer y ejecutar archivos, pero conceder acceso excesivo crea riesgos de seguridad.

Después de una migración o restauración pueden cambiar:

• Propietario.
• Grupo.
• Permisos de carpetas.
• Permisos de archivos.
• Acceso a uploads.
• Acceso a caché.
• Lectura de wp-config.php.

Como orientación frecuente se utilizan 755 para directorios y 644 para archivos, pero la configuración depende del hosting, del usuario que ejecuta PHP y de sistemas como PHP-FPM o suexec. WordPress advierte expresamente sobre los riesgos de utilizar permisos 777.

Solución:

1. Busca Permission denied en los logs.
2. Consulta la configuración recomendada por el hosting.
3. Corrige propietario y grupo.
4. Aplica permisos únicamente a las rutas afectadas.
5. Prueba subida, caché y actualizaciones.

Dificultad: avanzada.
Riesgo: alto.
Evita: aplicar 777 de forma recursiva.
Resultado esperado: PHP puede leer o escribir sin exponer todo el servidor.

9. La base de datos o el almacenamiento están fallando

Aunque los problemas de conexión suelen mostrar otro mensaje, una consulta pesada, tabla dañada, cuota agotada o bloqueo puede terminar en respuesta 500.

Revisa:

• Espacio en disco.
• Inodos.
• Cuota de base de datos.
• Estado de MySQL o MariaDB.
• Credenciales de wp-config.php.
• Tablas de plugins.
• Consultas lentas.
• Bloqueos.
• Logs del hosting.

Procedimiento:

1. Confirma la disponibilidad del servidor.
2. Revisa espacio e inodos.
3. Consulta errores de base de datos.
4. Verifica credenciales.
5. Crea un respaldo.
6. Solicita al hosting revisar MySQL.
7. Repara únicamente con diagnóstico.
8. Optimiza después de identificar el problema.

Una migración también puede generar errores si las rutas, credenciales o datos serializados no fueron actualizados correctamente.

Dificultad: avanzada.
Riesgo: alto.
Evita: ejecutar consultas o reparaciones desconocidas.
Resultado esperado: la aplicación recupera acceso estable a datos y almacenamiento.

10. El servidor, CDN o firewall bloquea la solicitud

El origen puede estar en Apache, Nginx, PHP-FPM, Cloudflare, ModSecurity, caché de objetos, Redis, límites de solicitudes o saturación del hosting.

Suele manifestarse cuando:

• El error es intermitente.
• Solo falla AJAX.
• Un formulario no guarda.
• Una importación se detiene.
• Funciona para una IP, pero no para otra.
• Apareció después de activar seguridad.

Solución:

1. Consulta la hora exacta del error.
2. Revisa logs del servidor y firewall.
3. Purga únicamente las cachés necesarias.
4. Prueba sin optimizaciones en staging.
5. Solicita el identificador de la regla bloqueada.
6. Crea una excepción específica y segura.
7. Revisa workers y PHP-FPM.
8. Restablece la protección.

No desactives permanentemente el firewall. La seguridad debe ajustarse, no desaparecer.

Dificultad: avanzada.
Riesgo: alto.
Evita: culpar al hosting sin comprobar la aplicación o viceversa.
Resultado esperado: la petición deja de ser bloqueada o agotada.

11. La página fue comprometida

Malware, plugins pirateados o accesos no autorizados pueden modificar .htaccess, index.php, plugins, temas, permisos y procesos del servidor.

Señales frecuentes:

• Administradores desconocidos.
• Redirecciones extrañas.
• Archivos con nombres sospechosos.
• Consumo elevado.
• Cambios no autorizados.
• Alertas del hosting.
• Avisos de Google.
• Errores que reaparecen.

Solución:

1. Aísla la web si representa un riesgo.
2. Conserva una copia forense.
3. Cambia credenciales.
4. Revisa usuarios.
5. Actualiza WordPress y componentes.
6. Elimina software no oficial.
7. Limpia archivos y base de datos.
8. Corrige la vulnerabilidad original.
9. Restaura una copia limpia cuando corresponda.
10. Monitoriza después de recuperar.

Mantener WordPress, plugins y temas actualizados forma parte de las recomendaciones básicas de endurecimiento de seguridad.

Dificultad: avanzada.
Riesgo: crítico.
Evita: restaurar una copia sin corregir la vulnerabilidad.
Resultado esperado: recuperar una instalación limpia y cerrar el acceso utilizado.

Orden recomendado para solucionar el problema

Orden	Acción	Dificultad	Riesgo
1	Confirmar alcance y cambios	Básica	Bajo
2	Revisar logs	Intermedia	Bajo
3	Comprobar plugins	Intermedia	Medio
4	Probar tema	Intermedia	Medio
5	Revisar .htaccess o servidor	Intermedia	Alto
6	Revisar memoria y recursos	Intermedia	Medio
7	Verificar PHP	Intermedia	Alto
8	Revisar código personalizado	Avanzada	Alto
9	Reinstalar núcleo	Avanzada	Alto
10	Revisar permisos y base de datos	Avanzada	Alto
11	Analizar servidor y seguridad	Avanzada	Crítico

Los registros deben revisarse desde el comienzo, aunque la solución aparezca en un paso posterior.

Qué hacer si no puedes entrar a wp-admin

1. Crea un respaldo desde el hosting.
2. Accede mediante SFTP.
3. Revisa los logs.
4. Renombra el plugin sospechoso.
5. Renombra temporalmente plugins si es necesario.
6. Comprueba los mu-plugins.
7. Prueba un tema oficial.
8. Revisa .htaccess solo en Apache.
9. Verifica espacio y versión de PHP.
10. Restaura nombres y reactiva uno por uno.

Renombrar una carpeta sirve para desactivar temporalmente, no para eliminar definitivamente.

Cómo afecta al SEO y a las ventas

Un fallo persistente puede detener formularios, pagos, campañas, procesos internos e integraciones.

También impide que Googlebot acceda al contenido. Google reduce temporalmente el rastreo cuando recibe errores 5xx; las URLs indexadas pueden conservarse durante un periodo, pero eventualmente podrían retirarse si el problema continúa. Cuando vuelven las respuestas 2xx, el rastreo se recupera gradualmente.

Un error breve no implica automáticamente una pérdida permanente. El riesgo aumenta cuando la respuesta se repite o se mantiene durante periodos prolongados.

Después de recuperar la página:

1. Confirma el código 200.
2. Prueba las funciones importantes.
3. Revisa Search Console.
4. Monitoriza los logs.
5. Comprueba formularios y compras.
6. Revisa Analytics.

Errores que debes evitar durante la reparación

• Realizar muchos cambios simultáneos.
• Trabajar en producción sin respaldo.
• Borrar plugins antes de diagnosticar.
• Eliminar .htaccess sin copia.
• Aplicar permisos 777.
• Cambiar PHP sin probar compatibilidad.
• Dejar WP_DEBUG activo.
• Mostrar errores a visitantes.
• Publicar debug.log.
• Editar archivos del núcleo.
• Desactivar permanentemente la seguridad.
• Restaurar copias infectadas.
• Reparar tablas sin respaldo.
• Copiar configuraciones de otro servidor.
• Confundir Apache con Nginx.
• Instalar un plugin para cada fallo.
• Utilizar software pirateado.
• Ignorar los registros.

La reparación efectiva es metódica: un cambio, una prueba y un resultado documentado.

Cuándo contactar al hosting

Contacta al proveedor cuando:

• Varias páginas alojadas presentan fallos.
• PHP-FPM no responde.
• No tienes acceso a los registros.
• El disco o los inodos están agotados.
• ModSecurity bloquea solicitudes.
• MySQL no responde.
• Existen problemas de propiedad.
• La cuenta fue suspendida.
• La web funciona localmente, pero no en producción.

Envía:

• URL afectada.
• Hora del fallo.
• Captura.
• Acción realizada.
• Código HTTP.
• IP, cuando sea relevante.
• Extracto del log.
• Versión de PHP.
• Últimos cambios.

No compartas contraseñas por canales inseguros.

Cuándo solicitar soporte profesional

El acompañamiento especializado es recomendable cuando existe una tienda WooCommerce, código personalizado, malware, integraciones empresariales, problemas de base de datos o una migración fallida.

También cuando:

• El sitio genera ventas.
• Los formularios están detenidos.
• No existe una copia confiable.
• Deben modificarse reglas del servidor.
• El fallo reaparece.
• No puede identificarse el componente responsable.
• Es necesario reducir el tiempo de inactividad.

Continuar probando sin control puede incrementar el costo de recuperación.

Una página profesional necesita infraestructura estable

Una página empresarial no depende únicamente de su diseño. También necesita hosting adecuado, PHP vigente, seguridad, copias de respaldo, rendimiento, HTTPS, monitorización y mantenimiento.

En Codwelt desarrollamos diseño de páginas web profesionales administrables con WordPress y Elementor.

Según el plan contratado, las soluciones pueden incluir diseño alineado con la marca, adaptación móvil, hosting avanzado, dominio, SSL, correos corporativos, rendimiento, seguridad, Analytics, Search Console, WhatsApp, blog, optimización SEO apoyada por IA y capacitación.

Una infraestructura profesional no elimina completamente la posibilidad de un fallo, pero facilita su prevención, diagnóstico y recuperación antes de que afecte durante demasiado tiempo a los clientes.

Solicita tu página web con una estructura profesional, segura y preparada para crecer.

Preguntas frecuentes

Conclusión

Las causas principales son:

1. Conflictos de plugins.
2. Errores del tema.
3. .htaccess o reglas del servidor.
4. Memoria y recursos agotados.
5. Incompatibilidad de PHP.
6. Código personalizado.
7. Archivos del núcleo.
8. Permisos.
9. Base de datos o almacenamiento.
10. Servidor, CDN o firewall.
11. Malware.

Cuando aparece un Error 500 en WordPress, la forma correcta de resolverlo es revisar los registros, aislar la causa y aplicar un cambio a la vez.

Evita que los errores técnicos detengan tus oportunidades comerciales. Cotiza tu página WordPress o soporte especializado con Codwelt.

Fuentes

Codwelt

• Codwelt — Diseño de páginas web profesionales
  https://codwelt.com/diseno-de-paginas-web-desarrollo-de-sitios-web/

WordPress

• WordPress — Errores comunes
  https://developer.wordpress.org/advanced-administration/wordpress/common-errors/
• WordPress — Depuración
  https://developer.wordpress.org/advanced-administration/debug/debug-wordpress/
• WordPress — Edición de wp-config.php
  https://developer.wordpress.org/advanced-administration/wordpress/wp-config/
• WordPress — Memoria y optimización PHP
  https://developer.wordpress.org/advanced-administration/performance/php/
• WordPress — Requisitos técnicos
  https://wordpress.org/about/requirements/
• WordPress — Solución de problemas
  https://wordpress.org/documentation/article/faq-troubleshooting/
• WordPress — Administración de plugins
  https://wordpress.org/documentation/article/manage-plugins/
• WordPress — Trabajo con temas
  https://wordpress.org/documentation/article/work-with-themes/
• WordPress — Apache y .htaccess
  https://developer.wordpress.org/advanced-administration/server/web-server/httpd/
• WordPress — Nginx
  https://developer.wordpress.org/advanced-administration/server/web-server/nginx/
• WordPress — Permisos de archivos
  https://developer.wordpress.org/advanced-administration/server/file-permissions/
• WordPress — Seguridad y endurecimiento
  https://developer.wordpress.org/advanced-administration/security/hardening/
• WordPress — Actualizaciones
  https://wordpress.org/documentation/article/updating-wordpress/
• WordPress — Migración
  https://developer.wordpress.org/advanced-administration/upgrade/migrating/
• WordPress — Salud del sitio
  https://wordpress.org/documentation/article/site-health-screen/

Google Search Central

• Google — Códigos HTTP y errores del servidor
  https://developers.google.com/search/docs/crawling-indexing/http-network-errors
• Google — Solución de errores de rastreo
  https://developers.google.com/search/docs/crawling-indexing/troubleshoot-crawling-errors
• Google — Contenido útil para las personas
  https://developers.google.com/search/docs/fundamentals/creating-helpful-content
• Google — SEO para imágenes
  https://developers.google.com/search/docs/appearance/google-images

Estándares HTTP

• RFC 9110 — 500 Internal Server Error
  https://www.rfc-editor.org/rfc/rfc9110.html#name-500-internal-server-error