Years and years ago, it was fairly common to see different sites have their blogs in different formats. Some uses subdomains, blog.example.com, and other subdomains for other subsections of their site. They could have the blog, and shop.example.com for a store, and so on. Other sites used subfolders the same way.
These das, it’s relatively rare to see subdomains used for much of anything. They still exist, largely on older sites that have decided to go all-in rather than make a costly migration, but most new sites are set up to use subfolders instead. You’re a lot more likely to see example.com/blog today, particularly since that’s the default behavior for many blog CMS systems, including WordPress.
Maybe you’re an older blog, or you’re a newer blog that decided to use a subdomain for stylistic reasons, and you’ve decided to change. Regardless of your reason for making the change, you need to make sure you’re minimizing the risks of such a migration.
Moving your blog from a subdomain to a subfolder is just as risky as any other major URL change. Changing from a /blog/year/month/day/ format to a /blog/post-title/ format would have the same risks.
What are those risks? Primarily, it’s in the loss of SEO value from the old URL. See, Google identifies a page by its URL. This is where many URL-based penalties come from. If multiple URLs have the same content, you’ll see duplicate or stolen content warnings. If content at one URL disappears, that page loses all SEO value.
When you migrate from one URL to another, be it a change in domain, a change from subdomain to subfolder, a change in URL structure, or anything else, you risk your old URLs disappearing. If suddenly your entire blog disappeared, you can bet your site would lose a ton of search ranking. After all, the main point of a blog is to rank your site in a bunch of different queries, to get more people coming in when they’re looking for relevant information.
If you don’t take steps to tell Google that it was a migration and not a deletion or duplication, you’re going to be hammered in your search ranking. If you move your blog and don’t remove the old blog, you suddenly have hundreds or thousands of instances of duplicate content, destroying your rank. If you move the blog and remove the old version without proper safeguards, a ton of content disappeared and you lose your ranking until Google figures out what happened.
What I’ve outlined below are the steps you should take to migrate your blog from subdomain to subfolder safely. You still may see some fluctuation in your search ranking, but ideally things will settle down quickly and you won’t lose ranking out of the deal.
There are three possible options for making this blog migration.
Among these three, each has its own issues.
Number 1 has the problem of keeping duplicate content live on your site. If the same blog post is on both the subdomain and the subfolder, Google will see two different locations for the same content and issue a duplication penalty via Panda. Ideally, canonicalization of the new location should solve the problem. Canonicalization is essentially a flag on both locations that tells Google what the one true real location is. If you make the new location the canonical URL, Google will eventually start to replace the old with the new in most queries that don’t specify the old location as a search target.
The issue here is that sometimes canonicalization is not enough. You also end up splitting your traffic. Some people will come in to the new URL, some will arrive at the old, and it’s a lot harder to measure the performance of a post when the metrics are split.
Number 2 is perhaps the ideal. You leave the old location alive and implement a redirect from it to the new location. Google will quickly realize that you made the change, and no user will be able to arrive at the old location unless the redirect fails. However, if the redirect does fail, the old version still exists as a fallback.
The goal here is to use this fallback until traffic in general drops off to the old location, at which point you can remove the fallback. You shouldn’t remove the redirect, however; in case any old links are still alive, you want them pointed at the right destination.
Number 3 is the same as number 2, but jumps ahead for removing the old location’s content. As long as the redirect is in place, virtually everyone should end up on the new location, regardless of their origin. The only issue comes from when a redirect doesn’t work, in which case the user will land on a 404 page. As long as you can handle this effectively, it’s a perfectly viable solution.
Regardless of which method you use, I recommend a few tips:
You want to minimize the time where both versions are live and visible to Google, so you don’t get hit with a duplicate content penalty while you’re in the middle of your migration.
While you’re making this migration, consider making sure you’re using a search-friendly URL structure. Many old blogs use a parameter-based URL structure, something like blog/post=?20170921. Instead, you should use human-readable URLs, something like blog/post/title-of-the-post-with-dashes.
If you already used SEO-friendly URLs with your subdomain, you should strive to maintain them to your subfolder. The less change you do, the better. The only reason I recommend more change over less in the case of parameter-based URLs is because it can benefit your SEO once everything settles down. If you don’t need to make the change, don’t do it. If you’re not sure, read this post to learn about the best practices for structuring URLs.
Once you have both the old and new URLs set and available, you need to implement your redirects. A redirect tells traffic arriving at A to go to B instead, and is done at the server level, before your page even really starts to load.
There are a bunch of different kinds of redirects, but Google recommends using the 301 redirect. A 301 redirect is a permanent redirect and passes your SEO value, link juice, and so on to the new location. A 302 redirect, for example, is a temporary redirect and does not pass on SEO value. Since your migration is permanent, make sure to implement a 301 redirect.
Even if you think you have every possibility covered with your redirects, make sure to implement canonicalization. It’s pretty easy; all you need to do is add a rel=canonical URL flag to every page, pointing at the appropriate version of the page. It’s easy enough to do.
Canonicalization is important for other reasons as well. For example, https://www.example.com and https://example.com are the same page, but with different URLs. If you keep both of them active, you run the risk of Google splitting link juice or issuing duplication penalties. Google is generally smart enough not to do this for www/non-www versions of pages, but it can still come into play. It also happens with example.com/post and example.com/post&utmsource=source, etc, along with other various URL parameters. The point is, Google is sometimes smart enough to ignore these, but sometimes not, and canonicalization is important to sort things out.
Regardless of whether you delete the old content files or maintain them hidden behind redirects/noindex/canonicalization, you at least need to keep the old subdomain active so the redirects can work. If you remove the old version entirely, it just becomes a 404, and the redirect fails.
You can solve this by using server-level redirects instead of page-level redirects, as in this script, though you need to add a line to make sure the redirect is a 301. Replace the [L] with [L,R=301] and that should be fine.
You don’t have to maintain the old version indefinitely, though there’s not really a reason not to. Technically, once you’ve reached a point where the old content hasn’t had a single hit in years, you don’t hurt anything by removing it. It’s up to you if that matters enough to remove, however.
Once you have the old version of your blog properly redirected and the new version is live, visible, canonical, and otherwise functional, you’re mostly good to go. From this point, you’re looking for errors, issues, and assistance.
One such point of assistance is to generate a brand new version of your sitemap that removes the old versions. Google will reject a sitemap that shows the old URLs when the old versions redirect to the new versions. Essentially, consider a sitemap a snapshot of your website the way you want it to be; everything you want is there, everything you don’t is not. Submit that new map to Google via your webmaster tools console.
Next up, you should scan your site with some kind of URL crawler or broken link checker. There are WordPress plugins that will scan this for you, or you can use third party tools like Screaming Frog to do a site/content audit.
What you’re looking for are cases where links in your content point towards old versions of the pages. You can go through and update these to point to the new URLs, instead of making a user pass through an unnecessary redirect from one point of your site to another. It’s very slightly faster and makes more sense to future-proof your site.
If you want, at this point you can use tools like Ahrefs and Majestic to pull your backlink profile, then send emails to the owners of sites that matter – or every site that links to you, if you want – asking them to adjust links to your site.
You don’t have to do this, and in fact many webmasters won’t bother to adjust the old links. In many cases, those links don’t get any traffic anyways, and for the ones that do, you can send more personal, customized emails to those webmasters.
Again, though, this isn’t necessary as long as you have the redirects in place. As long as Google and users can click the link and arrive at the right destination, everything is fine. Google won’t penalize you for some other website not changing their links.
If all of this sounds like a lot of work and a lot of room for error, you can always just not make the migration after all. There’s not really a reason to do it for its own sake. Matt Cutts and John Mueller have both at various times said that it doesn’t matter if your blog is on a subdomain or a subfolder, so long as the surrounding SEO practices are valid.
If you want a more data-driven look, CognitiveSEO compiled a lot of stories and case studies about people making the migration in one direction or another, analyzing if it’s beneficial to do so or not, and determined that any benefit or loss is generally due to other factors, not the migration itself.