How to Plan a Multilingual Website: URLs, Content and Language Switching

A multilingual website is more than a translated copy of existing pages placed behind a second navigation menu. A dependable setup needs a separate, readable URL for each language, explicitly linked counterpart pages, clear ownership of localisation and updates, a defined rule for missing translations, and two-way checks before publication.

Plan the project around five questions:

1. Which markets, countries and users are you serving?
2. Which pages will be available in each language?
3. How will equivalent language versions be connected?
4. Who owns translation, localisation, updates and approval?
5. How will language relationships be checked for both users and search engines?

When these decisions are documented before development, URL design, content production, language switching and international SEO stop becoming separate problems that different teams attempt to repair at the end. They become parts of one manageable publishing system.

Decide Whether the Business Actually Needs a Multilingual Website

The ability to publish a few paragraphs in another language is not, by itself, a reason to invest in a multilingual site. Start with the commercial objective and the organisation's ability to serve users in that language.

At Kumsal Ajans, we primarily recommend multilingual websites for:

• Businesses that export products or services
• Companies preparing to enter international markets
• Organisations operating in more than one country
• Businesses that regularly handle sales or service enquiries from international customers

Answer the following questions for every proposed language:

• Which market or audience will this language serve?
• Which products or services are genuinely available in that market?
• Can sales, support and operations continue in the user's language after an enquiry?
• Which pages are required for the initial launch, and which can be added later?
• Is there a named owner and a budget for keeping the content current?

This exercise turns “we should add English” into a defined project scope. To place language requirements alongside the rest of the business and technical needs, begin with the audience, page, content and integration questions in our website requirements document guide.

Build a Language and Page Scope Matrix First

Not every Turkish page has to receive an English counterpart on the first day. The team does, however, need to know whether each counterpart is ready, planned or intentionally outside the scope. Create a language-page matrix before design and development begin.

This is more than a URL inventory. It brings content production, technical mapping and publication decisions into the same row. Instead of asking only whether an English page exists, the team can ask whether it is current, approved and connected to the right source page.

Review how the multilingual scope is described in supplier proposals as well. “Two-language support” does not necessarily include copywriting, translation, content entry, professional language review or later updates. Treat these as separate responsibilities when you compare website proposals.

Give Every Language Version Its Own Readable URL

The Turkish and English versions of a page should have separate URLs that can be opened directly. Changing the body copy at one address solely according to a cookie, browser language or session can make each version more difficult to share, crawl and manage independently.

Google's guidance for multilingual and multi-regional sites recommends using a different URL for each language version and providing visible links so that users can select another version. It also warns that forced redirection based on an assumed language can prevent users and crawlers from reaching every variation.

For example:

• Turkish: example.com/hizmetler/web-tasarim
• English: example.com/en/services/web-design

Use language that is natural to the intended reader instead of carrying Turkish words into an English slug. Apply the same standard consistently to service, product, category and article paths. Google permits localised words in URLs; the important operational qualities are that the URL is stable, accessible and accurately represents its page.

Kumsal Ajans prepares slugs independently for each language. We favour lowercase words, hyphens and the removal of terms that add no meaning. This is not a ranking guarantee. It is a publishing standard that helps users and content owners understand what an address represents.

Treat a Slug Change as a Permanent Move When It Is Permanent

When the slug of an existing page changes, external links, bookmarks and search results may continue to use the old address. A permanent move therefore needs a route from the old URL to the closest relevant new page.

Google's redirect documentation defines 301 and 308 as permanent redirects and recommends a server-side permanent redirect where possible for a permanent URL change. A temporary situation should not be labelled as a permanent move.

Use these practical rules:

• Redirect an old Turkish URL to the relevant new Turkish page.
• Redirect an old English URL to the relevant new English page.
• Do not send a large set of unrelated old URLs to the homepage.
• Do not implement the language selector as a 301 redirect. It should be a normal link to the connected equivalent page.
• Test that the target opens in one step and does not create a loop.

These are two different operations: a 301 points a permanently moved URL to its new location, while the visible language control takes a user to an equivalent page in the language they chose.

Manage Turkish and English Pages as Connected Counterparts

The centre of a multilingual website should not be two disconnected sets of pages. It should be a set of explicit relationships between equivalent pages. A Turkish service page and its English version should not be assumed to match only because their titles look similar. They should be registered as language counterparts in the content workflow.

In the project-specific content management platforms configured by Kumsal Ajans, Turkish and English content is not created as unrelated records. The language versions are connected, and switching is checked in both directions. If that relationship is missing, a user may move from a Turkish page to the wrong English destination or lose the page context entirely.

Record the following for every linked pair:

• Turkish public URL
• English public URL
• Content owner
• Translation and final-review status
• Date of the latest material update
• Result of the language switch in both directions
• Result of the technical language mapping check

Use this approach for service, product, team, contact, campaign and legal pages as well as articles.

Do Not Send Users to an Unrelated Page When a Translation Is Missing

If a Turkish page does not yet have an English version, sending the visitor to the English homepage or to a vaguely similar page breaks the meaning of the language selection. The user expects the same information in another language, not a new starting point.

At Kumsal Ajans, we prefer to hide the language option temporarily on a page whose counterpart is not ready. Once the localised page has been approved, the control can become visible and the two versions can be connected.

Both content and technical teams should use the same status model:

• Ready: Content is approved, the URL is public and two-way switching works.
• In review: Translation or client approval is pending; the language option remains disabled.
• Update required: The source has changed and the localised version must be reviewed.
• Out of scope: No counterpart is planned; no language option is shown for that page.

Hiding an unavailable destination must not mean forgetting it. Keep the status in the content inventory so that it remains visible in the publication plan.

A Visible Language Switch and Hreflang Are Not the Same Thing

People use the language control displayed on the page. Search engines use technical annotations to interpret relationships between localised URLs. These layers complement each other; neither replaces the other.

According to Google's documentation for localised page versions, each version in an hreflang set should list itself and its counterparts. When two pages do not point back to one another, the annotations may be ignored. Adding the English address only to the Turkish page is therefore not sufficient; the English version must also identify the Turkish counterpart.

Check a Turkish-English page pair in this order:

1. Can both URLs be opened directly and crawled?
2. Does each page keep its visible content and navigation in one language?
3. Does each page use the intended same-language URL as its canonical?
4. Does each page list itself and the real counterpart with the correct hreflang value?
5. If the XML sitemap carries language relationships, does it use the same live URLs?
6. Does the visible language control open the correct counterpart?

Do not confuse canonical and hreflang. Canonical identifies the preferred URL for a page, while hreflang describes language or regional alternatives. Google's canonical guidance recommends a canonical in the same language when hreflang is used and supports a self-referencing canonical on the preferred page.

Correct implementation does not guarantee indexing or rankings. It does, however, establish a consistent technical relationship and reduces avoidable errors involving disconnected pages or conflicting URLs.

Define Localisation and Approval, Not Translation Alone

Replacing the words in one language with words in another does not necessarily make a page suitable for its target market. Service names, calls to action, currencies, delivery terms, dates, legal wording and contact expectations may need adaptation.

In Kumsal Ajans projects, the client supplies the main Turkish content or develops it with us. The English version is localised with professional translation support. The client completes the final language and content review before publication.

Define these responsibilities in the project plan:

Machine translation or automation can assist the process, but it cannot independently confirm a company's service conditions, legal statements or market-specific meaning. Human language review and client approval remain important, particularly for specialist material.

Review Navigation, Forms, Emails, Images and Legal Copy by Language

A multilingual website is not limited to the main page body. An English page may still display a Turkish validation message, automated email or text embedded in an image. Treat shared components as separate items in the localisation checklist.

Navigation

• Are the menu, categories and breadcrumbs in the correct language?
• Do their links remain within the current language where appropriate?
• Do search results and the 404 page preserve the language context?

Forms and automated email

• Are field labels, instructions and validation messages localised?
• Do the confirmation message and customer email continue in the selected language?
• Can the internal recipient identify the language and source page of the enquiry?

Images and documents

• If an image contains words, is the correct language version being displayed?
• Are alternative text, titles and captions written in the page language?
• Is a downloadable catalogue or PDF current for the intended market?

Legal and commercial information

• Have privacy, cookie, consent and terms pages been approved for their intended use?
• Are prices, currencies, taxes, delivery conditions and regional service boundaries accurate?
• Can the business handle enquiries through the contact channel offered on that page?

Translating a legal document does not automatically make it suitable for another jurisdiction. Where necessary, plan appropriate specialist review for the target country and business model.

Do Not Forget Other Languages When the Source Content Changes

One of the most common operational risks on a multilingual site is that the source language is updated while its counterparts remain unchanged. Outdated information about pricing, service scope, staff, addresses, certifications, contracts or product features can mislead visitors.

In the Kumsal Ajans workflow, when Turkish content changes, other language versions are reviewed through the content inventory and project tracking system. Missing or outdated translations are flagged.

Record one of the following decisions for every material update:

• The localised version is not affected.
• A small update is required in the other language.
• Professional re-localisation is required.
• Legal or technical specialist review is required.
• The language option should be hidden temporarily until the counterpart is updated.

This does not require every language to be published at the same minute. It requires the difference to be visible to the team so that old content is not mistakenly treated as current.

An Anonymised Example of Incorrect Language Routing

During the review of a corporate website, changing the language on an internal page took the user to a different page rather than to the correct localised counterpart. The English page existed, but the page relationship had been configured incorrectly.

The issue was resolved through the following steps:

1. The Turkish and English page inventories were compared.
2. Correct counterparts were reconnected in the content workflow.
3. The targets used by the visible language control were corrected in both directions.
4. Where old URLs had permanently changed, the relevant one-to-one 301 redirects were reviewed.
5. Turkish-to-English and English-to-Turkish journeys were tested again.

This example does not claim an increase in traffic, rankings or conversions. It illustrates a narrower point: the existence of an English page is not enough. The user control, content relationship and technical language mapping must all point to the same counterpart.

Pre-Publication Multilingual Website Checklist

Apply the following checklist to each important page template before launch:

Assess whether an off-the-shelf platform can support this workflow at the beginning of the project. If connected content, specialised roles or external integrations become central requirements, our off-the-shelf platform and custom web software comparison can help frame the platform decision.

Conclusion: Manage Languages as One Connected System

The quality of a multilingual website is not measured by the number of language options in its menu. The important questions are whether users reach the correct counterpart, whether each version has a stable and readable URL, whether the content remains current, and whether all shared components continue to work in the selected language.

Define the target markets and page scope. Create separate URLs. Connect counterparts explicitly. Hide options whose content is not ready. Assign localisation and approval responsibilities. Test the visible switch and hreflang relationship separately. Apply appropriate redirects to permanent slug changes and place future updates in the content workflow.

This approach turns multilingual delivery from a one-off translation exercise into a publishing system that can develop with the organisation. To plan language, content, technical structure and management needs together, explore Kumsal Ajans web design services.

Frequently Asked Questions

Does every language version need a separate URL?

Providing every language version at a separate, directly accessible URL makes it easier for users to share the page and for crawlers to access each variation. Prefer separate language URLs and visible language links over changing the content at one address solely according to browser settings.

Should a page without an English counterpart send users to the English homepage?

Under the Kumsal Ajans approach, users are not sent to an unrelated page. If the counterpart is not ready, the language option is hidden temporarily on that page. It becomes visible after the localised page has been approved, connected and checked.

Do Turkish and English pages have to use the same slug?

No. Each language can use a natural, descriptive slug. The English URL should use wording that makes sense to its intended audience. If a published slug is changed permanently, redirect the old URL to the relevant new page.

Does hreflang replace the visible language switch?

No. hreflang describes relationships between localised URLs to search engines. The visible language control enables people to move to the counterpart they choose. Both need to be tested independently and in both directions.

Should a site automatically redirect visitors according to browser language?

A forced redirect based on an assumed language can make other versions harder to access. A site may suggest an appropriate language, but users should retain a visible way to choose, and every supported version should remain available at its own URL.

Must the English page be published immediately whenever Turkish content changes?

Not every update has to go live at the same moment. The team should, however, record whether the English counterpart is affected and assign an owner and status when an update is required. If stale content could mislead users, the language option can be hidden temporarily until the counterpart is current.