Leaving Elementor without losing your rankings
A page builder migration is a move, not a redesign. Keep every URL, title and internal link where it was, and the site gets faster without a dip in traffic. Here is the checklist I run.
Sites don’t lose rankings because they left a page builder. They lose rankings because somebody treated the migration as a redesign and changed the URLs, the titles, and the links between pages at the same time as the code. Keep those three things exactly where they are, and Google sees the same site with a faster front end. That is the whole method. The rest of this article is how I make sure nothing moves.
- Change one thing: the markup. Not the URLs, not the titles, not the internal links, not the content.
- Build a URL map before touching anything, and check it after launch, not before.
- Migrate page by page on staging; the slow template goes first.
- Watch Search Console for 60 days: impressions by page tell you if anything slipped.
Why sites leave Elementor in the first place
Rarely because of the editor. Marketing teams like it. They leave because every page carries the builder’s CSS and scripts whether the page uses them or not, because the markup is six wrappers deep, and because at some point the speed work hits a ceiling that no amount of optimisation moves. I measure that ceiling before recommending a migration. If a site can get under 2.5 seconds on a phone with the builder in place, it should stay.
Case · Enterprise data platformElementor to a block theme, every page migrated by scriptBuilder removed, 160 articles moved, same design. Mobile LCP from 8.0 to 3.2 seconds, Lighthouse from 67 to 91 across the key pages.8.0 s → 3.2 sHomepage LCP, mobileWhat has to stay exactly the same
Four things. Everything else can change, these four cannot, and the whole checklist exists to protect them.
- URLsEvery page, post, category and tag keeps its address. Where a URL genuinely must change, a 301 to the one page that replaces it. Never to the homepage.
- Titles and meta descriptionsCopied, not rewritten. The urge to “improve” titles during a migration is how you get two changes at once and no way to tell which one moved the number.
- Internal linksThe links inside the content and in the templates: navigation, footer, related posts. A template that loses its “related services” block cuts links to every page it pointed at.
- Headings and contentH1 stays the H1, the text stays the text. Blocks can lay it out differently; the words and their order are the page Google already ranked.
A spreadsheet with every URL on the old site, its title, its canonical, its indexing status and its clicks from Search Console, next to the same for the new site. It is the only way to prove that nothing moved, and it is what I check against on launch day.
How I migrate
In one sentence: templates first, content by script, redirects checked by crawler, launch on a quiet day. In more than one sentence:
I start with the crawl. Screaming Frog or Sitebulb over the whole site gives the URL list, titles, canonicals, status codes and the internal link graph. Search Console adds clicks and impressions per page for the last 16 months, so the pages that earn traffic are marked and get checked by hand.
Then templates. A B2B site with 40 pages usually has five or six real layouts. Each becomes a set of native blocks: the hero block, the feature grid, the testimonial, the pricing table. Built once, with the fields the team edits, tested on a phone, measured. The slowest template goes first, because it is where the field data is worst and where the gain shows soonest.
Content moves by script where it can. Elementor stores page data as JSON in post meta; a migration script reads it, maps each widget to its block, and writes the block markup. On the data platform above, 160 articles went through the script in an afternoon. The handful that didn’t map cleanly were done by hand and listed, so the client knew which ones to proofread.
Redirects are the last build step and the first launch check. The map says which old URL goes where; a crawl of the old URL list against the new site proves every one of them answers 200 or a single 301, never a chain, never a 404.
# One hop, to the page that replaces it. Never to the homepage.
Redirect 301 /services/wordpress-speed-optimisation /services/wordpress-speed
Redirect 301 /blog/old-post-slug /insights/new-post-slugWhat usually goes wrong
The same four things, in roughly this order of frequency.
| What slipped | How it shows | How I catch it |
|---|---|---|
| Redirect to the homepage | Impressions for the old page vanish, nothing replaces them | Crawl of the old URL list after launch |
| Titles “improved” during the move | Rankings shift on exactly the rewritten pages | Title column in the URL map, old vs new |
| A template lost its related links | Pages two clicks deep lose impressions over weeks | Internal link count per page, before and after |
| Images renamed on export | Image search traffic drops, alt text lost | Media library kept, not re-uploaded |
Sometimes a page was ranking on the strength of a block of text the design hid in an accordion. If the new design drops the accordion, the text has to live somewhere visible, or the ranking goes with it. A migration is a good time to find out which pages those are.
The launch-day checklist
- Every URL in the map answers 200 on staging, with the same title and canonical
- Every changed URL 301s in one hop to its replacement
- robots.txt and the XML sitemap point at the new site, and staging was never indexed
- Analytics, consent banner and tag manager fire on the new templates, tested with a real form submission
- Mobile LCP on each template is under the target agreed before the work started
- Search Console is set to watch: a note on the launch date, a reminder for day 30 and day 60
Afterwards
Rankings do not react on launch day. Google recrawls over two to six weeks, and the Core Web Vitals report needs a full 28-day window before it reflects the new templates. So I set two reminders. At 30 days: impressions per page in Search Console against the map, looking for any page that lost more than a third. At 60 days: the Core Web Vitals report, which by then should show the mobile group moved from poor to good. If both are fine, the migration is finished. If one isn’t, the map tells us which page to look at.
Related serviceThinking about leaving Elementor, WPBakery or Divi?Page builder migration from $2,400: a URL map, native blocks your team can edit, a mobile LCP target agreed up front, and Search Console watched for 60 days after launch.See the service
Questions from this article.
Yes. That is the point of native blocks rather than a bespoke theme: the editor is the one WordPress ships, and the blocks are built to match your design, with the fields your team actually changes. No drag-and-drop canvas, but no locked-in layout either.
Three to eight weeks for a typical B2B marketing site, depending on how many distinct templates there are. Thirty pages that share four templates is a smaller job than twelve pages that each look different.
Animations and sliders usually go, on purpose, because they were a large part of the slowness. Forms, popups and tracking are rebuilt. If a client wants a specific effect kept, it is built as a block and measured like everything else.
Then something changed that should not have, and the URL map finds it. In practice a drop after a careful migration comes from a redirect that points to the wrong page, a title that was rewritten, or a template that lost its internal links. All three are on the checklist below.