WordPress vs Ghost

WordPress suits multi-purpose sites and stores that need plugins and a PHP hosting base. Ghost suits publishers who want memberships, paid subscriptions and newsletters built in, on a Node.js and MySQL stack.

On this page

WordPress or Ghost: when to choose each for publishing

Choose Ghost when the site is a focused publishing operation and memberships, paid subscriptions and newsletters are the core of the business. Choose WordPress when the site also carries company pages, a store, landing pages or other non-publishing features that need their own plugins. Ghost's own comparison page says WordPress remains the better fit for complex multi-purpose websites or ecommerce, and that is a reasonable starting point for your own review. Four drivers should settle the decision: how many non-publishing features you need, how dependent the membership and email stack would be on third-party plugins, how much hosting work your team can carry, and what it would cost to move content later.

The strongest case for Ghost is fewer moving parts for membership and email. Ghost lists memberships, paid subscriptions and newsletters as built in, so there is no plugin set to keep compatible across upgrades. That advantage only holds if your team can run a Node.js and MySQL stack with NGINX, or if you pay for Ghost(Pro). The strongest case for WordPress is breadth: a large plugin ecosystem, GPL licensing and automatic background updates for core. That advantage weakens if your membership logic depends on several plugins that each need their own updates, testing and support contracts. Ask any WordPress vendor for the full list of plugins the membership and payment flow requires, and check each plugin's update history before you commit.

Plan the exit before you launch. Ghost's WordPress importer moves posts from WordPress's XML export, with a limit of 2,500 posts and 100 MB files, and it converts categories into tags. Custom post types and content-restriction plugins do not migrate, so member access rules and any bespoke content types must be rebuilt by hand. Run a test import against a copy of your archive and list what did not arrive. If that list is long, the cost of switching is a real factor in choosing WordPress now, and a published migration route from Ghost to another platform should be confirmed with Ghost before you rely on it.

Which platform fits which publishing scenario

This table maps common publishing setups to the platform that fits them better, with the reason for each choice. Ghost's own comparison page says WordPress remains the better fit for complex multi-purpose sites or ecommerce, and it presents memberships and newsletters as built in; treat both as vendor claims and test them against your requirements. Use the scenarios as a starting point for your own review.

ScenarioBetter fitReason
Newsletter-only writerGhostNewsletters and paid subscriptions are built in. Ghost takes no transaction fee on paid subscriptions, but Stripe processing fees still apply.
Membership magazineGhost, if needs stay within built-in featuresGhost lists memberships as built in (vendor claim). Confirm your tiers, content gating and reporting needs before choosing.
Corporate blog with a shopWordPressGhost's comparison page says WordPress remains the better fit for ecommerce. Confirm the commerce plugin and its upkeep before deciding.
Multi-author news siteWordPress, unless seat counts fitGhost(Pro) lists 1, 3 and 15 staff users on Starter, Publisher and Business plans, per its pricing page. Count your editors first.
Site with heavy custom post typesWordPressGhost's migration docs say custom post types do not migrate, so an existing content model would need rebuilding or staying on WordPress.
Existing WordPress archive moving to GhostCheck before migratingGhost imports up to 2,500 posts from an XML file up to 100 MB, turns categories into tags, and leaves restriction plugins behind.

How WordPress and Ghost are built and what each means for operations

WordPress and Ghost reach the same reader through very different runtimes, and that difference shapes who patches what, how the server is built, and which hosting skills you need. The cards below cover the application stack, the database, the web tier, the install path, and the features that sit outside the default install.

WordPress runs on PHP

WordPress is a PHP application, and WordPress.org recommends PHP 8.3 or greater with MariaDB 10.11 or greater or MySQL 8.0 or greater. Most shared and managed PHP hosts already run this stack, so the server skills you need are mostly familiar ones. Confirm that your host supports the recommended PHP version, because the version you run sets which plugins and themes stay compatible over time. Check the PHP version your host offers before you choose a plan.

Ghost runs on Node.js

Ghost is a Node.js application that needs a supported Node.js version, which is why it is operated more like a custom service than a PHP site. The Ubuntu install guide uses Node 22 in its example, and Ghost's install path expects you to manage the Node runtime alongside the rest of the stack. Ask whether your hosting provider can keep a supported Node.js version running and how it handles Node upgrades.

Database and web tier

Ghost requires MySQL 8.0 or 8.4 and places NGINX in front of the application, with systemd keeping the process running. WordPress accepts MariaDB or MySQL and is usually served through Apache or NGINX on a PHP-FPM setup. Both need a database backup routine, but the Ghost stack adds a reverse proxy and a process supervisor that someone on your team must maintain. The configuration you run is the part that generates ongoing work.

Ghost-CLI install and its limits

Ghost is installed through Ghost-CLI on a server that meets the Ubuntu requirements, with at least 1 GB of RAM. The Ghost-CLI install does not support Ghost's web analytics, and the ActivityPub service is also outside that path. Ghost documents a separate Docker Compose install for self-hosting web analytics or the ActivityPub service, so plan that build before you promise either feature to editors. Confirm which of these you need before you choose the install method.

Automatic updates differ by platform

WordPress has shipped automatic background updates since version 3.7, and newly created sites have automatic major release updates enabled by default since WordPress 5.6. Plugin and theme updates follow different rules, so your team still owns the plugin inventory. Ghost ships frequent minor releases, and a Ghost-CLI host means your team must schedule and test those upgrades on its own server. Ask who applies updates on each platform and how a failed update is rolled back.

Operating the Ghost server

A self-hosted Ghost site means someone owns the Node.js runtime, the MySQL instance, the NGINX configuration, the systemd unit and the TLS certificate. Those components are an operations burden that a managed WordPress host often absorbs. Before you commit, ask whether your team has the on-call coverage to restart a failed service and restore from backup. This is the decision that most often separates the two platforms in practice.

What WordPress and Ghost license and charge for

WordPress is released under the GNU General Public License version 2 or later, so the core software is free to use, modify and redistribute. Running the core on your own servers carries no license fee. The GPL terms matter most when you distribute modified code, so ask counsel how the terms apply to your business model. Many plugins and themes are GPL-licensed too, but each extension carries its own license, vendor and renewal terms, so check them before you put anything into production.

  • Core software: no license fee for the core under GPLv2 or later, as set out in the WordPress license page.
  • Plugins and themes: each extension has its own license, and paid ones often renew annually or per site.
  • Hosting: PHP and database hosting is a separate recurring cost, and WordPress.org recommends PHP 8.3 or greater with MariaDB 10.11 or greater or MySQL 8.0 or greater.
  • Support: the free core includes no vendor support contract, so support comes from your host, plugin vendors or an implementation partner.
  • Membership and payment tools: these are almost always separate products with their own pricing, so they belong in the cost model from the start.

Check the license and renewal terms of every plugin you need for members, payments and email, and confirm who holds the support obligation for each one.

Memberships, payments, email and extensibility compared

This table compares what each platform includes out of the box and what you add yourself. Ghost's built-in claims come from Ghost's own comparison page, so treat them as vendor claims and test them against your workflow. For WordPress, the answer depends on which plugins you choose, so confirm each one against your own requirements before you commit.

CapabilityWordPress (self-hosted)Ghost (self-hosted or Ghost(Pro))
MembershipsNeeds a membership or content-restriction plugin chosen and maintained by youBuilt in, according to Ghost's own comparison page (vendor claim)
Paid subscriptionsNeeds a payments plugin or integration, with processor fees set by youBuilt in, with no Ghost transaction fee per Ghost's comparison page; Stripe processing fees still apply
Newsletters and emailNeeds an email plugin or external serviceBuilt in, according to Ghost's comparison page (vendor claim)
Content APIREST API included in core; you design the endpoints you useRead-only Content API returning JSON, with keys created through a Custom Integration in Ghost Admin
Custom post types and fieldsSupported in core, with custom fields handled by plugins you selectNot offered in the same way; custom post types do not migrate from WordPress
EcommerceTypically added through a commerce plugin; confirm fit for your catalogGhost's comparison page says WordPress remains the better fit for ecommerce
Plugin ecosystemLarge, third-party, quality varies; vet each plugin's maintenance and licenseSmaller set of built-in features; fewer third-party extensions to evaluate
Update handlingCore minor and security fixes can auto-update; plugin updates depend on WordPress.org security rulesFrequent minor releases such as 6.71.0 (October 15, 2026), applied through your own upgrade process
Hosting stackPHP 8.3 or greater with MariaDB 10.11 or greater or MySQL 8.0 or greater, per WordPress.orgNode.js with MySQL 8.0 or 8.4 and NGINX 1.9.5 or later, per Ghost's Ubuntu guide

How updates and security patches reach each site

WordPress has shipped automatic background updates since version 3.7, and since 5.6 newly created sites have automatic major release updates enabled by default. Plugin and theme auto-updates are different: by default they apply only in special cases determined through the WordPress.org API, which the WordPress Security Team controls to patch critical vulnerabilities. That means your plugins are still your responsibility. Before choosing WordPress for a membership or newsletter build, list every plugin you need for members, payments and email, check each one's update history and support status, and confirm which update settings your host and site configuration actually enable.

Only the latest WordPress release is officially supported, although the WordPress Security Team backports critical fixes to older versions as a courtesy. The current 7.1 series includes 7.1 (August 19, 2026) and 7.1.3 (October 6, 2026), and the WordPress.org releases archive states that only the most recent release in the 7.1 series is actively maintained. Plan to stay on that line. Confirm your PHP and database versions against the WordPress.org requirements page so that major updates do not stall on hosting constraints.

Ghost follows a different model. Its version 6.0.0 was published on August 4, 2025, and it ships frequent minor releases, with 6.71.0 published on October 15, 2026. If you run Ghost(Pro), the vendor handles hosting upgrades. If you self-host, your team owns every upgrade and patch, including the Node.js runtime, the MySQL version and the NGINX configuration, and each Ghost-CLI update must be tested against your own theme and integrations. Ask whether your hosting partner or internal team will track each minor release, how fast critical fixes will be applied, and who signs off on a rollback. Those answers determine the real operating cost of the self-hosted option.

What drives the running cost of each platform

Running cost splits into recurring items such as hosting, plans, plugins and staff time, and one-time items such as migration and setup. WordPress and Ghost put these costs in different places, so the same budget line can mean different things. Ask each vendor or partner to price the same components in writing.

Hosting and server footprint

WordPress runs on PHP with MariaDB 10.11 or greater or MySQL 8.0 or greater, which many shared and managed hosts already provide. Ghost needs Node.js, MySQL 8.0 or 8.4, NGINX and at least 1 GB of RAM on a self-hosted server, and it installs through Ghost-CLI. Ask each host to price the same traffic, storage and backup tier, and confirm whether the Node.js runtime and process manager are included or billed separately.

Premium plugins for members and payments

On WordPress, memberships, paid subscriptions and newsletters usually come from paid or free plugins and their add-ons, each with its own renewal and support terms. Ghost lists these features as built in and takes no transaction fee on paid subscriptions, though Stripe processing fees still apply. Recurring plugin licenses and add-on bundles are the line item most often missed when comparing the two.

Ghost(Pro) plan tiers

Ghost(Pro) is billed yearly, with Starter at $18 per month for 1 staff user and 1,000 members, Publisher at $29 per month for 3 staff users, and Business at $199 per month for 15 staff users, plus custom plans. Growth in staff users or members moves a site up a tier, so model the member count you expect in 12 months. Confirm what happens to pricing when you exceed a tier's limits.

Staff skills and operations time

Self-hosted Ghost adds Node.js version management, systemd services, NGINX configuration and database care, which usually needs someone comfortable with Linux operations. Self-hosted WordPress needs PHP version management, plugin review and backup testing. Estimate the hours each stack costs per month for patching, monitoring and incidents, and price those hours at your own internal rate or a partner's written rate.

Support and security response

WordPress has a Security Team that fixes responsibly disclosed vulnerabilities in bugfix releases, but only the latest version is officially supported. Ghost's support comes through Ghost(Pro) plans or your own operations capability when self-hosted. Ask whether a support contract, retainer or response commitment is included in the quote, and whether it covers out-of-hours incidents.

Upgrade and migration effort

WordPress minor and security releases can apply automatically, and newly created sites have automatic major updates enabled by default, which lowers recurring effort but still needs plugin compatibility checks. Ghost ships frequent minor releases, so routine upgrades recur. Moving an existing WordPress site to Ghost is a one-time cost: custom post types and content-restriction plugins do not migrate, and rebuilding them is usually the largest line in the budget.

Moving a WordPress publication to Ghost in order

This sequence moves a publication's content, members and paid tiers from WordPress to Ghost without losing subscribers or breaking links. Each step ends with a check that tells the team whether it can move to the next one.

  1. Inventory plugins, custom post types and shortcodes

    The editorial lead and the site administrator list every active plugin, custom post type, custom field group and shortcode in use on the live site. For each item, they record whether it supplies membership, paid subscription, newsletter, gated content or a feature Ghost would need to replace. Ghost's migration documentation says custom post types, most uncommon shortcodes and content-restriction plugins do not migrate, so this list defines the rebuild work. The step is done when every item is marked as carried over, rebuilt in Ghost, or retired, and the owner has signed off the list.

  2. Export the WordPress XML file

    The site administrator exports the content from WordPress's own export tool, choosing all content, and keeps a dated copy of the file outside the web server. Ghost imports WordPress content from this XML export, so the file is the input for every later test. The step is done when the export file opens without error, the post count matches the WordPress dashboard, and the copy is stored with the rest of the backup set.

  3. Test the import against Ghost's limits

    The technical lead runs a trial import into a non-production Ghost instance. Ghost's documented limits are 2,500 posts and XML files up to 100 MB, so a publication above either limit needs a split export or the open-source TryGhost/migrate toolkit, or a migration through Ghost(Pro)'s migrations team. The team compares post counts, images, internal links and categories against the source. WordPress categories become Ghost tags, so editors review how that mapping reads on the site. The step is done when the trial import matches the source on counts and the team has chosen one of the documented routes for the full migration.

  4. Rebuild memberships, paid tiers and gated content

    The product owner and the developer recreate membership tiers, paid subscription prices and access rules in Ghost, since content-restriction plugins do not migrate. Ghost lists memberships and paid subscriptions as built in, but Stripe processing fees still apply to payments, so the finance lead confirms the Stripe account and tax settings before any live charge. Existing paying members are the highest-cost data to move, because their subscriptions and payment records do not carry over automatically. The step is done when a test member can sign up, pay, and see only the content their tier allows.

  5. Map and redirect URLs

    The SEO lead builds a table of every published URL on the WordPress site and maps it to the matching Ghost URL, including category archives, tag pages, feeds and any custom post type routes that now need a new home. The developer configures redirects at the web server or DNS layer so old links reach the new addresses. Search rankings and inbound newsletter links depend on this map. The step is done when a crawl of the old site returns a single redirect hop or a direct 200 for every URL in the table.

  6. Verify email and payment flows

    The developer and the newsletter owner check the full path a subscriber takes: sign-up confirmation, welcome emails, newsletter delivery, paid conversion, renewal notices and cancellation. They use test accounts and confirm that emails arrive, links resolve and the correct access is granted after each payment event. Ghost takes no transaction fee on paid subscriptions, but the team should confirm the email sending setup and Stripe webhooks in their own environment. The step is done when each flow passes in test mode and the team has a written list of any gaps.

  7. Cut over and keep WordPress available for rollback

    The team sets a cutover window agreed in advance, freezes publishing on WordPress, runs a final export and import, updates DNS, and confirms the live site, redirects and member logins. WordPress stays in read-only mode with its database backup retained so the team can roll back if a critical defect appears. The step is done when the live site serves the full content, a sample of paying members can access their content, and the owner signs off the switch.

Where WordPress and Ghost projects usually run long

The longest part of a WordPress membership or paid newsletter project is usually not installation. It is choosing and configuring the plugins that gate content, connect payments and send email, then hardening that stack so the plugins, their roles and their webhooks stay correct over time. Each of those components is a separate decision: the membership plugin, the payment connector, the email service and the caching layer all need settings reviewed together, and a change to one often breaks an assumption in another. On the Ghost side, memberships, paid subscriptions and newsletters are built in, so the work shifts to server setup. A self-hosted Ghost install is typically Ghost-CLI on Ubuntu with Node.js, MySQL, NGINX as a reverse proxy, TLS certificates, systemd service management and backups of both the database and the content directory. Confirm which Ubuntu release, Node.js version and MySQL version your platform team supports before the first install, since Ghost's install guide lists specific versions.

Projects run long in four places. The first is restricted content. Ghost's migration documentation says content-restriction plugins do not migrate, so any WordPress paywall rules, membership tiers or gated posts must be rebuilt in Ghost and tested against real member accounts. The second is custom theme or template work, since a publisher's brand, subscription pages and signup flows often need changes beyond the default. The third is Stripe and email deliverability setup. Stripe processing fees apply on paid subscriptions, webhook endpoints and sending domain records such as SPF, DKIM and DMARC need configuration and testing, and a deliverability problem usually shows up only after launch. The fourth is legacy volume. Ghost's importer handles up to 2,500 posts from XML files up to 100 MB, so a larger archive needs the open-source TryGhost/migrate toolkit or Ghost's migrations team. Ask for a content inventory early, covering post count, file sizes, custom post types and shortcodes.

Questions buyers ask before choosing or hiring help

Can Ghost replace WordPress memberships and paid subscriptions?

For a publisher whose model is memberships, paid subscriptions and newsletters, Ghost covers the core case without extra plugins, according to Ghost's own comparison page, which lists those features as built in. The same page says Ghost takes no transaction fee on paid subscriptions, but Stripe processing fees still apply, so model those costs in your own numbers. Check the gaps before you commit. If your WordPress setup depends on custom access rules, gated content tied to a particular plugin, or a payment flow Ghost does not offer, map each rule to Ghost's model and confirm it in a test environment. Ghost(Pro) Starter is listed at $18 per month for 1 staff user and 1,000 members, billed yearly, which is useful for sizing a hosted option.

What does a WordPress to Ghost migration leave behind?

A WordPress to Ghost migration moves posts and content from WordPress's XML export, and WordPress categories become Ghost tags. Ghost's migration documentation says three things do not move: custom post types, most uncommon shortcodes and content-restriction plugins. Those are the items most likely to affect a membership site, because gated content and custom content types often depend on them. Plan for a separate rebuild of anything in those groups, plus the design and theme work, because a content export does not carry the look of the site. Confirm with your team which plugin settings, member records, redirects and integrations you need to keep, and assign an owner for each before cutover.

Does self-hosted Ghost need more operations skill than WordPress?

It needs a different skill set, and the balance depends on your team. WordPress requires PHP 8.3 or greater and MariaDB 10.11 or greater or MySQL 8.0 or greater, and WordPress.org provides automatic background updates for minor releases, with major updates enabled by default on sites created since WordPress 5.6. Ghost's Ubuntu guide asks for a supported Node.js version, MySQL 8.0 or 8.4, NGINX 1.9.5 or later, systemd, at least 1 GB of RAM and installation through Ghost-CLI. Ghost-CLI installs do not include web analytics, which needs the separate Docker Compose install. Your team will own Node.js runtime upgrades, process supervision and the reverse proxy more directly than on a typical WordPress host.

What does a Ghost migration need from the client's team?

The client's team has to make the content and membership decisions that no migration tool can make. You need an owner who knows the paid tiers, pricing and member records, a person who can grant admin access to WordPress and the target Ghost instance, and someone who controls DNS, TLS and the public domain at cutover. Your editors need to review migrated posts, tags and internal links, since categories become tags and shortcodes may not render. Finance or operations should confirm payment processor setup and Stripe fee handling. Ask any firm you hire to list these inputs in writing, along with who approves each decision and who signs off the final acceptance test.

Can our team run the WordPress to Ghost migration itself?

A small team can handle a simple migration if the site fits the import path. Ghost documents uploading WordPress's XML export in Ghost Admin under Settings, Advanced, Import/Export, with limits of 2,500 posts and XML files up to 100 MB. A site with few custom post types, no content-restriction plugin and a manageable post count is a reasonable candidate for an in-house import and review. Larger sites or sites with custom content should use the open-source TryGhost/migrate toolkit or Ghost(Pro)'s migrations team, as Ghost's documentation suggests. Check your capacity honestly: the import is the quick step, while content review, membership rebuild and redirect checks take most of the effort.

How long does a WordPress to Ghost migration take, and what drives it?

No supplied source gives a standard duration, so treat any timeline as something to agree in writing rather than a published figure. The main drivers are the number of posts and the size of the export against Ghost's 2,500-post and 100 MB limits, the count of custom post types and uncommon shortcodes that need manual rebuilding, and how much membership and payment logic must be recreated. Redirect mapping, template work, content review and staging tests add effort. Ask for a fixed scope that lists each content type, each integration and each acceptance test. DeployOpen agrees scope, deliverables and timelines in writing before work starts, and quotes follow from that written scope.

Can a online store run on Ghost instead of WordPress?

Ghost is designed for publishing, memberships, subscriptions and newsletters, and its own comparison page says WordPress remains the better fit for complex multi-purpose websites or ecommerce. If your business needs a product catalog, cart, inventory, shipping rules or tax handling alongside content, keep the store on a platform built for commerce, and consider whether the publishing side belongs on WordPress or Ghost. A content-first brand with a small product line may still fit, but confirm each store function in a proof of concept before you move anything. DeployOpen plans, implements and hardens self-hosted platforms, so a written scope can cover the store, the publishing side or both.

How DeployOpen helps choose, implement or migrate

DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For WordPress vs Ghost, that means starting from your content model, membership and payment needs, and hosting constraints before any platform is chosen or any migration begins.

How we scope

  • Inventory which posts, pages, members, newsletters and custom post types the site actually uses today.
  • Document which plugins handle memberships, payments and email, and which features Ghost builds in.
  • Agree the written scope, deliverables and timelines in writing before any work starts, as most engagements are fixed-scope.

How we build

  • Stand up the chosen platform in your environment, including a Node.js and MySQL stack for Ghost or PHP hosting for WordPress.
  • Test the WordPress XML export against Ghost's documented limits and map categories, tags and content restrictions.
  • Harden the server, configure backups and apply updates on a tested schedule before the site goes live.

How we hand over

  • Document the architecture, hosting stack, update steps and rollback procedure for your operations team.
  • Record which content, custom post types and restriction rules did not migrate and how each gap was resolved.
  • Walk your team through administration, member management and email configuration before handover is signed off.

How we support

  • Offer ongoing support, upgrades and continuous testing as a retainer after the initial handover.
  • Schedule upgrades against each platform's release cadence and confirm compatibility with your payment and email services.
  • Review the setup periodically to check that hosting requirements and plugin or integration dependencies remain supported.

Sources and further reading

Talk to our team.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.

  • 30-minute call: free, with no obligation.
  • NDA on request: we can sign before you share details.
  • Clear next steps: a scope and plan after the call.