When headless WordPress fits and when a traditional site is the better choice
Keep WordPress rendering pages unless a separate front end solves a problem you already have. A traditional site uses the theme to build pages on the server, so block patterns, theme templates, shortcodes and plugin output all arrive in one place and the editor's preview matches what visitors see. Headless WordPress keeps the same database and admin screens but sends content out through the REST API as JSON, and your team then owns a second application that renders it. That split pays off when a dedicated front-end team already works in React, Vue or a similar framework, when the same content must feed a website, a mobile app and a kiosk, or when the site needs interactive features that a theme cannot deliver cleanly.
A marketing site that depends on theme features, page builders, WooCommerce templates, membership plugins or form and SEO plugins that output HTML is usually the better case for a traditional build. Every one of those plugins would need its output rebuilt or re-exposed in the front end. Before you commit, list each plugin that writes to the page and ask whether its data is available through the REST API or a plugin-specific endpoint, and whether the editor's preview will still show drafts. Private and password-protected content also needs authentication on every request, so confirm how your front end will handle logins and draft previews.
Plan for the extra work on both sides. A headless model adds a build pipeline, a hosting target for the front end, cache invalidation when content changes, and a deployment process for two codebases, all of which recur after launch. Traditional WordPress keeps updates to one application, although the WordPress advanced administration handbook notes that plugin and theme updates still need an owner. Ask your team to estimate who will maintain the front end after the agency or internal build ends, and to name the person who approves plugin changes that affect the API.
Which model fits which team and site
A marketing site built mainly from pages, landing pages, case study listings and a blog usually fits a traditional, theme-rendered WordPress installation. The editors work in the same screen that publishes the page, the theme handles layout, and preview works without extra plumbing. A headless setup adds a second application to build, host and patch, and that cost rarely returns value when the only consumer of the content is the company's own website.
- Preview and layout: Editors see changes in context through the standard block editor and theme, without a separate preview pipeline.
- Fewer moving parts: One application, one hosting stack and one update routine cover the whole site.
- Plugin-based SEO and forms: Common marketing needs are often met by established plugins, which a classic theme can use directly.
- What changes the answer: A requirement to reuse the same pages in a mobile app, a kiosk or a partner portal would make the content API more valuable.
- What to confirm: Whether the marketing team needs custom page types or campaign landing pages that the theme cannot produce without a separate front end.
Before committing, list every channel that will read this content in the next few years, not only the current website.
A site whose features depend on plugins for memberships, commerce, bookings, search or form workflows usually fits traditional WordPress. Those plugins register their own output, shortcodes, templates and admin screens, and many of them assume the classic theme runs the page. Moving to a headless front end means every plugin feature must be rebuilt, re-exposed through the REST API or replaced, and that work is often larger than the content migration itself.
- Plugin output: Many plugins render markup and assets inside the theme, which a separate front end will not receive unless someone rebuilds it.
- Authentication and private content: The REST API applies the site's own access rules, so member-only or password-protected content needs authenticated requests in the new front end.
- Update coupling: Plugins and themes are updated on their own schedules, and a headless front end adds a second release train that must stay compatible with the API.
- What changes the answer: A plugin whose data is exposed cleanly through its own API, or a commerce or booking system that the team plans to run separately, lowers the rebuild cost.
- What to confirm: For each critical plugin, whether it exposes its data through the REST API and whether its vendor supports a headless setup.
A publisher that feeds a website, native apps, digital screens and newsletters from one editorial workflow usually fits a headless model. The WordPress REST API sends and receives JSON, which lets each channel request the content it needs in a format its own application can render. Editors still work in WordPress, while each front end is built and released independently. The trade-off is that the team must own the front ends, their builds and their monitoring.
- One source, several outputs: Articles, images and metadata are stored once and read by each channel through the same API.
- Independent release cycles: A change to the app does not require a change to the website, and the reverse is also true.
- Shared content rules: Access control for private or embargoed content follows the site's own authentication rules, so every consumer must authenticate correctly.
- What changes the answer: If the only channel is one website and the team has no plan for apps or screens, the extra build work does not pay back.
- What to confirm: How preview works for each channel, since the block editor preview is tied to the WordPress site and must be reproduced in each front end.
A team that already builds and operates React or another JavaScript front end, with a deployment pipeline and frontend engineers on staff, can take on a headless WordPress model without learning a new stack. The team can keep editorial work in WordPress while controlling rendering, routing and performance in the framework it already runs. Without that practice, the same model adds a language and build chain the team must learn and maintain alongside the CMS.
- Skills already in place: Frontend engineers can own the rendering layer, caching and component library without new hires for the front end.
- Build and hosting work: The front end needs its own build, hosting, caching and rollback process, separate from the PHP server that runs WordPress.
- Preview and draft handling: Previewing unpublished content requires authenticated requests and a preview route in the front end.
- What changes the answer: Limited frontend capacity, or a site that relies on classic theme features, makes traditional WordPress the more practical choice.
- What to confirm: Who will own on-call duty for the front end, and whether the team can maintain both the PHP host and the JavaScript build over the life of the site.
What the WordPress REST API gives you in a headless build
The REST API is the piece that makes a headless build possible at all. It is the foundation of the WordPress Block Editor, and the WordPress REST API handbook describes it as the way to bring WordPress content into completely separate applications or to build a new interactive front end. Requests and responses use JSON, so a front end written in any language can read posts, pages and other content without loading a WordPress theme. The decision you face is whether your front end needs the full content model, or only a few content types that your editors actually maintain. Before you commit, list the content types, fields and custom data your front end will consume, then confirm with your WordPress developer which of them are exposed through the API in your installation and which need custom registration. Those details are specific to your plugins and theme, so the handbook is the place to verify them rather than assuming the defaults cover your content.
Authentication is the control most teams underestimate. The REST API applies the same access restrictions as the site itself, so private, password-protected and internal content is returned only to authenticated requests. A public front end that queries the API without credentials will see only what an anonymous visitor could see on the classic site. Draft previews, members-only articles and internal notes need a deliberate design: which requests carry credentials, where those credentials are stored, and whether the front end server or the browser makes the call. Put that design in writing and test it with an unauthenticated client and a logged-in editor role before launch, because a misconfigured read permission can expose content that the classic theme would never have rendered to a visitor.
Because the API reflects site permissions, your access model moves into the headless stack as well. Roles that controlled what editors could see in wp-admin now also control what the front end can fetch, so a change to a role or a content visibility setting can change the public site without a code deploy. Ask your team to document which roles can read which content types, who can create application credentials, and how those credentials are rotated. Confirm with your security and compliance leads whether the API endpoints fall inside the same logging and review process as the admin interface, since a headless build creates a new path into the same data that your existing monitoring may not yet cover.
What you give up in themes, plugins and preview
A headless front end moves rendering out of WordPress, so features that a classic theme provided for free must be rebuilt, mapped or replaced. The cards below cover the losses that show up most often, and each one names what to confirm with the plugin author, theme developer or front-end team before committing.
Theme-rendered features
A classic theme supplies templates, menus, widgets, sidebars and custom page layouts. In a headless setup none of that output reaches the browser, so each template feature must be rebuilt in the front end and fed from the REST API. Inventory what your current theme renders, then check which of those items exist as data fields the API returns. Anything that exists only as theme PHP needs a new home before cutover.
Plugins that assume PHP output
Many plugins hook into the_content, shortcodes or template functions and return HTML that only the WordPress theme renders. Those plugins may add nothing to a JSON response, or add fields you never asked for. Ask each plugin author whether it exposes data through the REST API, whether its output is available as structured fields, and whether its licence and support terms cover use in a decoupled setup.
Preview workflows to rebuild
Editors who rely on the classic preview button see the theme as it will publish. A headless site needs a preview route in the front end that fetches draft content with authentication, which the REST API applies with the same restrictions as the site. Confirm with your front-end team how draft and unpublished content is requested, how preview tokens expire, and whether the editor workflow has been tested with real drafts before go-live.
Shortcodes and block output
Shortcodes and some block markup are rendered by PHP during page output, so the API may return the raw shortcode text instead of the finished result. Content written for the classic theme can therefore appear broken on the front end. Audit a sample of posts for shortcodes and custom block markup, then confirm with the plugin author and the front-end developer how each one is parsed, transformed or replaced.
SEO and redirect handling
Yoast, Rank Math and similar plugins write meta tags, sitemaps and redirects inside the PHP request. When the public site moves to a separate front end, the front end must emit titles, canonical URLs, structured data and redirects itself, or the plugin must be configured to serve them. Confirm which metadata fields the SEO plugin exposes through the API, who owns redirect rules after cutover, and how existing URLs will map to the new routes.
Search and forms
Site search and contact or lead forms usually depend on theme templates, plugin shortcodes or server-side handlers that run inside WordPress. A front end must call a search endpoint or form handler and deal with spam protection, validation and submission storage itself. Confirm with each form and search plugin vendor whether submissions can be posted through the API, where form data is stored, and how consent and retention settings carry over.
How the two models compare on hosting, updates and effort
This table compares a classic theme-rendered WordPress site with a headless WordPress setup across licensing, PHP and database needs, updates, preview and hosting skills. Read each row as the work you take on in each model, then confirm the items marked for your own check before you commit.
| Factor | Traditional WordPress | Headless WordPress with separate front end |
|---|---|---|
| License | GPLv2 or later from the Free Software Foundation | WordPress stays GPLv2 or later; the front end framework and its libraries carry their own licenses, which you must confirm |
| PHP and database | PHP 8.3 or greater; MariaDB 10.11 or greater or MySQL 8.0 or greater (WordPress.org requirements) | Same WordPress server requirements, plus a Node.js or other runtime for the front end, which you must confirm |
| Core updates | Automatic background updates; newly created sites have major release updates enabled by default since 5.6 | Same WordPress core update path for the API server, but a front end deploy and rebuild is a separate release to plan |
| Plugin and theme updates | Plugin and theme updates are applied automatically only in special cases chosen by the WordPress.org API for critical fixes | Same plugin rules on the API server; plugins that alter output must be retested against the front end, not only the site |
| Front end stack | Theme rendering runs inside WordPress with PHP templates | Adds a JavaScript build, a hosting target for the front end, caching and a deploy pipeline that your team owns |
| Preview | Core preview renders through the theme and active plugins | Preview needs a custom route in the front end that reads drafts through authenticated REST requests; confirm this with your framework |
| Plugin compatibility | Most plugins assume PHP template output and display hooks | Plugins that render markup or shortcodes may not show output through the API; check each one before migrating |
| Access to private content | Site login controls visibility | REST API applies the same authentication restrictions, so the front end must handle tokens or server-side fetches for private content |
| Skills needed | PHP, WordPress administration and theme work | WordPress administration plus JavaScript build tooling, API design, CI and front end hosting |
| Hosting cost | One WordPress host, often a single server or managed plan | Separate costs for the WordPress host and front end hosting; ask vendors and your framework provider for current pricing |
Components and topology of each model
A classic WordPress site is one deployable: PHP, the database and the theme render every page. A headless setup keeps WordPress as the content back end and moves rendering to a second application, which adds components, a build step and more places where an upgrade can break something.
WordPress core and PHP runtime
In a classic site, WordPress core runs on PHP and serves every page request, with the active theme deciding what visitors see. WordPress.org recommends PHP 8.3 or greater for hosting. Check that your plugins and theme support the PHP version you plan to run, because the PHP runtime is the first thing a host or patch cycle will change. In a headless setup this same runtime still exists, but it only serves the admin, the REST API and media, so it is no longer the public face of the site.
MariaDB or MySQL data store
WordPress stores posts, users, options and plugin data in MariaDB or MySQL, and both models depend on it. Headless does not remove the database, it makes it the system other applications read from through the API. Confirm the database version your host supports, and plan backups and restore tests for the content store, since content editors will see any loss there first. Plugins that write custom tables add to what must be backed up and upgraded together.
WordPress REST API as content back end
The REST API sends and receives JSON and applies the same authentication rules as the site, so drafts, private posts and password-protected content return only to authenticated requests. This is the seam between WordPress and the front end. Decide which endpoints and custom fields the front end needs, and test that their permissions hold for anonymous visitors. Any plugin that alters the API output becomes a contract your front end must track across WordPress upgrades.
Separate front-end application and build layer
A headless front end is a second deployable, usually a JavaScript framework app that fetches content at build time, at request time or both. The build pipeline must pull content from WordPress, compile pages and deploy them. Every WordPress minor or major upgrade can change API responses, so the build must be tested against the new version before the back end is updated. Ask who owns this pipeline after launch, since no classic theme upgrade ever required it.
CDN and caching layer
A classic site often relies on page caching inside WordPress or the host. A headless site usually places a CDN in front of the static or server-rendered front end, and cache invalidation must fire when an editor publishes or updates content in WordPress. Without a publish hook, editors see stale pages and support teams spend time explaining why. Check how your CDN purges cache, which origin it reads from, and how a WordPress outage affects pages that are already cached.
Authenticated preview endpoints
In a classic site, preview is the theme rendering a draft inside the same WordPress session. In a headless site, preview needs a route that the front end can call with credentials, returns draft content only to authorized editors and shows the page as it will look on the public site. Treat this as its own security surface: review who can request previews, how tokens expire and whether preview URLs can leak drafts to people outside the editorial team.
How upgrades and security patches reach each site
A traditional WordPress site and a headless WordPress back end both receive core updates through the same mechanism, but a headless build adds a second patch cycle that nothing in WordPress covers. Automatic background updates were introduced in WordPress 3.7, and since WordPress 5.6 newly created sites have automatic major release updates enabled by default. Check whether that default still holds on your installation, because existing sites may have been configured differently. Plugin and theme automatic updates are a narrower path: by default they apply only in special cases determined by the WordPress.org API, which the Security Team controls to patch critical vulnerabilities. Everything else in your plugin set still needs a deliberate update process.
The WordPress Security Team backports fixes to older versions as a courtesy, but only the latest version is officially supported. Plan for that gap. The WordPress.org releases page states that only the most recent release in the current series is actively maintained, so a headless back end that falls behind is running on courtesy fixes rather than supported ones. Confirm which WordPress version your back end runs and how quickly your team can apply each new release, including minor releases in a branch you are not yet tracking.
In a headless build, the front end has its own patch cycle, and automatic updates on the WordPress back end do not update it. The JavaScript framework, its build tooling, the Node.js runtime and every front end package are separate dependencies. A WordPress core update can also change REST API responses that the front end depends on, so the back end and front end need a joint test before each release reaches production. Assign an owner for the front end's dependency updates, decide how often they are reviewed, and confirm that a rebuild and redeploy pipeline exists for emergency patches. Without that, a patched back end can leave a vulnerable front end online.
Upgrades, backups, monitoring and skills for each model
This table compares the recurring operating work for a traditional theme-rendered WordPress site and a headless WordPress setup with a separate front end. Read each row as a task you will own after launch, and check the cell for your model before you choose.
| Operating task | Traditional WordPress | Headless WordPress with separate front end |
|---|---|---|
| Core upgrades | WordPress 7.1 series is the current line, and 7.1.3 was released on October 6, 2026. Only the most recent release in the 7.1 series is actively maintained, so the site moves with each core release. | The same WordPress core upgrade applies to the content API host, and it must be tested against the REST API responses your front end depends on. Confirm the response shapes your front end reads before each upgrade. |
| Plugin and theme upgrades | Plugins and themes can change markup and output, so each update may affect pages visitors see. By default, plugin and theme auto-updates apply only in special cases chosen by the WordPress.org API. | Plugins that add fields or change REST output can break the front end without any visible change in WordPress admin. Test API output and schema after each plugin update, not only the admin screens. |
| Front-end dependency upgrades | Little separate framework work, because the theme and WordPress share one codebase and one deployment. | A separate JavaScript framework, build tools and packages need their own upgrade cycle. Confirm the release cadence and support window of any framework you choose before committing to it. |
| Backups of database and uploads | Back up the WordPress database and the uploads directory together, plus the theme and plugin code. One restore point covers the rendered site. | Back up the WordPress database and uploads for the content API, and keep front-end source and build configuration in version control. Restoring content alone will not rebuild the front end. |
| Monitoring availability | Monitor the public pages, which show what visitors experience. A failing plugin or PHP error usually shows up on the page itself. | Monitor the API and the front end separately. The API can answer while the front end serves stale or broken pages, and the front end can stay up while the API is down. |
| Preview environment upkeep | Preview is handled by WordPress on the same site, so editors see changes in the theme they already use. | Preview needs a separate route that renders draft content through the front end. Keep that environment patched and in sync with production, or editors will review content on a different build. |
| Team skills | Staff need WordPress administration, PHP and theme or plugin support, and hosting administration. | Staff need WordPress administration plus REST API design, JavaScript framework work, build and deployment pipelines, and hosting for a Node.js or static front end. |
How to decide and move from one model to the other
This sequence turns the choice between a classic theme-rendered WordPress site and a headless setup into a documented decision with a known scope. It ends with a cut-over plan that keeps URLs, search visibility and editorial workflow intact.
Inventory plugins and theme-dependent features
List every active plugin, every custom theme template and every feature the theme renders, such as menus, widgets, shortcodes, forms, search, comments and WooCommerce pages. Mark which ones produce output on the front end and which only support editing or administration. The site owner and the lead developer should do this together, because theme code often hides logic that editors rely on. The step is done when each item has an owner and a stated fate: keep in WordPress, rebuild in the front end, or retire.
Decide which content the API must serve
Map each content type, taxonomy, custom field and menu to the channels that will consume it, such as a web app, a mobile app or a partner feed. Drop anything no channel needs, since every exposed field adds maintenance. Note where the WordPress REST API already returns the data and where a custom endpoint or a field-exposure plugin would be required. The output is a content model document that a front-end developer can build against without asking the editorial team follow-up questions.
Define authenticated and public content
Classify each content type as public, password-protected, private or internal. The WordPress REST API applies the same authentication rules as the site, so private and password-protected content is only returned to authenticated requests. Decide how the front end will authenticate, which roles may read drafts, and whether any content should never leave the internal network. Confirm the chosen authentication method with your security team and test that an anonymous request cannot retrieve restricted items. The step closes with a written access matrix.
Prototype the editorial preview workflow
Editors need to see drafts, scheduled posts and revisions as they will appear on the new front end before publishing. Build a small prototype with one content type and one editor, then test whether draft retrieval, preview links and revision handling work with the chosen authentication. Ask editors to complete a realistic publishing task and record where they hesitate. Treat preview as a gate: if it cannot be made reliable, the headless design needs rework before any content migrates.
Plan redirects, metadata and search visibility
List every indexed URL, its canonical form, its title and meta description, and the structured data it currently emits. Decide which URLs stay identical, which move, and which redirect, and where the front end will generate metadata that the theme used to output. Check that the new front end can produce the sitemap and canonical tags search engines rely on. The output is a redirect map and a metadata checklist that the team signs off before any cut-over date is set.
Run a parallel staging environment
Deploy the front end and the WordPress API to a staging environment that mirrors production hosting. Compare rendered pages, API responses and redirect behavior against the live site, using a copy of current content. Check the update path as well, since WordPress core, plugins and the front-end build now release on separate schedules. Confirm that the team can run both sides' updates and rollbacks. The step is done when differences are logged and each one is either fixed or accepted.
Cut over and monitor the transition
Schedule the switch during a period agreed with the editorial and operations teams, freeze content edits briefly, and point traffic to the new front end. Keep the classic site available for a rollback window and watch error rates, redirect hits, search console reports and editor feedback. Record what changed and who approved the change. The step closes when the rollback plan has been tested, the monitoring period has ended without open critical issues and the old theme code has a documented retirement date.
Questions buyers ask before choosing headless WordPress
What does headless WordPress cost to run compared with a classic site?
Headless WordPress costs more to run because you operate two systems: the WordPress back end and a separate front end with its own build, hosting and deployment pipeline. A classic site is one PHP application on one host. The recurring costs that grow are hosting for the front end (often a Node.js build or static hosting with a rebuild on each publish), monitoring for both tiers, and developer time for each WordPress or front-end release. The WordPress license is GPLv2 or later, so the software itself carries no license fee, but plugin licenses, hosting and staff time still apply. When you request a quote, ask for separate line items for the WordPress tier, the front end, CI/CD, monitoring, backups and the upgrade cycle, and ask which items recur monthly or annually. Confirm the PHP and database versions you will run, since WordPress.org recommends PHP 8.3 or greater and MariaDB 10.11 or greater or MySQL 8.0 or greater.
How long does a headless WordPress build take?
Duration depends on how much of the classic theme you rebuild, how many custom post types and fields you expose through the API, and how many plugins must be replaced or verified. A site with a small content model and few integrations is a much smaller job than a multi-language store with custom editorial workflows. Ask for a written scope with milestones before any timeline is agreed, because DeployOpen works on fixed-scope engagements where scope, deliverables and timelines are set in writing before work starts. Ask the implementer to list the templates, endpoints, plugins and integrations in scope, and to show how preview and staging will be handled. Any duration you are given should be tied to that list, not to a generic promise.
Can an internal team run headless WordPress without outside help?
Yes, if the team already runs WordPress and has someone who can build and deploy a JavaScript front end. The skills change: your team needs REST API knowledge, front-end build tooling, deployment pipelines and cache invalidation on top of normal WordPress administration. Plan for the security work too, because a public API and a separate front end add surface to patch and monitor. WordPress core updates are maintained by the WordPress Security Team, and only the latest version is officially supported, so your team must apply updates promptly. Before deciding, check whether you have on-call coverage for both tiers and whether you can keep the front end patched. DeployOpen plans, implements, hardens, backs up, upgrades, documents and supports self-hosted platforms, and ongoing support is available as a retainer if your team wants help after handover.
Which WordPress plugins usually break in a headless setup, and how do you check them?
Plugins that render HTML on the server, inject markup into theme templates, or depend on the front-end request cycle usually stop working or need replacing. Common examples include page builders, shortcode-based features, some SEO and schema plugins, and form plugins that output markup. Plugins that only extend the back end or register custom post types and fields often keep working, provided they expose data to the REST API. To check each plugin, list every active plugin, note what it outputs on the front end, confirm whether its data appears in REST responses, and test each one on a staging build. Ask the implementer for that inventory as a deliverable. Note that plugin and theme updates are applied automatically only in special cases chosen through the WordPress.org API, so you must schedule your own review of every plugin update.
How does preview work when WordPress is headless?
In a classic site, the editor previews the theme output directly. In a headless setup, the editor's preview request goes to the front end, which must fetch draft content from the REST API using authentication and then render it. You need a preview route in the front end, a way to pass the draft's identifier and a token, and a rule that prevents draft pages from being cached publicly. Ask the implementer to demonstrate preview for a draft post, a draft page with a custom field and a scheduled post before sign-off. Confirm whether your editors need preview for blocks and custom layouts, since those are the cases most often left unfinished.
Can the WordPress REST API serve private or password-protected content?
Yes, but only with authentication. The REST API applies the same authentication restrictions as the site, so private, password-protected and internal content is available only to requests that present valid credentials. A public front end should therefore fetch only published content, and any draft or members-only content needs a separate authenticated path with its own token handling and caching rules. Review the authentication method you choose, how tokens are stored in the front-end host, and which endpoints expose custom fields. Ask for a test showing that unauthenticated requests cannot read a private post, and that a revoked credential stops working.
When should a business keep the classic WordPress site?
Keep the classic site when your content is mostly pages and posts, your theme and plugins meet your needs, and your team does not need a separate front end for app, kiosk or multi-channel delivery. A classic site is one application to patch, one host to back up and one deployment path, which usually keeps running costs and staffing lower. Headless makes more sense when several channels consume the same content, when you need a JavaScript-driven front end, or when front-end performance requirements justify the added build work. Before deciding, price both options against the same written scope, and ask the implementer which plugins and features would be lost. WordPress 7.1 was released on August 19, 2026, and only the most recent release in the 7.1 series is actively maintained, so plan your upgrade path either way.
How DeployOpen scopes, delivers and supports WordPress deployments
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For a headless WordPress or traditional WordPress decision, we start by writing down which architecture your content, editors and front end actually need before any build work begins.
How we scope
- Written scope states which WordPress features, REST API endpoints and front-end pages are covered.
- Scope records which plugins, themes or custom code are in or out of the engagement.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- Installation, hosting and build pipeline are set up inside your cloud account, data center or air-gapped network.
- Preview, authentication and access rules for private content are configured and tested against the REST API.
- Security testing of the API and front end runs alongside build work, with findings tracked to closure.
How we hand over
- Documentation covers the hosting stack, build steps, update procedure and rollback path for your team.
- Backup and restore procedures are documented and tested before handover is accepted.
- Your team receives configuration records, runbooks and the list of items to confirm with vendors.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover WordPress core, PHP and database upgrades, plugin reviews and front-end dependency updates.
- Ask any provider, including us, for the written support scope, response expectations and upgrade responsibilities.
