Should Your Website Speak More Than English?

For most South African businesses, the answer is no. That is not a comfortable position for a web agency to publish, because a second language is a substantial billable addition to any build, and it is the honest one. A multilingual website costs roughly twice as much to maintain as it does to launch, the maintenance burden is permanent, and the commercial return only exists for a specific and identifiable set of businesses. This article explains which businesses those are, what the decision actually involves technically, and why a half-maintained second language is worse than never having built one.

The related question, which is what South Africans actually search in and how Google now handles African languages, is a different subject and is covered separately. This piece is about the build decision only.

The Numbers That Get Misread

The case for multilingual websites in South Africa usually opens with the language statistics, and the statistics are genuinely striking.

Census 2022 records isiZulu as the language most often spoken at home by 24.4 percent of the population, isiXhosa at 16.3 percent, Afrikaans at 10.6 percent and Sepedi at 10 percent. English sits fifth at 8.7 percent, followed by Setswana at 8.3 percent and Sesotho at 7.8 percent.

Presented as a business case, that reads as an obvious conclusion: you are publishing in the fifth most common home language in the country, so you are excluding the other ninety percent.

That conclusion does not survive contact with how the market actually operates. Home language is not the same thing as the language people conduct business in, and it is not the language most South Africans use to search for a supplier. English is the working language of South African commerce, of professional and technical vocabulary, and of the overwhelming majority of commercial search. A procurement manager whose home language is isiZulu will search for an industrial supplier in English, because that is the language the products are named in.

So the correct reading of those figures is not that ninety percent of your market is excluded. It is that language preference in South Africa is contextual, and the contexts where it shifts away from English are specific rather than general. Identifying whether your business operates in one of them is the entire decision.

Where It Does Not Pay

The most common multilingual project we are asked about is a Johannesburg business to business supplier wanting isiZulu because it feels like the right thing to do. The instinct is decent and the return is close to zero, because their buyers are procurement staff who work in English, search in English, and will find the isiZulu pages faintly odd in a commercial context.

Three signals that a multilingual build is not your priority.

• Your buyers are other businesses. South African B2B runs on English almost without exception.

• Your existing English website is underperforming. Adding a second language to a website that does not convert produces two versions of a website that does not convert. Fix the first one.

• You cannot name who will maintain the second language. If the honest answer is nobody, the project ends badly, and the next section explains why.

The Maintenance Cost Nobody Prices

This is the part that gets left out of every proposal, including plenty of agency proposals, and it is the single most important consideration in the decision.

A bilingual website does not cost twice as much to build. Translation of an existing structure is comparatively cheap, and machine translation with human review has made it cheaper still. A bilingual website costs approximately twice as much to operate, permanently, and that cost arrives in a form nobody budgeted for: everyone’s time.

Every change becomes two changes. A price update, a new service page, a corrected phone number, an amended trading hours notice, a new team member, a legal disclaimer update. Each one now exists in two places and the second place is the one that gets forgotten, because the person making the change usually does not speak the second language and cannot verify their own work.

What follows is entirely predictable and we see it repeatedly. Six months after launch the English website has moved on and the second language has not. Twelve months later the Afrikaans pages list a service you discontinued and a price that has risen twice. The second language has become a liability: it is publishing incorrect information to the audience you built it for, and it signals neglect to precisely the people you were trying to signal respect to.

That is why a half-maintained second language is worse than an English-only website. An English-only website in a bilingual market is a limitation. An abandoned Afrikaans section is a statement about how much the business cares, and it is being read by the people you built it for.

The right question at the proposal stage is therefore not what does it cost to translate. It is who, by name, will keep it current, and what happens when that person leaves.

How It Works Technically

Assuming the case holds, the build decisions are worth understanding, because they are difficult to reverse later.

URL structure

Each language needs its own indexable URL. Subdirectories are the standard approach and the right default for a South African business: yourbusiness.co.za for English and yourbusiness.co.za/af/ for Afrikaans. All the authority stays on one domain, and it is straightforward to set up and maintain.

Separate domains are appropriate only when you are genuinely running distinct operations in distinct markets, because you are then building and maintaining search authority separately for each. Subdomains sit awkwardly in between and rarely justify themselves.

The mechanism that tells search engines these pages are alternates rather than duplicates is hreflang annotation. Get it wrong and the two versions compete with each other in search results, which is the most common technical failure in multilingual builds. Every language version must reference every other version, including itself, and the references must be reciprocal.

The three plugin architectures

WordPress translation plugins take three fundamentally different approaches and the difference matters more than the feature comparisons suggest.

Duplicate-post architecture, used by WPML and Polylang, creates a separate post or page record for each language, linked as translations. Each version is a real page with its own database record, its own SEO fields and its own revision history. This is the most robust approach and the best fit for a website where the two languages will genuinely diverge in content rather than being strict translations.

Real-time translation of rendered output, used by TranslatePress, translates the rendered page as it is served, with translations stored separately from the content. The advantage is a genuinely simple editing experience, because you translate by clicking directly on text in a live preview of the page, which non-technical staff find far easier. The trade-off is that translation sits in a layer over the content rather than in the content.

Hosted translation services, such as Weglot, run the whole thing externally. Fastest to deploy, and your translations live on someone else’s infrastructure with pricing that scales with traffic and word count, which is also a cross-border data consideration worth thinking about.

On cost, published pricing at the time of writing puts WPML’s Multilingual CMS tier at 99 euros per year covering three websites and including its WooCommerce, string translation and media translation components. Polylang Pro is 99 euros per year for a single website, with WooCommerce support as a separate purchase or bundled at 139 euros. Verify current pricing before budgeting, since these change and the exchange rate moves against you.

Two costs consistently get missed. Automatic translation is metered separately from the licence on every platform, charged per word, so the licence fee is a floor rather than a total. And renewal pricing frequently differs from first-year pricing, which matters because this is a permanent commitment rather than a one-off.

What actually has to be translated

Page content is the visible part and roughly half the work. The rest is the material that determines whether the second language works at all.

Navigation menus and footer text. Button and form labels. Form validation messages. The confirmation message after a form submission. Automated emails, which are frequently missed and are the first thing a customer receives in the wrong language after a positive interaction. Meta titles and descriptions for every page, without which the translated pages cannot compete in search. Image alt text. URL slugs, so that the Afrikaans page has an Afrikaans address. Legal pages including your privacy policy. For a store, product names, descriptions, categories, shipping methods and the entire checkout.

A rough planning figure: the visible page content is around half the translation scope. Budget accordingly, and treat any quote that only counted pages with suspicion.

Machine Translation, Honestly

Machine translation for Afrikaans is now good. Not perfect, but good enough that machine output plus review by a fluent speaker is the correct workflow rather than a compromise, and it has changed the economics of this decision considerably.

For the Nguni and Sotho language families the position is weaker. These are lower-resource languages in machine translation terms, and output quality is more variable, particularly with technical or commercial vocabulary that may not have a settled equivalent. Machine translation alone is not adequate here, and the review step is substantive editing rather than proofreading.

Publishing unreviewed machine translation is worse than publishing nothing, and the reason is specific: your readers can tell. The audience for the translated pages are fluent speakers who will recognise machine output immediately, and the impression created is that the business could not be bothered to have a person read it. That is the opposite of the respect the translation was meant to signal.

One further point on scope. Translating word for word is rarely the right output anyway. Names of services, regulatory terminology, product categories and idiom all need decisions rather than translation, and those decisions benefit from someone who understands both the language and the business. That person is your reviewer, and budgeting for them is what separates a multilingual website that works from one that merely exists.

A Middle Path Most Businesses Should Consider First

Full multilingual is not the only option and it is rarely the right first step.

A more proportionate approach translates the two or three pages that matter most, typically the homepage and the primary service page, and leaves the remainder in English. This tests whether the second language produces anything measurable before committing to a permanent maintenance obligation, and it keeps the surface small enough that keeping it current is realistic.

There are other ways to signal language capability that carry no maintenance cost at all. Stating plainly on your contact page that your team serves clients in Afrikaans and isiZulu communicates the same respect and commits you to nothing. Making sure the person who answers the phone can switch languages matters more to most customers than the website ever will. If your business is genuinely bilingual in practice, saying so in English is often sufficient.

That is not a reason to avoid the work. It is a reason to be clear about what problem the second language is solving, because for many businesses the underlying goal is signalling accessibility, and there are cheaper and more durable ways to signal it than a website section nobody will update.

The Decision, Stated Plainly

Frequently Asked Questions

Does my South African website need to be in more than one language?

For most businesses, no. English is the working language of South African commerce and of the overwhelming majority of commercial search. The genuine cases are consumer-facing businesses in Afrikaans-dominant regions, services where the buying decision is emotional rather than transactional, public-facing and access-related services, and businesses entering markets outside South Africa.

How much does a multilingual website cost?

The build addition is modest relative to the total, since translating an existing structure is comparatively cheap. The real cost is operational and permanent: every future change has to be made twice. Plugin licences start around 99 euros per year, with automatic translation metered separately per word and renewal pricing frequently differing from the first year.

Which is better for a South African website, WPML or Polylang?

They use the same underlying architecture, creating separate page records per language, so the decision is usually about bundling and workflow rather than capability. Consider TranslatePress instead if non-technical staff will maintain the translations, because its visual front-end editing is significantly easier for people who are not comfortable in the WordPress admin.

Will a second language improve my Google rankings?

Only if people are searching in that language for what you sell. Translated pages compete for translated queries, so if the commercial search demand in your sector is in English, a second language adds pages without adding visibility. Confirm the search demand exists before treating this as an SEO investment.

Is machine translation good enough for a business website?

For Afrikaans, machine translation followed by review from a fluent speaker is now a legitimate workflow. For isiZulu, isiXhosa, Sesotho and Setswana, output quality is more variable because these are lower-resource languages in machine translation terms, and the review step becomes substantive editing. Publishing unreviewed machine output is worse than publishing nothing, because fluent readers recognise it immediately.

What happens if I do not keep the translated pages updated?

The second language becomes actively harmful. Within a year it typically lists discontinued services and outdated pricing, which publishes incorrect information to the exact audience it was built for and signals neglect to the people you were trying to show respect. Name the person responsible for maintaining it before the project starts.