Cómo elegir hosting gratis sin perder SEO ni rendimiento

Gratis no significa improvisado

Un hosting gratuito puede ser perfectamente válido para un proyecto real. El problema no es el precio, sino elegir por la cuota de almacenamiento y no por lo que de verdad limita un sitio: el tráfico, los builds, la capacidad de redirigir y el control sobre las cabeceras.

Antes de migrar, escribe tus requisitos. ¿Es un sitio estático o necesita backend? ¿Cuántas páginas tiene? ¿Publicas a diario o una vez al mes? ¿Necesitas formularios? ¿Vas a mover URLs antiguas? Con esas respuestas, la comparación se reduce a dos o tres opciones.

Lo que de verdad limita un plan gratuito

El almacenamiento casi nunca es el problema. Lo que se agota primero es el ancho de banda si sirves vídeo o imágenes sin comprimir, y los minutos de build si compilas en cada push. También importan los límites de peticiones si usas funciones serverless.

Lee la letra pequeña sobre uso comercial. Varios planes gratuitos son solo para proyectos personales. Usar un plan Hobby para una tienda puede acabar en suspensión, y una migración de emergencia siempre cuesta más que elegir bien desde el principio.

• Ancho de banda mensual y qué ocurre al superarlo.
• Número de builds o minutos de compilación.
• Límite de archivos por despliegue y tamaño máximo.
• Soporte de dominio propio y HTTPS sin coste.
• Redirecciones y cabeceras personalizadas.
• Uso comercial permitido en el plan gratuito.

Estático primero, dinamismo solo cuando haga falta

Si tu contenido no cambia por usuario, un sitio estático es más rápido, más barato y más difícil de romper. Puedes generarlo en tu máquina o en CI y subir archivos. Las funciones serverless quedan para lo que de verdad necesita ejecutarse en el servidor: un formulario, una API pequeña o una redirección condicional.

Esta separación también mejora el SEO: el HTML se sirve completo desde el primer byte, sin depender de que un navegador ejecute JavaScript para ver el contenido.

Dominio propio, HTTPS y canonical

Usa un dominio propio desde el primer día si puedes. Un subdominio del proveedor funciona para probar, pero traslada confianza y obliga a redirigir después. Configura HTTPS y fuerza una sola versión del dominio: con o sin www, pero no ambas.

La etiqueta canonical debe apuntar a la URL definitiva, con el dominio correcto y la barra final coherente. Un canonical mal configurado puede enviar a Google a una versión que no existe o que redirige.

Redirecciones: el detalle que salva una migración

Si cambias de proveedor o de estructura de URLs, necesitas redirecciones 301 desde las direcciones antiguas a las nuevas. Comprueba que el proveedor permite definir redirecciones sin tocar el código. Si no, tendrás que usar un Worker o un proxy delante.

Nunca redirijas todo a la home. Una redirección masiva a la página de inicio se interpreta como un soft 404 y pierde la mayor parte del valor de los enlaces y del historial.

Qué pasa cuando creces

Ten un plan de salida antes de necesitarlo. Si tu sitio es estático, migrar suele ser copiar archivos y cambiar los DNS. Si dependes de funciones propietarias, la migración es más cara. Documenta qué servicios usas y cuánto tardarías en moverlos.

No pagues por adelantado un plan anual para ahorrar un 20 % en un proyecto que aún no ha validado su tráfico. Empieza gratis, mide, y paga cuando el coste del plan sea menor que el tiempo que pierdes gestionando límites.

Recomendación por perfil

Para un blog estático con tráfico variable, Cloudflare Pages es la opción con menos sorpresas: no cobra ancho de banda y el despliegue es inmediato. Para un proyecto que necesita formularios o funciones sin montar nada, Netlify ahorra tiempo. Para documentación open source, GitHub Pages es imbatible en simplicidad. Para una demo personal con Next.js, Vercel ofrece la mejor experiencia, siempre que respetes el uso no comercial.

No hay un ganador absoluto. Hay un ganador para tu caso, y suele decidirse por una sola cosa: qué límite vas a tocar primero.