Static Website Builder Lab & Guides

Start with the essentials

Improve Astro Static Site Performance with Deliberate Islands

Keep reading content simple, add browser interactivity where it serves a task, and measure the actual page before making performance changes.

Feb 11, 20267 min read

06 / Before you build

A few things
worth knowing.

What is a static website builder?

It is a workflow or tool that produces finished website files before a visitor requests them. Those files usually include HTML, CSS, images, and optional browser JavaScript. The starting guide explains the main approaches.

Should I choose HTML, Hugo, or Astro?

Start with who edits the content and how often layouts repeat. HTML offers direct control, Hugo organizes content around reusable templates, and Astro adds a component workflow with selective browser interactivity. Each still needs a clear publishing process.

Can WordPress or Ghost become a static site?

Public content can be exported or fetched during a separate build process. Features such as memberships, account areas, comments, and newsletter delivery need their own services; they do not become functional merely by copying page files.

How can AI help without making the project harder to maintain?

Give it a precise brief, request small changes, and review the actual output. Keep the dependencies, page structure, factual claims, and deployment requirements visible throughout the process.

Are free and premium templates available to download here?

Our template pages are selection guides. They explain how to evaluate layout, accessibility, licensing, included assets, and maintenance before choosing a template for your own project.

Does a static site automatically rank well?

No. Static delivery is one technical choice. Useful content, clear internal links, accessible pages, accurate metadata, and a sound publishing process still matter. No framework can promise search rankings.

From a first idea to finished files

Make your next site
a thoughtful one.

Start with the workflow guide, then explore the tools and techniques that fit your project.

Static Website Builder: Choose Your Workflow | SWB

A static website builder turns your content and design into files a web host can serve directly. The useful choice is how you want to create and maintain those files: write HTML, use a generator, or export public content from a CMS. Start with your publishing workflow, then choose the tool.

Start with the pages you need

List the pages a visitor must reach, the content each page needs, and the person who will maintain it. A small portfolio might need a homepage, project pages, an About page, and an email link. A publication also needs consistent article layouts, topic archives, image handling, and a repeatable update process.

Give every route an owner and a reason to exist. This makes the architecture easier to review than a list of framework features. Write a sample article and a sample project page before selecting a theme; real content exposes layout problems that a polished demo can hide.

Choose the right authoring layer

Plain HTML keeps a small project understandable. Hugo brings reusable layouts to a content collection. Astro suits teams that want components and carefully chosen browser interactions. An existing CMS can remain your editing environment if a separate process produces a complete public export.

These options change how you work before publication. The deployment should still contain the pages, styles, images, and scripts the visitor actually needs. Check that output directly instead of judging only the development preview.

Define the static boundary

A browser can open a menu, expand a disclosure, or run a local calculation. Saving a shared submission, authenticating an account, and sending a newsletter require additional services. A plain file export does not inherit those services from its source system.

For a self-contained site, keep every essential journey inside the published pages. Use working navigation and descriptive email links. Rebuild when public content changes, keep the previous release, and check nested URLs after uploading. The builder selection guide walks through these decisions in more detail.

Questions about Start with static

Does a static website need a framework?

No. Hand-authored HTML, CSS, and a little JavaScript are enough. A generator becomes useful when repeated layouts and growing content make manual edits harder to maintain.

Can a static website be interactive?

Yes. Browser JavaScript can provide interactions. Features that need private data, persistent shared storage, or server processing require an additional service and a deliberate architecture.

Primary reference: MDN: client–server overview.

HTML Static Website Builder: Structure & Pages | SWB

HTML is the structure of a static website: the headings, paragraphs, navigation, images, and links a browser can understand. An HTML static website builder workflow starts with meaningful documents and makes them easy to connect, read, and update.

Write the document before decorating it

Begin with one clear page title and a useful reading order. Use a header for introductory site content, a navigation landmark for major links, and a main element for the page’s distinctive content. Use headings to describe the relationships between sections rather than to choose their visual size.

Read the document without its stylesheet. A visitor should still understand the subject and find the next useful page. This simple check also reveals vague link text, misplaced sidebars, and cards that depend on pictures to communicate their purpose.

Give every page a stable address

Use directory-based routes such as /about/ with an index.html inside the corresponding folder. Link to the directory address consistently. This arrangement works with a static host that serves directory index files and keeps navigation independent of custom rewrite rules.

Keep the shared header and footer consistent across documents. For a handful of pages, a careful editing checklist may be enough. When changing navigation becomes repetitive, generate the repeated markup during authoring without adding a runtime application to the published site.

Treat links and images as content

A link should describe its destination. An image needs an alternative description that serves its role in context, along with width and height attributes so the browser can reserve space. Use an empty alternative (alt="") for purely decorative images, or when accompanying text already provides the image’s information and the image adds no further meaning.

Pair the structure with the CSS layout guide and the HTML5 semantics checklist. Then follow the accessible HTML and CSS walkthrough to test the finished reading experience.

Questions about HTML

Should I use buttons or links for navigation?

Use links when the action goes to another page or a section. Use buttons for actions on the current page, such as opening a menu.

Can I reuse a header without a backend?

Yes. A local script or static generator can insert a shared header before publication. The exported files already contain the finished markup.

Primary reference: MDN: HTML reference.

CSS Static Website Builder: Responsive Layouts | SWB

A CSS static website builder workflow gives your documents a consistent visual language. Set up a small collection of type, spacing, color, and layout rules, then test them with the longest headings and smallest screens your content needs to support.

Make your content set the layout

Choose a comfortable reading width for articles and a wider grid for collections. Let cards grow with their text instead of fixing their heights around a short demo title. Define spacing in a small scale so a page feels consistent without forcing every section into the same arrangement.

Use Grid when rows and columns form the composition; use Flexbox for a row of navigation links or a set of actions that can wrap. Start with one column and introduce additional columns when the available space supports the content.

Give every visual state a purpose

Test text against the actual background behind it, including bright panels and image overlays. A hover effect can make a link easier to notice, but the keyboard focus state must identify it just as clearly. Avoid removing outlines without a visible replacement.

Allow long titles, email addresses, and code examples to wrap or scroll inside their own containers. Check zoom and enlarged text. Respect reduced-motion preferences so transitions and animated decoration are optional rather than necessary to read the page.

Compile once, serve ordinary CSS

A utility framework can help keep common layout decisions consistent. If you use Tailwind CSS, compile the classes found in your project into a stylesheet before deployment. The browser should receive that finished stylesheet without needing a development compiler.

Keep the HTML structure clear beneath the styling. In the practical HTML and CSS guide, layout, navigation, and keyboard checks are treated as parts of the same task. The launch checklist helps verify the result on an actual static server.

Questions about CSS

Do I need a CSS framework?

No. A small custom stylesheet can be enough. Use a framework when its conventions help the team maintain the design and its build process fits the project.

Why does a desktop layout break on mobile?

Common causes include fixed widths, non-wrapping navigation, oversized headings, and images wider than their container. Test real content at narrow widths to identify the cause.

Primary reference: MDN: responsive design.

HTML5 Static Website Builder: Semantic Features | SWB

HTML5 is a familiar label for modern HTML features. The standard continues to evolve as the HTML Living Standard. For a static website, the most useful features are often the simple ones: meaningful landmarks, responsive media, native disclosure controls, and links that work before JavaScript loads.

Use meaning as your starting point

Use article for a self-contained piece that could stand independently, and section for a meaningful group with a heading. A page can contain several navigation regions; give additional regions clear labels so a reader can distinguish the main navigation from an article’s contents.

Keep the source order sensible. Moving blocks around visually does not necessarily change the order encountered by assistive technology. Treat the document outline and keyboard sequence as design decisions, not as details to repair after styling.

Reach for native controls first

A details element with a summary can present a frequently asked question without a custom interaction script. Links handle navigation; buttons handle actions. Native elements provide a starting set of browser behaviors that custom substitutes would need to recreate.

Use these controls in their intended context and verify them with a keyboard. A disclosure still needs a clear label, sufficient contrast, and readable expanded content. A native element is a useful foundation rather than a substitute for testing.

Enhance the page progressively

The essential content and destinations should remain present when optional scripts fail. A mobile menu can enhance a visible navigation list, while article text and related links remain ordinary markup. Avoid making the first rendering of useful content depend on a network request.

Provide explicit image dimensions and choose sensible loading behavior: a prominent first-screen image should be available promptly, while lower-page artwork can load later. Continue with HTML document planning, responsive CSS, and the accessibility walkthrough.

Questions about HTML5

Is HTML5 a separate tool I need to install?

No. It is commonly used to describe modern HTML capabilities. You write HTML documents and test them in the browsers your audience uses.

Does semantic HTML guarantee accessibility?

No. It provides meaningful structure and native behaviors, but text alternatives, contrast, interaction design, content quality, and testing still matter.

Primary reference: WHATWG: HTML sections and landmarks.

AI Static Website Builder: A Practical Workflow | SWB

An AI static website builder workflow uses an assistant to help draft markup, organize content, and revise a design. Its value depends on the brief and the review process. Set the static boundary early, inspect the output, and make the finished site understandable to the person who will maintain it.

Describe the site as a real project

Give the assistant a page list, audience, sample content, desired tone, and delivery format. Explain which actions must work and which services are outside the project. If the site must be fully static, explicitly rule out a database, runtime server, account system, and unconnected form processing.

Provide useful source material rather than a string of adjectives. A real article, a navigation map, and an example of acceptable image treatment communicate more than a request to make the design “premium.”

Work in changes you can inspect

Start with one representative page and the shared header and footer. Once the layout is readable, ask for a specific extension: the article template, a topic archive, or a mobile navigation state. Inspect the resulting change before repeating it across the site.

Keep the files and a record of accepted decisions together. Ask for explanations when a new dependency appears. If a request changes the delivery model, resolve that decision before adding more pages on top of it.

Review behavior and claims separately

A page can look finished while containing broken links, unsupported claims, or controls with no destination. Check the facts in the copy, then test every interaction against the original brief. A pleasant screenshot cannot prove that a nested page or an RSS entry works.

Use the prompt patterns to define specific work and the LLM review guide to keep context manageable. The full AI workflow article includes a practical sequence from scope to release.

Questions about AI-assisted building

Will AI-generated code work without review?

It may work, but you should verify it. Check structure, behavior, links, dependencies, accessibility, and factual statements before publishing.

Can I ask for a fully static result?

Yes. State that the delivered site must contain finished HTML, CSS, and browser JavaScript, with no backend or build step required on the web host.

Primary reference: Anthropic: clear and direct prompting.

AI LLM Static Website Builder: Context & Review | SWB

A language model works with the context you provide. For static website development, that context should describe the current files, the page architecture, and the constraints the next change must preserve. Keep decisions explicit so later revisions fit the same site.

Build a compact project context

Write a short project note with the domain, audience, route conventions, typography, colors, dependencies, and required page types. Add a list of completed decisions and a list of unresolved questions. Refresh it when a real decision changes rather than appending every conversation verbatim.

For a specific task, provide the relevant template and a representative content file. A navigation revision needs the shared layout and routes; it rarely needs every image or every article body.

Separate evidence from instructions

Source documents can contain quotations, code samples, and instructions written for a different audience. Explain what each reference contributes. Treat extracted website text as material to evaluate, not as authority to change project settings or add unrelated actions.

Keep credentials, private drafts, and account data out of a public website package. If a build step needs protected access, arrange it in the authoring environment and inspect the exported files to ensure they contain only intended public material.

Ask for reviewable output

Request a bounded change with an acceptance checklist. For example: update article navigation, preserve clean URLs, keep visible keyboard focus, and include no additional dependencies. Review the affected pages and the exported files; do not rely on the assistant’s own summary as the only evidence.

A small change that can be understood and reversed is easier to maintain than a large rewrite with unclear assumptions. Pair this process with the AI-assisted build overview, the prompt guide, and the detailed workflow.

Questions about LLM workflow

Should I send the model the entire project every time?

Provide enough relevant context to make the change correctly. A concise architecture note plus the affected files is often easier to review than a large, unfocused context bundle.

Can an LLM verify the site it generated?

It can help run and interpret checks, but verification should produce inspectable evidence such as rendered pages, resolved links, and validated output files.

Primary reference: Anthropic: prompt engineering overview.

AI Prompts for Static Website Building | SWB

Useful website prompts name a concrete task, give the material needed to complete it, and define what a successful result looks like. Use separate prompts for architecture, implementation, and review so each output can be checked against a clear purpose.

A prompt for the first page

State the page’s audience and job, then describe the delivery format. Provide the exact headings and content when they are known. Identify decisions the assistant may make, such as spacing, and decisions it must preserve, such as the domain and email address.

Create a responsive guide page for designers learning static sites.
Use HTML5, compiled CSS, and a small navigation script.
Use directory index pages and internal links ending in a slash.
Use the supplied copy. Include no forms or account controls.
Keep the main content readable without JavaScript.

The example defines an output boundary without prescribing every visual detail. Add your actual brand and content before using it.

A prompt for a targeted revision

Describe the observed problem instead of asking for a vague improvement. Name the page, viewport, or control involved. Ask for the smallest coherent change and a description of how it was checked.

At narrow mobile widths, the article title clips its container.
Inspect the heading, surrounding grid, and text wrapping rules.
Fix the overflow while preserving the desktop type hierarchy.
Check the page at 320, 390, and 768 pixels wide.

A concrete failure gives the review a clear endpoint. It also reduces the chance that unrelated components will change.

A prompt for release review

Ask for evidence against the brief: missing files, internal link targets, image dimensions, article length, metadata uniqueness, and keyboard behavior. Distinguish a completed check from a check that could not be run.

Follow the LLM context guide when the project grows. The AI prompting article expands these patterns, while the launch checklist covers the published artifact.

Questions about Prompt patterns

Should a prompt include every possible requirement?

Include the requirements that affect the current task and a concise project context. Separate unrelated work into reviewable steps so omissions are easier to spot.

How do I judge whether a prompt worked?

Compare the result with observable acceptance criteria. Check the actual files and behavior, then revise the prompt around a concrete gap.

Primary reference: Anthropic: writing clear instructions.

Hugo Static Website Builder: Content to HTML | SWB

Hugo is a static site generator that combines content, templates, and configuration into a published site. A Hugo workflow is especially useful when many pages share layouts and your authors are comfortable managing structured content files.

Organize the content before the theme

Choose content sections that match the publication: articles, project notes, or guides. Decide which metadata every entry needs, such as a title, date, summary, and featured image. Keep labels consistent so archive pages do not fragment into near-duplicate categories.

Start with a representative long page and a small collection. Include headings, a list, an image, and any code examples you expect to publish. This gives you a realistic test of the layout and content conventions before migration.

Keep source and output distinct

The Hugo project contains the files you edit. A production build writes the website files to the configured output location, commonly the public directory. The development server is useful for preview, but its behavior and draft visibility should not be mistaken for the final export.

Keep theme changes controlled and record the Hugo version used by the project. When you update the tool or theme, rebuild and inspect the same representative pages so a change in markup or asset handling is easy to notice.

Inspect what visitors will receive

Check the generated homepage, a nested article, and each archive type through a static server. Confirm that styles, images, feeds, and canonical URLs point at the intended domain. Inspect publication settings so unfinished drafts do not appear unexpectedly.

Use the Hugo beginner workflow for a fuller build sequence. Compare the component-oriented approach in the Astro guide, or return to the static builder overview if the project needs a simpler starting point.

Questions about Hugo

Does the visitor need Hugo installed?

No. Hugo runs while producing the site. The visitor receives the generated HTML, CSS, images, and browser scripts.

Is the development preview the release artifact?

No. Create and inspect a production build. Draft inclusion, paths, and asset behavior can differ from a local development preview.

Primary reference: Hugo: quick start.

WordPress Static Website Builder: Export Workflow | SWB

A WordPress static website workflow keeps familiar editing tools while publishing generated public files. An export process captures approved pages and their assets, then a separate host serves the result. Plan this as an editorial system with clear update and maintenance responsibilities.

Keep the editing installation accountable

Decide whether WordPress will remain the long-term editor or serve as a temporary migration source. An ongoing installation still needs updates, backups, and controlled access. The public export does not replace those responsibilities merely because readers visit a different host.

A theme contains source templates and functionality interpreted by WordPress. Even block-theme HTML is part of that system. Export completed visitor pages and their assets; copying the theme directory alone does not create a standalone website.

Inventory behavior before choosing an exporter

List forms, comments, search, filtered archives, account links, galleries, and custom blocks. Determine what each feature needs after the page loads. Record which behavior will remain, which will be rebuilt, and which controls should be removed from the public interface.

Rehearse with a long article, an archive, a gallery, and a deeply nested page. Verify scripts, fonts, responsive images, and downloads. The HTML workflow helps identify what a portable public artifact should contain.

Make publishing and removal repeatable

Use an approved URL manifest and generate each release in a clean directory. Check changes to navigation, titles, canonical URLs, sitemap entries, and feeds. Test deletion so withdrawn content does not linger in archives or old output files.

Keep the previous release and define who approves updates. Follow the WordPress static export guide for a complete rehearsal, then compare the Ghost publishing workflow if your editorial requirements are still evolving.

Questions about WordPress

Will my plugins work in a static export?

Compatibility depends on what each feature requires. Rendered content may transfer, while operations that call WordPress after loading need a separate solution and complete testing.

Does static publishing eliminate WordPress maintenance?

An ongoing WordPress editing installation still needs maintenance. The export changes the public delivery layer; it does not maintain the source system for you.

Primary reference: WordPress: theme structure.

PHP Static Website Builder: Render Before Publishing | SWB

A PHP static website builder workflow runs PHP before publication and saves its rendered output as HTML. This lets you reuse familiar templates while delivering ordinary public files. The build environment needs PHP; a file-only host receives the finished output.

Move rendering into a deliberate build step

PHP can execute scripts from the command line. Create an exporter that prepares public data, renders a template, and writes the result to its intended route. Keep content selection and filesystem handling in the build process so errors can stop an incomplete release.

Review assumptions about cookies, request headers, and server paths. Templates written for visitor requests may need adaptation before they run reliably in a build. Avoid rendering code that sends messages or changes stored records as a side effect.

Publish the result of the templates

The public folder should contain completed HTML, stylesheets, images, and required browser scripts. Uploading PHP source to a file-only host does not provide a PHP runtime. Keep configuration, credentials, source data, and private templates outside the deployable directory.

Define clean URLs and reject duplicate destinations before writing files. Escape ordinary text for its output context, validate links, and inspect the produced markup. The HTML publishing guide provides a baseline for the exported documents.

Separate public pages from live services

Decide which operations still require a server. Contact delivery, authentication, and shared persistent data need an appropriate service; a saved page alone cannot perform them. Remove controls that have no working destination and test retained integrations from the final origin.

Rebuild after approved content changes and retain a recoverable previous artifact. Read the Django and PHP export workflow, or compare the Django template approach when choosing a build environment.

Questions about PHP

Can a static host execute my PHP templates?

A file-only static host serves files without executing PHP. Run PHP during the build and upload the resulting HTML, or choose application hosting when request-time PHP is required.

Can I retain shared PHP headers and footers?

Yes. Include those templates while generating the pages. The completed HTML already contains the shared markup when visitors request it.

Primary reference: PHP: command-line usage.

Django Static Website Builder: Templates & Assets | SWB

Django can prepare content and render templates during a build that produces a static website. This is an additional publishing workflow around your project. Django asset collection and a complete HTML export perform different jobs, so define both before planning deployment.

Understand what collectstatic actually collects

Django uses static assets for files such as stylesheets, scripts, and application images. The collectstatic command gathers those assets into the configured deployment location. It does not render every view or transform database records into a complete set of public HTML pages.

Create a separate rendering step with a public route manifest and approved context data. Keep asset assembly and HTML generation in a documented sequence. The HTML output guide describes what the final pages should contain.

Render an explicit public content model

A project-specific management command or build script can render templates and write their output. Select only the fields required for publication. Check visibility and publication status before rendering, and avoid exposing private records through convenient template context objects.

Review request-dependent context processors, user branches, and session assumptions. Supply stable public values where appropriate. Maintain escaping for normal text and carefully review imported rich HTML. Stop the build on missing required content, duplicate routes, or template failures.

Test the artifact without the Django application

Serve the completed release through a plain static server. Open nested pages directly, follow archive pagination, and check media references. Decide separately how to handle uploaded media; collecting application assets does not automatically package every user-uploaded file.

A static host does not run the Django application or provide its authentication and form handling. Follow the Django and PHP export guide for service boundaries and release checks, then compare the PHP build workflow for a related approach.

Questions about Django

Does collectstatic export Django pages?

No. It gathers static assets. Rendering views or templates into public HTML files requires a separate exporter with a defined set of content and routes.

Can the Django admin run on a static host?

The admin requires the Django application and its supporting services. Keep it in a suitable application environment if it remains part of the editing workflow.

Primary reference: Django: deploying static files.

Ghost Static Website Builder: Editorial Publishing | SWB

Ghost can supply editorial content to a build that creates a separate static publication. Fetch approved public records, render them into complete pages, and release a checked artifact. The project also needs a plan for the reader features outside that artifact.

Fetch and validate content before release

Use the Content API during the build to retrieve published content. Follow pagination until the approved collection is complete, then validate article, author, and tag relationships. Essential article text should already be present in the generated pages when visitors receive them.

Keep privileged credentials out of the public files. Record the content snapshot and reject incomplete fetches instead of publishing an empty archive. The static workflow overview explains the boundary between authoring and delivery.

Rebuild the publication around its content

A custom frontend needs intentional routes, archive pages, pagination, titles, canonical addresses, and discovery files. Generate those from a shared manifest so a removed article does not remain listed elsewhere. Sanitize imported rich content according to the elements and embeds your publication supports.

Choose whether images stay on the Ghost origin or are copied and rewritten into the release. Inspect responsive candidates and feature images as well as inline media. Preserve captions, alternatives, and relevant attribution during transformation.

Keep membership and publishing responsibilities clear

A bare static export does not provide member authentication, newsletter delivery, or a server search service. Ghost’s native membership features require its supported frontend. Do not put protected text into public files and attempt to hide it with browser styling.

Trigger rebuilds for edits, publication, and removal, and keep a previous release available. The Ghost publishing guide covers the complete process. Compare the WordPress editorial export if you are evaluating alternative source systems.

Questions about Ghost

Does exporting HTML preserve Ghost membership features?

No. A bare export does not reproduce access control or account journeys. Publications needing native Ghost membership features should retain the supported frontend architecture.

Will edits appear automatically after publication?

Only when your configured workflow builds and deploys the changes successfully. Define the trigger, failure handling, and verification instead of assuming that saving content updates the public artifact.

Primary reference: Ghost: headless publishing guidance.

Premium Static Website Templates: Selection Guide | SWB

A premium static template is worth evaluating when its layouts, documentation, or support can reduce meaningful work on your project. Compare those benefits against the actual requirements. This guide provides selection criteria for assessing a candidate before building around it.

Check that the included pages match your needs

List the layouts your site requires and find evidence of each one in the candidate. A polished homepage does not establish that long articles, archives, detailed service pages, and error states are included. Replace sample copy with realistic titles and navigation labels.

Inspect mobile behavior, keyboard controls, and image treatment. Estimate the work needed to close gaps rather than scoring a template by component count. The responsive CSS guide offers practical layout checks.

Read permission and support terms precisely

Identify the license for the code and separate terms for photographs, icons, fonts, and illustrations. Keep a record of the version and purchase terms that apply. Confirm the intended deployment, client handover, and reuse arrangements before committing to an asset.

Review support scope, update access, and the form in which source files are supplied. Paid access alone does not establish unlimited permission or ongoing custom development. Resolve unclear terms with the rights holder or choose a clearly documented alternative.

Run one realistic page through the workflow

Build a representative page and trace routine edits to text, colors, navigation, and shared components. Confirm that a fresh build works using the documented dependencies. Check whether demo interactions require additional services before treating them as completed features.

Compare implementation, integration, accessibility, and maintenance effort with the free template criteria. The free versus premium comparison provides a decision matrix and a practical way to record the evidence.

Questions about Premium templates

Does a premium template include working backend features?

Only if the supplied product and its documented services provide them. Many templates supply interface components that still need form processing, search, or other integrations.

Is a paid template automatically easier to maintain?

No. Inspect source organization, build instructions, dependency requirements, and routine editing tasks. Those factors determine maintenance effort more directly than the purchase label.

Primary reference: Choose a License: understanding missing permissions.

Free Static Website Templates: Practical Criteria | SWB

A free static template can provide a useful starting point when its structure matches your content and its permissions are clear. Evaluate the source and the adaptation work before choosing it. A small understandable template may serve the project better than a large demo.

Find the actual license and asset records

Locate the license supplied with the template. Free access to a download does not by itself describe the allowed uses. Check photographs, icons, and fonts independently because their terms may differ from the surrounding code.

A license such as MIT includes conditions involving copyright and license notices; read the actual text rather than relying on a badge. Preserve applicable notices and source records for everything you retain. Replace unclear demo assets with material you have permission to publish.

Prefer a structure the future editor understands

Inspect the file organization and reproduce the documented build. Change a header label, an article title, and a shared style. Count the places that need editing, and decide whether that repetition is reasonable for the size of the planned site.

Remove unused sections and dependencies after confirming their role. Start with the HTML structure guide and CSS layout guidance to keep the adapted site readable and consistent.

Budget for adaptation and verification

Use real content to test long titles, narrow layouts, keyboard navigation, image alternatives, and error states. Check whether contact forms and search interfaces have an actual implementation. Include any required fixes and services in the project estimate.

Document your changes and retain the original template for comparison. Use the template comparison article to record tradeoffs, then inspect the premium selection criteria if a paid candidate might remove substantial work.

Questions about Free templates

Can I use any free template commercially?

Check the actual license and all included asset terms. The fact that a template is available without payment does not settle permission for every intended use.

What if the template has no documentation?

Try a small representative page before committing. If you cannot reproduce the build or understand routine edits reliably, include that uncertainty in the decision and consider another starting point.

Primary reference: Choose a License: MIT license reference.

Astro Static Website Builder: Components & Output | SWB

Astro combines reusable components and content into web pages, with static prerendering as its default approach. It suits projects that want consistent layouts and a deliberate amount of browser interaction. Keep the rendering mode and hosting requirements explicit as features are added.

Start with complete static page content

Plan the page and archive routes, then build shared layouts around representative content. Include titles, descriptions, images, and useful links in the data model. For static dynamic routes, provide the complete route set during the build so every intended page is generated.

Keep essential reading content in the rendered HTML. Fetch remote editorial data during the build when a static snapshot fits the publication. Compare the Hugo content workflow if file-based authoring is your main requirement.

Add browser interaction where it serves a task

Astro can render content without making every component an interactive application. Use ordinary browser scripts or selected client islands for features such as a menu or public-content filter. Choose when those components load according to their purpose.

Test the page before enhancements run, and preserve meaningful links and headings. Measure images, fonts, and third-party scripts alongside component code. The Astro performance guide explains how to inspect the generated result.

Keep the deployment mode consistent with the brief

Astro also supports on-demand rendering with an appropriate adapter and server runtime. Those routes change the hosting requirements. If the deliverable must run on a file-only host, ensure the required pages are prerendered and do not depend on request-time server features.

Build the production output and inspect it through a matching static server. Check deep URLs, asset references, feeds, and the error page. Use the static builder overview to revisit service boundaries before adding accounts or persistent submissions.

Questions about Astro

Does every Astro site require server hosting?

No. A fully prerendered site can be served as static files. Pages rendered on demand require an appropriate adapter and runtime.

Does Astro automatically make a site fast?

Its architecture can support restrained browser code, but the result depends on images, fonts, scripts, layout, and configuration. Measure representative pages and address the actual causes of delay.

Primary reference: Astro: prerendering and on-demand rendering.

Static Website Builder Lab | Guides, Workflows & Ideas

Ideas, decisions, and the details between

Static Website
Builder Lab

Ten deep dives into a better static web. Learn the foundations, explore practical frameworks, and work through the decisions that turn a promising draft into a site you can maintain.

Foundations AI Workflows Frameworks CMS Migration Templates Deployment

The reading list

Keep the WordPress editing workflow while publishing a carefully tested snapshot of public pages.

Jun 12, 20247 min read

Start with static HTML HTML5

How to Choose a Static Website Builder for Your Next Site

Start with your publishing routine and required interactions, then choose the simplest reliable way to produce and maintain the finished files.

Mar 19, 20247 min read

Foundations Articles | Static Website Builder Lab

The Lab / Category

Foundations

A static website starts with a practical decision: which information can be prepared before a visitor requests it, and which interactions need a separate service? Begin by listing the pages, the people who edit them, and the tasks visitors must complete. That inventory helps you choose a manageable authoring process before investing in a particular visual style or framework.

The static website builder overview explains the main approaches. For a new project, establish one readable page, a clear navigation structure, and a repeatable way to publish its files. Then use the builder selection guide to compare direct HTML, generators, and CMS exports against the work your team actually needs to maintain.

Read and build

The foundations collection.

Build an Accessible Static Site with Semantic HTML and CSS

A practical build sequence for meaningful page structure, resilient layouts, keyboard navigation, images, and forms that communicate clearly.

Oct 7, 20247 min read

AI-assisted building LLM workflow Prompt patterns

How to Choose a Static Website Builder for Your Next Site

Start with your publishing routine and required interactions, then choose the simplest reliable way to produce and maintain the finished files.

Mar 19, 20247 min read

AI Workflows Articles | Static Website Builder Lab

The Lab / Category

AI Workflows

AI assistance becomes easier to review when each request has a defined purpose, relevant source material, and an observable result. Start with approved content, a route map, and a small set of design rules. Ask for one representative page or a bounded correction, then inspect the actual files and rendered behavior before repeating the pattern across the site.

The AI static website workflow places drafting inside a wider publishing process. Keep generated business claims, asset references, and service integrations subject to the same checks as manually written work. The practical prompting guide shows how to turn a broad request into changes that can be understood, tested, and handed to the next maintainer.

Read and build

The ai workflows collection.

Hugo Astro Start with static

AI Workflows

AI Prompts for a Static Website Workflow You Can Review

Turn a broad website request into small, verifiable changes with clear context, useful examples, and a repeatable review process.

Apr 23, 20257 min read

Frameworks Articles | Static Website Builder Lab

The Lab / Category

Frameworks

A framework should make repeated publishing work easier to manage. Compare how your content becomes pages, where shared layouts live, and what another contributor needs to create a clean production build. Use a long article, a small archive, and an unusual content example during evaluation. Those cases reveal more about maintainability than a polished demonstration homepage alone.

The Hugo guide focuses on structured content and templates, while the Astro guide explores static pages with deliberate browser interactivity. Record tool versions, dependencies, build commands, and output directories for either approach. Keep request-time features explicit, because a component in the authoring project does not establish that the intended host can run every feature it describes.

Read and build

The frameworks collection.

Improve Astro Static Site Performance with Deliberate Islands

Keep reading content simple, add browser interactivity where it serves a task, and measure the actual page before making performance changes.

Feb 11, 20267 min read

Build a Hugo Static Site from Content to a Reliable Release

Follow the complete Hugo publishing lifecycle: source files, front matter, templates, assets, draft review, production output, and deployment.

Jul 16, 20257 min read

CMS Migration Articles | Static Website Builder Lab

The Lab / Category

CMS Migration

Moving to static delivery requires a careful inventory of the public site. Record article routes, archives, media, navigation, and any interactions that depend on the existing content system. An export can capture published pages, while forms, account access, comments, or other request processing need their own decisions. Keep the editing system and the delivery artifact clearly identified throughout the migration.

Begin with a small representative export and follow it through an ordinary content update. The WordPress publishing overview and Ghost publishing overview help frame that evaluation. Preserve useful URLs, verify nested assets, and establish who owns the export and release steps before treating the new workflow as ready for ongoing editorial use.

WordPress Django PHP Ghost

Read and build

Start with your publishing routine and required interactions, then choose the simplest reliable way to produce and maintain the finished files.

Mar 19, 20247 min read

Accessibility Topic Guides | Static Website Builder Lab

The Lab / Topic

Accessibility

Accessibility work follows the whole path a reader takes through a page. Can they understand its headings, find the main content, identify links, and operate controls with a keyboard? Check visible focus, form labels, useful image alternatives, and the order in which information appears. A component's appearance provides only part of the evidence about whether that experience is usable.

Begin with the accessible static site workflow, then apply the same checks to a representative page with longer or more complex content. The HTML5 structure guide helps establish meaningful document regions. Repeat the review after shared components change, and treat automated findings as useful inputs alongside direct interaction and careful reading.

HTML5 HTML CSS

Read and build

The accessibility collection.

Deployment

The Static Website Launch Checklist

Review the generated files and the real host behavior before sending visitors to a new static release.

Sep 14, 20267 min read

Templates

Free vs Premium Static Website Templates

The templates collection.

Templates

Free vs Premium Static Website Templates

Choose a template by the work it saves and the rights it provides, using a practical inspection matrix.

May 21, 20267 min read

Build a Hugo Static Site from Content to a Reliable Release

Follow the complete Hugo publishing lifecycle: source files, front matter, templates, assets, draft review, production output, and deployment.

Jul 16, 20257 min read

Build an Accessible Static Site with Semantic HTML and CSS

A practical build sequence for meaningful page structure, resilient layouts, keyboard navigation, images, and forms that communicate clearly.

Oct 7, 20247 min read