WordPress vs SaaS Website Platforms: A 2026 Comparison

The moment someone says "we need a new website," the room usually splits four ways: hire someone to build it on WordPress, sign up for Wix and drag it together, open a Shopify store, or commission a custom build. All four get recommended, all four have people who regret them, and quotes range from a few thousand dollars to six figures.

The problem is not a shortage of information. It is that most comparison articles compare features rather than the thing that actually matters: whether you will regret this decision in three years. This article compares differently. It uses real market-share data as background, five-year total cost of ownership as the yardstick, data portability as the risk gate, and one dimension almost no platform comparison covers — whether AI systems can actually read your site.

The direction of the answer, stated up front: there is no best platform, only the one that matches your technical staffing, your payment needs, your publishing cadence, and your three-year expansion plan. What follows is four comparison tables and a decision tree, so you walk into your first vendor meeting knowing what to ask and what to insist on. If you are still shaping the budget, start with how to read a website quote; if you already have a site, first settle whether you are redesigning or rebuilding.

Start with the data: WordPress is not dying, but open-source CMS share is leaking

Direct answer: WordPress remains the clear market leader, but its share is moving to SaaS site builders at a visibly accelerating rate. That is a trend signal, not a verdict on whether you should use it — but it should change how you assess risk.

Take the absolute numbers first. According to W3Techs CMS market share data dated 6 September 2026, WordPress runs 40.7% of all websites, and 58.9% of sites where a CMS is detected. In the same survey, Shopify holds 5.3% of all sites (7.7% of the CMS subset), Wix 4.2% (6.1%), Squarespace 2.5% (3.6%), Joomla 1.1%, Webflow 0.8% and Drupal 0.7%. On a like-for-like basis, WordPress is still more than seven times the size of the runner-up. Any article telling you WordPress is about to be replaced can be closed immediately.

The trend, though, is real and faster than most people assume. The W3Techs historical trend table shows WordPress at 62.9% of the CMS subset in 2024, 62.0% in 2025 and 58.9% in 2026. That is a 0.9-point drop in the first year and a 3.1-point drop in the second — roughly three and a half times faster. Over the same window Wix climbed from 3.8% to 6.1%, Shopify from 6.0% to 7.7%, and Squarespace from 3.0% to 3.6%.

Aggregate them and the picture sharpens. The open-source trio of WordPress, Joomla and Drupal went from a combined 67.0% of the CMS subset in 2024 to 61.6% in 2026, a loss of 5.4 points. The SaaS trio of Shopify, Wix and Squarespace went from 12.8% to 17.4%, a gain of 4.6 points. What open source lost, SaaS builders picked up almost one for one. That is not a coincidence. It is a generation of small business owners voting with their feet against managing hosting, backups, TLS certificates and plugin updates.

Here is the myth worth breaking: many readers interpret this as WordPress falling behind technically. It has not. The share loss is concentrated in the smallest, least customised end of the market — one-page brochure sites, small blogs, five-page company profiles. Those sites never needed a full CMS and plugin ecosystem, and a drag-and-drop editor is a more honest answer for them. The real signal is not that WordPress is worse, it is that if your needs are simple you may have been paying maintenance cost for flexibility you never used.

The inverse also holds. If your site has to talk to an ERP, run several languages, filter products by technical specification, or let you control URL structure and server configuration, the market-share trend barely applies to you — what you need is precisely what SaaS platforms withhold. A trend is a market average, not your answer. The rest of this article is about extracting your answer from that average.

One second-order effect is easy to miss: declining share thins out an ecosystem. WordPress's real value was never the software, it was the tens of thousands of plugins, the hosting companies, and the large pool of developers who know how to fix it. As share drifts down, maintenance enthusiasm for niche plugins drops first, which raises the risk of building a dependency on an obscure extension. This will not bite you within three years, but it is worth an extra moment of thought when you choose plugins.

What the four routes actually are

Direct answer: there are only four real options — self-hosted WordPress, SaaS site builders, ecommerce SaaS, and custom development. The difference is not usability, it is who owns the server, who owns the source code, and who is responsible when something breaks. Settle those three questions and the choice largely makes itself.

Self-hosted WordPress: you rent the server and own everything on it

You (or your agency) rent a server, install the open-source WordPress software, and add a theme and plugins. Code and database live on your hosting, and new capability comes from the official plugin directory or from custom code. The trade-off: hosting, backups, TLS, version updates and security are all yours to own.

SaaS site builders: the platform runs everything, you just lay out pages

The platform bundles the editor, hosting, CDN, certificates and updates. You lay out pages visually and never touch a server. The Wix plans page currently lists Light, Core, Business and Business Elite tiers on annual billing, with the company noting that displayed prices are for reference. The Squarespace pricing page differentiates tiers by annual discount and by commerce transaction fees that step down as you move up. The trade-off: you never get the source code, and your ceiling is whatever the platform exposes.

Ecommerce SaaS: payments and logistics are native, fees are the price

Fundamentally a SaaS product built for selling. Payments, shipping, inventory, discount codes, multi-currency and tax are native rather than bolted on. The official Shopify pricing page lists monthly fees from the Basic plan upward along with card rates — 2.9% plus 30 cents for online transactions on Basic. The trade-off: on top of the subscription you pay transaction and processing fees, and non-commerce content pages such as blogs and technical documentation are noticeably less flexible than on WordPress.

Custom development: total freedom, total responsibility

Built from scratch on a framework, or headless, with a custom front end talking to a CMS or ERP behind it. You control HTML, URLs, caching and data structures, and you can integrate directly with internal systems. The trade-off: highest upfront cost, longest timeline, and a long-term relationship with a development team — a custom system nobody can pick up is a time bomb three years out.

The custom-development cost anchor above comes from Shopify's own ecommerce website cost guide, which puts custom builds at roughly 2,000 to 20,000 US dollars or more depending on complexity, a ten-page design build at 3,000 to 15,000, and domain registration at 9 to 30 dollars a year. Treat those as ranges, not quotes — page count, degree of customisation and system integration are what actually move the number.

Five-year total cost of ownership: the half that never appears on the quote

Direct answer: never compare platforms on build cost alone. Compare five-year total cost of ownership, because SaaS costs are deferred while self-hosted costs accumulate, and the two curves usually cross somewhere in year three or four. Judge on the first-year quote and you will choose wrong.

Start with the number small businesses most reliably underestimate: recurring overhead. Domain renewal, hosting, certificates and backups are the costs that begin the day you launch, and they are annual rather than one-off. Shopify's cost guide puts shared hosting at roughly 2 to 10 US dollars a month, cloud and VPS from 10 to 200 or more, and domains at 9 to 30 dollars a year — small individually, but they never stop. A useful planning rule from budgeting practice is to size the whole website budget as a fraction of annual revenue rather than as an isolated project cost, so that a growing business does not underfund the thing customers see first.

The last two rows carry the argument. Ecommerce SaaS cost grows with your revenue. At 2.9% plus 30 cents per online transaction on Shopify's Basic plan, a business doing a few million dollars of online sales is paying a meaningful five-figure sum in card fees alone, and that figure scales linearly with growth. That is not automatically bad — you are buying zero operations and very high reliability — but it belongs in the model rather than being waved away as "just the monthly fee."

Self-hosted WordPress inverts the shape. The monthly bill looks trivial, and the cost hides in labour. The Patchstack State of WordPress Security in 2026 whitepaper counted 11,334 new vulnerabilities disclosed across the WordPress ecosystem during 2025, a 42% increase over the 7,966 seen in 2024. Of those, 91% were in plugins and 9% in themes, while WordPress core itself accounted for just six, all low priority. More pointed still: 46% had no patch available at the moment of disclosure, and for heavily targeted flaws the weighted median time to first exploitation was five hours.

Read those numbers correctly. They do not say WordPress is insecure. They say WordPress core is well maintained and the plugins you install are the risk surface. So the honest TCO for self-hosting must include a named role: someone who reviews updates, tests compatibility and verifies backups every month. That work can be outsourced to a retainer or handled in-house, but it cannot be absent — and it is the single largest cost difference between self-hosting and SaaS.

A third cost that rarely gets modelled is the sunk cost of redesign. SaaS templates swap quickly, but once you want something the platform cannot do, the only route is a full rebuild. Swapping a WordPress theme can also mean re-laying every page. The only route that genuinely evolves incrementally is custom development, which is also the one with the highest entry price. This is why running an annual technical self-check on your site pays for itself: the earlier you find the platform ceiling, the cheaper the rebuild.

SEO flexibility: the ceiling is set by the platform, not by your effort

Direct answer: all four routes can do baseline SEO well. The difference is the ceiling — when you need control over URL structure, server-level redirects, deep structured data or multilingual hreflang, SaaS platforms hit a wall and WordPress and custom builds do not. For a ten-page brochure site that difference is irrelevant. For a manufacturer building a long-term content position, it is the whole decision.

Every modern platform handles the basics: titles and descriptions, image alt text, sitemaps, canonicals, Open Graph, mobile rendering, HTTPS. Those are table stakes. To confirm you have not missed one, work through a manufacturer website SEO checklist line by line.

The real divergence shows up in four places.

One: freedom over URL structure

WordPress and custom builds let you shape paths freely; SaaS platforms often force a fixed prefix on certain page types. That alone will not stop you ranking, but it becomes a hard limit when you want topic clustering or a one-to-one migration of an existing URL set. Never change platforms without a complete 301 mapping — it is the most common and most expensive migration mistake there is.

Two: depth of structured data

Google's introduction to structured data lists dozens of usable types, and the search appearance gallery shows which ones actually change how results are displayed. Ecommerce SaaS handles Product and Offer thoroughly because that is its business. A B2B manufacturer usually needs a different combination — Organization, detailed product specifications, FAQPage, HowTo, BreadcrumbList — with custom fields per page. That is fully controllable on WordPress and custom builds, and platform-dependent everywhere else.

Three: multilingual and hreflang

Any company selling across borders ends up with at least two languages. The technical crux is that hreflang annotations and per-language URL structures must line up correctly. WordPress has a mature multilingual plugin ecosystem, and custom builds can use framework-level i18n routing. SaaS platforms usually offer multilingual features, but the URL form of the language switch and whether each language can carry independent metadata and structured data vary widely. If export is the point of the site, verify this during platform selection rather than after launch. For the full sequence, see the export website build guide.

Four: server-level control

Redirects, cache headers, robots.txt, custom error pages, CDN behaviour — configuration files on self-hosted and custom builds, switches on SaaS. A concrete example of how much the granularity varies: Wix exposes an actual robots.txt editor, with an explicit warning that it is an advanced feature its support team will not troubleshoot, while Squarespace instead offers a checkbox that updates robots.txt on your behalf to request that known AI crawlers stay out. Two SaaS platforms, two very different levels of control — which is exactly the kind of thing to verify item by item during selection.

One myth to retire: SaaS does not automatically mean worse SEO. Page speed, mobile experience and certificate handling on a good SaaS platform routinely beat a cheap shared host, and those are genuine ranking inputs. The difference is not the floor, it is the ceiling — and the cost of choosing wrong shows up not in year one but around article two hundred, when you want to do something advanced.

The AEO angle: can AI actually read your website

Direct answer: AI search crawlers largely do not execute JavaScript, so a site that looks fine in a browser may be invisible to them. Whether a platform can serve server-rendered HTML and complete structured data is the most underrated platform-selection criterion of 2026. It appears in almost no platform comparison article.

Start with the mechanism. Google's own JavaScript SEO basics documentation describes a three-stage pipeline: crawl, then a render queue where headless Chromium executes the JavaScript, then indexing. One sentence in that document deserves to be pinned above every website project: server-side rendering or pre-rendering is still a great idea because it makes the site faster for users and crawlers, and not all bots can run JavaScript.

"Not all bots" means the AI crawlers. The Vercel and MERJ analysis published as The rise of the AI crawler puts hard numbers on it: in a single month GPTBot generated 569 million requests and Anthropic's Claude crawler 370 million, and none of the major AI crawlers currently render JavaScript. They will even download JavaScript files — 11.50% of ChatGPT requests and 23.84% of Claude requests — and then not execute them, reading only the raw HTML. The same analysis surfaced another number worth noting: 34.82% of ChatGPT fetches and 34.16% of Claude fetches hit 404 pages, against just 8.22% for Googlebot. AI crawlers are markedly worse at guessing URLs, so the cleanliness of your sitemap and internal links directly determines how much of your site they ever see.

In plain terms: if your product specifications, application notes or technical articles load through client-side JavaScript, that page may be blank as far as ChatGPT and Claude are concerned. As AI search absorbs a growing share of discovery, that is invisibility on an entire new channel.

The second issue is whether you can control how AI systems treat you. OpenAI's crawler documentation separates its bots into three: GPTBot for gathering training data, OAI-SearchBot for surfacing sites in ChatGPT search, and ChatGPT-User for user-initiated fetches where robots.txt rules may not apply. That implies something most owners never consider: you can block the training crawler while still admitting the search crawler — but only if you can write robots.txt yourself. On a checkbox-only platform, that trade is unavailable.

The third issue is structured data. For an AI system to describe you as a distinct entity it needs explicit Organization, Product and FAQPage markup, not attractive layout. The schema.org Organization type defines fields for legal name, address, certifications and contact points — precisely what a model needs to identify you when an overseas buyer asks which suppliers make a given component. For implementation detail, see the AEO technical setup guide.

The right way to read that table is not "custom development wins." It is: decide first whether you need this control. A company with a brochure site and no ambition to be discovered through AI search is fine with a checkbox. But if the strategy is to have North American buyers find you through AI answers, then writing your own robots.txt and emitting your own JSON-LD stop being technical details and become commercial requirements — free to secure before you sign, expensive to retrofit two years after launch.

There is a follow-on observation worth keeping. A 34% 404 rate means AI crawlers depend heavily on the structure you hand them. An accurate sitemap, URLs that do not silently change, and clear breadcrumbs and internal links are worth more to an AI crawler than to Google. Which loops back to platform choice: if your platform rewrites URLs whenever you edit a title and leaves no redirect behind, you are manufacturing dead links in the one channel that forgives them least.

Vendor lock-in: can your data actually leave

Direct answer: content usually travels, design and functionality usually do not — and the most common mistake is believing that "we can export a CSV" means "we can migrate." This is the least-asked question during selection and the most painful one three years later.

Split "data" into four layers and the differences become obvious: content (text, images, specifications), structure (URLs, taxonomies, navigation), design (layout, styling, interaction) and functionality (forms, payments, memberships, integrations).

Self-hosted WordPress gives you all four. Content sits in your own database, and the official export tool produces a WXR XML file containing posts, pages, taxonomies and custom fields. Themes and plugins are real files you can archive and move to another host. That is the underrated value of self-hosting: not that it is cheaper, but that it is free to leave.

Shopify sits in the middle. The Shopify Help Center documents CSV export for products, orders and customers, with UTF-8 encoding required and a per-file size limit, so your core commercial data travels. But themes are written in Shopify's Liquid templating language, app configuration and data mostly live with the app vendors, and payment and subscription relationships obviously do not follow. You can take the data, not the store.

SaaS site builders sit at the locked end. Wix states it plainly: because Wix is a SaaS architecture, the site must run on Wix servers and external hosting is not supported. You can export CMS collections, products, contacts and orders, typically as CSV, but the site code, layout and functionality cannot be exported and will not run anywhere else. Practically, switching platforms means rebuilding the site and paying the design cost a second time.

Custom development looks maximally free — the code and database are yours — but it carries a different lock: people. When only the original agency understands the system and the documentation is thin, you can be as stuck as on any SaaS. The mitigations are concrete: put code and database ownership in the contract, require technical and deployment documentation as a deliverable, and insist the repository lives in your own Git organisation. That is exactly what an RFP and acceptance checklist is for.

That last row is the most useful thing in the table. Whatever route you choose, the domain name must be registered under your company's own account, not your agency's. It is the most common avoidable form of lock-in: fall out with a vendor while they hold the domain, and you cannot even hire someone else.

The decision tree: four questions that pick your route

Direct answer: answer four questions in order and you converge on one or two options — do you have internal technical capacity, do you need online payments, how often does content change, and will you need system integration within three years. Do not start from "which platform is best." Start from your actual constraints and work backwards.

Question one: is there one person willing to spend two hours a month on the website?

No, and there never will be, so rule out self-hosted WordPress and custom development unless you simultaneously sign an annual maintenance retainer. Unmaintained self-hosted WordPress is the target of those 11,334 disclosed vulnerabilities. Yes, or you will pay for a retainer, so all four remain open.

Question two: do you need to take money on the site?

Yes, as the primary revenue line, so ecommerce SaaS is the default unless you have an unusual B2B quotation flow. Yes, but occasionally or in small amounts, so WordPress with a commerce plugin or a SaaS builder's store module is enough. No, deals close offline or through sales, so do not choose an ecommerce platform because you might sell online someday — you will pay a percentage forever for a capability you never use.

Question three: how often does the content change?

Once a year, so a SaaS builder wins on saved operations cost. A few posts a month with a long-term SEO and AEO strategy, so self-hosted WordPress or a custom build, because you need control over content structure and structured data. Weekly volume, several languages, multiple collaborators, so custom or headless, because you need a real editorial workflow.

Question four: in three years, will this site need to talk to your other systems?

Yes — ERP integration, live inventory and pricing, connecting to customer procurement systems — so custom or headless, because SaaS APIs rarely support deep integration. Not sure, so choose an option whose content exports cleanly and keep the decision open for your future self.

Two failure modes are worth naming. The first is "start cheap and switch later." That only works if switching is possible, and migrating off a SaaS builder costs roughly what building the site cost in the first place. If you already know you will expand within three years, the first-year saving will not cover the fourth-year rebuild. The second is treating custom development as the premium choice. The real barrier to custom is not money, it is having someone who can write a specification, run acceptance testing and maintain a long relationship with the developer. Without that person, an expensive custom system becomes derelict faster than a cheap SaaS one.

Three practical checks before you sign

Direct answer: beyond the technical fit, three operational realities decide how the next three years go — how deep the local talent pool is for your chosen platform, whether any funding or support programmes apply to your build, and how well you are protected when the vendor relationship ends. None of these are platform features, and all of them will shape your experience more than the feature list.

First, being able to find someone who can fix it matters more than elegance. Development markets are uneven: in most regions far more freelancers and agencies know WordPress and Shopify than know any given niche framework. That means if your original vendor disappears, you have a realistic chance of finding a second one. A technically superior stack that only a handful of people in your city can maintain is a hidden operational risk. Treat "how many people nearby can fix this" as a real evaluation criterion, not a footnote.

Second, check whether any grant, credit or support programme applies before you commit the budget. Many jurisdictions run small-business digitalisation support schemes covering cloud systems, ecommerce, CRM and AI tooling. Terms, amounts and deadlines change year to year, and some schemes impose conditions on the vendor or on which line items qualify — which means applying retroactively usually fails. Spend an hour checking what is available in your market in the current year before you sign anything, and treat any published figure as provisional until you have confirmed it against the current official announcement.

Third, handover risk is more common than technical risk. Companies change web vendors regularly, and every handover risks losing something: domain control still sitting with the previous agency, hosting credentials nobody recorded, a Search Console property owned by a former employee's personal address, source code that exists only on one laptop. None of these are technical problems and none of them depend on your platform choice. The minimum self-protection list has four items: register the domain to the company, use a company address as the owner account on the platform or host, keep owner-level access to Search Console and analytics in company hands, and verify at least once a year that a backup actually restores.

Put those three checks alongside the four tables above and one conclusion emerges: platform selection has never been about which technology is strongest. It is about which one conflicts least with your organisational capacity, cost structure and three-year plan. For related articles on the same theme, browse the website SEO and content topic hub.

Once the platform is settled, the next step is turning your requirements into a document a vendor can build against and you can accept against. That step affects the final result more than the platform choice does, because even the right platform will produce a site nobody wants to use if the specification is vague.