A publishing workflow your team can actually maintain
How Bransford Media separates editable content from website code, with drafts, previews, and checks on the published result.
A website is easier to keep useful when changing a headline does not require changing application code. It is also easier to trust when a content edit does not silently change the site’s structure or access rules.
This note describes the publishing pattern used on Bransford Media and William Bransford’s personal site. They are separate websites with separate content stores. The shared idea is a clear division between editing content and developing the application.
Give content a proper home
Payload owns the page copy, media references, navigation, and published records. The application owns how those fields are rendered. A service description can change in the CMS while the page’s layout remains consistent.
This distinction prevents a common maintenance problem: the same paragraph appearing in an editor, a seed script, and a component, with no clear answer about which version is current. An importer can help with a migration; it should not become a second editing interface that overwrites later work.
Keep drafts separate from public pages
A useful publishing flow lets an editor save unfinished work and inspect a preview before publication. Preview access should be limited to authorized editors. Public pages and public content APIs should return published material.
Search engines should see the public version and its public URL. Preview URLs are working tools, not alternate destinations for visitors. That boundary needs to hold across pages, API responses, metadata, and sitemaps.
Turn existing material into useful pages
A video can live on YouTube and still have a useful page on the website. The page can explain the main idea, give a worked example, and link to related material. The video remains available without being the only way to understand the content.
On William’s site, videos and notes are native CMS records. A record can link to an external destination or have its own article body and URL. That lets the publishing workflow grow without creating a second blog application.
The useful test is whether the page answers a reader’s question. A transcript with a different title is not automatically a better resource. Context, examples, limitations, and a sensible next step matter.
Check the actual published result
Saving an edit, building an application, and inspecting the live page are different checks. The public result needs the right title, working links, readable media, and a layout that fits a narrow screen. A sitemap should contain the published canonical URL, and an old link should lead to the intended replacement.
For structural changes, we also check types, tests, and the production build. Those checks catch different failures; they do not replace looking at the page an actual visitor receives.
What to decide for your own team
Identify who drafts, who approves, and who publishes. Decide which fields editors can change, where media belongs, and how a previous version can be recovered. Define what requires development and what should remain a routine content edit.
If keeping a website current feels like a development project every time, websites and content work can address the publishing process as well as the visible pages. If the bottleneck is the handoff between tools and people, start with marketing systems.