Building Multilingual URLs Correctly: Slugs, Special Characters, Strategies

Fundamentals of multilingual URL structures: Subdomain, subdirectory or ccTLD

Choosing the URL structure is one of the fundamental decisions for a multilingual website. Three common models have become established: country-specific top-level domains (ccTLDs), subdomains, and subdirectories. Each variant has specific advantages and disadvantages that you should weigh according to your goals and resources.

ccTLDs such as example.de or example.fr clearly signal the geographic focus to search engines and users. They are particularly suitable if you want to build an independent brand presence in each country. The disadvantage: you need separate domains, which increases administrative effort and costs. Additionally, signals such as backlinks cannot be aggregated across domains. For international corporations with local branches, this can be the right solution.

Subdomains like de.example.com or fr.example.com are easier to set up. They allow separate technical management, for example different content management systems. Search engines often treat subdomains as independent websites, which makes building authority more difficult. From an SEO perspective, subdomains are therefore not the first choice, unless you separate language versions for technical reasons.

Subdirectories such as example.com/de/ or example.com/fr/ are the most efficient from an SEO perspective. The domain collects all backlinks and trust signals in one place, so each language version benefits from the overall authority. They are also easy to manage. For most companies with a central domain, the subdirectory model is recommended. However, you must use hreflang tags to clearly reference the different language versions to avoid duplicate content issues.

In practice, a combination has proven effective: use subdirectories for language separation, but use ccTLDs for strong local brands or legal requirements. Before migrating, be sure to check current rankings and redirect old URLs with 301 redirects. Seek advice from an SEO expert when choosing, as the decision has long-term effects.

Translated paths vs. English slugs: Pros and cons for users and SEO

The design of URL paths – the part after the domain – is a central aspect of internationalization. Two strategies are prominent: translated paths (e.g., /de/produkte/kleidung/) or English slugs (e.g., /de/products/clothing/). Both have specific impacts on user-friendliness and search engine optimization.

Translated paths offer local users immediate added value. A French visitor immediately recognizes that /fr/vetements/ stands for clothing. This enhances the user experience and can increase the click-through rate in search results. Search engines can also interpret the keywords in the path as a relevance signal – provided the translation is correct and common. Disadvantage: The paths must be maintained with effort. With many languages, the translation effort increases, and changes to product names can lead to broken links. Additionally, translated paths can become longer and more error-prone.

English slugs are globally consistent. They significantly simplify technical administration because all language versions use the same path (only the language identifier differs). For search engines, the URL structure remains unchanged, which keeps indexing stable. However, the benefit for the local visitor is lower: A German user does not immediately recognize the topic if the slug remains English. In practice, however, many international websites work successfully with English slugs, provided page titles and H1s are optimized for the local language.

Our recommendation: Decide based on your content strategy. If you operate many language-specific landing pages with local keywords, translated paths are useful. If you mainly work with standardized product pages, English slugs suffice. A hybrid model – e.g., translated paths for main categories, English for products – can combine the advantages of both worlds. Important: Do not change chosen slugs lightly, as this endangers rankings. Use 301 redirects and a consistent hreflang setup for migrations.

Dealing with special characters: Umlauts, diacritics and ASCII substitution

Special characters like umlauts (ä, ö, ü) or diacritical characters (é, ñ, ç) pose a challenge in URL design. Technically, they are allowed in URLs, but not all systems and browsers handle them equally. For smooth usage and SEO, you should therefore follow a well-considered strategy.

In principle, you can keep umlauts in the URL – modern browsers and search engines automatically encode them in percent encoding (e.g., %C3%A4 for ä). This means the readable address is displayed in the browser, but behind the scenes a technical conversion takes place. The disadvantage: the URL becomes longer and less clear. Additionally, older systems or crawlers may have problems. In practice, most German-language websites therefore use ASCII substitution: ä becomes ae, ö becomes oe, ü becomes ue, ß becomes ss. This variant is recommended because it is universally compatible and brings no surprises.

For international projects with many languages, you should establish a uniform convention. Replace all special characters with their Latin equivalents without diacritics, i.e., é to e, ñ to n, ç to c. For SEO, this has the advantage that keyword recognition in the URL is not hindered by special characters. Users from other regions rarely type these characters directly anyway. Ensure that the substitution is consistent – a script or CMS function should automate this.

Avoid mixed approaches at all costs: A URL must not contain both umlauts and substitutions. Document your rule clearly and enforce it for all language versions. If you migrate from an old structure with special characters to ASCII slugs, redirect each old URL using a 301 redirect to the new one. Also check whether your target markets have specific requirements – in Scandinavia, for example, æ and ø are often considered separate letters. If in doubt, consult a legal expert, as naming rights for brands with special characters may be affected.

Language Marking in URLs: Using ISO Codes and Country Codes Correctly

The choice of language or country identifier in the URL influences both user guidance and search engine interpretation of your multilingual website. Two common standards exist: ISO 639-1 for language codes (e.g., 'de' for German) and ISO 3166-1 for country codes (e.g., 'DE' for Germany). In practice, you combine both to cleanly separate regional variants: 'de-de' for Germany, 'de-at' for Austria, 'de-ch' for Switzerland.

Use these codes ideally as path prefixes directly after the domain: example.com/de-de/produkt/. This keeps the structure clear and search engines recognize the target region via the hreflang attribute. Ensure consistency – avoid mixed forms like 'deu' or 'DEU'. Use exclusively lowercase for language codes; for country combinations, separate with a hyphen and capitalize the country code (e.g., de-DE).

A common mistake is using country codes without language reference: 'example.com/us/' for the USA says nothing about the language (English, Spanish, etc.). Better: 'en-us' for American English, 'es-us' for Spanish in the USA. If you offer only one language per country, a language identifier alone also works: 'example.com/de/' for German overall, but then you lose regional granularity.

Practical recommendation: In your CMS or project, define a table that specifies the exact path code for each target language and region. Use the hreflang tag with the corresponding combination code (e.g., de-DE) for output. This avoids inconsistencies that confuse search engines. After setup, test the URLs with a crawler to ensure each path is unique and no duplicate content arises. If uncertain about correct implementation of your specific country-language combinations, consult an SEO specialist or legal advice, especially if statutory country-specific regulations apply to your industry.

Consistency Rules for Slug Translations: Uniform Conventions Across the Team

Slug translations ensure that your multilingual URLs are not only technically correct but also semantically consistent. Whether you use translated paths or English slugs, you need binding conventions across the team. First, decide on a basic principle: either all slugs are translated into the target language (e.g., '/produkte/schuhe/' in German, '/products/shoes/' in English) or you maintain uniform English slugs (e.g., '/products/shoes/' for all language versions). The latter simplifies maintenance but may reduce local relevance.

Establish rules for transcribing special characters: umlauts (ä, ö, ü) should become ae, oe, ue if your system does not support UTF-8 slugs. For diacritics (é, ñ, ç), use ASCII replacements (e, n, c). Define a table with all occurring characters and their replacements – this must be consistent across all languages, otherwise different paths will emerge for the same term. Pay attention to hyphens, word separations, and capitalization: typically use lowercase and separate words with hyphens (e.g., '/de/ueber-uns/'), never underscores.

Implement a central glossary within the team that stores the correct slug for each term in all languages. Prefer native speakers for translations and avoid ad-hoc translations. Before launch, conduct a reconciliation: identical products or pages must have logically identical slug structures across all language versions to prevent user confusion. Document the agreed conventions as a checklist – this ensures consistency during new hires or content changes. An automatic slug generator in the CMS helps enforce rules: have terms automatically transcribed and shortened to a maximum of 50 characters. Regularly check whether the slugs are still current and not inconsistent due to product changes.

Migrating URL Structures: Planning 301 Redirects and Canonical Tags

Migrating your multilingual URL structure – for example, from subdomains to subdirectories or from English to translated slugs – requires careful planning to minimize traffic loss. Key elements are 301 redirects and canonical tags. Start with a complete inventory of all existing URLs per language. Create a mapping table: old URL → new URL, excluding the language identifier. Each old URL must point to the corresponding new URL in the same language version – not to the homepage or another language.

Implement 301 redirects server-side (e.g., via .htaccess or Nginx), ideally using high-performance redirect modules. Test all redirects before going live with a crawler to avoid dead links or redirect chains. Note: When changing languages, you cannot simply redirect all URLs of a subdomain to another, as the language context would be lost. Example: de.example.com/produkt (old) → example.com/de/produkt (new). Canonical tags help manage duplicate content during the transition: set a rel=canonical on the old URL pointing to the new URL if the old one has not yet been deleted. After a successful migration, old URLs should drop out of the index after a few weeks.

Another important step is updating internal links: adjust menus, breadcrumbs, and footer links to the new paths, otherwise broken links will occur. Sitemaps must also be regenerated – one sitemap per language version with the new URLs. Inform search engines of the change in Search Console by submitting the new sitemaps and removing the old ones. Plan a rollback scenario: keep the old URLs active for a transition period of at least three months in case adjustments are needed.

Finally, monitor the performance of the new structure: compare rankings, impressions, and clicks before and after migration. In case of unexpected drops, recheck the redirect logic and canonical declarations. For legal aspects, such as country-specific specifications, consult legal advice early to ensure compliance.

Correctly Implementing Hreflang Tags: Linking with URL Structure

Hreflang tags are a central element for multilingual websites. They signal to search engines which language and country targeting a page has and which alternative language versions exist. Correct implementation is crucial to avoid duplicate content issues and to serve the right version in search results.

The connection with the URL structure is established via the canonical tag of the respective language path and via hreflang attributes in the HTML header or in the sitemap. Each language version must reference itself and list all alternatives. It is mandatory to use two-letter ISO language codes (e.g., 'de' for German); optionally, the country code can be added (e.g., 'de-de' for Germany). For regional variants such as Swiss German ('de-ch'), precise hreflang values should be used. A common mistake is the absence of an x-default value, which defines a fallback page for non-matching language regions.

Practice shows: Hreflang tags should be placed on each page in the <head> section or via HTTP headers (e.g., for PDFs). Avoid contradictions between hreflang declarations and the actual language orientation of the page. For example, an English page with 'en-us' must not reference a Spanish page with 'es' if the latter does not also exist as an English alternative. Use tools like Google Search Console to check for implementation errors. A consistent URL structure facilitates maintenance: use the same scheme (e.g., subdirectory /language/) for all language versions and adhere to fixed rules for slug translation.

Recommendation: Create a central table with all language versions and their hreflang values. Regularly check for missing or incorrect tags using a crawler. During migrations, update all hreflang references simultaneously to avoid confusion for search engines. Keep in mind that faulty implementation can lead to traffic losses in individual language regions – a systematic review is essential.

Multilingual Sitemaps: Structure and Submission for Search Engines

Multilingual sitemaps help search engines discover and index all language versions of your pages. Their structure follows the same technical standards as monolingual sitemaps, but with additional details on language alternatives and hreflang information. You can either create a single sitemap for all languages or separate sitemaps per language. The latter is advisable when the website is very large or has different path structures.

In the sitemap, specify the language-specific address for each URL. Use the <xhtml:link> element with rel="alternate" and the hreflang attribute to list all other language versions. For example, for a German page /de/product/, include references to /en/product/ and /fr/produit/. Ensure these references are bidirectionally consistent – each page must be included in the hreflang entries of all alternatives. The sitemap itself can be named with a language indicator, e.g., sitemap-de.xml.

Submission is done via Google Search Console and other search engine tools. Submit each language-specific sitemap or use an index sitemap that points to all sub-sitemaps. Check the sitemap for errors such as broken links or missing alternatives. A crawler like Screaming Frog can help validate completeness. Note that the sitemap should not contain duplicate URLs – each language version appears exactly once. For dynamic parameters, use canonical tags to determine the preferred URL.

Recommendation: Create one sitemap per language and group them in an index sitemap. Update the sitemap whenever content changes and resubmit it. Use hreflang tags within the sitemap as the primary method, as search engines prefer processing them. Test the sitemap with the Google Sitemap Validator and fix any errors before submission. A clean sitemap improves the discoverability of all language versions and reduces the risk of duplicate content.

International Search Intent and URL Adaptation: Localization Instead of Translation

Simply translating URL slugs is often insufficient to capture the search intent of international users. Localization means adapting the URL to reflect country-specific search habits and cultural nuances. For example, German users are more likely to search for “Schuhe kaufen” than “shoes buy.” A localized URL like /de/schuhe-kaufen/ is therefore preferable to a direct translation like /de/shoes-buy/.

Adaptation should be based on keyword research in each target language. Use local search volume data and analyze which terms are common in individual markets. Avoid Anglicisms if they do not match linguistic usage. In France, English terms are often less common than in Germany. Change the slug structure only if it improves the user experience – otherwise, a translation of the existing structure suffices. Pay attention to country variants: “apartment” vs. “flat” or “color” vs. “colour” should be chosen accordingly in the slugs.

Another aspect is semantic fit: a slug should describe the content precisely but also be relevant to search engines. For example, instead of /de/produkte/artikel123/, use /de/produkte/sport-schuhe/. Keep slugs short and meaningful – long slugs are often truncated. Note that localization may also involve changes to the URL structure, e.g., from /en/ueber-uns/ to /en/about-us/. This requires clean 301 redirects to preserve link equity.

Recommendation: Conduct keyword research for each target language and create a list of preferred slugs. Consult native speakers to avoid cultural pitfalls. Document localization rules within the editorial team. After implementation, monitor click-through rates in Search Console to measure effectiveness. Avoid repeatedly changing slugs – plan the final version carefully from the outset. Well-thought-out localization increases relevance in international search results and improves user experience.

Avoiding Duplicate Content: Pitfalls with Similar Language Versions

On multilingual websites, duplicate content is particularly common when language versions are very similar in content – e.g., DE and AT, or Spanish for Spain and Latin America. Search engines may treat such pages as duplicates if they are not clearly marked. Typical pitfalls include identical product descriptions in different languages, automatically translated landing pages without manual adjustment, or URL parameters that deliver the same content under multiple addresses.

To avoid duplicates, set a correct hreflang link for each language version in the header or sitemap. Ensure that hreflang tags point to the correct URL and that each language page also includes a self-reference entry. For country variants with the same language (e.g., en-US and en-GB), you should offer different content – such as adjusted currencies, units of measurement, or regional terms. Pure translations without localization increase the risk of being classified as duplicates.

Practical recommendation: Regularly check your multilingual pages for overlaps. Use a crawling tool that shows you which pages have similar meta tags or text blocks. If you must use the same text for different countries, set the rel="canonical" attribute on the preferred version and link the others via hreflang. Note: Canonical tags are a hint, not a command – search engines can ignore them. Therefore, content differentiation is the safer path.

Another pitfall is parameters like ?lang=de or ?locale=de_DE that make the same content accessible under multiple URLs. Include such parameters in Google Search Console as "URL parameters" or avoid them entirely by using clean URL structures with language paths. During migrations or URL changes, you must redirect all old versions via 301 to the new correct language URLs – otherwise, duplicate indexing occurs. For legal questions regarding international content strategy, consult a specialist lawyer, as copyrights and trademark rights can vary by country.

Tools for checking and maintaining multilingual URLs

Regular monitoring of multilingual URLs requires specialized tools that cover both technical and content aspects. A crawler such as Screaming Frog SEO Spider or other website crawlers can capture all URLs of a domain and check them for hreflang tags, canonical links, HTTP status codes, and language errors. Configure the crawler to traverse all language versions and generate a report on missing or incorrect hreflang entries.

For ongoing maintenance, monitoring tools that track changes to hreflang tags or URLs and notify you of deviations are recommended. Many SEO suites include features for international SEO, allowing you to centrally manage language and country assignments. Ensure the tool supports duplicate detection—for example, through similarity analyses or comparing meta descriptions and titles. In practice, it has proven useful to generate a monthly crawling report and validate the hreflang implementation.

Another important tool is Google Search Console (GSC). It shows potential issues with hreflang or duplicate content for each language version. Use the “International Targeting” report in GSC to see if your pages are being served correctly. Also check there whether search engines have indexed unwanted language variants—for example, due to missing redirects. Additionally, you can use log file analysis tools to see how often crawlers request your different language versions.

An important recommendation: Document your URL structure and the language codes used in a central concept. Maintain a table with all language versions, their paths, hreflang tags, and specific notes (e.g., special character rules). This ensures that all stakeholders—editors, developers, translators—work according to the same conventions. For quality assurance, spot-check manually: Go through the most important paths in different language versions and watch for technical errors. Note that no guarantee of error-free function exists—the tools provide indications, not absolute certainty.

Performance Impact: Load Time Due to URL Length and Character Encoding

The length of a URL and the characters it contains directly impact your website's performance, though usually to a minor extent. Each additional character in a URL increases the data transmitted in HTTP requests—however, especially on pages with many images or scripts, this does not accumulate into a significant load time disadvantage. More critical is the type of character encoding: URLs with umlauts (e.g., “ä”) or diacritical marks (e.g., “é”) are converted by browsers using percent encoding (e.g., %C3%A4). This makes the URL longer and reduces readability. Additionally, some servers process these encoded characters more slowly than pure ASCII characters.

In practice, it is advisable to avoid special characters in URLs altogether and instead use ASCII-compatible substitutions. That means: “ä” becomes “ae”, “é” becomes “e”, and so on. However, this can lead to ambiguities—for example, “Straße” might be transcribed as “strasse”, which is not intuitive. An alternative is to use only English slugs, even if the content is in another language. But then you must weigh whether readability for users suffers. From a performance perspective, short, ASCII-based URLs are ideal.

Another factor is automatically generated URLs, which often become very long—for instance, due to product names in multiple languages. If you use long paths (e.g., /de/produkte/kategorie/unterkategorie/produktname-mit-40-zeichen), this can affect server processing time, especially with complex rewrite rules. The length can also increase when passing URL parameters for tracking or filtering—ensure the URL does not exceed the 2,000-character limit imposed by many browsers and servers. In practice, multilingual URLs usually stay below this limit.

Conclusion: Optimize your URL structure from the system design stage. Keep slugs short and avoid unnecessary path segments. If you operate many languages, use language codes (e.g., “/de/” instead of “/deutschland/”). Use only ASCII characters or implement server-side rewrite rules that automatically convert umlauts—without the user seeing the encoded version. Regularly test the load time of your critical language versions with performance tools. Note: A single URL rarely makes the difference, but in the sum of all optimizations, consistent character handling is important. For legal questions regarding the use of certain characters in URLs (e.g., trademark rights), please consult expert advice.

Checklist for Implementing a Multilingual URL Strategy

A systematic approach is key to a consistent and search-engine-friendly multilingual URL structure. The following checklist guides you through the essential steps – from planning to ongoing maintenance. Adjust the order as needed for your specific starting point.

**Planning Phase** 1. Define the language and country combinations you want to cover. Choose a URL structure (subdomain, subdirectory, or ccTLD) based on your target markets and technical resources. Use official ISO 639-1 codes for language identification (e.g., "de" for German) and supplement with ISO 3166-1 codes for country-specific variants (e.g., "de-at"). 2. Establish uniform conventions for slug translation. Decide whether to fully translate paths or retain English slugs – and document the decision per page type. Consider the search intent of the target audience: for heavily localized content (e.g., guides), translated paths are usually more beneficial; for branded products or technical documentation, English slugs may be more consistent. 3. Clarify the handling of special characters such as umlauts or diacritics. Recommended is conversion to ASCII equivalents (e.g., "ü" to "ue") or, if server configuration allows, percent-encoding. Choose a rule and apply it consistently across all languages.

**Implementation Phase** 4. Implement the URL structure in parallel with content creation. Ensure correct hreflang tags linking each language version to alternative URLs. Use either the HTML element or the sitemap method. 5. If migrating from an old structure, plan carefully. Set up 301 redirects from each changed URL to the new address. Document the mapping in a table and test the redirect chain before going live. 6. Create a multilingual sitemap containing all language versions with their correct hreflang annotations. Submit it in Google Search Console and other search engine tools.

**Post-Implementation and Maintenance** 7. Regularly check your URL structure for consistency. Tools like Screaming Frog or Sitebulb can help identify broken internal links or missing redirects. 8. Train your content team on the established conventions. A central document with examples and exceptions prevents deviations. 9. Monitor the performance of individual language versions, especially after major changes. Watch for unusual traffic drops or crawling errors in Search Console. For legal questions, such as domain selection, consult legal advice.

Outlook: Dynamic URLs, PWAs, and Future Developments

While static, descriptive URLs are the standard for multilingual websites, dynamic parameters and modern web technologies like Progressive Web Apps (PWAs) are gaining importance. Even if you are not currently using these techniques, you should keep an eye on their impact on your URL strategy.

**Dynamic URLs** Dynamic URLs with parameters (e.g., "?lang=de&id=123") are generally less SEO-friendly, as search engines crawl and interpret them less effectively. If you cannot avoid them for technical reasons, minimize the number of parameters and use meaningful names. Also, add a canonical tag pointing to the clean, static version. In practice, search engines index content behind complex dynamic paths less frequently. Therefore, whenever possible, rely on descriptive URLs and use dynamic parameters only for internal functionalities (e.g., filters).

**Progressive Web Apps (PWAs)** PWAs enable an app-like experience in the browser and often run under a single domain. For multilingual PWAs, a subdirectory structure (e.g., "domain.de/de/") is recommended, as it works consistently with the PWA manifest and service workers. Note that language switching within the PWA is implemented via JavaScript, but the URL should still display the current language. Ensure that language versions are also accessible without JavaScript – for example, through server-side rendering – so that search engines can crawl the content. Test the multilingualism of your PWA in the Lighthouse audit to identify errors in hreflang implementation or the manifest.

**Future Developments** The importance of AI-powered localization and automatic translation will increase. However, do not blindly rely on machine translations for your URL slugs, as they often appear unnatural or produce incorrect character encodings. In practice, a combination of AI translation and human quality control has proven effective – even for paths. Another trend is the increasing personalization of content: URLs could be dynamically adapted to the user's language without changing the structure. It will then be crucial that hreflang tags and internal linking continue to work correctly. Therefore, keep your URL strategy flexible and document all technical dependencies to be able to respond to new requirements. For legal implications of new technologies – such as using geolocation for language control – consult a legal advisor.

Common Pitfalls and How to Avoid Them

When setting up multilingual URLs, typical errors often occur that can negatively impact findability and user experience. A common pitfall is the inconsistent use of language codes: for example, some pages combine '/en/' with '/de/', while others use '/englisch/' or '/english/'. This leads to confusion for search engines and users. Consistency is crucial—use ISO 639-1 codes consistently (e.g., '/en/', '/de/', '/fr/') and avoid exceptions without good reason. Another error is the incorrect placement of the language indicator: in subdirectory structures, the language identifier should come directly after the domain (e.g., 'domain.de/de/produkt'), not after a category. Otherwise, crawlers may interpret the structure differently. Ignoring special characters in slugs can also be problematic: while it is advisable to retain umlauts and accents (e.g., 'straße' instead of 'strasse'), you must ensure that your CMS and server correctly process and encode these characters (UTF-8). Otherwise, unreadable percent encodings or error pages may occur. A classic SEO mistake is the absence of hreflang tags or their incorrect implementation. Without hreflang, you do not clearly signal to search engines which version is intended for which language/region—the risk of duplicate content assessments increases. Therefore, after launch, be sure to check that hreflang is set on all relevant pages and that the URLs are correctly referenced. Also, forgetting 301 redirects during URL changes can lead to ranking losses. Plan a migration phase and redirect all old URLs to the new ones. Additionally, note that language versions must be listed separately in the sitemap—a single sitemap with different language variants in one URL is not sufficient. A final point concerns user guidance: if you use automatic redirects based on browser locale, ensure that the user can switch languages at any time without a new redirect occurring. Have these pitfalls checked by an experienced tester before launch. For complex projects, separate legal advice is recommended to delineate trademark rights in different countries.

Budget and Effort: Realistic Planning for Localizing Your URLs

Localizing URLs is not a one-time process but an ongoing one that is often underestimated in practice. Realistic budget planning should consider several cost blocks: initial implementation, ongoing maintenance, and quality assurance. Initial costs include analyzing the existing URL structure, defining conventions for each language, and technical implementation (CMS adjustments, routing, rewrite rules). Depending on project size, a team of developers, SEO specialists, and translators may be required. In practice, coordination rounds between departments alone can take several weeks. Additional costs arise for slug translation: each URL segment must be translated or localized by a native speaker, with length and readability controlled. Expect an effort of 30 to 60 minutes per 100 URLs per language—for 20 languages and 500 product pages, this quickly amounts to 50 to 100 hours of translation work. Plus technical implementation: do you need to define rewrite rules for each path? Use a URL mapping tool? Cloud-based solutions or specialized middleware can help but incur licensing costs. Do not forget ongoing maintenance: new content requires new slug translations, old URLs must be redirected during restructuring. Therefore, plan a monthly budget for URL maintenance—in practice, about 10–15% of the initial effort. Quality assurance is another item: after launch, you should spot-check each language version to ensure URLs resolve correctly, no broken links occur, and hreflang tags are correct. Automated tools can help, but human oversight remains indispensable. For companies without internal resources, partnering with a specialized agency is worthwhile. When requesting quotes, look for transparent pricing structures—some providers charge by language count, others by URL volume. Ask for a detailed project plan with milestones. Also consider follow-up costs from adjustments after a relaunch or CMS change. A realistic timeline for fully localizing the URLs of a medium-sized shop (about 1,000 pages, 5 languages) is three to six months. A corresponding budget can range from €5,000 to €20,000 depending on complexity, automation level, and custom development needed. Seek legal advice on country-specific regulations if your URLs contain trademark-protected terms.