Migrating access for subdirectory-based wordpress sites to Netlify

I have a Wordpress multi install on a 3rd party server that I then point my various domains and some small client’s domains to. The set up there is using a subdirectory setup, so: mywpserver.com/client1 etc…

Their custom domains then point at my server and WP handles the redirection to point their domains at their respective subdirectory.

I plan to migrate these all over to jamstack with netlify and would love to have this setup used as my “data source” for all of these sites with their primary domains pointed at netlify instead of the 3rd party server.

But, would I be able to have redirects that point to these subdirectories so that they could access their wp dashboards at their clientdomain[dot]com/admin/ (like they do now) and also pull their data from it?

I read another post on here that explained this pretty well, however it was based on subdomains not subdirectories. See here: Netlify Custom Domain and WordPress

I don’t think it’s possible to point subdomains at subdirectories, is it?

So, in the end, to accomplish all of this I will have to change my Wordpress multi install to use subdomains instead, correct? (this worries me as this sounds like a nightmare) or am I totally overthinking this?

Thanks for any ideas and input. I am trying to pull the trigger on jamstack and go all in, but want to make sure I have a flexible setup similar to the one I have now.


As you’ve guessed, Netlify is based on a one-site+sourcebase-per-hostname model, however, it is quite possible to stitch things together from multiple sites under a single namespace. Maybe more effort than you want, but possible:

DNS has no way to “point a directory” anywhere, but you can point, either via proxy redirects (more complicated, more seamless for your visitor) as described there, or via straight 301 HTTP redirects (“this content has moved to https://othersite/otherpath”) that the browser will follow automatically (more details here: https://www.netlify.com/docs/redirects/#basic-redirects). I’d actually suggest the 301 redirects since those aren’t “visitor facing” (they are your-client facing, but you can say “hey you will still go here, but you will see a different URL in your browser when the page finishes loading, same interface as always though!”)

So, I don’t think you’ll have to change anything on the wordpress side to accomplish this - just let your clients know that their browser will take them to the same editing interface (at your wordpress service) based on the same path they always used which you’ll create a redirect for (each case of).

Let me know if it doesn’t sound like it would help or if I missed the point of your question - we had some internal debate as to whether I am answering your actual question or not :slight_smile:

Hi @twilightscapes! It is indeed possible to redirect subdomains (or full domains) to subdirectories. In fact, that’s exactly what’s happening in the examples I posted in the comment you linked in this topic. For your multisite setup, you’d probably still want to have each frontend site as a separate site on Netlify, and the redirect would just add one more directory level to the target path.

For example, for a site at client1.com, you can set a redirect rule like this:

/doorbell    https://mywpserver.com/client1/wp-admin   200

Then, when someone visits client1.com/doorbell, they see their admin UI at mywpserver.com/client1/wp-admin. The 200 code at the end of the rule sets the redirect as a rewrite, which means browser URL bar still shows the client1.com address, even though the browser is accessing mywpserver.com/client1.

That covers admin access on the WP server, but you also mentioned using the server as the data source for the frontend sites, presumably using the WP API. There are two ways to do this.

In many cases, it’s preferable to access the WP data at site build time, so the data can be baked in to pre-built html pages. In that case, you would set up your site generator or build tool to access the API endpoints at whatever URL they need — no redirects needed. In a multisite setup, that would involve GET requests to a URL like https://mywpserver.com/client1/wp-json/some-endpoint.

On the other hand, if you’re accessing data (like comments, say, or related posts) directly from the client with JavaScript, you could again access the API endpoints directly, but you’d have to deal with CORS, and you’d expose your server address in client-side calls. To avoid both of these problems, you can add a proxy rewrite rule.

Using the client1.com site example again, you could have a rule like:

/api/*    https://mywpserver.com/client1/wp-json/:splat  200

With that, you can code your JS GET requests to point to relative links like /api/this-endpoint and they’ll reliably and invisibly go to https://mywpserver.com/client1/wp-json/this-endpoint.

Hope that helps!