How to Filter Arabic Queries in Search Console
How to isolate Arabic-script queries in Search Console with a regex filter, why there's no built-in language filter, and how to report the result.
Search Console has no built-in language filter, so you isolate Arabic queries with a "Custom (regex)" filter on the query field, matching the Arabic Unicode block. That single filter turns a blended, bilingual report into two separate, honest ones — and it takes about two minutes to set up once you know the pattern.
That kind of query-level detail is one input into the fuller SEO reporting process, which covers how the rest of a report should be built once the raw data is clean.
On this page
Why filter by language in the first place?
Because an average hides exactly the kind of problem you need to see. A site with strong English pages and weak Arabic pages will show a perfectly reasonable blended average, and the Arabic-side problem stays invisible until someone thinks to separate the two — usually well after it has cost real traffic. This matters for any bilingual site, and it matters more the larger the gap between how much content and effort each language version has actually received.
It also matters because English and Arabic content on the same site often target genuinely different audiences with different expectations, not just a translated version of the same page. A query filter that separates them lets you judge each version against its own baseline instead of against a combined number that was never a fair comparison for either one.
| Filter type | Answers |
|---|---|
| Custom (regex) on query | Which language or script was the search in? |
| Country | Where in the world did the search happen? |
| Page | Which URL, and by extension which language version, ranked? |
How do you write a regex that reliably catches Arabic queries?
With a pattern matching the Unicode range Arabic script occupies — a filter such as one or more characters between U+0600 and U+06FF, applied under "Custom (regex)" in the Performance report's query filter [1]. Search Console's regex filters use RE2 syntax, which supports Unicode character classes, so this pattern works without any special escaping beyond what the filter box expects.
This one filter does more work than it looks like it should. Because it matches on the script of the characters typed, not a declared language setting anywhere, it catches genuinely mixed-language behaviour too — a query typed mostly in Arabic with an English brand name inside it will still match, which is usually what you want, since that whole query represents one real search intent regardless of which script any single word in it happened to use.
Open the Performance report and add a filter
Query > Custom (regex), then enter the Unicode range pattern for Arabic script.
Sanity-check a handful of results
Confirm the matched queries are actually Arabic and not Persian or Urdu, which share the same Unicode block and will also match.
Save the filtered view or export it
A filter you rebuild from memory every month is a filter that eventually gets typed wrong.
Repeat with the filter inverted for the non-Arabic comparison
Seeing both halves side by side is what actually reveals a gap between them.
Why doesn't Search Console just have a language filter?
Because Search Console's Performance report is built around what Google itself logs about a search — the query text, the country, the device, the page — and language is not one of the fields Google attaches to a query row [2]. A regex filter is a workaround built on top of the query text itself, not a native language dimension, which is also why it can only ever be as accurate as the pattern you write.
How do you combine this with a country filter?
By applying both at once, because they answer genuinely different questions. A country filter alone conflates an English search from inside the Gulf with an Arabic search from the same country, and a script filter alone conflates an Arabic speaker searching from inside the region with one searching from outside it. Together, the two filters tell you not just what language someone searched in but roughly where they searched from — useful when a site serves a broad Arabic-speaking audience across several countries rather than one single market.
This combination is also where a language-only view can mislead on its own. A rising count of Arabic queries from a country your business does not actually serve is a different finding than the same rise concentrated in a market you are targeting, and only the two filters together will tell them apart.
Do the same check in reverse for the English side of a bilingual site. A country filter on a Gulf or wider MENA market combined with the inverse of the Arabic regex will show you English-language demand from Arabic-speaking regions — a real and sometimes sizeable audience that a language filter alone, applied only to find Arabic queries, would never surface on its own.
How does this connect to the rest of your reporting?
The split should not stop at Search Console. Once you know which sessions were driven by Arabic-language demand, carry that same distinction into GA4 by segmenting on the Arabic pages' landing paths, and into your CRM by checking whether leads from those pages convert at a different rate than the English side. SEO KPIs by stage still applies here — the funnel stages do not change by language, but the numbers behind each stage might, and a report that never separates them cannot show you where.
It is also worth checking this split against anything unusual happening on the AI side. Tracking AI referrals covers assistant traffic broadly, and an Arabic-language assistant conversation citing your site is exactly the kind of session that a language-blind report would file under a generic "referral" bucket without anyone noticing which language actually drove it in the first place.
The bilingual sites that improve fastest are the ones that stop treating Arabic as a subset of the English report and start treating it as its own report that happens to share a domain. The regex filter is a two-minute setup for a distinction that changes how you read every number after it.
What do you actually do with the split once you have it?
Compare growth rates, not just totals. A blended report can show steady overall growth while one language version is flat or declining, hidden behind the other's gains. Once the filter is in place, that comparison takes one extra glance rather than a separate investigation, and it is worth including as its own line — not a footnote — in any report for a site that genuinely serves both audiences. SEO forecasting is more reliable once it is built on two clean trend lines instead of one blended one that was quietly averaging two different stories together.
Use the split to prioritise, too, not just to report. If the Arabic version of a page is carrying a fraction of the impressions the English version gets for an equivalent query, that is a concrete, specific brief — translation quality, missing internal links from the Arabic side, or a thinner page — rather than a vague instruction to "improve Arabic SEO." The filter turns a broad goal into a page-by-page list of exactly where the gap actually sits.
Questions people also ask
Does Search Console have a filter for query language?
No, not a dedicated one. There is no dropdown for "show me Arabic queries." You isolate them with a regex filter on the query field instead, matching the Unicode range Arabic script occupies.
What regex catches Arabic-script queries?
A pattern matching the Arabic Unicode block, such as one or more characters in the range U+0600 to U+06FF, applied as a "Custom (regex)" query filter in the Performance report. It will also catch Persian and Urdu text, which share the same block, so review the results if your market is Arabic-only.
Should I filter by country instead of by script?
Use both together when you can. Country tells you where a search happened; script tells you what language it was in. A Gulf-based visitor searching in English and an Arabic-speaking visitor searching from outside the region are both real audiences a country filter alone will conflate.
Why would I bother separating Arabic queries if my site is bilingual anyway?
Because a bilingual site's English and Arabic pages usually perform differently, target different intents, and need different fixes. A blended report that never separates them will hide a problem specific to one language behind a healthy-looking average.
Sources
- Performance report (Search results): Overview and basic setup — Google Search Central (checked 23 September 2026)
- About Search Console — Google Search Central (checked 23 September 2026)
- Search Console: Getting started — Google Search Central (checked 23 September 2026)
Get an SEO report that treats your Arabic content as its own story
Book a free 30-minute consultation with Ibrahem and Jeremy. We look at your site while we talk, and you leave with a prioritised plan.
Who wrote this
Jeremy ZavaCo-founder
Leads growth and client partnerships.
Works on: CRO, SEO
Reviewed before publishing by Ibrahem Helal, Co-founder.
- SEO reporting: what a good report showsA guide to SEO reporting: what a monthly report must include, which KPIs matter at each stage, and how to tie organic search to real revenue.
- SEO KPIs to Track by Funnel StageWhich SEO KPIs actually matter at each stage of the funnel, from first impression to closed revenue, and which ones are just noise dressed up as data.
- How to Track AI Referral TrafficHow to tell an AI referral from ordinary referral traffic in GA4, which domains to watch for, and why the number you get is still a floor, not a ceiling.
- SEO Forecasting: A Practical ModelA step-by-step model for forecasting organic traffic and leads, built on your own Search Console data instead of an industry-wide curve.