What the model actually sees on your website
A language model does not walk through your website the way a person does. It cannot click a menu, hover over an image, or watch a layout react. What it receives is the text you send it: headings, paragraphs, button labels, form fields, and whatever else you copy into the request. Inside the model, that text is broken into small pieces, and each piece is rendered against the patterns the model learned while training on huge amounts of writing in many languages. The result reads fluently because the model has seen both your source language and your target language in thousands of real contexts.
This is why the quality of the output depends less on the model and more on what you hand it. A model can only translate what it sees. If your navigation labels arrive with no context, the word Home might become a house instead of a landing page. If a phrase is actually a product name, it can get translated literally and lose the meaning your customers know.
So think of the model as a careful writer working from a brief, not as a scanner that visits every page. Your job is to prepare the text and describe the task clearly. The model takes care of the wording.
Collect the source text before the first run
Start with a short inventory of everything that needs translating. For a small website, that usually means the home page, an about page, a contact page, and maybe one or two product or service pages. Open each page and copy the visible text into a plain document or a spreadsheet, keeping one entry per line or per block so the pieces stay separate.
Keep the role of each phrase with the text. If a sentence is a heading, mark it as a heading. If it is a button label, say so. The model needs that hint to choose the right register: a button label should stay short and direct, while a paragraph can breathe and carry some personality.
A few things should never be sent for translation at all:
- Product names, brand names, and slogans you already publish as-is
- Email addresses, phone numbers, and web addresses
- Placeholders such as {name} or %s that your code fills in later
- Units, currencies, and date formats that stay the same in the target market
Also collect a few sentences that show how you already write. These become a style sample you can paste into every request, so the translation sounds like the same website rather than a different one.
Write one prompt that protects meaning and tone
Before you send the first batch, write a single prompt you can reuse for every page. It should state the job in plain words and set the boundaries. A solid starter prompt covers these points:
- The source language and the exact target language and region
- Who reads the page, such as new customers or technical users
- The tone you want, like friendly, formal, or direct
- A list of terms that must stay in the original language
- An instruction to keep placeholders, punctuation, and line breaks intact
- The style sample you collected, so the voice stays consistent
Then send one page at a time and check the first result before continuing. For a first run on a small site, a compact model such as Claude Haiku 4.5 or Gemini 2.5 Flash is a practical fit for short strings and page copy, and the same prompt keeps working if you try a larger model later for trickier passages.
Ask the model to explain anything it is unsure about instead of guessing. A short note such as left in English because it is a brand name is far more useful than a confident mistranslation that slips into production.
Checklist before the green light
Once the pages come back, run through this list before anything goes live. It catches most of the problems that plain reading misses.
- Read every heading aloud in the target language and confirm it still points to the right section
- Open each translated page and check that buttons, menus, and forms still make sense on their own
- Compare numbers, dates, and contact details against the original line by line
- Confirm placeholders and code fragments survived the translation untouched
- Check that longer text did not break a layout, a banner, or a fixed-height box
- Ask one native speaker to skim the most visible pages and flag anything odd
- Keep the source text and the translated text together so updates can be matched later
Fix the source text first when something reads badly. A vague English sentence usually becomes a vague translated sentence, and polishing the original is often faster than patching every language version. When the copy changes, rerun only the affected lines instead of the whole site.
Where a relay fits in this first run
Once your prompt is ready, you need a way to send requests to the model you choose. SwiftRelay is a pay-as-you-go relay for Claude, GPT, Gemini, DeepSeek, Kimi, GLM, Qwen, Grok and other models, billed per token, so you only pay for the translation work you actually run.
It works with Claude Code, Codex, Gemini CLI, and any OpenAI-compatible SDK. Point Claude Code and Gemini CLI at the bare host https://api.fastapirelay.com, and add /v1 when you use an OpenAI SDK. That means you can script the whole website as a batch, page by page, and rerun a line whenever the source copy changes.
You can sign up for a SwiftRelay account and start with a small gift credit, and inviting friends earns 14% of their top-ups. From there, the loop is simple: collect the text, write the prompt, run one page, check the result, and only then push the translation to your site.