On this page
A WP Forged lab report using an owned, synthetic website. This is a small local publishing test, not a client migration or a production benchmark.
What we tested
We connected a fresh WordPress installation to a minimal Astro website and followed one published post through an edit, an unavailable source, and deletion. A second post stayed in draft throughout.
The recorded run passed eight checks. It produced three successful static builds and one intentional build failure. WordPress changes appeared in the generated pages after a manual rebuild. The unpublished draft did not appear in the public responses or generated HTML we checked.
The practical finding is specific: keeping WordPress for content still requires a publishing process between WordPress and the public website. In this setup, saving a change in the source did not update the existing Astro files by itself.
Download the recorded results, counts, versions, and HTML hashes (JSON).
The setup
| Component | Recorded version or configuration |
|---|---|
| WordPress | 7.1.2 |
| Database integration | SQLite Database Integration 3.0.2 |
| PHP / SQLite | 8.3.33 / 3.53.2 |
| Astro / Node.js | 7.3.3 / 24.13.1 |
| Environment | Windows; PHP bound to local loopback only |
| Content | One published “Workshop hours” post and one unpublished “Workshop draft plan” |
| Source changes | WordPress PHP functions, not the editor interface |
| Source reads | Unauthenticated WordPress REST posts requests |
| Public output | A static index and a page for each returned published post |
| Publishing | A manual build followed by a separate output-promotion step |
We used SQLite to keep the experiment local without installing a separate database server. This does not test a MySQL-hosted production site. WordPress outbound HTTP requests, email, and scheduled cron execution were disabled for the fixture.
The Astro pages fetched the WordPress posts endpoint during their build. The loader rejected failed requests and unexpected records rather than substituting an empty content list. The fixture was deliberately small: it rejected results requiring a second API page instead of pretending to implement pagination.
This follows the integration approach described in Astro’s WordPress documentation. WordPress documents publish as the default status for its REST posts collection. We checked the actual responses from our installation as well.
Recorded results
| Check | Observed result |
|---|---|
| Draft excluded from the public list | HTTP 200 returned one published record. WordPress contained one draft, but its distinctive content marker was absent from the response. |
| Direct unauthenticated draft request | HTTP 401 with rest_forbidden. The response contained no draft content marker. |
| Initial static build | Exit code 0. Two HTML files: the index and /posts/workshop-hours/. Published content was present; the draft marker was absent. |
| Edit before rebuilding | The public API returned the new content, while the retained HTML still contained the old content and had the same hash. |
| Edit after rebuilding | Exit code 0. Both pages reflected the changed content. The previous marker and draft marker were absent. |
| WordPress unavailable | After stopping the local PHP server, the Astro build exited with code 1 and a connection-refused fetch failure. |
| Previously accepted output | Its HTML hash stayed identical across the failed build because the runner did not replace it. |
| Published post deleted | The public API returned zero posts while the draft remained in WordPress. The successful rebuild produced only the index; the old article file was absent. |
The published post’s synthetic opening time changed from 17:00 to 18:00. Distinctive text markers let the runner check which version reached the generated HTML. These checks inspect file contents and responses; they do not assess visual design or ease of editing.
What kept the earlier output intact
We built into a separate candidate directory. Only a successful build with the expected content checks was copied into the retained release directory. When the source was unavailable, that copy did not happen.
The HTML-set hash before and after the failed build was:
638845e1d237f31fb391db2ec64387058c7bd3a7d14d6d9a0743e06bced3fa0b
The hash covers sorted relative HTML filenames and their contents. The downloadable record explains the calculation and lists the other build hashes.
Retention was a behavior we implemented in the runner. It is not an automatic promise that any Astro deployment will preserve a working website. We did not deploy these files to a hosting provider, test traffic during a release, or test an interrupted promotion. A real project needs its own deployment and recovery checks.
Deletion has a similar boundary. We established that a fresh build stopped generating the article file. We did not test the HTTP response for its former URL on a production host or decide whether that address should redirect, return 404, or return 410. Those decisions belong in the migration URL plan.
What this experiment leaves open
This run does not demonstrate authenticated draft previews, scheduled publishing, automatic rebuilds, editor usability, media handling, custom fields, page builders, forms, analytics, or large-site behavior. It is not a security review, SEO migration, availability test, or performance comparison.
In particular, an unpublished draft being absent from the two public requests checked here is not a privacy audit. A working REST connection also does not preserve an existing page builder’s controls or prove that a marketing team can complete its usual tasks.
The next useful step is to test those agreed editing tasks on a representative site. The next-edit guide explains what to specify, and the project brief gives those requirements a place in the scope. Use the architecture guide when deciding whether this operating model fits the team at all.
Method and evidence
The recorded run completed on September 26, 2026. The public JSON contains its UTC timestamp, environment, all eight results, and the untested areas. Raw REST snapshots, build logs, and per-stage generated HTML were retained with the local fixture. Runtime credentials are excluded from the public record.
The procedure was: create the two posts; inspect the public list and direct draft request; build; edit the published post; compare the existing output before rebuilding; rebuild; stop WordPress and attempt another build; compare the retained output; restart WordPress; delete the published post; rebuild and inspect the resulting file list.
This is one recorded execution of a small fixture. It supports the observations above, not a success rate or a claim about every WordPress-to-Astro project. A scoped WordPress-to-Astro rebuild should turn the actual site’s requirements into its own acceptance checks.