Error 500 Internal Server Error

TL;DR — Un 500 Internal Server Error significa que el servidor falló al intentar construir la página: no es un problema de su URL, de su navegador ni del rastreador del buscador. Un 500 aislado suele ser reintentado por Google, y no existe ninguna regla que diga que le cueste algo. El peligro documentado aparece cuando muchas de sus páginas devuelven errores 500s durante un tiempo: es entonces cuando Google reduce la velocidad de rastreo y, con el tiempo, puede retirar páginas de la búsqueda. Empiece a solucionarlo revisando los registros de errores de su servidor, no el navegador.

Qué es un error 500

Un 500 Internal Server Error es la versión web de «algo salió mal y no puedo decirle exactamente qué». El servidor recibió la solicitud, empezó a construir la página, se topó con un problema y se rindió: devolvió un error genérico en lugar de la página. En la guía de códigos de estado HTTP de Ahrefs lo expresé así: el servidor “encounters some kind of issue and doesn’t have a better or more specific error code.” (traducción) «se encuentra con algún tipo de problema y no tiene un código de error mejor o más específico». Evidence for this claim A 500 response means the server encountered an unexpected condition that prevented it from fulfilling the request. Scope: RFC 9110 defines the generic response semantics; it does not diagnose the underlying server fault. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.6.1 — 500 Internal Server Error

Esto es lo esencial que hay que entender: un 500 es un código genérico que lo abarca todo. Indica que algo falló en el lado del servidor. No indica qué. Averiguar ese «qué» es todo el trabajo.

Es un problema del servidor, no suyo (por lo general)

Los errores 500 pertenecen a la familia 5xx: errores de servidor. Eso es distinto de los errores 4xx, como el 404 (página no encontrada), que se refieren a la solicitud (una URL incorrecta o inexistente). Con un 500, la URL puede estar perfectamente bien; simplemente el servidor no pudo terminar el trabajo. También verá parientes del 500 —502, 503 y 504— que también son del lado del servidor, pero apuntan a situaciones más concretas (una pasarela defectuosa, un servidor temporalmente no disponible o un tiempo de espera agotado).

¿Un error 500 perjudica al SEO?

¿Un 500 puntual y aislado en una sola página? Por lo general Google volverá a intentarlo y, si la página carga bien en el reintento, ahí suele acabar el asunto. Google no publica ninguna promesa general de que un fallo aislado sea inofensivo, pero tampoco documenta ningún mecanismo que penalice un incidente puntual.

El riesgo real y documentado son los 500s persistentes en muchas páginas. Cuando eso ocurre:

1. Google sigue reintentando, ve que los errores continúan y reduce la velocidad con la que rastrea su sitio.
2. Si los errores siguen sin resolverse, Google acaba por retirar esas páginas del índice, es decir, dejan de aparecer en la búsqueda. Evidence for this claim Google reduces crawling in response to 5xx errors and eventually removes persistently failing URLs from its index. Scope: Google documents the general 5xx progression; it does not provide a guaranteed retry or recovery timeline for an individual URL. Confidence: high · Verified: 2026-07-14 Google: How HTTP status codes affect Google's crawlers

La buena noticia: la propia documentación de Google describe una recuperación gradual una vez que el problema de fondo se corrige y los rastreos vuelven a tener éxito, pero no garantiza ni un plazo ni un resultado. “Recovery is usually quick” (traducción) «la recuperación suele ser rápida» describe el caso habitual, no una promesa.

Cómo empezar a solucionarlo

• Revise primero los registros de errores de su servidor. Ahí está el motivo real, no en el navegador. El navegador solo muestra «500»; los registros muestran por qué.
• Fíjese en qué cambió recientemente. ¿Un plugin, un tema o un módulo nuevo? ¿Un despliegue de código reciente? ¿Una modificación en un archivo de configuración como .htaccess? Los cambios recientes son los sospechosos habituales.
• Revise Google Search Console. El informe Page Indexing (Informe “Indexación de páginas”) tiene una sección “Server error (5xx)” que muestra en qué URL suyas está viendo Google errores 500s.
• Pregunte a su proveedor de hosting. Sobre todo en alojamiento compartido, muchos 500s se deben a alcanzar límites de memoria o de recursos; a menudo su proveedor puede verlo desde su lado.

¿Quiere la versión más profunda —cómo escala Google exactamente, la regla empírica del ~1 %, la distinción entre 500 y 503 y un orden de diagnóstico completo? Cambie a la pestaña Avanzado.

TL;DR — El RFC 9110 define el 500 como una condición inesperada que impidió al servidor atender la solicitud: ese es todo el límite del código de estado en sí; la causa, la duración y la conveniencia de reintentar son diagnóstico, no semántica. La reacción documentada de Google es graduada: los 500s aislados suelen reintentarse; los 500s persistentes en todo el sitio provocan un rastreo más lento y, si no se resuelven, la retirada final del índice. Mueller ha ofrecido una regla empírica aproximada y personal —tasas de error por encima de aproximadamente el 1 % probablemente signifiquen que algo está roto—, pero eso no es un umbral documentado de Google, y la secuencia reintento → rastreo lento → retirada describe comportamientos documentados, no un temporizador fijo y sincronizado. Diagnostique primero desde los registros del servidor y después con el informe “Server error (5xx)” de GSC y el desglose “by response” de Crawl Stats. La distinción entre 500 y 503 importa: el 503 es el código sancionado de «vuelva más tarde», con una ventana de gracia de ~2 días; un 500 incontrolado no obtiene esa gracia.

Qué es realmente un 500

Empiece por la especificación, no por la jerga profesional. El RFC 9110 —el estándar de semántica HTTP— define un 500 Internal Server Error como una condición inesperada que impidió al servidor atender la solicitud. Ese es todo el límite de lo que le indica el código de estado en sí. No identifica la causa raíz, el componente que falla, cuánto durará el problema, si la misma solicitud tendría éxito en un reintento ni si la recuperación es probable. Todo lo que va más allá de «el servidor se topó con algo que no pudo manejar» es diagnóstico, no semántica del código de estado, y el diagnóstico vive en sus registros de errores del servidor, no en la especificación ni en el navegador.

En la guía de códigos de estado HTTP de Ahrefs mantengo deliberadamente rotunda la definición dirigida a quienes trabajan en esto: el servidor “encounters some kind of issue and doesn’t have a better or more specific error code” (traducción) «se encuentra con algún tipo de problema y no tiene un código de error mejor o más específico». Es una glosa en lenguaje llano del mismo límite del RFC: sigue siendo un código genérico y sigue siendo un síntoma más que un diagnóstico.

Se sitúa en la familia 5xx junto al 502 (bad gateway), el 503 (service unavailable) y el 504 (gateway timeout) —todos del lado del servidor—, pero el 500 es el que significa «no se aplica ningún código mejor». Como el código de estado en sí no lleva ningún detalle de diagnóstico, recargar el navegador no dice nada sobre por qué ocurrió; los registros de errores de su servidor son la fuente fiable.

Cómo trata Googlebot un 500

El rastreador de Google es respetuoso por diseño: ajusta su ritmo al estado de salud de su servidor, y las respuestas 5xx son una de las señales que interpreta como «reduce la marcha». La documentación actual de Google confirma la forma de esa reacción: las respuestas 5xx y 429 provocan una reducción temporal de la frecuencia de rastreo (proporcional a cuántas URL están afectadas), y las URL que siguen fallando pueden acabar retiradas del índice, mientras que el contenido ya indexado se conserva entretanto a la espera de una actualización correcta. Evidence for this claim Google reduces crawling in response to 5xx errors and eventually removes persistently failing URLs from its index. Scope: Google documents the general 5xx progression; it does not provide a guaranteed retry or recovery timeline for an individual URL. Confidence: high · Verified: 2026-07-14 Google: How HTTP status codes affect Google's crawlers John Mueller ha descrito esa misma progresión con sus propias palabras, en una sesión de Google SEO Office Hours difundida a través de Search Engine Journal:

“We don’t have any strong thresholds on that. But essentially what happens with 500 errors is we’ll try to retry them. And if we continue to see …the 500 errors then we will …slow down crawling. And if we continue to see that there are 500 errors then we will drop those URLs from the index.” (traducción) «No tenemos umbrales estrictos al respecto. Pero, en esencia, lo que ocurre con los errores de servidor es que intentaremos reintentarlos. Y si seguimos viendo …los errores, entonces …reduciremos la velocidad de rastreo. Y si seguimos viendo que hay errores de servidor, entonces retiraremos esas URL del índice.»

Lea eso como una descripción de comportamientos documentados —reintento, rastreo más lento, posible retirada— y no como un temporizador fijo de tres pasos con transiciones o plazos garantizados; Google no publica umbrales exactos sobre cuándo una etapa pasa a la siguiente. Un 500 aislado en una sola URL suele reintentarse, y la siguiente obtención correcta suele zanjar el asunto, pero eso describe el caso habitual, no una garantía de que un fallo puntual no tenga ningún costo. El riesgo real y documentado está en los errores que no se resuelven.

Por qué los 500s en todo el sitio son peores que los aislados

Hay una dinámica más desagradable cuando una gran parte de su sitio devuelve 500s a la vez. La documentación actual de Google confirma que el recorte de la frecuencia de rastreo es proporcional a cuántas URL están afectadas: cuanto mayor sea la parte del sitio que falla, más se ralentiza el rastreo. Mueller ha expresado el razonamiento que hay detrás en términos más concretos, planteándolo como que Google sospecha que su propio rastreo podría ser parte de la sobrecarga:

“But if a large part of a site consistently has 500 errors and we might assume that maybe we’re causing the problem and we’ll slow down crawling of the whole site and at some point we’ll say well, it looks like these pages are really gone, we’re going to drop them.” (traducción) «Pero si una gran parte de un sitio tiene errores de servidor de forma constante, podríamos suponer que quizá nosotros estamos causando el problema y reduciremos la velocidad de rastreo de todo el sitio y, en algún momento, diremos: bueno, parece que estas páginas realmente han desaparecido, vamos a retirarlas.»

Trate ese encuadre causal concreto de «suponemos que lo estamos causando nosotros» como una caracterización propia de Mueller y no como una redacción tomada literalmente de la documentación oficial actual de Google: el mecanismo de fondo está documentado (más URL fallando, mayor reducción de la frecuencia de rastreo), aunque el razonamiento causal exacto sea más fácil de verificar en su propia declaración que en la documentación misma. En cualquier caso, vale la pena interiorizar el bucle de retroalimentación práctico: un rastreo agresivo bajo agotamiento de recursos puede provocar más errores 500s → Google reduce el rastreo de todo el sitio → y, si los errores persisten de todos modos, las páginas caen. También significa que un problema de 500 no siempre es un fallo de código: a veces es su servidor cediendo bajo carga concurrente que solo aparece con picos de rastreo o de tráfico.

¿Cuánto es «demasiado»?

No hay una línea clara: la propia documentación de resolución de problemas de Google no publica ningún umbral de tasa de error. Mueller ha ofrecido una regla empírica aproximada y personal en SEO Office Hours (de nuevo, difundida a través de Search Engine Journal, no una publicación oficial de Google):

“My feeling is if you’re seeing something more than one percent then that sounds like something is kind of broken.” (traducción) «Mi impresión es que, si observa algo por encima del uno por ciento, eso suena a que algo está medio roto.»

Trate el ~1 % como una prueba de olfato no oficial atribuida a Mueller, no como un límite documentado ni aplicado por Google. Por debajo probablemente esté bien; por encima, merece la pena investigar, pero no considere que cruzar el 1 % sea un detonante automático ni que quedarse por debajo sea una garantía. La única cifra que Google asume públicamente es la ausencia de una: “we don’t have any strong thresholds” (traducción) «no tenemos umbrales estrictos».

500 frente a 503: la distinción que importa

Aquí es donde mucha gente se equivoca. Un 503 Service Unavailable es la forma sancionada de decirle a un rastreador «estoy caído temporalmente, vuelve más tarde». Google lo trata como intencionado y le concede una ventana de gracia. La propia documentación de Google sobre resolución de problemas de rastreo es explícita:

Según Google, “Return 503 or 429 HTTP response status codes temporarily for Googlebot requests when your server is overloaded. Googlebot will retry these URLs for about 2 days. Note that returning ‘no availability’ codes for more than a few days will cause Google to permanently slow or stop crawling URLs on your site.” (traducción) «Para las solicitudes de Googlebot con el servidor sobrecargado, devuelva temporalmente los códigos de respuesta HTTP indicados. Googlebot volverá a probar esas URL durante unos 2 días. Si devuelve códigos de “no disponibilidad” más de unos días, Google ralentizará o detendrá de forma permanente el rastreo de las URL del sitio.»

El contraste: el 503 es intencionado y obtiene una gracia de reintento de ~2 días; un 500 incontrolado es involuntario y no obtiene esa gracia: simplemente se reintenta hasta que Google se rinde. Consecuencia práctica: para un mantenimiento planificado o una defensa deliberada frente a la sobrecarga, devuelva un 503 (idealmente con una cabecera Retry-After), no un 500 ni una página de error devuelta con 200. Nunca disfrace una caída real como un 200.

Cómo diagnosticar un 500

Trabaje por capas —aplicación/código, plataforma/CMS, infraestructura y recursos, y después configuración—, empezando por lo más barato y lo que más probablemente dé resultado. Los pasos marcados como (específico de WordPress) son práctica habitual en WordPress, no soluciones universales; adáptelos a la pila tecnológica que realmente utilice.

1. Registros de errores del servidor. error.log / access.log (o el visor de registros de su plataforma). Haga coincidir las marcas de tiempo con las solicitudes que fallan. Ahí es donde aparecen el rastro de pila real, el error fatal de PHP o el fallo de conexión con la base de datos. Todo lo que viene después es adivinar hasta que los haya leído.
2. GSC — informe “Server error (5xx)”. El informe Page Indexing (Informe “Indexación de páginas”) de Google Search Console señala las URL en las que Google está viendo errores 500. Después abra Crawl Stats y lea el desglose “by response” a lo largo del tiempo: así se distingue un incidente pasajero de un problema de disponibilidad real y sostenido.
3. Bing Webmaster Tools. Sus alertas de errores de rastreo agrupan los Server Errors (5xx) y le dirigen a las URL concretas y a la herramienta Crawl Information.
4. Reproduzca como un bot, no solo como un navegador. Una página puede devolver 500 para Googlebot y cargar bien para usted: por carga provocada por el rastreo, por una mala configuración de la detección de bots o del firewall, o por límites de capacidad que solo aparecen con tráfico de bots concurrente. Use URL Inspection (herramienta de inspección de URL) en GSC, Fetch as Bingbot o curl con un agente de usuario de bot para detectar fallos exclusivos de bots. «Funciona en mi navegador» no es una señal de que todo esté bien.
5. Conflictos de plugins, temas o módulos (patrón específico de WordPress; adáptelo en otros casos). Haga primero una copia de seguridad: tenga siempre una vía de vuelta antes de empezar a desactivar cosas. Después desactive las extensiones y reactívelas de una en una para aislar la culpable, comprobando los permisos y la propiedad de los archivos que toque. Las propias guías de resolución de problemas de WordPress de los proveedores de hosting informan a menudo de este patrón, pero eso es una observación específica de esa pila, no una prueba de que sea la causa principal en todas partes; en otro CMS o en una aplicación propia, el equivalente es un conflicto de un módulo, paquete o middleware de terceros.
6. Agotamiento de recursos. Límites de memoria de PHP, límites de conexiones a la base de datos, capacidad del alojamiento compartido, picos de tráfico o de rastreo. A menudo su proveedor de hosting puede confirmarlo desde su lado.
7. Configuración y cambios recientes. Un .htaccess roto, una edición incorrecta de la configuración del servidor, un despliegue reciente o credenciales de base de datos equivocadas. Los cambios recientes son el lugar más rentable donde mirar.

Cómo solucionarlo (ajuste la solución a la causa)

Ajuste la solución a la capa que haya señalado el diagnóstico. Estos son patrones habituales de los que se informa en textos profesionales, no una lista ordenada ni universal de lo más probable en su pila concreta:

• Lo causó la configuración o un despliegue → revierta el cambio; corrija el .htaccess, la configuración o las credenciales.
• Agotamiento de recursos → suba los límites (memoria de PHP, conexiones a la base de datos) o mejore el plan de alojamiento; si el rastreo está provocando la sobrecarga, también es una conversación sobre la frecuencia de rastreo.
• Conflicto de plugin o módulo → elimine o sustituya la extensión problemática.
• Fallo de código → corrija el código y añada la gestión de errores que falta.
• No consigue determinarlo → escale al proveedor de hosting con las marcas de tiempo exactas y las líneas de registro. No adivine en producción.

Cómo evitar que se repita

Monitorización y alertas sobre las tasas de 5xx, probar los cambios en un entorno de preproducción antes de que lleguen a producción, hacer pruebas de carga antes de picos de tráfico previstos y —si el propio rastreo de Googlebot es el detonante— gestionar la carga de rastreo (devolviendo 503/429 de forma deliberada durante una sobrecarga real, en lugar de dejar que el servidor emita errores 500s incontrolados).

Preguntas frecuentes

¿Un error 500 perjudica al SEO? El riesgo documentado tiene que ver sobre todo con la persistencia a escala. Los 500 aislados suelen reintentarse, sin ninguna penalización documentada por un incidente puntual; los 500 sostenidos en todo el sitio ralentizan el rastreo y pueden llevar a la desindexación.

¿Cuánto tarda Google en desindexar una página con un 500? No hay un plazo fijo. Google primero reintenta y reduce la velocidad de rastreo; la retirada del índice solo llega si los errores continúan. Corríjalo y, en general, las páginas vuelven cuando los rastreos tienen éxito de nuevo.

¿Por qué mi sitio devuelve 500 a Googlebot pero carga bien en mi navegador? Los 500 exclusivos de bots suelen indicar problemas de capacidad o de gestión de bots: carga provocada por el rastreo, reglas de firewall o de detección de bots, o límites que solo aparecen con tráfico de bots concurrente. Confíe en los registros, no en una comprobación manual con el navegador.

¿Pueden los 500s ralentizar el rastreo de todo mi sitio, y no solo de las páginas afectadas? Sí: la documentación de Google confirma que el recorte de la frecuencia de rastreo es proporcional a cuántas URL están fallando, de modo que una gran parte del sitio devolviendo 500s ralentiza el rastreo en todo el sitio. Mueller ha planteado además el razonamiento como que Google sospecha que su propio rastreo podría ser parte de la sobrecarga: es su propia caracterización, no una redacción tomada literalmente de la documentación oficial actual.

¿Qué causa un 500 en WordPress? En WordPress concretamente, los proveedores de hosting y la comunidad de WordPress informan con más frecuencia de conflictos de plugins o temas, de un .htaccess corrupto o de alcanzar el límite de memoria de PHP: eso es lo que se informa para esa plataforma, no una afirmación de que sean las causas principales universales de todos los 500. El orden de diagnóstico anterior (primero los registros, después qué cambió) es el mismo independientemente del CMS.

¿Es seguro reintentar automáticamente una solicitud tras un 500? Solo si ha comprobado antes el método y la idempotencia de la solicitud: el propio código de estado 500 no autoriza una política de reintentos. GET, HEAD, PUT y DELETE suelen ser seguros de reintentar porque son idempotentes (repetirlos no debería provocar efectos secundarios adicionales); un POST a secas normalmente no lo es, salvo que su API garantice explícitamente la idempotencia (por ejemplo, mediante una clave de idempotencia): reintentarlo a ciegas arriesga un pedido duplicado, un correo duplicado o un pago cobrado dos veces. Cuando reintente, use retroceso exponencial con jitter, limite el número de intentos y fije un presupuesto de reintentos para que un servidor con dificultades no reciba una tormenta de reintentos encima de lo que ya está fallando.

Resumen con IA

Una versión condensada del contenido de la pestaña Advanced:

• 500 = el límite de «condición inesperada» del RFC 9110. Ese es todo el alcance del código de estado en sí: ninguna causa raíz, ninguna duración, ninguna indicación de si conviene reintentar. Es un síntoma, no un diagnóstico; busque la causa raíz en los registros del servidor, no en el navegador. Distinto de los errores 4xx (cliente/solicitud) y de sus hermanos 5xx 502/503/504.
• La reacción documentada de Google es graduada: reducción temporal de la frecuencia de rastreo (proporcional a cuántas URL están afectadas) y posible retirada final del índice para las URL que siguen fallando, con recuperación una vez que las obtenciones vuelven a tener éxito. Mueller lo describe como reintento → rastreo más lento → retirada del índice: una descripción de comportamientos documentados, no un temporizador fijo y sincronizado. Un 500 aislado suele reintentarse; no hay ninguna promesa de que no tenga costo, pero el riesgo real y documentado es la persistencia a escala.
• Los 500s en todo el sitio son peores: el recorte de la frecuencia de rastreo es proporcional a cuántas URL fallan. Mueller plantea el razonamiento como que Google sospecha que su propio rastreo puede ser parte de la sobrecarga —su propia caracterización, no una redacción literal de la documentación oficial— y, en cualquier caso, es un bucle de retroalimentación en el que la carga de rastreo puede provocar más errores 500s.
• Regla empírica, no umbral: Mueller ha dicho que las tasas de error por encima del ~1 % están “probably broken” (traducción) «probablemente rotas», pero ese es su encuadre personal en SEO Office Hours, no un límite documentado de Google: Google afirma que no tiene umbrales estrictos.
• 500 frente a 503: el 503 (o el 429) es la señal sancionada de «vuelve más tarde», con una gracia de reintento de ~2 días según la documentación de Google; un 500 incontrolado no obtiene ninguna gracia. Use el 503 (con Retry-After) para las caídas planificadas.
• Orden de diagnóstico (por capas): registros del servidor → “Server error (5xx)” de GSC + “by response” de Crawl Stats → Bing Webmaster Tools → reproducir como bot (URL Inspection / curl) → conflictos de plugins o módulos (patrón específico de WordPress; adáptelo en otros casos y haga antes una copia de seguridad) → agotamiento de recursos → cambios de configuración o de despliegue.
• La seguridad del reintento depende de la solicitud, no del código de estado. Los métodos idempotentes (GET/HEAD/PUT/DELETE) suelen ser seguros de reintentar; un POST a secas normalmente no lo es sin una clave de idempotencia. Use retroceso, un tope de intentos y un presupuesto de reintentos.
• La recuperación suele ser rápida una vez corregido: las páginas retiradas tienden a volver a medida que los rastreos vuelven a tener éxito, aunque Google no garantiza ni plazo ni resultado.

Documentación oficial

Documentación de fuentes primarias de los buscadores y de la especificación HTTP.

Google

• Troubleshoot Google Search crawling errors — cómo gestiona Google los errores de servidor y el uso sancionado de 503/429 para una sobrecarga temporal.
• In-Depth Guide to How Google Search Works — el planificador de rastreo y el hecho de que las respuestas 5xx se interpretan como «reduce la marcha».
• Crawl Stats report — el desglose “by response” (incluido Server error (5xx)) que se usa para distinguir un incidente pasajero de un problema sostenido.
• Reduce la frecuencia de rastreo de Googlebot — la forma correcta y deliberada de ralentizar el rastreo (en lugar de dejar que el servidor emita errores 500s incontrolados).

Bing / Microsoft

• Bing Webmaster Tools — List of crawl error alerts — cómo agrupa Bing los Server Errors (5xx) y dónde inspeccionar las URL afectadas.

Especificación HTTP / referencia

• MDN — 500 Internal Server Error — la definición del código de estado en sí.
• RFC 9110 §15.6.1 — 500 Internal Server Error — la semántica HTTP autoritativa.

Citas de la fuente

Declaraciones hechas públicamente. Cuando una página de origen se renderiza con JavaScript o llegó a través de una cobertura secundaria, se indica con una advertencia <small>.

Google — la ruta de escalada

• “We don’t have any strong thresholds on that. But essentially what happens with 500 errors is we’ll try to retry them. And if we continue to see …the 500 errors then we will …slow down crawling. And if we continue to see that there are 500 errors then we will drop those URLs from the index.” (traducción) «No tenemos umbrales estrictos al respecto. Pero, en esencia, lo que ocurre con los errores de servidor es que intentaremos reintentarlos. Y si seguimos viendo …los errores de servidor, entonces …reduciremos la velocidad de rastreo. Y si seguimos viendo que hay errores de servidor, entonces retiraremos esas URL del índice.» — John Mueller, Google. Consultar la cobertura Difundido a través de la transcripción de Search Engine Journal de un vídeo de Google SEO Office Hours; confirme la redacción exacta con el vídeo original antes de tratarla como definitiva.
• “But if a large part of a site consistently has 500 errors and we might assume that maybe we’re causing the problem and we’ll slow down crawling of the whole site and at some point we’ll say well, it looks like these pages are really gone, we’re going to drop them.” (traducción) «Pero si una gran parte de un sitio tiene errores de servidor de forma constante, podríamos suponer que quizá nosotros estamos causando el problema y reduciremos la velocidad de rastreo de todo el sitio y, en algún momento, diremos: bueno, parece que estas páginas realmente han desaparecido, vamos a retirarlas.» — John Mueller, Google. Ver la cobertura Difundido a través de Search Engine Journal; verifique la literalidad con el vídeo original.
• “My feeling is if you’re seeing something more than one percent then that sounds like something is kind of broken.” (traducción) «Mi impresión es que, si observa algo por encima del uno por ciento, eso suena a que algo está medio roto.» — John Mueller, Google, sobre una regla empírica aproximada de tasa de error. Revisar la cobertura Difundido a través de Search Engine Journal; verifique la literalidad con el vídeo original.

Google — la señal sancionada de «reduce la marcha» (documentación, verificada)

• “Return 503 or 429 HTTP response status codes temporarily for Googlebot requests when your server is overloaded. Googlebot will retry these URLs for about 2 days. Note that returning ‘no availability’ codes for more than a few days will cause Google to permanently slow or stop crawling URLs on your site.” (traducción) «Si el servidor está sobrecargado, devuelva temporalmente los códigos de respuesta HTTP indicados cuando las solicitudes procedan de Googlebot. Este volverá a intentar esas URL durante unos 2 días. Si los códigos de “no disponibilidad” persisten más de unos días, Google ralentizará o detendrá permanentemente el rastreo de las URL.» — documentación de Google Search Central. Ir a la cita

Patrick Stox — la definición (Ahrefs, verificada)

• “500 Internal Server Error – The server encounters some kind of issue and doesn’t have a better or more specific error code.” (traducción) «Error interno del servidor: el servidor se encuentra con algún tipo de problema y no tiene un código de error mejor o más específico.» — mi guía de códigos de estado HTTP en el blog de Ahrefs. Ir a la cita

Lista de comprobación para el triaje de errores 500

Recórrala de arriba abajo en el momento en que aparezcan los 500s:

• Ha extraído los registros de errores del servidor y ha encontrado el error real (rastro de pila / error fatal de PHP / fallo de la base de datos), no solo el «500» del navegador.
• Ha revisado qué cambió recientemente: plugin, tema o módulo nuevo, despliegue reciente, edición del .htaccess o de la configuración del servidor, credenciales de base de datos modificadas.
• Ha abierto GSC → Page Indexing → Server error (5xx) para ver en qué URL está viendo Google errores 500s.
• Ha leído el desglose “by response” de Crawl Stats en GSC a lo largo del tiempo para juzgar si es pasajero o sostenido.
• Ha comprobado las alertas de errores de rastreo de Bing Webmaster Tools para las mismas URL.
• Ha reproducido el fallo como bot (URL Inspection / Fetch as Bingbot / curl con un agente de usuario de bot), no solo en un navegador.
• Ha descartado el agotamiento de recursos (memoria de PHP, conexiones a la base de datos, capacidad del alojamiento) con su proveedor de hosting.
• Ha aislado cualquier conflicto de plugin o módulo desactivando y reactivando de uno en uno.
• Ha confirmado que no emite errores 500 incontrolados durante caídas planificadas: use 503 (con Retry-After) en su lugar.
• Ha verificado que la tasa de error vuelve a estar por debajo de la prueba de olfato no oficial del ~1 % (la regla empírica de Mueller, no un umbral documentado de Google) una vez corregido, y que GSC muestra rastreos correctos de nuevo.

Runbook: «El sitio está devolviendo errores 500s: ¿qué reviso primero?»

Un orden de operaciones sin pánico. Hágalos en secuencia; pare cuando haya encontrado y corregido la causa.

0. Delimite el alcance (2 minutos). ¿Es una sola URL, una plantilla o sección o todo el sitio? Una sola URL tiene poco en juego (Google reintenta). Que sea en todo el sitio es la emergencia: ese es el patrón que hace que Google ralentice el rastreo de todo el sitio.

1. Lea los registros de errores del servidor. Primero error.log. Haga coincidir las marcas de tiempo con los fallos. Está buscando la causa real: un error fatal de PHP, un fallo de conexión con la base de datos, un segfault, una terminación por falta de memoria. Todo lo de abajo es adivinar hasta que haya hecho esto.

2. Correlacione con «qué cambió». Ordene por cambios recientes: el último despliegue, un plugin/tema/módulo añadido o actualizado, una edición del .htaccess, credenciales de base de datos rotadas, un envío de configuración. La mayoría de los 500s se remontan a un cambio de las últimas horas o días. Si puede, revierta primero y diagnostique después: restaurar el servicio le da tiempo.

3. Confirme la visión del buscador. GSC → Page Indexing → Server error (5xx) para las URL afectadas, y después Crawl Stats → by response para ver si es un incidente pasajero o algo sostenido. Compruebe también las alertas de errores de rastreo de Bing Webmaster Tools. Esto le dice cuán urgente es el reloj del SEO.

4. Reprodúzcalo tal como lo ve el bot. Si las personas obtienen la página bien pero Googlebot recibe 500s, pruebe como bot: URL Inspection, Fetch as Bingbot o curl -A "Googlebot" <url>. Los 500s exclusivos de bots apuntan a capacidad, a reglas de firewall o de detección de bots, o a carga provocada por el rastreo: una solución distinta de la de un fallo de código.

5. Descarte por bisección a los sospechosos habituales.

• Plugins/módulos: desactívelos todos y reactívelos de uno en uno hasta que vuelva a fallar.
• Recursos: revise con su proveedor de hosting el límite de memoria de PHP, el techo de conexiones a la base de datos y la capacidad del alojamiento, sobre todo si los 500s se agrupan en torno a picos de tráfico o de rastreo.
• Configuración: revierta el .htaccess o la configuración del servidor a una versión que se sepa correcta.

6. Si el rastreo es el detonante, no se limite a absorberlo. Cuando el propio volumen de rastreo de Googlebot le está sobrecargando, la palanca temporal correcta es devolver 503/429 (con Retry-After), no dejar que el servidor emita errores 500s incontrolados. Google respeta el 503 como «vuelve más tarde» durante ~2 días; un 500 no obtiene esa gracia.

7. Verifique la recuperación. Tasa de error de nuevo por debajo de la prueba de olfato no oficial del ~1 %, registros limpios y Crawl Stats de GSC mostrando obtenciones correctas de nuevo. Las páginas retiradas suelen volver a medida que los rastreos tienen éxito: sin plazo garantizado, pero normalmente es rápido.

Patrón de escalada que conviene tener en mente: 500 ocasional → normalmente se reintenta, riesgo documentado bajo → 500 persistente → el rastreo se ralentiza → sigue persistiendo → las URL caen del índice. Google no publica los plazos exactos de estas transiciones; su trabajo es romper la cadena antes de que llegue tan lejos.

¿Qué código de servidor debería devolver?

Use esto al decidir qué devolver o al interpretar lo que está viendo.

¿El fallo es intencionado (mantenimiento o defensa deliberada frente a la sobrecarga)?

• Sí → Devuelva un 503 Service Unavailable con una cabecera Retry-After. Google lo trata como temporal y reintenta durante ~2 días. No sirva una página de error devuelta con 200 y no deje que derive en un 500.
• No (es un fallo real e inesperado) → continúe.

¿El error lo recibe todo el mundo o solo el rastreador?

• Todo el mundo → Es un problema de código, de configuración o de base de datos. Vaya a los registros de errores del servidor y a la lista de «qué cambió». Revierta los cambios recientes.
• Solo Googlebot/Bingbot → Sospeche de la capacidad, de las reglas de detección de bots o del firewall, o de la carga provocada por el rastreo. Reproduzca como un bot; revise los recursos del servidor y cualquier regla sobre bots.

¿Es una sola URL o una gran parte del sitio?

• Una sola URL / ocasional → Poca urgencia. Google reintenta; corríjalo con calma, pero confirme que está realmente aislado.
• Todo el sitio / persistente → Emergencia. Este es el patrón que hace que Google ralentice el rastreo de todo el sitio y acabe desindexando. Restaure primero el servicio (revierta) y busque la causa raíz después.

¿La tasa de error está por encima del ~1 %?

• Sí → Merece la pena investigarlo como un problema real probable: esta es la regla empírica no oficial de Mueller, no un umbral documentado de Google.
• No → Probablemente esté bien, pero siga vigilando la tendencia, no solo la instantánea.

Prompt: correlacionar un 500 con los registros y un despliegue

Diagnose this HTTP 500 incident from the sanitized evidence I provide. Build a
timeline across deployment events, request IDs, access logs, application errors,
resource signals, and affected URL patterns. Rank likely causes by evidence, separate
the fastest service-restoration action from the root-cause fix, and give exact
validation and rollback checks. Do not invent missing stack traces or thresholds.

[PASTE TIMELINE, HEADERS, LOGS, AND RECENT CHANGES]

Prompt: convertir un rastro de pila en un plan de pruebas seguro

Explain this stack trace in plain language, identify the failing component and its
inputs, and propose the smallest reversible test that distinguishes code, dependency,
configuration, and resource-exhaustion causes. Include what evidence would falsify
each hypothesis and how to confirm the URL returns a stable non-5xx response afterward.
Redact secrets and do not suggest exposing debug output publicly.

[PASTE SANITIZED STACK TRACE]

Shell: muestrear una lista de URL en busca de respuestas 5xx

Ejecute esto con una URL absoluta por línea en urls.txt.

while IFS= read -r url; do
  curl -sS -o /dev/null -w '%{http_code},%{time_total},%{url_effective}\n' "$url"
done < urls.txt

La salida separa rutas aisladas de un fallo generalizado y registra la latencia sin descargar los cuerpos de las respuestas.

PowerShell: exportar la misma muestra de códigos de estado

Get-Content .\urls.txt | ForEach-Object {
  $r = Invoke-WebRequest -Uri $_ -SkipHttpErrorCheck
  [PSCustomObject]@{ Status = $r.StatusCode; Url = $_ }
} | Export-Csv .\status-sample.csv -NoTypeInformation

Shell: contar los códigos de estado 5xx en un registro de accesos

Ajuste la posición del campo del código de estado para que coincida con el formato de registro documentado antes de fiarse del resultado.

awk '$9 ~ /^5[0-9][0-9]$/ { count[$9]++ } END { for (code in count) print code, count[code] }' access.log

Herramientas para encontrar y diagnosticar los 500s

• Registros de errores del servidor — error.log / access.log, o el visor de registros de su proveedor de hosting o plataforma. La herramienta más importante de todas; la causa real vive aquí.
• Google Search Console — Page Indexing (Informe “Indexación de páginas”) — la sección “Server error (5xx)” lista las URL en las que Google está viendo errores 500s.
• GSC — Crawl Stats report — el desglose “by response” a lo largo del tiempo separa un incidente pasajero de un problema de disponibilidad sostenido.
• GSC — URL Inspection (herramienta de inspección de URL) — obtenga una sola URL como Google para reproducir un 500 exclusivo de bots.
• Bing Webmaster Tools — sus alertas de errores de rastreo agrupan los Server Errors (5xx) y le dirigen a la herramienta Crawl Information.
• curl — reproduzca con un agente de usuario arbitrario: curl -I -A "Googlebot" <url> para ver el código de estado como lo ve un bot.
• Rastreadores y auditorías de sitios — Ahrefs Site Audit y Screaming Frog SEO Spider muestran las respuestas 5xx de todo el sitio y permiten detectar patrones (una plantilla o sección completa fallando).
• Monitorización de disponibilidad y de estado — alertas sobre las tasas de 5xx para enterarse de un pico antes que Google.

Recursos que merecen su tiempo

Mis textos relacionados

• HTTP Status Codes: A Guide to How They Impact SEO & UX — mi referencia completa de códigos de estado, incluida la definición del 500 y el encuadre más amplio del rastreo y los 5xx.
• The Beginner’s Guide to Technical SEO — dónde encajan los errores de servidor en el panorama técnico más amplio.

Mis ponencias

• How Search Works (SlideShare) — mi recorrido por el rastreo y por cómo el estado de salud del servidor retroalimenta ese proceso. (Se aplica la advertencia permanente: “This is my understanding of systems… not going to be 100% complete or accurate.” (traducción) «Esta es mi comprensión de los sistemas… no va a ser 100 % completa ni exacta.»)

Del sector

• Cómo los códigos de error 500 pueden afectar negativamente a la indexación (Search Engine Journal) — el artículo de Matt G. Southern con las citas de John Mueller sobre reintento → rastreo lento → retirada del índice y la regla empírica del ~1 %.
• Cómo corregir el error «Server error (5xx)» en Google Search Console (Search Engine Land) — un recorrido paso a paso por el informe de GSC.
• Cómo corregir el «Server error (5xx)» en Google Search Console (Onely) — qué son los errores 5xx, dónde encontrarlos en GSC y una vía de solución.
• Cómo corregir un error interno del servidor 500 en su sitio (Kinsta) — una lista de soluciones detallada y centrada en el alojamiento de WordPress (registros del servidor, plugins y temas, memoria de PHP, .htaccess, permisos).
• Errores de servidor 5xx: guía para encontrar y corregir problemas 5xx (Lumar) — un ángulo de auditoría técnica y empresarial, sólido en el encuadre del análisis de registros y del presupuesto de rastreo.
• Cómo corregir el error de servidor 5xx en Google Search Console (Sitechecker) — otra versión del recorrido por el informe de GSC.

Vídeos

• Google Search Central (YouTube) — el archivo de SEO Office Hours, de donde proceden las orientaciones de John Mueller sobre errores de servidor y rastreo (el encuadre reintento → rastreo lento → retirada del índice citado arriba). Canal

Póngase a prueba: 500 Internal Server Error

Cinco preguntas rápidas sobre qué es un 500 y cómo afecta al SEO. Elija una respuesta para cada una y después compruebe.

Registro de cambios