Ghost can remain an editorial system while a separate build turns its public content into a static website. Authors write and publish in Ghost; the build fetches approved content, renders pages, and produces an artifact for deployment. Visitors then read those generated pages without asking Ghost to render every request.

That architecture changes more than the theme. Archives, feeds, metadata, search, images, and publishing updates need deliberate ownership. A static copy also does not bring along a functioning membership or email delivery system. Define these boundaries before you commit to the migration.

1. Define the publication you are actually building

List the pages and reader journeys that matter: article discovery, author biographies, topic archives, subscription information, downloads, and contact routes. Mark which parts are entirely public and which depend on a continuing service. An open editorial archive is a different project from a paid publication with account management.

Ghost's official headless publishing guidance explains that the default frontend supplies behavior a custom static frontend must recreate. It also states that native membership functionality is incompatible with headless setups. Treat that limitation as an architecture decision, not a missing visual component.

Write a simple acceptance statement: every approved public article is readable, discovery pages are complete, and all visible actions work. Use the Ghost static website overview to frame the editorial workflow and the static website builder guide to compare delivery approaches.

2. Fetch content during the build

Ghost's Content API provides read-only access to published content. For a static publishing workflow, fetch that content inside the build environment and render it into the output. Calling the API from each visitor's browser instead would create a different dependency and could leave essential article text unavailable until a network request succeeds.

Configure the content origin and appropriate Content API credentials in the build system. Keep Admin API credentials out of the public artifact. Although a Content API key is intended for public content access, there is no reason to ship unnecessary build configuration in page source. Treat private publication settings separately and confirm their access requirements.

Fetch the whole approved collection

Follow pagination metadata until the collection is complete. Avoid assuming one response contains every post. Retrieve pages, authors, and tags that the selected templates require, then validate relationships. Fail the build if expected records disappear because a request failed; an empty response should not silently become a successful empty publication.

3. Recreate routes and editorial metadata explicitly

Build a manifest connecting each content identifier to its public URL. Decide whether to preserve existing post paths and which author or tag archives deserve a page. Render those archives with useful context, correct article links, and working pagination. Check the first, middle, and final archive pages rather than judging the collection from its opening screen.

Store titles, descriptions, publication dates, update dates, and featured image references in the public content model. Define sensible fallbacks when an optional field is missing. Keep canonical URLs aligned with the public domain and intended route. A copied origin URL can accidentally identify the editing installation as the preferred public page.

Generate the sitemap, feed, and related-content links from the same approved manifest. Preserve stable feed identifiers where possible so that rebuilding does not make unchanged posts appear as new entries. Review custom routing rules individually; a file export does not automatically reproduce Ghost's request routing or redirect configuration.

4. Treat rich content as structured input

Article HTML may include headings, links, images, embeds, cards, and scripts introduced through editorial tools. Define what the static publication supports. Parse the content with an HTML-aware tool and apply a maintained sanitization policy before rendering imported rich text. Escaping an entire article would display markup as text; blindly trusting every fragment can preserve unsafe or incompatible behavior.

Use explicit rules for embeds and links

Allow the elements and attributes your templates need. Validate URL schemes, reject inline event handlers, and handle embedded services through a deliberate allowlist. If an embed is removed, supply a useful text explanation or approved alternative instead of an unexplained blank region. Preserve meaningful heading order and descriptive link labels.

Test at least one article containing each supported card type. Check tables on narrow screens, captions beside images, code blocks, and quoted material. Keep an editorial preview that uses the same transformation as production, so writers can see what the public build will retain before a release is approved.

5. Choose an image strategy with a complete manifest

Ghost content can contain absolute image URLs pointing to its origin. You can retain that media origin as a dependency or copy approved assets into the generated site and rewrite their references. Decide explicitly. Turning off the old installation while its images still serve your articles can break an otherwise successful migration.

If copying images, inspect both primary image URLs and responsive candidates. Include feature images, author portraits, tag images, and images embedded inside article HTML. Preserve useful alternative text and captions, and verify that each downloaded file is an image rather than an HTML error document. Record where each asset came from and any attribution requirements.

Use descriptive filenames and a stable mapping so a rebuild produces predictable paths. Set image dimensions based on the actual files and check cropped presentation at several widths. Avoid loading every large article image immediately when only the opening content is visible. Keep the image needed for initial reading available promptly.

A bare export contains public files. It does not authenticate members, enforce paid access, manage subscription changes, deliver newsletters, or maintain a server-side search service. Copying a subscription card or account button preserves its appearance without necessarily preserving the underlying journey. Test the complete behavior before keeping such controls.

For a publication that requires Ghost's native membership features, retaining the supported Ghost frontend may be the better architecture. Do not publish protected article text and rely on CSS or JavaScript to hide it. Once content is present in a public artifact, hiding the visible section cannot enforce access.

Email delivery may continue through a separately operated publishing system, but the static pages themselves do not send it. Verify subscription and unsubscribe destinations, and avoid blanket origin redirects that break service routes. For public article search, intentionally build a local index and accessible browser interface, or configure an appropriate search service. Include only approved public content in that index.

7. Rebuild after every meaningful content change

Choose a publication trigger: an authenticated webhook, a controlled manual action, or a documented schedule. A publish event can start a build, but it does not prove that the new artifact reached the public site. Track the content snapshot, build result, preview approval, and deployed release as separate states.

Include edits, deletions, changes to tags, and scheduled publication in the update plan. A revised author biography can affect many article pages. A removed post must disappear from archives, search, related cards, feeds, and the sitemap according to the publication's policy. Generate into a fresh directory so deleted files do not linger from the previous release.

Coalesce closely spaced editorial changes when useful, and prevent an older slow build from overwriting a newer approved release. On failure, keep the last successful site available and notify the publishing owner. Record enough input information to reproduce the problem without guessing which editorial state was used.

8. Verify the publication before and after release

Serve the generated output in a preview matching the destination host. Open deep links directly, inspect response codes, and check clean URL handling. Read several complete articles on a phone-sized screen. Test keyboard navigation, headings, archive pagination, search, media, and every remaining subscription or contact journey.

Check the output for unintended origin-domain links, private records, obsolete scripts, and development settings. Keep a previous artifact and rehearse restoring it. The static website launch checklist covers host behavior and release checks; the WordPress export guide offers another view of editorial snapshot maintenance.

A reliable Ghost static publication makes its responsibilities visible to the team. Editors understand when changes become public, developers can rebuild the same content consistently, and readers encounter supported features throughout the site. Establish those habits during the first small export, then expand the publication with confidence in the process.