Cuando una empresa comienza a trabajar su posicionamiento aparece tarde o temprano una pregunta:
¿Necesito un mejor hosting para posicionar mejor en Google?
La respuesta fácil sería decir que sí y recomendar inmediatamente un servidor más caro.
La respuesta correcta necesita algunos matices.
Google no concede mejores posiciones simplemente porque una página esté alojada en un VPS, tenga discos NVMe, una dirección IP exclusiva o un servidor con muchos procesadores.
El hosting tampoco sustituye al contenido, los enlaces, una buena arquitectura web o la satisfacción de la intención de búsqueda.
Pero existe otra cara del problema.
Un servidor que responde lentamente, se queda sin recursos, devuelve errores 500 con frecuencia o permanece inaccesible cuando Google intenta visitar la web puede terminar interfiriendo directamente con el rastreo, la experiencia del usuario y algunas de las métricas que Google sí utiliza en sus sistemas.
Por eso quizá la mejor manera de explicarlo sea esta:
un buen hosting no hace SEO por ti, pero un mal hosting puede convertirse en un obstáculo para el SEO que estás haciendo.
Y esa diferencia merece ser entendida.
Lo que Google necesita antes de pensar siquiera en posicionar una página
Antes de discutir velocidad, procesadores o discos, existe una condición mucho más elemental.
Google tiene que poder acceder a la página.
Sus requisitos técnicos mínimos son sorprendentemente sencillos: Googlebot no debe estar bloqueado, la página debe responder correctamente y debe existir contenido que pueda indexarse. Google señala concretamente que una página que funciona debe entregar normalmente una respuesta HTTP 200. Google for Developers
Parece obvio, pero aquí el hosting ya entra en juego.
Si un servidor está caído cuando llega Googlebot, la página no puede ser procesada como lo sería durante una respuesta normal.
Una caída ocasional no significa que Google vaya a eliminar inmediatamente el sitio. Los sistemas están preparados para que Internet tenga incidentes.
El problema es la repetición.
Google explica que ante errores 5xx reduce temporalmente la frecuencia de rastreo. Si una URL continúa devolviendo errores del servidor durante suficiente tiempo, puede terminar desapareciendo del índice. Google for Developers
Por tanto, la disponibilidad del hosting no es una cuestión abstracta de SEO.
Es la infraestructura sobre la cual Google intenta encontrar tu contenido.
Lo que sucede cuando Google encuentra un servidor saturado
Hay algo especialmente interesante en la documentación de Google que rara vez aparece en las páginas comerciales de hosting.
Googlebot intenta no sobrecargar los servidores.
Si detecta que una infraestructura está teniendo problemas para responder, reduce la intensidad de sus solicitudes.
La propia documentación de Google explica que la velocidad de respuesta y la capacidad del servidor afectan a cuánto puede rastrear Googlebot sin poner en riesgo la infraestructura. Si el servidor comienza a responder lentamente o devuelve demasiados errores, Google puede disminuir el ritmo. Google for Developers
Esto es particularmente importante en sitios grandes.
Una web corporativa con 40 páginas probablemente no debería obsesionarse con el llamado crawl budget. Google lleva años indicando que para sitios pequeños normalmente no es un problema relevante.
Pero un ecommerce con cientos de miles de productos, un periódico que publica continuamente o una plataforma con millones de URLs vive otra realidad.
En esos proyectos, la capacidad del servidor para responder rápidamente puede determinar cuántas páginas puede recorrer eficientemente un buscador.
Y aun aquí debemos evitar una confusión:
que Google pueda rastrear más páginas no significa automáticamente que esas páginas vayan a posicionar mejor.
La frecuencia de rastreo no es un premio de posicionamiento. Google lo ha explicado expresamente. Google for Developers
El TTFB: el tiempo que transcurre antes de empezar
Aquí aparece una métrica que debería interesar mucho más a quien compra hosting que muchas especificaciones utilizadas en publicidad.
TTFB significa Time to First Byte, o tiempo hasta el primer byte.
Es el tiempo que transcurre desde que comienza la solicitud de una página hasta que empieza a recibirse la respuesta.
No mide cuánto tarda en aparecer toda la web.
Mide cuánto tardamos prácticamente en comenzar.
Podemos imaginar un restaurante.
Una cosa es el tiempo que tarda el camarero en llevar todos los platos a la mesa.
Otra es sentarse y esperar diez minutos antes de que alguien siquiera tome la orden.
El TTFB se parece más a lo segundo.
web.dev, mantenido por Google, considera aproximadamente 0,8 segundos o menos una buena referencia para el TTFB en la mayoría de sitios, aunque aclara algo muy importante: TTFB no es una Core Web Vital. web.dev
Esto desmonta otro mito.
Un TTFB de 300 milisegundos no otorga automáticamente una ventaja SEO frente a uno de 500.
Pero el TTFB ocurre antes que muchas otras cosas.
Si el servidor tarda dos segundos únicamente en comenzar a entregar el HTML, hemos consumido dos segundos antes de que el navegador pueda avanzar con buena parte del trabajo.
Por eso web.dev lo describe como una métrica fundamental.
Un servidor lento también puede complicar el LCP
Una de las Core Web Vitals actuales es Largest Contentful Paint o LCP.
Mide cuándo aparece el elemento principal de contenido que el usuario ve en pantalla.
Google considera buena una experiencia cuando el LCP se produce dentro de aproximadamente los primeros 2,5 segundos para al menos el 75 % de las visitas evaluadas. Las otras Core Web Vitals actuales son INP para capacidad de respuesta y CLS para estabilidad visual. Google for Developers
Aquí el hosting puede influir, pero tampoco podemos culparlo de todo.
Si una imagen principal pesa cinco megabytes, ningún procesador va a corregir por arte de magia una mala optimización.
Si existen veinte scripts bloqueando el navegador, cambiar de servidor tampoco resolverá necesariamente el problema.
Pero si el HTML tarda demasiado en salir del servidor, prácticamente todo comienza tarde.
Un análisis de web.dev sobre LCP encontró precisamente que, entre sitios con resultados deficientes, un TTFB alto puede consumir una proporción enorme del tiempo disponible antes incluso de cargar el elemento principal. web.dev
Aquí aparece la verdadera relación entre hosting y Core Web Vitals.
No es:
“Tengo hosting premium, Google me posiciona mejor”.
Es:
“Mi infraestructura permite que la página comience a responder rápidamente y no dificulta las métricas de experiencia que estoy intentando optimizar”.
Es bastante diferente.
Google utiliza Core Web Vitals, pero no conviertas PageSpeed en una obsesión
Google confirma actualmente que las Core Web Vitals forman parte de los sistemas que evalúan la experiencia de página.
Pero también hace una aclaración que debería imprimirse encima de muchos informes SEO:
una buena puntuación no garantiza ocupar los primeros resultados.
Google sigue priorizando la relevancia del contenido. Una página extraordinariamente rápida no merece superar automáticamente a otra que responde mucho mejor a la búsqueda del usuario. Google for Developers
Semrush coincide actualmente en ese punto. Sus materiales técnicos sitúan Core Web Vitals dentro del SEO técnico, pero las tratan como una parte de un sistema mucho más amplio, no como un truco para conseguir posiciones. SEMrush
Por eso perseguir un 100/100 en PageSpeed durante semanas puede tener muy poco sentido si tenemos problemas mucho mayores de contenido, arquitectura o intención de búsqueda.
El objetivo debería ser una web realmente rápida para sus usuarios.
No una captura bonita con cuatro números verdes.
Yoast, Rank Math y Semrush coinciden más de lo que parece
Es interesante revisar qué dicen algunas de las compañías más conocidas del sector SEO porque, aunque venden herramientas diferentes, en este tema existe bastante consenso.
Yoast ha creado incluso un curso específico dedicado a hosting y configuración de servidores. Su planteamiento es razonable: el hosting influye en velocidad, disponibilidad y seguridad, pero no sustituye al trabajo SEO ni garantiza mejores posiciones. Yoast
Rank Math recomienda evaluar la fiabilidad del proveedor, rendimiento y capacidad del hosting porque todos afectan a la experiencia del sitio. También incluye un alojamiento estable dentro de las bases técnicas que recomienda para WordPress. Rank Math
Semrush analiza el mismo problema desde Core Web Vitals y SEO técnico. Entre las causas que identifica para un mal LCP aparece precisamente una respuesta lenta del servidor. SEMrush
La conclusión compartida no es que exista un “hosting SEO” secreto.
Es mucho más sencilla:
una infraestructura sana elimina problemas que pueden perjudicar una estrategia SEO.
Hosting compartido: ¿Google lo considera peor?
Este es uno de los mitos más antiguos de la industria.
Durante años se ha repetido que un hosting compartido posiciona peor porque muchas páginas utilizan el mismo servidor o incluso la misma dirección IP.
No funciona así.
John Mueller, de Google, ha explicado que utilizar hosting compartido es perfectamente válido para Google Search y que un servidor dedicado no recibe una ventaja SEO automática.
También ha desmentido la antigua teoría de los llamados “malos vecinos”: alojar un sitio en una dirección IP donde existen otras webs de poca calidad no hace que Google transfiera automáticamente su reputación hacia nosotros. Search Engine Journal
Eso no significa que todos los hostings compartidos sean iguales.
Un servidor donde cientos de cuentas compiten continuamente por CPU, memoria y disco puede sufrir problemas de rendimiento.
Pero ese es un problema de recursos, no una penalización de Google por pertenecer a un servidor compartido.
Un buen hosting compartido puede ser perfectamente adecuado para una pyme.
Un VPS mal configurado puede funcionar bastante peor.
La IP dedicada tampoco compra posiciones
Otro clásico.
“Para SEO necesitas una IP dedicada”.
No.
Google ha reiterado que utilizar una IP compartida es habitual y perfectamente normal, especialmente con proveedores de hosting y redes CDN. No existe una ventaja de posicionamiento por contratar simplemente una IP exclusiva. Search Engine Journal
Puede haber otras razones técnicas para necesitar una dirección IP concreta.
Pero comprarla esperando subir posiciones es confundir infraestructura con señales de relevancia.
¿Y si el servidor está en Perú?
Aquí existe otro mito interesante.
Si nuestro público está en Perú, parece lógico pensar:
“Google me posicionará mejor en Perú si el servidor también está físicamente en Perú”.
La geolocalización de las búsquedas no funciona de una forma tan simple.
La ubicación física del servidor puede afectar la latencia porque los datos tienen una distancia que recorrer.
Pero no deberíamos confundir eso con una señal directa que diga “servidor peruano = mejor SEO peruano”.
Google posee muchas otras señales para interpretar la orientación geográfica de un sitio y, además, las CDN han cambiado radicalmente cómo se entrega contenido en Internet.
Lo que realmente importa desde el punto de vista de rendimiento es cuánto tarda el contenido en llegar al usuario.
Google explica que una CDN puede servir contenido desde nodos mucho más cercanos al visitante y reducir de forma considerable esa distancia. Google for Developers
Un excelente servidor en Estados Unidos acompañado de una CDN bien configurada podría ofrecer a un visitante peruano una experiencia superior a la de un servidor físicamente ubicado en Lima pero saturado.
La geografía importa por física.
No por patriotismo algorítmico.
Una CDN tampoco arregla mágicamente un servidor malo
Las redes de distribución de contenido son extraordinariamente útiles.
Pueden almacenar imágenes, CSS, JavaScript e incluso HTML en servidores cercanos a los usuarios.
También reducen carga sobre el servidor de origen y pueden ayudar frente a determinados ataques o aumentos súbitos de tráfico. Google incluso explica que su infraestructura de rastreo está preparada para trabajar especialmente bien con sitios respaldados por CDN. Google for Developers
Pero aquí aparece otro matiz interesante.
Una página almacenada completamente en caché puede parecer rapidísima mientras el servidor real continúa siendo lento.
web.dev advierte expresamente de esta posibilidad: una CDN puede ocultar problemas del backend durante determinadas mediciones. web.dev
Por eso una auditoría seria debería poder distinguir entre:
el rendimiento del edge,
y el rendimiento del servidor de origen.
Ambos importan.
CPU, RAM y NVMe tampoco son factores de ranking
Este punto es importante porque encontramos estas palabras constantemente en anuncios de hosting.
NVMe.
32 núcleos.
DDR5.
Procesadores Xeon.
Todo puede ser técnicamente valioso.
Pero Google no asigna posiciones porque detecte que un servidor utiliza NVMe.
Lo que importa es el resultado.
Si utilizar almacenamiento rápido permite resolver consultas de base de datos con menor latencia y entregar páginas antes, perfecto.
Si disponer de más memoria permite mantener correctamente la caché y evitar swapping, excelente.
Si más CPU evita que WordPress se ahogue durante un pico de visitas, también.
Pero el SEO recibe el efecto, no la etiqueta del hardware.
Un hosting puede anunciar NVMe y seguir respondiendo lentamente por mala configuración, exceso de cuentas, plugins deficientes o una base de datos saturada.
Por eso debemos medir rendimiento real.
No comprar especificaciones como si fueran factores SEO.
La versión de PHP tampoco es una palabra clave para Google
Algo parecido ocurre con PHP.
Google no otorga mejores posiciones por utilizar PHP 8.4 en lugar de una versión anterior.
Pero mantener una plataforma moderna puede traer mejoras en rendimiento, compatibilidad y seguridad.
Yoast destaca precisamente la versión de PHP como uno de los aspectos de servidor que los propietarios de WordPress deberían comprender y mantener correctamente. Yoast
El razonamiento vuelve a ser el mismo.
PHP no es el factor SEO.
La velocidad, estabilidad y seguridad que una plataforma correctamente mantenida puede proporcionar sí forman parte de la salud técnica del proyecto.
El problema SEO de una caída no es solo perder clientes
Una web caída tiene una consecuencia evidente.
Los usuarios no pueden comprar, contactar ni leer.
Pero también existe un efecto sobre los buscadores.
Google distingue claramente los errores temporales del servidor. Los códigos 500, 502, 503 y similares indican que existe un problema para entregar el contenido.
Ante estas respuestas Google disminuye progresivamente el rastreo para evitar empeorar la situación.
Si el problema persiste, las URLs pueden terminar saliendo del índice. Google for Developers
Por eso un buen proveedor debería preocuparnos no únicamente por su porcentaje publicitario de uptime.
También por cómo responde cuando ocurre algo.
Un servidor puede caerse.
Una red puede sufrir una incidencia.
Incluso las mayores plataformas del mundo tienen interrupciones.
La diferencia está en la frecuencia, duración, capacidad de recuperación y soporte.
La seguridad también termina teniendo consecuencias SEO
La seguridad del hosting tampoco debería venderse como “un factor de ranking”.
Pero ignorarla puede tener consecuencias mucho más graves que perder unas décimas en PageSpeed.
Si una vulnerabilidad permite que un atacante inyecte páginas, malware, redirecciones o contenido fraudulento, Google puede mostrar advertencias a los usuarios e identificar el sitio dentro del informe de problemas de seguridad de Search Console. Ayuda de Google
Google reconoce además que los problemas de seguridad pueden provocar descensos de tráfico porque los usuarios reciben advertencias antes de acceder al sitio. Google for Developers
De repente, conceptos aparentemente ajenos al SEO, como copias de seguridad, actualizaciones, aislamiento de cuentas y posibilidad de recuperar rápidamente una web, comienzan a tener muchísimo sentido.
Un backup no mejora una posición.
Pero cuando necesitas restaurar un sitio comprometido, descubres rápidamente cuánto puede valer para conservar años de trabajo.
Entonces, ¿qué debería importar al elegir hosting para un proyecto SEO?
Más que buscar un plan que incluya la palabra “SEO”, revisaría estas cuestiones:
Estabilidad real: que la infraestructura mantenga una disponibilidad consistente y no presente errores 5xx recurrentes.
Tiempo de respuesta: observar TTFB real, tanto desde caché como desde el servidor de origen.
Recursos suficientes: CPU, memoria y procesos adecuados para la carga real del proyecto, no simplemente cifras publicitarias.
Escalabilidad: que un aumento de visitas no convierta una campaña exitosa en una caída del servidor.
Stack actualizado: servidor web, PHP, base de datos, TLS y demás componentes mantenidos y correctamente configurados.
Caché y CDN: disponibles cuando realmente aporten rendimiento, sin utilizarlos para esconder un backend permanentemente lento.
Seguridad y recuperación: aislamiento, protección, copias de seguridad y capacidad de restauración.
Soporte técnico competente: probablemente uno de los aspectos más infravalorados. Cuando existe un error 503, una migración, un certificado roto o Googlebot no puede acceder, necesitas una solución, no únicamente un panel bonito.
Esas son características que sí pueden sostener una estrategia SEO técnicamente saludable.
Mitos y realidades sobre hosting y SEO
Afirmación
Realidad
Un VPS posiciona mejor que un hosting compartido
Mito. Importa su rendimiento y estabilidad, no la etiqueta del servicio.
Una IP dedicada mejora posiciones
Mito. Google ha negado esa ventaja.
Necesito alojarme en Perú para posicionar en Perú
Mito como regla SEO. La proximidad puede reducir latencia, pero no compra relevancia geográfica.
NVMe mejora directamente el SEO
Mito. Puede mejorar rendimiento, que es otra cuestión.
Un servidor lento puede afectar al proyecto SEO
Realidad. Puede perjudicar experiencia, métricas y capacidad de rastreo.
Los errores 5xx persistentes pueden afectar la indexación
Realidad. Google lo documenta expresamente.
Obtener 100 en PageSpeed me hará subir posiciones
Mito. La relevancia sigue siendo esencial.
Una CDN puede ayudar
Realidad, especialmente con latencia, caché y carga, pero debe estar bien configurada.
Un hosting caro garantiza buen SEO
Mito. El precio no es una señal que Google pueda utilizar para valorar tu contenido.
El hosting debería ser invisible
Paradójicamente, probablemente esa sea una de las mejores características que puede tener.
Cuando todo funciona correctamente no deberíamos pensar constantemente en el servidor.
La página responde.
Google puede rastrearla.
El usuario navega rápidamente.
Las campañas soportan sus picos de tráfico.
Las copias de seguridad existen si algo falla.
Y los especialistas pueden concentrarse en contenido, arquitectura, intención de búsqueda, conversión y autoridad.
Yoast resume esta filosofía bastante bien en su material actual: un buen hosting no sustituye al SEO, pero uno deficiente puede trabajar silenciosamente en su contra. Yoast
Esa probablemente sea una descripción bastante más precisa que cualquier promesa de “hosting SEO”.
¿Tiene sentido cambiar de hosting únicamente por SEO?
No si la web funciona correctamente.
Cambiar de proveedor sin un problema concreto introduce un riesgo que no siempre aporta nada.
Google dispone incluso de documentación específica para migraciones de hosting y reconoce que puede producirse una fluctuación temporal en el rastreo mientras sus sistemas se adaptan a la nueva infraestructura. Si el nuevo servidor funciona correctamente, el rastreo tiende a normalizarse posteriormente. Google for Developers
Por eso no recomendaría migrar simplemente porque alguien promete “mejor SEO”.
Buscaría evidencia.
TTFB excesivo.
Caídas.
Errores 5xx.
Recursos agotados.
Problemas durante picos de tráfico.
Soporte insuficiente.
Infraestructura obsoleta.
Ahí sí tenemos razones.
¿Dónde encaja un proveedor como Inkaweb?
Para un proyecto orientado al mercado peruano también tiene sentido evaluar proveedores que puedan ofrecer soporte cercano y una infraestructura adecuada al tamaño del proyecto.
Un ejemplo es Inkaweb, que ofrece servicios de alojamiento web y publica actualmente opciones con almacenamiento NVMe, SSL, cPanel y sistemas de backup. Inkaweb
Pero incluso aquí aplicaríamos exactamente el mismo principio que hemos defendido durante todo el artículo:
no elegir un proveedor porque diga “SEO”, sino porque pueda sostener técnicamente una web que queremos posicionar.
Cuando evalúes un servicio de hosting web de Inkaweb o cualquier otra alternativa, comprueba rendimiento, estabilidad, recursos, seguridad, backups, capacidad de crecimiento y calidad del soporte.
Es mucho más importante que perseguir una dirección IP “SEO” o una característica comercial que Google ni siquiera utiliza como señal de posicionamiento.
Una buena infraestructura no convierte contenido mediocre en contenido relevante
Conviene terminar donde empezamos.
Podríamos tener un servidor extremadamente rápido.
TTFB excelente.
Core Web Vitals perfectas.
CDN global.
Cero caídas.
Eso no obliga a Google a colocar una página entre los primeros resultados.
Google continúa explicando que sus sistemas buscan contenido útil, fiable y relevante para las personas. La experiencia de página contribuye, pero no sustituye la calidad del resultado. Google for Developers
El hosting debe entenderse como los cimientos de una casa.
Unos buenos cimientos no convierten automáticamente una construcción en una gran vivienda.
Pero unos cimientos defectuosos pueden comprometer todo lo que construyas encima.
Con el SEO sucede algo parecido.
El hosting no posiciona tu web.
Pero debe permitir que tu web sea rápida, accesible, estable, segura y rastreable.
Cuando consigue eso, está haciendo exactamente el trabajo que necesitamos de él.