Adding a Language to Your Website: Steps and Handover

Imagine the English version of your site is ready and every page looks flawless at first glance. Then a visitor submits the contact form with a field missing, and an error message pops up in Persian. Adding a language to your website succeeds or fails on exactly this kind of detail. The short answer: assess your current structure, put the scope and owners in writing, build the new version in a test environment, and launch against clear acceptance criteria.

I've written this checklist from the project manager's seat, meaning the person who has to sign off at the end that each language is genuinely ready. That's why, when it comes to adding a language to your website, I talk less about translation and more about scope, responsibility, testing and handover.

What steps does adding a language to an existing website involve?

The overall path has four steps. To add a language to an existing website, first review the technical structure and the pages. Next, define the translation scope, who owns each task and when content will be ready. Then build the new version in a test environment and check the URLs and user journeys. Once the handover criteria are approved, launch with a monitoring and rollback plan in place.

But a checklist for adding a language to your website is only useful if every tick can be verified. So keep these four columns next to each item:

• Status: not started, in progress, ready for review or approved.

• Owner: one person's name, not "the tech team" or "marketing".

• Evidence: a screenshot, a link to a test report, or a ticket number logged in the destination system.

• Launch blocker: whether a gap in this item stops the launch or not.

A tick without evidence is just a claim. And in handover meetings, it's usually these undocumented claims that spark the longest arguments, so attach the evidence on the same day you tick the item.

Is your current website ready for a new language?

In most cases, yes. Adding a language to an existing website is usually feasible; the real question is how much work it takes and what the constraints are. Even so, tick these off before any estimate:

• Access to the source code or its repository, not just the admin dashboard.

• Admin access to the content management system (CMS), the panel you use to edit pages.

• Access to hosting and the domain control panel.

• Valid licences for the theme and any commercial plugins, because unlicensed copies usually don't receive updates.

• The ability to take a full backup of files and the database.

The output of this stage is a short report on limitations, for example "the form plugin is outdated and its messages can't be translated". Without that report, the next estimate is built on guesswork.

Then look more closely at three sample pages: a services page, a form, and a dynamic page such as a product listing or search results. Three criteria drive the decision here:

1. Text separated from code: if button labels are hard-coded into the theme, every new language means editing code.

2. Text direction support: Persian runs right to left and English left to right; the template must handle both without breaking the layout.

3. Language version management: the system needs to know which English page corresponds to which page in the original language.

For the details of text direction and date and number formatting, the web internationalisation guides are a good reference. And if you're still unsure about the overall structure, read our notes on multilingual website design before you decide.

My decision rule for turning an existing site bilingual is simple. If the core components can be extended, a full redesign isn't required. But if one important part, say the order form, isn't compatible, test that part first with a limited prototype. Then decide about the whole site.

Also ask the vendor to price the work that's essential before going multilingual separately from optional improvements. Updating the CMS core might be essential; changing the site's colour scheme isn't. That separation alone stops the scope from swelling for no good reason.

Inventory of existing pages, forms and integrations

Pin down the scope with a simple worksheet, not with the phrase "the whole site". The number of URLs isn't the same as the number of page templates; two hundred product pages may share a single template. As a result, development time depends mostly on templates, while translation time depends on URLs.

The numbers in this table are hypothetical. The most important column is the last one, because every row needs a clear launch decision; "we'll see later" isn't a decision.

When adding a language to your website, a large share of the text doesn't live in the pages at all. So list these too, and note where each one is edited:

• Menus and footer

• Search and the "no results found" message

• Form error and success messages

• Automated emails and text messages

• Downloadable files such as PDF catalogues

• Text inside images and banners

Then move on to integrations: the customer relationship management system (CRM), the payment gateway and the SMS service. But take one point seriously here. Translating the payment page doesn't mean an international customer can actually pay, or that you can actually serve them.

For example, picture a hypothetical shop with 200 products that translates only its 40 best sellers. That's entirely workable. But it has to be decided in advance what the categories will show and whether English search returns untranslated products. It also has to be clear what a visitor sees on a page with no translation.

Splitting responsibilities between client, translator and developer

When adding a language to a website, most delays come from tasks nobody owned. That's why you should write the roles down from day one:

• Client: sets the target market, the page scope and a single final approver.

• Translator: delivers a terminology glossary and reviewed copy.

• Developer: carries out the implementation and delivers test evidence.

Still, three tasks tend to fall between these roles: entering content into the site, reviewing the copy on the live page, and fixing short interface strings like "Submit" or "Read more". Don't assume these are automatically part of translation; give each one its own owner. Last-week surprises usually come from exactly these three orphaned tasks.

When adding English to a website, some decisions can only come from the client: for instance, the English names of products, or which currency prices are shown in, and whether they're shown at all. And there's one question few people ask: are the phone number and business hours you publish genuinely reachable for an international audience?

Before you start, put three things into the written agreement: the number of revision rounds, the response deadline for each approval request, and how scope changes are logged. These three clauses matter because without them every small fix turns into a fresh negotiation. For how to structure them, our guide to writing a professional website design contract will help.

Scheduling around content readiness

How long it takes to make a site multilingual depends on the number of templates, the volume of approved content, the integrations and the review rounds. That's why you shouldn't trust a fixed figure offered without an assessment. A credible estimate comes after the scope worksheet, not before it.

The good news is that technical work doesn't have to wait for translation. URL structure, the language switcher and preparing the template for left-to-right text can all move forward in parallel with translation. But testing the final layout needs real copy, because placeholder text never shows you the true length of headings.

Keep two situations apart. If the content is ready and approved, the schedule for adding a language to your website depends mainly on technical work and testing. But if the content is still being produced, the schedule is tied to how fast it gets written and approved.

In the second case, a content delay mustn't turn into an open-ended wait. So for every delay, write down a review date and a clear effect on the plan; for example, "if the service copy hasn't arrived by the review date, those pages move to phase two".

The launch date of a multilingual site is set by the day the last piece of copy is approved, not by the developer's calendar.

Test environment and the old-to-new URL map

A test environment (staging) is a separate copy of the site where you build and review changes without real users seeing anything. Every step of adding a language to your website should run here first. In this environment, control three things:

• Access is restricted, for example with a password or an allow-list of addresses.

• Search engines aren't allowed to index it.

• Data is non-sensitive; don't bring real customer information into staging.

Then build the URL map: for every current page, record the original-language URL, its translated equivalent and its publishing status:

The first and second columns match in most rows, and that's deliberate. When adding a language to your website, there's no need to change healthy URLs in the original language; doing so only creates risk for no reason.

But if a URL genuinely changes, set up and test a permanent redirect (301) to the relevant destination. Sending every old URL to the homepage confuses users and search engines at the same time.

The language switcher must also open the equivalent of the same page, not the English homepage. And define a specific behaviour for pages with no translation, such as a short note saying the page is only available in Persian. Silently redirecting to an unrelated page misleads the visitor.

Before any change to the live site, take a backup and actually test restoring it. A backup that's never been restored hasn't yet proven it works. Keep the URL map too, because it's part of the handover documents.

Testing translation, forms, mobile and SEO settings

For each test item, write down in advance how you'll check it and what result you expect. That way "looks fine to me" gets replaced by a result you can compare. This table is a good starting point:

Test forms all the way to the end: from submission on the site to the entry landing in the CRM or destination inbox, and the confirmation email reaching the user. At each stage, check the message language, input validation and success message. A form that rejects international phone numbers, for example, is in practice turning international customers away.

Next, look at everything on mobile with the final copy: the menu, the language switcher, tables and each page's main button. A healthy desktop version proves nothing about mobile. Many problems with adding a language to your website only show up on a small screen, so don't wrap up this stage with a quick glance at your own phone.

Then comes SEO, meaning optimising the site for search engines. Check the title and description of every translated page, the sitemap, and whether the English pages can be indexed. If adding a language to your website is meant to bring in new traffic, don't leave this part until after launch.

Two technical settings are decisive here. hreflang tells search engines which equivalents each page has in other languages. canonical sets the reference URL for each page. A common mistake is pointing the canonical of every translation to the Persian page. That effectively removes the English version from the results.

hreflang relationships also need to be valid and reciprocal: if the Persian page points to its English equivalent, the English page has to point back to the Persian one. See the documentation on telling search engines about localised versions for the details.

Finally, retest the key journeys in the original language. Adding a language to your website sometimes quietly breaks an existing feature, such as Persian search or the order form.

A test that only looks at the new version has missed half the risk.

Acceptance criteria and handover documents

Record the end of adding a language to your website with a signed acceptance record, one for each language. At minimum it contains:

• The approved scope, with a link to the worksheet

• The release version or launch date

• Test results

• Outstanding issues and the owner of each

• The signatory's name and the date signed

Every acceptance criterion has to be measurable. "The site should work properly" isn't a criterion. This one is: "every agreed page has the correct equivalent, and a test form submission is logged in the destination system".

Classify issues as well. A launch-blocking issue, like the main form failing, isn't the same as an uneven gap in the footer. If you give conditional acceptance, write an owner and a fix deadline for each condition.

Before you sign, collect these documents:

1. The old-to-new URL map

2. The terminology glossary

3. The test report

4. Instructions for adding content in each language

5. The necessary access credentials, delivered through a secure channel, not a public messaging app

6. A backup and rollback instructions

Also put three boundaries in writing: fixing bugs within this scope, new change requests, and maintaining translations after handover. These boundaries matter because each one follows a different cost logic. Review the factors in the cost of a bilingual website, from development to maintenance.

Phased launch, monitoring and a rollback plan

When adding a language to your website, a phased launch means publishing a complete, tested set of pages, not half-finished translations. For example, service and contact pages first, then selected products. Meanwhile, the original version stays as untouched as possible.

Before launch, four things need to be clear: who carries it out, who approves it, when post-launch checks happen, and the stop condition. My suggestion is to define a failure of the main form explicitly as a rollback trigger. Then, if something goes wrong, nobody argues about rolling back in the middle of a crisis.

Agree on how often each check runs with the team. The first days after launch usually need a closer eye, so schedule the checks more tightly during that period.

Rollback isn't just blindly restoring the database either. If orders or requests have come in since launch, restoring the earlier backup wipes them out. So the rollback instructions must say how that data is preserved.

Be honest about rankings too: nobody can promise they'll definitely hold. You can measure the effect, though. Record baseline data before launch, such as traffic to key pages. Then review each language's traffic changes alongside its technical status.

What information should you send for a quote?

This short list is enough for an initial estimate on making your site multilingual:

• The site URL

• The site's technology, if you know it, for example WordPress or custom code

• Target language and market

• Priority pages

• Integrations: CRM, payment gateway, SMS and anything else

• Translation status: ready, in production or needs a translator

• Any time constraint, such as a trade show or event

Mark anything you don't know as "needs review"; that's completely normal. But don't send admin passwords or customer data in your first request. Grant access after an agreement is in place, through a secure channel.

When proposals arrive, compare them against the same yardstick. A good proposal spells out its assumptions, out-of-scope items, who owns the content, approval points, the acceptance method and the monitoring period. The first thing I look for in any proposal is the "out of scope" section. A proposal with just a number and a date, on the other hand, isn't complete yet.

If you're ready to turn a single-language site into a multilingual one, send us this worksheet. With Niasa's multilingual website design services, we start by assessing your site and scope and walk you through the limitations report. We propose timing and cost after that assessment, not as an upfront guarantee.