Scheduling and updating blog posts

Schedule a new blog post for later, prepare an update while the current article stays live, or change an existing publication plan. The key is to distinguish the saved draft, the published version, and the time assigned to the next release.

For a first post, start with Writing and publishing a blog post. This guide assumes your post already has a saved draft.

The current blog editor has Write, SEO, Taxonomy, and History tabs, without a scheduling date picker. Use the personal assistant to schedule or clear a blog release when your site has that capability enabled. The editor’s Publish and Publish changes buttons publish immediately.

Choose the right action

• Keep working privately: choose Save draft. For a post already published, its earlier published version stays live.
• Release now: finish your review, then choose Publish for a new post or Publish changes for an update.
• Release later: save and review the draft, then arrange a future publication time through the assistant.
• Cancel a future release: ask the assistant to clear the publication schedule. Clearing a schedule preserves an existing live version.
• Remove the article from the website: move it back to Draft. This unpublishes the article and cancels its schedule; it is a different action from clearing the schedule.

If a post already has a schedule and you need to revise it, clear that schedule before making changes, especially when its release time is close or has passed.

Prepare the post and check scheduling access

1. Go to Site → Blogs on the correct site. Find the exact post by title or slug and use its edit action.
2. Finish the body, images, summary, author, category, tags, and search information. Check the address before sharing it.
3. Add a useful Change Note, such as “Revised class dates and booking instructions,” then choose Save draft. Wait for the saved confirmation.
4. Review the body’s Preview. For a new, unpublished post, return to Blogs and use Open draft preview to inspect its saved website layout.
5. If the article is already live, open its public address as well. Compare the current article with your intended changes so you know what readers will receive.

The blog list’s View action on a published post opens the live article. It is not a preview of an unpublished update. Use the assistant to obtain a preview of the latest saved update before scheduling it.

Scheduling needs permission to publish blog content, a working assistant service, and the assistant’s blog publishing tools enabled by your administrator. Read-only or draft-only assistance cannot complete a scheduled release. If the assistant reports a permission or service problem, keep the draft saved and ask your administrator to resolve it. See Why can’t I see or edit a feature?.

The Writing help and Draft review panels inside the editor help with content. For the scheduling requests below, return to the Blogs list and open Personal assistant chat using the assistant chat button.

Schedule a new post or a saved update

Give the assistant an exact article address, a full calendar date, a time, and a named timezone. Avoid requests such as “tomorrow morning” or “9:00” without a timezone.

1. Ask the assistant to read the post, confirm whether it already has a schedule, and provide a preview of its latest saved draft. Say that it should not publish or change the schedule yet.
2. Open the saved preview and check the complete article. For an update, compare it with the live version. Correct any issues in the editor, save again, and obtain a fresh preview.
3. Resolve any reported release blockers. If an AI review has flagged a blocker, review the finding and either correct it or dismiss it when you have confirmed it does not apply.
4. Tell the assistant to schedule the reviewed draft for your chosen future date and time. Identify the post again so the request cannot be confused with another article.
5. Ask it to read the result back: the exact post, the saved publication time and timezone, and whether an earlier version remains live.
6. Return to Blogs and inspect the post. An unpublished post should show Scheduled. An already live article can remain Published while a future update is scheduled, so confirm the stored publication time as well as the status label.

Here is a two-part request you can adapt. Replace the example address with your own post. Before sending the second message, replace [Month Day, Year] with your full future date and change the time and named timezone as needed.

Open the blog post at /blog/first-pottery-class. Tell me its current publication state and any scheduled time. Give me a preview of the latest saved draft and check its release readiness. Do not publish it or change its schedule yet.

After reviewing the preview:

Schedule the reviewed draft of /blog/first-pottery-class for 9:00 a.m. on [Month Day, Year] in America/Los_Angeles. Preserve any existing live version until then, and confirm the saved date, time, and timezone afterward.

The assistant’s response must confirm a completed scheduling action. A proposed plan, suggested date, reminder, or calendar entry is not proof that the blog publication has been scheduled.

Check the date and timezone carefully

Use a named timezone such as America/Los_Angeles or Europe/London, and check the offset for the selected date in the confirmation. Daylight-saving changes mean a location’s offset can differ between dates. Have the assistant clarify an ambiguous or nonexistent local time before scheduling it.

Choose a time in the future. A publication time at or before the current time can publish the post immediately. If your intended time has passed, decide explicitly whether to publish now or select a new future time.

If teammates work in different timezones, share the full date, time, and timezone together. A time displayed in another person’s local zone may represent the same scheduled moment.

Update a post that is already live

For a normal correction or content refresh, edit the existing post so its history and address stay together.

1. Open Site → Blogs, find the published post, and choose its edit action.
2. Check whether it has a future update scheduled. If it does, clear the schedule before continuing with revisions.
3. Edit the needed content in Write, SEO, or Taxonomy. Keep the slug unchanged unless you intend to change the article’s address and have a plan for existing links.
4. Add a Change Note describing the update, then choose Save draft. The current published version remains available to readers.
5. Review the new draft and compare it with the public article. Use a fresh saved preview from the assistant for the complete unpublished update.
6. Choose Publish changes when the update should go live now, or follow the scheduling steps above when it should go live later.
7. Open the public address in a signed-out or private browser window and verify the intended version after publication.

Publish changes saves and publishes the current edit immediately. It also clears an existing publication schedule. Finish your review before clicking it, and avoid making further edits while the request is running. If Cedros reports that newer edits still need saving, those later edits were not included in the completed publication.

The text, images, and metadata should all agree after an update. For example, when changing class dates, check the body, summary, featured-image text, linked booking page, and any downloadable checklist.

Keep media files needed by the live version available while preparing the update. Editing or deleting a shared library asset can affect the live page independently of saving the blog draft. For a different image, use a separate replacement file and follow Replacing or deleting a media asset.

Edit a post that already has a schedule

A scheduled release is tied to the current saved draft and its review. Saving a later edit can leave the publication time in place while making that review out of date. Do not assume that the originally scheduled text is locked into a separate copy, or that a newer unreviewed draft will publish successfully.

Use this sequence to avoid an unintended or missed release:

1. Ask the assistant to clear the post’s publication schedule while preserving any live version. Confirm that no publication time remains before editing.
2. Make the changes and choose Save draft.
3. Obtain and inspect a fresh saved preview. Recheck any release findings and compare the update with the current live article when there is one.
4. Schedule the reviewed draft again for a confirmed future date and time.
5. Verify the saved schedule after the last content change. Tell collaborators that further edits require another review and schedule check.

Be especially careful with an overdue schedule. Once a changed draft becomes reviewed again, an old time that has already passed can make it eligible for release. Clear the old schedule before reviewing the replacement when you want to keep controlling the release time.

Reschedule or cancel a release

Move the release to another time

Ask the assistant to read the existing schedule first. If the content has not changed, request the replacement future date, time, and timezone for that same post. Then ask it to confirm the newly stored time. If the content changed too, use the clear-edit-review-schedule sequence above.

For example:

Change only the scheduled publication time for /blog/first-pottery-class to the new future date and timezone I have provided. Keep its content and any existing live version unchanged. Confirm the replacement schedule afterward.

Cancel the future release and keep the content

Ask specifically to clear the publication schedule, rather than to unpublish or move the post to Draft.

Clear the publication schedule for /blog/first-pottery-class. Keep its saved draft and any currently published version. Confirm that no publication time remains and tell me what readers can still see.

After clearing the schedule, a post that has never been published returns to Draft. A post with a published version remains Published, with its saved update still available for later work. Clearing the schedule does not discard the draft or publish its changes.

In the Blogs list, choosing Draft from the post’s status menu and confirming Move to draft is different: it removes a live article from the website and cancels its scheduled release. Existing links can stop working. Use that action only when taking the article offline is your intention.

If a release time is very close, publication and cancellation can happen close together. Read back the final state and test the public address; a cancellation request alone does not establish which version is live.

Verify the scheduled release

Scheduling runs on the server, so you do not need to keep the browser open. The recorded time is the release target; confirm the result rather than assuming a status change will occur at an exact second.

After the scheduled time:

• Open the public article address in a fresh, signed-out window and check a specific changed sentence, image, or date.
• Confirm that the latest intended version is published and that the completed schedule has cleared. For a previously live article, Published by itself does not prove its update was released.
• Check images, downloads, buttons, and the mobile layout as a reader.
• Check the blog index with search and filters cleared.
• For coordinated announcements, verify the article before sending readers to it. Blog publication does not itself send an email campaign or social post.

If the post is still waiting, ask the assistant to read its saved publication time, current draft, reviewed version, and release blockers. A later unreviewed edit or a failed release check can prevent publication. Do not fix an overdue review until you have decided whether the post should publish now or be moved to a new time.

Troubleshooting and recovery

I cannot find a scheduling field. The current Write/SEO/Taxonomy/History blog editor does not expose one. Use the personal assistant when blog publishing is enabled for it. If scheduling is unavailable, keep the draft saved and arrange manual publication with an authorized teammate; a reminder does not schedule the article itself.

The assistant cannot schedule the post. Read the reported reason. It may need publishing permission, a working configured provider, a saved and reviewed draft, or a release issue resolved. Ask your administrator for the specific missing access or service. Do not use Publish as a substitute unless you want the article live immediately.

The assistant says the review is stale. Someone saved a different version after the earlier review. Clear any existing schedule, inspect the latest draft, refresh its review, and schedule that version for a future time.

The scheduled time passed but nothing changed. Check the timezone, saved time, latest review, and any blockers. If those are correct, ask your administrator to check scheduled publishing. Repeatedly refreshing the public article does not run the publishing job.

An associated pillar prevents release. A post linked to a pillar needs a valid release plan for that relationship. Check the post’s Taxonomy and ask the assistant to explain the reported dependency. Coordinate the pillar’s publication instead of removing the relationship simply to silence a blocker.

I need an earlier version back. Preserve any newer work you want to keep and clear the schedule first. In the editor’s History, identify the revision by its date and change note. Check its address before restoring: an older route can affect public links before the restored body is published. Then choose Restore Blog Post As Current Draft. This replaces the current draft with that revision; it does not automatically publish it. Review the restored title, address, body, images, and metadata before publishing or scheduling again. Follow Unpublishing or restoring content for the recovery sequence.

The website still shows the old article. Save draft alone does not update the public version, and scheduling an update keeps the existing version live until release. Check the exact public address and publication state before assuming a browser cache problem.

For help, use Getting help and reporting a problem. Include the site and article addresses, intended date/time/timezone, confirmed saved time, exact error, whether the post was already live, and whether anyone edited it after scheduling. Keep private drafts and preview links out of public reports.