Workflow
From Draft to Production in One Repo.
You define the site in React, draft content in markdown, check it, accept it, and ship from approved archive content. The live site is built from that accepted layer instead of from ad hoc working files.
Step One
Set the Site Identity Once.
One configuration surface controls the site name, canonical URL, navigation, footer copy, and default metadata. Rebranding or launch prep should not require hunting through route files.
That keeps the system understandable before anyone writes a page.
Step Two
Write Content Inside Approved Blocks.
New pages and revisions are written as markdown that calls prebuilt blocks. That keeps writing focused on content instead of reopening layout, styling, or template decisions every time.
People and AI tools use the same publishing surface, so the workflow does not fork as the team grows. The agent drafts inside the same boundaries a human editor would use.
Step Three
Validate Before You Publish.
A content check step catches route collisions, bad frontmatter, and invalid block usage before a change becomes a reviewed page. The readable source stays in the repo, and the live site is rebuilt from that approved set.
That is how PageQuarry keeps editing fast without making the site brittle.
Runtime Model
What Happens After You Accept a Draft.
- 01
Check the Draft
Validate the page before it becomes published so bad routes and broken blocks are caught early.
- 02
Store the Published Source
Approved markdown stays visible in the archive so the live source remains readable in the repo.
- 03
Build the Live Site Data
The app ships from generated page data instead of whatever files happen to be lying around.
See the Step-by-Step Publishing Guide.
The guide walks through the same flow with concrete commands and the exact sequence a writer or agent would follow.