Bilingual SEO: one site, two languages, no penalty
Arabic and English on one site is not duplicate content — if URLs, hreflang and redirects are right. The setup that works and the mistakes that hide traffic.
The most common worry about a bilingual site is that Google will treat two languages as duplicate content and punish it. That is not how it works. Two translations of a page are not duplicates — they are alternates, and search engines have explicit machinery for exactly this situation.
What does cause real damage is a bilingual site assembled without that machinery: one language invisible to search, both languages competing for the same query, or visitors bounced into a language they cannot read. All four of those are avoidable with decisions made before anyone writes content.
Pick a URL structure and never change it
Three options are common. One is clearly best for most businesses:
| Structure | Verdict |
|---|---|
/ar/page and /en/page — subfolders | Recommended. One domain, one accumulated authority, trivial to host and to certify, and the language is obvious to a human reading the link. |
ar.example.com — subdomains | Workable, but you are asking search engines to build reputation for two properties instead of one. |
?lang=ar — query parameters | Avoid. Fragile to crawl, ugly to share, and easy to serve inconsistently. |
Whichever you choose, every page must exist at a stable address in each language. A language that only appears after clicking a toggle — with no distinct URL — cannot be indexed, linked or shared. It is invisible to everyone except the person clicking.
hreflang is how you avoid competing with yourself
Without it, your Arabic and English pages about the same service look like two candidates for the same query, and the search engine picks one — often the wrong one for that user. With it, you are telling it plainly: same content, different language, serve the right one.
Three rules people get wrong:
- Annotations must be reciprocal. If the English page lists the Arabic alternate, the Arabic page must list the English one — and both should list themselves. One-way declarations are ignored.
- Use absolute URLs. Relative paths in hreflang are a silent failure.
- Include x-default. Point it at whatever you serve to someone whose language you do not know — for us, the bare path that performs the language selection.
Then let each page canonicalise to itself. A frequent and expensive mistake is pointing the Arabic page's canonical at the English one, which tells the search engine that the Arabic version should not be indexed at all.
Never redirect by IP address, and never redirect permanently
Geography is not language. An Iraqi engineer who prefers English, a visitor on a foreign SIM, and a crawler in another country are all mislabelled by IP-based redirection. Worse, a permanent redirect from the bare URL to one language can leave the other language effectively unreachable for search engines.
The behaviour that works: read a language cookie if one exists, fall back to the browser's stated language preference, then to a sensible default — and make it a temporary redirect, never a permanent one. Always show a visible language switch, and remember the choice, because the visitor's own decision must outrank your guess forever after.
Our own site does exactly this: a bare path sends you to Arabic or English based on your cookie then your browser, as a temporary redirect, with both language versions permanently addressable and declared as alternates of each other.
Translate the metadata, not just the paragraphs
The most common half-finished bilingual site has translated body text and English titles and descriptions on every Arabic page. Those two fields are what appears in search results, so an Arabic-language searcher sees an English result and scrolls past it.
The full list to translate per page: title, meta description, headings, image alt text, button labels, form field labels and error messages, the structured data description, and the share-card text. Set the page's language attribute and text direction per language too — that is the signal that makes browsers, screen readers and search engines all treat the page correctly.
Arabic keywords are not translated English keywords
Translating your English keyword list and stopping is how you end up ranking for phrases nobody types.
- Real searches arrive without diacritics, with alef variants used interchangeably, and with ه and ة swapped. Your content and your on-site search should tolerate all of it.
- Many Iraqi searches mix scripts: an Arabic sentence containing an English brand or product name. Both forms need to appear naturally somewhere on the page.
- Dialect words often beat formal ones in volume. The formal term may be what you would print; the dialect term may be what people search.
- Some categories are searched almost entirely in English even by Arabic speakers — much of IT is like this. Do not force a translation where the market does not use one.
Keep one language per page
A page that mixes both languages ranks for neither. It gives search engines an ambiguous signal and gives readers a page half of which they skip. Cross-link the two versions instead, prominently, and keep each page monolingual — with the obvious exception of proper nouns and technical terms that genuinely have no local equivalent.
Measure the two languages separately
An overall traffic figure hides the finding that matters. Look at arrivals, entry pages and enquiries per language and you often discover that one language brings most of the visits while the other brings most of the business — which changes where the next piece of content should go. That is a five-minute check in any decent analytics setup, and it belongs in the weekly numbers you already look at.
The launch checklist
- Every page exists at a stable URL in both languages
- Reciprocal hreflang annotations, absolute URLs, plus x-default
- Each page canonical to itself
- Language and direction attributes set per page
- Temporary — never permanent — language redirects, with a visible switch that is remembered
- Titles, descriptions, alt text and structured data translated
- Both languages in the sitemap, with alternates declared
- Arabic keyword research done natively, not translated
- Traffic and conversions reported per language
None of this is exotic, and all of it is cheaper to do at build time than to retrofit. It is also the visible half of a deeper discipline — the invisible half being layout, typography and the hundred details covered in true RTL is not a checkbox.
We build every site this way, in both languages from the first draft rather than translating one into the other afterwards — because a site that was designed in Arabic reads like it belongs to the business, and a site that was translated into Arabic always reads like a translation.