INFORMATION ARCHITECTURE

A site structure built around how your visitors think, not how your business is organised

Websites in the UAE often need to serve two distinct audiences: Arabic-speaking visitors who read right to left and English-speaking visitors who read left to right. That is not a translation problem. It is a structural problem. The sitemap, navigation hierarchy, content groupings, and user journeys need to be considered separately for each language stream, then unified into a coherent architecture that works for both. We build that structure before design or development begins.

Request your IA Diagnostic View the evidence

We are proudly featured on

Trusted by businesses we have shipped growth for

/ This is for you if

Information architecture work is right for you if any of the following describes your situation.

Your navigation labels reflect how your company is structured, not how your customers search or think. This is true in both your Arabic and English versions. Internally meaningful terms appear in the menu. Visitors, whether arriving in Arabic or English, cannot determine where to go from the home page without already knowing what they are looking for.

The Arabic version of the site was created by translating the English version page by page. The content hierarchy, navigation structure, and page groupings were carried over unchanged. The result is an Arabic site that reads right to left but is structured for a left-to-right audience, with content priorities and journey flows that do not match how Arabic-speaking visitors in the UAE actually navigate and decide. A translated structure is not an Arabic structure.

A new site is scoped. Design is about to begin. The brief mentions both Arabic and English versions but treats them as a translation requirement rather than an architecture requirement. If the sitemap is built once and then translated, the structural problems of the English version carry over into Arabic. IA work done before design begins means both language streams are built on a structure that serves each audience separately.

/ What's broken

These are the four structural problems we find most consistently on UAE business websites.

Navigation labels that make sense internally but confuse visitors

In both Arabic and English versions, menus use internal terminology. English menus surface division names from the corporate hierarchy. Arabic menus translate those same labels rather than rewriting them for how Arabic-speaking visitors describe what they need. The problem is compounded when the translation is literal rather than contextual, producing Arabic labels that are grammatically correct but not how anyone would search for that service.

No clear path from landing page to enquiry or purchase

Visitors arrive on a page, read it, and find no obvious next step. In both language versions, the path from informational content to a contact form, a quote request, or a product enquiry is either missing or buried. For businesses in the UAE where conversion happens through a human touchpoint (a phone call, a WhatsApp message, a meeting request), the structural gap between information and contact is where most of the site's traffic is lost.

Duplicate pages on the same topic with no internal linking

The site has multiple pages covering the same service or product, created at different times, in both Arabic and English, with no cross-referencing or internal linking strategy. Search engines cannot determine which page is authoritative. Visitors who find one version of a page never discover related content. This is a structural problem that requires sitemap decisions, not more content.

A URL structure that resets with every site rebuild

Platform migrations in the region frequently discard previous URL structures entirely. Rankings earned over previous years are lost. Backlinks stop resolving. A URL architecture set before the build begins, designed to be stable across future changes and to handle both Arabic and English URL paths correctly, protects the search equity the site has already built.

/ What we engineer

An information architecture engagement in the UAE covers seven deliverables, each designed to address both language streams.

Discovery Workshop

A structured session with your team covering your Arabic-speaking and English-speaking audience segments, their different entry points, decision-making behaviours, and conversion paths. This session establishes separate audience profiles for each language stream before any structural decisions are made.

Content Audit (Existing Sites)

A full inventory of every page in both language versions: what exists, what is duplicate, what is machine-translated rather than structured for its audience, what is orphaned, and what should be consolidated, redirected, or rebuilt. For bilingual sites, the audit often reveals that the Arabic version is structurally different from the English version in unintended ways.

User Journey Mapping

We map the paths each audience segment takes through the site, separately for Arabic and English visitors. Entry points, question sequences, and conversion paths often differ significantly between the two. Journey maps for both streams inform the structural decisions that follow.

Sitemap Document

A complete sitemap showing every page the site should contain in both language versions, how pages are grouped, what the hierarchy is, and where the two streams share structural logic versus where they diverge. Bilingual sitemap considerations (shared pages, language-specific pages, hreflang structure) are documented explicitly.

Navigation Label Recommendations

Label recommendations for both Arabic and English navigation, written for how each audience describes what they need rather than translated from one language to the other. RTL and LTR navigation patterns are considered separately, including label length, truncation behaviour, and the structural implications of right-to-left reading order on hierarchy and grouping.

Page Template Outlines

For each key page type, a content zone outline showing what content belongs on the page, in what order, and what each zone accomplishes. Where the Arabic and English versions of a page should differ in content priority or zone order, those differences are documented in the template.

URL Structure and Internal Linking Plan

A URL architecture covering both language streams, including how Arabic-language URLs are handled (transliterated, translated, or English-path with hreflang), and an internal linking strategy for each language version that guides visitors and search engines through the priority content in each stream.

Request your IA Diagnostic

/ What changes

What Changes

Before

After

BeforeIn both Arabic and English versions, menus use internal terminology. English menus surface division names from the corporate hierarchy. Arabic menus translate those same labels rather than rewriting them for how Arabic-speaking visitors describe what they need. The problem is compounded when the translation is literal rather than contextual, producing Arabic labels that are grammatically correct but not how anyone would search for that service.

AfterWhen each language version is structured for its own audience rather than mirroring the other, visitors in both streams navigate to the right page without effort. Navigation labels match the language each audience uses to describe what they need, not a translation of labels built for the other audience.

BeforeVisitors arrive on a page, read it, and find no obvious next step. In both language versions, the path from informational content to a contact form, a quote request, or a product enquiry is either missing or buried. For businesses in the UAE where conversion happens through a human touchpoint (a phone call, a WhatsApp message, a meeting request), the structural gap between information and contact is where most of the site's traffic is lost.

AfterThe journey mapping and internal linking plan produce a clear next step from every page in both streams. Arabic-speaking visitors are guided toward conversion touchpoints that match their expected interaction pattern. English-speaking visitors follow a parallel but structurally separate path. Neither version is a dead end.

BeforeThe site has multiple pages covering the same service or product, created at different times, in both Arabic and English, with no cross-referencing or internal linking strategy. Search engines cannot determine which page is authoritative. Visitors who find one version of a page never discover related content. This is a structural problem that requires sitemap decisions, not more content.

AfterA clean bilingual sitemap, correctly implemented hreflang structure, and deliberate URL architecture signal clearly to search engines which version of each page serves which audience. Duplicate content signals between language versions are resolved. Each language version ranks for its own audience's searches.

BeforePlatform migrations in the region frequently discard previous URL structures entirely. Rankings earned over previous years are lost. Backlinks stop resolving. A URL architecture set before the build begins, designed to be stable across future changes and to handle both Arabic and English URL paths correctly, protects the search equity the site has already built.

AfterWhen designers receive a completed bilingual sitemap and page template outlines before they begin, they do not make structural decisions mid-project. The RTL/LTR structural considerations are resolved at the architecture stage rather than discovered during UI design. The build runs faster because the hard decisions were made first.

/ How it works

Process

Diagnostic Week 1

We review both language versions of your existing site, identify the top structural problems in each, and confirm the scope of the engagement. You receive a one-page summary of what we found and what the IA project will address before work begins.
Research and Audit Weeks 1 to 2

Discovery workshop with your team, full content audit of both language versions, and user journey mapping for Arabic-speaking and English-speaking audience segments separately. This phase produces the inputs that all structural decisions are built on.
Sitemap and Architecture Weeks 2 to 3

We build the bilingual sitemap document, navigation labels for both streams, page template outlines, and URL structure. Each element is reviewed with your team before it is finalised, with bilingual review available where needed.
Handover Week 3 to 4

All deliverables are packaged into a handover document your designer and developer can act on immediately. We walk your team through the structure in a handover session, covering both language streams, and remain available during the design phase.

Request your IA Diagnostic

/ Common questions

Frequently asked questions about Information Architecture

Straight answers on scope, timelines and cost. Anything else, ask us directly.

Ask us directly

Is a bilingual IA engagement significantly more complex than a single-language project?

A bilingual IA engagement typically takes thirty to forty percent longer than a single-language project because two audience profiles, two journey maps, and two sets of navigation labels need to be developed and reviewed. The complexity is manageable and the cost of not doing it, which is an Arabic version that performs poorly because it was structured as a translation rather than an architecture, is consistently higher than the additional investment.

Should the Arabic and English versions of the site have different sitemaps?

They often should differ in some sections. The top-level structure is usually shared. Below that, content priorities, page groupings, and the depth of certain sections may differ based on how Arabic-speaking and English-speaking audiences use the site differently. The sitemap document we produce explicitly marks where the two versions share structure and where they diverge.

How do you handle navigation labels in Arabic?

We do not translate English navigation labels into Arabic. We develop Arabic navigation labels independently, starting from how Arabic-speaking visitors in the UAE describe the services or products they are looking for. The result is navigation that reads naturally in Arabic rather than reading as a translation of English labels.

Does the URL structure recommendation cover Arabic-language URLs?

Yes. The URL structure recommendation covers both language streams and includes a recommendation on how Arabic-language URLs are handled: whether Arabic-script URLs, transliterated URLs, or English-path URLs with hreflang are most appropriate for the site's technical setup and SEO goals. We also document the hreflang implementation required to tell search engines which version serves which audience.

Will the deliverables be in a format our designer and developer can use directly?

All deliverables are structured documents that designers and developers can act on without needing interpretation. The bilingual sitemap is provided as a visual diagram and an annotated document. Navigation labels, page templates, and URL structure are provided as reference documents covering both language versions. We include a handover session where we walk through both streams with the team executing the build.

/ Our team

The people behind the work.

Niraj Raut

SEO Expert

LinkedIn Website

Keshab Joshi

PPC Expert