There are many capable ways to build a WordPress website. For new custom projects, we choose the native WordPress block editor, pair it with a custom block theme, and add a carefully selected block library where the project benefits from it.

We do not use Elementor or Divi for new custom builds.

That is not because those tools are incapable of producing good websites. They are mature products used by many businesses and developers.

Our decision is about the foundation we want to maintain. We prefer to keep the editing experience, page structure, performance work, and long-term maintenance as close to WordPress core as practical.

We also pay attention to the vendors behind critical plugins. Ownership, licensing, support, and development priorities can change, so every major dependency deserves ongoing review.

What’s the difference between the WordPress block editor and a page builder?

The block editor is part of WordPress core. Elementor and Divi add their own visual-building systems, controls, and rendering logic.

In the native editor, pages are composed from blocks stored in WordPress content. Block themes can extend that same editing model to templates and site-wide design settings.

Page builders introduce their own interfaces, components, styling systems, and methods for storing or rendering layouts.

That extra layer can make some design work faster or more accessible. It also becomes another system that must remain licensed, compatible, maintained, and understood.

For most custom business sites, we prefer the simpler dependency chain of WordPress core, a custom block theme, and a small set of intentional plugins.

Do page builders slow down websites?

They can, because any visual builder may add markup, styles, scripts, and dependencies to a page.

That does not mean every Elementor or Divi site is slow, or that every block-editor site is fast. Performance depends on the implementation, including hosting, images, plugins, JavaScript, CSS, caching, and content.

When we evaluate an implementation, we look at:

• DOM depth
• Stylesheet size
• JavaScript and other assets
• Number of requests
• Core Web Vitals
• Which assets load when a component isn’t being used

We have not included a universal speed comparison because a fair test requires equivalent pages, hosting, caching, functionality, and test conditions. We would rather publish measured results from a controlled comparison than present a headline number that does not hold across real sites.

Our preference is straightforward. On a custom build, we want direct control over the markup and assets so we can optimize the site component by component.

What is page-builder lock-in?

Page-builder lock-in appears when changing tools requires layouts, templates, or content structures to be rebuilt.

That future migration cost is one of the main reasons we avoid making a proprietary builder the foundation of a new custom site.

On a heavily builder-dependent site, the builder can become intertwined with layouts, templates, and content. What remains after deactivation varies by product and version, but the visual structure usually cannot be assumed to transfer cleanly to another system.

A tool selected today can therefore create a substantial migration cost later.

A website should belong to its owner, and its technology should not make future change unnecessarily expensive.

The native block editor is not immune to technical debt, but it keeps the site closer to WordPress’s own architecture and reduces dependence on a separate editing system.

Is the block editor good enough for a real business website?

Yes. A custom block-based WordPress site can support far more than a basic blog.

Depending on the project, it can support custom layouts, reusable patterns, structured content, custom post types, taxonomies, dynamic content, forms, calls to action, and responsive page structures.

The key is not to hand editors an unrestricted blank canvas and expect them to solve the design system on every page.

We build the design system, components, and guardrails around the editor.

Editors get useful flexibility inside a controlled system, while developers retain control over the implementation.

For most business websites we build, that is the right balance.

Can a non-technical person edit a block editor site?

Yes. That is one reason we use it.

The block editor gives content teams a visual interface for creating and updating pages without requiring them to know HTML or CSS.

A custom block theme can provide guardrails. Editors work with approved components and patterns instead of sorting through unrelated widgets and design controls.

The goal is useful control, not unlimited control. Content owners should be able to manage the site without turning every update into a new design project.

Which block library do we use?

We currently use Greenshift as our primary block library because its feature set fits the way we build with the native editor.

We evaluate block libraries against practical criteria and retest those assumptions as the product changes:

• Assets should load only where their features are used whenever possible.
• Unused blocks should not add avoidable assets to unrelated pages.
• We test what happens to content and layout if the plugin is deactivated or replaced.
• Dependencies should be limited, documented, and maintainable.
• The library should support the design system instead of forcing the design into a predefined template.

We are not looking for the library with the most widgets.

We are looking for tools that help us build a focused, maintainable WordPress site.

Why does plugin ownership matter?

Because a critical plugin is also a long-term vendor relationship. Ownership and business-model changes can affect licensing, support, product direction, and compatibility.

One of WordPress’s strengths is its broad ecosystem of core contributors, independent developers, agencies, and product companies.

That ecosystem gives site owners choice, but it also places responsibility on developers to evaluate the companies behind important dependencies.

Acquisitions and consolidation are one part of that risk assessment.

When a product changes hands, the new owner may preserve its direction or may change pricing, licensing, support, bundling, or development priorities.

Those changes are not automatically harmful, and ownership structure alone does not determine product quality. They are still reasons to review a dependency instead of treating the original choice as permanent.

Customers usually cannot control those business decisions, but they can reduce risk through contracts, backups, documentation, and a migration plan.

For us, the practical issue is dependency risk, not a blanket judgment about one type of owner.

WordPress sites often depend on software maintained by outside companies. That makes update history, support, security practices, licensing, portability, and vendor stability important selection criteria.

No ownership model automatically makes a plugin good or bad.

What matters is how the product is maintained and how changes affect site owners.

We watch for concrete signals such as unexpected licensing changes, reduced support, abandoned features, compatibility problems, or pressure to adopt additional products.

Business growth and user value can align, but they do not always align.

We make deliberate choices about which products sit at the center of a client’s website, and we revisit those choices over time.

Why Greenshift?

Greenshift currently gives us the block-level control and conditional asset-loading approach we want. That fit matters more to us than the length of a feature list. We choose a block library because it fits our workflow, performance goals, editing model, and maintenance standards.

Our priorities are:

• Conditional asset loading
• Minimal unnecessary dependencies
• Predictable markup and styling
• Compatibility with the native block editor
• A vendor and license model we can reassess over time

No software company can promise what its ownership, pricing, or product direction will look like five or ten years from now. We can still make thoughtful choices today and avoid depending on more software than the project needs.

Are page builders ever the right choice?

Yes. A page builder can be a sensible choice in the right context.

If a client needs to create complex landing pages frequently and already has the skills and process to manage them, a mature visual builder may be useful.

If an organization has hundreds of Elementor pages and a team trained around that workflow, replacing the system may create more disruption than value.

The right choice depends on the site’s goals, existing investment, team, budget, and tolerance for future migration work.

For a new custom build, visual drag-and-drop editing alone is not enough reason for us to place the entire site inside a separate builder ecosystem.

We would rather build the editing experience the client actually needs.

Why don’t we use Elementor or Divi?

Because our default for new custom projects is a simpler WordPress foundation with fewer central dependencies.

Elementor and Divi have made sophisticated page building accessible to a broad audience, and that value is worth acknowledging.

They also create their own workflows and layout systems. Once a site depends heavily on those systems, moving away can require substantial rebuilding.

That is a dependency we choose not to introduce into new custom builds.

We use WordPress’s native capabilities, add only what the project needs, and keep the relationship between content and technology as straightforward as practical.

Can you migrate off a page builder?

Yes, but the difficulty depends on the site’s size and how deeply the builder is embedded in layouts, templates, and content.

A small marketing site and a large site with custom templates, integrations, and years of accumulated content require very different migration plans.

Migration usually involves auditing what can be preserved, rebuilding layouts, cleaning up content, recreating templates or functionality, and testing before launch.

There is no universal conversion path. If the old site depends heavily on the builder, migration may function much like a rebuild.

What does it cost to move away from a page builder?

A flat price is rarely useful because migration cost depends on the existing site’s size, complexity, content, and dependencies.

The biggest factors are:

• Number of pages
• Amount of builder-specific content
• Number of custom templates
• Custom functionality
• Content structure
• Existing plugin dependencies
• Whether the visual design is being preserved or redesigned

For a new site, avoiding unnecessary lock-in is usually less expensive than removing it later.

For an existing site, the first step is an audit that separates what can be retained from what must be rebuilt.

Our approach to WordPress

We build custom block themes with the native WordPress editor and do not use proprietary page builders for new custom projects.

We use Greenshift where it adds clear value, keep dependencies intentional, and build components around the website’s actual needs.

The goal is not to follow a trend or declare every other approach wrong.

It is to build websites that remain useful and maintainable after launch.

Your website should be yours.

The content should be yours.

The technology underneath it should serve the website, not restrict its future.

Ready to get off Elementor?

If you are considering a new WordPress site or questioning an existing Elementor or Divi implementation, start with an assessment.

We will review the site’s structure, performance, dependencies, editing experience, and long-term maintainability. If the existing foundation is worth keeping, we will say so. If rebuilding is the better path, we will explain why and what the work should involve.

Ask Search Strategies to assess your WordPress site.

If you are ready for a new site, our standard WordPress build starts at $3,500 and includes custom design and development, five pages, SEO foundations, and a full year of our Advanced Care Plan.