One company, several search journeys
ERP evaluation, industry needs and broad AI transformation are related, but they are not one query or one buying decision. A company homepage can introduce the business; on its own, it cannot give every search intent the detail it needs.
Company, services and focused pages each get a job
The bilingual homepage, About and services pages form a hierarchy rather than one long pitch. The company introduction establishes who AI Minds is; the service groups explain the offer; focused destinations can address a buyer’s particular need. My research, content strategy and search-aware copy shaped that layer of the site.
The opening explains the company offer before presenting routes into services.
Each service family is named for the problem it addresses and laid out for scanning.
Company context supports every other page
The About pages in both languages do quiet search work. They answer the brand query, establish who stands behind the products, and give every service and ERP page somewhere to point when a reader wants to know who they would be working with.
The About page carries the company story, so the service pages do not have to.
The paired page shows the Arabic structure and voice.
Saudi searches arrive from different directions
Saudi buyers searching in English use generic terms such as ERP software and ERP software in Saudi Arabia, name ERP suppliers, or search for digital transformation. The first two are system evaluation; supplier names are a comparison journey; broad transformation terms also attract policy and learning content. They call for separate topics, so one AI Minds page should not try to hold all of them.
Arabic search uses its own vocabulary. أنظمة تخطيط موارد المؤسسات ties the system to finance, resources and business processes, while التحول الرقمي can describe a much wider programme. The Arabic content map starts from that wording rather than from translated English keywords.
Each search job needs a fitting destination
The ERP industry selector shows how a sector choice can sit under a product explanation: a manufacturing example answers an application question once the ERP offer is understood. Not every selector option needs its own indexable page. A sector earns one when it has a distinct question and enough to say about it.
| Search family | What the reader wants | Where it should land |
|---|---|---|
| ERP software and regional modifiers | Evaluate a business system | ERP product explanation. |
| Implementation and process questions | Understand delivery and change | A service explanation, if that service is actually offered. |
| Industry ERP questions | Check a sector workflow | A substantial sector section or page supported by evidence. |
| Company name | Identify the provider | Company homepage and About context. |
Choosing an industry changes the explanation: manufacturing gets its own account of how the ERP fits, followed by a consultation route.
Links that explain how topics relate
A homepage link can introduce ERP; a module explanation can point to a relevant sector example; the sector example can return to the product or the right enquiry. These links serve readers first, and give search engines a path through the same logic. An identical list of services repeated under every paragraph would hide that relationship.
Before proposing new pages, I map the existing product, service and industry destinations and check which one already answers each question. A selector panel can stay inside a strong product page; a separate page needs its own scope and evidence.
What I would fix next
The English and Arabic homepages set the right language and reading direction. Next I would give each its own title and description, add canonical links and hreflang pairs, and put a main H1 at the top. These are small fixes with a large effect on how search engines understand the two language versions.
Turning the map into checkable requirements
For each substantive page, a developer handoff should name its reader job, main heading, localised title and description, internal links and its counterpart in the other language, and confirm that text and links behind selectors are available to crawlers.
Localised versions need full alternate links that point both ways between matching pages. I pair the equivalent pages first, then check canonicals, indexing and sitemap coverage. Search Console data then shows whether the structure is working.
A structure search can follow
The company page orients, the service pages explain distinct offers, and focused product and industry destinations answer narrower evaluation questions. With the technical signals in place, the structure that helps readers would also help search engines tell the offers apart.