Quick summary: one account, many blogs, one dashboard
If you have ever managed two blogs on WordPress, you know what the alternative looks like: two installs, two logins, two analytics dashboards, two newsletter tools, two of every plugin. The model below is the one Vlogerly uses, and it is the simplest answer to a question that the rest of the industry treats as exotic: how do you publish across several blogs from a single workspace without losing your mind.
This article covers what changes when you move from one blog to many, the four workflows that get genuinely easier, the three decisions to make before you add the second project, and a 60-second walkthrough of adding a new blog inside the dashboard.
Why most platforms force you into one blog per account
The standard CMS model assumes one blog per account because that is how the software was originally written. WordPress, Ghost, Substack and most others scope content, users, themes and settings to a single site. Running a second blog means a second account, a second billing line, a second deploy, a second of everything.
That works fine if you only ever have one blog. It breaks the moment you decide to test a second niche, run a client project, or split your audience by language. The friction is not the writing; it is the operational overhead of remembering two sets of credentials, two settings panels, and two places to check the morning's traffic.
The 6 things that change when you go multi-blog in one dashboard
1. The project switcher lives in the dashboard header
The single most consequential UX detail in a multi-blog dashboard is where the project switcher lives. In Vlogerly it sits in the header bar at the top of every dashboard view, showing the name of the active project plus a small chevron. Clicking it drops a list of all your projects plus a "Create a project" option. Switch and the whole dashboard reloads against the new project context.
You stay logged into one account the whole time. There is no separate login per blog.
2. The active project is in the URL
Every dashboard route includes the project as a query parameter (?project=<id>). That is how the dashboard knows which blog you are looking at. Practical implication: you can bookmark a specific blog's article list or analytics view and it lands exactly there, regardless of which project was active last time.
3. Categories and tags are scoped per project
A "Travel" category in your travel blog has nothing to do with a "Travel" tag in your B2B SaaS blog. Each project has its own categories list and its own tag list, and there is no cross-pollination. This is what keeps two unrelated blogs from contaminating each other's taxonomy.
4. Newsletter subscribers are project-scoped too
The list for blog A and the list for blog B are completely separate. A subscriber to your gardening blog does not get your fintech newsletter unless they explicitly subscribe to both. Confirmation, unsubscribe and milestone notifications all route based on which project the subscriber signed up to.
5. Analytics roll up per project, not per account
The KPI cards, charts and time-on-page numbers in the dashboard are filtered to the active project. To compare blogs head-to-head you switch from one to the other; you do not aggregate them by default. That matches how you actually evaluate a blog (in absolute terms, not as a slice of an account aggregate).
6. Custom domains attach per project
Each project can map to a different domain (or subdomain). One project might live at your-niche.com, another at your-client.com/blog, a third at your-name.com/notes. The dashboard does not care which; it serves the right project to the right domain.
Tip: the project list is unbounded. There is no hard limit on the number of projects per account (subject to fair use). Spin them up as cheaply as you would a Notion page.
The 4 workflows that get genuinely easier
1. Running niche A/B tests in parallel
Picking a blog niche is one of the slowest, riskiest decisions a beginner blogger makes (we covered the 3-circle framework in our niche selection guide). Multi-project flips the bet from "commit six months to one niche" to "publish 10 posts in two or three sub-niches and double down on the one that moves first." Same writer, same effort, three times the signal.
2. Spinning up a client blog without billing chaos
If you ghost-write or manage blogs for a small client, the friction of provisioning a new platform per engagement is real. With multi-project, you create the client's blog inside your account, map their domain, hand them limited access for review, and never touch a second billing platform. When the engagement ends, you delete the project; everything else stays clean.
3. Running an EN + ES split as separate projects
If you want a clean SEO architecture for English and Spanish audiences (rather than relying on translations within a single article), you can run them as two projects with different domains or subdomains. Each has its own SEO posture, its own newsletter, its own analytics. The article-level i18n stays available too, so you can mix strategies.
4. Sandboxing a new content angle before merging
You have a main blog and an idea for a new content angle that may or may not fit. A sandbox project lets you publish three or four posts in the new angle, see if the audience reacts, and then either fold it back into the main blog or graduate it to its own brand. No risk to your existing authority.
3 decisions to make before you create the second project
One niche per project, no exceptions. The whole point of separate projects is clean topical authority. Mixing two niches inside one project re-creates the problem multi-blog was supposed to solve. If you find yourself wanting to publish on two topics inside the same project, that is the signal to create a second project, not to widen the first.
Decide the domain ahead of time. Project creation works without a custom domain (you get a default Vlogerly subdomain), but if you plan to use a custom domain, it is much cleaner to set it during the first 24 hours, before search engines have indexed the default URL. Domain settings live in the project settings panel.
Pick a default project. One project is the default that loads when you sign in. Set it to the blog you check most often. You can change the default at any time from the project switcher.
60-second walkthrough: adding a second blog
From any dashboard page, click the project name in the top header to open the project switcher dropdown.
Click Create a project at the bottom of the list. A slideover panel opens on the right.
Fill in the name (required). The slug is generated automatically from the name. Optionally add a description, a domain, and a logo image. Logos go through the same R2 upload that articles use, so they are served from the CDN.
Submit. The new project appears in the switcher immediately. You are still on the same dashboard view, but switched into the new project context.
If you set a custom domain, head to Settings -> Project from the sidebar and complete the DNS records. Until DNS resolves, the blog is reachable at the default Vlogerly subdomain.
The whole flow takes under a minute. There is no second login, no second billing plan, no second analytics provider.
What stays separate, what stays unified
One of the most common questions about multi-project is "what gets shared between blogs?" The honest answer is: very little, and that is intentional.
Shared: your account, your billing, your single login, the editor and its features, the platform updates, the underlying CDN and infrastructure.
Separate per project: articles, categories, tags, newsletter subscribers, analytics, domains, branding (logo, name), settings.
That separation is what makes the model work. A travel blog and a fintech blog should not share categories or subscribers; they should share only the writer's account and the platform they sit on.
Edge cases worth knowing
Deleting a project is permanent and instantaneous. Articles, categories, tags, and the newsletter list for that project go with it. The dashboard will not let you delete your last remaining project (you always need at least one).
The "default project" is per-account. Switching projects via the dropdown also updates the default, so when you sign in again you land where you last worked.
Article slugs are scoped per project. You can have /how-to-start in two different projects without collision.
Project slugs (the public URL segment) must be globally unique within your account, and they are derived once at project creation. Pick a sensible slug at the start; renaming later changes the project name but not its URL slug.
Conclusion
Managing multiple blogs from one dashboard is not an exotic workflow; it is the default whenever you decide to publish on more than one niche, language, or client engagement. The Vlogerly model gives you a single account, one project switcher in the header, fully scoped categories, tags, subscribers and analytics per project, and a 60-second creation flow that does not bury you in second logins or second billing plans.
If you are still on one blog but the second is starting to feel inevitable (because the niche is widening, a client asked, or you want to A/B a sub-topic), create the second project this week. The whole reason the model exists is so the second blog costs you a minute, not a weekend. Create your free Vlogerly account and the project switcher is right there in the header the moment you land in the dashboard.
