Start with clear pages in each language, consistent service facts and links that take readers to an answer and a useful next step. Then test whether both versions can be discovered, rendered and used. AI search readiness is not a special code purchase that guarantees your company will be mentioned. It is a practical combination of useful content, sound implementation and observation of actual results.
Google’s current guidance retains SEO fundamentals and emphasizes content that adds genuine knowledge. It does not require a special AI file or AI-specific structured-data type, and meeting requirements does not guarantee visibility. Google’s generative AI search optimization guide.
This guide is for a service company operating in Saudi Arabia and serving Arabic- and English-speaking audiences. The Google-specific guidance below applies to Google Search, not automatically to every AI assistant.
1. Map buyer decisions, not a translated keyword list
For each service, ask who needs it, what they need to understand before making contact, and what the scope excludes. An Arabic-speaking manager might search for “تجهيز مكتب جديد بالرياض,” while an English-speaking colleague asks about “office fit-out scope in Riyadh.” The topic overlaps, but the wording and decision context need research in each language.
Build a small page map:
| Page type | Decision it supports | Required contribution |
|---|---|---|
| Service page | Is this suitable for our situation? | Scope, outputs, requirements and limitations |
| Comparison guide | Which option fits us? | Selection criteria and trade-offs |
| Process guide | What should we prepare? | Steps, inputs and responsibilities |
| Example or case study | What does the work look like? | Clearly labeled illustration or authorized project evidence |
Do not create a new page for every minor wording variation. Combine questions that serve the same decision and separate topics when the reader’s actual need changes. That is the purpose of content strategy and production, rather than maximizing page count.
2. Give each language a distinct URL and connect genuine equivalents
Google recommends separate language URLs rather than changing the content solely through cookies or browser settings. It also recommends letting visitors choose a language instead of automatically redirecting them based on an assumed preference. Google’s multilingual-site guidance.
Choose a structure the existing website supports and document it. Creating particular folder names is not a goal in itself, nor a reason to change stable URLs without a migration plan. Each intended page should be accessible, linkable and reviewable.
Use hreflang for true language alternatives: each version identifies itself and its alternatives, the links are reciprocal, and alternate URLs are fully qualified. Select language and region codes for the intended audience; the office’s location alone should not dictate every locale tag. Google’s localized-version guidance.
Do not point every Arabic translation’s canonical at the English page. Review each language’s canonical and the consistency of related signals. Google recommends a same-language canonical when using hreflang, where one exists. Google’s canonical-URL documentation.
3. Keep facts fixed while allowing the writing to change
Different word counts are not the main risk. Different promises are. If Arabic says a service covers design only, English must not imply that procurement and construction are included. A coverage change should not leave one language offering work the business no longer provides.
Maintain one approved fact register containing:
- Legal and trading names in both languages.
- Services actually offered and their exclusions.
- Service areas and delivery methods.
- Outputs and required inputs for each service.
- Approved projects, credentials and figures, with their evidence owners.
- Review dates and the pages using each fact.
Examples and explanation order can vary by audience while facts and limitations remain equivalent. Review form errors, confirmations and notifications as well as the main copy. The language switcher should preserve the current topic instead of sending a reader back to the homepage.
Where manual updates are becoming unreliable, CMS development can organize shared fields, translation status, review workflows and permissions.
Worked example: explaining an office-design scope
This is a hypothetical editorial example, not a LAB project or evidence of a particular company’s capabilities. Assume a Riyadh company provides office space planning and interior design. Construction is outside its standard contract.
Instead of a broad headline promising “complete solutions for every need,” both language versions explain:
| Fact | Information the buyer needs |
|---|---|
| Starting scope | Review of the team’s requirements and available space |
| Deliverables | Layout, design concept and specified files agreed in the proposal |
| Exclusions | Construction and procurement unless expressly agreed |
| Client inputs | Existing plan, required uses and known constraints |
| Next step | A scope discussion before a project quotation |
A supporting guide then answers “What should we prepare before commissioning an office design?” It provides documents, questions and decisions that help a buyer prepare, with a contextual link to the relevant service page. It does not replace the service page or repeat the same copy with a longer introduction.
If the guide includes a drawing of an invented office, label it as illustrative. If a real case study is published later, distinguish delivered outputs from verified outcomes and obtain publication permission. Readers should be able to tell a methodology explanation from the company’s project record.
This separation also makes editorial review easier. The service owner checks scope, the writer checks clarity, and the reviewer checks evidence. None of those responsibilities should disappear when the English version is produced.
4. Make answers understandable without writing for an imagined machine
Give the direct answer first, followed by conditions, exceptions and examples. A comparison table can be more useful than a dense paragraph, but there is no reason to fragment every thought into a separate line to make the page look “AI-friendly.”
Test each section: if a reader lands here directly, can they identify the subject and the limits of the answer? Name services clearly, explain specialist terms where necessary and attach sources to factual claims. Repeating the city and service name in every heading adds little to the decision.
Keep FAQs when they address real hesitation. Do not sell them as a guaranteed route to a Google rich result: Google stopped showing FAQ rich results in May 2026. Google’s documentation updates.
5. Test both the page and the journey in both languages
Website design needs to work with content and implementation. A working English page does not prove that an Arabic table, menu or form behaves correctly.
| Check | Proposed acceptance evidence |
|---|---|
| Content availability | Main copy is visible to users and inspectable in the rendered page |
| Equivalent language page | The switcher preserves the topic and technical alternatives are correct |
| Direction and mixed text | Arabic reads naturally; emails, numbers and URLs remain usable |
| Mobile layout | Fixed controls do not cover important content or fields |
| Form completion | Labels, errors and confirmations are understandable; the request reaches its owner |
| Internal links | Destinations exist and are relevant; guessed unpublished routes are absent |
| Claims | Important claims have a source or explicit internal approval |
| Maintenance | A changed shared fact triggers review of both versions |
These are practical acceptance tests for software quality assurance. Ask for a record of what was tested and what was not, rather than a blanket statement that the website is “SEO compliant.”
An issue should identify the page and language, reproduction steps, device, observed result and expected behavior. That gives the implementation team something it can fix and the reviewer something it can verify.
6. Measure discovery separately from commercial outcomes
Google’s current documentation provides a Search generative AI setting in Search Console for inclusion in its generative search features. Inspect the property’s actual setting and whether it inherits a parent setting. Do not change the owner’s choice without authorization. Search generative AI control.
A dedicated generative AI performance report provides impressions with page, country and device breakdowns. It may be absent when the property has insufficient impressions. This is not a complete record of every mention of your company across all assistants. Generative AI performance report documentation.
Alongside search visibility, review landing pages, received inquiries, inquiry quality and recurring sales questions for each language. Keep a dated change log. Asking one assistant a question can provide a dated observation, but it cannot establish market-wide visibility or guarantee another user receives the same answer.
Use those observations to select the next piece of work. If the Arabic page attracts relevant visitors but its form fails, technical repair matters more than producing another article. If visitors repeatedly ask what a service excludes, the page needs clearer scope. If one language is missing approved evidence, resolve the evidence gap before adding stronger promotional claims.
Mistakes that delay useful work
- Buying an AEO plugin before fixing missing language pages or broken links.
- Translating trust statements while expanding the underlying promise.
- Publishing near-identical city pages without useful local information.
- Hiding limitations in one language while explaining them in the other.
- Treating an impression or citation as equivalent to a qualified sales opportunity.
Frequently asked questions
Must the two versions be literal translations?
No. They need equivalent meaning, facts and scope, expressed naturally for each audience. Review each version as a usable page, then review consistency between them.
Do we need two separate websites?
Not simply because there are two languages. Assess the existing architecture, editorial workflow and team needs. Accessible, connected language versions matter more than duplicating systems.
Do we need llms.txt or special AI schema?
They are not requirements for Google’s generative search features under its current guidance. They should not replace content and technical improvements. Do not extend this conclusion automatically to every other service that might use such files.
Can a provider guarantee that AI answers will cite the company?
No. A provider can assess readiness, improve pages and observe results, but source selection and generated answers remain outside its control. Ask for verifiable work and honest measurement boundaries instead.
Your next step
Prepare the current page map, priority services, Arabic and English content, and evidence for published claims. Discuss a focused SEO and AI search readiness scope with LAB that connects content, technical priorities and verification, including ownership of factual updates after handover.
Sources
Official sources reviewed October 26, 2026:
- Google: Generative AI search optimization guide.
- Google: Managing multilingual websites.
- Google: Localized versions and hreflang.
- Google: Specifying canonical URLs.
- Google: Documentation updates, including FAQ rich-result retirement.
- Search Console: Search generative AI control.
- Search Console: Generative AI performance report.
