Unify custom WordPress theme & NodeJS application on 1 domain
Role
Lead developer tasked with developing custom WordPress theme & engineering reverse proxy
Issue
I had previously work with the client to develop the frontend of a Javascript application hosted on AWS. They wanted to add a WordPress install to do content marketing for the domain, but wants it to be hosted on the same domain.
Possible solutions
We could have easily created a subdomain (https://blog.clientsite.com) and have the domain registrar point that to the WordPress install on our WordPress host. However, the client didn’t like the way the URL looked, preferring 1 unified domain (https://clientsite.com) for all applications. More importantly, SEO best practices held that blog should be on the same domain as the main application in order to share any search equity (at least that was the thinking at the time).
Another approach allowed us to host the WordPress install separately, and have it accessible as a subfolder on the primary domain name: https://clientsite.com/blog. This is the approach we decided to go with, as it satisfied the most two main concerns of the client:
– A seamless experience for the visitor that looks like it’s one site,
– Allowed the application to benefit from the search equity earned by the blog
Implementation
To achieve the first goal of a seamless experience, I created a custom WordPress theme (I created a child theme for Understrap – a “starter” theme based off Automattic’s _’s that makes use of Bootstrap) that matched the main application’s design. We manually imported the existing blog entries and installed the entire blog on our new WordPress hosting partner, Kinsta.
In order to have the blog run on subfolder of the primary domain, I implemented a Reverse Proxy at Kinsta to accept traffic being sent to https://clientsite.com/blog. I then worked with the client to create a rule in the routing application (ExpressJS) to forward requests to Kinsta.
Issues with implementation
The implementation got the job done (which is the goal, after all!), but wasn’t perfect. Time and budget constraints didn’t allow us to fully flesh out what would have been a more manageable solution for the future. The biggest missed opportunity was being able to share the header and footer (which to the visitors experience, are identical) between the two applications. Instead, in order to be able to hit our milestones, we compromised and I simply re-created the existing markup being generated by the JavaScript application in my WordPress theme. This, again, satisfied the goal of allowing the visitor to think of the entire site as one unified website and not know when they had switched between the JavaScript application and the WordPress install.
However, I did build the WordPress headers and footer in a way that will allow for easy replacement in the future, where we can share code between the two applications; this will allow for easier site maintenance moving forward.
