If you have spent more than five minutes in an SEO forum, you have probably seen this argument play out: someone wants to add a blog or a regional site to their domain and the question immediately comes up whether to put it at blog.example.com or example.com/blog. Both work technically. Both are crawlable. But the choice you make has real consequences for how search engines attribute authority, how your DNS zone is structured, and how much maintenance headache you take on for the next several years. This guide cuts through the noise and gives you a concrete answer based on how Google actually treats these structures today, with the DNS mechanics thrown in because they matter more than most SEO articles admit.
What Is a Subdomain and What Is a Subdirectory
A subdomain is a hostname that sits to the left of your root domain. When you create blog.example.com, you are creating a separate DNS record, typically an A record or CNAME, that can point to an entirely different server than your root domain. From a DNS perspective it is a distinct entity. You could host it on a different provider, a different IP address, and a completely different CMS without the root domain ever knowing.
A subdirectory (also called a subfolder) lives under your root domain path: example.com/blog. There is no DNS record to create. The web server or application handles routing internally. The entire structure shares the same origin, the same IP, and in most configurations the same SSL certificate.
The distinction sounds simple, but the downstream effects on SEO, link equity, and server configuration are significant.
How Search Engines Treat Subdomains vs Subdirectories
Google has repeatedly stated that subdomains and subdirectories are treated equivalently. John Mueller has said this in multiple office hours sessions. Take that statement seriously but not literally, because there is nuance buried in the implementation.
In practice, Googlebot treats a subdomain as a separate crawl budget entity. The crawler has to discover the subdomain, allocate crawl rate to it independently, and build a separate internal link graph for it. If your root domain has strong authority, that authority does not automatically flow to a subdomain the way it does to a subdirectory. Internal links from the root domain to a subdomain are treated more like external links than links to a subfolder.
A subdirectory, on the other hand, shares the root domain's crawl budget pool and inherits all of its accumulated authority directly. Every internal link pointing to example.com/blog passes equity as a true internal link. There is no DNS boundary for Googlebot to cross.
The Case for Subdirectories in SEO
For the vast majority of use cases, a subdirectory wins on SEO grounds. Here is why the mechanics favor it:
- Link equity consolidation: Backlinks pointing to any page on example.com benefit every other page, including your blog at example.com/blog. A backlink to blog.example.com primarily benefits that subdomain.
- Unified crawl budget: One domain, one budget pool. Google does not have to split resources between two hostnames.
- Simpler Search Console setup: A single property covers all subdirectories. A subdomain requires either a separate property or a domain-level property verification.
- Shared SSL certificate: A wildcard cert covers subdomains too, but a standard cert on your root domain already covers all subdirectories with no additional configuration.
- No DNS record maintenance: Adding a blog at /blog requires zero DNS changes. Adding blog.example.com requires creating an A or CNAME record and waiting for propagation.
When a Subdomain Actually Makes Sense
Subdomains are not always wrong. There are legitimate technical and business reasons to use them, and in those scenarios the SEO trade-off is acceptable or even irrelevant.
- Separate product lines with distinct audiences: If your main site sells enterprise software and you want a community forum, putting the forum at community.example.com on a different server makes operational sense. The forum audience and the product page audience may not overlap, and you do not want forum content diluting your product pages in search.
- Country or language targeting: Some international SEO strategies use subdomains (fr.example.com) alongside country-code domains (example.fr) and subdirectories (example.com/fr). Google supports hreflang on all three. The subdomain approach can make sense if each region is managed by a separate team with separate infrastructure.
- Staging and testing environments: staging.example.com is a completely standard pattern. Just make sure it is blocked from indexing via robots.txt or a noindex header.
- Acquired web properties: If you acquire a domain with its own authority and you want to rebrand it under your main domain without a full migration, a subdomain buy-out period can work. But plan to migrate to a subdirectory eventually if SEO is a priority.
- Technical incompatibility: Sometimes your CMS, SaaS platform, or hosting setup makes a subdirectory genuinely impossible. Webflow, for example, historically required subdomains for certain configurations. Shopify's blog can be forced into a subdirectory but some app integrations cannot.
The DNS Configuration Difference
Understanding the DNS side of this decision matters because it affects propagation time, SSL issuance, and server routing. A subdirectory change is instantaneous from a DNS perspective because nothing in the DNS zone changes. A subdomain requires a new record.
To add blog.example.com pointing to a different server, you would add one of the following in your DNS zone:
To verify the record has propagated globally after you add it, run a dig query from your terminal:
Or use a Windows command prompt:
Propagation for a new A record typically takes between a few minutes and 48 hours depending on your registrar and the TTL set on the record. A new subdomain also needs its own SSL certificate or must be covered by a wildcard cert (*.example.com). If your hosting provider issues certificates automatically via Let's Encrypt, make sure the subdomain is added to the certificate issuance before you point traffic to it.
How to Use the DNS Lookup Tool to Audit Your Structure
Before making a decision, audit what DNS records already exist on your domain. You can use our DNS Lookup tool to query all record types on your domain at once. Enter your root domain and check the A, CNAME, and AAAA records. If you see a large number of subdomains already in use (common on older enterprise sites), you have existing technical debt that should factor into your decision. Consolidating scattered subdomains into subdirectories is a legitimate SEO migration strategy, but it requires careful 301 redirect planning.
Migrating from a Subdomain to a Subdirectory
If you currently run a blog or content section on a subdomain and want to move it for SEO reasons, here is the process. Do not rush this. A botched migration can tank rankings for months.
- Crawl the subdomain first. Use Screaming Frog or a similar tool to get a complete URL inventory of everything at blog.example.com. Export the list. You need a 1:1 redirect map.
- Set up the subdirectory content. Deploy the same content at example.com/blog. Make sure canonical tags point to the new subdirectory URLs, not the old subdomain URLs.
- Implement 301 redirects at the server level. Every old URL should 301 to its exact equivalent in the subdirectory. Do not redirect everything to the homepage. Do not use 302s.
- Update internal links. Go through your root domain and update every link that points to blog.example.com to point to example.com/blog.
- Submit updated sitemaps in Search Console. Remove the old sitemap for the subdomain property and submit a fresh sitemap for the new subdirectory URLs.
- Monitor for 30 to 90 days. Rankings will fluctuate. This is normal. If you implemented the redirects correctly, authority transfers over time.
On Apache, a server-level redirect for the entire subdomain looks like this in your virtual host config:
On Nginx:
What About Wordpress Multisite and Other CMS Scenarios
WordPress Multisite is a common source of subdomain confusion. When you set up Multisite in subdomain mode, each site in the network gets its own subdomain. This is a fine architecture for running genuinely separate sites, but it is a poor choice if your goal is to run a single brand with multiple content sections. In that case, use subdirectory mode for your Multisite installation. You can switch modes during initial setup or migrate later, though migration is painful and requires a database update and server reconfiguration.
Shopify forces your store onto a subdomain (yourstore.myshopify.com) but allows you to connect a custom domain. If you are adding a blog to a Shopify store, the native blog feature runs at example.com/blogs/news, which is a subdirectory and is the correct SEO choice. If you try to run a separate WordPress blog at blog.example.com alongside your Shopify store, you are splitting your authority unnecessarily.
Practical Recommendation Based on Use Case
Stop treating this as a philosophical debate. Here is a direct answer based on scenario:
- Adding a blog to an existing site: Use a subdirectory. Always. There is no defensible SEO reason to use a subdomain here.
- Adding a help center or documentation: Use a subdirectory if your platform supports it. If you are using a third-party tool like Zendesk or Intercom that forces a subdomain, use a CNAME record and accept the trade-off, or look for a proxy solution.
- Running an e-commerce store alongside a content site: Prefer subdirectory. If technical constraints make it impossible, use a subdomain but invest in cross-linking between the two properties.
- International or multilingual content: Subdirectory (example.com/fr/) is the simplest option. Use hreflang tags correctly regardless of structure.
- Separate SaaS app or web application: Subdomain is acceptable. app.example.com is a standard pattern and the SEO trade-off is irrelevant because the app pages are typically not meant to rank.
Verifying Your Setup After Any Change
Whether you just added a subdomain, migrated to a subdirectory, or set up redirects, verify everything before announcing the change or submitting sitemaps. Check that:
- The DNS record resolves to the correct IP (use dig or nslookup as shown above)
- HTTPS works on the new URL without certificate errors
- 301 redirects return status 301, not 302
- Canonical tags on the new pages point to the new URLs
- The old subdomain does not serve duplicate content without redirects in place
The subdomain vs subdirectory question is ultimately a DNS and architecture question with SEO consequences. Get the DNS right first, then focus on content quality. A perfectly structured subdirectory full of thin content will not outrank a well-managed subdomain full of genuinely useful pages. But all else being equal, the subdirectory wins every time.