Si buscas cómo elegir un hosting web, empieza por el tipo de proyecto, su carga probable y las tareas que estás dispuesto a administrar. El precio inicial y el espacio disponible importan, pero no dicen cuántas solicitudes simultáneas tolerará la aplicación, qué acceso tendrás, cómo se restaura un backup o qué ocurrirá al renovar. Un plan adecuado es el que hace compatibles tu software, tus picos y tus responsabilidades con límites que puedas comprobar antes de pagar.
Eso cambia la pregunta de «¿cuál tiene más recursos?» por «¿qué necesita mi sitio y dónde están los límites reales?». Una landing estática, una tienda con campañas, una API con procesos persistentes y una empresa que depende del correo no deben evaluarse con la misma lista de prioridades. Esta guía te ayuda a descartar opciones, elegir una categoría inicial y comparar proveedores sin asumir que una etiqueta como «ilimitado» elimina las condiciones de uso.
Decisión rápida según el proyecto
La tabla no asigna un ganador universal. Propone un punto de partida y la verificación que puede cambiarlo. «Managed» describe un alcance de gestión, no una cantidad fija de recursos; «cloud» describe una forma de infraestructura o aprovisionamiento, no una garantía automática de escalado, disponibilidad o rendimiento.
| Proyecto | Prioridad real | Punto de partida | Qué comprobar antes de elegir |
|---|---|---|---|
| Landing o portafolio estático | Publicación simple, TLS, transferencia y restauración | Hosting compartido si admite el flujo de publicación | Dominios, límites de archivos/inodos, caché, backups y proceso de despliegue |
| Blog o web empresarial con WordPress | Compatibilidad, actualizaciones, caché y soporte | Shared bien dimensionado o WordPress gestionado | Versiones, PHP workers/procesos, base de datos, alcance de gestión y restauración |
| WooCommerce, membresías o sitio dinámico con picos | Concurrencia, consultas, jobs y recuperación | Managed con límites suficientes o VPS/cloud | CPU/RAM sostenibles, workers, caché, I/O, escalado y quién administra el sistema |
| SaaS, API, Node.js, contenedores o procesos persistentes | Runtime, puertos, procesos, despliegue y observabilidad | VPS/cloud; dedicado cuando la carga o el aislamiento lo justifican | Acceso root, restricciones de red, almacenamiento, snapshots/backups y operación 24/7 |
| Proyecto que depende del correo corporativo | Continuidad, autenticación, reputación y soporte | Hosting con correo documentado o servicio de correo separado | Buzones, envíos, tamaño, SPF/DKIM/DMARC, logs, migración y límites antispam |
Hosting compartido: varios clientes comparten una plataforma administrada. Encaja cuando la aplicación es compatible, la carga es moderada y prefieres que el proveedor opere el sistema base. La contrapartida son límites de cuenta y menor control; por eso debes pedirlos, no inferirlos del almacenamiento.
WordPress gestionado: puede reducir tareas relacionadas con WordPress, pero la palabra «gestionado» no tiene un alcance único. Averigua si incluye actualizaciones, staging, caché, migración, recuperación o ayuda con plugins y, sobre todo, qué queda bajo tu responsabilidad.
VPS o cloud: proporciona más control y suele ser el punto natural para runtimes propios, colas, contenedores o procesos persistentes. También puede trasladarte parches, firewall, monitoreo, backups y respuesta a incidentes. Si todavía no distingues esa responsabilidad, revisa qué es un VPS y cómo funciona antes de comparar tamaños.
Servidor dedicado: ofrece una máquina para una sola organización y puede encajar cuando necesitas aislamiento, hardware específico o una carga sostenida que lo justifique. No es automáticamente más rápido ni más sencillo: capacidad, arquitectura, administración y recuperación siguen siendo decisiones separadas.
Los 12 factores que sí importan al elegir hosting
Estos son los doce factores de compra. En cada uno, busca un límite, una responsabilidad y una forma de verificarlo. Una cifra anunciada sin contexto es solo el inicio de la conversación.
1. Compatibilidad con la aplicación
Confirma runtime, versión, extensiones, base de datos, tareas programadas, reglas del servidor web y posibilidad de ejecutar procesos persistentes. Una aplicación PHP tradicional puede funcionar en shared, mientras que un servicio Node.js, un worker de cola o un contenedor necesita capacidades que muchos planes compartidos no ofrecen. Para WordPress, contrasta el plan con los requisitos oficiales vigentes y revisa en PHP cuáles son las ramas con soporte actual; no basta con que una versión antigua todavía arranque.
Pregunta también quién valida la compatibilidad después de una actualización. Un instalador de un clic facilita el inicio, pero no demuestra que tus plugins, tema, extensiones o flujo de despliegue sean compatibles. Prepara una lista del software exacto y solicita una respuesta escrita.
2. CPU, RAM, procesos y PHP workers
CPU y RAM anunciadas no describen por sí solas la concurrencia útil. Una página cacheada puede consumir poco PHP; un checkout, una búsqueda, una llamada a la API o una tarea en segundo plano puede ocupar un worker y ejecutar consultas. Pregunta por límites de CPU, memoria por cuenta o proceso, procesos simultáneos, PHP workers, tiempo de ejecución y conducta al alcanzar el límite: cola, throttling, error o terminación.
No existe una cifra universal de visitas por worker o de RAM por WordPress. Depende de caché, código, plugins, consultas, tráfico automatizado y picos. Más CPU o RAM tampoco corrige una consulta lenta ni una caché mal configurada. Si ya tienes un sitio, usa periodos representativos y relaciona errores, latencia y saturación antes de ampliar.
3. Almacenamiento, I/O e inodos
Los gigabytes responden cuánto cabe, no con qué rapidez se lee o escribe ni cuántos archivos puedes crear. Pregunta por tipo de almacenamiento, límites de I/O, operaciones, espacio de base de datos, inodos y consumo de backups, correos, logs y staging. Un WordPress con muchas miniaturas o cachés puede agotar archivos antes que capacidad; una tienda puede sentir latencia de base de datos aun con mucho espacio libre.
Define también cómo se amplía y reduce el volumen y qué ocurre al exceder una cuota. «SSD» o «NVMe» identifica tecnología, pero no promete una latencia concreta bajo tu carga. La única comparación sólida combina políticas documentadas con una prueba de tu aplicación.
4. Tráfico, ancho de banda y fair use
Separa visitas, solicitudes y transferencia. Una visita puede descargar imágenes grandes, activar varias peticiones dinámicas o quedar servida desde CDN; por eso ningún número de «visitas mensuales» se traduce de forma universal a capacidad. Si el plan dice «sin medición» o «ilimitado», lee la política de uso razonable y pregunta por puertos, transferencia, conexiones, tráfico automatizado y reacción ante abuso o picos.
Calcula escenarios, no promesas: campaña, lanzamiento, bot legítimo, importación, descarga y día normal. Confirma si el límite se cobra, restringe o suspende, y si recibirás avisos antes. Un margen de transferencia no sustituye los workers, CPU o base de datos necesarios para servir contenido dinámico.
5. Ubicación, latencia y CDN
La distancia y la ruta de red influyen en el tiempo hasta el servidor, pero un datacenter cercano no compensa una aplicación lenta. Elige región según la mayoría de usuarios, requisitos de datos y servicios conectados; después comprueba si puedes usar CDN para activos cacheables y cómo se purga la caché. Mide desde ubicaciones representativas en vez de asumir que el país del proveedor coincide con la ruta real.
Google presenta Core Web Vitals como métricas de experiencia real relacionadas con carga, interacción y estabilidad visual. El hosting puede afectar parte del recorrido, pero frontend, caché, terceros y dispositivo también cuentan. La propia guía de experiencia de página de Google aconseja evaluar el conjunto, no una sola señal.
6. Disponibilidad, SLA y mantenimientos
Una cifra de uptime necesita definición: periodo de medición, componentes cubiertos, exclusiones, mantenimiento programado, método de reclamación y compensación. Revisa el SLA y el historial de estado si existe. Pregunta cómo se comunican incidencias y mantenimientos, si hay redundancia real para tu servicio y qué parte —DNS, correo, base de datos, panel o aplicación— queda fuera.
Un SLA es un compromiso contractual, no una arquitectura ni una promesa de cero downtime. Tu diseño también importa: dependencias externas, despliegues defectuosos y errores de aplicación pueden dejar el sitio inaccesible aunque el nodo esté activo. Define cómo detectarás la caída y quién responde.
7. Backups, retención y restauración probada
Pregunta qué se respalda, con qué frecuencia, durante cuánto tiempo, dónde se conserva y quién puede restaurarlo. Confirma si bases de datos, correo, DNS, archivos, volúmenes y configuraciones entran en la copia; cuánto tarda la recuperación; si puedes descargar una copia independiente; y si restaurar tiene límites o coste. Un snapshot del servidor no siempre equivale a un backup aislado.
La existencia de una copia no demuestra que sea íntegra ni que conozcas el procedimiento. Haz una restauración de prueba en un entorno separado y documenta el resultado. Conserva además una copia bajo tu control, con una retención que cubra errores descubiertos tarde; no dependas de un único proveedor para origen y recuperación.
8. TLS, aislamiento, actualizaciones y DDoS por capas
TLS cifra la conexión, pero no corrige software vulnerable, credenciales robadas ni una aplicación comprometida. Verifica emisión y renovación de certificados, aislamiento entre cuentas, parches del sistema, versiones soportadas, firewall, malware, logs, autenticación multifactor y división de responsabilidades. La guía de Let’s Encrypt distingue entre certificados administrados por el proveedor y el uso de un cliente ACME propio: confirma cuál te corresponde.
Elige hosting con límites claros
Compara planes de Web Hosting según tu sitio, recursos y necesidades de crecimiento.
Para DDoS, separa mitigación upstream, límites de red, firewall del host y protección de aplicación. Pregunta qué tráfico se cubre, qué sucede durante un ataque y cómo se escala un incidente. Ninguna capa garantiza inmunidad; TLS tampoco es «seguridad completa». El objetivo es reducir riesgo y tener una respuesta conocida.
9. Panel, archivos, SSH/SFTP y acceso
El panel debe permitir las operaciones que harás de verdad: dominios, DNS, certificados, archivos, bases de datos, cron, logs, backups y usuarios. Comprueba si tendrás SFTP o SSH, claves, Git, CLI, acceso a logs y permisos suficientes para diagnosticar. FTP sin cifrar no debería ser tu única vía. Si el servicio usa DirectAdmin, su documentación oficial te permite contrastar conceptos y operaciones, pero el proveedor debe confirmar qué módulos y permisos habilita en tu plan.
Evita pagar por root si no lo necesitas y evita un panel cómodo que bloquee tu flujo crítico. Pide una demo, capturas actuales o documentación. Para equipos, confirma usuarios separados, roles y registro de cambios; compartir una contraseña dificulta revocar acceso y atribuir acciones.
10. Correo, límites y entregabilidad
Si el correo sostiene ventas o soporte, trátalo como sistema propio. Pregunta por número y tamaño de buzones, límites de envío y recepción, adjuntos, listas, webmail, filtros, backups, logs, reputación de IP, puertos y soporte para SPF, DKIM y DMARC. Decide si conviene alojarlo junto al sitio o separarlo para reducir dependencias y obtener herramientas especializadas.
Ningún proveedor puede prometer llegada a bandeja de entrada: influyen autenticación, reputación, contenido, consentimiento y conducta de envío. Las directrices oficiales para remitentes de Gmail exigen y recomiendan controles que varían según el patrón de envío; compáralas con tu caso y confirma qué configura el host y qué debes mantener tú.
11. Soporte, migración y alcance real
«Soporte 24/7» no explica canal, primera respuesta, capacidad técnica ni alcance. Presenta un incidente hipotético: error de base de datos, certificado que no renueva, cambio de DNS o saturación de workers. Pregunta quién lo diagnostica, qué evidencia requiere, si interviene en la aplicación y qué queda fuera. Revisa horarios, idioma, escalamiento y documentación.
Para migración, confirma qué mueve el proveedor, cuántos sitios y buzones, qué accesos necesita, si prueba antes del cambio, quién actualiza DNS y cómo revierte. «Migración incluida» puede cubrir solo archivos o una instalación compatible. Un inventario y un plan de aceptación evitan descubrir el límite durante la ventana de cambio.
12. Precio de renovación, upgrades, degradaciones y salida
Compara coste total, no solo la primera factura: plazo, renovación, impuestos, dominio, correo, backups, panel, migración, restauraciones y recursos adicionales. Pide el precio normal aplicable después de cualquier promoción y las condiciones para cancelar. No presupongas que el descuento se repite ni que todas las funciones siguen incluidas al cambiar de nivel.
Verifica si ampliar exige reinicio o migración, si puedes reducir, cómo se prorratea, cuánto tarda y qué datos puedes exportar. La salida debe cubrir archivos, base de datos, buzones, DNS, certificados y secretos. Un precio atractivo pierde valor si estás obligado a una arquitectura difícil de trasladar o si no puedes recuperar tus datos en un formato utilizable.
Recursos anunciados frente a límites operativos
Una ficha comercial suele mostrar almacenamiento, transferencia o «sitios», pero la experiencia se rompe al tocar otro techo: CPU por intervalo, memoria por proceso, I/O, inodos, conexiones de base de datos, workers, procesos, tamaño de buzón o tiempo máximo. Solicita la tabla completa de límites y la política de uso razonable. Después pregunta cómo se mide cada recurso, dónde puedes observarlo y qué evento ocurre al excederlo.
| Lo anunciado | Límite operativo relacionado | Pregunta útil |
|---|---|---|
| Mucho almacenamiento | I/O, inodos, cuota de base de datos y backups | ¿Qué cuenta en la cuota y qué ocurre al alcanzar cada límite? |
| Visitas o tráfico amplio | Workers, CPU, conexiones y fair use | ¿Cómo se atiende un pico dinámico y dónde veo la saturación? |
| Varios sitios | Recursos compartidos entre cuentas o dominios | ¿Todos consumen el mismo pool y puede uno afectar a los demás? |
| Backup incluido | Retención, alcance y tiempo de restauración | ¿Puedo descargarlo y probarlo sin sustituir producción? |
Cómo saber si shared basta o conviene managed o VPS
Shared probablemente basta si tu aplicación está admitida, puedes operar dentro de los límites publicados, no necesitas procesos persistentes ni configuración del sistema, tus picos son modestos y el proveedor ofrece el acceso y la recuperación que requieres. No es una opción «menor»: reduce trabajo operativo cuando el alcance coincide con el proyecto.
Managed puede compensar cuando el valor está en delegar tareas concretas —actualizaciones, caché, staging, monitoreo o recuperación— y el contrato define esas tareas. Comprueba que sus límites soporten tu carga; gestión y capacidad no son sinónimos.
VPS/cloud empieza a tener sentido cuando necesitas un runtime no admitido, procesos persistentes, reglas de red, paquetes propios, aislamiento o escalado que shared no ofrece. También cuando los límites operativos se repiten bajo una aplicación ya optimizada. Antes de migrar por intuición, revisa nuestra guía de comprobaciones para un WordPress lento: un servidor mayor no arregla automáticamente código, plugins o consultas.
Dedicado se justifica por requisitos medidos de carga, aislamiento, licencias o hardware, no por prestigio. Si no tienes personal o servicio gestionado para operar el sistema, el control adicional puede aumentar riesgo y tiempo de recuperación.
Preguntas verificables antes de comprar
- ¿Mi runtime, versión, extensiones, base de datos y tipo de proceso están permitidos hoy?
- ¿Cuáles son los límites de CPU, RAM, procesos, PHP workers, I/O, inodos y conexiones, y dónde los veo?
- ¿Qué ocurre exactamente al alcanzar cada límite y qué aviso recibiré?
- ¿Qué significa «ilimitado» o «sin medición» en la política de fair use?
- ¿Qué región aloja aplicación, base de datos, backups y correo?
- ¿Cómo define el SLA la disponibilidad y qué mantenimientos o componentes excluye?
- ¿Qué incluye el backup, cuál es la retención, puedo descargarlo y cómo pruebo una restauración?
- ¿Quién renueva TLS, actualiza el sistema, configura el firewall y responde ante DDoS o compromiso?
- ¿Tendré SFTP/SSH, logs, cron, exportación de base de datos, usuarios separados y el panel necesario?
- ¿Cuáles son los límites de correo y quién configura SPF, DKIM y DMARC?
- ¿Qué cubren soporte y migración, qué no cubren y cómo se escala un incidente?
- ¿Cuál es el precio de renovación y el procedimiento para ampliar, reducir, cancelar y exportar todo?
Pide enlaces a condiciones, documentación o capturas actuales y guarda las respuestas relevantes. Una afirmación de preventa verificable es más útil que un adjetivo. Para comparar el alcance actual de Teramont sin convertir esta guía en un ranking, consulta sus planes de Web Hosting y aplica las mismas preguntas.
Migración segura y rollback
- Haz inventario y una copia independiente. Incluye archivos, base de datos, correo, DNS, certificados, cron, redirecciones, variables y credenciales. Verifica que la copia pueda abrirse o restaurarse.
- Reduce el TTL con antelación cuando proceda. Documenta los registros actuales y entiende la propagación. Nuestra explicación de cómo funciona DNS ayuda a separar cambio de registro, caché y resolución.
- Prueba el destino antes de mover tráfico. Usa una URL temporal o una resolución local, recorre formularios, login, compra, jobs, correo y rutas críticas; compara versiones y permisos.
- Cambia DNS y observa ambos lados. Supervisa errores, logs, colas, certificados, transacciones y mensajes. Evita cambios de contenido no sincronizados durante la transición.
- No canceles el origen hasta validar. Conserva una ventana de rollback. Si falla un criterio crítico, restaura los registros anteriores o redirige al origen, corrige y repite. El rollback necesita datos recientes; por eso la estrategia de sincronización debe definirse antes.
Nadie puede prometer cero downtime en toda migración. El objetivo es reducir el riesgo, definir criterios de aceptación y mantener una ruta de retorno. Solo cancela cuando DNS, aplicación, correo, backups y monitoreo funcionen en el destino y haya pasado la ventana acordada.
Errores comunes al comparar hosting
- Elegir por almacenamiento y olvidar workers, I/O, inodos o procesos.
- Convertir visitas mensuales en una capacidad universal sin conocer caché y concurrencia.
- Suponer que «managed», «cloud» o «ilimitado» tienen una definición idéntica entre proveedores.
- Confundir certificado TLS con seguridad completa o protección DDoS con inmunidad.
- Confiar en un backup nunca restaurado o alojado en el mismo punto de fallo.
- Migrar DNS sin prueba previa, copia independiente ni rollback.
- Comparar promoción inicial sin renovación, salida y coste operativo.
Elige con evidencia, no con la cifra más grande
La mejor decisión no es el plan con más recursos anunciados, sino el que satisface tu aplicación, picos, acceso y recuperación con responsabilidades y límites claros. Clasifica tu proyecto, usa los doce factores, obtén respuestas por escrito y prueba restauración y migración antes de depender del servicio. Empieza con capacidad razonable, mide el comportamiento real y escala cuando una restricción identificada —no una intuición— lo justifique.
