Two current ViWeb Technology projects, for the businesses behind entertech.vn and datmachinpcb.com, share a starting point. Each had an existing WordPress site, and each owner was already familiar with an AI coding assistant such as Codex or Claude. On both projects ViWeb advised moving to a static site built with Astro, hosted on Cloudflare and deployed automatically from a Git repository, took on the migration work, and guides the client on making routine updates themselves with AI assistance once the site is launched. The routine need this serves is a familiar one: change a few lines of text, replace a photo, post a news item. This article explains the approach, who it suits, what it does not remove, and what a handover for this kind of site should contain.

What changes when the site is static

Astro pre-renders pages to HTML, CSS and JavaScript at build time by default. With the pages delivered as static files, the site needs no ongoing WordPress, PHP or database server upkeep, and there is no server for the client to administer; Cloudflare serves the built files, and small server-side features such as form handling run as serverless code on Cloudflare rather than on a server of the client’s own. Requests for static assets on Cloudflare Pages are free and unlimited, and a modest site can stay within the free plan’s build and file limits. Within those current limits, the hosting fee for the static site itself may be zero. The domain renewal remains, and so do AI tool access, any paid third-party feature, extra requirements and the human time spent reviewing and maintaining the site; those costs sit outside the hosting bill.

That advantage is real, so it is worth stating precisely. A static site removes one category of maintenance and one category of attack surface. It does not remove maintenance. Someone still owns the Cloudflare, Git and registrar accounts and keeps them secure. A bad edit still reaches the live site if nobody reviews it before release. Astro and its dependencies still receive updates. Cloudflare can have outages, and its free limits and terms can change. A contact form, analytics script or other integration can still break, and monitoring and recovery are still somebody’s job. What ViWeb can say is that a suitably scoped static site does not need the monthly WordPress and server upkeep the old site required. It still needs an owner.

Who it fits, and who it does not

The approach suits:

  • content that changes a few times a month, maintained by one or two people who will review a change before it goes live;
  • brochure, company profile, portfolio and catalogue sites, where the “database” is really a set of pages;
  • owners who already use an AI coding assistant, or are willing to learn one, with a developer available as a fallback.

Static does not mean giving up the contact form. Form submission and similar small server-side features can run on Cloudflare itself, through Cloudflare Pages Functions or Workers, so no separate WordPress, PHP or VPS server has to be managed for them. The result is static pages plus a small serverless backend, not a site with no backend at all; the function code is still part of the project and still has an owner. On these projects ViWeb keeps form submission working this way, with the processing running entirely on Cloudflare. Agree and test with the client at handover what should happen to each submission, whether it is emailed, stored or both, and add input validation and spam protection where relevant.

It is not a universal replacement for WordPress. A WooCommerce store, customer accounts, checkout, bookings or anything else backed by a database needs a backend, either on the existing platform or as separately scoped services with their own costs. Several non-technical editors publishing daily are usually better served by a CMS. Static also does not mean no JavaScript and no external APIs; it means the pages are built ahead of time, and anything dynamic is a deliberate addition that someone owns, keeps within its limits and backs up. Function requests count against Cloudflare’s Workers quotas rather than the free static allowance; a contact form on a modest site can fit the free tier, while heavier usage, storage and any email or delivery integration have their own scope, limits and possible costs. ViWeb assesses feature fit and any additional services before recommending the move.

This is the handover acceptance workflow ViWeb recommends, and ViWeb recommends writing it into the repository so it survives the handover.

  1. Open the project in an AI assistant such as Codex or Claude Code and describe the change in plain language: new opening hours, a replaced photo, a new news post.
  2. Read what the assistant changed. AI output can be wrong, so the diff is reviewed, not trusted.
  3. Push the change to a working branch, not straight to production. Cloudflare Pages can be configured to build a preview for non-production branches, so the client checks the result at a preview address before anything reaches the live site. At handover, ViWeb confirms the production branch and the preview and release rules with the client.
  4. Once the preview is approved, merge into the confirmed production branch. That push triggers the production build and deployment, so treat it as a release, not a routine save.
  5. Check the live site, and know the way back: a documented and tested route to the last known-good deployment, with the same review before it is used. Reverting the source alone does not restore data held by a dynamic feature or third-party service.

AI is not required to serve the prebuilt pages in this editing workflow; visitors load the built files. If the assistant is unavailable, the subscription lapses or the output is not right, the client can edit the Markdown and source files by hand or ask a developer.

On these projects ViWeb used Context Docs to record project decisions and the edit and deploy steps as reviewable Markdown in the repository. The client, or the next AI session, reads that context before making changes. The documents only help while they are reviewed and kept current.

The four handover checks still apply

Accounts and control. The site depends on the Cloudflare account, the Git host and the domain registrar. Each should be controlled by the business, with recovery on a business-controlled email address, individual members with scoped permissions, and no secrets in the handover document. AI assistant access is confirmed separately: which account the editor uses, who pays for it and what happens if it lapses; it does not need to be a corporate subscription. The repository and the static output provide an exit path, because the site can be built and hosted elsewhere, but a move still means re-pointing DNS, recreating the build configuration and integrations, and replacing any provider-specific feature. That is a dependency to plan for, not one that disappears.

Routine edits. The recommended acceptance test is the same as for any site: the person who will maintain the content makes three or four real edits through the cycle above, with ViWeb present but not driving. Where they got stuck becomes the edit guide. Anything that still needs a developer is listed and agreed now.

Backup, source and rebuild. The repository is the basis for rebuilding the live site. Confirm it contains the content, images and other assets, the build instructions and any export from the old WordPress site, and that a copy exists outside the Git host. A repository that cannot rebuild the site is not a backup. Confirm which branch deploys to production, and that the route back to a known-good deployment has been tested, not just described. Any dynamic feature or third-party service added later holds its own data and raises its own backup question that a source revert does not answer.

Support and responsibilities. Design and ongoing support remain separate decisions. Agree who updates Astro and its dependencies, who notices downtime or a broken form, who renews the domain, and how the client reaches ViWeb if an edit goes wrong. A static site can be handed over with no mandatory care plan; separately scoped support is available for clients who want it.

If you run WordPress, are comfortable with AI tools and mostly need routine edits, this is a conversation worth having early, because the choice shapes everything from hosting to handover. ViWeb Technology scopes this kind of migration and handover as part of a web design project. Monitoring, maintenance and backup is a separate agreement for clients who want it, not a condition of the site. The approach is recommended where it fits, not a fixed list of included deliverables.

References (checked 3 November 2026): Astro documentation on on-demand rendering, which confirms pages are pre-rendered at build time by default; Cloudflare Pages documentation on Git integration, limits, Functions, which run server-side code such as form handling on Cloudflare without a dedicated server, and Functions pricing; Context Docs.