Information architecture for international websites: Structure that scales

Fundamentals of Information Architecture for Multilingual Websites

Information architecture (IA) for a multilingual website defines how content is structured, linked, and discoverable by users. It forms the foundation for scalable internationalization. A well-thought-out IA considers three aspects: content hierarchy, navigation between language versions, and the separation of local-specific and global content. In practice, a well-planned IA significantly reduces costs for subsequent adjustments.

Central to this is building a consistent navigation structure that allows for both global components (e.g., main menu, footer) and local adaptations. For instance, a global product catalog can be identical across languages, while landing pages in each market set their own priorities. Importantly, the language switcher should be placed intuitively—typically top right or in the mobile menu—and display all available languages and regions. Users should immediately recognize the current language and switch without losing the current page.

When planning IA for multiple languages, orient yourself around typical user journeys. Conduct an analysis of the most common search and navigation paths for each target market. Use methods like card sorting to understand how users categorize content. Determine which content should be globally uniform (e.g., technical specifications) and which must be localized (e.g., legal notices, cultural references). Document these decisions in a content inventory that grows with the website.

Recommendation: Create a navigation concept that starts identically for all languages but allows market-level extensions. Test the IA with prototypes in at least two languages before development begins. Plan for new language versions from the outset without rebuilding the existing navigation—a flat hierarchy with a maximum of three click levels has proven effective in practice.

Directory Structures: Subdomain, Subdirectory, or Top-Level Domain

For the URL structure of international websites, three common options are available: subdomain (e.g., de.example.com), subdirectory (e.g., example.com/de/), and country-specific top-level domain (e.g., example.de). Each variant has different implications for SEO, maintenance effort, and user perception. Subdomains are often treated by search engines as separate sites, making it harder to build domain authority. Subdirectories, on the other hand, consolidate all languages under one domain, simplifying backlink maintenance and rankings. Country-specific TLDs signal strong local presence but require separate domain management and technical infrastructure.

From an SEO perspective, the subdirectory structure is often recommended. It consolidates link equity on a central domain and simplifies the implementation of hreflang tags. Additionally, new languages can be easily added as another directory. Subdomains are useful when technical separation is desired (e.g., different server locations) or when content varies significantly by country. Country-specific TLDs are ideal for large markets with an independent brand presence, such as when operating separate local shops or leveraging local domain trust.

The choice also depends on the content management system and operational resources. Subdirectories are easy to implement with most CMS, while subdomains and TLDs often require additional configuration. Keep in mind: restructuring an existing setup is complex and can cause temporary ranking fluctuations. Plan long-term. In practice, companies with up to five languages usually fare well with subdirectories, while corporations with many countries opt for TLDs.

Recommendation: Start with a subdirectory structure unless your markets are very different or you need separate domains for legal reasons. Establish a consistent URL scheme from the start, e.g., example.com/{language}/{region} for variants like de-at. Avoid parameters or dot notation in paths to minimize crawling errors. Document the decision and regularly review whether the structure still fits your internationalization.

Selection Criteria for the Right URL Structure for International Sites

When deciding on a URL structure for international websites, you should weigh several criteria: target audiences and markets, technical conditions, SEO goals, and maintenance effort. A central criterion is geographic alignment: if you want to offer per-country content with local-specific domains, country-specific TLDs are the first choice. If you prefer to consolidate domain authority and closely link language versions, the subdirectory structure is recommended. Subdomains offer a flexible middle ground if you want technical separation without purchasing a separate domain per country.

Another important criterion is the technical feasibility within your CMS. Some systems only support language versions as subdirectories, while others allow subdomains or multi-domain operations. The hosting model also plays a role: with distributed servers (e.g., CDN with geo-routing), subdomains can make sense to optimize loading times. Also consider hreflang implementation: subdirectories require only a single set of annotations, while subdomains and TLDs require all language variants to be referenced at one level.

SEO goals such as visibility in local search engines or rankings for country-specific keywords influence the decision. Country-specific TLDs are generally favored by local Google versions. Subdirectories benefit from the overall domain authority. Subdomains may achieve weaker rankings in international search engines if they build little independent authority. Costs and time for maintenance should also be factored in: subdirectories can be maintained centrally, while TLDs require separate legal documents, server configurations, and domain management.

Recommendation: Create a decision matrix with your most important criteria (number of languages, local presence, CMS capabilities, budget). Test the chosen structure with a pilot market. Opt for subdirectories if global uniform content and strong domain authority are priorities. Use TLDs only for markets with an independent brand strategy and sufficient budget. Avoid mixed forms like subdomain for one language and subdirectory for another—consistency eases crawling and user understanding. Seek legal advice for legal questions (e.g., local domain registration requirements).

Navigation Depth and User Guidance across Multiple Language Versions

The navigation depth of a multilingual website should be consistent across all language versions to provide users with familiar orientation. A flat hierarchy of a maximum of three to four levels is recommended, as deep menu structures increase abandonment rates. However, the navigation for each language version must be linguistically and culturally adapted: A menu item labeled 'Leistungen' in German should not simply be 'Services' in English, but should have the same logical reference.

Ensure clear labeling of main navigation elements. Avoid ambiguous terms like 'More' or 'Other' that do not guide users to their goal. Instead, use specific labels such as 'Products', 'Support', or 'Contact'. For international websites, a horizontal main navigation is recommended, supplemented by a secondary navigation (e.g., footer navigation) for legal information or language switchers. Mobile views also require a compact presentation, such as a hamburger menu, which should not impair the discoverability of important landing pages.

User guidance benefits from breadcrumbs that show the path to the current page. These should be available in all language versions and correctly reflect the language designation of the current version. For example: 'Startseite > Produkte > Software' instead of generic 'Home > Products > Software'. This maintains orientation across languages. Avoid automatic redirects that send users to a different language version without their consent. Instead, offer a clear notification with confirmation possibility, such as a modal window: 'This page is also available in English. Would you like to switch?'

In practice, it has proven effective to test navigation depth through user testing. Conduct A/B tests for different menu structures, especially for high-traffic pages like the homepage or product pages. A menu that is too flat (only one level) can increase clarity but may make the wealth of content appear unstructured. A compromise are so-called 'mega menus' that display visual categories on the second level. These are particularly suitable for large product portfolios in multiple languages. However, ensure that load times are not impacted by too many menu items, as this negatively affects the user experience.

Placement and Presentation of Language Switchers for Optimal Discoverability

The placement of the language switcher is critical for the usability of an international website. Positioning it at the top right of the header has proven effective, as users intuitively search there for language or country options. An alternative position is the footer, which however receives less attention. For pages with many language versions, a combination header makes sense: the logo on the left, the language switcher on the right. Ensure that the language switcher appears consistently in the same spot on all subpages – not just on the homepage.

The presentation should be clear and self-explanatory. Avoid using symbols alone (e.g., a globe), as these are not recognized by all users as language switchers. A better approach is a combination of symbol and text such as 'Language' or 'DE | EN'. For a small number of languages (two to five), you can display the language codes directly: 'DE', 'EN', 'FR'. For many versions, a dropdown menu with country names in their respective local languages is recommended (e.g., 'Germany (German)' instead of just 'DE'). Users also expect the current language to be highlighted or disabled to avoid confusion.

A common mistake is automatic detection of the browser language without confirmation. In practice, this often leads to unwanted redirects that annoy users. Better: On the first visit, show a notification with the detected language and a simple button to switch. Example: 'This page is also available in Spanish. Would you like to switch?' (with options 'Yes' and 'No'). Save the decision in a cookie to retain the selection on the next visit.

For pages with regional subdomains (e.g., de.example.com, fr.example.com), a language switcher that clearly distinguishes between country versions is necessary. Here, you can additionally use a flag icon, but only in combination with the country name. Flags are culturally sensitive and unambiguous – a country should never be represented by multiple flags (e.g., Switzerland with four official languages needs separate entries). Test the visibility of the language switcher on mobile devices: it should be reachable without scrolling, for example, via an icon in the top bar.

Designing the Language Switcher with Country and Language Combinations

When a website offers both language- and country-specific content (e.g., English versions for the USA, UK, and Australia), the language switcher must reflect both dimensions. The most common solution is a two-level menu: first, the user selects a country (e.g., Germany, Austria, Switzerland) and then the desired language (e.g., German, English). Alternatively, countries and languages can be combined in a flat list: 'Germany (German)', 'Austria (German)', 'Switzerland (German)', 'Switzerland (French)', etc. This presentation is clear for up to ten entries, but becomes unwieldy with many combinations.

The use of flags is controversial but widely practiced. Note that flags are not always unambiguous – the Swiss flag represents the country, not a language. For multilingual countries like Belgium or Canada, you should therefore always add the language name. A good example is: 🇨🇭 German, 🇨🇭 French, 🇨🇭 Italian. For purely language-based versions (e.g., 'German' without country reference), you should avoid flags and instead use language codes like 'DE'. Ensure that flags are displayed in a uniform size and quality to maintain a professional impression.

The sorting of entries should be based on relevance: frequently accessed language versions or the user's region (based on IP geolocation) can be prioritized. However, always provide a complete list of all available options so that the user can choose themselves. A search field within the language switcher is helpful for more than 20 entries. Avoid automatic redirects without asking – they often lead to frustration when the detected region is not desired.

In implementation, the language switcher should be technically clean: each language-country combination leads to a unique URL (e.g., /de-de/ for Germany in German, /de-at/ for Austria in German). The selection must persist in navigation: when a user clicks on another page, the chosen language-country combination remains. Test usability on all devices, especially smartphones where space is limited. A compact footer link to a language selection page can serve as an alternative if the header becomes too crowded. Legally, we recommend designing the language selection in a data protection compliant manner and not storing personal data without consent – consult your legal department for this.

Handling multilingual content and fallback strategies

For multilingual websites, the question arises of how to handle content that has not yet been translated into all target languages. A well-thought-out fallback strategy prevents users from encountering empty pages or error messages. Define a default fallback language for each language version – typically the company language or English as a bridge language. If a particular article has not yet been localized, redirect the user to the corresponding page in the fallback language. Important: This process must be transparent. A notice such as 'This page is currently only available in English' in the user's native language reduces frustration.

Alternatively to redirection, you can use placeholders: display the original in the fallback language, surrounded by a subtle frame or icon indicating the missing translation. For product pages in e-commerce, a missing localized description can be supplemented with automatically translated short texts from the CMS – but always with a note that it is a machine translation. Avoid mixing language versions in the same navigation. A menu that displays partially German, partially English appears unprofessional. Synchronize your CMS so that missing translations are not linked in the frontend at all.

Another proven method is the introduction of 'Language Hubs': create an overview page for each language that lists all available content in that language. This way, users immediately see whether the desired information exists. Ensure that the fallback strategy also applies to dynamic content such as search results. Configure your search function so that when there is no result in the current language, it automatically searches the fallback language and marks the hits. Also plan regular reviews of the fallback logic, as the content offering constantly changes. With these measures, you ensure that users have a consistent experience even in areas of your website that are not yet fully translated.

Country-specific requirements: Legal and cultural differences

International websites must be tailored not only linguistically but also legally and culturally to the target markets. Legal requirements vary significantly: While an imprint with complete contact details is mandatory in the EU, simple information often suffices in the US. Privacy policies must take respective national laws into account – such as the GDPR in Europe, the California CCPA in the US, or Japan's PPC. Cookie banners are also country-specific: In Germany the opt-in requirement is stricter than in many other countries. Additionally, product-specific regulations may apply, for example CE marking in the EU or FDA requirements in the US. Be sure to consult a legal advisor in each target market, as mistakes can have legal consequences.

Cultural differences significantly influence the acceptance of your website. Colors have different meanings in different cultures: While white stands for purity in Western countries, it symbolizes mourning in parts of Asia. Symbols like the "thumbs up" button are offensive in some countries. Payment methods are also culturally shaped: In China, Alipay and WeChat Pay are dominant; in Germany, many customers prefer direct debit or invoice. Product images should reflect local conditions – for example, in Arab markets, do not show women in revealing clothing. Ensure that your localization also correctly implements units of measurement (metric vs. imperial), date formats (MM/DD/YYYY vs. DD/MM/YYYY), and currencies.

To meet these requirements, close collaboration with local experts or agencies that understand the cultural and legal specifics is recommended. Create a check-in process for each new target country that covers legal texts, payment options, design elements, and content. Test your website before launch with users from the target market – through usability tests or feedback rounds. Document all country-specific adjustments in a central style guide so they are not lost in future updates. Only then can you create a trustworthy and legally compliant user experience in every market.

Adapting navigation elements to local user habits

Navigation is the compass of your website – its design should be based on the habits of the local target audience. A crucial factor is the reading direction: In languages like Arabic or Hebrew, text runs from right to left, so menus, logos, and buttons should also be arranged in mirror image. The position of the main navigation (top horizontal vs. left vertical) varies by culture. While Western users are accustomed to horizontal menus, users in East Asian markets often prefer vertical navigation with many levels. The depth of navigation also plays a role: In countries with lower internet affinity, you should aim for flat hierarchies with a maximum of three levels to avoid overwhelming users.

The labeling of navigation elements must be linguistically and culturally adapted. Direct translations are not enough: An "Imprint" in Germany is precise in terms of data protection, while an "About Us" in the US seems more inviting. In Japan, polite formulations and indirect expressions are common, while US users expect direct and action-oriented labels (e.g., "Buy Now"). Symbols like a shopping cart are understood internationally, but the cart icon can be confused with a shopping basket in some countries – therefore, test icons locally. Search functions should offer placeholder texts (e.g., "Search" in the local language) and autocomplete in the local language.

Concrete recommendations: Conduct a brief analysis of typical navigation of local competitors per market – not to copy them, but to recognize patterns. Use A/B tests to determine the optimal placement of the language switcher, as expectations differ. Implement the navigation responsively: Mobile users in emerging markets often operate with their thumbs, so menus should be easily accessible. Document all country-specific navigation adjustments in your style guide so that they are automatically taken into account during content delivery. Through these adaptations, the user feels understood in every country and can navigate intuitively.

When standalone domains or subdomains are useful

The choice between standalone domains (e.g., example.fr) and subdomains (e.g., fr.example.com) depends on several factors that you should carefully weigh. Standalone country-code top-level domains (ccTLDs) signal strong local presence to search engines and users. In practice, this can boost visibility in local search results, as search engines often consider ccTLDs a strong signal for regional relevance. However, ccTLDs require higher administrative effort: you must secure each domain legally, manage separate SSL certificates, and possibly meet local hosting requirements. They also complicate centralized SEO monitoring, as each domain is treated as a separate project.

International Content Strategy: Centralized vs. Decentralized Management

The question of whether to manage content centrally or decentrally significantly affects the consistency and efficiency of your international website. A centralized content strategy means that all content is created, translated, and adapted for local markets by a global team. Advantages include a consistent brand message, lower translation costs through reuse, and centralized quality control. In practice, this approach is suitable for highly standardized products or services with minimal local variation. However, central control can be slow to respond to local market needs, as decisions often pass through multiple hierarchical levels. A decentralized content strategy gives local teams the freedom to create and publish content independently. This enables quick adaptation to local trends, legal requirements, and cultural nuances. For example, local marketing teams can develop their own landing pages for regional campaigns without waiting for headquarters approval. Disadvantages include higher redundancy costs and the risk of inconsistent brand appearances. Additionally, decentralized management complicates global SEO monitoring, as each localization requires independent optimization. In most cases, the optimal solution is a hybrid model. Define a global content framework with mandatory elements such as brand guidelines, legal notices, and core messages. Local teams then have leeway to populate this framework with country-specific content. For example, a global e-commerce shop sets product descriptions and prices centrally but allows local teams to add content like regional testimonials or seasonal offers. Practical recommendation: Start with a centralized base that includes all mandatory content. Provide local managers with clear guidelines and training so they can act autonomously. Use a content management system that supports roles and workflows for both central and decentralized users. Regularly check that local content still aligns with the global strategy. For legally sensitive content (e.g., product liability), seek advice from local legal experts.

Technical Implementation: hreflang Tags and Canonical URLs

hreflang tags are a central tool for informing search engines about the linguistic and regional targeting of your pages. They prevent duplicate content issues by pointing to the correct language version. Technically, you implement hreflang either in the HTML header, HTTP header, or in the sitemap. In practice, the sitemap method has proven to be low-maintenance since you can manage all language versions centrally. A typical entry in an XML sitemap looks like this: <url> <loc>https://example.com/de/</loc> <xhtml:link rel="alternate" hreflang="de" href="https://example.com/de/"/> <xhtml:link rel="alternate" hreflang="en" href="https://example.com/en/"/> <xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/en/"/> </url> Note that each language version must reference itself and you should use the "x-default" hreflang attribute for the default page.

Canonical URLs complement hreflang by specifying the preferred version of a page when multiple very similar content exists. Set canonical tags only when you have identical content in different language versions—for example, a press release that appears unchanged in multiple languages. In that case, use the canonical tag to refer to the original version. Important: hreflang and canonical tags do not work in opposition; they fulfill different tasks. hreflang signals language alternatives, canonical tags indicate the main version. In practice, you should avoid canonical tags when you have different content per language, as this can confuse search engines.

A common mistake is incorrectly setting hreflang for country variants of the same language. Example: de-DE vs. de-AT. Here you must specify both variants with their specific language/country code (hreflang="de-DE" and hreflang="de-AT"). Do not forget to link to the default version (x-default), which is shown when no specific match exists. Regularly check your implementation with tools like the Google Search Console report or online hreflang testers. Faulty tags can cause search engines to deliver the wrong language version.

Practical recommendation: First set up a consistent URL scheme (e.g., subdirectory or subdomain). Then create a separate sitemap for each language version or a shared sitemap with hreflang entries. Test the tags before going live using a staging environment. Document your configuration so that changes remain traceable. If you have any doubts about the legal admissibility of redirects or canonicalization, consult a legal expert.

Checklist for Auditing International Information Architecture

A systematic review of the information architecture of multilingual websites ensures that structure and navigation work consistently and user-friendly in every market. The following checklist summarizes essential checkpoints that you should go through regularly.

First, check the URL structure: Do you use uniform directories (e.g., /de/, /fr/) or country-specific domains (e.g., .de, .fr)? Ensure that each language version has its own canonical URL and that hreflang tags correctly reference all alternative pages. Test whether the URL structure is logical for both search engines and users—for example, /products/ should map the same hierarchy in every language.

Check navigation depth: Are all pages a maximum of three clicks away from the homepage? On international websites, additional filters such as country selection can lengthen navigation. Test whether the main navigation is usable on mobile devices without horizontal scrolling. Make sure that the language switcher is visible but not intrusive—ideally at the top right or as a dropdown in the navigation. Also ensure that the language selection leads the user to the corresponding homepage of the chosen market, not to a general landing page.

Validate fallback strategies: What happens when a user switches to a page that is not translated in the target country? It is recommended to display the English version with a note about the missing localization. Also check whether legal and local requirements are met: imprint, privacy policy, cookie notices, or regional product restrictions must be adapted to the respective legislation. Test load times for all language versions—a directory structure under the same domain is usually faster than subdomains or separate TLDs.

Finally, conduct a usability test with native-language users: Have them perform typical tasks such as product search, contact, or language switching. Note where delays or errors occur. Document the results and prioritize corrections by criticality. A well-functioning information architecture is not a one-time project but requires continuous monitoring, especially after content updates or market expansions.

Outlook: Trends and Optimization Potential for Scalable Structures

International information architecture is constantly evolving. Three trends are shaping the future of scalable structures: AI-powered localization, headless CMS architectures, and personalized user guidance. For operators of multilingual websites, this offers concrete optimization potential.

Artificial intelligence is increasingly automating the translation and localization of content. In practice, this means you can enter new markets faster by using AI translations as a base and then having them reviewed by native speakers. The generation of regional metadata (title, description) also becomes more efficient. However, ensure that AI-generated navigation elements do not lead to inconsistent terminology – define a terminology workflow. Optimization potential lies in integrating AI into the translation process without neglecting quality control.

Headless CMS separates content management from presentation. This allows content to be maintained once and delivered via APIs to different platforms (web, app, voice). For international websites, this simplifies country-specific delivery: you can use separate frontends per market, tailored to local requirements. However, the technical effort for API orchestration increases. Check whether your team can handle a headless CMS – often a traditional system with good multi-site capabilities is sufficient.

Personalization is also becoming more important for multilingual websites: show visitors tailored content based on location, language, or past behavior. For example, a user from Austria might see the German version with Austrian-specific products. The challenge lies in maintaining many variants without duplication. Optimize your content modeling so that regional variations are represented as options in a central editorial system. Test how personalization affects performance and use caching strategies.

Another area of optimization is Core Web Vitals: fast loading times are critical, especially for international setups with many language versions. Rely on Content Delivery Networks (CDNs) and optimize images per region. Avoid unnecessary HTTP requests from language switchers or tracking scripts. Plan regular audits with tools like Google PageSpeed Insights – for each language variant separately. The combination of technical scalability and content localization becomes a decisive competitive advantage. Start with small steps: improve one language at a time, rather than changing everything at once.

Common pitfalls in implementation and how to avoid them

In implementing an international information architecture, recurring pitfalls appear in practice. One of the most common is inadequate planning of the URL structure: companies initially choose a seemingly simple subdomain solution, only to later find that SEO signals such as backlinks and domain authority do not converge. Avoid this by establishing a long-term strategy already in the concept phase – for example, a country-specific top-level domain (ccTLD) model for markets with high autonomy or a subdirectory model for closely related language versions.

Another stumbling block is the lack of consistency in navigation. For example, if you place the language switcher prominently on the homepage but move it to a submenu on subpages, you break user expectations. Therefore, establish a consistent position and appearance across all language versions.

Neglecting the hreflang attribute also leads to duplicate content issues: search engines cannot clearly determine which version is intended for which region. Therefore, after launch, check with tools like the hreflang tester whether all tags are set correctly.

A cultural pitfall concerns navigation depth: while users in some countries prefer flat hierarchies (fewer than three clicks to the target), others expect a deeper structure with many sub-points. Research local usage habits in advance or conduct A/B tests.

Automatic redirection based on IP address can also be problematic: visitors from another country who want to change the language version become frustrated if they are constantly redirected. Instead, offer a manual language switcher and save the preference in a cookie.

Finally, many companies underestimate the effort required to maintain multilingual sitemaps. Each language version needs its own sitemap, which must be updated regularly. Therefore, rely on a central content management system that automates the generation.

If you anticipate these pitfalls early, the rework effort is significantly reduced. However, note that the specific implementation requires legal and technical advice – so consult an expert if in doubt.

Tools and service providers: When collaboration makes sense

For planning and maintaining an international information architecture, various tools are available that you can use depending on the project's complexity. Simple structures can be mapped using CMS-native functions such as WordPress Multisite or Joomla language management. For demanding setups with dozens of language versions, specialized localization platforms like Transifex or Lokalise are recommended, offering translation workflows and variant management. Collaborating with service providers becomes sensible when you lack internal expertise or time resources. Website localization agencies support you in designing URL structures, implementing hreflang tags, and optimizing navigation for local markets. For example, a medium-sized machinery manufacturer plans to launch in five EU countries and opts for a subdomain model. The agency creates a specification sheet, defines redirects, and tests the performance of each subdomain. The effort typically amounts to 40 to 80 hours for initial setup, depending on content volume. When selecting a service provider, you should look for references with similar project size and obtain a detailed proposal that also covers maintenance costs. A common objection to external partners is the lack of control. You can counter this by defining close coordination processes, such as weekly status meetings and access to project management tools like Jira or Trello. For companies with high security requirements (e.g., in the financial sector), an internal solution may be more advantageous despite the higher effort. Note that the decision for or against a service provider also depends on your budget: for one-off projects with a clear scope, an agency is often more cost-effective than building your own team. Ongoing localization and content updates, on the other hand, can often be handled more cheaply by a dedicated freelancer. Regardless of the choice, you should always consult a legal advisor to correctly implement country-specific requirements such as the GDPR or cookie guidelines. Tools and service providers are not a panacea, but they accelerate the process and reduce sources of error – provided you retain strategic leadership.