The riskiest thing about this redesign has nothing to do with how it looks. It’s that someone registered a custom post type in the old theme instead of a plugin, which means switching themes for aesthetics alone would silently take down two content types. Fix that dependency first, then worry about the redesign.
Migrations
Plan a theme migration or redesign without breaking existing URLs
A redesign plan for replacing an old theme that accounts for custom post types registered in its functions.php and structured data tied to old templates, not just the visual rebuild.
Works with Claude / GPT218 uses★ 4.2
The prompt
migrations-theme-redesign-without-breaking-urls
[clientsite.com] is getting a full visual redesign, moving from a heavily customized legacy theme to a new custom theme, and I've discovered the old theme's functions.php registers two custom post types ([Testimonials] and [Case Studies]) directly in the theme itself rather than in a plugin, meaning that content will vanish the moment the old theme is deactivated. Plan this redesign so the underlying content and SEO signals survive independently of the visual change, covering what a typical "theme redesign checklist" overlooks: 1. Orphaned content types: explain why custom post types registered in a theme's functions.php disappear (become inaccessible, not deleted, but effectively invisible and their URLs 404) the moment that theme is deactivated, and the fix, moving that registration into a small standalone plugin before the theme switch, so the content survives regardless of which theme is active. 2. URL structure changes: if the new theme or an accompanying permalink change alters the URL pattern for any content type, explain how to build the specific redirect map needed so existing rankings and backlinks for those URLs aren't abandoned. 3. Structured data and templates: the old theme likely outputs schema.org markup (review stars, breadcrumbs, article schema) directly in its template files. Explain how to confirm the new theme reproduces equivalent structured data, since losing it silently costs rich snippets in search results without any error being thrown. 4. Shortcodes and widgets: catalog any theme-specific shortcodes used inside post content (not just page builder modules), since those will render as literal text once the theme providing them is gone, and explain how to find every place they're used before cutover. 5. Cutover approach: given the custom post type risk, what to fix first (moving CPT registration to a plugin) before doing anything else, versus what can wait until the visual redesign itself is ready to go live. Tell me which of these fixes needs to happen well before the redesign is ready, since the custom post type issue is a content-loss risk independent of the visual work.