Short answer: An SEO brief for translators tells them what each page must achieve in the target market, not just what the source text says. It should include the target language and country, locally researched keywords per page, a glossary of fixed terms and brand names, length limits for titles and meta descriptions, rules for URL slugs, alt text and internal links, local details such as currency and units, and what the translator should flag rather than decide. A short brief prepared once per language saves many rounds of corrections and keeps translated pages findable.
Why translators need an SEO brief
Professional translators are experts in meaning, tone and cultural fit. What they usually do not know is which words people in the target market actually type into search engines, which parts of the page carry SEO weight, and what technical rules the website follows. Without that information, even an excellent translation can miss:
- The translator picks a correct but rarely searched term, while locals search with a different word.
- Titles and meta descriptions are translated faithfully but become far too long.
- URL slugs, alt texts and link anchors stay in the source language.
- Internal links still point to the source-language pages.
- Brand and product names are translated when they should not be, or the reverse.
None of these is the translator’s fault. They are gaps in the handover. The difference between translation and localisation for search is explained in translation vs localization for SEO; the brief is the practical tool that makes localisation happen.
Part 1: market and audience
Start the brief with context that frames every decision:
- Target language and country, for example “Portuguese for Brazil” rather than just “Portuguese”.
- Audience: who reads these pages, their level of expertise and what they want to achieve.
- Tone and form of address: formal or informal, and for languages that distinguish them, which form of “you” to use.
- Local conventions: currency, units, date and number formats, phone number format.
- What must stay the same: legal statements, prices set centrally, technical specifications.
Part 2: keywords per page
This is the core of the SEO brief. For each page, give the translator:
- The main search term in the target language, researched in that market, not translated from the source keyword.
- Two to five secondary terms or common variations.
- Where the main term should appear: title tag, H1, first paragraph, at least one subheading, and naturally in the body.
- Terms to avoid, for example a literal translation that means something different locally or belongs to a competitor’s brand.
Keyword research for the target market should ideally be done or checked by a native speaker with access to search data. The method is described in multilingual keyword research. If you do not have research for every page, prioritise the pages that bring the most traffic or revenue in the source language, and give the translator freedom to choose natural terms for the rest.
Make it clear that keywords must read naturally. A translator should never force an awkward phrase into a sentence to match a keyword list. Readers notice, and so do search engines.
Part 3: glossary and fixed terms
A glossary (or termbase) keeps terminology consistent across pages and translators. It should list:
- Brand, product and feature names, with a clear note on whether they are translated or kept in the original.
- Key industry terms and the chosen local equivalent, especially where several are possible.
- Terms that must match the interface of your product or app, so tutorials and help pages use the same words as the screen.
- Legal and regulated terms that must be used exactly.
When keyword research shows that people search with a term different from the one in your glossary, resolve the conflict once, in the glossary, rather than page by page. Consistent terms also help search engines and AI systems understand what your products are.
Part 4: on-page elements and limits
List every element the translator will handle, with the rules for each:
| Element | Rule for the translator |
|---|---|
| Title tag | Main term near the start; roughly 50–60 characters; write, do not just translate |
| Meta description | Roughly 140–160 characters; summarise the page and give a reason to click |
| H1 and subheadings | Descriptive; main term in the H1; keep the heading hierarchy of the source |
| URL slug | Translated or kept per the site’s policy; short, lowercase, hyphens, no special characters if the policy says so |
| Image alt text | Describe the image in the target language; do not copy file names |
| Link anchors | Descriptive text in the target language |
| Buttons and calls to action | Short, natural and consistent with the interface |
Character limits matter because languages expand at different rates; German and Finnish text is often much longer than English. The detailed approach is in translating title tags and meta descriptions, and slug policy options are explained in should you translate URL slugs.
Part 5: links and technical details
Translators often work in a translation tool or spreadsheet, far from the website. Tell them explicitly how links and technical parts are handled:
- Internal links must point to the equivalent page in the target language. Provide a URL map, or state that links will be replaced automatically. Links to pages without a translation should be marked for review. See internal linking on multilingual sites.
- External links can point to local sources where that helps the reader, for example a local regulator instead of a foreign one.
- Code, placeholders and variables such as
{name}or HTML tags must remain unchanged. - hreflang, canonicals and structured data are usually handled by the website system, not the translator. Say so, so nobody edits them by hand.
- Text in images needs separate handling; list those images so they can be recreated.
Part 6: what to flag instead of deciding
Good translators notice problems. Give them a clear way to report them:
- Examples, references or offers that do not apply in the target market.
- Claims that may be legally different locally, such as guarantees or health statements.
- Keywords that sound unnatural or have unwanted connotations.
- Source text errors or ambiguities.
- Places where a local example, case or image would work better.
A simple comment column or a list at the end of each file is enough. These notes are often the most valuable localisation input you get.
A simple brief template
You do not need special software. A shared document plus one spreadsheet covers most projects:
- Document, section 1: language and country, audience, tone, form of address, local formats.
- Document, section 2: link to the glossary and a list of names that are never translated.
- Document, section 3: the element rules from the table above, with the site’s slug policy.
- Document, section 4: how links, placeholders and images are handled, and how to flag issues.
- Spreadsheet: one row per page with the source URL, target URL, main term, secondary terms, terms to avoid, and columns for the translated title, meta description and slug.
Keep the brief versioned and update it when you learn something, for example when a reviewer finds a better local term. New translators then start from what the team already knows.
Quality checks after translation
Before publishing, check the delivered pages against the brief:
- A native-speaking reviewer reads key pages for fluency and correct terminology.
- Title, meta description, H1 and slug are present, within limits and contain the main term naturally.
- Internal links point to target-language URLs and none are broken.
- Alt texts are translated, and no source-language text remains in menus, buttons or forms.
- After publishing, hreflang, lang attributes and canonicals are correct for the new pages.
If you use machine translation as a first draft, the brief matters even more, because the post-editor must correct terminology and SEO elements as well as grammar. The safe limits are discussed in machine translation and SEO. For a whole new language, follow the steps in how to launch a new language version.
An automated check helps here, because translated sites multiply every template problem by the number of languages. Site SEO AI Audit crawls all language versions and reports missing or duplicate titles and descriptions, H1 problems, missing alt texts and broken links, plus hreflang return links, lang attributes and x-default. The fix list shows how many pages each issue affects, so you can see whether a problem sits in one translation batch or the template. Paid plans add re-audits after each round of fixes.
Related reading
- Image SEO on multilingual sites: alt text, files and text
- Which blog posts to translate first: a data-led approach
- What to do with untranslated pages on a multilingual site
The bottom line
Translators produce what the brief asks for. Give them the market context, locally researched keywords per page, a glossary, clear limits for titles, descriptions, slugs and alt text, rules for links and code, and a way to flag problems. Then check the result with a native reviewer and a crawl. One good brief per language pays for itself in fewer corrections and better-performing pages.
FAQ
Should translators do keyword research themselves?
They can, if they have access to search data and the time is paid for. Otherwise, provide researched keywords for priority pages and let translators choose natural terms elsewhere.
How long should an SEO brief for translators be?
The general part can fit on two pages: market, tone, glossary link and element rules. Page-specific keywords are best kept in a spreadsheet next to the content.
Should translators translate URL slugs?
Follow your site’s slug policy. If slugs are translated, give rules for length, characters and transliteration. If not, tell translators to leave them unchanged.
Who handles hreflang when new translations are added?
Usually the website system or developer, not the translator. The brief should say this clearly so nobody edits technical tags by hand.
Is a brief needed for machine translation plus post-editing?
Yes, even more so. Machine translation does not know your keywords, glossary or limits, so the post-editor needs the same brief to correct them.


