How to Start a Blog: Platform, Domain, and Setup Decisions

If you're wondering how to start a blog for your company, the setup decisions are usually what slow people down, not the writing. Which platform to use, where the blog should live on your domain, what to call it, and how to get it showing up over HTTPS all feel like things you could get wrong. This blog setup guide takes you through them one at a time, in the order you'd actually do them, until you have a live blog on your own domain. It stops at setup, so it doesn't cover what to write or how to write it.

You'll need a few things before you start. That's access to your current website, whoever controls your domain account, and about an afternoon of focused time for the first pass.

1. Check your existing website before you buy anything

Before you pick a platform, find out what you already have. Work out who controls your domain, your DNS (the records that point your domain at a server), your hosting, and your website CMS. Then check whether that CMS can already handle a blog. You're looking for a repeatable post type or collection, a blog landing page, and a way to publish under your company's domain. Write down who has the access to change each of these, because you'll need that person later.

If your current site can do the job, look at that route first. A second platform means more DNS work, another design to keep consistent, another navigation to wire in, and one more thing to maintain. For a founder with a small team, that extra system is often the real cost.

You're done with this step when you know whether the blog can be added to your existing site, and who has the access to launch it.

Where people go wrong is buying separate hosting or a second site builder before finding out the current website already has a CMS built in.

2. Choose a platform and a plan

If your current site can't host a blog, or you'd rather keep it separate, this is where you pick the best platform to start a blog for your situation. There isn't one winner. It comes down to who is going to run the software, what plan you need for a real business blog, and which address setups the platform supports.

Here are four common options, with the advertised prices from each vendor's official pages as of September 2026. These are list prices, not quotes for your account, and taxes, domain renewals, and add-ons can change the total. Check the price at checkout before you commit.

A few of these have details that trip people up.

WordPress.org and WordPress.com are different things. WordPress.org is the free software that you install on hosting you arrange yourself. WordPress.com is a hosted service with its own plans, where hosting, updates, and SSL come bundled. On the self-hosted side, WordPress currently recommends PHP 8.3 or greater, MariaDB 10.11 or greater or MySQL 8.0 or greater, and HTTPS support, so pick a host that meets those. "WordPress is free" is true of the software, but the complete blog still needs hosting, a domain, and someone looking after it. On WordPress.com, the current pricing page says all paid plans can install plugins, and the annual plans include a custom domain offer for the first year only, so it isn't free after that.

With Webflow, the Site plan is what publishes your website to a custom domain, and a Workspace plan is a separate thing for collaboration. A Workspace subscription doesn't stand in for a Site plan. The cheaper Basic Site plan looks tempting because it allows a custom domain, but it's meant for sites that don't need a CMS, so for a blog you'd start at Premium. The free Starter plan gives you a Webflow-hosted address with 2 static pages and a limited CMS, which is fine for trying it out and not much more.

With Ghost(Pro), you can run the blog at the root of a domain or on a subdomain. Putting it at a /blog path on a main site that's hosted somewhere else is a different setup, which Ghost says needs a self-hosted reverse proxy and a $50/month add-on available only on the Business plan. I'll come back to that in step 3.

If you plan to use DeepSmith for producing and publishing articles later, it's worth checking that your platform matches a publishing destination we support. DeepSmith publishes directly to WordPress, Webflow, Strapi, Sanity, and Contentful, and to your own webhooks. The blog itself still has to be set up on its own, since DeepSmith doesn't provide hosting or domains.

You're done with this step when you have written down one platform, a plan that actually supports a blog, the person who owns the hosting, and a rough first-year and renewal cost.

Where people go wrong is treating a free subdomain or a static-page plan as if it were the same as a business blog on your own domain.

3. Choose your blog name and where it lives

There are two decisions in this step, and it helps to keep them apart. One is the name your readers see. The other is the address, which is the place the blog sits on your domain.

If you're working out how to choose a blog name, the simplest answer for most company blogs is to use your company or product name and label it plainly as "Blog" in the site navigation. A clever standalone publication name can hide the fact that the blog belongs to your company, and then you have a second identity to build and explain.

For the address, you have three options.

• A path on your main site, like yourcompany.com/blog. This works when your website's CMS can serve it.
• A subdomain, like blog.yourcompany.com. This is often easier when the blog runs on a separately hosted service, because DNS can point the subdomain to that host.
• A separate domain. This is a second registration and a second identity to look after, so it's usually the least convenient choice for a company blog.

The first two don't need you to buy anything if you already control the parent domain. They're different website configurations, not different domain purchases. Pick the one your chosen platform actually supports. A hosted blog product can't publish into a path on a site hosted somewhere else without extra infrastructure, and Ghost's reverse-proxy requirement from step 2 is a good example. I'd avoid the argument about whether a path or subdomain ranks better, because there isn't good evidence for a general answer and it's really an infrastructure and ownership decision here. If you want to see how the choice fits into a bigger site layout, our piece on how to structure a SaaS site for AI search goes into it.

If you do want a distinctive new name, check it before you pay for any branding. Look at the exact name, similar spellings, the domains that are available, and who else is already using it. For a US-facing business, the USPTO recommends searching for potentially confusing marks in related goods and services, not only for an exact match, and it also suggests checking internet uses. It's worth reading their guidance on a comprehensive clearance search before you settle. A domain being available doesn't mean the name is cleared, and if a conflict matters to you, that's a point where legal advice is worth paying for.

Choosing a blog name comes down to keeping your company identity visible. You're done when you've settled the blog's displayed name, the address arrangement you'll use, and checked for naming conflicts.

Where people go wrong is picking a name that hides your company, or assuming an available domain gives you permission to use the name.

4. Put domain ownership and renewal under company control

If you need a new domain, register it through a registrar or reseller and record which account holds it. Write down the registrant account, the recovery contact, the renewal terms, and who can edit DNS. If you're reusing your company domain, you don't register anything, you just confirm you can get in.

ICANN separates two roles that people often mix up. The registrant holds the rights to the registered domain, and the registrar is the company that provides the registration service. Your prices, transfers, and renewals are governed by your agreement with the registrar, and ICANN's domain registration process explains how those roles fit together. When you compare registrars, compare the renewal price as well as the first payment, because the introductory price isn't what you'll pay in year two. There's no single domain price I can give you, since it depends on the registrar and the extension.

Turn on any account security and renewal safeguards your registrar offers. Registrars have to send renewal reminders, but those go to the contact details on file, so they only help if your payment and recovery details are current.

You're done when a company-controlled account holds the domain, and at least one person can change its DNS and renew it.

Where people go wrong is letting an agency, a former employee, or a founder's personal email that nobody else can reach be the only way into the domain account.

5. Connect your address and turn on HTTPS

Now create the site in your chosen platform, choose its blog-capable setup, and add your domain or subdomain in its publishing settings. Do this in the platform first, before you touch DNS. For a subdomain, the provider has to be able to serve that hostname before the DNS record will do anything useful.

Then follow that platform's current instructions for your specific site, rather than copying record values from a generic tutorial. On Webflow, the path starts in Site settings, then Publishing, then Production, and their help page on connecting your domain covers the rest. Ghost(Pro) documents mapping a custom domain through DNS records, and WordPress.com has its own separate procedure for connecting a domain you've already registered.

At your DNS provider, the record type depends on what the platform gives you. If it gives you an IPv4 address, create an A record. If it gives an IPv6 address, create an AAAA record. If it gives you another hostname to point at, create a CNAME. Use your intended subdomain as the record name. Then look at proxy status and TTL, and let the platform issue the HTTPS certificate. If you're using Cloudflare, it can serve a certificate for a DNS record only when that record is proxied, and otherwise the origin service handles the SSL/TLS connection, so read the platform's instructions alongside Cloudflare's.

DNS and HTTPS are two separate things. A record helps your hostname resolve, but the server or proxy still needs to serve that hostname securely with a valid certificate. If you're switching nameservers on a domain you've used before, list the existing records first so you don't knock out email or another service by accident.

Once it's connected, test the exact public address, and test any redirect from the alternative hostnames too. If something behaves oddly, our guide on whether your CDN or WAF is blocking crawlers is a useful check.

You're done when the address you intended loads the right blog over HTTPS, and the platform shows the domain as connected.

Where people go wrong is adding DNS records before setting up the hostname at the host, copying another provider's IP address, or assuming DNS alone gives you HTTPS.

6. Set up the blog's basic structure

With the address working, set the mechanics that every visitor will run into. That means the site title and the company identity shown on it, a blog landing page, a consistent URL pattern for posts, a link to the blog from your main navigation, and a clear way back to your main site. Only add the branding and template pieces you need. You can polish it later.

If you're on WordPress, set the permalink structure before the blog goes public. WordPress calls these the permanent URLs for your posts, pages, and archives, and its documentation on how to customize permalinks explains the options. Also confirm that your front-page and blog-page settings give you the layout you meant to have.

Check mobile navigation too, and check that the template shows visitors whose blog it is. A good way to test all of this without touching content strategy is to make an unpublished sample item and see how the template treats it.

Linking from the blog back to the rest of your site matters, and linking to the blog from it does as well. If you want to think about that further, our piece on internal linking for SaaS covers how blog, docs, and product pages connect.

You're done when the landing page, the post template, the navigation, and the URL pattern all work in preview and on the public site.

Where people go wrong is changing post URLs after publishing without planning redirects, or launching a blog that visitors can't reach from the company site.

7. Check security, search access, and measurement

This is the step where a launch quietly goes wrong, so it's worth slowing down for. Make sure there's an owner account and appropriate access for teammates. Sort out who is responsible for backups and updates, which depends on your host. Then check that the public blog isn't password-protected or marked noindex by accident.

On WordPress, look at Settings, then Reading, then Search Engine Visibility, and read the documentation for that screen if you're unsure what it does. A setting left on from a staging site is one of the most common ways a live blog ends up hidden from search.

It helps to know that a robots.txt block and a noindex tag are not the same thing. Google has to crawl a page to see a noindex tag or header, so a robots.txt block can stop it from ever seeing that instruction. Google's page on how to block search indexing with noindex covers the details. If you want to go further on crawler access, we have a walkthrough on how to configure robots.txt for AI crawlers.

Where it applies, verify your site in Google Search Console and submit your sitemap with the Sitemaps report, which Google explains in its Search Console help. Then test a public blog URL yourself, because submitting a sitemap doesn't mean a page has been indexed. Google says indexing and serving aren't guaranteed, and there's no reliable number for how quickly a new business blog gets indexed or picks up traffic, so I won't give you one. If you're curious how sitemaps relate to AI crawlers specifically, we looked at whether XML sitemaps help AI crawlers find your content.

Set up whichever analytics you prefer and confirm that it records a visit without counting it twice from duplicate tags.

A note on AI search, since a lot of founders ask. Being eligible to show up as a supporting link in Google's AI Overviews or AI Mode requires an indexed page that can appear in Search with a snippet, and Google names no extra technical requirement for those AI features. So you don't need an AI-only file or special schema before you launch. A reachable, secure, crawlable site is the setup. When you're ready to look at what else affects retrieval, our technical SEO checklist for LLM retrieval is the next place to go.

You're done when the live blog is reachable, nothing you want public is blocked by accident, a sitemap can be submitted, and a test visit shows up in your analytics.

Where people go wrong is leaving a staging-site noindex or a sitewide WordPress search visibility setting in place when the production blog goes live.

8. Launch and test it like a visitor

Before you call it launched, test it from the outside. Open the public blog in a private browser window, on desktop and on your phone. Click the blog link in your main navigation, open the blog landing page, open a public page or post if you have one, and move around using the internal navigation. Check HTTPS, check that the hostname you intended is the one that loads, and check that the alternative hostnames redirect to it.

Then check the owner side. Confirm that the right person can sign in, publish, and restore from a backup. Check that the domain and hosting subscriptions each have an owner and a renewal reminder in someone's calendar. You can add a first article whenever your writing process is ready, and this guide doesn't try to teach that part.

This is also a good point to work out how you want to launch a business blog beyond the technical switch, meaning who will look after it week to week. That's a plan for later, and our piece on content marketing for SaaS founders who don't have time to write is a reasonable place to start thinking about it.

You're done when someone who isn't signed in can reach a correctly branded, secure blog through your company website, and your team knows who maintains it.

Where people go wrong is declaring the launch finished because the builder's preview looks right, while the production domain, the navigation, or the search-access setting was never tested.

Common mistake: buying the wrong plan, or leaving production set to noindex. Both are easy to catch. Read what the plan is meant for before you pay, and test the live address in a private window before you tell anyone the blog is up.

What to do next

Once the blog is live and tested, you have a working home for your content. The next things to work out are what you'll publish and how you'll write it, and a content strategy for a bootstrapped startup is a fair place to begin. It also helps to save a short record of what you set up from this blog setup guide, including the platform, the plan, who owns each account, and the renewal dates, so nobody has to rediscover it later. If you'd like a plan for turning the finished blog into a repeatable habit, our guide on stages of content program maturity shows what usually comes after the first post.

When you're ready to fill it, DeepSmith can use your live website during onboarding, track how AI engines answer questions about your brand, and help produce and publish the articles that follow, straight to your CMS. You can start a 7-day free trial of DeepSmith and see real data and real drafts before you pay.