Actualizado el 19 de agosto de 2026 · Escrito y verificado por Josué Pérez Suay, CEO de OrbitaClick
El hosting no «mejora» tu SEO. Lo que hace un hosting malo es ponerte un techo del que no puedes salir por contenido.
1. El número que hay que mirar es el TTFB. Google fija el umbral en 800 ms o menos para considerarlo bueno, entre 800 ms y 1,8 s «necesita mejorar» y por encima de 1,8 s deficiente. No es una Core Web Vital, pero es la base sobre la que se construye el LCP: si el servidor tarda un segundo en contestar, ya no llegas a un LCP de 2,5 s por mucho que optimices imágenes.
2. Google rastrea menos si tu servidor va mal. Lo dice literalmente: si el sitio se ralentiza o responde con errores 5xx o con señales de limitación como el HTTP 429, «el límite baja y Google rastrea menos». Y al contrario: si responde de forma consistente y el TTFB se mantiene o mejora, «el límite sube».
3. Lo que se agota no son las visitas: son los procesos PHP simultáneos. Es la causa número uno de webs que «se caen» con poco tráfico.
4. La fiabilidad se paga una vez y se cobra siempre: uptime, backups diarios restaurables y un soporte que responda una persona. Un incidente de 6 horas en Black Friday cuesta más que tres años de diferencia de plan.
Decisión rápida: si tu TTFB en móvil supera 800 ms de forma sostenida y ya has descartado plugins y caché, el problema es el plan o el proveedor, no tu web.
El hosting es la decisión SEO más invisible y, a la vez, más determinante que vas a tomar. Puedes tener el mejor contenido y una arquitectura impecable, pero si tu servidor responde lento o falla, Google lo detecta antes que tus clientes.
Y aquí está el problema de fondo: casi nadie elige hosting mirando datos. Se elige por precio, por recomendación de un foro o porque «venía incluido». Esta guía va de los cuatro factores que sí se pueden medir, con los umbrales que publica Google y no los que te diga un comparador afiliado.
Qué mide Google en tu servidor (y qué no)
Conviene separar mito de documentación. Google no publica una métrica llamada «calidad del hosting». Lo que sí hay son dos mecanismos documentados donde tu servidor entra directamente en juego.
1. Las Core Web Vitals, que dependen del servidor más de lo que parece
| Métrica | Umbral «bueno» | Cuánto depende del hosting |
|---|---|---|
| LCP (Largest Contentful Paint) | ≤ 2,5 s | 🔴 Mucho. El TTFB es la primera porción del LCP: si el servidor consume 1 s, te quedan 1,5 s para todo lo demás |
| INP (Interaction to Next Paint) | ≤ 200 ms | 🟡 Medio. Es sobre todo JavaScript en el navegador, pero un backend lento en llamadas AJAX lo empeora |
| CLS (Cumulative Layout Shift) | ≤ 0,1 | 🟢 Poco. Es maquetación, no servidor |
| TTFB (diagnóstica, no es Core Web Vital) | ≤ 800 ms | 🔴 Casi todo. Es la métrica del hosting |
Google es explícito en que el TTFB no es una Core Web Vital y que «no es absolutamente necesario que los sitios cumplan el umbral de TTFB bueno». Pero también lo describe como una métrica fundacional que precede a las demás. Traducido: nadie te penaliza por el TTFB en sí, te penaliza el LCP que no puedes arreglar por su culpa.
2. La tasa de rastreo, que Google ajusta según la salud de tu servidor
Esta parte está documentada de forma inequívoca. Sobre qué ocurre cuando el servidor va mal: «Si el sitio se ralentiza (la latencia aumenta o los tiempos de respuesta se alargan), o responde con errores de servidor (códigos 5xx) o señales de limitación de velocidad (como el HTTP 429), el límite baja y Google rastrea menos».
Y sobre qué ocurre cuando va bien: «Si el sitio responde de forma consistente y sus tiempos de respuesta (incluida la latencia y el Time-to-First-Byte) se mantienen estables o mejoran, el límite sube», lo que significa más conexiones disponibles para rastrear.
🎯 Por qué esto importa más de lo que parece. Si publicas contenido nuevo y tu servidor va justo, Google tarda más en descubrirlo. No es que te posicione peor: es que llega más tarde a saber que existes. En un blog con publicación semanal esto es un retraso constante y silencioso.
Clave 1. TTFB: el número que decide todo lo demás
El TTFB es el tiempo que pasa desde que el navegador pide la página hasta que recibe el primer byte de respuesta. Dentro de ese tiempo cabe la resolución DNS, el establecimiento de conexión y TLS, y —lo importante— el trabajo del servidor: PHP ejecutándose, consultas a la base de datos y generación del HTML.
| TTFB | Valoración de Google | Qué significa para ti |
|---|---|---|
| ≤ 800 ms | ✅ Bueno | El servidor no es tu cuello de botella. Optimiza contenido y front-end |
| 800 ms – 1,8 s | ⚠️ Necesita mejorar | Estás gastando en el servidor tiempo que necesitas para el LCP |
| > 1,8 s | ❌ Deficiente | Ninguna optimización de imágenes te va a salvar. El problema está detrás |
Cómo saber si el TTFB alto es culpa del hosting o tuya
Es la pregunta clave, porque la respuesta cambia la factura. Un método rápido:
- Mide la home cacheada y una URL imposible de cachear (por ejemplo, la home con un parámetro aleatorio detrás). Si la primera va rápida y la segunda va lenta, tu caché tapa el problema pero el servidor es lento generando páginas.
- Repite la medición a distintas horas, incluida la hora punta. Un TTFB que se dispara por la tarde en un plan compartido apunta a vecinos ruidosos o a límites de recursos.
- Desactiva plugins en un entorno de pruebas, no en producción. Si con un WordPress limpio el TTFB sigue alto, el problema es el servidor.
- Mira los datos de campo, no solo de laboratorio. El percentil 75 de los últimos 28 días en Search Console es lo que Google usa; una medición puntual con tu fibra no representa a tus usuarios.
- Comprueba la ubicación del servidor. Si tu público es de Alicante y tu servidor está en Estados Unidos, arrastras latencia física en cada petición.
Clave 2. Los recursos reales del plan, no los «ilimitados»
Aquí es donde más gente se equivoca al comparar. La cifra que se anuncia (espacio en disco, «transferencia ilimitada») casi nunca es la que te limita. Lo que te limita son los recursos de ejecución.
| Recurso | Qué es | Qué pasa cuando se agota |
|---|---|---|
| Procesos PHP simultáneos | Cuántas peticiones dinámicas puede atender tu web a la vez | 🔴 La causa nº1 de webs «caídas». Las peticiones esperan en cola y acaban en error o timeout |
| Memoria por proceso | RAM disponible para cada ejecución de PHP | Pantalla en blanco o error crítico en páginas pesadas, imports o backups |
| Entradas/salidas de disco (I/O) | Velocidad de lectura y escritura | Todo se ralentiza sin que nada dé error: el peor escenario para diagnosticar |
| Conexiones a la base de datos | Consultas simultáneas permitidas | Errores de conexión intermitentes en horas punta |
| Espacio en disco | Lo único que casi siempre sobra | Es lo que se anuncia y lo que menos importa |
Lo desarrollamos con detalle, incluidas las señales concretas para detectarlo, en cómo se satura una página web en WordPress y cómo evitarlo.
Por qué la caché cambia por completo la ecuación. Una página servida desde caché no ejecuta PHP: se entrega un HTML ya generado.
Con caché de página bien montada, la mayoría de visitas anónimas no consumen procesos PHP. Sin caché, cada visita compite por ellos.
Por eso una web con caché aguanta un pico de tráfico en un plan modesto, y la misma web sin caché se cae. Y por eso una tienda online, donde carrito y checkout no se pueden cachear, necesita más recursos reales que un blog con el mismo tráfico.
La caché no sustituye a un buen servidor: reduce cuántas veces lo necesitas.
Clave 3. La pila del servidor
No hace falta ser sysadmin, pero sí saber preguntar tres cosas antes de contratar.
| Elemento | Qué preguntar | Por qué importa |
|---|---|---|
| Servidor web | ¿Apache, Nginx o LiteSpeed? | LiteSpeed trae su propia caché a nivel de servidor, más rápida que cualquier caché en PHP. Nginx rinde muy bien con configuración adecuada |
| Versión de PHP | ¿Qué versiones ofrecéis y puedo cambiarla yo? | Cada rama moderna de PHP rinde mejor que la anterior. Quedarse en una versión sin soporte es un problema de rendimiento y de seguridad |
| Caché de objeto | ¿Hay Redis o Memcached disponible? | Cachea consultas a base de datos. En WooCommerce o webs con muchas consultas, la diferencia es notable |
| Protocolo | ¿HTTP/2 y HTTP/3? | Reducen latencia con muchos recursos. HTTP/3 mejora especialmente en redes móviles inestables |
| Ubicación | ¿Dónde está físicamente el centro de datos? | Si tu público es español y el servidor está en otro continente, pagas latencia en cada petición |
| CDN | ¿Incluida o de pago aparte? | Acerca los archivos estáticos al usuario. No arregla un TTFB alto de HTML dinámico, pero ayuda al resto |
🔧 Nuestro stack, por transparencia. En OrbitaClick montamos los proyectos WordPress sobre hosting con LiteSpeed y caché de página, con WP Rocket para el resto de optimización de front-end. No es la única combinación válida; es la que nos da resultados consistentes y la que sabemos diagnosticar rápido cuando algo va mal. Lo importante no es copiar el stack: es exigir que el tuyo cumpla los umbrales.
Un buen hosting te da el techo; quien lo aprovecha o lo desperdicia es el mantenimiento que hay encima. Si quieres que actualizaciones, copias y monitorización dejen de depender de acordarse, eso es lo que hace nuestro mantenimiento web WordPress.
Clave 4. Fiabilidad: uptime, backups y soporte
Esta es la clave que nadie valora hasta que la necesita, y la que más dinero cuesta cuando falta.
- Uptime medido, no prometido. Todos anuncian 99,9%. Monta tu propia monitorización externa y tendrás el dato real, que además te avisa antes de que te avise un cliente.
- Backups diarios y, sobre todo, restaurables. Un backup que no has restaurado nunca es una hipótesis. Prueba la restauración una vez al año como mínimo.
- Backups fuera del mismo servidor. Si el backup vive en la misma máquina que se ha comprometido, no tienes backup.
- Soporte con personas y con horario real. En una incidencia crítica —web caída, checkout roto, hackeo— la diferencia entre resolver en una hora o en un día es quién contesta al otro lado.
- Entorno de pruebas (staging). Actualizar plugins directamente en producción es la forma más habitual de romper una web que funcionaba.
- Accesos completos. Debes ser dueño de tu hosting, tu dominio y tu código. Si no puedes irte cuando quieras, no es tu web.
⚠️ Cuidado con los sistemas anti-bot mal configurados. Algunos hostings incorporan protección anti-bot que puede llegar a devolver una página de comprobación a rastreadores legítimos. Si eso ocurre y además se sirve con un código 200 en lugar de un 503, Google puede llegar a indexar la página de comprobación en vez de tu contenido. Es un problema poco frecuente pero muy caro: vale la pena verificar cómo responde tu web a Googlebot.
Qué tipo de hosting necesitas de verdad
| Tipo | Para quién | Riesgo principal |
|---|---|---|
| Compartido básico | Web corporativa pequeña, poco tráfico, sin tienda | Recursos escasos y vecinos ruidosos. Se te queda pequeño antes de lo que crees |
| Compartido de calidad con LiteSpeed | La mayoría de PYMEs con web y blog | Ninguno grave si el plan tiene procesos PHP suficientes |
| WordPress gestionado | Quien no quiere tocar nada de servidor y valora el soporte especializado | Precio y, en algunos, restricciones de plugins |
| VPS | Tiendas con volumen o proyectos con requisitos concretos | Necesita administración. Un VPS sin mantener es peor que un compartido bueno |
| Cloud escalable | Picos muy marcados (campañas, lanzamientos, estacionalidad) | Coste variable difícil de prever y complejidad de configuración |
Señales de que tu hosting te está costando dinero
- El TTFB en datos de campo supera los 800 ms de forma sostenida y ya has descartado plugins y caché.
- La web va bien de mañana y mal por la tarde. Patrón clásico de límite de recursos compartidos.
- Errores 5xx intermitentes en Search Console o en tu monitorización. Cada uno de ellos es una señal directa para que Google rastree menos.
- El escritorio de WordPress va lento incluso sin visitas. El backend no se cachea: es el termómetro más honesto de tu servidor.
- Los backups tardan horas o fallan. Síntoma de I/O saturado.
- Cada actualización da miedo porque no hay entorno de pruebas ni forma rápida de volver atrás.
Los KPI que hay que vigilar
| KPI | Dónde se mide | Objetivo |
|---|---|---|
| TTFB en datos de campo | PageSpeed Insights (datos CrUX), percentil 75 | ≤ 800 ms |
| LCP en móvil | Search Console → Core Web Vitals | ≤ 2,5 s |
| Errores 5xx y tiempo de respuesta | Search Console → Estadísticas de rastreo | Cero 5xx, respuesta estable |
| Uptime real | Monitorización externa propia | Sin caídas no explicadas |
| Páginas rastreadas al día | Search Console → Estadísticas de rastreo | Estable o al alza tras publicar |
| Tiempo de restauración de un backup | Prueba manual anual | Que exista un número, no una promesa |
📈 Orden de trabajo recomendado. Antes de cambiar de proveedor: mide el TTFB de campo, revisa la caché, comprueba la versión de PHP y descarta plugins problemáticos en staging. Si después de eso el TTFB sigue por encima de 800 ms, ya tienes el argumento para migrar con datos y no por intuición. Y si el problema es de front-end y no de servidor, la palanca está en otro sitio: lo explicamos en Core Web Vitals reales.
Errores que vemos una y otra vez
| Error | Por qué duele | Arreglo |
|---|---|---|
| Elegir por espacio en disco | Es el recurso que menos limita. Los procesos PHP son los que te tumban | Preguntar por procesos PHP simultáneos y memoria por proceso |
| Tienda online en el plan más básico | Carrito y checkout no se cachean: consumen PHP en cada petición | Dimensionar por peticiones no cacheables, no por visitas |
| Servidor lejos del público objetivo | Latencia física en cada petición, imposible de optimizar | Centro de datos cercano al mercado principal |
| Sin caché de página | Cada visita ejecuta PHP y consulta la base de datos | Caché a nivel de servidor y, encima, optimización de front-end |
| PHP en una versión sin soporte | Rendimiento peor y riesgo de seguridad conocido | Actualizar en staging y luego en producción |
| Backups solo en el propio servidor | Un incidente que afecta a la máquina se lleva también la copia | Copia externa y prueba de restauración |
| Migrar sin plan de redirecciones | Se pierden URLs y con ellas el posicionamiento | Mapa de URLs y 301 uno a uno antes de tocar nada |
| No monitorizar nada | Te enteras de las caídas por un cliente | Monitorización externa con aviso inmediato |
Si estás valorando un cambio de proveedor, el riesgo no está en el servidor nuevo: está en la migración. Los puntos que sí hay que blindar los detallamos en el coste oculto de una migración web mal hecha.
Preguntas frecuentes sobre hosting y SEO
¿El hosting influye en el posicionamiento en Google?
Sí, pero de forma indirecta. Google no puntúa tu proveedor de hosting. Lo que ocurre es que un servidor lento empeora el LCP, que sí es una Core Web Vital, y que un servidor con errores 5xx o latencia creciente hace que Google reduzca la tasa de rastreo: la propia documentación dice que en esos casos «el límite baja y Google rastrea menos». Un buen hosting no te sube posiciones por sí solo; un hosting malo te pone un techo.
¿Cuál es un TTFB aceptable?
Google considera bueno un TTFB de 800 ms o menos, «necesita mejorar» entre 800 ms y 1,8 segundos, y deficiente por encima de 1,8 segundos. Mídelo con datos de campo (percentil 75 de los últimos 28 días), no con una prueba puntual desde tu conexión.
¿Es mejor un hosting compartido o un VPS para SEO?
Depende del proyecto, no del SEO. Un hosting compartido de calidad con caché a nivel de servidor rinde mejor que un VPS mal administrado, y para la mayoría de webs corporativas y blogs es suficiente. El VPS tiene sentido cuando el volumen de peticiones no cacheables lo justifica: tiendas con tráfico, áreas privadas, aplicaciones. Si nadie va a administrar ese VPS, no lo contrates.
¿Importa dónde está el servidor si mi público es de España?
Sí. La distancia física entre el usuario y el servidor añade latencia en cada petición, y esa latencia entra dentro del TTFB. Una CDN acerca los archivos estáticos, pero el HTML dinámico se sigue generando donde esté el servidor. Si tu mercado es español, un centro de datos en España o en Europa occidental te ahorra tiempo que después no tienes que recuperar optimizando.
¿Una CDN sustituye a un buen hosting?
No. Una CDN distribuye archivos estáticos (imágenes, CSS, JavaScript) y ayuda mucho con ellos, pero el HTML de una página dinámica lo sigue generando tu servidor. Si el TTFB es alto porque PHP tarda en construir la página, la CDN no lo arregla. Son complementarios, no alternativos.
¿Cada cuánto debo revisar el rendimiento del hosting?
Los datos de campo, mensualmente: es un vistazo de dos minutos en Search Console. Y siempre después de tres momentos concretos: una actualización grande de plugins o tema, un cambio de plantilla, y un pico de tráfico por campaña. Son los tres escenarios en los que un plan que iba bien se queda corto.
¿Qué hago si mi web se cae en las horas de más tráfico?
Es el síntoma clásico de agotamiento de procesos PHP simultáneos. El orden correcto es: primero comprobar que la caché de página funciona de verdad para visitas anónimas, después revisar qué está consumiendo procesos (bots agresivos, plugins que hacen peticiones, cron mal configurado), y solo entonces ampliar recursos. Ampliar el plan sin diagnosticar suele significar pagar más por el mismo problema.
¿Cambiar de hosting me puede hacer perder posiciones?
El cambio de servidor en sí no debería afectar si el dominio y las URLs no cambian. Lo que sí hace perder posiciones es una migración mal ejecutada: URLs que cambian sin redirección 301, contenido que se queda atrás, un entorno nuevo indexable por error, o un periodo de caídas durante la propagación. Con un mapa de URLs previo y verificación posterior, el riesgo es bajo.
📚 Fuentes consultadas
- web.dev — Time to First Byte (TTFB) (umbrales de 800 ms y 1,8 s; TTFB no es Core Web Vital pero precede al LCP)
- Google Search Central — Gestión del presupuesto de rastreo (el límite de rastreo baja con errores 5xx, HTTP 429 y latencia creciente; sube si el TTFB se mantiene o mejora)
- web.dev — Web Vitals (umbrales de LCP, INP y CLS)
¿Te miramos el servidor con datos en la mano?
Medimos tu TTFB de campo, revisamos qué está consumiendo recursos, comprobamos si la caché funciona de verdad y te decimos si el problema es tu web o tu plan. Si toca migrar, lo hacemos con mapa de URLs y verificación posterior. Y si no toca, te lo decimos igual.
Josué Pérez Suay, CEO y fundador de OrbitaClick, agencia de marketing digital en Alicante desde 2018. Especializado en WordPress, rendimiento web y SEO técnico. Citado en 25 artículos de Computer Hoy como fuente experta.
