Google Translate Breaking Your Website Layout? How to Fix It

At Talha Aslan and team, we hear this complaint on many site reviews. A visitor from abroad translates the page, and suddenly the menu wraps onto two lines. The logo text becomes a strange phrase. A booking form stops responding. In short, the site itself is rarely broken. Instead, it simply was never built with translation in mind.

One distinction matters from the start. Blocking translation is usually the wrong goal. The better goal is translation that does no harm: your brand name stays intact, the menu holds its shape, and forms keep working. This guide covers exactly that, and nothing else.

What are the signs that Google Translate is causing problems?

The symptoms tend to follow a pattern. At first, the translated page looks fine. Then, after a few clicks, odd behavior starts. You can walk through the list below on your own site in a few minutes.

• Short menu labels turn into long phrases, so the navigation wraps onto a second line.
• Your brand name, product names, or people’s names turn into literal translations.
• Also, button labels spill outside their boxes or get cut off.
• Error messages after a form submit appear in the original language.
• Then cart, filter, or tab components stop responding after translation.
• Finally, prices, units, or order codes show odd changes.

Even one of these issues can cost you a lead. For example, a buyer who wants a quote from another country sees a broken menu and loses trust. Therefore, treat this as part of your sales flow, not as a cosmetic detail.

What does browser translation actually change on a page?

Browser translation does not touch the files on your server. After the page loads, the browser collects text fragments, sends them to a translation service, and writes the results back in place. So the change only lives on the visitor’s screen.

So that is exactly where trouble starts. If one of your scripts looks for a specific piece of text, it may not find it after translation. In addition, the translator sometimes wraps words in extra elements. As a result, the page structure shifts in small but important ways.

The second effect, however, is length. Some words get shorter in another language, while many get longer. German compound nouns, for instance, overflow narrow menus quickly. If your design relies on fixed width boxes, that growth breaks the layout right away.

So the problem has two layers. First, you control which text gets translated. Second, you build a layout that can absorb longer text. If your current theme supports neither, patching it piece by piece gets expensive. In that case, a rebuild through professional web design with translation tests in the brief is often the cheaper path.

Why is the lang attribute the first thing to check?

The lang attribute tells browsers which language a page or element uses. The MDN reference for the lang attribute explains that it takes a BCP 47 language tag. It also notes that child elements inherit the value from their parent. Without any value, the language counts as unknown.

A wrong value changes how translation behaves. For example, an English page that still says es from an old theme may confuse the browser. It may offer translation to readers who already speak English. On the other hand, it may skip the offer for readers who actually need it.

The lang value matters for accessibility too. Screen readers pick pronunciation based on it. If search engines also misread your language, our guide on wrong language detection and the html lang attribute covers the search side in depth.

So the rule is simple. Set one correct value on the html element. Then add a separate lang value only to parts written in another language.

Checking takes a minute. Open the page source and look at the html element at the top. If you use a content management system, the site language setting usually controls this value. In other words, you can often fix it without touching any code.

How do you mark text in a second language on the same page?

An English page may contain a Spanish slogan, a French product name, or a quote from a German customer. Without its own lang value, the browser treats that text as English. Consequently, the translator may mangle a phrase that needed no translation at all.

The fix is to add the right language tag to the element around that phrase. For example, use es for the Spanish slogan and fr for the French product name. That way, both translation tools and screen readers handle the phrase correctly.

• Slogans and campaign lines.
• Customer quotes in another language.
• Foreign words inside product or model names.
• Language names in your language switcher, each written in its own language with its own lang value.

This markup also helps accessibility. MDN describes marking language changes inside a page as part of the WCAG requirements. In practice, one small edit solves two problems at once.

Which parts of a site break most often during translation?

In our experience, problems cluster in a few areas. If you know them, you can test faster and start with the riskiest parts.

• Top navigation and dropdowns, because many words share a narrow space.
• Then hero headlines, because large font sizes overflow quickly.
• Pricing cards and comparison boxes, because they expect equal heights.
• Form labels and error messages, because scripts interact with them most.
• Finally, the footer, because brand name, address, and legal links sit together.

Here is an example scenario. A service page shows three pricing cards side by side. After translation, the middle card title wraps onto two lines. Then the buttons end up at different heights. That small shift alone makes the page look careless. Instead, use a card layout that pins the button to the bottom but lets the height follow the content.

What does translate="no" do, and where should you add it?

The translate attribute tells translation tools whether an element’s text should change. The MDN reference for the translate attribute lists two states. An empty value or yes allows translation, while no means the element must stay as it is. MDN also states that automatic systems such as Google Translate respect it. It even suggests the attribute for brand names.

Add the value to the smallest part that needs protection. For instance, wrap just the brand name next to the logo, a product code, or an email address. If you block a whole heading or the entire menu, visitors cannot understand that area at all.

• Short elements around brand and product names.
• Order numbers, SKUs, and similar codes.
• Also usernames, email addresses, and domains such as example.com.
• Small interface parts whose scripts depend on the exact text.

MDN also notes that not every browser recognizes the attribute. That means translate="no" is not a guarantee on its own. It works best together with a solid layout and well structured scripts.

When does it make sense to block translation for a whole page?

Some pages really suffer from translation. A contract that only counts in its original language is one example. A technical document full of code samples is another. The Google Search Central page on special tags lists a meta tag for googlebot with the notranslate value. According to Google, it signals that you do not want Google to provide a translation for the page.

However, that tag concerns translation offers in search. For translation inside the visitor’s browser, the element level translate value is the more direct tool. Some browser translators also honor a notranslate class. Still, we suggest you treat that behavior as an assumption wherever official documentation does not confirm it.

Our general view, therefore, is that page level blocking should be the exception. If visitors cannot read your language and you block translation, they either find another tool or leave. Neither outcome helps you, because both cost you the visitor. Put simply, managing translation works better than banning it.

How do you protect your brand name from Google Translate?

A translated brand name causes both funny and harmful results. Consider an example scenario: a shop called "Blue Door Furniture" turns into a literal phrase in Spanish or German. Later, the visitor searches for that phrase and cannot find the business. Therefore, your brand name should stay identical everywhere.

1. List every place your brand name appears: logo text, headings, footer, contact card, and product names.
2. Add translate="no" to the small element around each instance.
3. If the logo is an image, keep the brand name consistent in its alt text.
4. Keep the brand name unchanged in the page title and meta description.
5. After the change, open the page with Google Translate in a few languages and check the result.

Also remember content from other sources. For example, the business name inside an embedded review widget may get translated too. Our guide on how to show Google reviews on your website covers the layout of such embeds. Finally, if you have brand guidelines, add a line saying the name never gets translated.

Which content should be translated, and which should stay protected?

To make decisions easier, we sort content into three groups. For example, some text can change freely. Some needs protection. The rest needs design support so longer text fits. The table below works as a quick decision aid.

A note on the legal row: this is not legal advice. Ask your attorney which language version of your terms is binding. On the site, a short note can explain that any translation is for information only.

How do you stop the navigation menu from overflowing?

Menu overflow is the most visible symptom, because it sits at the top of every page. A short word like "Services" can turn into a much longer phrase. If the menu reserves a fixed width for each item, the last item drops down or slides off screen.

• Do not give menu items a fixed width. Let them grow with their content.
• When items no longer fit, let them wrap neatly or switch to the mobile menu earlier.
• Also, cut the number of items. Fewer, clearer items mean less risk.
• Above all, never force menu labels onto a single line.

For the menu structure itself, see our website navigation menu design guide. It covers item count and hierarchy in detail. Meanwhile, an overflowing menu can also make the whole page scroll sideways. That is a separate and common issue, and our guide on a website that scrolls sideways on mobile walks through the fix.

Next, here is a quick thought test. Imagine your menu filled with the longest possible words. If the layout still holds, translation will most likely not hurt it either.

How do you build a layout that handles longer text?

A resilient layout starts with one assumption: you never know how long the text will be. With that mindset, boxes grow with their text, buttons can wrap onto two lines, and headings move down instead of getting cut off.

• Use padding instead of fixed heights and widths on buttons and labels.
• Avoid settings that force text onto one line and hide the overflow.
• Also, allow long words to break at the end of a line.
• In practice, accept from the start that cards may end up with different heights.
• Leave breathing room next to icons that sit beside text.

Readability plays a role here too. A page with balanced line length and font size absorbs longer text much better. We cover this in our guide on readable typography, line length, and line height.

In other words, a translation proof layout is not a separate project. A good flexible layout already adapts to different screen sizes. Translation is just one more test of that flexibility.

Why do forms and web apps stop working after translation?

Form and app problems are the sneakiest, because you cannot see them at first. Suppose a script finds the submit button by looking for the word "Send." After translation, that word changes, so the script fails. Likewise, scripts that rewrite text directly can clash with the extra structure the translator adds.

That is why we suggest two principles for your developer. First, scripts should find elements by IDs or data attributes, not by visible text. Second, small text fragments that must not change should carry translate="no".

1. Fill out and submit the form with translation off, and note the result.
2. Translate the page into another language with Google Translate.
3. Fill out the same form again and check required field warnings and the success message.
4. Test carts, filters, and tabs the same way.
5. Send any broken part to your developer with a screen recording.

If your site has a chat widget, include it in the test. If you want to serve multilingual visitors properly, a bot that answers in their own language beats relying on browser translation. Our page on AI chatbot development explains that approach.

How do you test Google Translate on your site step by step?

First, you do not need special tools for this. Desktop and mobile Chrome are enough. Instead, what matters is a systematic approach, not random clicking. Repeat the steps below after every major design change.

1. Pick a test set: the home page, one service page, one product page, and the contact page.
2. Open each page in its original language and take a screenshot.
3. Next, translate each page into at least two languages, one that lengthens words and one that shortens them.
4. Compare the menu, buttons, cards, and footer with the original screenshot.
5. Check whether the brand name and codes changed.
6. Use forms and interactive parts while the translation is active.
7. Repeat the same steps on a mobile screen.

Then sort each issue with three questions. Should this text have been translated at all? Can the layout carry longer text? Does a script depend on the text? The answers point you to the right fix. Also, keep the results in a short table so the next redesign does not repeat old mistakes.

Do Safari and other browsers behave differently?

Yes, the details vary from browser to browser. Chrome, Safari, and Edge each offer their own translation feature, and each may rewrite text in its own way. Consequently, a test in one browser does not represent every visitor.

Still, the good news is that the foundation stays the same everywhere. A correct lang value, translate="no" on protected parts, and a flexible layout help in all of them. Since MDN notes that not every browser recognizes the translate attribute, the flexible layout remains your real safety net.

Our practical advice is to check your analytics and pick the two most used browsers. Then run the full test in both. If many visitors use iPhones, do not skip Safari.

Also, treat mobile as its own step. A phone screen is narrow, so longer text overflows much sooner than on desktop. For example, a button that looks fine on a laptop may wrap onto two lines on a phone and push its icon down. So plan the mobile check separately, not as a quick repeat.

Is turning off translation completely a good idea?

For most businesses, the answer is no, because it creates new problems. Turning translation off does not solve the problem. It just makes the page unreadable for foreign visitors. They will still find a workaround, such as pasting the text into another tool. That takes the experience fully out of your hands.

The cases where blocking makes sense are narrow. Examples include a contract page where only the original text counts, a document where technical terms lose meaning, or a help page full of codes. Even there, show a short note that explains why translation is off.

Instead, the balance we recommend is simple. Keep the page translatable in general. Then protect only brand names, codes, and small script dependent parts. That way, visitors understand the content and your site stays intact.

When do you need a real multilingual site instead of browser translation?

Browser translation is a bridge, not a permanent solution. If foreign visitors are a small share of your traffic and only need basic information, that bridge may be enough. However, if you expect regular sales or quote requests from abroad, you need a real multilingual setup.

• You want to appear in search results in another language.
• Your quote form, contract, and pricing must be accurate in that language.
• You want your brand voice to come across with the same care in every language.
• You want each language version to exist as its own page in search.

Browser translation only happens on the visitor’s screen, and search engines do not index it as your page. We explain the search side in our multilingual website SEO guide. If you plan automatic language selection, read about the risks of an IP based language redirect first. For the switcher itself, see our guide to language switcher design.

Can Google Translate still cause trouble on a multilingual site?

It can, but far less often, because each version declares its language. On a real multilingual site, every version carries its own correct lang value. When the browser sees the visitor’s language, it has no reason to offer translation. However, visitors who speak a language you do not offer will still translate.

So the same basic rules apply. Protect the brand name, keep the layout flexible, and decouple scripts from text. For instance, if you offer English and Spanish but a visitor arrives from Japan, browser translation will still test your design.

That said, one common mistake deserves a mention. Teams forget to update lang on one of the versions. Then the Spanish version still says en from the theme, and the browser may offer translation even to Spanish readers. That small slip confuses both visitors and search engines. Therefore, check the lang value on every version before launch.

How much of this can you fix yourself?

Several steps need no technical background. Running the tests, listing your brand names, and documenting broken pages with screenshots are all things you can do yourself. In addition, if your content system allows it, adding translate="no" around a brand name is often a simple edit.

However, other tasks need design and coding skills. Turning a fixed width theme into a flexible one, decoupling scripts from visible text, or building a multilingual structure belong in this group. Here, a careless edit can create a bigger problem than the one you tried to solve.

If you start on your own, keep this order. First the lang value, then brand names, next menu and button overflow, and finally forms. This order begins with the cheapest and most effective steps. After each step, run the same test again. That way, you see clearly which change fixed which issue.

What should your pre launch checklist include?

Run the list below after every new page and every theme update. It is short, but it catches most problems.

• The lang value on the html element matches the real page language.
• Quotes and product names in other languages carry their own lang value.
• Brand names, product names, and codes sit inside translate="no" elements.
• The menu does not overflow even in the longest translation, and no sideways scroll appears.
• Buttons and cards grow with longer text.
• Forms submit while translation is active, and error messages appear.
• You ran the test in at least two browsers and on a mobile screen.
• You use page level blocking only on pages that truly need it.

Next, share this list with your team. Then everyone who adds content follows the same rules. As a result, you fix the problem once, and it does not come back.

When should you hand a translation proof build to a professional?

If your tests reveal several problems across menus, forms, and cards, the cause is likely the underlying structure. In that case, patching each issue separately costs more over time. A flexible layout, text independent scripts, and a clean language setup hold up much better when someone plans them from the start.

At Talha Aslan and team, we add a translation test to the pre delivery checklist of new projects. When you compare web design services, ask each team how they test translation and longer text. That one question reveals a lot about how flexible their builds really are.

In short, Google Translate is not your enemy. It is a free test that shows how flexible your site really is. With a correct lang value, a protected brand name, and a flexible layout, you pass that test with ease.