Cómo el hosting afecta al SEO: TTFB, CDN y la realidad del 2026

Este post lo escribí en 2013 como la tercera parte de una serie de “60 tips SEO” para principiantes. Trece años después, casi todo lo que decía es irrelevante o falso. Lo borro y empiezo de cero, porque la pregunta sigue siendo la misma — ¿afecta el hosting al SEO? — pero la respuesta correcta tiene poco que ver con TLDs, geolocalización del servidor o si tu hosting “es competente”.

Vamos por partes.

La pregunta correcta

Casi todo el contenido sobre “hosting y SEO” en castellano sigue anclado en 2013-2015. Las recomendaciones suelen ser las mismas: “.es para España”, “evita los hostings compartidos baratos”, “el uptime importa”, “huye de 1&1”. Algunas tienen un fondo de verdad, otras son directamente mitos.

La pregunta correcta no es “¿qué hosting usa la gente que rankea?”. Es: ¿qué señales técnicas mide Google y dónde puede destrozarlas tu hosting?

Hay cuatro vectores reales por los que el hosting puede arruinarte el SEO:

1. TTFB (Time To First Byte) demasiado alto.
2. Core Web Vitals que no pasan, sobre todo LCP.
3. Uptime irregular que afecta a Googlebot y a usuarios.
4. Crawl budget desperdiciado porque el servidor responde lento o con errores.

Todo lo demás — el TLD, la “localización física” del servidor, el panel de control, el espacio en disco — es ruido o factores de quinto orden. Vamos a ver cada uno con calma.

1. TTFB: el factor que realmente mueve la aguja

TTFB es el tiempo que tarda el navegador en recibir el primer byte de la respuesta del servidor desde que pide la página. Es la suma de:

• Resolución DNS
• Negociación TCP + TLS
• Tiempo que el servidor tarda en procesar la petición y devolver el primer byte

Es la métrica más directa para medir la “velocidad” del servidor en sí. Y es la única donde el hosting puede ser realmente el culpable.

Qué dice Google sobre TTFB

Google no usa TTFB como factor de ranking directo, pero sí lo usa como input de los Core Web Vitals (entra dentro de LCP) y como señal indirecta para el crawl budget. La recomendación oficial de Google es mantenerlo por debajo de 800 ms en el percentil 75 de tus visitas reales, idealmente bajo 600 ms. Por debajo de 200 ms es excelente, por encima de 1500 ms es un problema serio.

Más importante todavía: Googlebot ajusta su crawl rate en función de la respuesta del servidor. Si tu TTFB es alto y errático, Google rastrea menos. Menos crawl = más tarde se indexan tus cambios, las páginas nuevas tardan más en aparecer, y las páginas viejas se reevalúan con menos frecuencia.

Cómo medirlo de verdad

Olvídate de hacer un ping al dominio. Eso no mide nada útil. Mide TTFB en condiciones reales con estas herramientas:

• PageSpeed Insights (incluye datos del CrUX, que es el dataset oficial de Google).
• WebPageTest.org desde varias ubicaciones (es gratis y te da el desglose completo de la conexión).
• curl -w desde la línea de comandos si quieres datos crudos: curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\n" https://tudominio.com
• Search Console → Configuración → Estadísticas de rastreo → Tiempo medio de respuesta. Esto es lo que realmente ve Googlebot.

Si tu TTFB en CrUX es alto pero el tiempo medido por Googlebot en Search Console es bajo, el problema es el cliente (DNS, geografía del usuario). Si los dos son altos, el problema es el servidor.

Qué hace que el TTFB se dispare

• Servidor saturado (vecinos ruidosos en hosting compartido, o tu propio servidor sin recursos).
• Base de datos lenta o sin índices.
• Aplicación que ejecuta queries N+1, llamadas externas en cada request, render server-side sin caché.
• Falta de caché de página completa (cuando se construye HTML en cada petición).
• Conexión a la BD remota con latencia.
• Hosting físicamente lejos del usuario (para una web sin CDN delante).

Nota la jerarquía: el hosting es solo una de las causas, y rara vez la principal. La mayoría de webs WordPress lentas no tienen un problema de hosting, tienen 47 plugins, ningún caché de página, y una imagen LCP de 2 MB. Cambiar de hosting sin arreglar eso es como ponerle ruedas mejores a un coche con el freno de mano puesto.

2. Core Web Vitals y el papel del servidor

Los Core Web Vitals son tres métricas — LCP, INP y CLS — que Google usa como factor de ranking suave desde 2021. El impacto directo en posiciones es menor de lo que Google quiere que creas, pero pasar Core Web Vitals tiene efectos colaterales reales: mejor CTR, mejor experiencia de usuario, mejor tasa de conversión y mejor salud del SEO en su conjunto.

El hosting solo afecta directamente a uno de los tres: LCP (Largest Contentful Paint), porque LCP empieza a contar desde el TTFB. Si tu TTFB son 1.500 ms, tu techo de LCP en el percentil 75 es prácticamente imposible de pasar — no importa lo optimizadas que tengas las imágenes.

INP (interactividad) y CLS (estabilidad visual) son problemas de frontend, no de hosting. Cambiar de proveedor no los va a arreglar.

La regla práctica

Si tu…	El culpable suele ser…
TTFB > 800 ms	Hosting, app, BD o falta de caché de página
LCP > 2.5 s	Imagen sin optimizar, render bloqueante, o TTFB alto
INP > 200 ms	JavaScript pesado, third-party scripts, manejadores de eventos lentos
CLS > 0.1	Imágenes sin dimensiones, fonts que reflowean, ads insertados después

Solo en la primera fila el hosting puede ser parte del problema. En las otras tres, cambiar de hosting no te salva.

3. CDN y edge: la era del servidor único ha muerto

En 2013, “tu servidor está en España” era una recomendación razonable porque la mayoría de hostings servían el HTML directamente desde un único datacenter. Si tu servidor estaba en Madrid y tu visitante estaba en Barcelona, perfecto. Si estaba en California, la latencia te penalizaba.

En 2026 esa lógica ya no aplica si haces las cosas bien. La mayoría de sitios serios sirven su HTML — o al menos sus assets estáticos — desde una CDN con cientos de PoPs distribuidos por el mundo. Da igual dónde esté tu servidor de origen: el primer byte llega al usuario desde el PoP más cercano.

Las opciones reales hoy son:

• CDN delante de un origen tradicional: Cloudflare, BunnyCDN, KeyCDN, o el CDN de tu hosting. Cacheas HTML y assets en el edge. La mayoría de WordPress modernos funcionan así.
• Edge-first o serverless: Cloudflare Pages, Vercel, Netlify, Fastly Compute. El sitio entero se sirve desde el edge sin servidor de origen “fijo”. Es lo que uso yo en este blog: Astro estático en Netlify (antes Cloudflare Pages). El TTFB es ~30-80 ms desde Europa porque el HTML ya está pre-renderizado y servido desde el PoP más cercano.
• Híbrido: SSR en un origen + cache de página en el edge con purging por evento. Lo que hace WP Rocket + Cloudflare APO, o lo que monta cualquier ecommerce serio.

Lo que cambia con CDN

Cuando hay un CDN bien configurado delante, el “hosting” pasa a importar mucho menos. Lo que importa es:

• Cache hit rate: cuántas peticiones se sirven desde el edge sin tocar tu origen. Por encima del 90% es ideal para sitios mayoritariamente de contenido.
• Política de cache: que las páginas dinámicas no se cacheen mal, que las páginas públicas sí, y que las purgues cuando publicas o editas.
• Reglas de bypass: que las peticiones autenticadas (login, carrito, panel) no se cacheen.

Para sitios pequeños, Cloudflare gratis ya es suficiente para tener un CDN decente delante. Para sitios serios, vale la pena pagar por el plan Pro o usar APO si estás en WordPress — el impacto en TTFB en visitantes lejanos al origen suele ser brutal (de 800 ms a 80 ms en el primer test).

4. Uptime real

El uptime sigue importando, pero no por la razón de 2013. La idea de que “una caída de pocas horas te tira de la primera página de Google” es una exageración del marketing de hostings. Google no penaliza inmediatamente por una caída puntual.

Lo que sí pasa cuando tu servidor cae intermitentemente:

• Googlebot recibe 5xx: si pasa muchas veces, ralentiza el crawl o lo pausa. Si dura días, empieza a desindexar URLs.
• Search Console te dispara avisos de “errores del servidor” en el informe de cobertura.
• Los usuarios que estaban a punto de convertir, no convierten. Esto no es SEO, es negocio.
• Si la caída coincide con un pico de enlaces externos, pierdes el tráfico de referral y la oportunidad de capturar el momentum.

La métrica realista que deberías exigir a tu hosting es 99.9% de uptime mensual, lo que equivale a un máximo de ~43 minutos de downtime al mes. Por debajo de eso, cambia. Por encima, da igual qué te prometan los planes “premium” con 99.99% — el SLA solo te devuelve el dinero, no el tráfico perdido.

Para monitorizar uptime real, no te fíes del dashboard del hosting. Usa una herramienta externa: UptimeRobot (gratis para los básicos), Better Stack, Pingdom o lo que prefieras. Pregunta desde varias ubicaciones, no solo desde una.

5. Crawl budget y la respuesta del servidor

Esto le importa solo a webs grandes (> 10.000 URLs en el índice), pero si es tu caso, escucha. Googlebot tiene un presupuesto de crawl finito por host, y ese presupuesto se ajusta dinámicamente en función de:

• Velocidad de respuesta del servidor (TTFB de Googlebot, no de los usuarios).
• Tasa de errores (5xx, timeouts).
• Demanda de crawl (cuántas URLs nuevas o modificadas detecta).

Un hosting saturado, lento o intermitente reduce el crawl budget. Para un blog de 200 posts, da igual. Para un ecommerce con 50.000 productos, una caída del 30% en crawl rate significa que los productos nuevos tardan semanas en indexarse.

Si tienes este problema, mira en Search Console → Configuración → Estadísticas de rastreo. Si el “tiempo medio de respuesta” sube cuando suben las “solicitudes totales”, tienes un cuello de botella en el servidor. Cambiar de hosting (o escalar el actual) sí te puede solucionar esto.

Mitos del hosting y SEO que puedes ignorar tranquilamente

Después de 13 años viendo a gente repetir las mismas cosas, estos son los mitos más extendidos que ya no aplican (y muchos no aplicaban ni en 2013):

“El servidor tiene que estar físicamente en España para rankear en España”

Falso desde hace años. Google determina la geolocalización por TLD (.es, .com.es), por la etiqueta hreflang, por la declaración en Search Console y por las señales del propio contenido (idioma, moneda, direcciones, prefijos telefónicos). La IP del servidor es una señal residual y tiene cero peso si las otras están claras.

Esto se nota especialmente cuando usas un CDN: tu IP “geolocalizable” cambia según el visitante. Si Google la usase como señal fuerte, ningún sitio detrás de Cloudflare podría rankear en su país. Y rankean perfectamente.

”Tu IP compartida con webs penalizadas te penaliza”

Falso. Es el clásico “bad neighborhood” del SEO de los 2000. Google sabe que millones de webs comparten IP con webs spam (es lo que pasa en cualquier hosting compartido) y no las penaliza por ello. La excepción son bloques enteros de IPs dedicados a spam, que Google sí filtra — pero tú no estás ahí salvo que hayas comprado hosting en una proveedora muy turbia.

”Tu hosting tiene que tener mucha RAM y mucho espacio”

Estas métricas son vanidosas. Lo que importa es CPU disponible bajo carga y velocidad de I/O del disco. Un hosting con 8 GB de RAM y una CPU compartida con 200 webs vecinas va a ir peor que uno con 2 GB de RAM y vCPUs dedicadas. El espacio en disco no importa para SEO en absoluto, salvo que te quedes sin espacio y tu sitio caiga.

”El panel de control determina la calidad del hosting”

cPanel, Plesk, panel propio… Todos sirven. La calidad del hosting está en la infraestructura, no en el panel de administración. Algunos de los mejores hostings que he probado tenían paneles de control horribles, y algunos de los peores tenían cPanels preciosos.

”Cambiando de hosting voy a subir posiciones”

Probablemente no, salvo que tu TTFB actual esté por las nubes y se note en CrUX. Si tu TTFB es razonable (< 800 ms en p75) y tus Core Web Vitals están en verde o ámbar, cambiar de hosting no te va a mover ni una posición. Tu problema seguramente no es el hosting.

Qué deberías mirar al elegir hosting para SEO

Olvídate de las listas de “10 mejores hostings para SEO”. Mira esto:

1. TTFB real medido desde la geografía de tus usuarios. Pídele al hosting datos reales o monta una web de prueba antes de migrar todo.
2. Soporte técnico que sepa qué es PHP-FPM, OPcache, HTTP/2 y Brotli. Si no lo saben, fuera.
3. Uptime monitorizado con datos públicos, no con marketing. UptimeRobot público o similar.
4. Stack actualizado: PHP 8.2+, MySQL/MariaDB modernas, Nginx o LiteSpeed, HTTP/2 o HTTP/3, TLS 1.3.
5. Posibilidad de poner Cloudflare (u otra CDN) delante sin que rompan funcionalidades.
6. Backups diarios automáticos + restore fácil. No es SEO, pero el día que la cagues lo agradeces.
7. Migración asistida gratis, idealmente. El cambio no debería ser un drama.
8. Política clara de límites: que sepas cuántas peticiones, cuánto CPU, qué pasa si los superas. Los hostings “ilimitados” siempre tienen letra pequeña.

Y un bonus que casi nadie cita: lee opiniones recientes en foros, no en blogs de afiliación. Reddit, Webmaster World, los grupos de WordPress en Facebook. Ahí se ve la verdad.

El caso real de este blog

Para que veas lo lejos que ha llegado la cosa: este blog (tecnicaseo.com) es un sitio Astro estático servido desde Netlify. Coste de hosting: 0 €/mes. TTFB desde Europa: 30-80 ms. Lighthouse: 100/100 en todo. Página completa media: < 80 KB.

¿Significa eso que recomiendo Netlify para todo el mundo? No. Significa que para un blog de contenido, cualquier solución estática + edge bate a cualquier WordPress en hosting compartido, en TTFB, en Core Web Vitals, en uptime y en coste. Y casi siempre en SEO técnico.

Para WordPress moderno, mi recomendación sigue siendo un hosting gestionado decente (los hay buenos en España: Factoría Digital, SiteGround, Raiola Networks, dinahosting si controlas tú lo técnico) + Cloudflare delante (gratis o Pro) + una buena estrategia de caché de página.

Ya hablo de hostings concretos en otros sitios:

• Comparativa de hosting independiente — comparativa actualizada de los hostings que he probado y por cuáles pondría la mano en el fuego.
• Dinahosting: mi opinión sin censura — el caso concreto de uno de los más usados en España.

El resumen en cinco líneas

1. El hosting afecta al SEO solo a través de TTFB, Core Web Vitals (LCP), uptime y crawl budget. Todo lo demás es ruido.
2. TTFB bajo 800 ms en p75 es lo mínimo decente. Mídelo en CrUX y en Search Console.
3. Si pones un CDN delante, el “dónde está físicamente el servidor” deja de importar. Lo que importa es el cache hit rate del edge.
4. El uptime importa, pero no como te dijeron en 2013. 99.9% real basta.
5. La mayoría de webs lentas no tienen un problema de hosting. Tienen un problema de arquitectura encima de un hosting decente. Mide antes de migrar.

Y si después de leer esto sigues convencido de que tu problema es el hosting: mide TTFB de tus usuarios reales, mira las estadísticas de rastreo en Search Console, y ponlo todo en un documento. Si los números no te dan la razón, el problema está en otro sitio.

Mejor invertir en arreglar tu sitio que en cambiar de proveedor.