A bilingual website can create two excellent reading experiences.
It can also create duplicate titles, broken language switches, missing translations, conflicting canonicals, and a sitemap that tells a different story from the HTML.
The second list is more common than it should be.
When I built the English and Bangla structure for this portfolio, I treated localization as a routing and content contract—not a translation toggle.
Choose a URL system you can maintain
English lives at /. Bangla lives at /bn.
That subdirectory structure works well for this site because:
- both languages stay on one domain;
- every page has a stable, shareable URL;
- the default English URLs do not need to move;
- the route structure is easy to explain;
- the sitemap can pair the two versions.
Subdomains are not automatically “bad for SEO,” and query parameters are not automatically uncrawlable. They simply create different operational tradeoffs.
The best URL system is the one the product can keep consistent for years.
Give each language its own canonical
The English page is not canonical to the Bangla page.
The Bangla page is not canonical to the English page.
Each localized page is a real page with its own self-referencing canonical:
export const metadata: Metadata = {
alternates: {
canonical: "/bn/blog/example",
languages: {
en: "https://www.mhtawfik.com/blog/example",
bn: "https://www.mhtawfik.com/bn/blog/example",
"x-default": "https://www.mhtawfik.com/blog/example",
},
},
};
Then both versions return the same language cluster.
That reciprocity matters. If English references Bangla but Bangla does not reference English, the implementation is incomplete.
hreflang is a hint, not a visibility switch
hreflang helps Google understand localized variants and serve an appropriate version.
It does not:
- make a weak page useful;
- create rankings by itself;
- replace a canonical;
- translate the content;
- guarantee that a particular version appears.
Google also says it determines page language from the content, not from the lang attribute or hreflang alone.
I still set <html lang="en"> and <html lang="bn"> because language metadata helps browsers, screen readers, and the document itself remain correct.
Route groups make the root language explicit
This site uses separate root layouts:
app/
(en)/layout.tsx
(en)/page.tsx
(bn)/layout.tsx
(bn)/bn/page.tsx
Route groups do not appear in the public URL. Each layout can own the correct root lang, font configuration, and locale metadata.
It is not the only valid Next.js architecture. It is the clearest fit for this repository.
Pair content at the source
Every article has:
- one shared canonical slug;
- an English
.mdxfile; - a Bangla
.bn.mdxfile; - an explicit locale;
- a Bangla
translationOfreference; - real publication and revision dates.
The content validator rejects a missing counterpart or a broken internal article link.
This catches a problem metadata alone cannot: a language switch that points to a page that does not exist.
Localize the thinking, not only the sentences
Literal translation keeps the nouns and loses the person.
English technical writing can tolerate compact abstractions. Bangla often reads better when the context arrives earlier and the sentence breathes differently.
I keep the same:
- reader problem;
- factual meaning;
- decision;
- code;
- evidence.
I rewrite:
- rhythm;
- examples;
- transitions;
- technical explanations;
- CTA language.
That is why the Bangla post is a counterpart, not a line-by-line copy.
Keep every signal in one cluster
For each pair, I verify:
- both URLs exist;
- each URL has its own canonical;
- both return the same reciprocal language alternates;
- the language switch reaches the actual counterpart;
- the sitemap shows the same relationship;
- titles and descriptions are localized;
- visible author facts remain consistent;
- internal links stay in the reader’s language where possible.
If one layer disagrees, I fix the source model instead of patching the rendered tag.
About llms.txt
This site publishes a generated llms.txt directory because some tools and people may choose to read it.
It is supplemental.
Google says llms.txt is not required for its AI search features. The file does not control all crawling, training, retrieval, or citations. Those are different systems with different controls.
The pages, visible content, structured data, crawler access, and independent references remain more important.
The result I actually want
The goal is not “more URLs.”
The goal is:
- international clients can evaluate my work in English;
- Bangla readers can understand the same expertise in a natural voice;
- search systems can see which pages are counterparts;
- every name, author, and service fact remains consistent;
- the content system fails loudly when a pair breaks.
That is a useful bilingual product.
For the content side, read how I write technical content for people before search engines. If your Next.js localization has conflicting routes or metadata, send me one broken pair.
- #Next.js
- #International SEO
- #Localization
- #Hreflang
- #Bangla
Continue reading
Related field notes on engineering, SaaS, freelancing, and building dependable products.