No todo sitio estático está listo para el internet público apenas se sube.
Un preview para cliente puede tener copy provisional. Un caso de estudio de portafolio puede estar destinado solo a una persona de reclutamiento. Una documentación interna puede servir al equipo, pero no debería aparecer en resultados de búsqueda. Una landing de lanzamiento puede necesitar aprobación antes de conectar el dominio final.
Ahí es donde la protección con contraseña tiene sentido. No es un sistema completo de identidad. Es una puerta compartida delante de contenido estático que necesita un poco de control antes de mostrarse.
Para qué sirve la protección con contraseña
Los sitios estáticos suelen pasar por una etapa privada antes de ser públicos. El sitio ya está construido. Los archivos existen. El enlace funciona. Pero la audiencia todavía está controlada.
| Caso de uso | Por qué ayuda una contraseña |
|---|---|
| Revisión con cliente | Stakeholders pueden revisar una URL real antes del lanzamiento público. |
| Documentos internos | El equipo comparte notas, manuales o páginas de proyecto sin abrirlas a todo el mundo. |
| Portafolio privado | Algunos casos de estudio se pueden enviar a reclutadores, clientes o entrevistadores sin publicar todo. |
| Proyecto estudiantil o de equipo | Revisores pueden abrir el proyecto mientras el grupo decide qué quedará público. |
| Campaña en preparación | Copy, tracking, assets y layout móvil se revisan antes de promocionar. |
| PDF o paquete de recursos | Una página estática puede agrupar documentos, archivos o materiales detrás de un paso de acceso. |
La idea no es protegerse de un atacante determinado. La idea es evitar que algo circule públicamente por accidente mientras se revisa, corrige o aprueba.
Contraseña, noindex o autenticación completa
Son herramientas distintas. Tratarlas como si fueran lo mismo crea expectativas peligrosas.
| Herramienta | Qué hace | Qué no hace |
|---|---|---|
| Protección con contraseña | Bloquea el acceso casual con una contraseña compartida antes de servir el sitio. | No crea cuentas, roles, auditoría ni SSO. |
noindex | Pide a los buscadores que no muestren una página en resultados. | No impide que alguien con la URL abra la página. |
robots.txt | Da instrucciones públicas a crawlers sobre rutas. | Es público y no debe usarse como protección. |
| Autenticación de aplicación | Gestiona usuarios, sesiones, permisos e identidad. | Requiere lógica de aplicación, no solo hosting estático. |
| Control de acceso de red | Restringe acceso por proveedor de identidad, dispositivo, IP o política organizacional. | Es más pesado que lo que necesitan muchos previews de cliente. |
Google documenta noindex como control de indexación. Sirve para que una página no aparezca en búsqueda, pero no es una barrera de privacidad. Cloudflare Access y Vercel Deployment Protection muestran el otro extremo: sistemas de acceso más fuertes para aplicaciones y despliegues. Una puerta con contraseña vive en el medio.
Protege toda la experiencia estática, no solo el homepage
Un sitio estático es más que index.html.
Si solo el homepage está protegido, pero imágenes, scripts, PDFs o deep links siguen públicos, el preview todavía puede filtrarse. Una protección útil debe ubicarse delante de la experiencia publicada, incluidos los archivos que hacen que la página tenga sentido.
Antes de compartir un enlace protegido, revisa estas rutas:
| Tipo de ruta | Qué verificar |
|---|---|
| Homepage | La primera visita pide contraseña. |
| Deep links | Páginas de proyecto, docs o subrutas de campaña también requieren acceso. |
| Assets | Imágenes, PDFs, scripts y descargas no quedan expuestos por enlaces directos obvios. |
| Formularios | Si existe un formulario, funciona correctamente después del acceso. |
| Páginas de error | 404 o fallback no revelan copy sensible ni nombres de archivos. |
Esto importa mucho en portafolios y trabajo para clientes. Un homepage censurado no ayuda si las capturas sin publicar siguen abiertas en /assets/client-redesign-final.png.
Elige un flujo de contraseña adecuado
Las contraseñas compartidas son simples de operar. Aun así necesitan disciplina.
| Situación | Hábito práctico |
|---|---|
| Una revisión corta | Usa una contraseña compartida fuerte y cámbiala después de la revisión. |
| Varios equipos del cliente | Usa proyectos o enlaces separados si las audiencias no deberían mezclarse. |
| El enlace se reenvió demasiado | Cambia la contraseña y envía la nueva solo a quienes deben verla. |
| El proyecto se vuelve público | Desactiva la protección después de la aprobación final y el lanzamiento del dominio. |
| El trabajo sigue siendo sensible | Mantén una página pública editada y comparte detalles solo con personas aprobadas. |
No uses una contraseña de broma fácil de adivinar para una revisión con cliente. Usa algo suficientemente largo y compártelo por un canal coherente con la sensibilidad del trabajo.
Dónde no alcanza una contraseña
La protección con contraseña es útil porque es liviana. Ese también es su límite.
Usa autenticación real de aplicación cuando necesites:
- Cuentas o invitaciones por persona.
- Permisos distintos para distintos usuarios.
- SSO con Google Workspace, Microsoft Entra, Okta u otro proveedor de identidad.
- Logs de auditoría que muestren quién vio qué.
- Requisitos legales, contractuales o de compliance sobre acceso.
- Revocar a una persona sin cambiar el acceso de todas.
- Datos sensibles de clientes, pagos, salud o registros regulados.
Para un preview estático, una contraseña compartida suele ser suficiente. Para un portal de clientes, un sistema interno o un flujo regulado, no lo es.
Errores comunes en previews estáticos protegidos
La mayoría de los problemas son pequeños descuidos operativos.
| Error | Mejor enfoque |
|---|---|
| Enviar el enlace antes de activar la protección | Activa la puerta primero y prueba en una ventana privada. |
| Olvidar deep links | Abre directamente páginas de proyecto, docs, assets y PDFs. |
| Usar una contraseña para siempre | Cámbiala después de revisiones, lanzamientos o reenvíos accidentales. |
Tratar noindex como privacidad | Usa noindex para búsqueda, no para control de acceso. |
| Publicar detalles confidenciales | Edita nombres, métricas, capturas y rutas privadas antes de subir. |
| Dejar la puerta activa después del lanzamiento | Decide si el sitio final será público, protegido o dividido en versiones. |
Un preview protegido merece la misma revisión de contenido que un sitio público. La contraseña reduce exposición accidental; no vuelve inofensivo publicar sin cuidado.
Cómo encaja con el despliegue estático
La protección con contraseña funciona mejor cuando forma parte del flujo de deployment.
Un flujo práctico:
- Construye o exporta el sitio estático.
- Sube la carpeta, ZIP, HTML, build del framework, portafolio o página con PDFs.
- Activa la protección antes de compartir el preview.
- Envía el enlace y la contraseña a revisores.
- Corrige copy, archivos, vista móvil y assets.
- Cambia la contraseña si cambia la audiencia.
- Quita o conserva la protección cuando se tome la decisión final.
Así la revisión ocurre cerca del sitio real. Las personas ven las mismas rutas, assets y comportamiento responsive que usará la versión pública.
Cómo lo maneja DeployPages
DeployPages está pensado para publicación estática, así que su protección con contraseña está orientada a previews estáticos y uso privado, no a autenticación backend.
Puedes publicar una carpeta estática, ZIP, proyecto HTML, portafolio, export de documentación, sitio generado con IA o una página con assets PDF, y luego activar la protección desde los controles del proyecto cuando el plan del workspace la incluya. Los visitantes deben ingresar la contraseña del proyecto antes de ver el sitio publicado. El mismo proyecto también puede usar analytics, dominios personalizados, rollback instantáneo y deploys por CLI.
El flujo queda claro: sube el sitio, protégelo durante la revisión y decide después si la versión final seguirá privada o pasará a un dominio público.
Checklist antes de compartir
Antes de enviar un sitio estático protegido con contraseña:
- Abre el enlace en una ventana privada y confirma que aparece la pantalla de contraseña.
- Prueba un deep link, no solo el homepage.
- Intenta abrir enlaces directos a PDFs, imágenes, scripts y descargas importantes.
- Elimina nombres confidenciales, métricas privadas, comentarios internos y rutas de borrador.
- Usa una contraseña compartida fuerte y guárdala donde el equipo pueda rotarla.
- Comparte la contraseña separada del enlace si el trabajo es sensible.
- Decide cuándo se quitará, cambiará o mantendrá la protección.
- Conserva una ruta de rollback antes de reemplazar una versión revisada.
La protección con contraseña no está para complicar un sitio estático. Está para hacer menos riesgosa la etapa privada mientras el trabajo se evalúa, corrige y aprueba.