Aloja un archivo HTML como enlace en vivo

El caso clásico: has programado a mano un index.html, una página de «próximamente», un RSVP para un evento, un link-in-bio, una página de detalles de boda, y cada guía de alojamiento quiere que compres un dominio, apuntes los nameservers y esperes la propagación. Aquí la página está en vivo en el segundo en que termina la subida, en un enlace que puedes compartir por mensaje de texto. Como se renderiza en vivo en lugar de mostrar el código, los visitantes ven la página real con su maquetación, fuentes y estados hover intactos. El límite real: es genuinamente un solo archivo. Si tu sitio es index.html más una carpeta /css y una carpeta /images, o bien integras todo en ese único archivo o esta no es la herramienta adecuada, un conjunto de recursos no se ensambla solo.

Muchas herramientas exportan un .html autocontenido: un informe de cobertura de pytest o Jest, una ejecución de Playwright, un resumen de Allure o pandas-profiling, una auditoría de Lighthouse, un notebook de Jupyter guardado como HTML. Estos ya están diseñados para ser un solo archivo con todo integrado, lo que los convierte en una opción casi perfecta. En lugar de comprimir el informe y enviarlo por correo, donde el destinatario tiene que descargarlo, descomprimirlo y encontrar el archivo de entrada, envías un solo enlace que abre el informe interactivo en su navegador. El contador de visitas te indica que el cliente o compañero realmente lo abrió, y el enlace sigue funcionando para la próxima persona que lo necesite. Los gráficos interactivos y las tablas colapsables siguen funcionando siempre que su JS haya sido integrado en la exportación.

El correo HTML es un formato doloroso por sí solo, tablas anidadas, estilos inline, sin hojas de estilo externas, y antes de lanzar una campaña quieres que un responsable vea el resultado renderizado, no el código fuente. Pega tu salida de Mailchimp, Klaviyo o MJML compilado en un archivo .html, alójalo y envía el enlace para su aprobación. Dos advertencias honestas que vale la pena mencionar desde el principio: un renderizado en navegador no es un renderizado real en bandeja de entrada (Gmail y Outlook modifican el HTML a su manera, así que úsalo para revisar maquetación y texto, no para el QA final de entregabilidad), y cualquier píxel de seguimiento o enlace de rastreo de clics incluido en la exportación seguirá apuntando a tu ESP. Elimínalos de la copia de revisión si no quieres que tus propias aperturas de prueba se contabilicen.

Cuando estás haciendo prototipos, a menudo tienes un solo archivo que es todo el proyecto: un hero de landing con Tailwind vía CDN, una animación CSS de la que estás orgulloso, un sketch con canvas, una demo pequeña de D3 o Three.js, un componente que construiste para mostrar a un cliente. Un enlace en vivo supera a un CodePen o una captura de pantalla cuando quieres que parezca una página real en una URL real, sin el entorno del editor alrededor, se abre a pantalla completa en un teléfono. Mientras tus bibliotecas carguen desde un CDN por https y tu código esté integrado, funciona. Esta es la forma más rápida de convertir «aquí hay una idea aproximada» en «abre esto en tu teléfono» sin un pipeline de despliegue.

Tu HTML se sirve dentro de un frame en sandbox sin acceso al mismo origen. Esto protege tanto a ti como a cada visitante: el marcado no confiable no puede leer cookies, no puede acceder a la página padre y no puede actuar como si formara parte del host. Para el 95% de las páginas, maquetación, estilos, animaciones, bibliotecas CDN, scripts autocontenidos, nunca lo notarás. Donde sí lo notarás: código que asume que controla la ventana de nivel superior, que necesita cookies de primera parte o localStorage, o que habla con una API que solo permite un origen específico (CORS). Esas son preocupaciones de apps personalizadas, y para ellas un host real es la opción correcta. En cualquier plan puedes poner una página alojada en tu propio dominio en la barra de direcciones con SSL automático, pero la página sigue renderizándose en sandbox, por lo que se aplican los mismos límites de scripts. Para alojar una página con el fin de que sea vista, el sandbox es una característica, no una limitación.

Ideal para: desarrolladores, diseñadores, estudiantes, marketers y constructores sin código que tienen un único .html terminado y necesitan una URL ahora, una demo para un cliente, un informe para un manager, un fragmento para un compañero, una página única para un evento. No es la opción adecuada para: un sitio de varias páginas con enlaces internos entre archivos .html, una app que necesita un backend o variables de entorno, cualquier cosa que requiera tu propio dominio en la barra de URL, o un paso de compilación que genere una carpeta /dist con recursos separados. Para eso, usa un host real. Si tu único obstáculo era «no quiero configurar alojamiento para un solo archivo», esto elimina exactamente ese obstáculo y nada más.