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

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.

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.

Un ejemplo: blog estático con formulario externo

Considere un blog en el que las páginas se generan en build y el formulario envía datos a una API separada. El servidor del blog necesita entregar HTML, CSS, JavaScript e imágenes; la API necesita validar los campos, limitar el abuso y tratar el envío. Publicar el blog correctamente no demuestra que el formulario está funcionando.

En ese diseño, una actualización editorial exige generar y publicar un nuevo build. Si el contenido viene de un CMS, defina quien dispara esa generación y cómo reconocer un fallo. El sitio continuará mostrando la versión anterior hasta que el nuevo artefacto sea publicado; eso es parte del flujo editorial elegido, no un defecto del DNS.

Haga la publicación como un release, no como una copia improvisada

Guarda el commit de origen, la versión Node, el lockfile y el resultado de build. Prepare todos los archivos antes de reemplazar la versión pública. Una actualización parcial puede dejar HTML apuntando a archivos con hash que aún no han llegado al servidor.

Cuando la infraestructura permite un cambio de directorio o de release de forma controlada, utilice ese mecanismo. Si la publicación es por envío de archivos, planee el orden, preserve assets aún usados y mantenga una copia recuperable. No elimine archivos antiguos por nombre o fecha sin verificar si siguen referenciados.

• Abra directamente una URL interna, sin navegar antes por la home.
• Compruebe la URL canónica, el sitemap, robots y la URL de la imagen social.
• Prueba una dirección inexistente y compruebe si la respuesta HTTP es realmente 404.
• Envíe un mensaje de prueba y confirme su recepción en el destino.
• Simule la restauración del release anterior antes de automatizar actualizaciones.

Cómo analizar la velocidad sin atribuirlo todo al framework

La salida estática elimina el procesamiento de renderizado en cada visita, pero no evita que imágenes grandes, scripts de terceros o fuentes retrasen la página. Mida la página publicada en condiciones comparables e identifique el elemento que determina el LCP, los bytes transferidos y la estabilidad visual.

En una home con una ilustración importante, dimensiones explícitas y una imagen bien dimensionada pueden valer más que cambiar el servidor. Ya una API lenta exige investigar su propio procesamiento. Separe la medición de la página estática de la medición de los servicios que consume.

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.