This site, riaansmith.com, is already running on ESTAGE's new blog architecture. I'm writing this post inside it right now. That means I can speak about what changed from the inside out, not as a hypothetical.
Before I get into the specifics, a bit of context. If you've read my earlier hands-on review of the ESTAGE blogging platform, you'll know I've been testing this platform thoroughly and noting where the rough edges are. One of the rougher edges was always the relationship between a post's content and the page that displays it. They were the same file. That mattered more than it sounds.
Think about what that meant in practice. If you wanted to redesign your article layout, maybe adjust the column width, change the header style, or ask the AI to give the whole thing a different look, you were editing the same file your writing lived inside. A bad drag, an accidental section delete, or an AI that got a little too enthusiastic with a rebuild could take your actual post content down with it. That is not a reassuring place to store anything you spent hours writing.
What Actually Changes
The core shift is structural. Posts are now stored separately from the pages that display them.
Your blog is now made up of four ordinary pages: the blog index, single post view, author page, and category page. You can restyle any of those exactly the same way you restyle any other page on your site. Ask the AI for a completely different look. Delete a section. Rebuild the layout from scratch. None of that touches the posts themselves, because the posts are no longer inside those pages.
The writing is stored separately. The design is stored separately. They connect at publish time, not at edit time. That is the whole change, and it is a meaningful one.
It Happens By Itself, and You Can Undo It
You do not need to do anything to trigger the migration. It happens automatically the next time you publish your blog, or the next time you open the Posts panel. When it runs, the blog panel tells you it happened and shows an Undo button right there.
Pressing Undo actually reverts everything. ESTAGE keeps a copy of the previous version specifically so that button can work. If you undo once, that project will not be auto-upgraded again automatically. The manual upgrade button stays available if you change your mind later, so you're not locked out either way.
Posts written after the upgrade cannot be brought back with Undo. They are stored in the new format, and the old format has no place to put them. ESTAGE will tell you this rather than silently dropping anything, but it is worth knowing before you press Undo after having added new content.
There is also a deliberate exception to auto-migration. If any of your posts contain custom code added by hand, whether by you or by AI, or if you built a fully custom blog page, the new format has nowhere to store that kind of content reliably. Those blogs are left exactly as they are, and you are told specifically which posts are affected. Nothing is lost. Nothing is decided for you automatically. You get the information and the choice.
Fixed
Alongside the architecture change, ESTAGE shipped a set of real, distinct fixes. These are not polish items. They are things that were actively broken.
- Category filter buttons now actually filter. Before, selecting a category highlighted the button and did nothing else. The post list did not change. Now it shows the correct posts for that category. A genuinely empty category tells you it is empty, instead of reporting that the entire blog has no posts.
- Post text now opens from a Write button directly on the post. Previously you had to either double-click the body inside the preview or navigate through post settings to find the editor. That was undiscoverable enough that some posts went live still reading "Start writing your post..." with no one the wiser until someone clicked through.
- New posts start empty. The placeholder text that used to pre-fill a new post is gone. That placeholder was a publish-accident waiting to happen. A blank canvas is the right default.
Better In Search
For anyone running a content-driven site where the blog is meant to do real SEO work, not just exist, these are the changes that matter most. A site-wide SEO audit on a hub-centric setup almost always surfaces gaps around per-article metadata and schema completeness. The improvements below address exactly that category of problem at the platform level.
- The SEO title is now its own separate field. Before, one box served both the reader-facing headline and the search title. Optimizing for search silently overwrote what readers saw as the post title. Now they are independent. Leaving the SEO field empty falls back to the headline, same behavior as before, but you can write them differently when you need to.
- Author and category pages are now real, individually addressed pages. Previously they were signaling to Google that they were duplicates of the homepage, while the sitemap was pointing crawlers directly at them anyway. Each now has its own address, its own social preview settings, and its own index controls.
- Page Settings now apply to the blog index page. Whatever you typed there was quietly being ignored in favor of a generated default. That is fixed. What you write is what gets used.
- Articles now carry richer structured data. Google reads last-updated date, publisher information, and FAQ schema when deciding whether to show a rich result. Posts now include all three where applicable.
- Reading time is now counted from actual article content. Posts that were stuck showing "1 min read" regardless of length will show the correct estimate on the next publish.
- Hand-written pages placed under /blog/ are no longer skipped. An article written as a normal page now gets a proper listing and shows up in the Pages list. Those pages were effectively invisible to the blog system before.
A Smoother Place to Write
A few smaller UX items also shipped. None of these are architectural, but they remove friction that adds up over time.
- The Blog Manager now follows dark mode, matching the rest of Genesis.
- Inserting a button or a gallery now opens its settings panel alongside it. The link field was always there; the panel just was not opening automatically.
- Multiple images can be selected at once for a gallery, instead of reopening the picker for each one individually.
- The "Open editor" action now works every time, not only on the first click of a session.
Good to Know
- Your published live site does not change until you actually publish again. The upgrade reaches a live site the same way any other edit does, through a real publish. Nothing goes out on its own.
- Posts written after the upgrade cannot be recovered with Undo. The old format has no place to store content created in the new format. The system will tell you this before you confirm, not after.
- Nothing is deleted. Existing posts, images, and drafts all stay exactly as they are. The upgrade changes where things live structurally, not what exists.
Frequently Asked Questions
Will I lose my existing posts, images, or drafts?
No. Nothing is deleted at any point in the process. The upgrade changes where post data is stored structurally. Your content, images, and drafts remain intact.
What if I don't want the automatic upgrade?
Press Undo when the panel notifies you. ESTAGE keeps a copy of the previous version specifically so that button can work. After undoing once, that project will not be auto-upgraded again. The manual upgrade option remains available whenever you decide you want it.
Does this affect my live site immediately?
No. Your published site stays exactly as it is until you publish again. The upgrade only reaches visitors through a real publish, the same as any other change you make in the editor.
What if my blog uses custom code in some posts?
Those posts are not auto-migrated. The new format has no way to store hand-added custom code reliably, so the system leaves those posts alone and tells you exactly which ones are affected. Nothing is lost and no decision is made for you automatically.
Can I undo after writing new posts in the new format?
Not for those new posts specifically. Content written after the upgrade is stored in the new format, and the old format has nowhere to put it. ESTAGE will tell you this clearly before you confirm an Undo, so you are not caught off guard.
Do I need to do anything to trigger the migration?
No action is required. It runs automatically the next time you publish your blog or open the Posts panel, unless your blog falls into the custom-code exception. You will see a notification in the blog panel when it happens.
Separating content from the template that displays it is not a new idea in publishing. Every mature content platform eventually arrives there because the alternative, where a design edit can take down real writing, is structurally fragile. That ESTAGE has made this move is good news for anyone building a content operation on the platform long-term. The writing you put in is no longer a casualty risk when the layout needs attention. For a hub-centric business where the blog carries real authority and real SEO weight, that is a structural improvement worth understanding, not just a changelog item to scroll past.
This post is part of the same running series as my earlier look at stopping bot submissions with ESTAGE's reCAPTCHA v3 setting. If you are tracking platform updates and want to know what is actually changing under the hood, that post is worth reading alongside this one.