Un correo de auditoría, una línea de PageSpeed Insights o la página Estadísticas de rastreo (Crawl stats) de Search Console acaban de decirle que su servidor es lento, y ahora quiere saber si eso perjudica sus posiciones en los buscadores. Por lo general es una señal real que vale una revisión de diez minutos, y rara vez una emergencia por sí sola. El número mide cuánto tarda su servidor en enviar el primer byte de una página después de que un visitante o un rastreador la pide. Cuando esa espera crece, o cuando el servidor empieza a devolver errores, Google puede reducir cuánto de su sitio rastrea. No necesita reconstruir nada esta noche, y no necesita cambiar de host por una sola puntuación. Necesita leer bien el número, hacer dos revisiones gratuitas y saber qué entregarle a su host si el problema sigue apareciendo.
Puntos clave
El tiempo de respuesta del servidor es la espera antes de que llegue el primer byte, a menudo llamada TTFB. La guía aproximada de web.dev considera bueno un tiempo de 800 milisegundos o menos, y malo uno mayor de 1.8 segundos.
Google reduce el rastreo cuando sube la latencia, cuando se agota el tiempo de espera del servidor o cuando el servidor devuelve errores 5xx o respuestas 429. La frecuencia de rastreo no es una señal de posicionamiento, y ningún umbral de TTFB decide los posicionamientos.
Ejecute PageSpeed Insights en su página principal, y luego abra Search Console, Configuración (Settings), Estadísticas de rastreo. Los resultados lentos que se repiten en ambas cosas pesan más que una sola puntuación.
Primero el caché de páginas, luego la capacidad del host, después los plugins o el trabajo de la aplicación lentos, y por último una CDN. Un host nuevo es la respuesta solo cuando las mediciones muestran que el plan se quedó sin espacio.
¿Qué significa un tiempo de respuesta lento del servidor para su SEO?
El tiempo de respuesta del servidor es el lapso entre una solicitud y el primer byte que regresa. Antes de que una página pueda empezar a dibujarse, su servidor tiene que recibir la solicitud, construir o encontrar la página y empezar a enviarla. web.dev llama a este tiempo «time to first byte» (tiempo hasta el primer byte), o TTFB, y da una guía aproximada: 800 milisegundos o menos es bueno, más de 800 milisegundos hasta 1.8 segundos necesita mejorar, y más de 1.8 segundos es malo. Como todo lo demás espera detrás de él, un TTFB largo retrasa las mediciones posteriores, como first contentful paint y largest contentful paint.
Para el SEO, el efecto pasa por el rastreo. Google dice que su rastreador puede obtener más páginas cuando un servidor responde rápido, y que el límite de rastreo baja cuando un sitio se vuelve lento o responde con errores del servidor o señales de limitación de velocidad. En sus palabras, de la documentación sobre el presupuesto de rastreo (crawl budget): «If the site slows down, or responds with server errors or rate-limiting signals, the limit goes down and Google crawls less.» (Si el sitio se vuelve lento, o responde con errores del servidor o señales de limitación de velocidad, el límite baja y Google rastrea menos.) Google también dice que una latencia estable o en mejora puede hacer que ese límite vuelva a subir.
Eso es distinto de una penalización de posicionamiento. El rastreo no es en sí mismo una señal de posicionamiento, el TTFB no es un Core Web Vital, y no existe un umbral universal de TTFB que decida si una página se rastrea. Lo que sí puede hacer un servidor lento o que falla es retrasar que Google vea una página nueva o un cambio, y costarle visitas de personas que se van antes de que aparezca la página. Un sitio pequeño con unas pocas páginas y un servidor que casi siempre responde está en una situación muy distinta de un sitio al que se le agota el tiempo de espera del servidor varias veces al día.
¿Dónde veré el tiempo de respuesta de mi servidor y qué es un buen número?
Verá este número en dos lugares. En PageSpeed Insights aparece como la auditoría «Reduce initial server response time» (reducir el tiempo de respuesta inicial del servidor). En Search Console aparece como «average response time» (tiempo de respuesta promedio) en el informe de Estadísticas de rastreo, junto con el total de solicitudes de rastreo, los códigos de respuesta y el estado del host. Cada uno mide algo un poco distinto, así que léalos juntos en lugar de escoger el que se ve peor.
| Dónde lo ve | Qué mide | Léalo con cuidado |
|---|---|---|
| PageSpeed Insights, resultados de laboratorio | Una prueba simulada de una URL, en un dispositivo y una red | Una sola ejecución. Pruebe en móvil y en escritorio, y repita en otro día |
| PageSpeed Insights, datos de campo | Visitas reales recopiladas de usuarios de Chrome, cuando hay suficientes | Mejor evidencia de lo que reciben los visitantes, pero no aparece en páginas de poco tráfico |
| Search Console, Estadísticas de rastreo | Las propias solicitudes de Googlebot a su sitio: tiempo de respuesta promedio, códigos de respuesta y estado del host | Muestra lo que recibe el rastreador, a lo largo del tiempo, no lo que recibe un visitante |
| Registros del servidor, si su host se los da | Cada solicitud, incluidos los errores y los tiempos de espera agotados | El lugar para encontrar qué URL fallan y cuándo |
En cuanto a lo que cuenta como bueno, la guía publicada de web.dev es la que hay que usar: 800 milisegundos o menos es bueno, y más de 1.8 segundos es malo. Eso también responde la pregunta común sobre los 100 milisegundos. Una respuesta en ese rango está muy por debajo de la marca buena, así que no es algo que haya que perseguir. Es posible que todavía vea una página más antigua de Google que cita una meta de 200 milisegundos. Esa página está marcada como desactualizada y se refiere a una versión retirada de la API de PageSpeed Insights, así que no le exija a su sitio que cumpla con ella.
Algunas distinciones más evitan que los números lo confundan. El tiempo de respuesta del servidor es solo el primer byte, mientras que el tiempo de carga de la página incluye cada archivo de imagen, script y estilo que sigue, y eso es lo que cubre sitio web lento para cargar para los visitantes. Una puntuación rápida de página no demuestra que el servidor esté sano, y una ejecución de laboratorio lenta no demuestra que el rastreador tenga un problema. Para el lado de la velocidad que ven los visitantes, Core Web Vitals para pequeños negocios explica lo que Google mide en su lugar.
¿Cómo reviso mi tiempo de respuesta del servidor en diez minutos?
Dos herramientas gratuitas le dan una línea base, y anotar los números es lo que las hace útiles después. Trabaje en este orden.
- Abra PageSpeed Insights e ingrese la dirección completa de su página principal.
- Ejecute la prueba de móvil y luego la de escritorio, y anote el tiempo de respuesta del servidor o el TTFB en cada una.
- Revise si aparecen datos de campo y si coinciden con el resultado de laboratorio.
- Abra Search Console para su propiedad verificada, elija Configuración y luego Estadísticas de rastreo. El informe de Estadísticas de rastreo muestra el tiempo de respuesta promedio, el total de solicitudes de rastreo, un desglose por código de respuesta, tipos de archivo, propósito del rastreo y estado del host.
- Busque respuestas 5xx, advertencias de estado del host y una caída en las solicitudes de rastreo que coincida con días lentos.
- Si una página importante parece ser el problema, analícela con Inspección de URL y pruebe esa dirección también en PageSpeed Insights, no solo la página principal.
Una prueba lenta por sí sola no establece un problema del rastreador, y un promedio bajo en Search Console no demuestra que cada página sea rápida. La evidencia que se repite en ambas herramientas, en páginas distintas y a lo largo de varios días es la que vale la pena atender. Si también usa Search Console para sus revisiones generales de salud, Su sitio web puede estar rompiendo su propio SEO sin que usted lo note cubre los otros problemas que se esconden a plena vista.
¿Por qué su servidor responde lento y qué significa que se agote el tiempo de espera?
Un servidor se vuelve lento cuando tiene demasiado que hacer o muy poco espacio para hacerlo. web.dev señala algunas causas, y un orden práctico para revisarlas es el siguiente:
- Páginas construidas desde cero en cada solicitud: Sin caché de páginas, el servidor reconstruye la misma página pública para cada visitante y cada rastreador.
- Un plan de hosting sin espacio: La memoria insuficiente o un host sobrecargado vuelven lentas las respuestas, sobre todo cuando llegan más solicitudes al mismo tiempo de las que el plan puede manejar.
- Consultas lentas a la base de datos o código de aplicación: Las páginas que esperan consultas costosas o llamadas externas responden tarde.
- Plugins y procesamiento de terceros: En WordPress, los plugins que agregan consultas, trabajo del lado del servidor o llamadas externas pueden sumar espera. La cantidad por sí sola no es el problema, así que mida antes de quitar nada.
- Problemas de red: Los problemas de DNS, de conexión o de TLS pueden parecer un servidor lento cuando el servidor en sí está bien.
- Picos de tráfico o solicitudes abusivas: Los bots o una ráfaga de visitas pueden agotar la capacidad.
- Cadenas largas de redirecciones: Cada salto suma tiempo antes de que empiece a llegar la página final.
Este es un orden para revisar, no una clasificación de qué tan seguido ocurre cada causa. Cuando se agotó el tiempo de espera del servidor, eso es el extremo lejano del mismo problema. Significa que el servidor no respondió dentro del tiempo que el solicitante estaba dispuesto a esperar, y la solicitud termina sin ninguna página. Google trata los tiempos de espera agotados, los errores 5xx y las respuestas 429 como señales de que el servidor está en apuros, por eso pueden llevar a un rastreo menor. La guía de Google sobre solución de problemas de errores de rastreo también dice que, si su servidor está sobrecargado, un 503 o un 429 temporal es la respuesta correcta, y que no debe seguir devolviéndolos por más de unos dos días, o las URL pueden empezar a salir del índice. La guía de errores de DNS y de red cubre las fallas que ocurren antes de que se llegue siquiera al servidor.
¿Qué pasa con los rastreadores de IA, como los de ChatGPT y Claude?
Es posible que su auditoría haya marcado una respuesta lenta específicamente para los rastreadores de IA. Esos rastreadores tienen nombres que puede reconocer en los registros del servidor. OpenAI documenta OAI-SearchBot para los resultados de búsqueda de ChatGPT y GPTBot para el rastreo relacionado con el entrenamiento, cada uno controlado mediante robots.txt, y dice que un cambio en robots.txt puede tardar unas 24 horas en afectar el rastreo de búsqueda. Anthropic dice que ClaudeBot respeta las directivas estándar de robots.txt. No hay un umbral universal de velocidad para los rastreadores de IA, así que no existe un número aparte que alcanzar para ellos.
Lo que aplica a todos los rastreadores es simple. Una solicitud que agota el tiempo de espera o que regresa como error no puede devolver el contenido de su página, así que un servidor lento o inestable es un mal lugar desde donde ser leído. Corregir la causa ayuda por igual al rastreador de Google y a los rastreadores de IA. Mantener un servidor rápido no logrará por sí solo que su negocio sea citado en una respuesta de IA, y bloquear un rastreador en robots.txt no acelerará a Google. Para el lado de acceso de esta pregunta, es decir, si esos rastreadores pueden llegar a sus páginas, vea si ChatGPT y la IA de Google pueden leer su sitio web. Si la alerta vino de una herramienta que califica su visibilidad en IA, si puede confiar en una puntuación de visibilidad en IA explica cómo tomar el resto de ese informe.
¿Cómo corrijo un tiempo de respuesta lento del servidor y por dónde empiezo?
Empiece por la solución que cuesta menos y que coincide con lo que midió. Un host nuevo es el último paso, no el primero.
| Solución | Qué hace | Cuándo ayuda | Esfuerzo típico |
|---|---|---|---|
| Caché de páginas | Sirve una copia almacenada de una página pública en lugar de volver a construirla | Páginas que son iguales para todos los visitantes | Pequeño a mediano. Pruebe formularios, carritos e inicios de sesión |
| Encabezados de caché y solicitudes condicionales | Permite que los rastreadores reciban un 304 Not Modified cuando nada cambió | Páginas que casi no cambian | Pequeño a mediano |
| Limpieza de plugins y temas | Quita el trabajo que el servidor hace en cada solicitud | Sitios de WordPress con plugins pesados o llamadas externas | Pequeño a mediano. Mida cada cambio |
| Más capacidad de hosting | Le da al sitio más memoria y espacio de procesamiento | Las mediciones muestran que el plan se queda sin espacio una y otra vez | Mediano si hay que mudarse |
| CDN | Sirve contenido en caché desde una ubicación más cercana al solicitante | Visitantes repartidos lejos de su servidor, y páginas en su mayoría almacenables en caché | Mediano. No corregirá el trabajo lento sin caché en su servidor de origen |
| Correcciones de base de datos y código | Quita consultas lentas o llamadas externas | Una función o página lenta, con una causa clara en los registros | Mediano a grande |
La razón de ese orden es que cada solución apunta a un cuello de botella distinto, y la equivocada cuesta dinero sin cambiar el número. web.dev menciona el caché de borde de una CDN, la compresión y los edge workers como formas de reducir el TTFB, y menciona la memoria insuficiente y el hosting sobrecargado como causas de respuestas lentas. Google recomienda que los servidores acepten solicitudes condicionales y devuelvan un 304 Not Modified cuando el contenido no ha cambiado, lo que describe el estándar de caché HTTP de la RFC 9111. Una CDN ayuda más cuando la página se puede guardar en caché. No rescatará una página que debe generarse de nuevo en cada solicitud.
Así que, antes de pagar por algo, vuelva a medir después de cada cambio y conserve los números anteriores. Si administra el sitio usted mismo, puede que sea un fin de semana de trabajo. Si forma parte habitual de la operación de su sitio, el mantenimiento de sitios web continuo es donde suelen vivir las reglas de caché, las actualizaciones de plugins y el monitoreo, así que una semana lenta se detecta antes de que Search Console la muestre. Para una mirada más larga a lo que el plan debería ofrecer, cómo elegir hosting para un pequeño negocio revisa las opciones.
¿Cuándo un host nuevo es la respuesta correcta y cuándo puede esperar?
Cambie de host cuando la evidencia apunte a eso: se alcanzan una y otra vez los límites de CPU, memoria o conexiones, los errores 5xx o los tiempos de espera vienen del propio servidor y no de una sola página mala, y el caché y la limpieza no han bajado los números. En ese punto, entregue al host o al desarrollador los detalles en un solo mensaje: las URL afectadas, el rango de tiempo, sus números de PageSpeed Insights y de Estadísticas de rastreo, cualquier evidencia de errores 5xx, 429 o de que se agotó el tiempo de espera del servidor, y qué cambió en el tráfico o en el rastreo. Así podrán revisar la capacidad, la carga de la base de datos, el caché y los registros del servidor con algo concreto que comprobar.
Normalmente puede esperar cuando sus páginas importantes cargan, Search Console no muestra ningún problema de disponibilidad del host, no se repite ningún patrón de respuestas 5xx o de tiempos de espera agotados, solo una ejecución de laboratorio se vio lenta, y el sitio es lo bastante pequeño como para que Google tenga poco que volver a rastrear. Cambiar de host por una sola prueba sintética puede costarle una migración y no arreglar nada, ya que mejorar el hosting no ayuda cuando la lentitud viene de trabajo de aplicación sin caché, de un plugin, de una llamada externa o de una cadena de redirecciones. Las revisiones gratuitas de arriba, repetidas durante unas pocas semanas, le dirán en cuál situación está.
¿Sabe leer su tiempo de respuesta del servidor?
Elija una respuesta para empezar.
1. ¿Qué rango de TTFB de web.dev cuenta como bueno?
2. ¿Qué puede hacer Google cuando su servidor se vuelve lento o devuelve errores 5xx o 429?
3. Su prueba de PageSpeed Insights muestra una respuesta lenta del servidor y Search Console se ve sana. ¿Cuál es el mejor siguiente paso?
Preguntas frecuentes sobre el tiempo de respuesta lento del servidor y SEO
¿El tiempo de respuesta lento del servidor perjudica el SEO?
Puede hacerlo. Google reduce el rastreo cuando sube la latencia, cuando se agota el tiempo de espera del servidor o cuando devuelve errores 5xx o respuestas 429, lo que puede retrasar que se vean las páginas nuevas. No es una penalización automática de posicionamiento.
¿Cuál es un buen tiempo de respuesta del servidor?
La guía aproximada de web.dev considera bueno un tiempo de 800 milisegundos o menos, y malo uno mayor de 1.8 segundos. Una respuesta de 100 milisegundos está muy por debajo de la marca buena. El TTFB no es un Core Web Vital.
¿Qué significa que se agotó el tiempo de espera del servidor?
El servidor no respondió dentro del tiempo que el solicitante estaba dispuesto a esperar, así que la solicitud terminó sin una página. Los tiempos de espera agotados repetidos, los errores 5xx y las respuestas 429 son señales para Google de que el servidor está en apuros.
¿El tiempo de respuesta del servidor es lo mismo que el tiempo de carga de la página?
No. El tiempo de respuesta del servidor es la espera hasta el primer byte. El tiempo de carga de la página incluye todo lo que sigue, como imágenes, scripts y estilos. Un primer byte lento retrasa el resto, pero uno rápido no garantiza una página rápida.
¿Una CDN corrige el tiempo de respuesta lento de su servidor?
Puede hacerlo con el contenido que sirve desde una caché más cercana al solicitante. No corregirá el trabajo lento en su servidor de origen para páginas que no se pueden guardar en caché, así que encuentre la causa antes de comprar una.
¿Dónde encuentro mi tiempo de respuesta promedio en Search Console?
Abra Search Console, elija Configuración y luego Estadísticas de rastreo. El informe muestra el tiempo de respuesta promedio junto con los códigos de respuesta y el estado del host.
Reflexiones finales
Un tiempo de respuesta lento del servidor importa para el SEO sobre todo porque puede hacer que Google rastree menos y que los visitantes esperen más. La guía de web.dev es de 800 milisegundos o menos, un resultado lento no es por sí solo una penalización de posicionamiento, y los rastreadores de IA no tienen un objetivo de velocidad aparte. El camino a seguir es el mismo para todos: ejecute PageSpeed Insights, lea las Estadísticas de rastreo, confirme que el patrón se repite y corrija la causa en orden, desde el caché hasta la capacidad, los plugins y una CDN.
Cuando los números se asienten, deja de preguntarse si el próximo correo de auditoría es un problema real, y una página nueva se ve más pronto. También tendrá un mensaje claro para entregarle a un host o a un desarrollador si algo sí se rompe.
Si prefiere que alguien lea la evidencia con usted, Web Leveling puede revisar su configuración de hosting web, averiguar de dónde viene la espera y decirle si un plan nuevo no es lo que necesita. Nuestro equipo también puede preparar una línea base para que vea si un cambio ayudó. Cuéntenos qué marcó su auditoría en nuestra página de contacto, y empezaremos con las revisiones gratuitas. Trabajamos con pequeños y medianos negocios en todo el país y en el extranjero.
Términos clave
Términos de tiempo de respuesta en este artículo
Toque un término para ver qué significa.
TTFB. Time to first byte, el tiempo de espera entre una solicitud y la llegada del primer byte de la respuesta desde el servidor.
Tiempo de respuesta del servidor. Cuánto tarda un servidor en empezar a responder una solicitud. Search Console informa su promedio para las solicitudes de Googlebot.
Estadísticas de rastreo (Crawl stats). Un informe de Search Console que muestra cómo Googlebot solicita su sitio, incluido el tiempo de respuesta promedio y el estado del host.
Error 5xx. Un error del lado del servidor, como 503 Service Unavailable, que le dice al solicitante que el servidor no pudo hacer el trabajo.
Respuesta 429. Un código HTTP que le dice al solicitante que envió demasiadas solicitudes y debe bajar el ritmo.
CDN. Una red de entrega de contenido que sirve copias en caché de un sitio desde ubicaciones más cercanas al solicitante.
Caché de páginas. Guardar una copia construida de una página pública para que el servidor pueda enviarla de nuevo sin volver a construirla.
