Back to blog
5 min read Updated:

A multilingual website relaunch: an SEO plan from inventory to launch

Denis Elisei
Denis Elisei
Codavix Solutions
A laptop and desktop monitor on a bright desk beside green plants
Photo: Domenico Loia / Unsplash

A website relaunch changes how customers discover your business, understand your services and contact you. For a site in Romanian, English and German, every design decision also has three sets of pages, navigation labels and search results behind it. A clean homepage is only one part of a successful release.

The useful starting point is a record of what already works. Build the new site around those findings, then test the route from a search result to a completed enquiry in every language. The following plan is intended for a business site whose design, content or URL structure is changing.

Start with an inventory that includes business value

Create a spreadsheet with one row for each existing URL. Record its language, page purpose, search impressions, visits, enquiries and whether another website links to it. Include articles and downloadable documents, not just the pages visible in the main navigation.

Use a representative period and note campaigns or seasonal changes. A page with few visits may still bring valuable enquiries. Ask the sales team which service descriptions they send to prospects; that can identify useful pages that traffic reports understate.

Give each row a decision: keep, improve, combine or retire. Add an owner and a proposed destination. This turns an abstract redesign into a reviewable content plan. It also exposes missing translations before the development team has to guess what an empty language page should contain.

Treat URL changes as a separate deliverable

For URLs that must change, prepare a direct mapping to the closest relevant new page. Google recommends permanent server redirects and discourages redirecting unrelated old pages to the homepage. Temporary search fluctuations can still occur while a move is processed. Google’s site migration guidance explains these behaviours.

In an illustrative service-site migration, an old English maintenance page should lead to the new English maintenance page. Sending it to the Romanian homepage makes the visitor repeat the search and obscures whether the service still exists.

Ask for a test report that records the old address, response status, final destination and destination language. Include common variations such as HTTP, HTTPS and the www hostname. Decide who owns any redirect configured at the hosting provider, because it may sit outside the application repository.

Check language relationships and language quality separately

For equivalent translated pages, each language version should reference itself and the other versions through reciprocal hreflang annotations. These annotations describe a relationship; they do not replace translation. See Google’s localized-page documentation.

Create a second review that a native reader can complete without technical tools. Does the German service page make the same offer as the Romanian page? Does its contact link remain in German? Are form errors, consent labels, breadcrumbs and confirmation messages translated? Does the language switcher open the equivalent article rather than the blog homepage?

Review search titles and descriptions as editorial copy. A literal translation may be awkward or much longer in another language. Keep the meaning aligned while allowing natural wording. Use descriptive image alternatives where the picture adds information, and avoid repeating keywords in every interface label.

Test the journey that earns an enquiry

Choose one realistic task per important service. For example: a prospect finds the English software page, compares the delivery process, reads an article and requests a discussion. Ask someone unfamiliar with the redesign to complete it on a phone.

Record where they hesitate. A technically valid page can still hide the contact action, use vague service names or demand too much information. Agree which form fields are necessary for the first conversation, and verify where a submission actually arrives using an authorized test address.

Keep the launch review concrete:

  • Every intended public page loads and has a clear main heading.
  • Navigation, article links and contact details lead to the intended destination.
  • Search metadata describes the visible page and identifies its preferred URL.
  • The sitemap contains the intended language versions, with no staging addresses.
  • Mobile layouts remain readable with long German headings and validation messages.

An automated SEO score is a diagnostic signal. It does not measure whether the page answers a customer’s question or whether sales can follow up successfully.

Plan the first month after release

Save the inventory and a prelaunch snapshot so that later comparisons use the same page groups. Assign one person to review broken URLs and another to check incoming enquiries. Start with the busiest landing pages and the services most important to the business.

Look at search visibility, successful form submissions and enquiry quality together. A fall in one measure needs investigation, not an immediate redesign rollback: the cause could be tracking, demand, a technical error or an actual content problem. Record changes so that several simultaneous edits do not make the evidence impossible to interpret.

For a relaunch, request the content inventory, URL mapping, language review and release checks alongside the design files. Our web development work can cover these pieces together. Tell us which pages and markets matter most, and we can define a focused starting scope.