Updated October 9, 2026.
“Static or dynamic?” describes how a website delivers content. It does not, by itself, tell you whether your staff can edit pages, whether the site is affordable, or whether it will be fast.
Start with the work the site must do. A service page, a staff-edited blog, and a private customer account have different requirements. One website can combine several approaches.
The difference in page delivery
A static page is prepared ahead of the request. A server can send the finished HTML file to visitors. A server-rendered dynamic page is generated when requested, potentially using current data or information specific to that visitor. Astro supports both approaches; see its rendering guide.
These are simplified descriptions of the page response, not complete inventories of every service behind a site. A prebuilt marketing page can still submit a form to an application. A dynamic application can serve cached responses rather than repeating the same work for each visitor. HTTP caching adds another layer to how responses are delivered.
| Question | Prebuilt page | Page generated on request |
|---|---|---|
| When is the initial HTML prepared? | Before the visitor asks for it | While handling the request, unless a cached response is used |
| How does changed content reach visitors? | Through the configured publishing/build process | Through the application and any relevant caches |
| Can the page be interactive? | Yes; browser scripts or external services can add behavior | Yes; browser scripts can also add behavior |
| Does it require an editing dashboard? | No, but one can be connected | No; an editing dashboard is a separate product decision |
| What should you evaluate? | Build/publishing workflow and connected services | Application, data, caching, and operational responsibilities |
Editing is a separate choice
A content management system, or CMS, gives people a way to organize and edit content. It can feed prebuilt pages or a live application. Astro’s CMS integration guide includes options for editing content outside the code repository.
For an owner, the useful test is practical: can the right person make a routine change, preview it, and publish it without unwanted access to other settings? Ask about approvals, scheduled content, new page creation, and how long publication takes. “Static” does not automatically mean developer-only editing, and “dynamic” does not automatically provide a good admin interface.
WordPress combines publishing tools with a large extension ecosystem. An existing WordPress site may still be a sensible fit for a team already using those tools. Moving away from it should solve a concrete problem, not merely change a technology label.
Decide where live functionality is needed
An illustrative contractor site might use prebuilt service and project pages, a CMS for new portfolio entries, and a separate service to receive quote requests. That does not make the inquiry system maintenance-free; it simply separates it from the public page delivery.
A customer portal has a different requirement: it must verify who the visitor is and return only the records that person may access. Real-time booking availability, payments, and account data also require services beyond a fixed public HTML file. Those services may be part of the same application or provided by another system.
A mixed approach can fit both needs, but it introduces integration work. Agree on what happens when a provider changes its API, fails to respond, or stops supporting a feature. More services are not automatically cheaper or easier to maintain.
Compare complete costs
Architecture alone does not establish a market price. A simple templated site and a custom booking application are different scopes even if both are described as dynamic. Likewise, a bare hosting account is not equivalent to a managed service that includes content work.
Ask for these items separately:
- Initial work: design, content preparation, development, migration, testing, and training.
- Recurring services: hosting, CMS subscriptions, booking or commerce tools, and domain renewal.
- Ongoing work: software updates, monitoring, backups, content changes, and support.
- Later changes: new pages, new integrations, or a change in the editing workflow.
- Exit and ownership: access to content, source files, accounts, and any export or migration work.
Our new Astro website builds start at $5,000. Our Astro hosting plan is $300/month, including any updates to existing pages; new pages are quoted separately. CMS and integration requirements should be confirmed in the proposal. Those are our service prices, not universal prices for static websites.
For illustration, a project quoted at exactly $5,000 plus twelve months at $300 would total $8,600 before additional agreed work or other charges. Use the actual proposal to compare alternatives over the same period. Lower infrastructure cost alone does not establish lower total ownership cost.
Why we use Astro for new sites
Astro lets us prepare content pages ahead of time and add interactive components where the project needs them. Its islands architecture separates interactive components from the rest of the page. It also supports on-demand routes when the application requires them.
Our own site uses Astro with static output. That is a description of our implementation, not proof of a particular speed, ranking, or reliability result. Large assets, scripts, integrations, hosting, and implementation choices still matter.
We focus new website work on Astro. If you need a different platform, we can discuss whether the project fits our services rather than promising a new WordPress build. This comparison is intended to help you evaluate a proposal, not steer every project toward the same stack.
Five questions to put in your brief
- What do customers need to read, submit, buy, or manage?
- Which information changes for each visitor or depends on current availability?
- Who edits content, and what does a routine publishing task look like?
- Who owns updates, recovery, and support for each connected service?
- What is the full cost over your comparison period, including work outside the base plan?
Those answers are more useful than choosing a winner between static and dynamic. For the ongoing responsibilities, see our guide to managed static websites. For the wider project process, use the website planning guide.