Most personal injury firms that go after Spanish speaking or Arabic speaking clients do it the cheap way: a translation plugin, a language toggle in the header, and an English intake team that scrambles when a Spanish voicemail arrives. The result is a site that does not rank, pages that read like a machine wrote them, and leads that go cold on the first callback. Building for these audiences properly is not exotic. It comes down to structural decisions Google documents publicly, layout rules the W3C has published for years, and an intake process that matches the language of the person filling out the form.
Separate URLs for Each Language, Not a Toggle
The first decision is structural. Google recommends using different URLs for each language version of a page rather than using cookies or browser settings to adjust the content language. A JavaScript toggle that swaps text on the same URL effectively hides your Spanish content from search. If you dynamically change content based on language settings, Google might not find and crawl all your variations, because the Googlebot crawler usually originates from the USA. Your English homepage gets indexed and your Spanish version may as well not exist.
Throughout this article I will use CheckMyAccidentValue.com as the working example, and here is the disclosure in one plain sentence: it is built and operated by Legal Gridlock. The English experience lives at the root of the domain, and the Spanish site lives under /es/ with its own URL for every page, so each version can be crawled, indexed and ranked on its own merits.
Hreflang and Canonical Tags Done Right
Once each language has its own URLs, connect them. If you use different URLs for different languages, use hreflang annotations to help Google Search results link to the correct language version of a page. Google supports several methods for labeling language variants, including hreflang annotations and sitemaps. Pick one method and apply it consistently. An x-default value tells search engines which fallback version to show users whose language or region does not match any localized version.
Canonical tags are where bilingual sites most often shoot themselves in the foot. Language variants should not canonicalize to each other; each language version is a distinct canonical URL. Pointing the Spanish page's canonical at the English page tells Google to ignore the Spanish page. The duplicate content fear behind that mistake is unfounded: Google treats localized versions of a page as duplicates only if the main content of the page remains untranslated. A fully written Spanish page is not a duplicate of anything.
Write Natively for Each Audience, Do Not Translate
Google uses the visible content of your page to determine its language, and does not use code-level language information such as lang attributes or the URL. Ranking in Spanish therefore requires real Spanish content, researched in Spanish. Someone searching for accident help in Spanish uses phrases like abogado de accidentes or cuanto vale mi caso, not a word for word translation of your English headlines. The same is true in Arabic, where you also have to decide between Modern Standard Arabic for published pages and dialect-aware phrasing for conversational intake.
Google's guidance supports the one page, one language discipline: use a single language for content and navigation on each page, and avoid side-by-side translations. Every Spanish page on the example site carries its own copy, adapted for Spanish speaking readers and served as a real page rather than swapped in by a plugin, and the case study walks through how that build was structured.
Right-to-Left Layout for Arabic, Not a Mirrored Afterthought
Arabic pages need direction handled at the markup level. The dir attribute sets the base direction of text for display and is essential for languages that use right-to-left scripts such as Arabic. If the overall document direction is right-to-left, add dir=\"rtl\" to the html tag. Setting lang=\"ar\" is not enough: the lang attribute declares the language but does not imply the base direction. And never use CSS to apply the base direction; instead use logical start and end values on margins, padding and alignment so direction changes are easy to manage during localization.
This is also why mixing Latin and Arabic script in a single line breaks layouts. Directionally neutral characters cause the trouble: parentheses and brackets have no inherent direction, so a parenthesis sitting between left-to-right and right-to-left runs cannot inherit direction from the surrounding text and defaults to the paragraph's base direction, landing on the wrong side. W3C's accessibility techniques show the same failure with quotes: the Unicode bidirectional algorithm alone is insufficient and leaves the Latin text on the wrong side. Keep each headline, button and line in one script. When an English firm name or phone number must appear inside Arabic text, follow the W3C pattern: if text with a left-to-right base direction is embedded in a right-to-left document, add a dir attribute to its enclosing element. For intake forms, set the dir attribute to auto on forms so the direction of user-supplied content is detected automatically.
Local City Pages That Are Genuinely Local
A find-and-replace template that swaps Houston for Dallas fools nobody, in any language. Each city page should stand on its own: the courts and venues that handle injury cases there, the highways and intersections where crashes actually cluster, the neighborhoods where the language community lives, and the local logistics of getting medical care and police reports. Google's warning about thin localization points the same way: translating only the boilerplate of pages while keeping the bulk of content in a single language creates a bad user experience when the same content appears repeatedly in search results. The lesson applies within one language too. If two city pages are interchangeable after swapping the city name, neither deserves to rank.
Intake, Consent and Callbacks in the Language of the Page
Ranking is wasted if the conversation after the form breaks the trust the page built. The legal backdrop matters here. Under the TCPA, businesses must obtain prior express written consent to send marketing text messages or make marketing robocalls, and the statute provides a private right of action with statutory damages of 500 to 1500 dollars per violation, with no requirement to prove actual injury. The FCC defines prior express written consent as a written agreement clearly authorizing the calls or texts, specifying the phone number, and including the person's signature. Opt-in requirements include clear disclosures, documented consent and notice that consent is not a condition of purchase, and businesses must offer a simple revocation method such as replying STOP and honor it promptly. New FCC opt-out rules began taking effect on April 11, 2025, with some provisions postponed, so check the current status before you update your scripts.
The rules are also still moving. The FCC adopted a one-to-one consent rule in December 2023 to close the lead generator loophole, but the Eleventh Circuit vacated it in January 2025, days before it was set to take effect, and the FCC may revisit the rule while state laws suggest tighter standards could return.
Now the language point. A consent disclosure only does its job if the person can read it. An English-only checkbox under an Arabic form is a conversion killer and an invitation to dispute what was agreed to. Put the consent language, the confirmation text and the callback in the language of the page. A lead from the Spanish site should reach a Spanish speaker on the first call, not a phone tree in English. None of this is legal advice; have your counsel review the consent language in every language you publish.
What Your Firm Should Do Now
- Move each language to its own URLs, such as /es/ and /ar/, and retire the toggle that swaps content in place.
- Add hreflang annotations across all versions, including x-default, via tags or sitemaps.
- Audit canonicals so no language version points at another language version.
- Commission native-language content built on query research done in that language, not translations.
- Set dir=\"rtl\" on the html element of Arabic pages, use logical CSS properties, and keep each line in a single script.
- Rewrite city pages until each one contains facts that are true only of that city.
- Translate consent disclosures, confirmation texts and opt-out instructions into the page language, and have counsel review them.
- Staff or route intake so Spanish and Arabic leads get a same-language response fast.
The Bottom Line
A translated copy of the English site fails because it treats language as a skin instead of an audience. Separate URLs, correct hreflang and canonicals, native writing, proper right-to-left markup, genuinely local pages and same-language intake are each individually unremarkable. Together they are the difference between a Spanish or Arabic site that decorates your footer and one that signs cases.
