Imagine pressing the language button on a Turkish service page and landing on the English home page. The menu has changed, but you have to find the service you were reading about all over again. On a multilingual site, the problem is sometimes not translation quality at all: it is that the relationship between the two pages was never established.
Multilingual SEO treats URL structure, the signals you give search engines and the path the user follows as one problem. Adding a few tags does not complete missing content. Equally, a flawless translation does not fix an incorrect URL mapping on its own.
This guide works through a hypothetical site with Turkish and English service pages. The example.com addresses in the code samples are illustrative only; they do not represent a structure implemented or published for WebWizz.
Build a content inventory before you pick a language list
Bring the request “let's make the site English” down to page level. Are the home page, services, products, contact, form results and downloadable documents all in scope? Are there older blog posts that will not be translated? Every piece of content needs a named owner and a clear state of readiness.
A simple spreadsheet can hold the content ID, the Turkish address, the English address, the content owner and the review date. Managing that table with a content ID independent of the URL text prevents the language relationship from being lost when a title changes.
For example, a service can keep its English name rewritten and still belong to the same service group. Conversely, do not automatically pair a different service offered in only one country just because the titles look similar. The matching decision should rest on what the page actually offers, not on word similarity.
Choose an accessible, stable address for each language
Google recommends using separate URLs for language versions. Options such as subdirectories or subdomains exist; weigh your current infrastructure and management overhead when choosing. Rather than force-redirecting users based on a guessed language, give them clear links to reach the other versions. Google Search Central: Multi-regional and multilingual sites.
In the example project, /tr/hizmetler could serve the Turkish services page and /en/services the English one. But do not change a working URL structure without thought purely to support a second language. Changing addresses creates a separate migration job covering old links, menus and analytics reporting.
The language switcher should preserve page context
When a user reading a Turkish service selects English, they should arrive at the equivalent of that same service. If there is no equivalent, say so plainly. Pointing every missing translation at the home page breaks the user's expectation and hides the gap in your content inventory.
Consider making the language switcher legible with language names rather than flags alone. The same language can be used in several countries; keeping language and region as separate concepts in your product and content decisions makes later expansion easier.
Hreflang lets equivalents recognise each other
Hreflang relates language or regional variants. Google's guidance asks for absolute addresses, for each version to list itself, and for the links to be reciprocal. You can choose whichever method suits you — HTML, HTTP header or sitemap; using all three together brings no additional search benefit. Google Search Central: Localized versions.
The two alternate lines below define the same pairing in the HTML head of both service pages:
<link rel="alternate" hreflang="tr" href="https://example.com/tr/hizmetler">
<link rel="alternate" hreflang="en" href="https://example.com/en/services">
If you do not need a country distinction, you can start with the language code as shown. If you use a welcome or language-selection page for languages you do not target, x-default can be considered separately; that signal does not replace translating the content.
A useful approach for the technical team is to generate these tags from the published equivalents in the content group rather than writing them by hand on every page. That way, when an English page's address changes, there is far less need to update every relationship separately in different places.
Do not confuse canonical with the language relationship
Hreflang says “this content has an equivalent in another language”, while canonical signals the preferred address for identical or very similar content. Google states that when hreflang is used, the canonical should where possible point within the same language. Canonical is a signal, not an absolute guarantee of the search engine's choice. Google Search Central: Consolidate duplicate URLs.
In our example, two service pages that are full translations of one another, independent and intended for indexing, can each point their canonical at their own address. On the Turkish page:
<link rel="canonical" href="https://example.com/tr/hizmetler">
And on its English counterpart:
<link rel="canonical" href="https://example.com/en/services">
Do not copy this example across all sites without thinking. Where there are parameterised duplicates, regional near-duplicates in the same language or other duplication problems, preferred URLs have to be designed separately. Write down first which page you want to stand as an independent result and why; set the tags after that decision.
Carry the translation all the way through the conversion flow
However good the English service page is, the experience stays half-finished if the error messages in the quote form remain in Turkish. The team has to check not just the body copy but the buttons, the form help text, the submission result and the related email templates.
For our hypothetical service page, run the same scenario in both languages: find the service, understand its scope, send a question, see the acknowledgement. Note at each stage the questions the content owner needs to answer. “Which regions is this service offered in?” is not a detail a translator should fill in by guessing.
Write titles and descriptions in natural phrasing for the target language. Rather than preserving the word order of the source, answer the target user's question. If you use local examples, verify them; do not invent an office, a client or a service area that does not exist.
Updates need a named owner
Set up a workflow that triggers a review of the English version whenever the Turkish service scope changes. A “translation out of date” state for a content group is far more manageable than old text being quietly forgotten.
After the first launch you can pick a regular sample: one service, one product, one blog post and one form. Retesting the language switches and links on those samples helps you notice the effect of template changes early.
Pre-launch implementation checklist
- Record each page's language, content owner and equivalent.
- Try the language switcher on key pages the way a user would.
- Do not use unpublished draft addresses in language mappings.
- Check hreflang relationships are reciprocal and use absolute URLs.
- Verify canonical decisions alongside your language and duplicate-content structure.
- Review the accessibility and indexing settings of the target pages.
- Complete forms, error messages and result screens in every language.
- Prepare a migration plan for old links whenever URLs change.
- After launch, track page and enquiry data separately per language.
If you are planning a multilingual site with WebWizz, you can share your target languages and the list of pages to be translated through our contact page. That way the scope is defined by completed user journeys, not just by a count of translations.
Frequently asked questions
Does adding hreflang guarantee a ranking increase?
No. Explaining language equivalents is not a guarantee that changes how useful your content is or what the competition looks like. Track success against your own goals, such as reaching the right page and receiving qualified enquiries.
Should we map an untranslated blog post to another language's home page?
Do not create such a mapping if it does not represent an equivalent-content relationship. Keep the missing translation visible in your inventory and show the user clearly which options exist.
Can an English page's canonical point to the Turkish page?
In our example of fully translated pages intended to appear independently, do not start by consolidating languages onto a single address. Evaluate the canonical decision separately for same-language duplicates and special cases.
Do we have to translate every blog post at once?
No. You can start with a scope that completes your service and enquiry flows. What matters is knowing which equivalents are genuinely ready, and adding later translations consistently into the existing structure.