WordPress website design: keep some, move others

WordPress is open source software, and the project's about page says it is designed for everyone [1]. We keep some sites on it and move others off it because that breadth is also the weight: unused plugins, page builders, shortcodes, and a running list of updates. Staying is the better fit when a store already runs on WooCommerce and the team wants the WordPress editor. We move a site when the WordPress website design no longer matches the work, because the install has collected tools the business does not use.

What being built for everyone means

The about page says the software is built on PHP and MariaDB and licensed under the GPLv2, with the freedom to run it for any purpose and the freedom to change it [1]. That is what lets an owner keep the site and alter it, instead of renting a layout from one hosted builder.

On the philosophy page, which has no date and which we re-read in October 2026, the stated rule is that core should provide features that 80% or more of end users will actually appreciate and use [2]. The page says the core is designed to be lean, and that a theme and plugin system lets people add the rest. The owner then inherits whatever got installed.

The Manage Plugins guide, updated January 10, 2026, says plugins are PHP scripts that extend WordPress. Because so much functionality comes through plugins, core does not have to include everything for everyone [3]. The same guide says directory plugins are of varying quality and are often works in progress, and that a plugin not updated since the latest core release may be incompatible or of unknown compatibility [3]. The directory we loaded on October 21, 2026, tells visitors to browse over 76,000 free plugins [4]. That is a wide menu. We do not treat "available" as "belongs on this site."

Plugins, tables, and shortcodes

A plugin is not only a screen in the dashboard. The handbook page on creating tables is dated September 12, 2024, and it was still the live page when we checked in October 2026. It says someone writing a plugin will almost certainly need to store information in the WordPress database. Setup choices can live in the options system. Data that grows can live in a separate MySQL or MariaDB table, which the plugin creates [5]. Hiding that plugin's screens does not, by itself, promise the table leaves. We look for leftover tables on purpose.

Shortcodes age the same way. The developer handbook, which we re-read in October 2026, calls the Shortcode API a simple set of functions for creating shortcodes for use in posts and pages, and it notes that the API was introduced in WordPress 2.5 [6]. A token in the page text becomes a form, a gallery, or some other output while the plugin is active. On pages we review, the token often outlives the plugin. The visitor then sees brackets and a name where a button or a form should be.

Page builders are plugins, not core. The editor WordPress ships is the block editor. Documentation updated September 14, 2026, says that after WordPress 5.0 launched in December 2018, the block editor became the default and replaced the classic editor [7]. Blocks cover paragraphs, images, headings, lists, videos, galleries, and more, and plugins can add further blocks [7]. A team that works in that editor has a reason to stay. A team that only uses a separate builder depends on that plugin. When we turn one off in a review, the layout it owned often falls apart.

The weight is what one business added, kept after the need passed, and then still had to update.

When we keep a site on WordPress

We keep a site on WordPress when it is doing the job the business actually has, and the people who run it can still work in it.

A store is the clearest case. The WooCommerce listing in the plugin directory describes WooCommerce as the open-source ecommerce platform for WordPress [8]. Products, orders, and checkout already live there. The people who add a product already know those screens, or they are willing to stay with them. Moving that store to make a point would throw away a working catalog and retrain the people who update it. We would rather delete what the store does not use and leave the selling system in place.

One store we kept was already on WooCommerce. We moved it to our own server, with Cloudflare in front of it. We are not naming the business.

In our tests, 850 unused old tables were still in the database.

In our tests, the database was about 925 MB before we cleared out what those old plugins had left.

We saw the database at about 494 MB after that cleanup.

In our tests, the homepage server response was about 0.33 s on staging.

We saw about 0.9 s for that homepage on the old host.

Staging was the copy on our server. It answered faster in those tests than the old host did. Nothing in those tests argued for leaving WordPress. The store stayed on it. What changed was the host, the unused tables, and the old plugin data. That is one store. It is not a rank we offer the next client, and it is not a claim about calls or leads.

We also keep it when the team wants the editor and will use it. Someone who can change a headline, swap a photo, and publish a page is saving real time. If that person already works in WordPress, a new system has to be clearly easier. From Charlotte, we would rather watch a real page go up than push a move nobody needs. Being tired of unused plugins is a reason to delete plugins. It is not, by itself, a reason to throw out a catalog that already takes orders.

When we move a site off WordPress

We move a site when WordPress is mostly a container for tools the business no longer needs.

The public site is often a handful of pages, a phone number, and a form. Behind the login there is a page builder, a retired slider, two form plugins, an old gallery, and shortcodes in pages nobody has opened in a year. Updates are waiting, and something breaks when they are applied, because one plugin was never kept current. The owner wants the pages to say the right thing, and the phone number to be the current one.

The leaner path is a site built around those pages. We compared a purpose-built site and WordPress on our Forged and WordPress page. If the team lives in the editor or the store, stay and clean house. If nobody lives there, and the stack is the maintenance, move.

Plenty of businesses should stay. "We already have it" is not the same fact as "it still fits." A builder that felt easy in year one can be why a text change takes a developer in year six, and owners then delay edits because the edit feels risky. A dated font can be fixed in place. The decision is who can edit, what must be updated, and whether the plugins still earn a place. A few pages, a form, and a long plugin list nobody can explain is a reason to talk about leaving.

Updates are part of the decision

The update list is one reason the pile matters.

On September 22, 2026, WordPress.org released version 7.1.2 and described it as a fix for a critical severity security vulnerability. It recommended updating sites immediately [9]. The notes say an unauthenticated attacker can, under certain conditions, make page template resolution include a chosen readable local PHP file outside the active theme directories. If preconditions on the server and the active theme are met, that can lead to remote code execution [9]. The same note says only the most recent version of WordPress is actively supported [9]. The fix was backported, as a courtesy, through the branches eligible for security fixes, at that time through 4.7 [9]. A courtesy backport is not a reason to stay on an old branch.

The National Vulnerability Database record for CVE-2026-87902, published September 22, 2026, describes that same page-template issue and the same remote-code-execution precondition [10]. A CISA coordinator note on the record lists exploitation as active [10]. A secondary CVSS 3.1 entry lists a base score of 8.1, rated high, which is not the same label as "critical" on the WordPress.org release [10]. The preconditions were real, and so was the fix [9].

On October 6, 2026, WordPress 7.1.3 followed with 7 security fixes and 4 bug fixes [11]. The notes include stored cross-site scripting on the comments administration page, a denial-of-service issue in WP_Http::make_absolute_url(), and a second-order SQL injection in the WordPress WXR export [11]. Someone still has to apply the fixes and check the plugins beside them.

Plugin and theme updates are a separate switch. The WordPress.org guide was last updated on January 13, 2023, and it was still the page we loaded in October 2026. It says that since WordPress 5.5, an administrator opts in theme by theme and plugin by plugin [12]. It also says WordPress runs those auto-updates twice a day by default, and only where that opt-in is on [12]. The 7.1.2 notes add that, on sites which support automatic background updates, the core update begins on its own [9]. Plugins do not all join that list unless someone enables them, or the host changes the behavior. A quiet plugin may be fine, or it may be a plugin whose author stopped shipping.

The PHP version belongs in the same conversation. The requirements page, as we read it in October 2026, recommends PHP 8.3 or greater, and MariaDB 10.11 or greater or MySQL 8.0 or greater [13]. It also says WordPress still runs on PHP 7.4 or newer and MySQL 5.5.5 or newer, and that those older versions have reached official end of life and may expose a site to security vulnerabilities [13].

A WooCommerce store with a short plugin list, current core, a current PHP line, and a team in the editor is one we keep. A brochure site with a builder, dormant shortcodes, and a plugin list nobody can explain is one we would rather rebuild. WordPress was built so it can fit everyone. We look for the pieces a business added for a job it no longer has.

Practical takeaways

• Keep WordPress when orders already run through WooCommerce and the people who edit want the WordPress editor.
• Stay, and still clean house. Unused plugins, leftover database tables, and shortcodes from plugins you turned off are weight, not features.
• Move when the public site is a few pages and the login area is a page builder plus plugins nobody uses.
• Treat security releases as normal upkeep. Read the note, update core, and remember that plugin auto-updates are an opt-in, one plugin or theme at a time, on the guide last updated in January 2023 [12].
• Do not turn one cleanup into a promise. The database sizes and response times above are from one store, in our tests. They are not a ranking and not a lead count.
• If the month's real job is taking orders or letting your team edit, staying can be right. If the real job is fear of the update button, talk about a simpler site.

How we can help

Have more questions or want to get in touch? Visit our contact page. Call (980) 322-4500. Email [email protected].

Citations

1. WordPress.org, "About – WordPress.org" (2026-10-21)
2. WordPress.org, "Philosophy – WordPress.org" (2026-10-21)
3. WordPress.org, "Manage Plugins – Documentation – WordPress.org" (2026-01-10)
4. WordPress.org, "WordPress Plugins | WordPress.org" (2026-10-21)
5. WordPress Developer Resources, "Creating Tables with Plugins – Plugin Handbook | Developer.WordPress.org" (2024-09-12)
6. WordPress Developer Resources, "Shortcode – Common APIs Handbook | Developer.WordPress.org" (2026-10-21)
7. WordPress.org, "WordPress Block Editor – Documentation" (2026-09-14)
8. WordPress.org, "WooCommerce – WordPress plugin | WordPress.org" (2026-10-21)
9. WordPress.org, "WordPress 7.1.2 Release – WordPress News" (2026-09-22)
10. National Vulnerability Database, "CVE-2026-87902" (2026-09-22)
11. WordPress.org, "WordPress 7.1.3 Maintenance and Security Release – WordPress News" (2026-10-06)
12. WordPress.org, "Plugin and themes auto-updates – Documentation – WordPress.org" (2023-01-13)
13. WordPress.org, "Requirements – WordPress.org" (2026-10-21)