The pros and cons of subdomains for international SEO

When a company expands into a foreign market, it must decide where to host new language and regional versions of the website. You can register a separate domain for each country, create subdomains, or add subfolders to an existing website. All three options are used for international SEO, but the support costs and setup requirements vary.

A separate issue arises when a company already has two registered domains pointing to the same website. Without proper configuration, search engines can detect identical pages at different addresses and independently select their canonical versions.

We'll explore the specifics of each structure, its impact on indexing and link signals, and hreflang and canonical configuration. We'll also explore when it's worth changing the existing architecture and how to migrate a site without losing important pages.

What is a website domain, subdomain, and subfolder?

The domain structure determines the URLs at which users and search engines find website sections. For an international project, it also helps organize language versions, separate products, and distribute responsibilities among teams.

In practice, there are three main schemes: separate domains, subdomains, and subfolders. These can point to the same server or use different infrastructure, so a website's structure cannot be determined by a single address.

Main domain and domain zone

A domain name is the internet address of a website, such as example.com. In this address, example is the registered name, and .com is the top-level domain, often referred to as a domain extension. The domain owner controls its DNS settings and can create subdomains if the infrastructure allows it.

For international promotion, a distinction is made between country-specific domains (ccTLDs) and generic domains (gTLDs). Country-specific domains include .ua, .de, .pl, and .fr, while gTLDs include .com, .net, and .org. A country-specific domain typically refers to a specific country, although Google applies rules similar to gTLDs for some ccTLDs.

A Ukrainian company can use a single international address, example.com, or register multiple national domains. The choice depends on the target markets, the availability of suitable domain names, and the willingness to maintain separate websites.

What is a subdomain?

A subdomain is an additional name within a primary domain that appears before it. For example, in the address de.example.com, the “de” portion is a subdomain, while example.com remains the primary registered domain.

Subdomains are often created for language versions, online stores, blogs, apps, and personal accounts. Shop.example.com might host a store, help.example.com a help center, and de.example.com a German version of a corporate website.

Each subdomain can use its own CMS, server, security settings, and content publishing rules. Technical independence depends on the project's configuration: multiple subdomains can be served by a single application and database.

For SEO, the quality of pages, their accessibility to search engines, and their connection to other sections of the project are important. The mere presence of a subdomain does not provide additional ranking benefits or automatically reduce rankings.

What is a subfolder (subdirectory)?

A subfolder is a section of a website that appears after the domain name in the browser's address bar. For example, example.com/de/ might contain the German version, and example.com/pl/ might contain the Polish version.

Unlike a subdomain, a subdirectory remains within the same host. This typically simplifies centralized management of navigation, internal links, templates, and technical site settings.

Subfolders are especially convenient when international versions use a common CMS and a similar page structure. This makes it easier for the developer to maintain consistent URL generation rules, a sitemap, and a language switching system.

Moreover, the folder doesn't have to correspond to a physical directory on the server. Modern CMS and server applications can generate pages dynamically, preserving the familiar URL structure for users and search engines.

Examples of addresses for different countries and languages

Let's imagine a company that sells products in Ukraine, Germany, and Poland. It can build its website in one of three ways, maintaining separate URLs for each local version.

The addresses in the diagram are arbitrary, and the designations don't always convey the same information. For example, uk is the language code for the Ukrainian language, while UA designates Ukraine as a country. The address /de/ can also refer to the German language in general, not just users of Germany.

If a company targets specific language and country combinations, more detailed designations such as /de-DE/ and /en-GB/ can be used. However, the directory name alone does not replace proper page localization and hreflang configuration.

How does Google treat domains, subdomains, and subfolders?

Google doesn't generally prioritize subfolders over subdomains for indexing and ranking. Google Search Central's official guidelines encourage site owners to choose a structure that's easier to organize and maintain.

This doesn't mean that architecture has no impact on SEO. It affects internal links, duplicate content management, the ability to scale content, and the complexity of technical changes.

Does URL structure directly affect rankings?

The common belief that Google always favors pages in subfolders isn't supported by its official guidelines. A subdomain with high-quality content can rank well if the pages are relevant to user queries and accessible for indexing.

The difference arises at the implementation level. For example, a website with subfolders may have a more convenient internal linking system, while a company will have to configure navigation and technical processes separately for multiple subdomains.

Therefore, comparing the two structures solely based on the rankings of individual websites is inappropriate. Page content, competition, external links, technical condition, and search demand patterns all influence search rankings.

When choosing an architecture, it's important to evaluate a combination of factors. If an existing subdomain receives stable organic traffic, moving it to a folder without other reasons could create more risks than potential benefits.

Indexing and crawling by search robots

Googlebot discovers pages through links, sitemaps, and other available URL sources. For a page to be indexed, the bot must retrieve its content and ensure that the current settings allow indexing.

Different subdomains may have their own robots.txt files, sitemaps, and technical limitations. Subfolders of a single host typically share a common robots.txt file located in the root of the corresponding website.

If an international project contains thousands of pages, architectural errors can make crawling difficult. For example, a robot might find numerous duplicates instead of new products, services, and useful materials.

Search engines also need time to discover and process new URLs. Regular sitemap updates, logical interlinking, and stable server responses help avoid unnecessary indexing bottlenecks.

Link signals and internal linking

External links help search engines discover pages and evaluate their value in the context of other documents. Local link sources, language consistency, and website theme are also important for international SEO.

When all versions are located in subfolders, maintaining internal linking is often easier. Developers can use shared menus, breadcrumbs, catalogs, and recommendation blocks without additional cross-host configuration.

Regular HTML links can also be created between subdomains. Their impact depends on the specific pages and the project structure, so you can't count on automatic transfer of “domain authority” to each new subdomain.

When promoting across multiple markets, it's helpful to evaluate your link profile by individual sections and regions. Local publications can lead users directly to the corresponding language pages.

Geographic relevance and regional versions

Google uses various signals to determine the appropriate audience for a page. These include the national domain zone, the language of the main content, hreflang, local contact information, and links from relevant resources.

Geographical targeting is especially important when the same language is used by multiple countries. For example, English-speaking users in the UK and the US may expect different prices, delivery methods, and commercial terms.

For such pages, simply replacing the country name in the title isn't enough. Regional search intent needs to be verified, offerings tailored, and information provided relevant to the specific market.

In international SEO, geotargeting doesn't act as an absolute limitation on impressions. The search engine automatically selects the result it deems most relevant to the user and their query.

The Pros and Cons of Subdomains for SEO

Subdomains allow you to separate different parts of an online project while maintaining a connection to the overall registered domain. This structure is suitable for companies whose separate business areas require independent technical solutions.

However, additional hosts increase the number of settings that need to be maintained. Before creating subdomains, weigh the organizational benefits against the costs of development, content, technical SEO, and subsequent monitoring.

Benefits of using subdomains

The main advantage of subdomains is the flexibility of project organization. Teams can use different applications, publishing processes, and content management systems without rebuilding the main corporate website.

This is convenient for companies with independent products or separate national divisions. For example, a local office can update its own catalog and commercial offerings while a central team maintains the international website.

Practical benefits include:

• Separation of products. The online store, application, technical documentation, and corporate website can develop independently.
• Flexibility of infrastructure. Subdomains can be pointed to different servers, CDNs, or applications when the architecture requires it.
• Different CMS. Individual teams can work with appropriate management systems without a common update cycle.
• Regional autonomy. Divisions gain the ability to manage local inventory, content, and technical settings.
• Separation of processes. It is possible to organize separate releases, testing, and monitoring of the availability of various services.

These benefits come with proper separation of resources and responsibilities. A subdomain alone does not guarantee security, higher speed, or independence from the main website's issues.

If multiple subdomains run on a single server and share a database, an infrastructure failure could affect them all simultaneously. Therefore, technical separation must be considered when designing the system.

When does technical independence become an advantage?

Let's imagine a company with a corporate website, a SaaS application, and a help center. The main resource is hosted at example.com, the application runs on app.example.com, and the documentation is available at docs.example.com.

App developers can update functionality separately from marketing pages. Documentation editors use their own templates and publishing processes without affecting the service catalog.

For such projects, subdomains simplify the division of responsibilities. This is especially true when product teams work with different technologies or adhere to independent update schedules.

At the same time, search engine optimization for each available host requires attention. It's important to maintain logical navigation between products, properly configure indexing, and avoid creating competing pages with the same purpose.

Disadvantages of subdomains for international promotion

The main disadvantages of subdomains are related to the additional complexity of management. The more independent websites a company creates, the more difficult it is to monitor technical conditions, localization, and consistent SEO requirements.

If a business has ten regional subdomains, template errors may be repeated on each one. There's also a risk that one team might update the technical settings, while others continue to use an outdated configuration.

Common problems include:

• Additional administration. For different hosts, you have to control availability, certificates, server settings, and change publishing.
• Separate promotion processes. Each subdomain page requires its own content strategy and a sufficient number of relevant links.
• Analytics errors. Incorrect measurement settings may interfere with tracking navigation between the main site and additional hosts.
• Duplicate content. The same products and services are sometimes published in multiple regional versions without any real localization.
• Complex interlinking. Without a common navigation, some useful pages remain weakly connected to the rest of the project.

The problem often arises from premature scaling. Companies create subdomains for each language or city, even though they don't yet have the content or resources to develop them independently.

In such a situation, a single site with subfolders may be more convenient. However, this decision should be made after assessing the existing visibility and the technical costs of changing the structure.

Why doesn't a subdomain guarantee the transfer of SEO signals from the main site?

A new subdomain can share the same branding, design, and navigation elements as the main website. However, having the same second-level domain name doesn't mean all search signals are automatically shared across pages on different hosts.

Google evaluates documents and the relationships between them based on a variety of factors. Therefore, to promote a new subdomain, it's essential to ensure high-quality content, internal links, and page accessibility.

For example, if a company launched pl.example.com but didn't add a link to the Polish version to the navigation, it would be more difficult for users and robots to discover. The lack of relevant localization would also limit the usefulness of the new section.

When working with subdomains, it's important to check how the search engine actually behaves. It's important to analyze indexing, organic traffic, and link signals, rather than relying on arbitrary domain authority metrics.

When is it appropriate to use subdomains?

Subdomains make sense when specific areas of the website truly require independent management. These could include corporate services, applications, user dashboards, large reference databases, and local divisions.

An international company can also choose subdomains if regional websites use different CMSs, catalogs, or order processing systems. However, the language versions must remain understandable to users and search engines.

For a small website planning to add two or three translations, separate subdomains may be overkill. Managing multiple locales within a single CMS is often easier, especially on a smaller budget.

The decision should be made after reviewing the current structure and development plans. Unless the company has a technical reason to separate versions, creating subdomains solely for the perceived SEO benefit is unnecessary.

The Pros and Cons of Subfolders for International SEO

Subfolders allow you to host language versions on a single main domain while maintaining a familiar URL structure. For example, Ukrainian pages are located in /uk/, German pages in /de/, and Polish pages in /pl/.

For many corporate websites and online stores, this approach is convenient due to its shared management. However, with a complex international infrastructure, a single CMS and server architecture can create limitations.

Benefits of placing language versions in folders

Subfolders simplify the maintenance of an international website if pages in different languages use common templates and URL generation rules. Editors can manage translations from a single system, and developers can maintain a common technical configuration.

Internal linking also becomes easier. Users can switch languages within a single structure, and search engines receive clear links between versions of related pages.

Other benefits relate to day-to-day work. The team can more easily manage sitemaps, redirects, canonicals, analytics, and updates to common interface components.

Subfolders don't automatically gain a ranking advantage. Their practical benefit lies in simplifying the organization of related content and reducing the number of independent settings.

Disadvantages of the subfolder structure

The main limitation arises when different markets require independent technical solutions. For example, national stores may use separate catalogs, warehouse systems, and payment processing processes.

While it's technically possible to host such projects in subfolders, this sometimes requires complex request routing. In some cases, supporting multiple independent applications within a single domain is more expensive than working with subdomains.

Problems also arise when a CMS is insufficiently flexible. If the system doesn't support localized URLs, individual meta tags, and full hreflang support, a unified structure won't overcome these limitations.

Extra care is required when changing shared templates. A global configuration error can affect multiple language sections simultaneously, so it's important to test all locales before publishing changes.

When are subfolders the optimal solution?

Subdirectories are often suitable for companies that need a single corporate website in multiple languages. In this situation, the sections differ in translations and localized offerings, but share a common navigation, design, and management system.

For example, a Ukrainian agency could create example.com/uk/, example.com/pl/, and example.com/en/. Each version would receive its own text, meta tags, and URLs, and the technical team would continue to maintain a single platform.

A similar approach is suitable for an online store with a shared catalog, provided the system can accurately display local prices, delivery methods, and product availability. For international SEO, it's important that local pages meet real demand.

If you plan to expand to dozens of countries, it's a good idea to plan the architecture in advance. Adding new languages will be easier when the CMS supports separate URLs, templates, translations, and SEO settings for each locale.

Separate domains for an international website: advantages and limitations

Separate domains are used by companies for whom national markets have independent commercial significance. This structure allows for the development of local websites under addresses familiar to their audience.

However, each additional domain increases registration, technical support, and promotion costs. Furthermore, it's necessary to maintain brand consistency and properly link language versions.

National ccTLD domains

Country-code top-level domains (ccTLDs) are associated with specific countries. For example, .de refers to Germany, .pl to Poland, and .fr to France. For Google, such domain zones can be a strong geographic signal.

Users also often perceive a local domain as a sign of a company's presence in the national market. However, the level of trust depends on the brand, seller information, and website quality, so the domain extension alone does not guarantee conversion.

A company operating through national divisions can use separate ccTLDs for different countries. This is convenient for independent catalogs, support teams, and local legal requirements.

The disadvantages stem from the need to maintain multiple full-fledged resources. Each site requires content, technical maintenance, search engine demand analysis, and link profile management.

International gTLD domains

Generic domains, including .com, .net, and .org, are not tied to a specific country. Therefore, a single international domain is often chosen by companies planning to operate in multiple markets.

It can use language subfolders, regional subdomains, or a combination of both. For example, a corporate resource is hosted on example.com, and versions for different countries receive addresses within the chosen structure.

The international zone itself doesn't tell Google which language a particular page is intended for. The search engine determines the audience based on content and other signals, including hreflang and local market information.

When choosing a domain, consider your brand's development and company plans. If your business plans to gradually expand its geographic reach, a single international address can simplify the management of new locales.

When is it appropriate to register a separate domain for each country?

Separate national domains are appropriate when markets differ in product range, commercial terms, or organizational structure. In such cases, each website serves independent business purposes and can develop according to its own plan.

For example, a company sells industrial equipment in Ukraine and Germany, but uses different suppliers and contractual terms. Each market may require separate catalogs, pricing, contact information, and legal documents.

Before registering multiple domains, consider the costs of content, maintenance, and SEO. If resources are limited, maintaining a large number of independent websites can slow down promotion.

In practice, a separate domain makes sense when the national business line is sufficiently independent. When differences between versions are limited to the interface language, a structure with subfolders often requires less operational effort.

One brand on several national domains

Let's imagine an equipment manufacturer that uses example.com for its international audience, example.de for Germany, and example.pl for Poland. All three sites are owned by the same company but contain localized offerings.

The German website displays products available in Germany, along with local contact information and terms of service. The Polish version uses its own sales language, pricing, and delivery information.

If pages have corresponding translations, they can be linked via hreflang. However, each fully localized version should typically have its own canonical URL.

Don't automatically redirect visitors from one national domain to another. Users must be provided with access to the desired version, and search engines must be able to find all supported locales.

Two domains on one site: how does this affect SEO?

Sometimes businesses register multiple domains for a single project. The reasons vary: brand protection, buying a suitable name, entering a foreign market, or moving a website to a new address.

Having two domains doesn't pose a problem for search engine optimization. Risks arise when the same content is available at multiple addresses without consistent signals about which version is preferred.

Is it possible to link two domains to one website?

Technically, two domains per website are connected via DNS and web server or hosting platform settings. Both addresses can direct users to the same application, database, and set of pages.

For example, a company registered example.com and example.net. The server can accept requests from both domains and display the same online store using the same CMS.

However, this configuration requires a separate SEO solution. If both domains return pages with a 200 status code and identical content, Google receives multiple URLs for the same content.

Typically, one primary address is chosen and the second is used for permanent redirection. This is especially convenient if an additional domain is registered for brand protection or to handle old links.

What happens if the same content is available on two domains?

When identical pages are accessed on multiple domains, Google may group them into duplicates. The search engine then selects the canonical URL it deems most appropriate for display.

Duplicate content itself doesn't automatically result in a penalty. However, a website owner may find themselves in an undesirable situation where Google displays a domain other than the one the company considers primary.

There are also challenges with analytics and links. Users may navigate to different URLs, and external resources may link to different versions of the same page.

Therefore, when doing SEO for a site with two domains, it's important to determine the purpose of each address. If both domains contain the same information for the same audience, it's usually best to consolidate them through permanent redirects.

Which domain should I choose as my primary one?

Choosing a primary domain begins with checking its history and current status. If one address already receives organic traffic and has high-quality external links, this information should be taken into account before transferring.

Brand recognition, name usability, and target market relevance are also checked. For example, a national domain may be suitable for a local business, while an international company prefers a generic address.

To make a decision, it is useful to compare:

• Organic traffic and number of indexed pages of each domain.
• History of registrations, redirects and possible search problems.
• Quality and thematic relevance of external links.
• Branded queries, direct clicks, and customer's usual addresses.
• Technical condition, availability and convenience of further support.

After analysis, select a preferred domain and create a transfer map. If the old address has been used for a long time in advertising, documents, and partner materials, it should be retained as a working redirect source.

Decisions shouldn't be made solely based on name length or domain extension. An additional domain with an attractive name may be inferior to an existing resource in terms of history, traffic, and links.

How to properly set up a 301 redirect between domains?

To permanently redirect old URLs to new ones, HTTP redirects such as 301 or 308 are typically used. Google treats these redirects as a strong signal that the target URL should be chosen as canonical.

The main rule is to redirect each old page to the corresponding new one. For example, old-example.com/catalog/item/ should redirect to new-example.com/catalog/item/ if the product is still stored at that address.

It's not advisable to redirect all old URLs to the homepage. This approach degrades the user experience and can lead to the loss of relevance of certain content.

After setting up, you need to check that the redirect works in a single hop and that the destination page is accessible with a 200 status code. You should also update internal links and sitemaps so that they immediately point to the current addresses.

When to use canonical instead of redirect?

The rel="canonical" attribute tells search engines which URL to use among identical or very similar pages. It's used when alternative URLs should remain accessible, but one version is preferred for search results.

For example, a website may have technical variations of a single page with sorting options. In this situation, canonical URLs help specify the primary URL without redirecting the user from each additional URL.

However, canonical remains a signal, not a mandatory command for Google. The search engine may choose a different URL if it detects conflicting settings or more compelling signals.

If the second domain is a complete duplicate of the first and isn't needed for independent browsing, a permanent redirect is usually clearer. Robots.txt or noindex should not be used as a universal replacement for canonicalization.

Is it possible to use two domains for different countries without harming SEO?

Yes, two domains on a single website can serve different countries, as long as the pages are truly intended for those markets. However, a shared app or CMS doesn't prevent you from creating separate localized URLs.

For example, example.com might contain the international English version, while example.de might contain German pages with local business terms. The search engine receives two separate addresses with different purposes.

To ensure proper functionality, you need to localize the content, configure hreflang, and check canonical. If the main text of pages is translated into different languages, such versions are usually not considered simple text duplicates.

When both versions in the same language are virtually identical, the situation is more complex. Regional differences, intent consistency, and the need for canonicalization for specific pages must then be assessed.

Subdomains, Folders, or Separate Domains: Which to Choose for International SEO?

There's no one-size-fits-all solution for all international projects. A small corporate website, an online store with multiple warehouses, and a large SaaS platform all have different architectural requirements.

Therefore, choosing a structure should begin with business objectives and search demand. It's important to determine which markets the company intends to serve, how different the products are, and who will support the local versions.

Comparison of three architecture options

Subdomains, subfolders, and separate domains allow you to create fully functional regional websites. The differences between them primarily relate to management, technical independence, and geographic signals.

To make a preliminary selection, it's useful to compare the key characteristics of all three structures. However, the table doesn't show a direct ranking advantage of any option.

Subfolders are often chosen when a single platform and shared content team are in place. Subdomains are suitable for technically independent parts of a project, while national domains are suitable for independent local sites.

But even proper architecture can't compensate for a lack of quality content. If the language versions consist of unverified translations and repetitive commercial offers, changing the URL structure won't solve the underlying problems.

Choosing a structure for an online store

An online store needs to consider product selection, currencies, delivery, availability, and local payment methods. If the catalog is shared across multiple countries, language subfolders can simplify product and category management.

For example, a store uses shop.example.com/uk/, shop.example.com/pl/, and shop.example.com/de/. This layout allows for centralized product management while maintaining separate localized pages.

If national stores are serviced by different legal entities and have their own warehouse systems, separate domains or subdomains may be more convenient. In this case, technical independence impacts the day-to-day operations of the business.

Whatever the structure, it's important to avoid creating duplicate pages with a different country name. Buyers should see up-to-date prices, purchase terms, and information specific to their region.

Choosing a structure for SaaS and IT projects

SaaS companies often have several different types of content: a corporate website, an app, a help center, and technical documentation. These parts of the project can be updated by different teams and use separate technologies.

Therefore, subdomains are often a convenient way to separate services. For example, app.example.com serves the application's users, while docs.example.com contains developer documentation.

Marketing pages can be placed in subfolders of the main website. Language versions of services and products remain part of the overall structure, simplifying content management.

The key is to maintain clear connections between sections and avoid competing pages. If documentation and the corporate blog explain the same functionality, it's important to separate their tasks and organize internal links appropriately.

Choosing a structure for a service agency

An agency operating in several countries typically needs to localize not only texts but also commercial proposals. Demand for SEO, web development, and internet marketing services may vary between Ukraine, Poland, and Germany.

If the site's services and structure remain similar, subfolders allow for centralized support for different languages. At the same time, the Title, Description, H1, pricing, and terms of cooperation should be tailored to the specific market.

Creating a subdomain for each language can complicate the maintenance of a small website, especially when all the work is performed by a single team and there is no need for separate technical platforms.

For an agency, it's more important to properly distribute semantics and commercial pages. The localized version should address the audience's real queries, rather than simply repeat the literal translation of the original text.

Choosing a structure for a corporate blog

Corporate blogs are most often hosted in the /blog/ directory or on a separate subdomain, blog.example.com. Both options allow for organic traffic with high-quality content and proper indexing.

A subfolder is convenient when materials directly support services and commercial sections. Articles can be used to create contextual links to relevant pages while maintaining the overall navigation and analytics system.

A subdomain may be appropriate for an independent media outlet or a large content platform. For example, an editorial team uses a separate CMS, publishes content independently, and serves its own audience.

Migrating an existing blog simply because of the perceived benefits of subfolders isn't always wise. First, evaluate organic traffic, link profile, post structure, and potential migration risks.

An example of architecture for Ukrainian business entry into the EU

Let's imagine a Ukrainian company initially planning to operate in Poland and then considering entering the German market. Initially, it has a single team, a single product range, and a limited promotional budget.

In this situation, you can use an international domain with subfolders like example.com/uk/, example.com/pl/, and example.com/de/. This scheme allows you to gradually add localized sections without launching separate websites.

Once the Polish branch receives its own catalog and development team, the company may consider a separate domain or subdomain. However, the transition should be justified by genuine technical and commercial needs.

If national divisions are independent from the outset, separate ccTLDs can match the business structure. Each option must be designed with URLs, hreflang, interlinking, and content management in mind.

Setting up hreflang and canonical for international sites

Once the domain structure is selected, it's necessary to explain to the search engine the purpose of language and regional pages. This is accomplished by using separate localized URLs, the hreflang attribute, and consistent canonicalization rules.

These settings serve different purposes. Hreflang helps Google determine the appropriate language version for the user, while canonical indicates the preferred URL among identical or very similar pages.

How does the hreflang attribute work?

The hreflang attribute links alternative language and regional versions of the same content. It helps search engines display the page to users in the appropriate language or country.

For example, hreflang="uk" denotes Ukrainian, and hreflang="de" denotes German. For regional versions, you can use the combinations en-GB and en-US if the pages are intended for the UK and US, respectively.

The language code is listed first, and the regional code is listed after the hyphen. You can't use just the country code and expect Google to automatically detect the page's language.

Hreflang does not replace translations or automatically create a separate document in the index. Each version must have an accessible URL, meaningful content, and technical requirements for indexing.

How to properly link language versions of pages?

All relevant language versions must link to each other via hreflang. If a Ukrainian page specifies a German page as an alternative, the German version must link back to the Ukrainian version.

The set of alternatives also includes a link to the current page. This allows for the creation of a consistent list of locales for each version of a single piece of content.

For users whose language isn't represented on the site, you can specify x-default. This is typically linked to the language selection page or another suitable fallback.

When constructing hreflang, it's important to match documents with the same purpose. For example, a Ukrainian product page should link to the corresponding German page, not to the main page of the German section.

Example hreflang for Ukrainian, Polish, and English versions

Let's imagine a service page available in three languages: Ukrainian, Polish, and English. Each version has its own URL and contains a translation of the main text.

In the HTML document of a Ukrainian page, a set of alternative links might look like this:

<link rel="alternate" hreflang="uk" href="https://example.com/uk/service/" />

<link rel="alternate" hreflang="pl" href="https://example.com/pl/service/" />

<link rel="alternate" hreflang="en" href="https://example.com/en/service/" />

<link rel="alternate" hreflang="x-default" href="https://example.com/en/service/" />

These elements are placed within the <head> section, and a similar set is specified for all three language versions. In this example, the English page is selected as a fallback for x-default, but in another project, this could be a separate language selection page.

In addition to HTML, Google supports specifying alternative versions via XML sitemaps and HTTP headers. When choosing a method, consider the capabilities of your CMS and ensure there are no conflicting settings.

How does canonical interact with hreflang?

Canonical and hreflang serve different functions, so they need to be configured in concert. For complete translations, their own canonical URLs are typically used, and the relationships between languages are specified through hreflang.

For example, the Ukrainian page example.com/uk/service/ may contain a canonical to itself. The German page example.com/de/service/ also specifies its own address as the canonical.

The error occurs when all translations point canonical to the original language page. This configuration tells Google that other URLs are not preferred and can interfere with proper locale processing.

For very similar regional pages in the same language, the situation requires separate evaluation. For example, pages for the US and UK may have virtually identical body text, so Google recommends considering both canonical and hreflang.

How to avoid duplicates when translating a website?

Duplicates often arise due to incomplete localization. The CMS creates separate language URLs, but the main text remains the same, with only the menu, a few captions, or the country name changing.

A fully-featured language version requires translating the page content and checking its relevance to search queries. Particular attention should be paid to commercial offers, delivery terms, and terminology.

Technical setup is also important. Each locale must receive its own Title, Description, H1, canonical, and correct hreflang links if the page is intended for separate indexing.

It's impossible to automatically assign a single set of meta tags to all languages. Search queries, common phrases, and demand patterns differ, so a literal translation of Ukrainian semantics may not be suitable for the Polish or English version.

Technical SEO optimization of subdomains, folders, and domains

Even a well-chosen domain structure requires technical preparation. For international websites, correct server responses, language availability, and consistent SEO settings are especially important.

Before launching, you should check DNS, HTTPS, robots.txt, sitemap, canonical, hreflang, and internal links. After publishing, you should monitor which URLs Google detects and which versions it chooses for indexing.

DNS, HTTPS, and SSL certificates

For a domain or subdomain to function, you need to configure DNS records that link the hostname to the underlying infrastructure. Depending on the architecture, A, AAAA, CNAME, and other suitable records are used.

Every public host must be properly served via HTTPS. The certificate must cover the corresponding domain name, otherwise users may encounter security warnings.

Wildcard certificates are sometimes used when working with subdomains. However, this type of certificate does not address application security, access control, or server infrastructure security.

Additionally, uniform HTTP redirection rules are checked. If a company has chosen HTTPS and a specific hostname variant, alternative technical addresses should be rewritten to a consistent canonical structure.

Google Search Console and Analytics

Google Search Console helps you monitor page discovery, indexing, and search traffic metrics. For an international project, it's important to choose the right property types and organize monitoring of different website versions.

The domain property covers the corresponding domain and its subdomains, while the URL-prefix property can be used for more specific analysis of a specific prefix. If necessary, teams create multiple properties for easy monitoring.

In GA4, you should check transitions between domains and subdomains if a user navigates through them within the same scenario. Incorrectly configured measurements can distort traffic sources and user sessions.

It's also useful to analyze organic traffic by country, language, and landing page. This helps you understand whether a new locale is attracting relevant visitors and which areas require improvement.

Robots.txt and sitemap.xml

The robots.txt file controls search engine bot access to specific URLs within the corresponding protocol, host, and port. Therefore, settings for example.com do not automatically propagate to de.example.com.

For each public subdomain, ensure robots.txt accessibility and the absence of any unintended restrictions. Test environments, which may have been closed to robots during the development phase, should be monitored especially closely.

The sitemap.xml sitemap must contain up-to-date canonical URLs for indexing. If necessary, the XML sitemap can specify hreflang links between language versions.

Robots.txt cannot be considered a reliable way to remove a page from the search index. If you need to block indexing, use appropriate noindex mechanisms or access restrictions tailored to the specific section's needs.

Internal linking between language versions

Internal links help users and search engines navigate between related content. On an international site, they also provide access to different languages, commercial sections, and informational pages.

The language switcher should link to the corresponding version of the current page, if one exists. If there is no translation, a clear transition path must be provided, without directing the visitor to random content.

It's helpful to maintain consistent navigation and breadcrumb trails. Link text and interface elements should also match the language of the current version.

Subdomains and national domains require special attention. Logical HTML links should be created between them to ensure that related parts of the project are not isolated from the overall structure.

SSR, loading speed and localization

An international website must be fast and stable for users worldwide. Performance is affected by server infrastructure, page size, images, JavaScript, and network connection quality.

For applications with a large amount of dynamic content, server-side rendering (SSR) can be useful. It allows for the delivery of rendered HTML, but the specific rendering method should be chosen based on the capabilities of the CMS and the project's requirements.

A CDN helps deliver static resources through a distributed network of servers. However, using it doesn't eliminate the need for image optimization, script optimization, caching, and Core Web Vitals testing.

Don't forcefully redirect all visitors by IP without the option to select a language. Googlebot may not detect some regional versions if they are only available through automatic location detection.

How do I move a website from a subdomain to a subfolder or to another domain?

Migration changes the addresses of documents that may already be in the search index. Therefore, moving a subdomain to a folder or changing the primary domain requires preparation and post-publication monitoring.

Even with proper implementation, the search engine will need time to process the new URLs. On large sites, the index update period can be lengthy, so migration planning should be done with due consideration for the business risks.

Preparing for migration

Before migrating, you need to collect a complete list of existing URLs and determine their new addresses. This can be done using CMS exports, XML sitemaps, analytics data, and site scan results.

Pages that receive organic traffic or have external links are checked separately. They cannot be deleted or moved to irrelevant URLs without assessing the consequences.

Preparation includes several mandatory steps:

• Create a map of old and new URLs.
• Check pages with organic traffic and external links.
• Prepare localized meta tags and technical settings.
• Check the accessibility of the new website for search robots.
• Test redirects and canonical URLs before public launch.

After preparation, you need to ensure that the new structure supports all required languages and regions. You should also check the functionality of internal links, forms, catalog, and other elements important to users.

If the migration involves both a CMS and design change, the potential for errors increases. Whenever possible, it's best to separate independent changes to make it easier to identify the root cause of issues after launch.

Setting up permanent redirects

When a URL changes permanently, Google recommends using 301 or 308 server redirects. These indicate that the page has moved to a new address and the old URL should no longer be used as the primary one.

For each address, the most relevant page should be selected. If the service has been retained, the old URL should be directed to its new page, not to the main page or any other section.

It's important to avoid redirect chains. For example, redirecting from an old subdomain to an intermediate address and then to a new domain creates additional requests and can slow down processing.

After implementation, the redirect map should be checked automatically and selectively manually. Response codes, final URLs, the absence of loops, and the consistency of redirected pages with their original content should be monitored.

Updating internal links and technical files

After migration, setting up redirects alone isn't enough. If internal links continue to point to old URLs, users and robots will go through unnecessary redirect hops.

Menus, content links, breadcrumbs, links between language versions, and image URLs, where applicable, need to be updated. Canonical and hreflang are also checked separately to ensure they comply with the new structure.

The XML sitemap also needs to be recreated with the current URLs. The sitemap typically includes canonical pages that are actually intended for indexing.

Additionally, structured data, analytics settings, and integrations are checked. If Schema.org contains old absolute URLs, they should be updated to reflect the new domain or structure.

Checking the site after the transfer

After publishing, it's necessary to monitor the availability of new pages and the correctness of redirects. Check server responses, internal links, robots.txt, sitemap, and 404 errors.

In Google Search Console, track indexing changes and selected canonical URLs. Also analyze impressions, clicks, CTR, and rankings for key queries.

Minor fluctuations in traffic after changing URLs are possible. However, a sharp drop in visibility for certain sections requires an assessment of redirects, content, and technical limitations.

There's no universal timeframe for how long it will take for rankings to recover after migration. Processing time depends on the site's size, the condition of the pages, and how often search robots re-crawl them.

Common mistakes when choosing a domain structure

International SEO errors often arise at the intersection of development and content work. A site may have the correct language URLs but still send conflicting signals to search engines.

Problems are especially common when creating subdomains en masse, migrating pages, and automatically localizing. These errors affect multiple sections at once, so it's best to identify them before launch.

Full duplication of a website on multiple domains

Sometimes a company connects a second domain and creates an exact copy of the main website on it. Both versions receive the same text, meta tags, navigation, and indexable URLs.

Google can independently select canonical pages, but this choice doesn't always align with the site owner's plans. Furthermore, analytics and maintaining a consistent brand address become more complex.

To fix this, you need to determine whether the second domain needs to exist independently. If it's intended solely for an alternative spelling of the brand, permanent redirects are typically used.

If domains serve different markets, it's essential to ensure true localization. In this case, the content, hreflang, and canonical URLs of each version are checked.

Automatic translation without quality check

Machine translation helps speed up the production of multilingual content, but finished texts need to be reviewed. Errors in terminology, terms of service, and service names can impair page comprehension.

Literal translations of search queries are particularly dangerous. The wording popular in Ukraine may not correspond to how users search for a similar service in Poland or Germany.

For each market, it's advisable to collect separate semantics and check the search results structure. Based on this, adapt the Title, Description, H1, and body text.

If your CMS supports automatic localization, it's important to monitor the results. Avoid using the same service labels or generic commercial wording where a separate language version is required.

Incorrect canonical for different languages

One common mistake is setting a single canonical to the original version for all translations. For example, the German and Polish pages each specify the English address as the preferred one.

This setting may conflict with the goal of independent indexing of translations. This signals to the search engine that alternative URLs should not be used as primary URLs.

For full language versions, self-canonical links are typically used, which is a canonical link to the page's own URL. In this case, the pages are linked using hreflang.

If regional versions use the same language and have nearly identical content, canonicalization should be analyzed separately. It's important to consider Google's guidelines for multi-regional sites.

Missing hreflang return links

Hreflang should form a consistent system of links between related pages. If one version references another, it's advisable to ensure mutual confirmation.

For example, a Ukrainian service page contains a hreflang link to a Polish one, but the Polish version doesn't link back. This incomplete configuration can prevent Google from correctly interpreting the link.

Problems also arise from incorrect language codes, redirected URLs, and links to missing translations. Sometimes, the template automatically generates hreflang even for pages that don't yet exist.

The fix begins with checking the actual list of localized URLs. Then, it's necessary to generate correct sets of alternatives and ensure that all related pages are accessible.

Mass creation of identical regional pages

Companies sometimes create dozens of pages for different cities, changing only the geographic name. The main text, offers, contact information, and terms of service remain the same.

Such documents rarely provide additional information to the user. This is especially noticeable when the company has no physical presence in the specified cities and does not explain local operating conditions.

Before creating regional pages, research search demand. A separate URL is justified when it's possible to provide useful content for a specific audience.

This rule is equally important for subfolders and subdomains. The technical ability to create multiple regional URLs doesn't mean that each one needs to be indexed.

Redirects to an inappropriate language version

With automatic country detection, a website can redirect visitors to pages in a different language. For example, a user opens an English page, but their IP address immediately leads to the Polish section.

This behavior can interfere with access to the desired content. Search engines also may not be able to detect all versions if the site constantly changes its destination.

Instead of forced redirects, it's often more reasonable to offer a choice of language or region. This way, the original page remains accessible, and the user can make their own decision.

If a redirect is truly necessary, its impact on indexing should be tested. All important localized URLs should be accessible via direct links.

Ignoring internal links after migration

After a website transfer, links to old domains and subdomains often remain. Even with working redirects, this structure creates unnecessary redirect hops and complicates website maintenance.

Pay particular attention to menus, footers, breadcrumbs, and links within content. In large CMSs, absolute URLs can be stored in various fields, templates, and component settings.

It's also necessary to update hreflang links and sitemap data. If search engines are constantly receiving old URLs through internal navigation, processing the new structure can be complicated.

After migration, it's a good idea to run a full site scan. This will help identify redirect chains, broken links, duplicates, and documents with incorrect canonical URLs.

A Checklist for Choosing a Structure for International SEO

Before launching a new market, it's important to check not only the appropriate domain scheme but also the company's willingness to support it. A mistake in the initial choice could require costly migration once traffic starts to build.

For a small project, it's enough to start with a few key checks. A large international company will also need to coordinate the technical architecture, content strategy, and responsibilities of regional teams.

1. Identify countries and languages. Check which markets require separate versions, and where a common international website is sufficient.
2. Study search demand. Collect a semantic core separately for each language and evaluate the search results structure.
3. Select URL architecture. Compare subfolders, subdomains, and national domains based on technical capabilities.
4. Check CMS capabilities. Ensure that the system supports separate meta tags, canonical, hreflang, and localized URLs.
5. Prepare local content. Adapt services, products, currencies, delivery terms and commercial offers.
6. Set up indexing. Check robots.txt, sitemap, server responses, and the availability of all relevant pages.
7. Organize cross-linking. Add links between language versions and related commercial sections.
8. Set up analytics. Ensure accurate data collection across countries, languages, domains, and subdomains.
9. Check mobile version. Test pages on different devices and evaluate performance metrics.
10. Create a control plan. Determine who is responsible for indexing, errors, translations, and updating technical settings.

Once these steps are completed, you can proceed to launching localized sections. It's a good idea to plan the order in which new languages will be added in advance, so that expanding the site doesn't require constantly changing existing URLs.

When choosing a structure, it's helpful to consider long-term costs. Even a successful architecture will require regular technical checks, content updates, and analysis of promotion results.

How to evaluate the chosen architecture before launch?

First, you need to check whether the structure aligns with the actual business objectives. If all language versions use the same CMS, creating separate subdomains may not provide any practical benefits.

Next, they assess technical readiness: URL stability, hreflang, canonical, sitemap, internal links, and language switcher functionality. They also check for duplicate content between domains and the accessibility of pages for search engines.

After launch, key metrics should be monitored in Google Search Console and Analytics. Particular attention should be paid to indexing, organic traffic, and which local pages are receiving impressions.

If a new version isn't gaining search visibility, you should first look for the specific cause. It could be related to semantics, content, indexing errors, or insufficient page connectivity.

Subdomains, subfolders, and separate domains are suitable for international SEO if their use aligns with the business structure. Subfolders are often suitable for a centralized multilingual website, subdomains for standalone products, and national domains for individual local markets.

When two domains point to the same website with identical content, it's usually best to choose a primary URL and set up permanent redirects. If the domains are intended for different countries, it's important to ensure full localization and properly link the corresponding pages.

Before changing the existing architecture, it's important to assess organic traffic, technical limitations, and migration costs. Seo-Gen offers a technical SEO audit of your international website: our specialists will check the domain structure, indexing, canonical, hreflang, and internal links, and then prepare specific recommendations for implementation.