¿Un sitio estático puede tener formularios, login o carrito?

Sí, si esa parte se hace con JavaScript en el navegador llamando a una API externa (tuya o de terceros). El sitio sigue siendo archivos; la API guarda los datos y valida las contraseñas.

¿Un sitio estático es lo mismo que uno hecho solo con HTML?

No. Estático describe cómo se entrega el sitio: archivos listos, sin procesamiento por visitante. Esos archivos pueden escribirse a mano o generarse con React, Astro, Hugo, Next.js y otras herramientas.

¿Un sitio estático es más rápido que uno dinámico?

Suele serlo, porque el servidor solo lee y devuelve un archivo, sin consultar una base de datos ni armar la página. Aun así, el tamaño de los archivos y las imágenes pesa mucho para el usuario.

¿Cómo actualizo el contenido de un sitio estático?

Cambias la fuente (texto, Markdown, datos), ejecutas el build otra vez y publicas los archivos generados. En cuanto los archivos nuevos llegan al servidor, el siguiente visitante ya recibe la versión nueva, sin reiniciar nada.

Qué es un sitio estático y cómo hospedarlo

Cuando abres una página, el navegador pide un archivo y el servidor responde. La diferencia entre un sitio estático y uno dinámico está en lo que hace el servidor entre la petición y la respuesta. El estático solo lee un archivo del disco y lo devuelve. El dinámico ejecuta código, consulta una base de datos y arma la página en el momento.

Esa diferencia cambia el costo, la velocidad, la seguridad y el tipo de hosting que necesitas. Para un portafolio, un blog, documentación o una página institucional, lo estático suele ser la opción más simple.

¿Cómo funciona un sitio estático por dentro?#

Según la documentación de MDN, el servidor de un sitio estático recibe un GET, busca el documento en su sistema de archivos y lo devuelve con estado 200 OK. Si el archivo no existe, responde 404. No cambia la respuesta según datos de la petición, como parámetros de URL o cookies, y no guarda estado entre una petición y otra.

En la práctica, el sitio es una carpeta:

text

dist/
  index.html
  acerca/index.html
  assets/app.3f9c1a.js
  assets/style.82b7d0.css
  imagenes/logo.svg

Una petición a /acerca/ se convierte en la lectura de acerca/index.html. Un servidor web (como nginx) está en línea y solo entrega el archivo. Ningún código tuyo se ejecuta en el servidor, así que no hay lenguaje de back-end, base de datos ni proceso de tu aplicación que mantener.

¿En qué se diferencia de un sitio dinámico?#

Un sitio dinámico genera la respuesta según la petición: quién es el usuario, qué producto, qué hora es. El servidor busca datos en una base y rellena una plantilla.

	Estático	Dinámico
Respuesta	Archivo listo, igual para todos	Generada en cada petición
Necesita back-end y base de datos	No	Sí
El contenido cambia	Solo con nuevo build y deploy	En cualquier momento
Superficie de ataque	Pequeña (sin código en el servidor)	Mayor (código, base de datos, sesiones)
Ejemplos	Blog, docs, landing page	Tienda, red social, panel

CSS, JavaScript e imágenes se sirven igual en ambos. Un sitio dinámico también tiene archivos estáticos; lo que lo define es la página generada por petición.

¿Estático significa sin interactividad?#

No. "Estático" se refiere al servidor, no al navegador. El JavaScript que corre en el navegador puede animar, filtrar listas, abrir modales y llamar a APIs. Un formulario de contacto, por ejemplo, puede enviar los datos con fetch a una API tuya o de un servicio de terceros.

Muchos frameworks también exportan el proyecto como archivos estáticos. Next.js, con output: 'export' en next.config.js, genera una carpeta out con HTML, CSS y JS (documentación). En ese modo no funcionan las características que dependen de un servidor: Server Actions, cookies, redirects y headers de next.config, Incremental Static Regeneration y rutas dinámicas sin generateStaticParams(). Vite, con vite build, genera la carpeta dist (documentación).

¿Cómo se genera y se publica un sitio estático?#

Puedes escribir HTML y CSS a mano o usar un generador (Astro, Hugo, Eleventy, Vite, Next.js y otros). El flujo es el mismo:

Escribe el contenido y el código fuente.
Ejecuta el build, que produce la carpeta final (dist, out, public, según la herramienta).
Publica el contenido de esa carpeta en un servidor que sirva archivos. Eso es el deploy.

Con Vite, por ejemplo:

bash

npm create vite@latest mi-sitio -- --template vanilla --no-immediate
cd mi-sitio
npm install
npm run build        # genera la carpeta dist/
npx vite preview     # sirve dist/ en local para revisarlo

Antes de publicar, abre la vista previa y prueba los enlaces. Las rutas absolutas como /assets/app.js se rompen si el sitio se sirve desde una subcarpeta; en ese caso ajusta la opción base de Vite.

¿Cómo funciona el caché en un sitio estático?#

Como los archivos solo cambian en el deploy, el caché es la mayor ganancia de velocidad. MDN describe el patrón de "cache busting" (Cache-Control): poner un hash en el nombre del archivo (app.3f9c1a.js), no modificar nunca ese archivo y publicar los cambios con un nombre nuevo. Así puedes cachearlo por un año:

http

Cache-Control: max-age=31536000, immutable

Ese header vale para los archivos de /assets/. El index.html, en cambio, recibe Cache-Control: no-cache, para que el visitante siempre reciba la versión nueva, que apunta a los archivos con el hash nuevo.

Generadores como Vite ya ponen el hash en el nombre de los archivos de assets. Los headers se configuran en el servidor o en el hosting.

¿Cuándo no basta un sitio estático?#

Necesitas un servidor con código cuando el contenido depende de cada visitante o cambia todo el tiempo y debe verse al instante:

login con sesión y páginas personalizadas por usuario;
carrito, pagos y panel de administración;
páginas generadas a partir de una búsqueda libre;
funciones en tiempo real, como un chat con WebSocket.

Un punto medio común: front-end estático y una API aparte para la parte dinámica. El sitio sigue siendo liviano y la API se encarga de datos y autenticación. Si esa API crece, puedes repartir la carga con un balanceador de carga.

¿Qué términos aparecen junto a "sitio estático"?#

SSG (static site generation): generar el HTML en el build, no en cada petición.
SPA: aplicación de una sola página que carga JavaScript y arma las pantallas en el navegador; puede servirse como archivos estáticos.
Jamstack: nombre de la industria para sitios estáticos que usan APIs para lo dinámico.
CDN: red que guarda copias de los archivos en varios lugares, cerca del visitante.

Para tener HTTPS y una dirección propia necesitas un certificado (cómo funciona Let's Encrypt) y un registro en el DNS (cómo apuntar un dominio).

Cómo hacerlo en Square Cloud#

Un sitio estático solo necesita un servidor web que esté en línea y entregue la carpeta del build. En Square Cloud, entre diversos runtimes, como Node.js, Python y Go, hay uno para sitios estáticos: en él nginx está siempre en ejecución sirviendo tus archivos, y ningún código tuyo se ejecuta en el servidor. Subes la carpeta (dist, out) como ZIP en el panel, con la CLI, desde GitHub o con la extensión de VS Code. El archivo squarecloud.app es opcional: el panel lo genera en el deploy, o lo escribes en la raíz del proyecto. Consulta los runtimes disponibles hoy en Runtimes.

Actualizar el sitio es reemplazar archivos. Un nuevo commit, una subida o una edición en el administrador de archivos quedan en línea al instante, sin rebuild ni reinicio. En una SPA, renombra el index.html del build a vite.html: el runtime responde con él a toda ruta que no sea un archivo, y sin él las rutas desconocidas reciben tu 404.html.

Sin código tuyo que ejecutar, el sitio suele caber en el mínimo de una aplicación web, 512 MB de la RAM de tu plan. El Hobby, desde R$12,49 al mes, ya sirve para sitios e incluye subdominio *.squareweb.app con HTTPS, CDN global y tráfico ilimitado (política de uso justo). El dominio propio empieza en el Standard: creas en tu registrador los registros DNS que indica el panel, y el TLS es automático. Empieza por el runtime de sitios estáticos.