How To Create A Subdomain

What a Subdomain Actually Is

A subdomain sits in front of your main domain name, separated by a dot: blog.yoursite.com, shop.yoursite.com, staging.yoursite.com. Technically it’s a separate hostname that shares your domain’s registration but points to its own DNS record, which means it can resolve to a completely different server, a different IP address, or a different application than your main site, while still living under the same domain you already own.

That last part is what people usually miss when comparing subdomains to the alternative, a subdirectory (yoursite.com/blog). A subdirectory is just a folder path on the same install; it inherits your main site’s server, theme, and, for search engines, most of its domain authority. A subdomain is closer to running a second website that happens to share your brand name. Google has said for years it generally treats subdomains as part of the same site for most signals, but in practice they still build authority somewhat independently, load balance independently, and can even run on entirely different hosting if you want them to. If you’re deciding between the two for a blog or a store, that’s the real tradeoff: subdirectories consolidate SEO equity onto one domain, subdomains give you technical independence at some cost to that consolidation.

The DNS Record Behind Every Subdomain

Before touching any control panel, it helps to know what’s actually happening under the hood, because it explains half the “why isn’t this working” questions people run into later. A subdomain needs one DNS record pointing it somewhere:

• A record, points the subdomain directly to an IP address. Use this when the subdomain is served by a different server than your main domain (a separate app, a different host, a dedicated staging server).
• CNAME record, points the subdomain to another hostname instead of an IP, which then resolves further. This is what you use for most third-party services: pointing mail.yoursite.com to a hosted email provider, or shop.yoursite.com to a SaaS storefront platform, without needing to know or manage that provider’s IP address directly.

If you create the subdomain through your web host’s control panel rather than manually through DNS, the host typically creates this record for you automatically, pointed at the same server your main site lives on. That’s convenient, but it’s also why control-panel-created subdomains almost always live in the same hosting account as your main site by default, if you want a subdomain hosted somewhere else entirely, you’ll be editing DNS records directly at your domain’s DNS provider instead of clicking through your host’s subdomain wizard.

Method 1: Creating a Subdomain Through cPanel

Most shared and managed WordPress hosts still run cPanel underneath, even if their own dashboard hides it. If yours does use cPanel rather than Plesk, worth checking, since the exact steps differ between the two, here’s the process:

1. Log into cPanel and find the Domains section, then click Subdomains.
2. In the “Subdomain” field, type just the prefix, blog, not blog.yoursite.com, and select your main domain from the dropdown next to it.
3. cPanel auto-fills a “Document Root,” which is the folder on the server where files for this subdomain will live. Accept the default unless you specifically need it pointed elsewhere, the default keeps things organized under a folder named after the subdomain.
4. Click Create. cPanel adds the DNS record and creates the folder in one step, which is the main advantage of this route over manual DNS editing.

The subdomain is technically live at this point, but empty, visiting it will show a directory listing or a blank page until you either install WordPress there or upload content into that folder.

Method 2: Creating a Subdomain Through Your DNS Provider

If your DNS is managed somewhere other than your hosting account, Cloudflare is the most common case, since a lot of sites route DNS through it for performance and security even when hosting lives elsewhere, you create the subdomain there instead, and it has nothing to do with cPanel at all:

1. Log into your DNS provider’s dashboard and find the DNS management section for your domain.
2. Add a new record. Choose A if you’re pointing to a specific server IP, or CNAME if you’re pointing to another hostname.
3. In the “Name” or “Host” field, enter just the subdomain prefix (blog, app, staging), most providers automatically append your root domain.
4. Enter the destination IP (for an A record) or hostname (for a CNAME), save, and wait for propagation.

This method doesn’t create hosting space for you the way cPanel’s wizard does, you’re only pointing traffic. If the subdomain needs its own WordPress install or app, that has to be set up separately on whatever server the record points to.

Common Reasons to Set One Up

The steps are the same regardless of purpose, but knowing the common use cases helps you pick sensible naming and decide whether you actually want a subdomain versus a subdirectory:

• staging.yoursite.com, a private copy of your site for testing changes before they go live. Many hosts, particularly ones aimed at WordPress specifically, provide one-click staging environments that handle this without manual DNS work.
• shop.yoursite.com, separating a WooCommerce store from a content-focused main site, sometimes on different hosting entirely for performance isolation.
• app.yoursite.com, a member dashboard, community area, or web application distinct from your marketing pages.
• docs.yoursite.com, product documentation, often on a separate, lighter-weight platform than the main CMS.
• *.yoursite.com (wildcard), used for multi-tenant setups where each customer or member gets their own subdomain, generated dynamically.

Subdomain Installs for WordPress Multisite

If your reason for reading this is setting up WordPress Multisite with subdomain-style sites (site1.yoursite.com, site2.yoursite.com), there’s an extra layer beyond a single manual DNS entry: you need a wildcard DNS record (*.yoursite.com) pointing at your server, because Multisite creates new sub-sites on demand and you can’t manually add a DNS record for each one as they’re created. On top of the wildcard record, Multisite itself needs define( 'SUBDOMAIN_INSTALL', true ); set in wp-config.php during the network setup step, and most hosts require you to confirm wildcard subdomain support is enabled on their end before this works, not every shared hosting plan allows wildcard DNS, so it’s worth checking with support before building the whole network setup around it.

SSL Certificates: The Part People Forget

A brand-new subdomain does not automatically inherit your main domain’s SSL certificate unless that certificate is specifically a wildcard certificate (covering *.yoursite.com) or a multi-domain certificate that explicitly lists the new subdomain. A standard single-domain certificate for yoursite.com does not cover blog.yoursite.com, visit the new subdomain over HTTPS before that’s sorted out and browsers will throw a certificate warning, even though the main site is fine.

Most modern hosts using Let’s Encrypt via AutoSSL or a similar automated system will detect the new subdomain within a short window after creation and issue a certificate for it automatically, but “automatically” can still mean anywhere from a few minutes to a few hours depending on the host’s certificate renewal cycle. If you’re using Cloudflare in front of your hosting, its “Universal SSL” already covers first-level subdomains for the zone automatically in most plans, which sidesteps this wait entirely. If neither applies, you may need to manually trigger SSL issuance for the new subdomain from your host’s control panel rather than assuming it’ll appear on its own.

Propagation: Why It Doesn’t Work Immediately

DNS changes don’t take effect everywhere at once. Every DNS record has a Time To Live (TTL) value telling other servers how long to cache it before checking again, commonly anywhere from a few minutes to 24 hours depending on the provider’s default and whether you changed it. Until that cache expires across the internet’s various DNS resolvers, some visitors (and you, depending on your ISP) may still get “not found” or an old result. Tools like whatsmydns.net let you check propagation status across multiple global locations rather than guessing based on what your own browser shows, which is useful because your own computer’s DNS cache can make a change look “done” for you specifically well before it’s actually propagated everywhere else.

Troubleshooting Checklist

• “This site can’t be reached” right after creating it: normal in the first few minutes to hours, check propagation status before assuming something’s broken.
• SSL warning on the new subdomain: the certificate hasn’t been issued for it yet, see the SSL section above.
• Subdomain resolves but shows the wrong content: check that the document root or DNS target actually points where you intended, it’s easy to point a new subdomain at the main site’s folder by accident when clicking through a hosting wizard quickly.
• Multisite subdomain won’t create new sites: confirm the wildcard DNS record exists and that your host explicitly supports wildcard subdomains, some budget shared hosting plans block this by policy.

Creating a Subdomain in Plesk (If That’s What You’re On)

Plesk uses different terminology and a different click path than cPanel, so following cPanel instructions on a Plesk-managed host will leave you hunting for menus that don’t exist. On Plesk, subdomains are created from Websites & Domains, using an “Add Subdomain” button rather than a dedicated Subdomains section. You’ll again be asked for just the prefix and, separately, the document root, Plesk defaults this to a folder nested under your main domain’s directory, similar to cPanel’s default, though the exact path structure differs between the two panels. If you manage more than one site and aren’t sure which panel a given host runs, check the login URL pattern first, cPanel logins are typically at yourdomain.com:2083, Plesk at yourdomain.com:8443, rather than guessing from the dashboard’s visual style, which can be re-skinned by the host.

Removing or Redirecting a Subdomain Later

Retiring a subdomain isn’t just deleting the folder, the DNS record needs to go too, or the hostname will keep resolving to whatever’s left at that IP, which can produce a confusing dangling page or, worse, a security risk if someone else later controls that IP and your DNS still points visitors there. In cPanel, deleting the subdomain through the same Subdomains screen removes both the DNS entry and offers to remove the associated files. If you manage DNS externally through a provider like Cloudflare, you’ll need to delete the A or CNAME record separately from removing any server-side files, since the two aren’t linked outside of a hosting panel’s convenience wrapper.

If you’re moving content to a new location rather than deleting it outright, merging a subdomain blog into your main domain’s /blog subdirectory, for instance, which is a common SEO consolidation move, set up a 301 redirect from the old subdomain to the new URL structure before removing the old DNS record, not after. Removing DNS first just makes the old URLs return connection errors instead of redirecting, which loses whatever link equity and direct traffic the old subdomain had built up, rather than passing it forward the way a proper 301 does.

Subdomain vs. Subdirectory: Making the Actual Call

This comes up constantly for anyone adding a blog, knowledge base, or store to an existing site, so it’s worth being direct about it rather than listing pros and cons in the abstract. If SEO consolidation is the priority, you want every page contributing to one domain’s overall authority, a subdirectory wins in the general case; that’s why most SEO-focused guidance defaults to recommending yoursite.com/blog over blog.yoursite.com when there’s no strong technical reason to split them apart. Subdomains earn their keep when there’s a genuine technical or organizational reason to separate the two: different hosting requirements (a WooCommerce store needing different server resources than a content site), different teams managing each piece independently, a different CMS or application entirely, or a login-gated app area that shouldn’t be crawled and indexed the same way public content is. If none of those apply and you’re choosing a subdomain purely out of habit or because it “looks cleaner,” a subdirectory is very likely the better default.

Choosing a Subdomain Name

A few practical rules that hold up regardless of platform: keep it short, lowercase, and hyphen-free where possible, memberarea rather than member-area reads slightly cleaner in a URL, though hyphens work fine technically. Pick a name that describes function rather than being clever (docs, not knowledge), since that’s what a returning visitor is going to try typing from memory. And change your mind before launch, not after, moving content from one subdomain to another later means redirects, updated internal links, and potentially a temporary SEO dip while search engines re-crawl and re-associate the new address, all of which is avoidable by picking the right name up front.

Frequently Asked Questions

Can I create more than one subdomain on the same domain?

Yes, and there’s no practical limit imposed by DNS itself, most hosting control panels cap the number based on your hosting plan tier rather than any technical restriction, so check your plan’s limits if you’re planning to create several. Each one gets its own DNS record and, if created through cPanel or Plesk, its own document root folder.

Do I need a separate WordPress install for each subdomain?

Only if you want each subdomain to run as an independent site with its own database, plugins, and users. If instead you want subdomains that are all part of the same WordPress install and share user accounts and content, that’s what Multisite’s subdomain mode is for, covered above, the two approaches solve different problems and aren’t interchangeable after the fact without a migration.

Will a subdomain show up as a separate property in Google Search Console?

Yes. Search Console treats subdomains as distinct properties from the root domain unless you’re using a Domain property (rather than a URL-prefix property), which does aggregate data across all subdomains and protocols under one view. If you’re already tracking your main domain with a URL-prefix property, a new subdomain needs its own separate property added and verified before you’ll see its search performance data.

Does adding a subdomain cost anything extra?

Not from a domain registration standpoint, subdomains aren’t separately registered or renewed the way a new domain name is, since they’re just DNS records under a domain you already own. The only added cost would come from hosting resources if the subdomain runs its own server or app, or from an SSL certificate if your host charges separately for issuing one outside its free automated options.

How long should I wait before assuming a new subdomain is broken?

Give it at least an hour past whatever TTL was set on the record, and check propagation with a third-party tool rather than only refreshing your own browser, since your ISP or device may be caching a stale result independently of the record’s actual TTL. If it’s still not resolving anywhere after 24 hours, the record itself is the more likely problem, not propagation delay.