A blog post can be “almost ready” for days.
The writer thinks the editor has it. The editor is waiting for approval. Your virtual assistant does not know whether the approved version can be loaded into WordPress. The article eventually reaches the CMS, but the featured image is missing and nobody is sure who should schedule it.
The problem is not necessarily the content calendar. The publication date may have been clear from the beginning.
The problem is the handoff.
A useful blog publishing workflow makes it obvious who owns the article now, what that person needs, what must be true before the article moves forward, and who receives it next.
That becomes especially useful when a writer, editor, business owner, SEO specialist, and virtual assistant may all touch the same article before it goes live.
A content calendar answers questions such as what you plan to publish and when.
A publishing workflow answers a different set of questions:
Who owns this article at its current stage?
Which version is the current one?
What input is still missing?
What does the current owner need to complete?
Does somebody need to approve the next action?
Who receives the article after this stage?
What happens if the normal process cannot continue?
That difference matters because a due date alone does not move work.
Imagine an article scheduled for Friday.
The draft is finished on Tuesday. On Wednesday, the VA sees the file but does not know whether the editor has approved it. The editor assumes the owner will send the approved version to WordPress. The owner assumes the VA is already preparing the page.
Everyone knows the deadline.
Nobody owns the transition.
The fix is not another reminder. Give each transition a defined trigger and next owner.
If you already manage delegated work in a project system, the same principle applies to your Trello or Notion delegation setup: the task record should show enough context for the next person to act without reconstructing the assignment from messages.
You do not need a complicated publishing platform to make the process clearer.
For every stage, define five things.
What must exist before this stage begins?
For an editor, that might be a complete draft and its source material.
For a publishing VA, it should normally be the version that has actually been cleared for WordPress preparation, together with the metadata, images, links, or other approved materials included in the assignment.
“Article ready” is too vague if different people interpret it differently.
One person or role should own the next action.
Several people may contribute to an article, but that does not mean several people should simultaneously assume someone else is moving it forward.
At each stage, be able to answer:
Who has the article now?
Define what makes the current stage finished.
“Editing” is a status.
“Editorial review complete and unresolved questions returned to the content owner” is a completion condition.
Likewise, “in WordPress” does not necessarily mean ready to publish.
A WordPress preparation stage might be complete only when the approved copy is formatted, supplied images are placed, links have been checked, required metadata is entered, and the preview is ready for the designated reviewer.
Do not wait until a stage is complete to decide where the article goes next.
If editorial review ends with owner approval, say so.
If owner approval sends the article to a publishing VA, say so.
If WordPress preparation returns the page to an editor for final review, make that transition part of the workflow.
The next person should not have to discover that responsibility from a message sent after the previous stage finishes.
A good workflow also explains when not to continue.
For example:
the draft and brief conflict;
the approved image is missing;
a source link no longer supports a claim;
two files both appear to be the final version;
supplied SEO information conflicts with the article;
the WordPress layout breaks;
publication authority is unclear.
The VA should not have to resolve an editorial, SEO, technical, or business decision simply because the article has reached their stage.
One of the most useful boundaries in a publishing workflow is the distinction between approved content and a prepared WordPress page.
They are not the same thing.
Editorial approval answers questions about the content itself. Depending on your process, that may include the argument, facts, sources, wording, brand fit, specialist review, or other substantive issues.
WordPress preparation is an execution stage.
A publishing VA may be responsible for tasks such as:
loading the approved article;
applying the required heading structure;
formatting paragraphs, lists, and tables;
inserting approved links;
uploading supplied images;
entering media metadata;
adding the supplied SEO title and description;
setting the approved slug, excerpt, category, and tags;
checking the page preview;
preparing the article for final review or scheduling.
These are also among the recurring WordPress tasks that can be outsourced to a virtual assistant.
The important boundary is that WordPress preparation should not quietly become a second unplanned editorial rewrite.
If the publishing VA notices an unsupported claim, broken source, missing section, conflicting instruction, or substantial content problem, the workflow should tell them where to send it.
The AI content quality control checklist goes deeper into the checks that belong before publication. The publishing workflow has a different job: making sure those checks happen at the right point and that unresolved issues reach the right owner.
Your project-management status and your WordPress status do not have to be identical, but they should not contradict each other.
WordPress has built-in roles and capabilities that determine what different users can do. Its official roles and capabilities documentation distinguishes roles such as Administrator, Editor, Author, Contributor, and Subscriber.
That gives you a way to match access to responsibility rather than automatically giving a publishing assistant unrestricted administrator access.
If the VA only needs to prepare content, choose permissions based on that actual work and your site’s configuration. Plugins and custom roles can change what is available, so confirm the capabilities on your own site rather than relying on the role name alone.
The same principle applies to credentials. If another person needs access to the CMS or supporting systems, use a controlled account and access process rather than passing owner credentials around. The guide to sharing passwords safely with a virtual assistant covers that setup in more detail.
WordPress also distinguishes states such as Draft, Pending, Scheduled/Future, and Published. Its post-status documentation explains how those states support content workflow, including pending review for users who do not have publishing capability.
Use those states deliberately.
For example, your internal workflow could distinguish:
Ready for WordPress → editorial content has been approved for CMS preparation.
WordPress Draft Ready → formatting and required publishing fields are complete.
Final Approval Needed → the designated reviewer must approve the prepared page.
Scheduled → publication has been authorized and the post has been scheduled.
Published and Checked → the live page has been verified and the publication record updated.
The labels in your task system can be more specific than WordPress’s built-in statuses. What matters is that the team understands what each state means.
Use the following as a starting point for one recurring blog-production process.
Replace the roles and requirements with the way your business actually publishes.
| Stage | Starts when | Active owner | VA action | Done when | Next handoff |
|---|---|---|---|---|---|
| Topic and brief | Topic and search intent are approved | Content owner or SEO lead | Create or update the production record, attach the approved brief and required source locations | Writer has the current brief, deadline, format, and required inputs | Writer |
| Draft | Writer receives the complete brief | Writer | Track status and flag missing dependencies where coordination is in scope | Complete draft is submitted in the agreed location | Editor or content reviewer |
| Editorial review | Complete draft is submitted | Editor or responsible reviewer | Keep the current version and review status visible; route questions to the named owner | Required edits are resolved and content is cleared for CMS preparation | Publishing VA |
| WordPress preparation | Approved content and required publishing inputs are available | Publishing VA | Format the post, insert approved links and images, enter supplied metadata, and prepare the preview | Required WordPress preparation and preflight checks are complete | Final approver |
| Final approval | Prepared WordPress page is ready | Content owner, editor, or other authorized approver | Record requested corrections and return them to the appropriate owner; do not infer approval | Authorized reviewer confirms the prepared article can be scheduled or published | Publishing VA or authorized publisher |
| Scheduling/publication | Final approval is recorded | Authorized publisher | Set the approved publication date or publish according to the agreed process | WordPress shows the intended publishing state | Publishing VA or content owner |
| Live verification | Post is live | Publishing VA or designated checker | Open the live page, check important links and presentation, record the clean URL and publication status, and flag problems | Live page has passed the agreed post-publication check | Content owner / downstream promotion |
This is a handoff SOP, not a requirement to use seven separate people.
In a small business, one person may own several stages. Your writer might also edit. Your content owner might handle final approval and SEO. Your VA might prepare WordPress, run the publishing preflight, schedule approved content, and record the live URL.
Keep the stages even when the same person owns several of them.
The stages describe changes in responsibility and permission, not headcount.
This distinction prevents a surprisingly risky shortcut.
An article can be ready for WordPress preparation without being authorized to go live.
That lets the publishing work happen earlier without making publication approval ambiguous.
For example:
The editor approves the article for CMS preparation.
The VA formats it in WordPress and completes the assigned publishing fields.
The VA sends or records the preview for final review.
The authorized reviewer checks the prepared page.
Only after that approval does the article move to scheduling or publication.
WordPress supports scheduled publication through the post settings. Its Page/Post Settings documentation explains how a future publication date can be selected.
Your workflow should still define who is allowed to make that scheduling decision.
The ability to click Schedule is not the same thing as authorization to choose when an article goes live.
Publishing workflows become messy when several versions of the same article remain active.
You might have:
the writer’s original draft;
an edited copy;
a version with owner comments;
a downloaded file;
a copy already pasted into WordPress;
another document with last-minute corrections.
Choose one place where the current editorial version wins before the WordPress handoff.
Once the approved version has been loaded into the CMS, decide how later corrections are handled.
For small corrections, WordPress may become the current working version after the handoff. For more substantial changes, your process may require the source document to be updated as well.
The rule matters more than which tool wins.
WordPress also maintains post revisions, which can help you inspect and restore saved changes inside the CMS. That is useful protection, but it does not solve uncertainty about which external draft was approved in the first place.
If your publishing workflow repeatedly produces version confusion, fix the handoff before adding another tool.
A useful publishing process tells your VA how to handle normal work and abnormal work.
Use a simple blocker rule:
If the next action is clear and within the approved scope, continue. If an essential input is missing, contradictory, unapproved, or outside the assigned authority, stop that stage and flag the specific blocker.
The update should make the next decision easy.
Instead of:
Article blocked. Please advise.
Use:
WordPress formatting is complete. The supplied featured image is still marked draft, so I have not added it or scheduled the post. Final image approval is needed from the content owner. Once approved, I can add the image, run the final preview check, and prepare the post for scheduling.
That update identifies:
what is already complete;
what is missing;
who needs to act;
what will happen afterward.
It keeps the blocker from becoming another investigation.
The same rule works for conflicting links, missing metadata, unclear revisions, broken formatting, or an approval that was discussed but never recorded.
Do not build a 20-status publishing system before one article has gone through it.
Choose a normal post and follow it from approved topic to live URL.
At each transition, note:
what the next person needed;
what they had to ask for;
which status was ambiguous;
where two versions competed;
which approval was unclear;
which check happened too late;
which information had no obvious home.
Then fix those points in the workflow.
If you use a task board, update the task template.
If the problem belongs in the procedure, update the SOP.
If the same publishing instruction keeps being explained in messages, move it into maintained documentation. The guide to writing SOPs for virtual assistant tasks explains how to document inputs, steps, quality checks, exceptions, and definitions of done without turning a simple task into an enormous manual.
The objective is not to eliminate every question.
It is to eliminate the questions your process should already answer.
A good blog publishing workflow does not need to be complicated.
At any point, you should be able to look at an article and identify five things:
Current stage. Current owner. Required input. Completion condition. Next handoff.
Add a clear escalation rule and the workflow becomes much harder to lose between people.
Your content calendar can still tell you what should publish and when. Your project system can still track deadlines. WordPress can still hold the prepared page.
The publishing workflow connects those pieces by making responsibility visible from one stage to the next.
At Boost VA, I can support the recurring execution around that process, including content operations, WordPress preparation and publishing support, link and formatting checks, metadata entry, status tracking, and process-based backend work. If the editorial decisions are already being made but articles keep stalling between approved draft and published page, send me the workflow you want help keeping moving.