Move the subdomain. Keep the rankings.
Migrating blog.yourdomain.com to yourdomain.com/blog is a solved problem with a documented procedure. This is the three-phase plan, built on Google's own site-move guidance, including the parts people skip and later regret.
What Google actually says
This guide leans on two primary sources worth reading yourself: Google's site move with URL changes documentation and the Change of Address tool reference. The short version: permanent redirects transfer signals without PageRank loss, moves take weeks to process, redirects should live for at least a year, and the Change of Address tool cannot target a path, so it plays no role in this particular migration. Everything below is those facts turned into a runbook.
The three-phase plan
Prepare, while everything still works
Inventory every URL the subdomain serves
Crawl the subdomain and export its pages from Search Console (Performance and Indexing reports). The URLs only you remember are the ones that keep rankings; the ones nobody remembers are the ones that 404 after cutover.
Write the one-to-one redirect map
blog.yourdomain.com/post-name maps to yourdomain.com/blog/post-name, page by page. Resist the shortcut of redirecting everything to the new section home: a redirect that ignores the path throws away the earned links pointing at individual pages.
Benchmark before you touch anything
Export current clicks, impressions, and average position for the subdomain from Search Console. Without a baseline, week-two panic and week-two noise look identical.
Stand up the subfolder route and preview it
Serve the same content at yourdomain.com/blog through your proxy before announcing it to anyone. Test forms, pagination, feeds, and a handful of deep URLs while the subdomain is still the live version.
Cut over, all on one day
Go live on the subfolder path
The proxy route becomes the canonical home. From this moment every page on the new path must declare itself: canonical tags, og:url, and internal links all point at yourdomain.com/blog/…, never at the old host.
Deploy the page-level 301s
Every old subdomain URL permanently redirects to its mapped subfolder URL. Google’s site-move documentation recommends server-side permanent redirects (301 or 308) and states plainly that permanent redirects do not cause a loss in PageRank.
Ship the sitemaps, both of them
Submit a new sitemap with the subfolder URLs on the main domain property. Keep the old sitemap available temporarily too: it helps Google recrawl the redirected URLs faster and watch the move happen.
Check robots.txt on both hosts
The main domain’s robots.txt must not block the new section, and the subdomain must stay crawlable so the redirects can be seen. Blocking the old host is the classic way to strand your own signals.
Hold, for longer than feels necessary
Keep the redirects for at least a year
Google’s guidance is explicit: keep site-move redirects for at least 12 months, and ideally indefinitely. The old host also needs valid TLS for as long as the redirects live, because a redirect nobody can connect to does not exist.
Watch both Search Console properties
Indexed pages on the old property should fall toward zero while the new paths rise. Crawl errors in the first weeks are your edge-case detector: query strings, trailing slashes, and forgotten feeds show up here first.
Judge the move on weeks, not days
Per Google, a small to medium site takes a few weeks for most pages to transfer, larger sites longer. Position churn inside that window is the process, not the verdict. Compare against your benchmark at week four, not day four.
The five mistakes that actually cost rankings
Redirecting everything to one page
A blanket redirect to yourdomain.com/blog treats hundreds of earned pages as one. Google treats it accordingly.
Leaving canonicals on the old host
If the new pages still declare blog.yourdomain.com as canonical, you are telling Google the move did not happen.
Expecting the Change of Address tool to do this
Search Console’s Change of Address tool moves domain-level properties and, per Google’s documentation, cannot target a path. For a subdomain-to-subfolder move, the redirects and sitemaps are the mechanism. There is no button.
Letting the old certificate lapse
Redirects served over broken TLS are unreachable redirects. The subdomain needs a valid certificate for the whole life of the redirect rules.
Migrating during your peak season
The transfer window is measured in weeks. Schedule it for the quietest quarter you have, not the month the pipeline depends on.
Where the proxy fits
The migration plan above is platform-neutral: it works whether the subfolder is served by your own nginx, an edge worker, or a managed route. The proxy is simply the piece that makes yourdomain.com/blog exist at all when the blog actually lives on another platform. Utilly's role in this plan is phase one, step four and everything it implies: the route, the preview before cutover, TLS on both hosts, and the rollback path being one routing change.
Subdomain migration FAQs
Will I lose rankings by moving my blog to a subfolder?
Done with one-to-one permanent redirects, correct canonicals, and updated sitemaps, the move transfers your signals: Google states that 301 and other permanent redirects do not cause a loss in PageRank. Expect position churn during the recrawl window of a few weeks, which is normal processing, not lost equity.
How long does a subdomain-to-subfolder migration take to settle?
Google’s site-move documentation says a small to medium site takes a few weeks for most pages to be processed, and large sites take longer. Keep the redirects live for at least a year regardless of how fast the reports settle.
Do I need the Search Console Change of Address tool?
No. That tool moves whole domain-level properties and cannot target a path, so it does not apply to a subdomain-to-subfolder move. Page-level 301 redirects plus updated sitemaps are the entire mechanism.
Can I roll the migration back if something goes wrong?
Yes, and a proxy-based setup makes it cheap: the subfolder route is a routing rule, so rolling back means removing the redirects and pointing traffic at the subdomain again. The safest migrations are the ones planned with the return path in mind.
Should I move everything at once or section by section?
For one subdomain with a coherent purpose, one cutover day with a complete redirect map is cleaner than a long mixed state. If you run several subdomains, migrate them one at a time so Search Console tells you which move caused what.