Change WordPress Theme Without Losing Your Testimonials
August 12, 2026 · Testimonials
❝
❝
❝
Sample wall, illustrative content. Your real testimonials collect and embed the same way.
Send a request, watch the wall of love fill
Whether your testimonials survive a theme change depends entirely on where they are stored, and in the three most common WordPress setups they are stored somewhere that does not survive. Your posts and pages are safe. WordPress keeps those in the posts table and no theme owns them. Testimonials are different, because on most sites they were never saved as content in the first place. They were typed into a page builder module, or into a post type your theme invented.
The rest of your site gives you plenty of warning when a migration goes wrong. Testimonials do not. They usually look fine right up until the moment you activate the new theme, and then a section that was carrying your social proof is either empty, showing bracketed markup, or gone from wp-admin entirely while the rows sit untouched in the database. Here is how to work out which of those is about to happen to you, before you switch rather than after.
Will I lose my content if I change my WordPress theme?
Your posts, pages, media library, menus and users are stored independently of the theme and come through a theme change intact. What you lose is anything the theme itself was responsible for: widget placement, customizer settings, shortcodes the theme registered, and any content type the theme created. Testimonials commonly fall into the last two categories, which is why they are one of the first things people notice missing.
Where your testimonials live decides everything, so start there:
| How your testimonials were built | Where the text actually lives | What happens on theme switch | Recovery |
|---|---|---|---|
| Divi 4 Testimonial module | An et_pb_testimonial shortcode inside the page content | Raw shortcode text appears on the live page where the testimonial was | Manual edit per page, or find and replace across the posts table |
| Divi 5 Testimonial module | Divi's newer storage format, not shortcodes | The section comes up empty. Elegant Themes describes it as starting with a blank slate | Retype every testimonial into the new build |
| Elementor testimonial or carousel widget | Elementor's own data, stored in post meta rather than the page content | The content disappears from the rendered page and is orphaned in the database | Retype, or keep Elementor installed indefinitely |
| Custom post type registered by your theme | The posts table, as real records | The rows survive but vanish from wp-admin, because nothing registers the post type any more | Re-register the post type, then the content reappears |
| Custom post type registered by a plugin | The posts table | Nothing. The plugin is independent of the theme | None needed. Restyle only |
| Typed into Gutenberg core blocks | Page content as plain HTML | Survives. It may look wrong until you restyle it | Styling only |
| Embedded from outside WordPress | Not in WordPress at all | Nothing. The embed renders in the new theme | None |
The two rows worth reading twice are the theme-registered post type and the page builder rows, because between them they cover most WordPress sites that display testimonials at all.
The theme-registered post type trap
This is the one that causes genuine panic, and it is also the most recoverable, so it is worth understanding before you start deleting things.
Plenty of commercial themes, especially the large multipurpose ones sold on marketplaces, register a testimonials post type in the theme's own code. While that theme is active you get a Testimonials item in the wp-admin sidebar, you add each testimonial as a record, and everything behaves like a proper content library. Then you switch themes. Nothing in the new theme registers a post type by that name, so WordPress stops exposing it. The Testimonials menu disappears, the archive returns a 404, and every testimonial appears to be gone.
They are not gone. The rows are sitting in the posts table exactly where they were, with a post type value nothing is currently claiming. Register that post type again, from a plugin or an mu-plugin rather than from the new theme, and the entire library reappears in wp-admin untouched. Search the WordPress.org support forums for testimonials custom post type disappeared and you will find people who assumed they had lost years of content and had not.
The lesson underneath it is the long-standing WordPress principle that content types belong in plugin territory, not in a theme. A theme is meant to control presentation. The moment it also owns a content type, your content is only as portable as your design decisions, and every future redesign becomes a data migration. If you are building this yourself, register the post type in an mu-plugin, which loads automatically and does not care which theme is active.
What happens to Divi testimonials when you switch themes
Divi is worth its own section because the answer changed recently, and because both answers cost you the same thing.
In Divi 4, every module you place is written into the page content as a shortcode, and the Testimonial module is no exception. While Divi is active WordPress renders that shortcode into a testimonial. Deactivate Divi and nothing is registered to render it, so visitors see the raw shortcode text instead. On a site with testimonials across a home page, a pricing page and a few landing pages, that is not a graceful degradation, it is bracketed markup where your proof used to be.
Divi 5, which exited beta on February 26, 2026, moved away from shortcodes to a more modern storage format. Elegant Themes are direct about what that means when you leave: if you build your website with Divi 5, and then switch to a new theme or builder, you will start with a blank slate instead of with unwanted shortcodes in the post content.
That is a real improvement and it is not the improvement you were hoping for. A blank slate is cleaner than shortcode debris, and it is still blank. Every quote, name, job title and portrait you entered by hand is not carried across either way. The full picture, including the fact that Divi has no native testimonial carousel at any price tier, is on the Divi testimonial slider page. Elementor arrives at the same destination by a different route, storing each quote in its own data rather than in the page content, which is covered on the Elementor testimonial widget page.
How to check which situation you are in before you migrate
Ten minutes of checking now saves a bad afternoon later. Work through these in order on a page that currently shows testimonials.
- Look for a Testimonials item in the wp-admin sidebar. If it exists, find out what created it. Deactivate your testimonial-related plugins one at a time on a staging copy and see whether the menu disappears with a plugin or only when you switch the theme. If it is the theme, you have the trap above and you now know it is recoverable.
- Open the page in the block editor rather than the builder. Switch a Divi or Elementor page back to the default editor and look at what is there. Shortcodes in brackets mean Divi 4. An empty page with the content held elsewhere means Elementor or Divi 5. Readable HTML means you are in good shape.
- View the page source on the live site and search for the text of one testimonial. If the quote is in the delivered HTML, it is on the page. If it only appears after JavaScript runs, it is coming from somewhere else, which is worth knowing for both migration and indexing.
- Copy every testimonial into a spreadsheet before you touch anything. Quote, name, role, company, date, and where you got permission. Unglamorous, and it is the only step on this list that guarantees you still have the words on the other side.
- Check your consent records separately. Permission is usually in an email thread, not in the module, so a migration that loses the testimonial rarely loses the consent with it. It does mean the two are stored in different places, which is its own problem the day someone asks you to take theirs down.
What to do the week before you switch
Take a full backup including the database, and stage the new theme rather than activating it live. That much is standard. The testimonial-specific work is deciding whether you want to be in this position again in three years, because most sites go through a redesign roughly that often, and each one repeats this exercise from scratch.
The durable fix is to stop storing testimonials as page layout. Keep them somewhere the theme does not own, then render them into whatever design you are running at the time. A plugin-registered post type does that inside WordPress. Keeping them outside WordPress entirely and dropping in one line of embed code does it without adding a plugin to maintain, which also means the same approved testimonials render on a landing page built in a different tool, and one edit reaches all of them. The trade-offs of each route are worked through on the WordPress testimonial plugin page.
One thing worth planning for on the other side: a theme change is a site-wide event, and rankings can move for reasons that have nothing to do with your testimonials. Templates change, headings get restructured, and internal links quietly disappear from the new design. Give yourself a reason to go back through the pages that mattered and check the published versions still hold up a few weeks later, rather than assuming a visual match means an SEO match.
And if the honest answer is that you only have three testimonials and losing them would not hurt much, that is the real finding, and the migration is not the problem worth solving. Fixing the collection rate is. The mechanics of getting testimonials without chasing people are on collect testimonials, and the wording that gets a reply is in how to ask for a testimonial.
Collect proof without chasing
Send one link, your customers record a video or text testimonial in seconds with no login, and you embed a beautiful Wall of Love in minutes. Text and video, unlimited, at one flat price.