Ir al artículo
Deploy y desarrollo

Cómo publicar un sitio web Astro en el panel WordPane

De build al dominio: publique un sitio Astro en WordPane, configure la carpeta pública y prepare actualizaciones por Git sin confundir estático con SSR.

Cubierta del artículo: Cómo publicar un sitio web Astro en el panel WordPane — WordPane Cloud
Comparte esta guía
WhatsApp (abre en nueva pestaña)LinkedIn (abre en nueva pestaña)Facebook (abre en nueva pestaña)

Astro es una opción para sitios institucionales, blogs, documentación y páginas de producto. También combina bien con un flujo en el que la IA ayuda a escribir componentes y contenido. Pero terminar la interfaz en el ordenador no concluye la publicación: necesita transformar el proyecto en archivos de producción, colocarlos en el directorio correcto y probar la dirección real. Esta guía presenta un camino estático verificable en el panel WordPane y explica lo que cambia cuando existe procesamiento en el servidor.

Antes de empezar: identificar la salida del proyecto

Abra el repositorio y vea el package.json, el archivo de configuración de Astro y las integraciones usadas. El caso más simple es un sitio completamente prerenderizado. En este escenario, build produce archivos que un servidor web puede entregar, sin mantener el proceso de desarrollo del Astro funcionando. La documentación oficial de deploy indica dist como directorio estándar de salida.

Si el proyecto utiliza variables dinámicas, sesiones o renderización bajo demanda, puede exigir un ajuste y un runtime. No intente publicar solo la interfaz y esperar que la autenticación o la API aparezcan automáticamente. Anote también servicios externos, variables, dominio, formularios y destino de los datos enviados. Esta lista define el ambiente y las tareas de validación.

Gere y compruebe la versión de producción

Ejecute las órdenes a seguir en la carpeta del proyecto. El ejemplo presupone npm y package-lock.json versionado; si usa otro administrador, mantenga el administrador y el lockfile del proyecto. Compruebe la versión Node requerida por su versión de Astro. Pare si la instalación o build falla y corrija el error antes de enviar archivos.

Utilice la ubicación previa para verificar las páginas y el resultado del build. La previa sirve para conferencia, no como servicio permanente de producción. Abra una página interna directamente, examine las imágenes y prueba el formulario. Consulte si la URL pública y la canónica apuntan a su dominio, en lugar de la dirección localhost.

En el ordenador de desarrollo o en el entorno de build
npm ci
npm run build
npm run preview

Prepare la aplicación en el panel

En el área del cliente, elija la infraestructura compatible y espere a la conclusión de la configuración del servidor. Para un sitio estático, evalúe un entorno web que permita servir los archivos del proyecto. Node no necesita contratar un runtime Node solo porque Astro usa Node durante el build. La generación puede suceder en su ordenador o en una automatización de CI.

El camino observado en el panel es Applications → Create an Application → Custom. Los campos de versión PHP de este formulario pertenecen a la aplicación personalizada PHP; no transforman el Astro en PHP. El uso relevante para el sitio estático es preparar dominio, usuario y directorio público que servirá los archivos. Revise ese comportamiento en el stack elegido.

  1. Informe Application Name y seleccione Primary Domain o Test Domain.
  2. Para dominio propio, informe la dirección y revise la opción SSL; DNS necesita apuntar al destino correcto.
  3. Elija Custom y revise System User en Show Advance Options.
  4. Consulte Custom Webroot. El destino debe corresponder a la carpeta que recibirá el contenido generado, no al directorio de código fuente.
  5. Cree la aplicación y comprueba el camino en File Manager antes de enviar build.

Envíe el contenido de dist al webroot

En File Manager de la aplicación, confirme el breadcrumb y el camino. Webroot observado en nuestra documentación es public_html; un proyecto con Custom Webroot puede usar otro destino. Envíe el contenido interno de dist a esa carpeta, preservando subcarpetas y nombres. Si coloca la carpeta dist entera dentro de public_html, el index.html puede quedar un nivel por debajo de lo que el servidor busca.

Use File Manager o SFTP con el usuario correcto. Mantenga una copia del sitio anterior antes de reemplazar archivos. No envíe .env, .git, archivos de credenciales o dependencias del entorno de desarrollo a la carpeta pública. Para futuras actualizaciones, publique el build completo de forma consistente: HTML nuevo con assets antiguos, o lo contrario, puede romper la página.

Integre Git sin saltar la etapa de build

La integración Git permite vincular cuenta, repositorio y branch a la aplicación que proporciona este recurso. Ella no significa, por sí solo, que todo proyecto tendrá dependencias instaladas y build ejecutado. En la documentación WordPane, la aplicación creada por el método Git ofrece opciones propias de actualización; no hay un campo de build universal confirmado para todas las stacks.

Puede generar los archivos en una rutina externa y publicar los artefactos, o ejecutar un procedimiento de build en el ambiente que tenga runtime, permisos y recursos necesarios. Documente cual método su equipo adoptó. Sólo habilite actualización automática después de probar que un commit produce los archivos finales en el webroot y que existe una forma de recuperar la versión anterior.

Lo que cambia con Astro y SSR

Para renderizar en el servidor, consulte la adaptación Node oficial y la documentación correspondiente a la versión del proyecto. Esta arquitectura necesita un proceso de producción, configuración de ejecución y proxy. El ambiente Node.js de WordPane está en beta; consulte la versión, comando, puerta, variables y controles disponibles antes de la contratación.

No copie el formulario PHP como si fuera el formulario Node. Si la aplicación depende de un runtime de edge o de un servicio específico de otro proveedor, prepare la adaptación. El alojamiento del código en la VPS no reproduce automáticamente servicios de Vercel o Cloudflare. Para ese caso, envíe los requisitos y el comando de producción al equipo antes de seguir.

Valide el dominio y resuelva las fallas más comunes

  • Página de inicio funciona, pero una ruta vuelve 404: Compruebe la salida de build, las reglas de URL y la estructura de carpetas.
  • CSS o imágenes fallan: vea el camino base y si los assets generados fueron publicados junto a HTML.
  • Formulario no envía: verifique la variable real y el backend responsable; HTML estático no procesa mensajes solo.
  • Un cambio no aparece: confirme branch, build, directorio de destino y caché del navegador.
  • SSL no concluye: Compruebe DNS y la configuración del dominio antes de repetir la emisión.
  • Antes de divulgar, prueba menu, páginas internas, metadatos sociales y el registro que ofrece su proyecto.

Donde WordPane agrega a la rutina

La plataforma reúne la creación o conexión del servidor, seguimiento de operaciones y consumo en el área del cliente. En el panel de control, usted encuentra herramientas para dominio, archivos, integración Git, logs y copia de seguridad conforme al entorno configurado. Esto organiza tareas que continuarían existiendo incluso cuando la IA produce buena parte del código.

La recaudación por hora permite acompañar el consumo del medio ambiente en el saldo. El costo de la infraestructura es separado de modelos de IA, APIs y servicios externos usados por el proyecto. Comience con una publicación de prueba, registre los pasos que funcionaron y elijan los recursos basándose en el comportamiento observado. El primer resultado útil es un sitio web accesible, actualizable y recuperable.

Elija el entorno del proyecto

Compara los planes o envíe los requisitos de la aplicación al equipo WordPane.

Configurar mi proyecto en WordPaneConsultar la documentación del panel

Referencias para profundizar