Subdomain vs Subfolder: Which Is Better for SEO, Blogs and Language Versions?

We at Talha Aslan and team hear this question at two moments above all: when a company launches a blog and when a site adds a second language. The subdomain vs subfolder debate has no single universal answer. However, there are clear criteria that point each business to the right one. In this guide we walk through what Google's official documentation says, how authority flows in practice, how management differs, and what a migration really risks.

What exactly are a subdomain and a subfolder?

A web address has several parts. In https://blog.example.com/post/, the registered domain is "example.com". The "blog" part in front of it is the subdomain. In https://example.com/blog/post/, on the other hand, the blog lives inside the domain as a folder that comes after the slash.

• Subdomain: It has its own DNS record. Because of that, you can point it to a different server, a different platform and a different team.
• Subfolder: It sits on the same server as the main site and usually runs in the same content management system. In other words, menus, templates and security settings stay shared.
• Country code domain (ccTLD): A fully separate domain such as example.de. It comes up as a third option when you plan language and country versions.

On paper the difference looks small. In practice, though, search engines, browsers and analytics tools often treat a subdomain as a separate host. As a result, robots.txt, Search Console properties and some reports follow that split.

What does Google's official documentation say about both structures?

Google's guide to managing multi-regional and multilingual sites compares four URL structures: a country code domain, subdomains with a generic domain, subdirectories with a generic domain, and URL parameters. The guide marks URL parameters as "not recommended." That said, it does not claim a ranking advantage for either subdomains or subdirectories.

Here is a short summary of the pros and cons it lists:

• Subdomains: They are easy to set up, allow different server locations and keep sites easy to separate. The downside is that users may not know whether "de" means a language or a country.
• Subdirectories: They are easy to set up and need little maintenance because they share one host. The downsides are a single server location and harder separation between sections.

In addition, Google's URL structure documentation uses a country code domain and a country folder on a generic domain as its examples for multi-regional sites. We do not read that as a ranking signal. Still, it is worth noting that Google's chosen examples lean toward the folder approach.

Can Google crawl and index subdomains and subfolders equally well?

Yes. Nothing in Google's documentation blocks subdomains from indexing or rewards subfolders on their own. In both setups your pages go through the same crawling, rendering and indexing pipeline. Therefore claims like "subdomains don't show up in Google" or "subfolders automatically rank higher" do not hold up.

The real difference lies in the technical rules that come with each structure. For example, Google's robots.txt documentation states that a robots.txt file on a subdomain only applies to that subdomain. The robots.txt on your main site does not control pages on blog.example.com. Likewise, some search features such as site names work at the domain and subdomain level.

In short, Google can handle both. The decision depends less on indexing and more on day to day management, internal link flow and brand consistency. We cover each of those criteria below.

How does authority flow between a subdomain and the main domain?

This is the most misunderstood part of the topic. Google does not publish a formula for how authority moves between a subdomain and its root domain. So any figure claiming that "a subdomain gets X percent of the authority" is a guess. We don't rely on numbers like that.

What we see in practice is simpler. A blog post in a subfolder naturally picks up internal links from the main menu, the footer and product pages. As a result, the external links it earns circulate inside the same site structure. On a subdomain you have to build those connections on purpose, and many teams forget to do it.

Moreover, a subdomain with its own template and its own menu often feels like a different website to visitors. That weakens linking in both directions. As we explain in our domain authority guide, third party authority scores are not Google signals. However, the continuity of internal links stays in your hands with either structure.

Subdomain vs subfolder for a blog: which should you choose?

When the subdomain vs subfolder question concerns a blog, our default advice is the subfolder. The reason is simple: a blog is a content hub that feeds your service and product pages. A reader who moves from a guide to a service page should see the same menu, the same design and the same trust signals.

A subfolder usually wins in these situations:

• The blog and the main site run on the same content management system.
• The blog exists to bring search traffic to service or product pages.
• The same team manages the content and no separate server is needed.
• You want to see the performance of the whole site in a single Search Console report.

On the other hand, things change if the blog has to live on another platform. For instance, if your main site is custom software and the blog uses an off the shelf system, a subdomain is technically easier. Even then, a reverse proxy can publish the blog under a folder. That option adds technical work, so calculate the cost and upkeep before you commit.

Subdomain vs subfolder for language versions: what changes?

For language versions, the subdomain vs subfolder question shifts a little. Here the goal is to show each reader the right page in the right language. Google can understand language pairs through hreflang in both setups. Google's documentation on localized versions also states clearly that alternate URLs do not need to be on the same domain.

Our preference in the field is language folders such as /en/ and /de/ when there is one brand and one team. With that setup, the translation workflow, templates and security updates run from one place. In addition, pages in a new language join the main site's internal link network from day one.

However, if each country runs as a separate company with its own catalog and team, a subdomain or a country code domain may fit better. Whichever structure you pick, your hreflang annotations must be reciprocal. We cover that in detail in our hreflang tag guide. For the bigger picture, see our multilingual website SEO guide.

When does a country code domain make sense as a third option?

A country code top level domain (ccTLD) is an extension tied to one country, such as example.de. Google's multi-regional guide says this structure gives the clearest geotargeting signal. On the other hand, it also notes that ccTLDs can be expensive, require more infrastructure and can only target a single country.

For example, if you serve three German speaking countries with the same content, example.de alone does not cover Austria and Switzerland. In that case a language folder is more flexible. Meanwhile, a business that sells only in Germany and cares a lot about local trust cues may find a ccTLD worthwhile.

Another drawback is that every new domain has to earn trust from scratch. In other words, the external links of your main site do not pass to the new domain on their own. Therefore we only recommend this route when you can fund separate content, separate link building and a separate budget for each market.

Decision table: which structure fits which situation?

The table below combines the pros and cons in Google's documentation with our field experience. It is not a guarantee. Instead, think of it as a starting framework that makes the decision easier.

In short, choose a subfolder when the content should feed the main site. Choose a subdomain when the content lives like a separate product or business. Keep one thing in mind while reading the table: no single row decides on its own. For example, if you need a separate server but the content feeds the main site, a reverse proxy can keep the folder structure as a middle path. So weigh the purpose of the content first, then the team setup, and finally the infrastructure.

How do you set up Search Console properties for each structure?

Search Console offers two property types. According to Search Console Help, a Domain property collects all subdomains and protocols under one roof. A URL-prefix property only covers addresses that start with the prefix you enter. A Domain property also requires DNS verification.

That split shapes the reporting side of your decision:

1. First, create a Domain property. That way the main site and any subdomains appear in one report.
2. If you use a subdomain, add a separate URL-prefix property for it. You can then track that section's issues on their own.
3. If you use a subfolder, you can still add a URL-prefix property for https://example.com/blog/. This makes it easier to isolate blog performance.
4. Submit the relevant sitemap to each property and review the indexing reports regularly.

If you are new to the tool, our Google Search Console guide walks through the core screens step by step.

How do robots.txt and sitemaps change with each structure?

Google's robots.txt documentation is very clear. The file must sit in the top level directory of the site, and its rules apply only to the host, protocol and port where it lives. Crawlers do not look for robots.txt files in subdirectories.

That rule plays out differently in each setup. With a subfolder, your blog's crawl rules live in the main site's robots.txt. So a wrong block that a developer adds on the main site can also hit the blog. With a subdomain, you need a separate robots.txt on every subdomain. Otherwise that subdomain has no rules at all.

Sitemaps follow a similar logic. Google's localized versions documentation notes that a sitemap can only contain URLs below the directory where it lives. A sitemap in the /blog/ folder therefore cannot list other pages of the main site. For that reason, the cleanest approach is to keep sitemap files at the root and reference each section as its own sitemap.

Does the structure affect site names and brand visibility?

Yes, at one specific point. Google's site names documentation says the site name shown in search results works for domain level and subdomain level sites. The same page states plainly that Google Search does not support site names at the subdirectory level.

So what does that mean in practice? If your blog sits at example.com/blog/, it appears in search results under the main site's name. For most businesses that is an advantage, because blog traffic maps directly to the main brand. On the other hand, a subdomain such as blog.example.com can carry its own site name.

That can help if you want to build a separate product brand. However, if your goal is to strengthen the main brand, a separate site name may split it in two. Put simply, brand strategy should not override the technical decision, but the two should line up.

What are the technical and team management differences?

SEO debates often focus on rankings. In daily work, though, management overhead creates the bigger difference. With a subfolder you manage one certificate, one firewall and one template system. As a result, a speed improvement reaches the whole site at once.

With a subdomain, each system may follow its own update schedule. For example, the main site may stay current while the blog runs an outdated plugin. In addition, cross domain tracking, cookie consent and tag management add work in analytics. If you skip these tasks, the same visitor can look like two different users.

• Security: An outdated system left open on a subdomain can hurt the reputation of the main brand.
• Design: Separate templates drift apart over time, and consistency needs regular checks.
• Access: For separate teams, a subdomain makes it easier to split permissions.

Therefore a subdomain makes sense when you truly need a separate team, separate software and a separate release cycle. If you don't, a subfolder produces fewer surprises.

What is the risk of moving from a subdomain to a subfolder?

Moving an existing subdomain into a subfolder is a site move with URL changes. Google's documentation on site moves with URL changes says you should expect temporary ranking fluctuation during the move. It also notes that for a medium sized site, new URLs can take a few weeks or more to replace the old ones.

The risk comes less from the move itself and more from poor execution. Missing redirects, redirect chains and forgotten internal links cause most of the losses. Moreover, panicking at an early traffic dip and rolling the structure back usually doubles the problem.

So before you decide, measure whether the current structure actually causes a problem. Don't move only because you expect "better SEO." A move needs a concrete reason, such as lower maintenance, a unified brand or stronger internal links. We plan this kind of move for your site, build the redirect map and monitor the results afterward; you can request a quote through our SEO consulting page. We don't promise rankings, but we make the risk measurable.

How do you plan a subdomain to subfolder migration step by step?

When we combine the main steps in Google's site move documentation with our own checklist, the process looks like this:

1. Build an inventory: List every indexed URL on the subdomain, the sitemap and the pages with the most traffic.
2. Create a mapping table: Write down the new address for each old URL. For example, blog.example.com/post/ becomes example.com/blog/post/.
3. Test the new structure: Before launch, check that pages in the new folder load, canonical tags point to the right place and robots.txt does not block anything.
4. Add permanent redirects: Google recommends server side permanent redirects such as 301 or 308 where possible. Send each URL straight to its final address without chains.
5. Update internal links: Change menu, footer and in-content links to the new URLs instead of leaning on redirects.
6. Refresh the sitemap: Submit a sitemap with the new URLs in Search Console.
7. Start monitoring: Track the old and the new property side by side.

Before you launch, you can test sample URLs with our redirect checker tool. For the broader process, our website migration SEO checklist offers a wider framework.

Which signals should you watch after the move?

The work doesn't end on launch day. In fact, the real learning period starts in the following weeks, because Google discovers the new structure step by step. During the first weeks, read the page indexing report and the performance report in Search Console together. The expected pattern is that old subdomain pages drop out of the index as redirects, while pages in the new folder enter it.

These are the main signals we suggest you watch:

• How quickly new URLs enter the index, and old URLs listed as page with redirect.
• Impression and click trends on your priority pages.
• URLs that return 404 because they slipped through the mapping table.
• URLs that form a redirect chain or loop.

Google advises keeping redirects for as long as possible, generally at least one year. We cover the practical side in how long 301 redirects should stay. For chain issues, see our redirect chain guide.

Does the Change of Address tool help with this move?

The Change of Address tool in Search Console exists to tell Google about a move from one domain or subdomain to another domain. Search Console Help explains that the tool only works with domain level properties. It also does not support moving a single path within the same site.

That's why you should not rely on this tool when you move a subdomain into a folder of the same domain. For cases like this, the official guidance points to redirects and sitemap updates instead. In other words, the success of the move depends on correct redirects, updated internal links and a clean sitemap.

The same help page also recommends keeping redirects for at least 180 days, and longer if Google Search still sends traffic to them. In practice we treat these redirects as permanent, because external links to old URLs live on for years. Also, don't delete the old subdomain's DNS record; otherwise the redirects stop working too.

What are the most common mistakes with this decision?

The mistakes we see most often come from haste rather than a lack of technical knowledge. You can use the list below as a pre-decision check:

• Moving on hearsay: Breaking a working structure without a reason because "subfolders are always better."
• Forcing language by IP address: Automatic redirects based on location can make it harder for Googlebot to see other languages. We explain this risk in our IP based language redirect article.
• One-way hreflang: Google states that tags get ignored if two pages don't point to each other.
• Forgetting the subdomain: Setting up robots.txt, sitemaps and Search Console for the main site and leaving the subdomain unmanaged.
• Mixed structures: Publishing one language in a folder and another on a subdomain, which adds maintenance for no gain.

To produce error free hreflang tags, you can use our hreflang generator tool.

Example scenarios: which choice would three businesses make?

The three cases below are not real clients. They are example scenarios that show the decision logic.

Example scenario 1: An architecture studio wants to add a blog to example.com. The site and the blog share one content management system, and the same team writes the content. In this case example.com/blog/ is clearly the simplest choice. That way every post can link directly to the service pages.

Example scenario 2: A software company has a marketing site and a separate customer dashboard app. The dashboard expects no search traffic, and another team builds it. Here a subdomain such as app.example.com makes sense. However, if you don't want dashboard pages in the index, you still need to configure that separately.

Example scenario 3: An online store plans to publish in Turkish, English and German. The catalog and the team are shared. In this case folders such as example.com/en/ and example.com/de/, combined with reciprocal hreflang, are the easiest structure to manage. Consequently, a ccTLD only makes sense if each country will operate like a separate company.

When should you get expert help with this decision?

If you are building a new site and the table gives a clear answer, you can make the call yourself. In some situations, though, an outside view saves serious time. Examples include moving a subdomain that has drawn traffic for years, merging several languages, or bringing different platforms under one domain.

In projects like these, we first build an inventory of the current state. Then we evaluate the structure options together with your team and infrastructure. After that, we prepare the mapping table, the redirect plan and a monitoring schedule. In the weeks after the move, we read Search Console data regularly and report deviations.

If you'd like to make this decision together and have the rollout monitored, you can get a quote scoped to your site through our SEO consulting service. We don't guarantee ranking results, but we base every step on Google's official documentation.

So which structure should you choose?

The answer to subdomain vs subfolder comes from management realities, not ranking myths. Google can crawl and index both, and its official documentation does not name either one as better for rankings. That said, a subfolder gives one brand and one team less maintenance and a more natural internal link flow.

A subdomain, meanwhile, is a strong option for separate products, separate apps and separate teams. If you are thinking about changing an existing structure, write down the reason first. Then estimate the risk, the redirect plan and the monitoring process. That way your decision becomes a measurable plan instead of a guess.

Core guide: What Is Digital Marketing? Its types, examples and how it is done, on one page with an interactive film that travels through the brain.