A service page can be grammatically correct in three languages and still leave a customer unsure what you actually do. The missing information is often the same: what is included, what you need from them, what happens next, and why they should trust the person doing the work.

Before translating a service page, I would write a brief that answers those questions. Then I would adapt the wording and examples for the intended reader. Translating an incomplete page just reproduces the gaps.

I offer consultations in Swedish, English and Persian through Ramfa SEO. That makes multilingual content a practical part of my own website, as well as an area of my multilingual SEO work. Here is the brief I would use to make a service page useful in each language.

Separate the reader’s language from their location

A Persian-speaking business owner may be based in Sweden. An English-speaking customer may be looking for a Swedish supplier. Do not assume that language alone tells you the customer’s country, budget or level of technical knowledge.

Google distinguishes multilingual websites from websites targeting different regions in its international site guidance. That distinction is useful for content planning too. Write down the intended service area and available consultation languages as separate facts.

For each page, complete this sentence: “This page helps [a specific reader] decide whether [this service] fits [this situation].” If the only difference between two briefs is a language code, check whether you have understood the audience well enough.

A worked brief: a website migration service

The following example is a planning exercise, not a description of a particular client contract. Imagine a business moving an established WordPress site to a new platform. Its owner is worried about losing enquiries and breaking existing search traffic.

The decision the page needs to support

The reader needs to understand whether SEO support should join the project before development starts, what work it covers, and how responsibilities are shared with the developer. “We provide seamless migrations” does not answer any of those questions.

The facts to collect before writing

The change: Is the domain, platform, URL structure, content or more than one of these changing?
The current dependency: Which pages bring enquiries, sales or important referral traffic?
The delivery team: Who can change redirects, templates, hosting and tracking?
The timing: Has a launch date already been promised, and what work is still reversible?
The boundaries: Does the engagement include implementation, review, coordination or a defined combination?

Those facts should shape the service explanation. They also tell you which questions the first contact form needs to ask. A small business should not have to produce a technical audit just to start a conversation.

The evidence the page can show

Use evidence that matches the claim. A redirect example can show how a redirect was checked. It cannot prove that every future migration will preserve traffic. A public profile can support professional background, but it does not replace a project result.

On Ramfa, the redirect and rollback exercise is identified as an exercise. The professional profile serves a different purpose. Keeping those distinctions visible helps the reader judge the evidence instead of decoding a vague “proven results” statement.

Keep the service facts consistent; write the explanation naturally

The scope, delivery responsibilities and limitations should agree across languages. Sentence structure does not have to. A sentence that is concise in English may become stiff or ambiguous when translated word for word.

For the migration example, a useful plain-English explanation is: “Before the site moves, we map the old URLs to their replacements and check where each redirect ends.” A natural Persian version could be:

قبل از انتقال سایت، مشخص می‌کنیم هر آدرس قدیمی باید به کدوم صفحهٔ جدید برسه و بعد بررسی می‌کنیم که انتقال‌ها درست کار کنن.

A Swedish version could be:

Innan webbplatsen flyttas kopplar vi varje gammal webbadress till rätt ny sida och kontrollerar att omdirigeringarna fungerar.

These examples keep the same concrete action. They do not add a guarantee, an invented result or a service that was absent from the original brief. A language reviewer should check both meaning and tone, not just spelling.

Build the questions from the buying decision

Instead of filling an FAQ with broad questions such as “Why is SEO important?”, collect questions that would stop someone from contacting you. For the migration page, I would start with:

Can you work with our existing developer?
Should we involve you before the new site is built?
What do you need to review the planned move?
What happens to pages that will not exist on the new site?
Which checks happen before launch, and which need the live site?

Answer them with the actual service arrangements. If timing or cost depends on the size and condition of the site, explain the factors instead of publishing a number that the business cannot support.

Review the whole journey in the chosen language

A translated headline is not enough when the form errors, confirmation message and next page switch back to English. Walk through one complete enquiry on a phone in each language. Include navigation, button labels, consent text, error messages and the response the visitor sees after submission.

For Persian, document language and text direction need separate attention. The W3C guidance on HTML direction explains that a language declaration does not set direction. Review mixed Persian text, email addresses, numbers and URLs in context. A technically correct paragraph can still be awkward to read when punctuation and alignment behave badly.

Publish a complete smaller set before an incomplete larger one

If only two service pages are ready in a new language, publish a clear, useful journey around those pages. Do not create empty copies of the rest of the site just to make the language menu look complete.

Use separate, accessible URLs and let visitors choose their language. Google recommends avoiding automatic language redirects that prevent people and crawlers from reaching alternatives. A suggestion that can be dismissed is easier to control than a forced switch.

When equivalent pages exist, connect the matching versions correctly. Google’s localized-version documentation covers reciprocal hreflang references. A language homepage is not automatically an equivalent of a detailed service page. Our hreflang guide covers the technical implementation in more detail.

A page is ready when the reader can make the next decision

Ask someone who understands the language to explain, in their own words, what is offered, what is excluded and what they should do next. If their answer differs from the brief, fix the page before adding more copy.

After publication, compare enquiries and recurring questions by language. Do not judge a new language version only by raw traffic against a much older version. Look for missing information that makes people hesitate, and use those questions to improve the next revision.

For help building that brief and organising the pages, see content strategy. The WordPress and migration service shows the type of detailed service explanation used in this example.

Multilingual service pages: write the brief before the translation