The navigation problem

A library organized only by content type asks readers to know what they need before they arrive: a calculator, a playbook, a framework, or a skill guide. Many people start somewhere less tidy: “Customers click WhatsApp, but orders are not coming in,” or “My Arabic ads sound translated.”

The resource finder starts from those situations. Each problem area connects a short diagnosis to a small set of tools, practical guides, and skill areas. The current page has 12 starting points, including lead quality, checkout loss, campaign measurement, Arabic localization, search visibility, and GCC market entry.

Why keep the first version static?

The page already has a bounded catalogue. It does not need to generate answers or invent recommendations; it needs to find the relevant entries that were reviewed and mapped to each problem. A local search keeps the interaction simple and avoids sending the reader’s wording to an external model.

That choice also defines the feature honestly: it is client-side keyword matching, not semantic search. It can be quick and useful without pretending to understand every sentence.

1. Make the resource card the unit of discovery

The page groups each scenario into a card. A card includes the problem statement, a short next-step explanation, and links to resources that do different jobs. For example, a profitability question can point to a calculation tool, a reconciliation guide, and an analytics skill area.

This is more useful than returning a flat list of unrelated links: the user sees why a resource is relevant and can choose the level of help they need.

2. Put searchable aliases beside the content

Each card carries a compact search index alongside its visible copy. The index includes an intent category and alternate English and Arabic phrasings. This keeps the search catalogue close to the content it represents, so a new problem card can be reviewed with its own aliases and destinations.

The visible page is the source of truth for the recommendations. Search filters those reviewed cards; it does not create new advice.

3. Normalize Arabic and English before matching

Before comparison, it calls JavaScript’s toLocaleLowerCase() without an explicit locale, applies Unicode normalization, removes the Arabic marks in U+064B–U+065F and U+0670, and maps أ/إ/آ to ا, ى to ي, and ؤ/ئ to ء. It then replaces punctuation with spaces. This reduces simple spelling and formatting mismatches without claiming full Arabic language understanding.

A simplified excerpt of the normalization step looks like this:

function normalize(value) {
  return (value || "")
    .toLocaleLowerCase()
    .normalize("NFKD")
    .replace(/[\u064b-\u065f\u0670]/g, "")
    .replace(/[أإآ]/g, "ا")
    .replace(/ى/g, "ي")
    .replace(/[ؤئ]/g, "ء")
    .replace(/[^\p{L}\p{N}]+/gu, " ")
    .trim();
}

Normalization is a practical compatibility layer, not translation. The index still needs human-written phrases that reflect how people actually describe a problem in each language.

4. Filter locally, and be clear about the limit

The search splits the normalized query into terms and checks those terms against each card’s index. In the current implementation, a card matches when any query term appears. That makes the interaction forgiving, but it can also return broad matches for a long sentence. It does not rank by relevance, infer intent, or understand synonyms that were not added to the index.

When there is no match, the page says so and offers other library routes. That is a useful fallback: it gives the reader another path instead of presenting an empty search as a technical failure.

What I would test before adding complexity

Try short queries and full sentences in both languages: “low quality leads,” “clicks but no orders,” “إعلاناتي العربية مترجمة,” and “بصرف على الإعلانات ومش عارف الأرباح.” Check that each result points to the right kind of resource and that a nonsense query reaches the no-match state.

Then review the misses. If readers repeatedly use a phrase that is absent from the index, add that phrase as an alias. If common queries return too many cards, consider a measured change such as phrase-first matching or weighted ranking. Do not add an AI model just because the input accepts natural language; first establish that the simpler method is failing in a way that matters.

This implementation is a small static-site pattern, not a search benchmark or a claim that the feature improves conversion. Its value is that the behavior is inspectable: curated problem cards, explicit destinations, local matching, and a clear fallback.

Try it and inspect the source

• Open the problem-based resource finder
• Read the search implementation

The finder is part of a larger portfolio of marketing tools and guides, but this article focuses on one engineering decision: make discovery useful before making it more complex.