How to configure Nginx for a WordPress root domain while preserving dynamic MERN app routes?

Question

I’d appreciate some advice from experienced DevOps or full-stack engineers.

We have a SaaS product built with the MERN stack, currently running on example.com.

Current setup:

Backend API → api.example.com

Main website → example.com (serves MERN homepage and app)

Now, we want to host a WordPress landing page (for marketing and content) on the same domain, ideally replacing the homepage / while keeping the rest of the MERN routes working.

MERN routes that must stay accessible:

example.com/dashboard – user dashboard

example.com/:shopUsername – shop pages

example.com/:shopUsername/:productURL – individual product pages

example.com/auth – authentication pages

We’re fine with WordPress handling just the root and marketing pages.

The issue

Whenever I install and configure WordPress properly, the MERN app stops working. When I restore the MERN setup, WordPress becomes inaccessible. It seems whichever is deployed last takes over the domain completely.

The question

What’s the best way to configure hosting or a reverse proxy so that:

WordPress handles / (and other marketing pages)

MERN app continues to handle routes like /dashboard, /auth, and shop URLs

Both can coexist on the same domain (example.com) without interfering

Would an Nginx reverse proxy or sub-directory setup be the right approach? Any example configurations or best practices would be really helpful.

• C3roe: Problem is that you are dealing with two applications that both use dynamic routing. Neither /:shopUsername nor /slug-of-one-of-your-wordpress-pages map to any physically existing on the server - both need to get looked up in the dabatase, by one of those two applications. Now, if /foobar gets requested - how is the server supposed to know, whether it needs to pass this to your MERN app, or to Wordpress? It doesn't. Unless you maintain a list of all relevant paths (or path prefixes at least) on the server level itself, so that the request could then be rewritten to the relevant system.
• C3roe: Placing WordPress into a sub-directory, and then internally rewriting the request for / to that directory might work, if you really only needed this for the home page. But then you mention additional "marketing pages", which are also supposed to be served by WP ...?