How Do You Move a Blog From a Subdomain to a Subfolder?

How do you move a blog from a subdomain to a subfolder?

You map every old URL to its new one, arrange for the subfolder to be served, put permanent redirects from the old subdomain to the new paths, update internal links and canonical tags, submit a new sitemap, and file a Change of Address in Search Console. Then you wait, because the waiting is part of the process.

This is one of those jobs that is conceptually simple and full of small ways to lose traffic. Almost all of the damage happens in two places: an incomplete URL map, and redirects that were only tested on the homepage. Neither is hard to avoid, but both are easy to skip when you are in a hurry.

I am going to walk through it in the order I actually do it, and I am going to lean on Google's own site move documentation rather than folklore, because this is an area where advice from five years ago is still circulating and some of it is wrong.

Why is a subfolder usually the better home for a blog?

Because it keeps your content on the same host as the rest of your site, under one property and one set of signals. A subdomain is treated as its own site for a lot of purposes. That is fine when the content is genuinely separate, and unhelpful when your blog exists to support your product pages.

There is a practical argument too, separate from any ranking theory. On a subfolder, every link your blog earns points at the same host as your pricing page. Your internal linking works in one direction rather than across a boundary. Your analytics, your Search Console property and your reporting stop needing a footnote that explains why the blog is missing.

I want to be careful here. Anyone who tells you a subfolder is worth a specific percentage lift is selling something, and I have no verified number to offer you. What I can say is that the operational simplicity is real and immediate, and that is usually reason enough. If your blog and your product are the same business, they should live on the same host.

The counter-case is worth stating. If the blog runs on a system you cannot serve from the main domain without meaningful engineering, and the traffic is modest, the move may cost more than it returns. That is a legitimate reason to leave it alone.

What do you need to check before you touch anything?

Export a complete list of live URLs on the subdomain, not just your posts. Category pages, tag pages, author pages, paginated archives, feeds, images and any landing pages living there. Then pull the ones that actually have traffic or links, because that subset decides how careful you need to be about the rest.

Get this list from more than one place. A crawl of the subdomain gives you what is linked. Your sitemap gives you what you intended to publish. Search Console gives you what Google has actually seen, including URLs you forgot existed. Analytics gives you what people visit. The union of those four is your real inventory, and it is always bigger than the first list you make.

While you are there, note anything that will not move cleanly. Feed URLs that other services subscribe to. Images embedded in posts that point at the subdomain. Anything hardcoded in an email template. These are the items that break silently a month later, long after everyone has declared the migration finished.

How do you build the URL map?

One row per old URL, one column for the new URL, and no blanks. Most rows are a mechanical swap of the host for the path. The rows that matter are the exceptions: pages that are being merged, retired or renamed at the same time. Resolve those before the move rather than during it.

My strong advice is to change one thing at a time. If you are moving the blog, move the blog. Do not also restructure your categories, shorten your slugs and drop the date from your URLs in the same release. When something goes wrong afterwards, you want one variable to investigate, not four. The tidy-up can follow in a month.

Keep the map as a file, not as a set of redirect rules typed straight into a settings panel. You will need to check it, hand it to somebody, and test against it afterwards. I went through how I lay this out in the article on building a redirect map before a migration, and the same format works here.

What does Google actually require during the move?

Google's site move documentation is specific. It recommends server side permanent redirects from the old URLs to the new URLs, meaning 301 and 308 responses. Each new URL should have a self-referencing canonical link tag. Internal links on the new site should be changed from the old URLs to the new ones. A new sitemap goes into Search Console.

Two details in that documentation get missed more than the rest. The first is the instruction to keep the redirects for as long as possible, generally at least one year. People remove them after a quarter because the traffic looks settled, and that is exactly when the last long tail of links and bookmarks is still arriving on the old paths.

The second is the Change of Address step. Google documents that you submit a Change of Address in Search Console for the old site when moving from one domain or subdomain to another, and that you skip it for changes like HTTP to HTTPS or adding www on the same domain. A blog moving off a subdomain is precisely the case where it applies, which surprises people who assume it is only for full domain changes. I wrote up that process separately in the piece on Change of Address after a domain move.

On timing, Google's documentation sets the expectation plainly: a small to medium-sized website can take a few weeks for most pages to move, and larger sites take longer. Tell your stakeholders that number before the move, not after the first nervous week.

How does the subfolder get served in the first place?

Either the blog moves onto the same system that serves your main site, or a proxy sits in front of your domain and forwards requests for the blog path to wherever the blog is hosted. The first is simpler and usually better. The second exists because the first is not always possible.

If your blog and your main site can live on the same platform, do that. Fewer moving parts, one deployment, one cache, one place to debug. This is the version I recommend to almost everyone who asks, and the migration then really is just content plus redirects.

The proxy route is what you use when the blog runs on a platform you want to keep. The pattern is the same everywhere: requests to your domain for the blog path get forwarded to the blog's origin, and the response comes back under your domain. The configuration details differ by host, and they change, so read your platform's current documentation rather than a tutorial. Webflow, for example, publishes a help article called Set up a self-managed reverse proxy in Webflow, and that is the page to read before you start rather than any summary of it including mine.

Whichever route you take, test the behaviour before you move any traffic. Request a post, a category page, a paginated page and a file, and confirm each one returns what you expect under the new path. Proxies tend to work perfectly for the first URL you try and then surprise you on the fifth.

Should you move everything at once or in sections?

Google's documentation addresses this directly. Small or medium sites should move simultaneously, while large sites may move one section at a time because it is easier to monitor. For most blogs, that means move the whole thing in one go and watch it carefully, rather than dragging the move across a quarter.

The reason a phased move appeals is emotional rather than technical. It feels safer. In practice it doubles the period during which two versions of your blog exist, which means twice as long for internal links to be wrong, twice as long for canonical confusion, and twice as many chances to forget which half is live.

If your archive genuinely is large enough to phase, split by section rather than randomly, keep each phase short, and finish. A half-finished migration that has been sitting for six months is the worst outcome available, and it is more common than anyone admits.

What do you do in Search Console after the switch?

Submit the new sitemap containing the new URLs, file the Change of Address for the old subdomain property, and keep both properties open. You need the old one to watch the redirects being followed, and the new one to watch the new URLs being indexed. Do not delete the old property when the move looks done.

Then use URL Inspection on a sample rather than on everything. Pick your ten most valuable posts, your busiest category page and a page that you know is awkward, and inspect each one. If those are being fetched and indexed at the new address, the rest is usually following behind.

Watch the coverage of the new property over the following weeks rather than the following days. The number that should be climbing is indexed pages on the new path. If it stalls while the old path is still fully indexed, something in the redirect layer is not doing what you think it is.

How do you know the move worked?

Test every row of the map, not a sample. Request each old URL and confirm it returns a 301 to the exact new URL, in one hop, with no chain and no redirect to the homepage. Then check that the new URL returns a 200 with the right content and a canonical pointing to itself.

The one-hop part matters more than people expect. Old redirect rules on the subdomain often still exist, so a request lands on an old rule, gets sent somewhere, and then hits your new rule. Each extra hop is a chance for something to be dropped. I went through how to find and flatten those in the piece on redirect chains, and it is worth doing before the move rather than after.

The other failure I watch for is the lazy redirect, where everything on the old subdomain is pointed at the new blog index instead of at its matching post. It looks tidy in a settings panel and it throws away the value of every individual page. If your map has a hundred rows, you need a hundred destinations. Before you build the map, settle whether your Webflow site should use www or the root domain, so every destination uses the final hostname.

What should you do next?

Build the inventory this week, from all four sources, before you make any decisions about the move itself. That list will tell you whether this is an afternoon of work or a fortnight, and it is the only part of the job that nobody can do for you. Everything after it is mechanical.

Then read Google's site move documentation end to end once. It is short, it is current, and it settles most of the arguments people have about redirects and timelines using the words of the company whose index you are trying to keep.

If you have a blog sitting on a subdomain and you are not sure whether moving it is worth the disruption, reach out. It is usually a quick judgement call once I can see the size of the archive and how the two sites are hosted, and sometimes the honest answer is to leave it where it is.