Multilingual Websites in Pakistan: A Developer's Guide to Urdu RTL and hreflang

If you build sites for Pakistani clients, a bilingual site is a layout and routing problem before it is a translation problem. This guide walks through the decisions that matter in code: direction, language routing, and hreflang, using the same business logic as the main guide.

Why an English only site misses people

Think about a customer who finds your site on a phone, late at night, and wants one answer. How much does this cost? Where do I order? When will it arrive? If that answer is in a language they have to work hard to read, many will not struggle through it. They will go back and tap the next result. Language is also about trust. A customer who can read a return policy in Urdu is more likely to believe it. A parent reading a clinic page in Urdu can check timings and fees without asking a relative to translate. A shopper who sees clear Urdu size and delivery details is less likely to abandon a cart over a doubt. That does not mean every Pakistani customer prefers Urdu. Preferences vary by city, age, business type, and habit. Some people search in English and message in Roman Urdu, typing phrases like "website banwani hai" in a chat. Roman Urdu tells you how people talk and search. It is not a replacement for a proper Urdu version of your site. The practical choice for most small businesses is English and Urdu as the two main versions, with Roman Urdu kept in mind when you write headings and questions customers actually ask.

What a bilingual site actually needs

A working bilingual site has four parts, and all four need attention. First, a clear language switcher. Put it in the header, where people expect it. Label it "English" and "اردو". Flags alone are a poor choice, because a flag is not a language. When a visitor switches, take them to the same page in the other language, not back to the homepage. If someone is reading a lawn collection in English and taps Urdu, they should land on that same collection in Urdu. The choice should also stick as they move around the site, and it must be easy to tap on a mobile screen. Second, separate content for each language. Each version needs its own pages, not a single page that flips words with a script. A visitor and a search engine should both be able to open the Urdu page on its own. Third, mobile friendly navigation in both languages. Most Pakistani customers will meet your site on a phone first. Test the menu, the contact button, and the inquiry form in Urdu on a real phone, not only on a desktop screen. Fourth, a plan for keeping both versions current. When a price changes, a service closes, or a phone number changes, both versions need the update. An Urdu page with last year's prices is worse than no Urdu page, because it looks careless and it misleads the customer who trusted it. At aimEncoders, we start this work by asking a simple question: which pages bring enquiries today? Those pages go first. The rest can follow in phases, which keeps the project useful from the start instead of stuck in translation for months.

Urdu design is more than translation

Urdu reads right to left. That changes the layout, not just the words. A proper Urdu page sets its direction to right to left, so menus, breadcrumbs, forms, and buttons sit where an Urdu reader expects them. Headings and paragraphs align accordingly. Fonts matter a lot here. Some fonts render Urdu characters cleanly, and some make them cramped or hard to read. Line spacing matters too, because Urdu script needs room to breathe. Then there is the mixed content problem. An Urdu page will still contain English brand names, email addresses, product codes, prices, and phone numbers. Those pieces read left to right, inside right to left text. If the page only right aligns everything and hopes for the best, numbers and names can break in strange places. The code needs proper handling for text that runs in two directions. In practice, developers mark the Urdu page as Urdu and right to left, and use layout rules that adapt to direction instead of hard coding left and right everywhere. That way the same design can serve both versions without building two separate sites. Test this on a phone. A menu that looks fine on a laptop can crowd badly on a small Urdu screen. Forms are the place to be strictest. If a customer cannot read the form labels, or the submit button sits in an odd place, the enquiry never arrives.

Note for Developers: Build for Direction, Not Just Translation

Mark Urdu pages lang="ur" dir="rtl" and English pages lang="en" dir="ltr". Prefer logical CSS properties such as padding-inline-start, margin-inline-end, and text-align: start, so the layout flips with direction instead of needing two stylesheets. Test mixed direction strings carefully: prices, phone numbers, email addresses, and Latin brand names inside Urdu text, plus form inputs and error messages. Keep hreflang pairs reciprocal and self referencing, with an x-default fallback, and make the language switcher link to the equivalent page, not the homepage. Finally, test both versions on a small Android screen, because that is where most Pakistani visitors will first meet the site.

How Google should read both versions

Search engines need help to understand that your English page and your Urdu page are versions of each other, not two competing pages. The cleanest setup for a small business is separate addresses under one domain. For example, an English about page at /en/about/ and its Urdu version at /ur/about/. The homepage, services, and contact pages follow the same pattern. Both versions stay on the same domain, which keeps management simpler than running two separate sites. Then each page points to its counterpart with hreflang tags. In plain terms, hreflang is a label that says: this page is English for Pakistan, and here is its Urdu version for Pakistan. Each page should reference itself and its alternate, and the references should match in both directions. You can also set a default version for visitors whose language is not covered. Translate the search details too, not just the visible text. Page titles, meta descriptions, and addresses should be in the right language for each version. An Urdu page with an English title and description is a missed chance, and it looks unfinished in search results. One honest warning: hreflang helps Google understand the relationship between pages. It does not guarantee indexing, a ranking, or that Google will always show the version you prefer. Good structure gives your pages a fair chance. Content quality, competition, and technical health still decide the rest.

What to translate first

You do not need to translate everything at once. In fact, launching a small set of fully translated pages beats launching fifty half translated ones. Phase one covers the pages a customer needs to trust you and contact you: the homepage, an about page, main services or product categories, and contact details including WhatsApp and inquiry buttons. These are the pages that answer the first questions. Phase two covers the pages that help a customer decide: individual service pages, product descriptions, prices, FAQs, and delivery, payment, and return policies. This is where a clothing store translates sizes, prices, and delivery details. A clinic translates services, appointment steps, doctor profiles, and location details. A real estate agency translates listings, locations, pricing, and inquiry forms. A training institute translates courses, eligibility, fees, schedules, and admission steps. Phase three covers supporting content: blog articles, guides, testimonials, and case studies. These help over time, but they should not delay the pages that bring enquiries. Ask yourself one test for every page: does translating this page help a customer understand, decide, or buy? If yes, it belongs early. If not, it can wait.

Machine translation is not enough

Machine translation can draft text quickly. It cannot be the whole Urdu version of your business. Good Urdu translation carries meaning, not just words. It uses familiar expressions instead of stiff, formal vocabulary. It keeps technical terms understandable. It uses the same word for the same thing across the site, so customers are not confused by three different terms for delivery. Human review matters most where a mistake costs money or trust: product details, prices, payment instructions, return and refund policies, and medical, legal, or financial information. Marketing lines and calls to action need review too, because a literal translation of a slogan often sounds odd. Use machine help where it is safe: a first draft, repetitive product text, or a rough FAQ draft. Then have a fluent Urdu speaker who knows your customers read the important pages. The goal is Urdu that sounds like a person from your business wrote it, not like a tool guessed at it.

Cost and time, honestly

No honest agency can quote a fixed price for a bilingual site without knowing the project. The price depends on how many pages you translate, how the translation is done, whether the design needs right to left work, what your platform supports, and how much search setup is involved. Ongoing maintenance matters too, because every future update touches two versions. There are three broad shapes. A basic bilingual site covers essential pages, a switcher, and proper right to left support. A growing business site adds bilingual service pages, product information, FAQs, and search setup. A full ecommerce site translates the whole buying journey, including categories, product pages, cart, checkout, order messages, and support. The cheapest safe way to start is to launch a small, complete set and expand from there. Translation and development can often run side by side, so the schedule depends on page count, source content quality, translator availability, platform, and testing. A timeline without those details is a guess, and you should treat it as one. For custom web development work, we plan the bilingual structure before we build, so the Urdu version is part of the design rather than an afterthought bolted on at the end.

Mistakes that waste the effort

Most bilingual sites fail in the same few ways. Avoid these and you are already ahead. Do not use a simple auto translate widget as your Urdu site. It produces pages you cannot properly control, and the quality is uneven. Build real language pages instead. Do not translate only the homepage. A customer who clicks through to a service page and finds English only will feel misled, and the homepage promise falls apart. Do not keep the English layout unchanged for Urdu. Test the right to left design, especially menus, forms, and checkout. Do not forget the search setup. Without hreflang and translated titles and descriptions, Google may struggle to match the right version to the right searcher. Do not leave forms and checkout in English while the rest of the page is Urdu. Translate the whole journey, or the customer stalls at the last step. Do not let the Urdu version go stale. When a service changes, update both versions in the same week. An outdated Urdu page quietly undoes the trust the rest of the site built.

How to start this week

You can move on this without a huge project. Start with four steps. First, look at your enquiries and ask which customers struggle with English pages. Your WhatsApp chats and phone calls will tell you quickly. Second, pick ten to fifteen pages that matter most, using the phases above. Write them in clear English first, because clear source text translates better. Third, plan the structure: /en/ and /ur/ addresses, a visible switcher, and hreflang links between matching pages. Agree this before design starts, not after. Fourth, test both versions on a phone, with a real person reading the Urdu pages. Check the switcher, the menu, the forms, and the prices. Fix what confuses them before you launch. A bilingual site done this way is not a cosmetic extra. It is a practical way to serve the customers you already attract, in the language they actually read. If you want help planning one, talk to the aimEncoders team about your pages, your customers, and a phased plan that fits your budget.

Frequently asked questions

Do Pakistani businesses need a website in both Urdu and English?

Not every business does, but many benefit from it. If a good share of your customers read Urdu more comfortably, or ask questions in Urdu on WhatsApp and phone, a bilingual site removes friction at the exact moment they decide. Start with your enquiry pages and judge by the response.

Can Google index Urdu pages?

Yes, Urdu pages can be indexed when they are real pages with their own addresses, proper language labels, and hreflang links to their English versions. Indexing is not guaranteed for any page, in any language, but a correct setup gives Urdu pages the same fair chance as English ones.

Should I translate my whole website at once?

Usually no. Translate the pages that help customers understand, decide, and contact you first, then expand in phases. A small complete bilingual section is more useful than a large site where most Urdu pages are empty or machine translated without review.

Is a translation plugin enough for an Urdu website?

A plugin can help with drafting or managing content, but it is not a finished Urdu site on its own. You still need reviewed Urdu text, a tested right to left layout, translated forms and checkout steps, and correct hreflang setup.

How do I keep both language versions updated?

Treat updates as one job, not two. When a price, service, or contact detail changes, update the English and Urdu pages together, and keep a short checklist of pages that changed. That habit is what keeps a bilingual site trustworthy over time.

About the author: Muhammad Asad Ullah is the founder of aimEncoders, a web development agency in Faisalabad that builds custom websites, web applications, and ecommerce stores, and tests every site before launch. His team also writes about practical website topics, including local search, in the aimEncoders blog.