Serhii LypiiJe hoeft je site niet opnieuw te bouwen voor een page-builder switch. Dat is wat de meeste agencies zullen voorstellen, omdat een herbouw makkelijker te factureren is dan een migratie. Maar in negen van de tien gevallen is je bestaande content prima bruikbaar. Je hoeft alleen de hoes eromheen te veranderen.
Elementor naar Bricks migreren is een typisch voorbeeld. Beide builders draaien op WordPress, beide werken met dezelfde onderliggende content (posts, pages, custom post types, media). Het verschil zit in de manier waarop ze die content visueel renderen. De onderliggende inhoud kun je grotendeels intact houden.
In dit artikel beschrijf ik hoe je content overzet zonder dubbel werk, wat je doet met shortcodes en widgets die niet 1-op-1 vertalen, hoe je het snelheidsverschil meet, en wanneer een migratie juist géén goed idee is. Geschreven voor ondernemers die overwegen om weg te gaan van Elementor, en voor agencies die meekijken bij een eigen klant.
Waarom switchen mensen weg van Elementor
In mijn praktijk komen drie redenen telkens terug.
Snelheid. Elementor staat erom bekend dat het veel CSS en JavaScript laadt, ook voor pagina’s die het niet gebruiken. Volgens web.dev is dat een directe oorzaak van slechtere Core Web Vitals. Bricks en native Gutenberg laden veel minder overbodig.
Onderhoud en updates. Elementor brengt vaak grote updates uit met breaking changes. Eén update verkeerd, en je site ziet er anders uit. Bricks is conservatiever, Gutenberg is onderdeel van WordPress-core en daardoor stabieler.
Kosten. Elementor Pro is een jaarlijks abonnement. Bricks is een eenmalige aankoop (of een lifetime-licentie). Gutenberg is gratis. Voor sommige mkb-sites is dat een argument.
Of een switch zin heeft, hangt af van wat de site nu doet en hoeveel werk er al in zit. Daarover later meer.
Wat een page builder eigenlijk opslaat
Eerst het technische begrip. Elementor slaat zijn pagina-opbouw op als JSON in de WordPress-database, in een postmeta-veld. Bricks doet ongeveer hetzelfde, met een eigen structuur. Gutenberg slaat blokken op als HTML in de post_content-kolom.
Wat dat betekent: de content (tekst, afbeeldingen, links) zit in de database, maar de structuur (welke widget waar staat, met welke styling) zit in een specifiek formaat dat de ene builder begrijpt en de andere niet.
Een 1-op-1-automatische conversie van Elementor naar Bricks bestaat (nog) niet. Er is geen plugin die zegt: “ik lees jouw Elementor-pagina’s en bouw dezelfde Bricks-pagina’s op”. Wat je wel kunt: de content overnemen, de structuur opnieuw bouwen, en het zo handig mogelijk doen.
Route 1: Content overnemen via copy-paste
Voor sites met overzichtelijke pagina’s (10 tot 30 stuks) is dit vaak de pragmatische route.
Werkwijze per pagina:
- Open de pagina in Elementor in de front-end (de gewone bezoekersweergave)
- Selecteer en kopieer alle tekst, sectie voor sectie
- Open in Bricks of Gutenberg een nieuwe pagina aan met dezelfde naam
- Plak per sectie en bouw de structuur opnieuw op met de equivalente blokken/elementen
- Importeer dezelfde afbeeldingen uit de mediabibliotheek (die blijft hetzelfde)
- Stel de SEO-velden in (Yoast of Rank Math gegevens blijven gewoon staan)
Per pagina ben je 15 tot 60 minuten kwijt, afhankelijk van complexiteit. Voor een mkb-site met 15 pagina’s: een dag of twee.
Wat je daarbij wint: een veel schonere structuur. Bricks of Gutenberg laat zich vaak slanker bouwen dan Elementor. Pagina’s worden sneller en beter leesbaar in code.
Wat je verliest: animaties, sommige interactieve elementen, en specifieke widget-effecten die Elementor heeft maar Bricks niet (of andersom). Daar moet je vaak een alternatief voor verzinnen.
Route 2: HTML-export voor langere content
Voor blogposts of pagina’s met veel doorlopende tekst is een HTML-export sneller dan copy-paste.
Werkwijze:
- Bezoek de pagina in een browser
- Bekijk de paginabron of gebruik “View source”
- Knip het deel uit dat de content bevat (binnen de hoofdsectie van Elementor)
- Plak het in een tekst-editor en ruim het op: schrap Elementor-specifieke wrapper-divs, behoud headings, paragrafen, links en afbeeldingen
- Plak de schone HTML in Gutenberg (via een “Custom HTML”-blok of na conversie naar blokken)
- In Bricks: gebruik een Rich Text-element en plak de schone HTML
Voor blogposts werkt dit prima. Voor dynamische pagina’s (formulieren, sliders, prijslijsten) niet, omdat je daar functionaliteit verliest. Daarvoor terug naar route 1.
Shortcodes en widgets mapping
Het werk dat het meeste tijd kost. Elementor heeft een eigen ecosysteem van widgets (Image Box, Icon Box, Accordion, Toggle, Tabs, Forms, Pricing Tables). Bricks heeft zijn eigen verzameling. Gutenberg heeft blokken plus de blokken van plugins.
Wat ik per project doe: een mapping-tabel maken.
Voorbeelden van veelvoorkomende mappings:
- Elementor Heading → Bricks Heading of Gutenberg Heading-blok
- Elementor Icon Box → Bricks Icon Box of een eigen Gutenberg-blok-pattern
- Elementor Accordion → Bricks Accordion of Gutenberg Accordion-blok (uit een blokken-pakket)
- Elementor Form → Bricks Form, of doorverwijzen naar Gravity Forms of een ander vrijstaand plugin
- Elementor Pricing Table → Bricks Pricing Table of opbouw met losse Gutenberg-blokken
Sommige Elementor-widgets hebben geen directe vertaling. Specifieke effecten (parallax, masking, motion effects) zijn typisch Elementor. Bij een migratie kies je per geval: vervangen door een eenvoudiger alternatief, opbouwen met custom CSS, of accepteren dat dat element verdwijnt.
Voor klanten met sterke afhankelijkheid van Elementor-only-functies adviseer ik soms om te blijven. Daarover later.
Snelheidsverschil meten
Een belangrijke stap die vaak vergeten wordt. Voordat je begint, meet de huidige snelheid van een paar typische pagina’s via PageSpeed Insights of GTmetrix. Noteer de scores voor mobiel en desktop, LCP, FID en CLS.
Na de migratie meet je dezelfde pagina’s opnieuw. Bij een goed uitgevoerde Elementor-naar-Bricks-overstap zie je typisch:
- LCP daalt met 0,3 tot 1,5 seconde op mobiel
- Totale paginagrootte halveert vaak
- PageSpeed-score stijgt met 10 tot 30 punten
Zie je geen verbetering, dan zit het probleem ergens anders. Vaak: trage hosting, slecht geoptimaliseerde afbeeldingen, een externe API-call die alles vertraagt. Een page-builder-switch lost dat niet op. Dan beter naar WordPress verhuizen naar andere hosting zonder downtime of een snelheidsoptimalisatie kijken.
Wanneer je juist NIET moet switchen
Eerlijk over de grenzen. Een paar gevallen waarin een migratie geen goed plan is.
Een site met veel custom Elementor-werk en weinig pagina’s. Als je 5 pagina’s hebt met allemaal Elementor-specifieke effecten, kost herbouwen meer dan het oplevert. Optimaliseer dan binnen Elementor (cache, plugin-opschoning, beeldoptimalisatie).
Een Elementor-site met goede performance. Niet elke Elementor-site is traag. Een goed geconfigureerde Elementor-site met goede hosting kan prima scoren. Switchen om te switchen heeft geen zin.
Een klant zonder tijd of budget voor de overstap. Een page-builder-migratie is een meerdaagse klus. Voor een klant zonder tijd of budget lukt het niet om in korte doorlooptijd resultaat af te leveren. Beter een paar dingen optimaliseren in de bestaande setup.
Klanten die zelf doorbouwen. Heeft de klant zelf de site in Elementor opgebouwd en wil hij ermee doorgaan, dan is overstappen naar Bricks (een meer technische builder) een drempel. Gutenberg is in dat geval een betere stap.
Verbeteren boven herbouwen is hier letterlijk het uitgangspunt. Een page-builder-switch is een vorm van technisch herbouwen, dus de vraag is altijd: kan ik de bestaande situatie verbeteren in plaats van te vervangen?
Multi-stack: dezelfde aanpak voor andere builders
De aanpak werkt niet alleen voor Elementor. Vergelijkbare migraties die ik doe:
- Elementor naar Gutenberg (volledig native, geen aparte plugin meer)
- Divi naar Bricks of Gutenberg
- WPBakery (oude Visual Composer) naar Bricks of Gutenberg
- Beaver Builder naar Bricks
Bij WordPress-naar-andere-CMS-migraties (bijvoorbeeld WordPress naar Drupal) is dat een hele andere klus. Zie daarvoor Wix naar WordPress migreren voor de algemene aanpak van CMS-migraties.
Wat het kost
Een page-builder-migratie reken ik tegen 95 euro per uur, het migratie- en servertarief. Voor een typische mkb-site met 10 tot 20 pagina’s en wat blogposts kost het 12 tot 24 uur. Dat is inclusief:
- Inventarisatie van pagina’s en widget-gebruik
- Mapping-tabel maken
- Pagina’s opnieuw opbouwen in de nieuwe builder
- Aanpassing van templates (header, footer, archive)
- PageSpeed-meting voor en na
- Controle van forms en interactieve elementen
- Oplevering
Voor sites met veel custom code of grote omvang loopt het op. Bij twijfel: een gratis kennismaking en ik kijk eerst of een switch zin heeft.
