Error 5xx en Search Console. Diagnóstico y solución.
¿Google muestra «Error del servidor (5xx)» en la indexación de tus páginas? Aprende a encontrar la causa real —hosting, WordPress, PHP, Cloudflare o firewall— y a comprobar que Googlebot puede volver a rastrear tu web.
¿Qué significa el error 5xx de Search Console?
El aviso «Error del servidor (5xx)» indica que Google intentó solicitar una URL y recibió una respuesta de error del servidor. El problema puede encontrarse en el alojamiento, la aplicación, la base de datos, el proxy, la CDN o la comunicación entre ellos. No significa que Google haya penalizado el contenido. Significa que no pudo obtenerlo correctamente en ese intento. Definición oficial de Google ↗.
Si antes estaba indexada, una URL que falla puntualmente puede permanecer en el índice. Pero si los errores se repiten, Google reduce el rastreo y puede acabar retirando páginas. Que la web funcione ahora en tu navegador no demuestra que Googlebot pudiera acceder cuando ocurrió el error.
También existen códigos 520–526 en determinadas infraestructuras con Cloudflare. Se distinguen más adelante.
No todos los errores 5xx tienen la misma causa.
Search Console puede agrupar distintos fallos dentro de «Error del servidor (5xx)». El código HTTP exacto, cuando está disponible, ayuda a determinar dónde investigar. Ninguna fila constituye un diagnóstico definitivo sin registros del servidor.
| Código | Significado | Posibles causas | Qué revisar primero |
|---|---|---|---|
| 500 Internal Server Error | El servidor no puede completar la solicitud. | Error fatal de PHP, plugin, configuración, permisos, límites de memoria o aplicación. | Registro de errores, cambios recientes, recursos, WordPress. |
| 502 Bad Gateway | Un intermediario recibe una respuesta inválida del servicio de origen. | PHP-FPM caído, upstream defectuoso, proxy mal configurado o desconexiones. | Nginx/Apache, PHP-FPM, proxy inverso y logs de upstream. |
| 503 Service Unavailable | Servicio no disponible temporalmente. | Mantenimiento, saturación, límites del hosting o capacidad insuficiente. | Uso de CPU/RAM, procesos, mantenimiento y cabecera Retry-After. |
| 504 Gateway Timeout | Un intermediario espera demasiado al origen. | Consultas lentas, bloqueos, procesos prolongados o timeouts de red. | Tiempos de respuesta, base de datos, aplicación y timeouts del proxy. |
| 429 Too Many Requests | El servidor aplica una limitación de solicitudes. | Rate limiting, WAF o protección antibots demasiado agresiva. | Reglas de limitación, tráfico real, identificación de Googlebot. |
| 520–526 Cloudflare | Errores de comunicación, origen o TLS en el entorno Cloudflare. | Conexiones rechazadas, timeouts, respuestas no válidas o certificados. | Ray ID, códigos de origen/edge, TLS, firewall, logs de Cloudflare. |
Aunque 429 pertenece a la familia HTTP 4xx, Google lo interpreta como señal de sobrecarga y lo trata de forma similar a un error de servidor para el rastreo. Referencia: códigos HTTP y rastreadores de Google ↗.
El recurso debería funcionar, pero falla al servirlo.
Si la URL debe estar disponible, investiga por qué la infraestructura responde mal. Una redirección indiscriminada no arregla el origen del fallo.
El recurso no existe, o se ha eliminado.
Un 404 o 410 válido puede ser la respuesta correcta para contenido que ya no existe. No debe confundirse con un 5xx ni sustituirse por un 200 falso.
Dónde ver el 5xx dentro de Search Console.
Conviene cruzar dos informes: Indexación de páginas muestra URLs que Google no ha indexado por problemas detectados; Estadísticas de rastreo ayuda a ver si los errores son puntuales, recurrentes o afectan a la disponibilidad del host.
Fig. 01 · Representación editorial de la ubicación del informe; la interfaz de Google puede cambiar. No es una captura auténtica.
Abre el motivo de exclusión.
En Indexación → Páginas, busca «Error del servidor (5xx)» y anota las URLs de ejemplo. No presupongas que la lista de ejemplos incluye todas las solicitudes fallidas.
Inspecciona una URL concreta.
Introduce la URL completa en Inspección de URLs, mira «Obtención de página», último rastreo y resultado de Probar URL publicada. El estado guardado y la prueba en vivo pueden ser diferentes.
Consulta Estadísticas de rastreo.
En Ajustes → Estadísticas de rastreo, revisa respuestas del servidor, tiempo medio de respuesta y estado del host. Este informe se ofrece en propiedades de dominio o prefijo raíz compatibles.
Compara las fechas con tu servidor.
Contrasta el momento de las incidencias con actualizaciones, picos de carga, incidencias de la CDN, reglas de seguridad y registros. El informe no reemplaza el log técnico.
Una diferencia importante: «Probar URL publicada» comprueba el estado actual; el informe de indexación puede seguir mostrando un rastreo anterior. Una prueba que funciona ahora no invalida un 5xx histórico. Ayuda oficial de inspección de URLs ↗.
Cómo solucionar un error 5xx paso a paso.
El orden importa: primero hay que reproducir y acotar el fallo, después intervenir sobre el componente correcto. Modificar plugins, DNS y reglas de seguridad a la vez dificulta saber qué ha cambiado.
Selecciona una URL prioritaria.
Empieza por una URL que debería responder 200 y sea importante: home, categoría o servicio. Guarda la URL, el código observado y la fecha del último rastreo. Separa URLs eliminadas o parámetros inútiles.
Repite una petición GET real.
Comprueba el código de respuesta y las cabeceras con curl o una herramienta HTTP. Evita depender solo del navegador o de HEAD, porque caché y métodos pueden devolver resultados distintos.
Delimita el alcance.
¿Falla toda la web o una plantilla? ¿Solo durante picos de tráfico? ¿Solo para ciertas redes o agentes? Compara home, un post, robots.txt y una URL afectada sin alterar masivamente la infraestructura.
Correlaciona los logs.
Revisa access/error logs, aplicación, PHP-FPM, MySQL, CDN y WAF usando la misma franja horaria y zona horaria. Un 502 de Nginx puede no aparecer como 502 en el log de WordPress.
Corrige la causa raíz.
Puede requerir revertir un despliegue, reparar una extensión, reducir consultas lentas, ajustar el pool de procesos o una regla de seguridad. Realiza cambios controlados y con copia o plan de reversión.
Verifica desde distintos contextos.
Repite GET, comprueba que la respuesta y el contenido son correctos y, cuando proceda, usa la prueba en vivo de Search Console. Verifica también el acceso a /robots.txt.
Solicita revisión sin confundirla con reparación.
Una vez recuperada la disponibilidad, puedes usar «Validar corrección» en el problema del informe cuando esté disponible y solicitar indexación para URLs concretas importantes. No son sustitutos de corregir el servidor.
Monitoriza la estabilidad.
Comprueba nuevas respuestas 5xx, latencia y carga durante varios días. La desaparición del aviso de Search Console y la actualización de la indexación pueden tardar; no existe una fecha universal garantizada.
Diagnóstico guiado: ¿por dónde empiezo?
Selecciona los síntomas observados y obtendrás una ruta de comprobación priorizada. Es un asistente de orientación local: no se conecta a tu hosting, no accede a Search Console y no inventa resultados de tu servidor.
¿Qué está ocurriendo?
Comprueba el error real antes de intervenir.
Una etiqueta genérica de Search Console no identifica el componente que falló.
- Reproduce la URL con HTTP GET.
- Consulta la fecha y los logs.
- Verifica la corrección en la prueba en vivo.
No es una comprobación automática, una auditoría remota ni un diagnóstico clínico de la infraestructura. Los resultados cambian según tus selecciones, no según datos externos.
Comprueba una URL sin adivinar qué responde.
Con curl puedes comprobar el código HTTP, las cabeceras y si hay redirecciones. Esto ayuda a contrastar lo observado en Search Console con el estado actual de la URL; no reproduce necesariamente el contexto de Googlebot.
Generador de comando curl
Escribe una URL pública HTTPS/HTTP que controles. El generador solo crea el comando de texto; no visita el sitio, no realiza peticiones ni almacena la URL.
curl -sS -o /dev/null -D - --max-time 20 'https://ejemplo.com/pagina/'La prueba incluye GET y no sigue redirecciones automáticamente; comprueba también los Location y el destino cuando aparezca 301/302. Haz pruebas repetidas si el fallo es intermitente. No uses direcciones internas, credenciales ni URLs privadas.
Ejemplo de investigación de un 502
2026-10-17T09:41:02+02:00 upstream timed out
while reading response header from upstream
request: "GET /blog/guia/ HTTP/1.1"
upstream: "fastcgi://php-fpm"
status: 504Registro inventado para explicar la lectura. Sugiere revisar el backend PHP y los tiempos de espera; no demuestra que ese componente sea el culpable en tu caso. En tu servidor real conviene correlacionar hora, endpoint, solicitud y latencia con los registros pertinentes.
¿Es una contradicción?
No necesariamente. Search Console puede reflejar una visita anterior; el error también puede producirse solo bajo cierta carga, desde determinadas IP o durante reglas antibots. Revisa la cronología y la prueba publicada.
¿Por qué evitar solo curl -I?
El método HEAD no siempre sigue la misma ruta de aplicación o caché que GET. Para una verificación repetible, inspecciona el comportamiento GET y la cadena de redirecciones por separado.
Error 500 en WordPress: plugins, PHP, .htaccess y hosting.
En WordPress los errores 500 y 503 suelen investigarse desde cambios recientes, extensiones, PHP, configuración y recursos. No desactives plugins a ciegas en una tienda o web crítica: prepara una copia o entorno de pruebas y anota cada modificación.
Plugins y tema
Relaciona la primera fecha del 5xx con actualizaciones, versiones de PHP, snippets o cambios en Elementor. En staging, desactiva componentes de uno en uno o revierte el cambio identificado.
PHP-FPM y recursos
Comprueba límites de memoria, procesos PHP, tiempo máximo de ejecución, almacenamiento y conexiones de base de datos. Aumentar recursos sin conocer la causa puede ocultar el síntoma.
.htaccess y permalinks
En servidores Apache compatibles, un .htaccess corrupto puede provocar un 500. Guarda copia antes de cambiarlo; si identificas la causa, regenera enlaces permanentes de forma controlada.
Cómo activar un log de diagnóstico de WordPress sin mostrar errores al visitante
En un entorno de staging o durante una ventana controlada bajo supervisión, WordPress documenta estas opciones dentro de wp-config.php, antes de la línea final de configuración. No las dupliques si ya están definidas y no dejes depuración detallada activa innecesariamente en producción.
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );Seguridad: los registros pueden contener rutas, errores y otros datos internos. Restringe el acceso a debug.log, evita exponerlo públicamente, elimina o desactiva la depuración al terminar y no copies contraseñas ni tokens en tickets. Fuente: documentación oficial de WordPress ↗.
Si el error aparece solo en Elementor
Comprueba si el fallo afecta a páginas con una plantilla, widget o recurso concreto; si coincide con una actualización, un cambio de versión de PHP o una consulta muy pesada; y si se repite en la vista pública sin sesión de administrador. Un widget que falla en el editor no implica automáticamente que Google esté recibiendo un HTTP 5xx. La prueba es el código que devuelve la URL pública.
Como referencia, la guía de errores comunes de WordPress describe conflictos de plugins y temas, límites PHP y problemas con .htaccess como líneas de diagnóstico del error interno.
Errores 520, 521, 522 y 524 con Cloudflare.
Una CDN puede generar su propia respuesta de error cuando no consigue comunicarse correctamente con el hosting. La distinción entre código devuelto al usuario (edge) y respuesta del origen evita responsabilizar al componente equivocado.
| Error | Qué indica Cloudflare | Primera comprobación |
|---|---|---|
| 520 · Unknown Error | Respuesta vacía, inesperada o no válida del origen. | Crashes, cabeceras, configuración HTTP y registros de origen. |
| 521 · Web Server Is Down | El origen rechaza la conexión desde Cloudflare. | Servicio web activo, firewall, puertos y rangos IP de Cloudflare. |
| 522 · Connection Timed Out | Se agota el tiempo al establecer o gestionar la conexión con el origen. | Firewall, saturación, red y tiempos de conexión. |
| 523 · Origin Is Unreachable | Cloudflare no puede alcanzar la dirección de origen. | DNS de origen, rutas y conectividad. |
| 524 · A Timeout Occurred | Cloudflare contacta con el origen, pero este tarda demasiado en responder. | Procesos lentos, base de datos y tiempos de respuesta. |
| 525 / 526 | Problemas con negociación TLS o certificado SSL del origen. | Certificados, cadena de confianza y modo SSL/TLS. |
En Cloudflare, registra el Ray ID, la URL, la hora con zona horaria, el código edge y, si lo tienes, el código del origen. No presupongas que un 52x implica una incidencia global de Cloudflare. Guía oficial Cloudflare 5xx ↗.
¿Y si el firewall bloquea a Googlebot?
Revisa si alguna regla WAF, protección antibots, limitación de velocidad o desafío genera respuestas problemáticas al rastreador. No basta con ver una cadena «Googlebot» en el User-Agent: puede falsificarse. Google recomienda verificar la identidad mediante DNS inverso y posterior comprobación directa o mediante rangos oficiales de IP. Verificación oficial de Googlebot ↗.
Si el bloqueo se confirma, modifica la regla concreta para permitir tráfico legítimo sin dejar desprotegida la web. Evita listas de excepciones amplias sin comprobación, y conserva evidencia antes y después del cambio.
Humanos ven la web; Google falla.
Prioriza verificación de Googlebot real, respuestas desde el WAF, reglas de rate limiting, CDN y filtrado geográfico o por red.
También fallan peticiones normales.
Prioriza servicio de origen, DNS, conexiones, sobrecarga, certificados o incidencias generalizadas del hosting.
¿Los errores 5xx afectan al SEO y la indexación?
Sí, pueden afectar al descubrimiento, al rastreo y a la permanencia de URLs en Google si la indisponibilidad persiste. Pero no todos los errores tienen el mismo impacto: distingue un fallo puntual de una incidencia prolongada y de un bloqueo a todo el host.
Google recibe un error y no procesa el contenido devuelto por esa solicitud.
Google reduce temporalmente el ritmo de rastreo del host en función del volumen de errores.
Las URLs previamente indexadas pueden conservarse al principio y salir del índice si la indisponibilidad continúa.
Con respuestas correctas, el rastreo se recupera gradualmente. No existe una posición garantizada.
Distinción importante: Google describe 5xx y 429 como señales para ralentizar el rastreo; una URL ya indexada puede permanecer temporalmente, pero los errores persistentes tienen consecuencias. No es un mecanismo que debas utilizar como estrategia habitual para controlar el crawl budget. Google: comportamiento de los códigos HTTP ↗.
¿Qué pasa si el error está en robots.txt?
Es especialmente delicado. Si Google no puede obtener el archivo debido a un fallo de servidor, documenta una fase inicial de hasta 12 horas en la que deja de rastrear el sitio mientras vuelve a solicitarlo; después puede recurrir a la última versión correcta almacenada en caché durante un periodo de hasta 30 días, con matices según la disponibilidad y la caché existente. No es lo mismo que un robots.txt que devuelve 404, respuesta que puede ser válida. Especificación de robots.txt de Google ↗.
¿Es recomendable devolver un 503 durante mantenimiento?
Para interrupciones breves y reales, Google recomienda responder con 503 Service Unavailable, idealmente con Retry-After, en lugar de mostrar una página de mantenimiento con HTTP 200 como si fuera contenido normal. Debe ser temporal: mantener 503/429 durante días puede provocar reducción fuerte del rastreo y pérdida de URLs indexadas. Google: pausar una web temporalmente ↗.
HTTP/1.1 503 Service Unavailable
Content-Type: text/html; charset=utf-8
Retry-After: 3600Es una respuesta HTTP ilustrativa; el servidor real debe estar configurado para emitirla. No es una recomendación de mantener la web caída durante una hora exacta.
Checklist de recuperación y validación en Google.
La reparación no termina cuando el navegador vuelve a abrir la página. Hay que comprobar que el código real es correcto, que el origen resiste nuevas solicitudes y que Google deja de registrar errores en visitas posteriores.
Prueba de infraestructura
Comprueba GET HTTP 200 para páginas existentes, contenido válido, redirecciones, acceso a robots.txt, tiempo de respuesta y ausencia de errores nuevos en los registros.
Comprobación de Google
Usa «Probar URL publicada», vuelve a consultar el informe y, si está disponible, inicia «Validar corrección». Revisa las Estadísticas de rastreo; los datos tardan en reflejar el nuevo estado.
Prioridad práctica: primero URLs de negocio que deben indexarse, luego páginas de navegación y contenidos útiles. Si Google muestra ejemplos de URLs eliminadas, comprueba qué estado HTTP corresponde realmente a cada una. No conviertas automáticamente todas las URLs de una lista en respuestas 200.
Checklist interactivo para antes de cerrar la incidencia
0 de 8 comprobaciones realizadas
Las casillas se conservan únicamente mientras mantengas abierta esta página; no se envían a ningún servidor.
Qué debe cambiar y qué no puede prometerse
Es razonable esperar que, tras corregir la causa, las peticiones vuelvan a responder con códigos correctos y que los informes reflejen gradualmente menos problemas. No sería correcto prometer que todas las URLs se indexarán inmediatamente: una respuesta 200 es necesaria para servir la página, pero la indexación depende de otros factores, como canonical, duplicados, relevancia, directivas de indexación y señales del sitio.
Si tras recuperar el servicio la URL sigue excluida por otro motivo —por ejemplo, «Rastreada: actualmente sin indexar»—, se trata de un diagnóstico diferente. No mantengas el 5xx como explicación cuando la respuesta ya funciona.
Errores habituales al intentar corregir los 5xx.
Una reparación incorrecta puede crear problemas de indexación adicionales o hacer que desaparezca la evidencia necesaria para resolver la incidencia.
Solicitar indexación antes de reparar.
La nueva visita puede volver a fallar. La prioridad es recuperar el servicio y su estabilidad.
Redirigir todos los 5xx a la home.
Un 301 masivo sin equivalencia de contenido oculta problemas y crea redirecciones inadecuadas.
Bloquear Googlebot en robots.txt.
No arregla el origen del fallo y puede impedir el rastreo del contenido que quieres indexar.
Mirar únicamente el HTTP actual.
Los errores intermitentes necesitan cronología, muestras repetidas y logs de diferentes capas.
Desactivar toda la seguridad.
Si sospechas del WAF, identifica y ajusta la regla causante; no suprimas controles indiscriminadamente.
Confundir 200 con éxito SEO.
Un 200 puede servir contenido equivocado, una página de error falsa o una URL no indexable.
Preguntas sobre el error 5xx en Google Search Console.
Respuestas directas a problemas habituales de indexación, servidores, WordPress y diagnóstico.
¿Qué significa «Error del servidor (5xx)» en Search Console?
Que Google intentó acceder a una URL y el servidor devolvió un error de la familia 5xx. Puede deberse a aplicación, hosting, proxy o infraestructura intermedia. El informe por sí solo no identifica la causa exacta.
¿Cómo solucionar el error 5xx de Search Console?
Identifica las URLs afectadas, comprueba el código HTTP mediante GET, consulta logs del momento del error, corrige el origen del fallo y valida el acceso con la prueba de URL publicada. Después supervisa las Estadísticas de rastreo.
¿Un error 500 perjudica al posicionamiento?
Puede perjudicarlo si impide que Google rastree páginas importantes de forma repetida o prolongada. Un fallo puntual no implica necesariamente una retirada inmediata de los resultados; los 5xx persistentes sí pueden provocar pérdida de indexación.
¿Por qué Search Console marca 5xx si la web funciona?
Porque Google puede estar mostrando un intento anterior, o el error puede ser intermitente y depender de carga, red, IP, bot o caché. Compara fechas, registros y el resultado de «Probar URL publicada».
¿Cuál es la diferencia entre 500, 502, 503 y 504?
500 expresa un fallo interno genérico; 502 indica una respuesta incorrecta de un servicio upstream; 503 comunica indisponibilidad temporal; 504 significa que un intermediario agotó el tiempo de espera. Sus causas se confirman en logs.
¿El error 429 también afecta al rastreo de Google?
Sí. Aunque 429 es un código 4xx, Google lo interpreta como una señal de que el servidor recibe demasiadas solicitudes y puede reducir el rastreo. Revisa rate limits y reglas de seguridad.
¿Debo usar «Validar corrección»?
Sí, cuando la opción esté disponible y después de solucionar el problema. Sirve para pedir una revisión, no repara el hosting ni garantiza que la página consiga posiciones o entre en el índice.
¿Cuánto tarda Google en quitar el aviso 5xx?
No hay un plazo único. Depende de cuándo Google vuelva a rastrear y procese la información. Comprueba primero la recuperación HTTP y sigue la evolución de los informes, que no siempre se actualizan en tiempo real.
¿Puede un plugin de WordPress provocar un 500?
Sí. Un error fatal, una incompatibilidad o un consumo excesivo de recursos pueden desencadenarlo. Revisa registros y cambios recientes antes de desactivar componentes en un entorno controlado.
¿Qué hago si tengo un 502 de Nginx?
Revisa la comunicación entre Nginx y su upstream: PHP-FPM o aplicación, logs de error, procesos, reinicios y configuración del proxy. Un 502 puede originarse fuera de WordPress.
¿Qué significa 522 en Cloudflare?
Que Cloudflare agotó el tiempo intentando comunicarse correctamente con el origen. Revisa conectividad, firewall, estado del servidor, limitaciones de red y saturación.
¿Debo bloquear Googlebot si consume recursos?
No como respuesta habitual a los 5xx. Google ofrece recomendaciones específicas para emergencias de sobrecarga, como el uso temporal de 503 o 429 y el aumento de capacidad. Evita medidas permanentes que limiten el descubrimiento.
¿Es peligroso que robots.txt devuelva 5xx?
Sí, puede afectar al rastreo del sitio. Google aplica un tratamiento especial a los fallos de acceso a robots.txt, con reintentos y uso condicionado de versiones almacenadas. Comprueba esa ruta de forma prioritaria.
¿Puedo solucionarlo con una redirección 301?
No si la URL debería existir y solo está fallando el servidor. Una 301 corresponde a un traslado real de contenido hacia una URL equivalente, no a ocultar una indisponibilidad temporal.
¿Debo devolver 503 durante mantenimiento?
Para una interrupción breve y real, es preferible a mostrar una página de mantenimiento con HTTP 200. Puedes incluir Retry-After, pero debes recuperar el servicio lo antes posible: los 503 prolongados afectan al rastreo y la indexación.
¿Por qué una URL ya responde 200 pero sigue sin indexarse?
Porque resolver el 5xx elimina solo una barrera técnica. Todavía pueden intervenir directivas noindex, canonical, duplicados, calidad y relevancia del contenido o tiempos de procesamiento de Google.
Documentación oficial para comprobar cada paso.
Revisión editorial: 17 de octubre de 2026. Los requisitos y comportamientos de rastreo se han contrastado con documentación de Google, WordPress y Cloudflare. Las recomendaciones de priorización son criterio operativo, no estadísticas propias ni datos de una cuenta real.
Criterio editorial
La guía diferencia tres cosas que suelen mezclarse: qué informó Google en su último rastreo, qué responde actualmente el servidor y qué causa interna explica la incidencia. Solo la correlación de datos permite pasar de síntomas a una corrección defendible.
Las ilustraciones de Search Console y los logs de ejemplo son simulaciones educativas. Las herramientas de esta página se ejecutan en el navegador y no pueden acceder a cuentas privadas, servidores ni registros del usuario. Si trabajas con infraestructura crítica, valida cambios con un administrador de sistemas y plan de reversión.
