Most website localisation projects are done in the wrong order, which is why they overrun. The translating is booked first because it is the visible cost, and the structure, the tags and the record are dealt with afterwards, by which point the URLs are already wrong and the tags are being retrofitted onto pages that are live. Doing it in the order below costs the same and finishes.
First: scope and structure, before a word is translated
Decide which pages, which locales, and whether the locales live on subdirectories, subdomains or country domains. Write the URL pattern down. This takes an afternoon and it is the only part that is expensive to change later, because changing it after launch is a migration with redirects and a ranking risk attached.
Second: size it, then book the translation
Pages times average words times locales, minus what you will machine translate, at the rate you have been quoted. A brief with that number in it gets a better quote and a real schedule; a brief that says translate our website gets a per-word rate and an open-ended timeline. The scope sheet on this site produces the number.
Third: the tags, generated rather than typed
Build the hreflang set from the same source of truth that knows which pages exist in which locale, so a page that has not been translated yet simply does not appear. Hand-written tags are correct on the day they are written and wrong by the second locale.
Fourth: the record, from day one rather than year two
One row per page per locale with a status and a date. Started at the beginning it costs nothing; started later it is an audit of a site nobody understands any more. It is what answers which pages are stale, which is the question the second year of a multilingual site is entirely made of.
Fifth: launch one locale, then read it for a quarter
Ship the first locale alone. Read its coverage report, its search impressions by page, its switcher usage and the pages readers leave from, for a quarter, before the second locale is booked. The first locale finds the structural mistakes at a quarter of the cost of finding them four times: the template that renders the wrong hreflang set, the form that posts in the source language, the transactional email nobody translated, the page that exists in German and not in the sitemap. A company that launches four locales at once discovers all of those in four languages on the same day and fixes them under pressure; one that launches one fixes them once and applies the fix to the record before the second is built.
A project worked through, in weeks
Week one: scope and structure. A hundred and twenty pages in English; sixty of them earn a translation; subdirectories per locale; German first. Week two: the count. Sixty pages at four hundred and fifty words, plus a shared chrome block of two thousand, is twenty-nine thousand words; forty percent will be machine translated and left alone, so the brief asks for seventeen thousand four hundred words of post-editing at a quoted rate. Weeks three to six: translation, while the build learns to generate the hreflang set and the sitemap from the record. Week seven: the German locale live, sixty rows in the record with a status and a date. Weeks eight to twenty: reading. The scope sheet on this site produces the week-two number; the record is the paid half.
Questions people ask about website localization how to
How long does a website localisation take?
The translating is quick and the deciding is slow. Scope and structure in a week, translation in whatever your word count buys, tags with the build, and the record from the start.
What is the most common mistake?
Booking the translation before deciding the URL structure, which means the URLs are wrong when the words arrive.
Do we need a separate team for this?
No. One person who owns the scope and the record, plus whoever translates. The failures come from nobody owning the record, not from headcount.
Who owns the record after launch?
One named person, usually whoever briefs the translators, and the record is theirs whatever tool holds it. Every source change is a row that goes stale; the owner reads the stale rows monthly and decides which are retranslated and which are left. A record owned by a team is a record nobody read the month the German page went wrong.
What is the smallest version of this that works?
A spreadsheet with a row per page per locale, a status column and a date, kept from the first locale; a URL pattern written down; and tags generated from that spreadsheet rather than typed. That is the whole method at ten pages, and it is the same method at a thousand with the spreadsheet replaced by the record on this site.