Choose example.com/blog when your main website team can reliably serve and maintain the blog there. Choose blog.example.com when a separately managed blog is the workable way to publish. Neither address should be your default merely because someone expects a Google ranking bonus. Before choosing, name the team that will publish an article, the system that will serve its public URL, and the person who will fix that route when it breaks. The example addresses in this article are fictional.
Choose by publishing ownership, not a ranking theory
Google describes ranking as using multiple systems and signals, including page-level signals. Its site-diversity system generally treats subdomains as part of the root domain, although it can sometimes treat them separately for that system. That is not a promise that either example.com/blog or blog.example.com will rank better. Make the location decision around a publishing workflow your team can keep running.
The distinction is about control, not simply how the URL looks. A subfolder puts the public route under the main site's address, but its content could still come from another system. A subdomain gives a separate blog deployment a clear address, but someone must still maintain navigation, product links and a consistent reader experience across the two sites.
Compare the work each location creates
Use the same questions for both options. In particular, ask for the actual route owner—not just the person who writes posts. If another service supplies pages under /blog, the main-site team needs to own the routing arrangement. Next.js documents rewrites that proxy a path to an external destination while keeping the original site's visible URL; that is one possible arrangement for a Next.js-controlled site, not something a separate CMS or app deployment provides automatically.
| Question | Main-site subfolder | Blog subdomain |
|---|---|---|
| Who serves the public article URL? | The main site or a route it explicitly manages. | A separately addressed blog deployment. |
| Who can ship a post? | The publisher needs access to the main site's blog workflow. | The publisher can use the separate blog workflow. |
| What breaks when systems change? | Route or proxy changes can affect blog URLs on the main site. | Changes to the blog deployment can affect its URLs; cross-site navigation still needs care. |
| What needs ongoing coordination? | Main-site releases and blog publishing, especially if they use different systems. | Blog maintenance plus links and presentation across the two sites. |
A worked choice for a mixed-stack SaaS team
Consider this fictional team: its marketing site at example.com runs on a CMS, its product app at app.example.com runs on Next.js, and marketing owns the articles. The CMS team cannot offer a dependable /blog route or maintain a proxy to another deployment. Marketing can, however, publish supplied Markdown into a separate CMS blog served at blog.example.com, and has an owner for that deployment. The resulting choice is the subdomain: marketing can publish and fix its articles without depending on an unowned route on the main site. The app's Next.js stack does not change who controls the marketing site's /blog path.
Ranks supports automatic blog setup and publishing for Next.js App Router websites using TypeScript; for other website technologies, it provides Markdown and a copyable prompt for manual publishing. In this example, the CMS blog uses the manual path. Connecting the app repository would not by itself establish publishing to the CMS site's /blog route. If the marketing CMS team instead could serve /blog natively and owned its release process, the subfolder would be the simpler choice for this same team. Check the target repository and public route before selecting an automatic workflow.
Check the chosen URL and publisher before launch
Make one representative article your acceptance test. Before release, write down its intended address—for example, blog.example.com/onboarding-guide for the fictional subdomain choice—and the system and person responsible for publishing it. Decide where the main site's blog navigation will point, prepare an inbound link to the article, and check that its product-page destinations exist. If those destinations and links cannot ship together, publish the destination before linking to it.
After publishing, open the public article URL rather than relying on a draft or deployment preview. Check its text, links, navigation and intended canonical URL, then inspect the sitemap produced by the chosen blog system. Google advises using fully qualified URLs in sitemaps and including the canonical URLs you want shown in search results. Ranks likewise advises checking the live blog route after setup changes deploy and the live article URL after publication; a generated draft alone does not prove the page is live.
For the publishing details, use the Next.js App Router blog publishing checklist if the chosen site uses that supported stack, or the manual Markdown publishing guide for the CMS route. If you change already-published article addresses later, use the separate SaaS blog migration guide; choosing a new blog location does not require a migration plan for URLs that do not yet exist.
