The classic page-builder-migration failure is leftover shortcode text rendering in plain sight on a live page because the old builder got deactivated before every page was rebuilt. Sequencing the cutover per page, with old-builder shortcodes still active until each page’s replacement is verified, avoids that entirely.
Migrations
Migrate a site from one page builder to another without breaking layouts
A rebuild plan for moving pages off one page builder onto another that accounts for leftover shortcode debris, builder-specific serialized meta, and SEO meta that must survive the rebuild.
Works with Claude / GPT95 uses★ 3.8
The prompt
migrations-page-builder-switch-without-breaking-layouts
I'm moving a 60-page WordPress site off [Divi] and rebuilding it in [Bricks Builder], because the client wants better performance and the old builder is being phased out. The pages have years of nested sections, custom CSS classes tied to Divi's own module IDs, and Yoast SEO metadata that must not change. Plan this rebuild so it's methodical instead of ad hoc, addressing the failure modes a generic "switch page builders" article doesn't mention: 1. Content audit before touching anything: how to find and catalog every page that uses builder-specific shortcodes or module markup stored directly in the post content (Divi wraps content in [et_pb_section] style shortcodes that will render as literal text if left behind after the builder is deactivated), so nothing gets silently orphaned. 2. Rebuild order and URL preservation: how to sequence rebuilding pages in the new builder while keeping the exact same URL/slug so internal links, backlinks, and Yoast's existing meta title/description/canonical settings carry over untouched even though the page content itself changes. 3. Custom CSS and responsive settings: Divi stores per-breakpoint responsive settings and custom CSS scoped to its own module class names, which won't translate automatically. Explain how to identify pages relying on custom CSS tied to those class names so styling doesn't silently break the moment Divi is deactivated. 4. Cutover strategy: whether to rebuild in place on production page by page (risking a half-migrated site being visible) versus rebuild on staging and swap per-page, and the tradeoffs of each given a small team doing this alongside normal client work. 5. Verification: the specific check for confirming no leftover shortcode text or broken module markup is visible on any live page after each page's cutover, since this is the single most common visible failure in builder migrations. Give me a page-by-page migration order and a verification step for each page, not just a general strategy.