A blog on a subdomain is a different site, and moving it proves it
Choosing between a subdomain and a subfolder is a five-minute decision. Moving between them afterwards is the part nobody plans for. Here is the whole list.
Moving a blog from a subdomain to a subfolder changes the host in every URL the blog has, which means every post gets a new address and every old address needs a permanent redirect to its replacement. The work is not one change but six: the addresses, the redirects, the sitemap, the internal links, the Search Console property, and the analytics filters that were written against the old hostname. Skipping any one of them leaves the blog reachable but measured wrong.
A subdomain is a different host, and almost everything that touches a website is scoped by host rather than by brand. A URL-prefix property in Search Console covers one scheme and one host, so a blog on a subdomain is verified, reported and diagnosed as its own property; a Domain property is the one that spans a host and its subdomains together. Cookies default to the host that set them. A robots.txt file is fetched per host. None of that is Google having an opinion about your information architecture — it is the plumbing being addressed by hostname.
That is why the subdomain-versus-subfolder argument keeps going. Both sides are describing real behaviour: the subfolder camp is right that a subfolder inherits the host's existing standing automatically, and the subdomain camp is right that the separation is sometimes exactly what you want, for instance when the blog runs on a different platform. The decision is cheap. What is expensive is changing your mind afterwards.
A blog move has two halves that are easy to confuse. The first is where the blog is served from, which is usually one or two settings — in Market4 a blog carries a site address and a base path as separate fields, so moving the host and moving the path under it are separate edits. The second half is everything in the world that already points at the old addresses, and that half is not a setting anywhere.
| What changes | Where the change lives | What breaks if you skip it |
|---|---|---|
| The blog's host and path | Two settings on the blog | Nothing — this is the easy half |
| Permanent redirects, old URL to new | Your web server or hosting rules | Every existing link and bookmark 404s |
| The sitemap | Regenerated from the new addresses, resubmitted | Search engines keep fetching a list of dead URLs |
| Internal links in old posts | The body of each post that links to another | Readers and crawlers take an extra hop on every link |
| Search Console property | A property covering the new host | Your search data starts on a fresh, empty property |
| Analytics filters and reports | Anything filtered by hostname | Traffic to the blog disappears from the reports |
A changelog migration is four decisions, not a copy and paste: where the entries live from now on, what address each one answers at, what happens to the links people already shared, and who writes the next entry.
Market4 turns one release note into a changelog page, a blog post, a mail-out and a week of social posts — and then tells you which of them brought anyone back.
Permanent redirects from a moved blog need to stay indefinitely, not for a tidy transition period. A 301 tells a search engine the resource has moved for good, and engines will follow and eventually consolidate on the new address — but links on other people's sites, in old newsletters and in bookmarks do not update at all. Those requests keep arriving for years, and without the redirect they arrive at a 404. Removing redirects after six months converts a completed migration back into a broken one.
The same logic applies at a smaller scale inside a blog. When a published post is renamed in Market4, the old address keeps working through a permanent redirect and the previous slug is kept on the record rather than discarded. That is the same promise a host move makes, applied one URL at a time: an address that was ever public stays answerable.
The order of a blog move matters because there is a window in which both addresses can be live, and the goal is to make that window short and to make the new addresses the ones being advertised. Publish nothing new during the move; a post that appears at the old host mid-migration will be the one URL nobody remembers to redirect.
One step that is often skipped is the fifth. Redirects make old internal links work, so nothing appears broken and there is no error to notice. What they cost is a redirect hop on every internal click, and a set of internal links that describe an address structure the site no longer uses. Rewriting them is dull work with no visible symptom either way, which is exactly why it gets left.
Not if every old URL redirects permanently to its exact new counterpart. The risk is not the move itself but the shortcuts taken during it: redirecting everything to the blog index instead of to matching pages, leaving some paths unmapped, or removing the redirects later. Expect a settling period while engines recrawl and consolidate, and expect nothing at all to happen on the day you flip the switch.
You need a property that covers the new host. A URL-prefix property is scoped to one scheme and host, so a blog that moves from a subdomain to a path on the main site now belongs to the main site's property. A Domain property covers a host and its subdomains together, which is why sites that expect to move things around often verify one of those from the start. Keep the old property while it still reports impressions.
Indefinitely. Search engines will consolidate on the new addresses within a recrawl cycle or two, but links from other people's sites, old newsletters, chat archives and bookmarks never update. Requests to the old URLs keep arriving for years, and once the redirects are removed those requests become 404s. Treat the redirect rules as permanent infrastructure rather than as part of the migration.
Rewrite them. Redirects will keep the links working, so nothing looks broken, but every internal click then costs an extra request and your own pages keep describing an address structure the site has abandoned. It is unglamorous work with no visible symptom on either side, which is why it is the step most often skipped and the one most worth scheduling explicitly.
Better not to. A post published at the old host part-way through the move is the URL nobody thinks to add to the redirect map, because it did not exist when the map was written. Freeze publishing from the moment you start putting redirects in place until the new addresses are live and the sitemap has been resubmitted, then resume. A few days of no new posts costs less than one orphaned URL.
Publishing writes to a database and tells search engines about an address. Preflighting is the step that asks the server answering that address whether it serves a page. What to check, which findings block an announcement, and why the check must never fail a publish.
Search Console's regex filters are RE2 expressions, which is a deliberately smaller syntax than the one most regex tutorials teach. What RE2 leaves out, what to write in place of each missing construct, and the two things a filter does not change.