El hosting es el servicio que mantiene los archivos de tu sitio en un servidor conectado a internet las veinticuatro horas. Hay cinco formas de resolverlo, de menos a más control: estático, ideal para sitios sin base de datos y a menudo gratuito; compartido, barato y con recursos repartidos entre muchos; administrado, más caro y con el mantenimiento incluido; VPS, con recursos propios y administración a tu cargo; y dedicado, un servidor entero. Lo que decide no es el espacio en disco —hoy sobra en cualquier plan— sino tres cosas que rara vez figuran en la comparativa: qué respaldos hay y si se pueden restaurar, quién actualiza el software y qué pasa cuando algo falla un domingo.
Ver índice de contenidos
Qué hace un servidor web
La palabra «servidor» nombra tres cosas distintas, y separarlas evita confusiones: el equipo físico que está encendido en un centro de datos, el programa que atiende las peticiones HTTP, y el servicio que contratás. Cuando alguien dice «contraté un servidor», casi siempre habla del tercero.
Lo que ocurre cuando alguien visita tu sitio es, en resumen: el navegador resuelve el nombre por DNS, obtiene una dirección, abre una conexión —cifrada si hay certificado— y pide una ruta. El programa servidor busca qué responder y devuelve el contenido.
Ese «busca qué responder» es la bifurcación que define todo lo demás:
- Sitio estático: los archivos ya existen tal cual y se entregan. Es rapidísimo y no hay casi nada que pueda romperse.
- Sitio dinámico: un programa arma la respuesta en el momento, normalmente consultando una base de datos. Es lo que hace WordPress, y por eso necesita más del servidor.
Los cinco tipos
| Tipo | Qué es | A favor | En contra |
|---|---|---|---|
| Estático | Solo archivos, sin base de datos ni lenguaje de servidor | Rapidísimo, poca superficie de ataque, a menudo gratuito | No sirve si hace falta procesar en el servidor |
| Compartido | Muchos sitios en la misma máquina, repartiéndose recursos | El más barato; el proveedor mantiene el sistema | El vecino ruidoso te afecta; hay límites poco anunciados |
| Administrado | Preparado para una plataforma concreta | Actualizaciones, respaldos y caché incluidos; soporte que conoce el software | Bastante más caro; menos libertad de configuración |
| VPS | Una porción garantizada de un servidor, con sistema propio | Recursos asignados y acceso completo | La administración, las actualizaciones y los respaldos son tuyos |
| Dedicado | La máquina entera | Control total, sin vecinos | El costo y la responsabilidad operativa más altos |
Una aclaración sobre el estático, que suele descartarse antes de tiempo: hoy un sitio estático puede tener formularios, buscador y comentarios usando servicios externos. Para un portfolio, una landing, la documentación de un proyecto o un blog que se publica desde archivos, es la opción más rápida, más segura y más barata que existe.
Cuál te corresponde
| Si tenés… | Conviene | Por qué |
|---|---|---|
| Un portfolio o una landing sin base de datos | Estático | No hay nada que mantener ni que puedan vulnerar |
| Un blog o sitio institucional con pocas visitas | Compartido | Alcanza de sobra y el proveedor mantiene el sistema |
| Una tienda o un sitio del que dependen ingresos | Administrado | Los respaldos y las actualizaciones dejan de ser tu problema |
| Una aplicación propia o varios servicios juntos | VPS | Hace falta instalar cosas que un compartido no permite |
| Requisitos de cumplimiento o carga muy alta | Dedicado | Control total del entorno |
El criterio que ordena la decisión no es el tamaño del sitio: es cuánto cuesta que esté caído y cuánto tiempo tenés para dedicarle. Un blog personal puede estar dos días abajo sin consecuencias. Una tienda no, y ahí pagar por administrado sale más barato que el fin de semana perdido.
Qué mirar antes de contratar
El espacio en disco y la transferencia son lo que todos muestran y casi nunca lo que decide. Estas cinco preguntas sí:
- ¿Hay respaldos automáticos y puedo restaurarlos yo? No alcanza con que existan: tiene que poder recuperarlos uno, sin abrir un ticket y sin pagar aparte.
- ¿Quién actualiza el software? El sistema, el lenguaje, la base de datos. Si la respuesta es «vos», es un trabajo recurrente que hay que contar en el precio.
- ¿Qué soporte hay un domingo a la noche? Y en qué idioma. Un chat que responde en dos minutos vale más que un gigabyte extra.
- ¿Qué versiones ofrece y puedo elegirlas? WordPress, por ejemplo, recomienda PHP 8.3 o superior y MariaDB 10.11+ o MySQL 8.0+. Un proveedor con versiones viejas es un problema a plazo fijo.
- ¿Qué tan fácil es irse? Si podés descargar el sitio y la base de datos sin depender del panel del proveedor, tenés una salida. Si no, estás atado.
Y una que casi nadie hace y conviene: buscar el nombre del proveedor junto con la palabra «caída». La forma en que una empresa comunicó su último incidente dice más que toda su página de características.
Las palabras del marketing
Tres términos que aparecen en todas las páginas de precios y significan menos de lo que parecen.
«Ilimitado». No existe ningún recurso ilimitado. Lo que hay es ausencia de un límite publicado en disco o transferencia, y límites reales en otro lado: cantidad de procesos simultáneos, entradas por hora, consultas a la base de datos, archivos totales. Esos son los que te frenan de verdad, y suelen estar en la política de uso aceptable y no en la tabla comparativa.
«99,9 % de disponibilidad». Suena a perfección y equivale a unas 8 horas y 45 minutos de caída al año. Cada nueve adicional divide ese número por diez. Pero lo que importa no es la cifra sino la letra chica: qué compensación ofrece el contrato si no se cumple. Casi siempre es un crédito proporcional al tiempo caído, no una indemnización por el daño, así que el número funciona más como declaración de intenciones que como garantía.
«Optimizado» o «turbo». Sin una descripción de qué hace, no significa nada. Preguntá qué caché usa, qué versión del lenguaje corre y si hay límites de memoria por proceso.
Respaldos: la parte que se descubre tarde
Es lo que menos se mira al contratar y lo único que importa el día del problema. Cuatro preguntas concretas:
- ¿Cada cuánto se hacen?Diario es lo razonable. Semanal significa poder perder seis días de trabajo.
- ¿Cuánto se conservan?Siete días no alcanza si el problema tardó dos semanas en notarse, que es lo habitual con un sitio comprometido.
- ¿Puedo restaurar yo, sin pedir permiso?Si hay que abrir un ticket y esperar, el respaldo existe pero no está disponible cuando hace falta.
- ¿Están fuera del mismo servidor?Un respaldo en el mismo disco no protege del caso que más importa.
Un respaldo que nunca se restauró no es un respaldo: es una suposición. Vale probar la restauración una vez, con calma, en un entorno de prueba. La cantidad de respaldos que resultan estar vacíos, incompletos o corruptos justifica ese rato de trabajo.
Y conviene tener una copia propia además de la del proveedor. Si la cuenta se suspende, los respaldos del proveedor se suspenden con ella.
Seguridad mínima
Un sitio alojado y desatendido no queda igual: se degrada. El blog de Underc0de documentó una campaña de cryptojacking que comprometió más de 3.500 sitios web para minar criptomonedas con el navegador de las visitas. Ninguno de esos sitios era un objetivo elegido: eran instalaciones desactualizadas encontradas por barrido automático.
El mínimo razonable, sin importar el tipo de alojamiento:
- Actualizar el sistema, el lenguaje y la aplicación. Es la medida que más rinde y la que más se posterga.
- Doble factor en el panel de control y en el administrador del sitio.
- HTTPS obligatorio, con redirección desde HTTP. Hoy es gratis y automático en casi todos los proveedores.
- Acceso por clave en lugar de contraseña si hay conexión remota al servidor.
- Menos software instalado. Cada complemento y cada servicio que no usás es superficie de ataque sin contrapartida.
Y una advertencia sobre el software del propio servidor: el blog también cubrió el caso de HTTP/2 Bomb, que afectó a NGINX, Apache e IIS. En un alojamiento compartido o administrado eso lo parchea el proveedor; en un VPS, lo parchean ustedes.
Migrar sin quedarte afuera
Cambiar de proveedor es más fácil de lo que parece si se hace en el orden correcto, que es exactamente el inverso al intuitivo:
- Bajar el TTL del DNSA cinco minutos, un día antes. Es el paso que evita el corte, y está explicado en cómo funciona el DNS.
- Copiar todo al destinoArchivos y base de datos. El sitio viejo sigue en línea y atendiendo.
- Probar en el servidor nuevo sin tocar el DNSPor dirección IP o con un dominio de prueba. Acá se descubren las rutas escritas a mano.
- Emitir el certificado en el destinoAntes del cambio, para no tener una ventana sin HTTPS.
- Cambiar el registro DNSCon el TTL corto, la ventana es de minutos.
- Dejar el viejo encendido unos díasMientras conviven las dos respuestas, parte del tráfico sigue yendo para allá.
El paso tres es el que más sorpresas evita: es donde aparecen las direcciones absolutas escritas en la base de datos, las rutas de archivos del servidor anterior y las versiones de lenguaje incompatibles.
Errores frecuentes
- Elegir por el precio del primer año. La renovación suele multiplicarse por tres.
- Comparar por espacio en disco. Sobra en todos los planes; no es lo que te va a frenar.
- Suponer que el proveedor tiene respaldos útiles. Hay que confirmar frecuencia, retención y quién puede restaurar.
- No tener una copia propia. Si suspenden la cuenta, se suspenden también sus respaldos.
- Contratar un VPS sin saber administrarlo. Es un servidor sin nadie que lo cuide: en pocos meses está desactualizado.
- Descartar el alojamiento estático. Para muchos sitios es la mejor opción y suele ser gratis.
- Migrar cambiando el DNS primero. Es la receta para tener el sitio caído a la mitad de la gente.
- Dejar el dominio en manos del proveedor de hosting. Conviene tenerlos separados para poder mudarse.
Preguntas frecuentes
¿Qué diferencia hay entre hosting compartido y un VPS?
En el compartido, muchos sitios conviven en la misma máquina y se reparten los recursos, con el proveedor a cargo del mantenimiento del sistema. Es barato y suficiente para la mayoría de los sitios chicos, pero un vecino que consume de más puede afectarte y hay límites que no siempre se publican. En un servidor virtual privado tenés una porción garantizada de recursos y acceso completo al sistema, con la contrapartida de que las actualizaciones de seguridad, la configuración y los respaldos pasan a ser tu responsabilidad.
¿Qué significa realmente «ilimitado»?
Que no hay un límite publicado en disco o transferencia, no que no haya límites. Los que frenan de verdad están en otro lado y suelen figurar en la política de uso aceptable: cantidad de procesos simultáneos, entradas por hora, consultas a la base de datos, cantidad total de archivos. Cuando un sitio empieza a recibir visitas y de golpe responde con errores sin haber cambiado nada, casi siempre es alguno de esos topes. Conviene leer esa política antes de contratar y no después.
¿Qué garantiza un 99,9 % de disponibilidad?
Menos de lo que suena. Equivale a permitir unas ocho horas y tres cuartos de caída al año, y cada nueve adicional divide esa cifra por diez. Pero el número importa menos que la letra chica: hay que mirar qué compensación ofrece el contrato si no se cumple, cómo se mide la caída y quién la mide. En la mayoría de los casos la compensación es un crédito proporcional al tiempo caído, no una indemnización por el perjuicio, así que funciona más como declaración de intenciones que como garantía.
¿Sirve un hosting estático para un sitio real?
Para muchos sí, y suele descartarse antes de tiempo. Un sitio estático entrega archivos ya generados, así que es rapidísimo, casi no tiene superficie de ataque y con frecuencia es gratuito. Hoy puede tener formularios, buscador y comentarios apoyándose en servicios externos. Para un portfolio, una landing, la documentación de un proyecto o un blog que se publica desde archivos es la mejor opción disponible. Deja de servir cuando hace falta procesar cosas en el servidor, como un carrito o cuentas de usuario.
¿Cada cuánto conviene hacer respaldos y dónde guardarlos?
Diarios como mínimo si el sitio cambia seguido, y conservados el tiempo suficiente para cubrir un problema que tarde en detectarse: siete días es poco cuando un sitio comprometido tarda semanas en notarse. Tienen que estar fuera del mismo servidor y tiene que poder restaurarlos uno mismo, sin abrir un ticket. Y lo más importante: un respaldo que nunca se restauró no es un respaldo, es una suposición. Conviene probar la restauración una vez, con calma, antes de necesitarla.
¿Conviene contratar el dominio y el hosting en el mismo lugar?
Es cómodo y tiene un costo oculto. Si el mismo proveedor tiene el nombre y el sitio, mudarte implica dos trámites al mismo tiempo y con la misma empresa, justo cuando querés irte. Tenerlos separados agrega cinco minutos de configuración una sola vez y te deja la puerta abierta: podés cambiar de alojamiento apuntando un registro sin tocar el dominio, y cambiar de registrador sin tocar el sitio. Para un proyecto que va a durar, la separación conviene.
Fuentes
Documentación oficial y material de la comunidad consultados para esta guía. Fecha de consulta: 27 de julio de 2026.
Aportes de la comunidad Underc0de
- Underc0de, foro. Sección Hosting y dominios. Experiencias de la comunidad con proveedores, migraciones y caídas.
- Underc0de, blog. Campaña global de cryptojacking: más de 3.500 sitios web comprometidos, 21 de julio de 2025. Qué pasa cuando un sitio alojado queda desatendido.
- Underc0de, blog. HTTP/2 Bomb amenaza NGINX, Apache e IIS, 3 de junio de 2026. Un recordatorio de que el software del servidor también se actualiza.
Documentación oficial
- MDN Web Docs. What is a web server?. La distinción entre el equipo, el programa y el servicio.
- WordPress. Requirements. Los requisitos vigentes de PHP, base de datos y HTTPS citados en esta guía.
- Let’s Encrypt. Let’s Encrypt. La autoridad de certificación gratuita que la mayoría de los proveedores integra.