Looks like you're in . Want the local site?
Operating in both Arabic and English means your WordPress site cannot be an afterthought. Elementor's RTL support is a workaround, not a solution. A custom WordPress theme built with RTL-first architecture handles Arabic content, bidirectional layout, and bilingual SEO from the foundation up.
You built your site on Elementor and enabled an RTL plugin to handle Arabic. The Arabic layout works in some places and breaks in others. The font rendering is inconsistent. The mobile layout flips incorrectly on certain devices. Your Arabic content team works around the limitations rather than solving them. A custom WordPress theme built RTL-first means Arabic is not an afterthought added onto an LTR framework; it is part of the architecture from the first line of CSS.
You were brought in to maintain or extend a site that someone else built with a visual builder and an RTL toggle. You can see the workarounds. The Arabic templates are duplicated LTR templates with directional CSS overrides. Content is managed in two separate systems that are not connected. Custom WordPress development with proper bilingual post types, ACF language fields, and RTL-native CSS means the Arabic and English versions of your site share a single, maintainable architecture.
Your editors maintain Arabic and English content in parallel, often in separate WordPress installations or with a plugin that doubles the admin overhead. Updates to one language version must be manually mirrored in the other. Custom post types with language-aware fields and a Gutenberg block library built for bidirectional layout means your editorial team manages both languages from a single, structured interface.
Elementor and Divi handle RTL by flipping the direction CSS property and applying margin and padding overrides. This works for simple layouts. It fails for complex ones: multi-column sections, icon positioning, navigation menus, and animation directions. Arabic is not a mirrored version of English. A custom WordPress theme designed RTL-first handles directional layout at the CSS architecture level, not as a patch applied after the fact.
Running a bilingual site in Elementor means either maintaining two separate template sets or using a translation plugin that adds significant complexity to the editing workflow. Neither approach gives you a clean, queryable content structure. Custom post types with ACF fields for each language mean that Arabic and English content for the same item (a service, a team member, a case study) live in the same post and are managed in the same edit screen.
Page builders load heavy asset libraries that perform poorly on mobile connections, which make up a significant portion of traffic in the UAE market. A site with Elementor, an RTL plugin, a translation plugin, and a caching plugin fighting each other will produce Core Web Vitals scores that damage both user experience and search rankings. Custom themes load only what each page needs.
Bilingual sites are more complex than single-language sites. A change to a shared template affects both Arabic and English outputs. A plugin update can break RTL rendering site-wide. Testing on the live site is not a maintenance strategy. Custom WordPress development at Ignited Nepal includes a staging environment and Git version control on every project, regardless of complexity.
We document the full site architecture before writing code: page templates, post types, language fields, RTL CSS strategy, third-party integrations, hosting environment, and performance targets. For bilingual builds, the specification covers how Arabic and English content is structured, stored, and served. You approve the specification before development begins.
We build a custom PHP theme with bidirectional CSS architecture from the ground up. No Elementor. No Divi. The theme handles LTR and RTL layout natively, without a directional override plugin. Arabic typography, font loading, and text rendering are handled at the theme level. The result is a site where Arabic is a first-class layout, not a mirrored copy of the English version.
We register custom post types for every content type your site needs and configure ACF fields for Arabic and English content within the same post. Services, team members, case studies, and testimonials are managed in a single edit screen with language-specific fields. Content stays consistent, queryable, and correctly associated between language versions.
We build a Gutenberg block library with RTL-aware layout logic. Each block handles directional rendering at the block level. Editors can compose Arabic and English pages from the same block library without needing to manage separate template sets or worry about layout direction.
We audit every active plugin for RTL compatibility, performance impact, and redundancy. Plugins that break Arabic layout, load unnecessary assets, or duplicate native functionality are removed. For bilingual requirements, we use the most lightweight approach that achieves the content goals: often custom post type fields rather than a translation plugin.
We optimise for Largest Contentful Paint, Cumulative Layout Shift, and Interaction to Next Paint. For bilingual sites, we pay particular attention to Arabic font loading (subsetting for the Arabic character set), conditional asset loading for LTR and RTL stylesheets, and CDN configuration for UAE-region traffic. We target green PageSpeed scores on both mobile and desktop before launch.
Every project has a staging environment that mirrors production. All code is version-controlled in Git. Changes to shared templates that affect both language versions are tested on staging before deployment. You receive repository access at handover.
We write editorial documentation for both the Arabic and English content workflows: how to add a post in each language, how to update custom fields, how to use each Gutenberg block. We run a bilingual pre-launch checklist covering hreflang tags, RTL rendering across devices, Core Web Vitals, and analytics. Launch is planned and coordinated.
We audit your current site or scope your new build. For existing bilingual sites, we document the current language architecture, RTL implementation, plugin dependencies, and Core Web Vitals performance across Arabic and English pages. We produce a written diagnostic report covering what to rebuild, what to retain, and how to approach the bilingual content structure.
We write the technical specification covering RTL CSS architecture, post types and language fields, block library components, hreflang implementation, and hosting requirements. Design is developed for both Arabic and English layouts simultaneously, not as a sequential adaptation. You approve the specification before development begins.
Development happens on a staging environment. We build in sprints: RTL-first theme scaffolding, post types and ACF with language fields, bilingual Gutenberg block library, template files for both language directions, and performance optimisation. You review staging at the end of each sprint in both Arabic and English. Nothing goes to production until it is approved in both languages.
We run the bilingual pre-launch checklist: hreflang tags, RTL rendering across devices and browsers, Arabic font loading, Core Web Vitals, analytics, and sitemap. We deploy from the Git repository to production. We deliver repository access, bilingual editorial documentation, and a handover walkthrough for your Arabic and English editorial teams.
Elementor's RTL support relies on directional CSS overrides applied after the LTR layout is rendered. For simple single-column pages it functions adequately. For multi-column layouts, navigation menus, icon positioning, and animation direction, the workaround approach produces inconsistencies across devices and browsers. A custom theme with RTL architecture built in from the start handles Arabic layout at the foundation, not as a patch.
No. We structure bilingual content using custom post types with ACF language fields, so Arabic and English versions of the same content item live in the same post and are managed in the same screen. This approach avoids the admin overhead and synchronisation problems of running two installations or a translation plugin with duplicated templates.
We subset Arabic font files for the specific character ranges your content uses, which significantly reduces font payload. We configure font loading to avoid layout shifts during rendering, which improves Cumulative Layout Shift scores. Arabic font selection is part of the design specification and reviewed with you before development begins.
Yes. We implement hreflang tags for language and region targeting, configure separate sitemaps for Arabic and English content, and optimise Core Web Vitals for UAE-region delivery including CDN configuration. On-page SEO for Arabic content follows Arabic keyword and user intent considerations. We advise on bilingual content strategy during the specification phase.
We offer a monthly maintenance retainer covering WordPress core and plugin updates, RTL rendering checks after major updates, performance monitoring, and content update support for both Arabic and English. If you prefer to manage the site in-house, the Git repository, technical specification, and bilingual editorial documentation give your team and any future developer a complete picture of how the site works.
Not a black box. Real specialists you can call, with their names on the work.
If your bilingual site has Arabic layout issues, slow load times on mobile, or a content workflow that requires a developer for every update, the problem is the page builder architecture underneath it. A custom WordPress build from Ignited Nepal gives you RTL-first architecture, structured bilingual content, and a codebase that any developer can maintain. Start with a diagnostic.
Ignited Nepal
Growth engineering · replies within 1 business day
By continuing you agree to our privacy policy.
