Six reasons. Some technical, some political, all of them earned across 9 years of WordPress work — much of it cleaning up sites that Elementor wrote checks no team could cash.
1. The performance tax is non-trivial
Elementor adds 200–400KB of CSS and 100–300KB of JS to every page, regardless of what’s actually on it. That’s before any widget you actually use. On mobile networks at 4G speeds, that’s 2–4 seconds of LCP debt before your content even tries to render. Lighthouse 95+ is mathematically out of reach.
2. The output HTML is hostile to maintenance
Elementor’s HTML is a forest of nested divs with auto-generated class names like elementor-element-7a3f9e. There’s no semantic structure underneath. When you need to make a change, you can’t grep for the markup; you have to find the visual element in the editor and hope the right control exists.
3. Migration costs balloon
Content authored in Elementor is stored as Elementor-specific shortcodes in post_content. To migrate to anything else — Gutenberg, headless, another platform — you have to either rebuild every page by hand or write a custom parser. Most clients underestimate this by 5–10x.
4. The plugin pulls in 47 dependencies
Elementor + Pro + Header/Footer addon + Widget Pack + Crocoblock — by the time you have a “production” Elementor stack, you’re depending on 5–8 different paid plugins, all of which need to update in sync, all of which break each other periodically. The maintenance overhead is constant.
5. The accessibility story is a disaster
Default Elementor output fails most WCAG AA contrast checks, has missing aria attributes, hierarchy violations, focus traps. You can fix these manually but the editor won’t help; it’ll re-introduce them when someone updates the page. Every Elementor site I’ve audited has been an accessibility liability.
6. It teaches the team the wrong things
The most insidious one. Teams who ship on Elementor for two years internalise that “WordPress = page builder” and lose the ability to evaluate alternatives. They also never develop the content-modeling discipline that makes WordPress (or any CMS) actually scale. The platform’s strengths atrophy.
What I do instead
Custom block themes. Real Gutenberg. Custom blocks where needed, core blocks where they fit, ACF for structured fields. The site you’re reading is built this way — Lighthouse 100, sub-1s LCP, 12 hand-written blocks, zero builders. Every client engagement looks like this. No exceptions, even when asked.
Yes, I know the counter-argument
“My team can edit Elementor pages, they can’t edit Gutenberg.” Two responses: (a) Gutenberg in 2026 is meaningfully better than it was in 2020 — give it another look, and (b) the editor experience your team needs is a function of how the theme is built, not the underlying engine. A well-built block theme is friendlier than Elementor for editors, with none of the costs above.