Error 503: qué es, cómo solucionarlo y qué hace Google

El error 503 (servicio no disponible) es la respuesta que entrega un servidor cuando está vivo pero no puede atenderte en este momento, y esta semana volvió a la conversación por una razón bien concreta. El 21 de octubre PHP publicó parches de emergencia para dos fallas críticas, muchos equipos bajaron sus sitios para aplicarlos y ese mismo día Google Search Central les recordó en LinkedIn que, mientras trabajan, respondan con un 503. John Mueller, de Google, fue más directo en Bluesky: usen 503 en vez de dejar que las respuestas se caigan por timeout, den 404 o den 500.

Me gusta que Google lo dijera en voz alta, porque es de esos detalles que se deciden a las 11 de la noche, con el sitio abajo y alguien preguntando "¿y qué pongo mientras tanto?".

Mi lectura es que el error 503 es el único código de estado que le pide a Google que vuelva más tarde, y en un sitio grande conviene usarlo a propósito en cada mantenimiento y vigilar el que nadie planificó, porque un 503 en el robots.txt o en una regla del CDN puede frenar el rastreo de todo el sitio aunque las personas lo vean funcionando perfecto. Acá va qué significa, qué lo causa, cómo solucionar el error 503 y qué hace Google cuando lo encuentra.

¿Qué es el error 503?

El error 503 (en inglés, 503 Service Unavailable, o "servicio no disponible") es un código de estado HTTP de la familia 5xx, la de los errores del servidor. Dice algo bastante específico: el servidor existe y recibió tu solicitud, pero ahora no puede procesarla, normalmente porque está sobrecargado o en mantenimiento. Es, por definición, una condición temporal.

La analogía que más me sirve es el letrero de "vuelvo en 15 minutos" en la puerta de un local. El local sigue ahí, la dirección es la correcta y nadie cerró el negocio. Solo que en este momento no hay quién atienda. Un 404, en cambio, es llegar a la dirección y encontrar un sitio eriazo.

El mensaje que ves cambia según el servidor y la configuración: "Error 503", "HTTP Error 503", "503 Service Unavailable", "Servicio no disponible" o una página de mantenimiento con el logo de la marca. A Google el diseño de esa página le da lo mismo. Google lee el código de estado que devuelve el servidor y decide con eso qué hacer con tus URLs.

¿Qué causa un error 503?

Las causas se repiten bastante de sitio en sitio:

• Exceso de tráfico. Llegan más solicitudes de las que el servidor puede procesar con sus recursos de CPU, memoria y conexiones. Un clásico es la campaña que funcionó demasiado bien: en 2017 el sitio de Renfe colapsó cuando ofreció pasajes a 25 euros por su aniversario.

• Mantenimiento o actualizaciones. Backups, cambios de versión, parches de seguridad como los de PHP de esta semana. Durante esa ventana el servicio queda fuera a propósito.

• Plugins y temas. En WordPress, un plugin incompatible o un tema mal programado puede disparar el consumo de recursos hasta botar el sitio.

• Configuración del servidor. Límites de memoria de PHP muy bajos, un balanceador mal configurado o procesos que quedaron colgados.

• Firewall y protección contra bots. Reglas demasiado estrictas o un límite de peticiones que bloquea solicitudes legítimas y responde con 503.

• Ataques DDoS. Un ataque que inunda el servidor de solicitudes hasta dejarlo sin capacidad para las visitas reales.

• Base de datos y servicios de terceros. Una base de datos lenta, una API caída o una pasarela de pago que no responde pueden dejar la página sin los datos que necesita para armarse.

A veces el error 503 es intermitente: aparece y desaparece. Eso suele pasar cuando la carga sube y baja (un peak de visitas, un bot pidiendo páginas a toda velocidad) y el problema de fondo sigue ahí. Que se arregle solo a los diez minutos es una tregua: si nadie toca el fondo, en el próximo peak vuelve a pasar.

Hay un origen que las guías mencionan poco y que en sitios grandes me parece el más traicionero: el 503 que solo ven los bots. El CDN o el firewall decide que Googlebot hace demasiadas solicitudes, le responde 503 a él y a nadie más, y el equipo no se entera porque desde la oficina el sitio carga sin problema.

¿Qué hacer si ves un error 503 en otro sitio?

Si el error 503 aparece en un sitio que no es tuyo, tu margen de acción es corto. Recarga la página después de unos segundos, espera unos minutos si parece mantenimiento y vuelve más tarde. Cambiar de navegador no ayuda, porque el problema está del lado del servidor.

¿Cómo solucionar el error 503 en tu sitio?

Si el sitio es tuyo, antes de tocar nada contesta dos preguntas: desde cuándo pasa y a quién le pasa (todas las URLs o una plantilla, las personas o solo los bots). Con eso claro, este es el orden que seguiría para solucionar el error:

1. Revisa si hay un mantenimiento en curso. Mira el panel de control del hosting, la página de estado del proveedor y del CDN, y los correos de aviso. Si alguien está aplicando un parche, el 503 es el comportamiento esperado.

2. Lee los logs. El archivo de errores de Apache o NGINX, y el debug.log si usas WordPress, suelen decir qué script, consulta o proceso falló y a qué hora. Busca mensajes repetidos alrededor del momento en que empezó el problema.

3. Mira el consumo de recursos en el hosting. CPU, memoria e I/O al tope casi siempre apuntan a tráfico, a un proceso pesado o a una extensión que se está comiendo el servidor.

4. Reinicia los servicios. El servidor web, PHP o la base de datos pueden tener procesos atascados. Reiniciarlos libera capacidad, aunque no explica qué pasó.

5. Desactiva plugins y vuelve al tema por defecto. Apágalos todos a la vez y, si el sitio vuelve, reactívalos de a uno hasta encontrar al culpable. Sin acceso al panel, renombra su carpeta por FTP.

6. Revisa el firewall y el CDN. Confirma que ninguna regla nueva esté bloqueando IPs legítimas, incluidas las de Googlebot.

7. Escala o pide soporte. Si el tráfico real superó lo que el hosting puede dar, toca subir de plan o de arquitectura. Y si nada de lo anterior funciona, escríbele al soporte del hosting con la hora exacta del problema y lo que ya probaste.

¿En qué se diferencia el error 503 de un 500, 502, 504 o 429?

Se parecen en pantalla, pero le dicen cosas distintas al navegador y a Google:

Todos los de la familia 5xx terminan en el mismo cajón para Google, según su documentación sobre códigos de estado. La gracia del 503 está en lo que comunica: dice "vuelve después" de forma explícita, y Mueller esta semana validó un orden de preferencia bastante útil para una caída: 503, después 500, después 403, después 404 y, al final de todo, un 200 con una página de error.

¿El error 503 afecta al SEO?

Depende de cuánto dure y de dónde aparezca. Un error 503 de unos minutos no pesa: Gary Illyes, de Google, dijo en 2024 que un 503 de 10 a 15 minutos de vez en cuando no es "prolongado" en ningún sentido. El riesgo aparece cuando se estira por horas o días.

Esto documenta Google sobre los errores del servidor:

• Googlebot baja temporalmente el ritmo de rastreo cuando recibe 5xx o 429, y lo vuelve a subir de a poco cuando el servidor responde bien. La baja es proporcional a la cantidad de URLs con error.

• Las URLs que ya están en el índice se preservan, pero si siguen respondiendo con error terminan saliendo. Google no da un plazo exacto para eso.

• Mientras una página responde 503, Google no puede actualizar su título, su descripción ni sus datos estructurados.

• Para una pausa urgente de uno o dos días, la guía de Google para pausar un sitio recomienda el 503. Para cierres más largos, sugiere mantener una página indexable que responda 200.

O sea, la pregunta para tu equipo es cuántas horas y en qué URLs. Un mantenimiento de una hora con 503 es invisible para el SEO. Una tienda que responde 503 a Googlebot durante tres semanas porque el CDN lo confundió con un bot agresivo es otra historia.

Un detalle más: Google documenta el 503 o el 429 como forma de bajar el ritmo de rastreo cuando Googlebot sobrecarga el servidor, pero recomienda no hacerlo por mucho tiempo, porque retrasa el descubrimiento de páginas nuevas y la actualización de las existentes (si quieres el contexto, en el artículo sobre crawl budget está cuándo vale la pena preocuparse del rastreo).

¿Qué pasa si el robots.txt devuelve un error 503?

Esta es la parte que más me importa del artículo. Según la especificación de Google, si el robots.txt responde con un 5xx, Google deja de rastrear todo el sitio durante las primeras 12 horas mientras sigue intentando leer el archivo. Si no lo logra, usa la última versión buena que tenga guardada hasta por 30 días.

Traducido: un modo mantenimiento que responde 503 a todas las URLs, incluido el robots.txt, apaga el rastreo del sitio entero. Por eso la guía de Google dice explícitamente que no devuelvas 503 en el robots.txt. Lo vimos también en la guía de robots.txt: el archivo más corto del sitio puede frenar todo lo demás.

¿Cómo hacer un mantenimiento con error 503 sin perder posicionamiento?

Si vas a bajar el sitio a propósito (por un parche, una migración o un cambio de servidor), estos son los pasos que dejaría escritos en el checklist:

1. Sirve el 503 desde fuera de la aplicación. Si el problema es PHP, el 503 no puede depender de PHP. Mueller sugirió responderlo desde fuera de PHP, desde el CDN o apuntando el DNS a otro lado.

2. Deja el robots.txt respondiendo 200. Es un archivo estático, así que puede quedar servido aparte aunque todo lo demás esté abajo.

3. Agrega el encabezado Retry-After. Viene del estándar HTTP y le dice a navegadores y bots cuándo volver a intentar, en segundos o con una fecha. Suma contexto, aunque Google no promete volver justo a esa hora.

4. Revisa la configuración del CDN para que no guarde el 503 en caché. Si la respuesta de error queda cacheada, los usuarios y los bots pueden seguir recibiéndola después de que el sitio volvió.

5. Evita los atajos. Nada de páginas de error con código 200 (Google puede indexar el mensaje de error), ni 404 masivos, ni noindex temporal, ni la herramienta de retiradas de Search Console.

6. Si va a durar más de un par de días, cambia de estrategia. Mantén una home indexable con código 200 que explique la situación, como sugiere Google para cierres largos.

7. Al volver, revisa. Inspecciona tus páginas que más venden en Search Console y confirma que respondan 200.

Las migraciones son mi fuente favorita de estos accidentes, porque juntan apuro, ambiente de pruebas y servidor nuevo. En el checklist para rediseñar tu web y en el de riesgo SEO de una migración está el resto de lo que revisaría.

¿Cómo saber si Google está viendo errores 503?

Acá está la diferencia entre el 503 que tú ves y el que ve Google. Para el segundo hay dos fuentes:

1. Search Console, en Configuración > Estadísticas de rastreo. El desglose por respuesta muestra qué parte de las solicitudes de Googlebot terminó en error del servidor (5xx), y el estado del host muestra si hubo problemas para leer el robots.txt o para conectarse con el servidor. Si ves un salto ahí y nadie avisó de un mantenimiento, vale la pena investigar.

2. Los logs del servidor. Es el método que usamos en las auditorías de sitios enterprise: tomamos 30 días de logs, filtramos las visitas reales de Googlebot (verificadas, no cualquiera que diga llamarse así) y agrupamos los errores por plantilla: fichas, categorías, filtros, búsqueda interna. Un 503 repartido al azar suele ser carga. Un 503 concentrado en una plantilla suele ser una consulta lenta a la base de datos o una regla del firewall.

Un ejemplo ilustrativo: un sitio con 400.000 solicitudes de Googlebot al mes donde el 6% termina en 503, casi todo en las páginas de categoría entre las 9 y las 11 de la mañana. Ese patrón ya te dice dónde mirar (y quizás coincide con el horario en que marketing lanza sus campañas). Si además quieres revisar el estado de indexación de las páginas afectadas, en cómo indexar una página en Google está el detalle de cada estado.

¿Cómo evitar que el servidor vuelva a dar un error 503?

La prevención es menos glamorosa, pero ahorra noches:

• Monitorea disponibilidad y recursos con alertas, para enterarte antes que tus clientes.

• Prueba la carga antes de los peaks. Si sabes que viene un evento de descuentos o una campaña grande, simula ese tráfico en un ambiente de pruebas antes del día. Si tu peak es Black Friday, en SEO para Black Friday están los datos de cuándo llegan los clics.

• Usa caché y CDN para que el servidor de origen trabaje menos con cada visita.

• Mantén actualizados el CMS, los plugins y el tema, y prueba cada actualización en staging antes de publicarla.

• Planifica los mantenimientos en horarios de poco tráfico, con el 503 y el robots.txt configurados como en la sección anterior. Si tu plan de hosting se queda corto cada vez que hay campaña, esa conversación también va aquí.

• Revisa las reglas de bots del CDN y del firewall cada vez que alguien de seguridad las cambie, con SEO en la conversación.

Qué revisaría esta semana

Si tu equipo aplicó los parches de PHP o tiene una ventana programada, abre Search Console y mira las Estadísticas de rastreo de los últimos siete días: si hay un salto de errores del servidor, cruza la fecha con la ventana de mantenimiento. Después pide un curl -I a tu robots.txt durante el próximo mantenimiento programado y confirma que responda 200. Son diez minutos y sale bastante más barato que descubrirlo por una caída en el reporte de noviembre.