Illustrated sunset landscape where two winding paths, one from the left and one from the right, meet at a blank signpost on a hill, for a guide to bilingual WordPress SEO.

هذا المقال متوفر باللغة العربية — اقرأ بالعربية

Running a site in Arabic and English doubles your reach, but it also doubles the ways search can go wrong. The Arabic page ranks in the US, the English page shows up for Arabic searches, or Google picks one version and quietly ignores the other. That’s what bilingual WordPress SEO is mostly about, removing that confusion: clear URLs for each language, hreflang tags that agree with each other, sensible slugs, and content that is written for how people actually search in each language.

This guide sticks to what Google documents in Search Central and what the WPML and Polylang teams document about their own plugins. We’ll cover URL structure, hreflang and x-default, slugs, redirects, translated metadata, Arabic keyword research, sitemaps and the Search Console checks worth doing after launch.

How Google sees a site in two languages

A few facts from Google’s documentation shape everything else in this guide:

  • Google uses the visible content to detect a page’s language. It doesn’t use the lang attribute or the URL for that. So the Arabic page has to actually be in Arabic, navigation included.
  • Each language should have its own URL. Google recommends different URLs per language rather than switching the language on one URL with cookies or browser settings.
  • Translated pages aren’t duplicates. Google says localized versions are only considered duplicates if the main content stays untranslated.
  • Avoid side-by-side translations. Google suggests one language for content and navigation on each page, rather than Arabic and English mixed on the same page.

Even though Google doesn’t use lang to detect language, keep <html lang="ar" dir="rtl"> correct on Arabic pages. The W3C recommends always declaring the page language, and screen readers and browsers rely on it. WordPress sets these from the site language, and WPML and Polylang switch them per language.

Choosing a URL structure

Google’s multi-regional and multilingual guide lists four options:

Structure Example Pros (per Google) Cons (per Google)
Country-specific domain (ccTLD) example.com.eg, example.sa Clear geotargeting, easy separation of sites Expensive, more infrastructure, can only target one country, sometimes strict requirements
Subdomains ar.example.com Easy to set up, allows different server locations Users may not recognize the targeting from the URL alone
Subdirectories example.com/ar/ Easy to set up, low maintenance on the same host Single server location, sites are harder to separate
URL parameters example.com/?lang=ar None listed Not recommended

For most bilingual businesses in Egypt and the Gulf, subdirectories like /ar/ and /en/ are the practical choice. You’re targeting two languages, not two countries, and one WordPress install with one domain is the easiest to maintain. WPML’s own documentation calls the directory format its default and most common choice. Choose a ccTLD per country only if you truly run separate markets with different products, prices or legal requirements.

One update worth knowing: Search Console used to have an International Targeting report where you could set a country for a site. Google deprecated it in 2022 and said it continues to support hreflang. So country targeting now comes from your URL structure, hreflang and content, not a Search Console setting.

Hreflang and x-default done right

The rules that matter

Hreflang tells Google which pages are language versions of each other. From Google’s documentation:

  • Each language version must list itself as well as all other language versions.
  • Alternate URLs must be fully qualified, including https://.
  • If two pages don’t point to each other, the tags are ignored. Return links are required.
  • You can use HTML tags, HTTP headers or the sitemap. The three are equivalent for Google, and using more than one adds no benefit.
  • The language code uses ISO 639-1, with an optional region in ISO 3166-1 Alpha 2. A region code alone is invalid.

What it looks like on a bilingual page

Both the Arabic and English versions of a services page should carry the same set of tags:

<link rel="alternate" hreflang="en" href="https://example.com/en/services/" />
<link rel="alternate" hreflang="ar" href="https://example.com/ar/services/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/en/services/" />

Choosing x-default

Google describes x-default as the fallback for users whose language doesn’t match any of your versions. It was designed for language selector pages and works best with those, but you can use it on any page. On a site without a selector page, point x-default at the version you want unmatched visitors to land on. For most sites in the region that’s English, since a visitor searching in French or Turkish is more likely to read English than Arabic.

Plain “ar” or “ar-EG”?

Use plain ar and en unless you really have different pages for different countries. Region codes such as ar-EG or ar-SA are valid, but they only make sense when you have separate versions, for example different prices or delivery terms for Egypt and Saudi Arabia. Google notes that codes like UK or EU aren’t valid region codes and are ignored. For the United Kingdom the code is GB.

Canonical tags and hreflang together

Each language page should have a canonical pointing to itself. Google’s guidance is to specify a canonical page in the same language. A common mistake is setting the Arabic page’s canonical to the English page, which tells Google to drop the Arabic version.

How WPML and Polylang output hreflang

WPML

According to WPML’s documentation, it automatically inserts hreflang tags pointing every page to its translations, placed as early as possible in the head by default. The settings live under WPML, Settings, URLs and SEO. Check which URL your pages mark as x-default in the page source. If a developer needs to change the output, for example to point x-default at a different version, WPML documents filters for it, including wpml_alternate_hreflang and wpml_hreflangs_html. A good habit with any multilingual plugin is to create content in your default language first and translate from it, so every page has a complete set of versions.

Polylang

Polylang also adds hreflang tags automatically. Its documentation says it outputs x-default only on the home page when the home page is auto-redirected, not on every page. If you want x-default on all pages, Polylang documents the pll_rel_hreflang_attributes filter. A safe version that only adds x-default when an English translation exists:

add_filter( 'pll_rel_hreflang_attributes', function( $hreflangs ) {
    if ( isset( $hreflangs['en'] ) ) {
        $hreflangs['x-default'] = $hreflangs['en'];
    }
    return $hreflangs;
} );

Check the final output

Whatever plugin you use, open a few pages, view the source and search for hreflang. You want one clean set per page, with self-references, return links on the other language, and no duplicate sets added by a second plugin or by the theme. Check a post, a page, a category archive and, if you have WooCommerce, a product.

Translated or shared slugs: the honest tradeoffs

This is where bilingual sites disagree the most, and there’s no single right answer. Google’s URL guidance says to use words in your audience’s language in URLs, and its own example of a properly percent-encoded URL happens to be Arabic. That’s the catch: an Arabic slug like /ar/خدمات/ travels as /ar/%D8%AE%D8%AF%D9%85%D8%A7%D8%AA/ when copied, shared on some apps or pasted into an email.

Your options:

  • Arabic slugs. Readable in the browser bar and in search results, and matched to the Arabic query. The downside is long encoded links when shared outside the browser, and messier analytics reports.
  • Transliterated slugs. WPML’s documentation says that when you choose to translate slugs and the language uses a non-Latin script such as Arabic, it automatically transliterates the slug into Latin letters. Short and shareable, but not real words for either audience.
  • Shared English slugs. WPML offers an option to copy the original slug when the translation language would produce encoded URLs. Polylang Pro can share the same slug across translations. Clean and consistent, but the Arabic URL carries no Arabic keyword.

Our usual advice: short English or transliterated slugs for service pages and products, because they get shared most on WhatsApp and social media, and Arabic slugs only if your team is comfortable with encoded links. Whatever you pick, decide before launch. Changing slugs later means redirects for every URL. Also remember that Polylang Pro can translate URL bases such as category and WooCommerce product bases, which matters if you don’t want English words inside Arabic URLs.

Don’t auto-redirect by IP or browser language

Google is direct about this. Its guide says to avoid automatically redirecting users from one language version to another based on what you think their language is, because it can prevent users and search engines from seeing all versions. It also says not to use IP analysis to adapt content. Googlebot usually crawls from the US and sends requests without an Accept-Language header, so it may never see your Arabic pages if you redirect based on either.

Both plugins have redirect features, so check them:

  • WPML has a browser language redirect that is disabled by default. Its options are “only if a translation exists” or “always”, and it uses JavaScript.
  • Polylang has a “detect browser language” setting that redirects first-time visitors to the home page in their browser’s language, and sets a cookie for returning visitors.

The safer setup is no automatic redirect, plus a clear language switcher on every page that links to the same page in the other language. Google recommends exactly that kind of link. If marketing insists on a nudge, a small banner suggesting the other language is far safer than a forced redirect.

Beyond hreflang: bilingual WordPress SEO for titles, meta, alt text and schema

Hreflang only connects pages. Ranking depends on what’s on each page, and that’s where many bilingual sites cut corners.

  • Titles and meta descriptions. Write them separately in your SEO plugin for each language. WPML documents a WPML SEO add-on that translates the SEO fields of Yoast SEO and Rank Math. Don’t leave English meta on Arabic pages.
  • Alt text. Google uses alt text, along with computer vision and page content, to understand images. Write it in the page’s language. In WordPress, media translation settings decide whether each language gets its own alt text, so check yours.
  • Structured data. Google requires structured data to describe content that is visible on the page. If the Arabic page shows Arabic text, the schema on it should be in Arabic too. The schema.org inLanguage property can state the language of the content.
  • Menus, widgets and theme strings. Translate everything, including buttons, footer text and form labels. Leftover English on Arabic pages works against Google’s “one language per page” advice.
  • Internal links. Arabic pages should link to Arabic pages. A link from an Arabic article to the English contact page is a small leak that adds up.

We wrote separately about how Arabic sites get cited in Google AI Overviews. The foundations in this guide are the same ones those features rely on.

Do separate Arabic keyword research

Translating your English keywords into Arabic is the fastest way to target words nobody types. Arabic search varies by country and by habit:

  • Egyptian and Gulf vocabulary differ. A mobile phone is commonly «موبايل» in Egypt and «جوال» in Saudi Arabia. A car is often «عربية» in everyday Egyptian speech and «سيارة» elsewhere.
  • Formal and dialect forms both appear. People search in a mix of Modern Standard Arabic and dialect, depending on the topic.
  • English terms in Arabic searches. Many Arabic speakers search technical and brand terms in English, or in Arabic transliteration, such as «ووكومرس» next to «WooCommerce».
  • Spelling variations. People type the same word with and without hamza, or with «ه» instead of «ة». Note the variants you see in your own query data.

Use Google Trends to compare terms and look at interest by region, so you can see whether a word is more popular in Egypt or in Saudi Arabia. Then check the queries in Search Console after a few weeks. If your main market is one country, write for its vocabulary. If you serve both, use Modern Standard Arabic as the base and mention the local terms naturally where they fit.

Sitemaps per language

  • Make sure your sitemap includes both Arabic and English URLs. WPML says it provides per-language sitemaps when used with an SEO plugin like Yoast SEO or Rank Math.
  • Google allows you to submit multiple sitemaps, which helps you track the performance of each one. Separate Arabic and English sitemaps make indexing problems easier to spot.
  • Sitemaps must be UTF-8 encoded, and each one is limited to 50MB uncompressed or 50,000 URLs.
  • Google notes that a sitemap can only contain URLs under the directory where it’s hosted, so keep sitemaps at the root unless you know what you’re doing.
  • You can also declare hreflang inside the sitemap with xhtml:link entries. If your plugin already outputs hreflang in the HTML, one method is enough.

Search Console checks after launch

  1. URL Inspection on both versions. Inspect an Arabic page and its English twin. Check that each is indexed and that the Google-selected canonical is the page itself, not the other language.
  2. Page indexing report. Look for Arabic URLs under “Duplicate” or “Alternate page” statuses that you didn’t expect.
  3. Performance by language. In the Performance report, filter pages by URL containing /ar/ and then /en/, and compare queries and countries.
  4. Sitemaps report. Confirm each sitemap is read successfully and the discovered URL counts make sense.

Since Search Console no longer has a hreflang report, use a third-party hreflang checker or a site crawler to validate tags in bulk. Google’s documentation lists a couple of such tools while noting it doesn’t maintain them.

Common mistakes and how to fix them

Mistake What happens Fix
Missing return links Google ignores the hreflang pair Make sure both versions list each other and themselves
Arabic canonical points to the English page The Arabic version drops out of the index Self-referencing canonical on every language page
Auto-redirect by IP or browser language Googlebot and some users never see the other version Turn it off and use a visible language switcher
Region code used as language, such as eg The annotation is invalid Language first: ar or ar-EG
English meta and alt text on Arabic pages Weak snippets and mixed-language signals Translate SEO fields and media separately
Machine-translated Arabic Pages that don’t match how people search Write or adapt Arabic with a native writer and Arabic keyword research
Changing slugs after launch Broken links and lost rankings Decide the slug strategy before launch, redirect if you must change
Two plugins outputting hreflang Conflicting or duplicated tags Keep one source and check the page source

Frequently asked questions

Do I need hreflang if my Arabic and English pages are clearly different?

Google may find alternate versions on its own, but it says it’s usually best to indicate them explicitly. With WPML or Polylang it’s automatic, so there’s no reason to skip it.

Should the default language be Arabic or English?

Pick the language most of your customers use. In both WPML and Polylang it decides which version can sit at the root of the domain without a language folder, and it’s the language you’ll usually write first and translate from.

Is it bad for SEO to have Arabic letters in URLs?

No. Google supports them and recommends words in your audience’s language. The tradeoff is practical: encoded links when shared and harder-to-read reports.

Can I target Egypt and Saudi Arabia with one Arabic version?

Yes, with plain ar. Create ar-EG and ar-SA versions only if the content really differs, like prices, shipping or legal terms.

A final word

A bilingual site that’s set up correctly gives each language a fair chance to rank on its own. Most of the work happens once, at the start: URL structure, plugin settings, slugs and redirects. If you’re planning a bilingual build or fixing one that isn’t ranking, our WordPress development team can set it up properly, and you can start with a free consultation. If you’d rather learn to do it yourself, take a look at our courses.

References