An English /en prefix can be valid
A multilingual site can use /en for English, just as it can use /he for Hebrew. Another valid design puts English at the root. The problem is unmanaged duplication and conflicting signals: for example, both /services and /en/services serving the same English page while links, canonicals and sitemaps disagree.
This project uses English at the root and prefixes its other supported languages, including Bangla, Hebrew and Arabic. That is a project convention, not a universal SEO rule. Its redundant English-prefixed paths redirect to the matching root paths. A site already organized consistently around /en need not migrate just to follow that convention. See Google's guidance on multilingual URL structures.
Map equivalent pages explicitly
Each genuine translation should normally canonicalize to its own preferred URL. Link the equivalent versions with reciprocal hreflang, including a reference to the current page. Use absolute URLs and a valid language code. x-default identifies a fallback for languages without a specific match; it does not mean that every page is English.
For example, an English service page can point to its Bangla, Hebrew and Arabic equivalents, and each equivalent returns the same cluster. A link to the homepage in another language is not a substitute for a missing service translation.
Translated navigation around an unchanged English article does not create a translated article. On this site, an article translation receives its own canonical URL and reciprocal language links only when translated main content is available. A language URL still showing the English source points to the English canonical and is excluded from the translation cluster. Google's localized-version reference explains reciprocal annotations and untranslated main content.
Check the HTML and the reading direction
Return a meaningful lang attribute with the server HTML. Hebrew and Arabic need dir="rtl"; use logical start/end properties for layout. Isolate left-to-right values such as email addresses, URLs and product names where they would otherwise reorder confusingly. Language metadata does not replace readable, correctly translated content.
A practical release review
- Request one representative URL in each language without browser JavaScript and inspect the title, canonical, language and headings.
- Follow alternate-language links in both directions and confirm they resolve successfully to equivalent content.
- Keep only preferred, published URLs in the sitemap. Exclude tracking variants, empty collections and drafts.
- Confirm a preview host delivers
noindexin an HTTP header or HTML meta tag, while production remains indexable. Allow crawlers to fetch the preview page so they can read that directive. - Exercise language switching on a service, an article and the enquiry form, including direct loads and remembered preferences.
The noindex behavior follows Google's indexing-control guidance. These checks support consistent discovery; they do not promise rankings. For implementation help, see web development and the secondary technical SEO service.
