For whatever reason, the debate over subdomains vs subdirectories just. won’t. die. However, I’m going to be the guy in the “prove me wrong” meme about this subject until I see some definitive evidence otherwise. I’ve been a part of too many projects where we have seen migrations in both directions and the subdomain -> subdirectory always yields better Organic Search performance.
More often than not, from an SEO perspective, the problem that companies are trying to solve with subdomains is better solved with a reverse proxy.
In this episode of Rank and File, I talk about how a reverse proxy can be a valuable solution to your subdomain problem and why.
Video Transcription:
Intro
Welcome back ladies and gentlemen to another edition of Rank and File. I’m your host, Mike King. I’m the founder and managing director here at iPullRank. So what I want to talk to you about today is why reverse proxies are still better than subdomains. Now the reality is, you know, there are people that consider a subdirectory versus the subdomain as a way to build out a website. And so anytime that I have gone from subdomain to subdirectory, I’ve seen organic search traffic go up. And anytime I’ve done the opposite, I’ve seen traffic go down. So what we’re talking about here is example.com/blog versus blog.example.com. So why do people do this?
Why do people use subdomain?
Well, first of all, it is a perfectly valid way to build a website. Prior to Google coming along in this actually making a difference. Um, you know, a lot of the websites that I worked on back in the day when I built websites, we would structure them that way because we wanted to indicate that, you know, a, a subdomain was a different part of the website. And so let’s say you were on a hosting provider, you got your own subdomain and that represented your section of that site. And it was completely different from everything else that was on that website.
So it’s a perfectly valid structure for how the web was built. But the main reason why people do that is because their main site adds some sort of constraint to it that keeps them from executing on something that they want to do. So they may want to build, you know, a certain functionality, but the way the main site is built, they don’t have the capability or the access to do so. So they move things to a subdomain so that they don’t have those constraints. And oftentimes what you’ll see is that these websites, while at the same design as the root domain, and you can’t really tell the difference unless you’re looking at that a directory structure.
And so there’s also a good reason around Site segmentation. So again, if you want to segment content, content is so different from the root domain or from the WWW, there’s a reason to do that also by location or language. There’s a reason for that just to make it clear that this section of the site is, you know, the Canadian version versus, you know, the French Canadian version versus the, you know, France version of the site. There’s a variety of different languages in locations that you can, you know, account for. And there’s a variety of ways you can do it, but a subdomain is a good way to do it.
And then also additional software. So let’s say, for instance, you’re setting up like Unbounce landing pages or your Marketo landing pages. It makes sense for that to be on a subdomain because perhaps you want that entire subdomain to be no index or you don’t want it to be found for whatever reason. And it’s very easy to just segment that away from what’s going on with the core site.
What’s a reverse proxy?
So what’s a reverse proxy? Well, a reverse proxy is effectively an intermediary server that you send and receive requests from that server to other servers. And so most of the websites that you’re working on may be set up this way. If you think about google.com itself, think about all the different products, whether it’s photos or Gmail or all these other different sections of Google. It’s not all on one server. That would be completely ridiculous. And so the main server then you know, goes out and finds where calendar is and then does that request and brings you back. And in some cases there are actually redirects in place. Like, for instance, if you do type in, you know, google.com/mail or something like that, it does take you to mail.google.com but in the case of calendar it may be different.
Um, nevertheless, the whole point here is that you know, the reverse proxy acts to route you to other sections of the site and then return that content once it finds it. So as an example, imagine you’re the client, your web browser is here and then you’re pinging site.com. That reverse proxy then goes out to different servers for the different things that you want to see on that domain. So for instance, uh, you know, one server may have WordPress on it. So that’s the /blog path and the reverse proxy is then going out to that server, making that request for you, and then bringing that content back and showing it to you at /blog.
Same thing for a Magento server. So for instance, let’s say there’s a /store on site.com. Wow. It’s going to go out to that second server, get all the data in the content and bring it back and show it to you on a /store your URL. Same thing for community. Imagine you have Zendesk and I dunno if this index actually supports reverse proxy, but let’s just assume it does. And so you had that living at /community and then it goes out to that server, brings that content back and then shows it on a /community URL.
Service side configuration
So this really comes down to server configuration. You know, if you’ve got an engine X server, it’s as simple as these three lines of code. You set up a location which is /blog. If you want the trailing slash that’s fine. If you don’t, you don’t have to have it. I recommend having it. And then you do proxy pass to the actual URL that it lives at. On Apache it’s pretty much the same except you don’t put the location, you just put proxy pass and then you put the sub-directory and then where do you want it to go to get that data?
Main thing you need to know is like you got to figure out how to handle those requests. So if you don’t do anything beyond this configuration I showed you, there’s a series of other options as you can add in either server, you gotta make sure that you’re forwarding the IP address and then also the application and server that you’re sending it to knows how to handle that. Otherwise, every connection will be the IP of the proxy server rather than the actual user. So that’s going to be a problem for analytics, going to be a problem for user management. And you know, let’s say you’re thinking of a message board community server, you know how it often has the IP of the user. Every single user would have the same IP address. And these are some of the reasons why, you know, some of the tools out there don’t support reverse proxy.
So for instance, Unbounce no longer does. I know HubSpot doesn’t. Shopify doesn’t. Um, and so because of that, you know, you want to make sure that whatever you’re using or you’re trying to do this with, you actually have that capability or that they support it.
Security concerns
And then the final thing which will likely come up with your clients and also internally is that there can be a series of security concerns with this. So it can be anything from, you know, uh, how requests are managed, can be hacked. You can potentially add, you know, cross-site scripting payloads to a URL which the, you know, server may process. Because the thing is this, the reverse proxy introduces a series of processes to the requests that sent and then it forwards that request on. So based on how it handles that request or, and then also how the backend server handles that request. You can then have issues with security where things get broken or people get access to things that they shouldn’t.
So make sure that you are dialing in the configuration very well, working with your security teams, working with your dev-ops teams. But once you handle all these issues, you know, this is a great opportunity to not have to use those subdomains and see those losses from your organic search traffic.
Conclusion
So really, before you consider going into subdomain direction from a directory, give this a look first. Take a look at, you know, how you can do a reverse proxy on your server. Every type of service supports it. And, um, yeah, I hope that helps. Don’t want to see you lose your traffic. See you tomorrow.
Over to you, how have you effectively solved the subdomain vs subdirectory problem?
Leave a Comment