A language switcher does not make a site multilingual. The URLs, page ownership, metadata, content model, direction, internal links, and feeds must agree about which translations really exist.
The most damaging shortcut is to generate an English alternate for every Arabic path. If the translated page does not exist, search engines and users are sent to a different page or a language hub. That is not a translation.
Give each language stable URLs
Use a predictable structure such as Arabic at /blog/article/ and English at /en/blog/article/. Each page should canonicalize to itself. The language prefix is part of the public interface, so avoid changing it casually after pages are indexed.
Do not redirect every unknown English article to the English blog index. Return a real 404 when content is missing.
Store translation relationships explicitly
An English content entry can require sourceSlug, while the Arabic entry remains the source record. At build time, validate that the source exists and that two English entries do not claim the same source.
This explicit mapping supports language navigation, reciprocal alternates, related content, and editorial tracking. Guessing relationships from the current URL works only while every slug is identical.
Emit alternates only for real pairs
When both versions exist, Arabic and English pages should point to each other with hreflang, and both can point x-default to the chosen default. If no translation exists, omit the alternate links.
The language control should follow the same rule. On a translated article it opens the matching article. On an untranslated one it can link to the other language’s blog hub, but its label should not imply that it is a translation of the current page.
Separate content collections when schemas differ
An English collection can require review dates, source slugs, service relationships, and social images without forcing those fields onto old Arabic drafts. Shared rendering components can still receive a normalized article model.
Build validation should reject missing images, invalid dates, duplicate metadata, and broken source relationships before deployment.
Handle RTL in structure and CSS
Set lang and dir on the document. Use logical properties for spacing and borders. Test mixed strings such as product codes, URLs, email addresses, and English library names inside Arabic sentences.
Do not create two unrelated component systems for RTL and LTR. One component with semantic direction-aware rules is easier to maintain, but it still needs visual testing in each language.
Localize discovery surfaces
Translate breadcrumbs, navigation, service links, article metadata, empty states, form errors, and 404 pages. Generate a separate RSS feed for English content, with English item URLs and language metadata.
Related article logic should compare stable tags or editorial relationships. It should never send an English reader to an Arabic article without making the language change clear.
Audit the built HTML
After the production build, inspect every canonical, alternate, title, description, language attribute, structured-data URL, and sitemap entry. Verify that each alternate URL exists and points back.
Astro makes static multilingual output straightforward. The difficult part is editorial honesty: publish only the translations you have, connect them explicitly, and let build checks reject the rest.