WORDPRESS网站500、502、503、504错误的4大罪魁祸首

Yo opero variosWordPressEl sitio web llegó a perder más de 800 visitas en un solo día debido a un error 502. Tras tres días de investigación, se descubrió que la causa era una configuración poco visible en el servidor.

Cualquier persona que administre un sitio web de WordPress sabe que lo más frustrante no es la falta de tráfico, sino cuando el sitio web de repente se vuelve inaccesible, con errores ilegibles como 500, 502, 503 y 504 que aparecen en la pantalla.

Pensaste que el servidor se había caído y te apresuraste a discutir con el proveedor de alojamiento, solo para descubrir después de que lo revisaron que el servidor funcionaba perfectamente.

Es posible que pienses que se trata de un conflicto de complementos, así que los desactivas y los vas solucionando uno por uno, dedicando la mayor parte del día a ello, pero el error sigue reapareciendo.

En realidad, no tiene por qué ser tan complicado. Tras caer en innumerables trampas, descubrí que el 80% de los errores 5xx de los sitios web de WordPress se deben a estos tres factores. Cada uno está bien oculto, pero puede arruinar fácilmente tu sitio web.

Ahora, usaré mi propia experiencia práctica para exponer claramente estos escollos, de modo que incluso los principiantes puedan seguir los pasos y solucionar los problemas, y nunca más tendrán que sentirse abrumados por los errores.

Problema n.° 1: WP-CRON no estaba desactivado, lo que esencialmente instalaba un "consumo de energía oculto" en el sitio web.

Mucha gente desconoce que WordPress cuenta con una función integrada de tareas programadas llamada WP-CRON, que está habilitada por defecto.

Sus funciones parecen muy prácticas, como programar la publicación de artículos, realizar copias de seguridad automáticas, comprobar si hay actualizaciones de plugins e incluso enviar recordatorios a los miembros.

¿Pero sabías que esta función aparentemente útil es en realidad la principal culpable de que los servidores se bloqueen y se produzcan errores 5xx?

WP-CRON es diferente del Cron nativo del servidor. No se ejecuta de forma proactiva, sino que se activa con las visitas de los usuarios. Cada vez que un usuario visita tu sitio web, ejecuta de forma encubierta el archivo /wp-cron.php para comprobar si hay tareas programadas pendientes.

Esto significa que cada visitante a tu sitio web supone una "carga adicional", y cuantos más visitantes tengas, más pesada será esa carga.

Antes tenía un sitio web que recibía más de mil visitantes al día. Cuando WP-CRON no estaba desactivado, el uso de la CPU del servidor solía dispararse a más del 80%, y se producían al menos dos errores 503 al día, redirigiendo a los visitantes a una página de error en cuanto hacían clic en ella.

Lo peor es que, aunque no configures ninguna tarea programada, WP-CRON se ejecutará automáticamente, solicitando repetidamente recursos del servidor. Con el tiempo, el servidor no podrá soportar la carga y mostrará un error.

La documentación de GitHub indica claramente: "Código de respuesta HTTP inesperado: 500 o superior. Esto significa que se ha producido un error en el servidor que impide la ejecución del generador de tareas cron". Esto significa que, cuando WP-CRON no funciona correctamente, provoca un error del servidor de tipo 500 o superior.

La solución correcta consiste en desactivar WP-CRON por defecto y utilizar las tareas programadas nativas del servidor. Esto garantizará que las tareas programadas se ejecuten con normalidad, a la vez que se reduce la carga del servidor.

Si su servidor admite el comando curl, puede agregar directamente una tarea programada como esta (modifíquela según el dominio de su sitio web):

*/15 * * * * curl https://www. 你的域名/wp-cron.php?doing_wp_cron > /dev/null 2>&1

Este comando ejecuta una tarea WP-CRON cada 15 minutos, adecuada para la mayoría de los sitios web pequeños y medianos; si su sitio web tiene tareas programadas frecuentes, también puede usar esto:

*/5 * * * * curl https://www. 你的域名/wp-cron.php?doing_wp_cron > /dev/null 2>&1

Tras desactivar WP-CRON y configurar tareas programadas en el servidor, el uso de la CPU del servidor se redujo a menos del 30%, y no se registraron errores 503 durante todo un mes. La tasa de retención de visitantes también aumentó un 18%.

Segundo culpable: Las tareas programadas CRON repetidas y los archivos residuales después de la desinstalación del complemento básicamente "dejan basura" en el sitio web.

Resolver el problema de WP-CRON no significa que puedas estar tranquilo; existe un inconveniente oculto que muchos propietarios de sitios web pasan por alto.

Esto significa que las tareas programadas de CRON se ejecutan repetidamente, o que algunas tareas programadas residuales siguen ejecutándose en secreto después de desinstalar el complemento.

¿Te ha pasado alguna vez que desinstalaste un plugin de copia de seguridad, pero descubriste que el servidor sigue realizando copias de seguridad automáticamente todos los días, o incluso muestra un mensaje de error de copia de seguridad, lo que finalmente provoca un error 500?

Esto se debe a las tareas programadas residuales del complemento.

Por ejemplo, si un plugin genera una tarea programada diaria, WordPress seguirá ejecutándola incluso después de desinstalar el plugin. Estas tareas programadas son inútiles. Estas tareas residuales sin sentido consumirán continuamente recursos del servidor y, con el tiempo, provocarán errores.

Peor aún, algunos complementos generan automáticamente múltiples tareas programadas repetitivas. Por ejemplo, una tarea de "verificación diaria de actualizaciones" podría crearse cinco veces, y cada una se ejecutaría según un cronograma, lo que significa que el servidor tendría que procesar cinco tareas idénticas simultáneamente.

Ya instalé uno antes.SEOTras desinstalar el plugin, no lo noté, y medio mes después, el sitio web empezó a sufrir frecuentes errores de tiempo de espera 504. Solo después de revisar los registros del servidor descubrí que el plugin había dejado tres tareas programadas diarias, cada una con un tiempo de ejecución de hasta 12 segundos. La ejecución simultánea de las tres tareas provocaba directamente el tiempo de espera agotado del servidor.

Aún más aterrador es que estas tareas residuales, repetitivas y cronometradas...back-end de WordPressEs invisible; no tienes ni idea de que está funcionando en secreto.

Sin embargo, existe una solución: el plugin WP-Crontrol lo gestiona a la perfección. Se trata de la herramienta oficial de gestión de tareas Cron recomendada por WordPress, que permite ver, editar y eliminar todas las tareas programadas directamente desde el panel de administración.

Según la descripción del plugin de WordPress, WP-Crontrol permite "ver todos los eventos cron programados, editarlos, eliminarlos, pausarlos, reanudarlos y ejecutarlos inmediatamente". En otras palabras, permite ver todas las tareas programadas y eliminar las duplicadas o no válidas. Es muy fácil de usar y no requiere escribir ni una sola línea de código.

Tras usar este complemento para solucionar el problema, eliminé 8 tareas duplicadas y 5 tareas residuales del complemento, y la velocidad de respuesta del sitio web mejoró directamente en un 40 %. El error 504 no volvió a aparecer.

Una advertencia: al eliminar tareas, asegúrese de revisarlas cuidadosamente y evite eliminar accidentalmente tareas programadas esenciales de WordPress, como "wp_version_check" (verificación de versión). La eliminación accidental puede impedir que el sitio web se actualice correctamente.

Si bien el plugin WP-Crontrol puede eliminar manualmente las tareas duplicadas o no válidas, requiere intervención manual, lo cual no es lo ideal...

Sin embargo, podemos automatizar este proceso usando código de WordPress. Consulta el tutorial a continuación para obtener más detalles. ▼

🔗Consejos para acelerar tu sitio web de WordPress: Elimina automáticamente las tareas programadas CRON no válidas.

Culpable n.º 3: Bases de datos redundantes en WordPress

En WordPress, aparece lo siguiente Error 500 Una de las razones es la redundancia de la base de datos, especialmente las tablas de datos de gran capacidad generadas por ciertos complementos.

Al usar el plugin de optimización de WP, descubrí que algunas tablas de datos tenían un tamaño anormalmente grande, entre las cuales... Tabla de configuración de Wordfence (wfconfig) Especialmente prominente.

Análisis del problema

• wfconfig tiene una grave redundancia en la tabla de datos.Ya se había limpiado una vez, pero reapareció muy rápidamente.
• Problemas con el motor de almacenamiento predeterminadoLa tabla de configuración de Wordfence utiliza el motor InnoDB predeterminado, que acumulará cientos de MB de datos redundantes con el tiempo.
• Impacto en el rendimientoLas tablas de datos pueden alcanzar fácilmente cientos de MB de tamaño, lo que provoca una disminución en la velocidad de carga del sitio web e incluso errores 500.

Solución

Esto se debe a que las tablas de datos configuradas por Wordfence utilizan el motor Inno predeterminado. Con el tiempo, esto acumulará rápidamente cientos de megabytes de datos redundantes, lo que afectará la velocidad de carga del sitio web.

hestiacpPara obtener instrucciones sobre cómo cambiar el motor de almacenamiento predeterminado de MariaDB a MyISAM, consulte el siguiente tutorial:

¿Cómo cambiar el motor de almacenamiento predeterminado de MariaDB a MyISAM en HestiaCP? ¡Una solución sencilla en un solo paso!

Cuarto culpable: Los errores que se producen tras las actualizaciones de plugins o temas son como realizar una "cirugía poco convencional" en el sitio web.

Muchos propietarios de sitios web tienen la costumbre de hacer clic inmediatamente en "actualizar" cuando ven avisos de actualización para complementos o temas, creyendo que las actualizaciones solucionarán las vulnerabilidades y mejorarán el rendimiento.

Pero la realidad es justo la contraria; muchos errores 5xx se deben a la actualización de plugins o temas.

Ya me había encontrado con este problema antes. El mes pasado, actualicé mi sitio web con un popular plugin de creación de páginas. Tras hacer clic en actualizar, la página quedó en blanco y, al actualizarla, apareció un error 500 de servidor interno, lo que imposibilitó el acceso al panel de administración.

Posteriormente descubrí que la nueva versión del plugin era incompatible con la versión de PHP de mi sitio web. Tras actualizar el plugin, el código no se ejecutaba correctamente, lo que provocaba directamente un error en el servidor.

Los errores que se producen tras las actualizaciones de plugins o temas son una causa común de los errores 500 de WordPress, especialmente cuando la nueva versión del plugin tiene vulnerabilidades en el código o entra en conflicto con otros plugins o temas del sitio web.

Otro escenario posible es que, tras actualizar el tema, el código personalizado anterior se sobrescriba, lo que provocará que el diseño del sitio web se desorganice y que las funciones fallen, lo que a su vez dará lugar a errores 502 y 503.

tener un hacerComercio electrónicoPara algunos usuarios, tras actualizar el plugin WooCommerce, sus sitios web experimentaron errores 502, lo que imposibilitó la realización de pedidos. Esto resultó en una pérdida de más de 2000 en ventas en tan solo 3 horas, y se tardó toda una tarde en resolver el problema.

De hecho, la solución más directa y eficaz a esta situación es volver a una versión anterior que funcionara correctamente.

Mucha gente no sabe cómo revertir los cambios, pero no es necesario descargar ni subir archivos manualmente; el plugin WP Rollback lo hace muy fácil.

Según la descripción de WordPress, el plugin WP Rollback permite "revertir de forma rápida y sencilla cualquier tema o plugin de wordpress.org a cualquier versión anterior (o posterior) sin complicaciones manuales". En otras palabras, puede restaurar plugins o temas a cualquier versión anterior con un solo clic, sin operaciones complicadas, lo que facilita su uso para principiantes.

Tras el fallo de la última actualización de mi plugin, utilicé WP Rollback para volver a la versión anterior con un solo clic. El sitio web volvió a la normalidad en tan solo 30 segundos y no se perdió ningún dato.

Un consejo: antes de actualizar plugins o temas, siempre haz una copia de seguridad de tu sitio web. Lo mejor es probarlo primero en un entorno de prueba para asegurarte de que no haya problemas antes de actualizarlo en el sitio web oficial y así evitar errores.

Conclusión: Domina estos 3 puntos para despedirte por completo de los errores 5xx de tu sitio web de WordPress.

Al administrar un sitio web de WordPress, los errores 500, 502, 503 y 504 son como "obstáculos", aparentemente problemáticos, pero la causa principal es bastante clara: no se trata de que el servidor esté defectuoso, ni de que haya un problema grave con el programa del sitio web, sino más bien de que hemos pasado por alto tres detalles: WP-CRON, tareas programadas residuales y actualizaciones de plugins/temas.

Como propietario de un sitio web de WordPress, desde sentirme abrumado por los errores al principio hasta poder solucionar rápidamente todos los errores 5xx, mi mayor conclusión es que el funcionamiento estable de un sitio web no se basa en "cerrar la puerta del establo después de que el caballo se haya escapado", sino más bien en que "más vale prevenir que curar".

Muchos propietarios de sitios web piensan que estos pequeños detalles no son importantes y solo se arrepienten de no haberlos revisado con antelación cuando el sitio web falla, pierde tráfico y sufre pérdidas de ingresos.

Es importante comprender que, para un sitio web, la "estabilidad" es la principal ventaja competitiva. Un solo error 5xx puede provocar la pérdida del 10 % de los visitantes, y varios errores pueden incluso causar una caída en el posicionamiento en buscadores, haciendo que todos los esfuerzos de SEO anteriores resulten en vano.

Como dice el refrán: "Un dique de mil millas puede ser derribado por un agujero de hormiga". Los errores 5xx de los sitios web de WordPress nunca aparecen de repente, sino que son el resultado de la acumulación de pequeños problemas: WP-CRON no desactivado, tareas programadas residuales y actualizaciones apresuradas. Estos "agujeros de hormiga", aparentemente insignificantes, acabarán por destruir todo el "dique" del sitio web.

Unas operaciones verdaderamente eficientes implican atajar los problemas de raíz.

1. Desactive el WP-CRON predeterminado y sustitúyalo por una tarea programada basada en el servidor;
2. Utilice WP-Crontrol con regularidad para limpiar las tareas programadas repetitivas y residuales;
3. Asegúrese de hacer una copia de seguridad de sus datos antes de actualizar los complementos o los temas, y revierta los cambios inmediatamente si se producen errores.

Estas tres operaciones no requieren tecnología compleja ni desarrolladores costosos, e incluso los principiantes pueden dominarlas fácilmente; además, pueden evitar que su sitio web sufra errores 5xx y mantener un funcionamiento estable.

Cada carga estable de tu sitio web y cada estancia de un visitante es un activo valioso que acumulas con el tiempo.

A partir de ahora, identifique a estos tres culpables y realice un mantenimiento diario para garantizar que su sitio web de WordPress no solo soporte su arduo trabajo, sino que también aumente constantemente el tráfico y los ingresos.

Si actualmente experimentas errores 5xx, intenta seguir los pasos de este artículo para solucionarlos. Creo que pronto podrás resolver estos problemas, lograr que tu sitio web funcione de forma estable y alcanzar un crecimiento a largo plazo.