Information architecture is the map of what exists on a site, what each thing is called, how the things relate, and where each one lives. Three audiences use the same map: visitors trying to find the service they would pay for, editors trying to publish without filing a ticket, and search engines trying to work out which page answers which query. On a bilingual site there is a fourth reader: the rule that says which Arabic page is the twin of which English one.
Skip the map and every later decision is improvisation. Navigation gets argued about in the design review. Developers encode accidental relationships that become a schema rewrite six months later. And the search engine, finding three pages that half-answer the same query, ranks none of them.
What operators feel when it is wrong
- "The site is confusing." Visitors cannot find the service they need, so they call, or they leave for a competitor whose site is duller and clearer.
- "Every change needs a developer." Content types were never defined, so a new product means a new template.
- "We rank for nothing." Ten blog posts and two service pages compete for the same term, and the service page loses to the blog.
- "The Arabic site is a mess." Some pages have twins, some do not, the switcher lands on the home page, and nobody knows which version is canonical.
Each of those is an architecture problem wearing a different costume.
Step 1. Start from intents, not from a sitemap
Write down what people are trying to do when they arrive. Not what the company wants to say; what the visitor wants. For a B2B service company the list is short and concrete:
| Intent | Example query | Page type that answers it |
|---|---|---|
| Find a provider for a specific service | "wordpress migration company" | Service page |
| Check the provider is credible | "alnitak reviews", "who built pht.com.sa" | Case study, About |
| Solve a problem before buying | "site not indexed after migration" | Guide (blog) |
| Compare options | "wordpress or next.js" | Comparison guide |
| Get a price or a scope | "seo audit cost" | Offer / package |
| Contact | "alnitak contact" | Contact |
Every row gets exactly one primary page. The rule that follows from this table is the one that matters most:
One URL per intent. If two pages answer the same intent, merge them or make one clearly the primary and link the other to it. A service page and a blog post competing for the same commercial query is the most common self-inflicted ranking problem.
Step 2. Define page types before pages
A page type is a template plus a content model: the fields an editor fills, the layout that renders them, the schema that describes them. Most business sites need five or six.
- Service page: intro, who it is for, what is delivered, FAQ, CTA. Schema: Service, FAQPage, BreadcrumbList.
- Case study: client, problem, work, outcome, stack. Schema: Article or CreativeWork, BreadcrumbList.
- Guide (post): body in structured text, TOC, related, CTA. Schema: BlogPosting.
- Offer: scope, price, timeline, who it is for, next step.
- Hub: a list of one type (all services, all guides in a category) with an intro that is itself worth indexing.
- Utility: contact, about, legal.
The test of a good page type: an editor can create a new instance by filling fields, and it renders correctly without touching a template. If a new service needs a designer, the type is not defined yet.
Step 3. Write the URL rules
URLs are the architecture made visible. Write them as rules, not as a list:
/services/<service-slug>/
/projects/<project-slug>/
/blogs/<post-slug>/
/blogs/category/<category>/
/ar/… for the Arabic twin of any of the above
Rules that hold up:
- Folders name the type, slugs name the thing.
/services/technical-seo/, not/technical-seo-services-company/. - No dates in URLs unless the content is genuinely time-bound. A guide updated yearly should not carry 2024 forever.
- Slugs in one script for both languages. Arabic slugs are legal but break sharing, analytics and hand-typed links; the English slug under
/ar/is the practical choice. - Trailing slash decided once, enforced by a redirect, and used consistently in canonicals, sitemap and hreflang.
- Freeze the rules. Changing a URL is a redirect and a temporary loss. Design them so you do not need to.
Step 4. Decide the language model
A bilingual site is not two sites and it is not one site translated. It is one architecture with a rule for twins.
- Every page type has a twin rule. The Arabic service page for
/services/x/lives at/ar/services/x/. Same slug, same type, same fields. - A twin exists only when it is written. Not every English post needs an Arabic version. The rule is: emit the Arabic URL, the hreflang entry and the switcher target only when the Arabic document exists. A page that "falls back" to English under an Arabic URL is a duplicate wearing a flag.
- The content model has both languages as columns. Title, description and body are
{ en, ar }pairs on the same record. Arabic is a field, not a translation queue in another system. - Navigation can differ. The Arabic market may care about different services first. Order and even presence of items can vary; the twin rule cannot.
- Names follow the market's search intent. The Arabic H1 is what an Arabic buyer types, which is often not a translation of the English H1. Keyword research per language decides the names.
Step 5. Draw the tree and read it aloud
Put the page types and their instances in a tree, three levels deep at most for anything commercial. Then read it aloud to someone who does not work at the company. If a branch needs a paragraph to explain, it is wrong. If two branches sound the same, merge them. If a visitor with a specific need would not know which branch to open, add the missing name, not a page.
The tree is also the navigation, the breadcrumb schema and the sitemap. One source produces all three, which is how they stay consistent.
Step 6. Internal links follow the tree
Every service page links to the guides that answer its pre-purchase questions and to the case study that proves it. Every guide links up to its service and sideways to two related guides. Every case study links to the services it demonstrates. Hubs link down to everything of their type. The result is that any page is within three clicks of any other, and the anchor text says what the target is.
The minimum IA before anyone designs
- The intent table, with one primary page type per row.
- The page types, each with its fields and schema.
- The URL rules, frozen.
- The twin rule for languages, and the list of which pages will exist in which language on launch day.
- The tree, read aloud and survived.
- The linking pattern between types.
Only then wireframes. Pretty first is how you ship a hero image and no path to a contract.
What we do with clients
The corporate site package opens with this exercise in a working session: the intent table on one screen, the tree on the other, both languages side by side. It takes half a day and it decides the CMS, the templates, the sitemap and the hreflang before a line of code. When the design starts, it starts from a map that three audiences can already read.
