{"id":128,"date":"2018-04-27T18:24:27","date_gmt":"2018-04-27T18:24:27","guid":{"rendered":"http:\/\/poparideblog.wpengine.com\/?p=128"},"modified":"2020-07-24T21:31:56","modified_gmt":"2020-07-24T21:31:56","slug":"how-to-host-wpengine-blog-in-subdirectory-using-reverse-proxy","status":"publish","type":"post","link":"https:\/\/poparideblog.wpengine.com\/how-to-host-wpengine-blog-in-subdirectory-using-reverse-proxy\/","title":{"rendered":"How to host your WPEngine blog in a subdirectory using a reverse proxy"},"content":{"rendered":"

Having your cake and eating it too<\/h2>\n

Hosting, scaling and maintaining your own blog is neither fun nor typically a good use of your time. For this reason, many companies – especially time-strapped startups – tend to use hosted services. These typically work by pointing a DNS record at the hosted instance resulting in a blog URL format that I’m sure you’re familiar with; blog.example.com<\/code>.<\/p>\n

Early on in a venture, this approach is an entirely sensible one as you get a blog up and running with very little operational complexity or cost. It does, however, come at some apparent cost<\/a> to the ranking of your blog content on search engines. While this cost is hard to confirm and quantify, after considering others’ experiences and our own data, at Poparide<\/a> we decided that the time had come to optimise our search engine rankings by moving our blog from blog.poparide.com<\/code>,  to www.poparide.com\/blog<\/code>.<\/p>\n

As exciting as the subdirectory vs. subdomain debate is, this article is not about that quandary. This article is about how you can have your cake and eat it too! That is, how you can use a hosted service and have your blog accessed at your root domain and in a subdirectory.<\/p>\n

 <\/h2>\n

Choosing a reverse proxy<\/h2>\n

The standard approach for serving whole websites at an entirely different domain to where it is actually hosted is to use a reverse proxy<\/a>.<\/p>\n

At Poparide, we are using WPEngine<\/a> to host our blog, as our content creators were most comfortable with WordPress. While WPEngine does support the use of reverse proxies<\/a> in combination with their service, they do not support the hosting of content within a subdirectory<\/a> such as example.com\/blog<\/code>. We are neither PHP nor WordPress developers, so the prospect of getting mired in the internals of a WordPress instance was very unappealing to us. For this reason and because we believe it’s a cleaner approach, we opted to consider the hosted WordPress instance a black-box and fake access via a subdirectory in the reverse proxy.<\/p>\n

\"\"<\/p>\n

Faking the \/blog\/<\/code> subdirectory in our reverse proxy keeps complexity in one place; in the reverse proxy configuration. Since no complex WordPress configuration or plugins are required as a result, it makes it easier for us to potentially move away from WordPress if we ever want to. However, it did mean having an additional requirement when it came to choosing a reverse proxy; it needed to be able to dynamically rewrite both the headers and bodies of requests and responses. For example, we neededexample.com\/blog\/some-neat-article<\/code> to be translated to a request to WPEngine at ourblogname.wpengine.com\/some-neat-article<\/code>, and any links in the response to be converted from ourblogname.wpengine.com\/yet-another-article<\/code> to example.com\/blog\/yet-another-article<\/code>.<\/p>\n

There were several candidates considered, but in the end, Nginx<\/a> was a clear winner. It is fast, intuitively configurable and proven. HAProxy<\/a> was a close runner-up but was ultimately disqualified due to not supporting the rewriting of body content. Not only did Nginx come with excellent header and body rewriting capabilities, after experimenting with both, we felt that it was a lot friendlier to configure than HAProxy.<\/p>\n

 <\/h2>\n

Configuring the reverse proxy<\/h2>\n

Nginx proved to be a breeze to configure and we quickly had a working configuration up and running that handled:<\/p>\n