Hosting y SEO: cómo elegir un servidor rápido

El hosting y SEO es una relación mal explicada: ningún proveedor te sube posiciones porque sí, pero un servidor lento o que devuelve errores 5xx puede frenar el rastreo de Google y arruinar tus Core Web Vitals.

Aquí verás qué decide de verdad el hosting, qué soportan los rastreadores de Google, cómo medirlo con herramientas que ya tienes y una checklist de 12 puntos para contratar o migrar sin sustos.

Qué decide el hosting y SEO en los resultados (y qué no)

Lo que no importa: el proveedor, la marca y el tipo de plan no son factores de ranking. Google no hace nada especial por alojar un sitio en su propia nube y el hosting compartido no penaliza por sí mismo.

Lo que sí importa son cuatro vectores medibles:

Disponibilidad: errores 5xx, 429 y timeouts. Un servidor caído durante una ventana de rastreo es tráfico que no se descubre.
Tiempo de respuesta: el TTFB arrastra al LCP y con él a las Core Web Vitals.
Capacidad de servir bytes: si el servidor va ahogado, Google baja la frecuencia de rastreo.
Caché y protocolos: cómo se entrega el HTML que Google descarga (ETag, compresión, HTTP/2).

La ubicación del servidor no te geolocaliza

Mudar el servidor a otro país para posicionar allí es un mito: la ubicación física no se usa para geotargeting. Para eso están el dominio de país o la configuración de país en Search Console (ver web multilingüe).

Lo que sí se nota es la latencia, que entra en la experiencia de página y se corrige con una CDN delante. Al detectar un cambio de hosting, Google reduce el rastreo por precaución y lo recupera después: es un freno temporal, no una penalización.

Disponibilidad: 5xx, 429 y por qué Google te rastrea menos

Los errores 5xx y los 429 ralentizan el rastreo, porque Google interpreta que tu infraestructura sufre. Las URLs ya indexadas se conservan al principio, pero acaban descartándose si el error persiste; al volver los 2xx, el rastreo sube de forma gradual. En un error 500, el descenso es proporcional al número de URLs afectadas.

El informe de Estadísticas de rastreo de Search Console resume la disponibilidad de los últimos 90 días con el estado del host, aunque solo existe en propiedades de nivel raíz. Devolver 500 o 503 para frenar a Google es una medida de emergencia: afecta a todo el hostname y no debería durar más de uno o dos días.

Sobre 30 días, un uptime del 99,9 % equivale a unos 43 minutos caído al mes, el 99,95 % a unos 22 y el 99,99 % a unos 4. Con esas cifras, la monitorización externa con alertas deja de ser un lujo.

Tiempo de respuesta: los dos números que conviene memorizar

Dos números para memorizar: 600 ms, el umbral del audit de tiempo de respuesta de Lighthouse, y 0,8 segundos, la referencia de TTFB que recomienda web.dev para la mayoría de sitios, medida en el percentil 75 (por encima de 1,8 s se considera mala).

Esto es SEO puro: el TTFB es la base del LCP (umbral oficial 2,5 s) y con un servidor lento ninguna optimización de imágenes te salva, porque el cuello de botella está en el origen. El desglose está en la guía de TTFB.

Qué recursos mirar antes de contratar

CPU y workers: los planes con límites estrictos se quedan sin procesos en los picos y empiezan a responder 503.
RAM y caché de objetos: sin memoria, cada visita golpea la base de datos.
Disco: NVMe o SSD con IOPS suficientes; un disco saturado se nota en el TTFB de las páginas dinámicas.
Base de datos: si comparte servidor, compite por los mismos recursos; separarla es de las mejoras más rentables.
Escalado: elige el plan que aguanta el doble de tu pico, no el que aguanta tu media.

Caché: la palanca más barata para bajar el TTFB

Tres capas, de mayor a menor impacto: la caché de página completa en el origen (el visitante recibe HTML ya generado y la aplicación no se ejecuta), la caché de objetos para consultas repetidas y el OPcache, que evita recompilar el código en cada petición. La primera es la diferencia entre 40 ms y 600 ms de TTFB.

Dato oficial poco conocido: Google solo soporta caché HTTP vía ETag con If-None-Match y Last-Modified con If-Modified-Since, y recomienda ETag porque no arrastra problemas de formato de fecha. Un 304 correcto ahorra ancho de banda en cada re-rastreo, y ajustar Cache-Control: max-age a la frecuencia real de cambio ayuda a decidir cuándo volver.

Protocolos y compresión: qué soporta Googlebot de verdad

Los rastreadores de Google soportan HTTP/1.1 y HTTP/2 y por defecto usan HTTP/1.1. Rastrear por HTTP/2 ahorra CPU y RAM a tu servidor, pero no da ninguna ventaja de posicionamiento; si algo se rompe se puede devolver 421 para pedir que no se rastree por esa versión. HTTP/3 es excelente para usuarios reales, pero no está en la lista de protocolos soportados por los rastreadores. En compresión aceptan gzip, deflate y Brotli, así que servir HTML sin comprimir es regalar tiempo de respuesta.

Puedes comprobarlo desde la terminal, sin instalar nada:

curl -sI https://tu-dominio.com | head -20 muestra la versión de protocolo, el content-encoding y el etag.
curl -sI --http2 https://tu-dominio.com confirma que se negocia HTTP/2.
Si no ves content-encoding, el servidor no está comprimiendo el HTML.

El límite de 2 MB: por qué tu HTML debería pesar mucho menos

Googlebot descarga solo los primeros 2 MB de cada URL HTML, y ese corte incluye las cabeceras HTTP. En PDFs el límite es de 64 MB y el valor por defecto para el resto de rastreadores, 15 MB. Lo que queda por debajo no se rastrea, no se renderiza y no se indexa.

De ahí la regla de oro: lo importante va arriba. Título, metas, canonical y datos estructurados deben estar en el head, no empujados hacia abajo por cientos de kilobytes de CSS en línea o imágenes en base64. Mover ese peso a archivos externos ayuda doble, porque cada recurso tiene su propio contador de bytes.

Cómo saber si tu hosting te está frenando (sin herramientas de pago)

Search Console: en Estadísticas de rastreo, mira el tiempo medio de respuesta, el estado del host y la tabla de respuestas. Si el tiempo sube y las solicitudes caen, el problema es de infraestructura.
Logs del servidor: separa las peticiones de Googlebot por código y duración y verifica las IPs con DNS inverso, como explica la guía de análisis de logs.
PageSpeed Insights: si el diagnóstico señala el tiempo de respuesta del servidor y el resto de oportunidades están bien, el cuello de botella es el hosting.
Síntomas típicos: TTFB alto solo en páginas dinámicas apunta a base de datos lenta; picos a la misma hora, a copias de seguridad comiendo disco; 502 y 503 intermitentes en picos, al límite de workers del plan.
Umbral de decisión: si con caché de página el TTFB sigue por encima de 0,8 s en el percentil 75, el plan se quedó corto. Sube de plan antes de cambiar de proveedor.

Un servidor rápido y sin errores es, al final, la forma más barata de aprovechar mejor el presupuesto de rastreo.

Checklist: 12 puntos antes de contratar o migrar

Uptime histórico publicable y acuerdo de nivel de servicio por escrito.
TTFB medible desde tu región objetivo antes de pagar.
HTTP/2 y TLS 1.3 activos; HTTP/3 como extra para usuarios.
Compresión Brotli o gzip a nivel de servidor.
Posibilidad de activar caché de página en el origen.
OPcache y caché de objetos incluidos en el plan.
Recursos explícitos: CPU, RAM, IOPS y workers.
Escalado vertical: subir CPU o RAM sin migrar de servidor.
Acceso a logs con retención suficiente.
Copias de seguridad automáticas y una restauración probada.
Monitorización externa de disponibilidad y latencia con alertas.
Plan de migración: IP dedicada, TTL de DNS bajo el día del cambio y no tocar URLs ni redirecciones en el mismo movimiento.

Conclusión: hosting aburrido, SEO sano

Tres ideas para llevarte. El proveedor no es un factor de ranking, pero la disponibilidad, el TTFB y la capacidad de servir bytes sí tienen consecuencias, porque Google reduce el rastreo cuando el servidor sufre. La caché es la mejora más barata.

El siguiente paso no cuesta nada: mira hoy el tiempo medio de respuesta y el estado del host en Search Console. Si el TTFB supera los 0,8 segundos en el percentil 75, activa caché de página antes de cambiar de proveedor.