How to Structure Your Website URLs for International SEO in 2026

Are you preparing to create or redesign your website in 2026? Don’t overlook one crucial element: URL structure. A clear, optimised URL forms a solid foundation for both Google and your users, particularly when it comes to international SEO.

Unfortunately, we often encounter the same issue: poorly designed URLs that harm visibility, indexing efficiency, and ultimately, business performance. In this article, we outline best practices, common mistakes, and, most importantly, how to structure your URLs for optimal results.

Create a User-Focused URL

A good URL should, above all, convey clear and understandable information. Google primarily requires a readable and stable format. The structure should allow the topic of the page to be immediately identifiable, without keyword stuffing or unnecessary elements.

The aim is not to form a complete sentence, but to provide a clear reference point. Many companies overcomplicate their URLs by including irrelevant information, which can create indexing difficulties.

When redesigning a website or planning a new one, this rule should be applied from the very start of the project.

Structuring URLs for International Markets

International versions are often the most poorly managed. Many websites attempt to expand their visibility abroad simply by creating subdirectories such as mysite.fr/es or mysite.fr/it.

From an SEO perspective, this structure sends a clear signal: the site is primarily domestic, even if some content is translated. It also severely limits visibility in local search results because the domain authority does not match the target market.

To gain relevance in markets outside your home country, websites should adopt an appropriate structure, such as a .com organised by international directories (mysite.com/es, mysite.com/it) or, where strategically relevant, country-specific domains (mysite.es, mysite.it). This technical choice should be supported by native content, local trust signals, a backlink profile in the target country, and a dedicated SEO strategy.

Also read our article on how to be visible on Google in multiple European countries! 

Many companies assume that simply changing the URL is enough to succeed internationally. This is not entirely the case. A coherent, structured, and localised approach is required to achieve genuine competitive visibility. This is exactly where Mintense can help: we guide you in selecting the right URLs and building a robust international URL structure integrated into a comprehensive multilingual SEO strategy.

Why URL Structure Requires Expert Guidance

A poorly designed URL structure can impact your entire site: lost rankings, indexing drops, unintended duplications, and misinterpreted hierarchy, the list goes on. When a company plans a website creation or redesign, or wants to improve performance across multiple countries, expert guidance becomes essential.

At Mintense, an international SEO agency with offices in London, Paris and Italy, we assist businesses in designing, redesigning, and optimising their URL structures, both domestically and internationally. We manage complex projects including technical restructuring, SEO migrations, international expansion, website redesigns, implementing multilingual strategies, and full audits of existing URLs.

Our approach is based on a simple principle: a URL must be readable, logical, and aligned with the overall website strategy. It is this coherence that sustainably improves organic visibility and strengthens positioning in each target market.

Whether you want to work with us or simply have a question, please do not hesitate to get in touch, we will respond as promptly as possible.

Country code, language code, or both in the path?

Once you have settled on a single domain organised by directories, the next decision is what those directories are called, and it trips up more projects than the domain choice itself. A path segment can carry a language, a country, or a pairing of the two, and the three say different things. A segment like /es/ says this content is in Spanish. A segment like /mx/ says this content is for Mexico. A segment like /es-mx/ says both at once, and is the only one of the three that answers the question a search engine actually asks when it has to choose between two Spanish pages.

Pick the shape that matches how you sell. If you serve one country per language, a plain language code is enough and keeps the address short. If you serve several countries that share a language, Spain and Mexico, Germany and Austria, the UK and Ireland, you need the country in the path as well, or you will end up with one page trying to rank in markets whose prices, delivery terms and legal notices differ. Use the standard two letter codes, lower case, and resist inventing your own. A visitor who sees /uk/ understands it instantly; a visitor who sees /gb-en-2/ has learnt nothing and neither has a crawler.

One case deserves a rule of its own: a site that exists in one language only should not sit under a language folder at all. Putting an English only site at /en/ adds a redirect, splits the home page from the root and buys nothing, because there is no second language for the segment to distinguish it from. Add the folder on the day you add the second language, not before.

Do you translate the slug as well as the page?

A translated page with an untranslated address is a job left half finished. If the German version of your industrial pumps page lives at /de/industrial-pumps/, the words a German buyer types are nowhere in the URL, the breadcrumb reads in English, and every link anyone builds to that page carries English anchor text into a German result. Translate the slug, so the address becomes /de/industriepumpen/, and every one of those signals starts pointing the same way.

Translate it properly, though, which is not the same as translating it literally. The right slug is the phrase buyers actually search in that market, and it is often not the dictionary translation of your English one. This is the same research that decides your headings and your ad copy, so do it once and reuse it. Where a market uses a loanword, keep the loanword: forcing a native coinage that nobody types is worse than leaving the English in place.

Non Latin scripts need one extra decision. Modern browsers and Google both handle Cyrillic, Greek, Arabic and Chinese characters in a URL, and readers in those markets find them far more legible than a transliteration. The catch is that the address gets encoded into percent signs the moment it is copied into an email or a spreadsheet, which looks alarming to anyone reviewing a report. Either accept that and use the native script, or transliterate consistently across the whole market. What you must not do is mix the two inside one site.

Your URLs and your hreflang have to tell the same story

The URL structure decides what hreflang can do. Each language and country combination needs exactly one address, that address has to return a 200, and the set of alternates on every page in the group has to list every member of the group including itself. Break any one of those and the annotation is quietly discarded, which is why so many teams report that hreflang did nothing for them. It usually did nothing because it was never valid.

Three faults account for most of it. The first is pointing an alternate at a URL that redirects, which happens the moment someone tidies trailing slashes on one market and not another. The second is a missing return link, where the Spanish page names the German one but the German page names only itself, so the pair is never confirmed. The third is a group where two markets claim the same country code, which forces the engine to pick one and ignore the other.

Add x-default and point it at the page you want an unmatched visitor to land on, usually your main international version rather than a redirect script. If you are tempted to detect a visitor's location and bounce them automatically, resist it: an automatic redirect stops a crawler from ever reaching the other versions, and it strands a buyer who deliberately wanted to read your English page. Offer the switch, and let the reader take it.

Changing an international URL structure without losing what it earned

Restructuring is the point at which a good plan destroys a year of rankings, and it is entirely avoidable. Start with a full list of the addresses you have now, taken from your sitemap, your analytics and your server logs together, because each of the three knows about pages the others have forgotten. Map every one of them to its new address by hand. A rule that rewrites paths in bulk will get the top of the site right and quietly send the long tail to a category page, which is where the traffic you cannot afford to lose actually lives.

Then move once. Each old address should redirect straight to its final destination with a 301, never through a chain of two or three hops picked up from earlier migrations. Update your internal links to the new addresses in the same release, so the site itself stops pointing at the redirects, and regenerate the sitemap so it lists only the new set. Leave the redirects in place permanently. They cost nothing and they keep the links other people built to you working.

Expect a dip and plan for it. Rankings usually wobble for two to six weeks while the new addresses are recrawled, and the market with the least crawl budget recovers last. Watch coverage and impressions per market rather than a site wide total, which will hide a single country falling off a cliff. If one market has not recovered after two months, the problem is almost always a mapping error or a redirect chain, not patience.

FAQ, international URL structure

Country domains or one domain with folders: which should we choose?

Folders on a single domain suit most companies, because every market inherits the authority the whole site has built and there is one estate to maintain. Country domains earn their extra cost when you have a genuine local presence, separate legal entities or a team in the market able to build links there. The deciding question is rarely technical. It is whether you have the resources to run several sites properly rather than one site well.

Should the language code go in the folder, the subdomain or a parameter?

Use a folder. Subdomains are treated as separate properties and start further back, which means every market builds authority from scratch. Parameters are worse still, because the same page can be reached with and without them and you invite duplication. A folder keeps every market on one domain, makes the structure legible to a visitor reading the address, and lets you add a market later without touching anything that already ranks.

Do we need to translate the words inside the URL?

Yes, wherever the page itself is translated. An address in English on a German page leaves the words your buyers type out of the URL, out of your breadcrumbs and out of the anchor text anyone uses when linking to you. Use the phrase people in that market actually search rather than a literal translation, and keep loanwords when the market uses them. Retrofitting this later means a migration, so do it when the page is first published.

What breaks most often when a site adds new markets?

Alternates pointing at addresses that redirect, and groups where the return link is missing on one side. Both stop hreflang from being applied at all, which is why teams so often conclude it does nothing. Duplicate country codes inside one group are the third common fault. Check the whole set after every release, because a change to trailing slashes or to a single market's paths is enough to invalidate annotations across every language.

How long does a URL migration take to settle?

Two to six weeks for most sites, longer for the markets that are crawled least often. Watch impressions and coverage market by market rather than as a site total, which will hide one country falling away while the others recover. If a market has still not returned after two months, look for a mapping mistake or a chain of redirects rather than waiting. Patience is not the fix when the problem is structural.