How We Moved CoreAEX to Astro and a Headless CMS Without Moving Public Hosting

CoreAEX started as a set of manually maintained static pages. As the site grew, adding an article meant working around repeated markup, shared elements that could drift apart and a publishing process with too much file handling. We wanted reusable templates and an editorial interface, but we also wanted to keep readable HTML, our existing URLs and our public hosting on DreamHost.

We made the change in stages. First we migrated the existing site to Astro. Then we added Payload and a workflow that turns an approved content version into a checked static release. A separate server runs the editorial application and publication runner; public pages still come from the same host. Our first scheduled attempt, on October 6, stopped before changing the public site, and a repair plus operator recovery deployed the research study it carried. On October 13 the next scheduled article went live on time without a hitch, and a later check reported the October 20 article live too.

Two labels mark evidence boundaries on this page. Documented marks a platform behaviour directly supported by the linked Astro, Payload or Google documentation; any surrounding interpretation remains CoreAEX analysis. Recommendation marks a check or practice we suggest that no source prescribes. Results from our own system are described in the prose at their evidence level: confirmed by the operator, reported by an implementation or test report, or observed on the public site. Untagged text is ordinary explanation.

Why manual static publishing became difficult

The clearest symptom was the author box. Every article carried its own copy of the same author block, along with its own copy of the footer, the table of contents markup and the call-to-action panel. Each article was a complete, hand-maintained HTML file. As the library grew, a change to one shared element meant editing every file that contained it, and any file that was missed quietly drifted.

Publishing had the same problem in another form. A new article needed correct markup, metadata, a canonical URL and structured data, and it had to appear in the resources listing and the sitemap. Uploading the text was only part of the job.

The fix for the first problem is ordinary templating. Before, changing the author box meant editing it across many files. Now it is a component: each article keeps its own content, while the author box, CTA and related-reading block are defined once. That set the order of work. Templates came first; editorial automation could only sit on top of pages that already rendered from shared components.

Why we separated the migration from the CMS

We deliberately ran two projects rather than one. The first moved the existing site to Astro for reusable templates and static, readable initial HTML. Only after the existing pages had migrated did we add Payload for editorial data, versions and drafts, plus a custom workflow for import, review, version-bound release jobs, export, build, validation and deployment. That way we could judge whether migrated pages matched the originals before asking whether the automation worked.

Astro builds a site into a folder of output files that can be uploaded to a host, and its deployment guide distinguishes static output from on-demand rendering, which needs an adapter. Payload's versions feature keeps a history of document changes, lets editors save drafts newer than the published document, and supports restoring earlier states. Documented

Each part has one job:

What runs where

This is a workflow built on Astro and Payload, not a CMS engine built from scratch. The framework documentation describes what the platforms can do; it cannot show that our own release rules work. Those need their own evidence, so the rest of this article says what was confirmed, reported or still open.

How we migrated the existing pages

We started from a read-only snapshot of the existing site, so the original pages stayed available as the reference throughout. The migration then ran in bounded batches, with Git checkpoints and archives between them. Each batch aimed to preserve the content and behaviour of the pages it touched before the next batch began.

The repeated markup became a small set of components with clear responsibilities. ArticleHero handles the article header, ArticleToc the table of contents, AuthorBox the author block, RelatedReading the related links and ArticleCta the call to action, with ArticleLayout.astro assembling them around each article's own content. The names matter less than the split: shared presentation lives in one place, and article content stays with the article.

The cutover milestone was September 30, 2026. The reported scope at that point was 80 content routes, plus assets and control files, with the legacy .html URLs retained. That is a dated milestone, not today's page count; the site has added pages since. What mattered for readers was the method: content, routes and expected output were compared in bounded stages rather than in one switch.

Public hosting and DNS stayed where they were. The source and build system changed, and the resulting static files went to the same public host. That reduced what changed at cutover: no new host, no DNS move, no new serving stack. It suited our situation; it is not an argument for any particular host.

How an article moves through the new workflow

Here is the path a single article takes, as the integration was reported to work:

1. Supply the source: an HTML or DOCX file, with Resources or Research as the section.
2. Import a draft: the importer maps article content into a Payload draft, rather than nesting a whole standalone page inside the template.
3. Review the private preview, reading it as a reader would.
4. Correct it: each correction is a new saved version, previewed again.
5. Choose publication timing: immediate or scheduled.
6. Approve the reviewed version. Approval is the final operator decision.

The runner then exports the pinned version, processes media, builds Astro, validates the candidate and deploys it through controlled SFTP, with no manual export or upload step. That is the reported integration; not every intended control in it has been independently audited.

What a pinned version means

A pin records exactly which content version a release job will publish. Say we review version 5, approve it and schedule it for Tuesday, and on Monday someone saves an edit as version 6. The Tuesday release should publish version 5, the reviewed one, not silently substitute the newer draft.

What happens to a queued job when its article is edited after scheduling is not yet fully documented. So the practice is a read-back: after any edit, the operator checks the job's pinned version and due time against what was reviewed, and replaces the schedule deliberately if they differ. Recommendation

An isolated rehearsal built a scheduled article before and after its due time. Before it, the page, its automatic listing entry and its sitemap entry were all absent; after it, all three were present. That tested build eligibility only, not a live deployment.

The production results

The integration article was scheduled for 14:00 Europe/Belgrade (12:00 UTC) on October 13, 2026, and we confirmed it went live as scheduled without a hitch. A later check reported the programmatic SEO article live on October 20, with its listing and sitemap entries. One is an operator confirmation, the other a reported post-release check; the full job and file-verification records are internal evidence we are still retaining.

Three statuses stay separate. Editorial status is what the CMS record says. Job status is what the release job did. Serving status is what the public URL returns, and the only proof of that is fetching the page.

Why the scheduler does not live on a laptop

The runner is hosted on the VPS, so publication does not depend on a home computer staying on. If the editorial server is unavailable, the public site keeps serving its last release, because those pages are static files; editing, previews and new releases pause until it returns. Contact and booking have their own dependencies and their own tests.

Articles versus site development

Services, Contact, navigation and Tools are source changes in the Astro codebase, not CMS content. Both paths share one build and one public target, so a later article build must include newer templates and assets, and a source deployment must preserve CMS-exported articles. Each of our tool pages, for example, needs both its HTML and its JavaScript bundle; ship one without the other and the page renders but does not work.

Where SEO safeguards fit into the process

We treat SEO safeguards as three responsibilities. Migration parity protects pages that already exist. Release checks protect the next publication. Editorial review decides whether the content and links make sense. The table shows where each check sits in our process; it is not a claim that every current page was freshly audited against every row.

Publication risks and where they are checked Recommendation

Article content must also be readable in the initial HTML response, and redirects and missing-page responses are checked by status code and body, not by appearance.

Listing, sitemap and the curated page

A released article becomes eligible for the automatic all-resources listing and the sitemap at publication time. Our curated /resources.html page is an editorial decision, and the rehearsal tested eligibility without promoting anything onto it. The public All Resources listing, retrieved on October 31, includes both the October 13 and October 20 articles; we did not retrieve the sitemap at the same time. Tools discovery is managed in source.

Private previews and noindex

Drafts are reached through a private connection, and the preview also carries noindex. Google describes noindex as an instruction to drop a page from search results, and says it must crawl a page to see the rule, so a page blocked by robots.txt cannot deliver it. Documented Noindex is an indexing instruction, not access control: the private connection keeps drafts private, and noindex is an extra property we check.

Mixed URL shapes and canonicals

Most of the site keeps legacy .html URLs, while Tools is served as a /tools/ directory index; both need matching output, links and canonicals. Astro's build.format option governs output shape: directory is the default, and preserve generates HTML files as they appear in the source folder. Google advises linking internally to the canonical URL and not declaring conflicting canonicals, treats sitemaps as a weak canonical signal, and makes the final choice itself. Documented We state the requirement rather than a configuration snippet, because our exact current configuration and full regression report are not reproduced here.

For redirect planning specifically, our free Redirect Map Checker inspects a supplied redirect map; it does not fetch destinations or test live redirect rules, and it is not a gate in this pipeline.

None of these checks is a growth tactic. They reduce migration and publishing defects. We have not measured any ranking, traffic or AI-citation gain from the migration, and we are not claiming one.

What failed and what it taught us

Three problems taught us the most.

The displaced author box. On one imported article, the author box rendered in the wrong place. The cause was not the template: the imported HTML contained a surplus closing div that pushed the author box out of position. The fix went into the import and source mapping, followed by a bounded reimport and reported checks across 77 Resources pages. The lesson is that shared templates only help if the content entering them is structurally sound. An importer needs its own structural checks.

The first scheduled release. Our first scheduled production attempt, on October 6, passed export, build and validation, then stopped at its last check of the live server, before writing anything. The check had confused a new article being genuinely absent from the server, which is expected, with a file probe that had not completed, which proves nothing. The repair made the outcomes explicit: each expected file is present, absent or unproven, and anything unproven stops the deployment. After the repair, an operator recovery deployed the page and its discovery files.

The broader lesson: neither a passing build nor a "Published" label in the CMS proves a public release happened. During that attempt the CMS record showed as published while the page did not yet exist. The proof is the job record plus the page actually being served. The October 13 scheduled release then ran as intended.

The incident also showed that a rollback must restore the release records as well as the files, so the system stops claiming a page that was never released. That was part of the reported repair, not a promise of atomic deployment or database restoration.

The stale source copy. On November 4, publishing a new guide rebuilt the whole site from the release server's copy of the source, which had fallen behind the repository. The release dropped a newer Tools card and the footer's Tools navigation from every page, although the article itself was correct. We restored the site the same evening through the normal release path. Every release now checks out a named commit from the repository and refuses to publish from source that is stale or locally modified. The lesson matches the source-drift row above: an article release is also a release of every template it is built with.

What someone else would need to reproduce it

If you are considering something similar, budget for more than the CMS interface. The realistic dependency list looks like this: Recommendation

• An authoritative source repository and a complete route inventory, including pages that have no CMS record
• Templates and a content schema that separate shared presentation from article content
• The CMS database and media store, with backups that are consistent and actually restorable
• Importer, review and version rules, including what happens when a scheduled article is edited
• An always-on runner that does not depend on anyone's laptop
• Isolated preview and build spaces, so drafts cannot leak into a release
• Controlled deployment, with current file-ownership records and byte-level verification of what was uploaded
• Tested recovery: rollback, restore and what to do with a late or failed job

Reproducing our exact system would also need its current source, configuration and lockfiles; this article explains the approach, and operational particulars stay in internal documentation.

The trade-off: simple static public hosting stays in place, but the editorial application, its credentials, the scheduler and recovery become operational responsibilities, and custom publishing rules need their own maintenance and tests. This fitted CoreAEX's requirements. Many sites would be better served by a simpler editorial workflow, and none of this is required for SEO.

Limitations as of 31 October 2026

The October 13 scheduled article went live as intended. Later publication checks reported the October 20 article live with its automatic listing and sitemap entry. Further work includes documenting the complete recovery drill and completing or verifying the remaining access and collision controls. Production publication is working, while broader outage and recovery guarantees need their own tests. We have not measured ranking, traffic or AI-citation gains from this migration.

The practical takeaway

We now have reusable templates, an editorial draft-and-preview process and static releases built from reviewed versions, while public hosting stays where it was. If you are weighing a similar move, the decision is not only which CMS to use. Budget for source control, release checks and recovery as well as the editing interface, because those are what make a scheduled publication trustworthy.

---

Sources