DEV Community: Kreetive Digital Marketing

How to Turn Search Demand into a Website Information Architecture

Kreetive Digital Marketing — Fri, 28 Aug 2026 16:54:40 +0000

Many websites begin with a template and then try to fit the business into its navigation. A stronger process begins with customer demand, groups related needs, and turns those groups into pages with a clear purpose.

This is not about creating hundreds of thin pages for search engines. It is about using evidence to decide what deserves a page, what belongs in one section, and how visitors should move through the site.

1. Collect demand from more than one source

Start with a small, traceable dataset:

search queries related to the service
Search Console queries from an existing website
sales and support questions
Google Business Profile categories and services
competitor page structures
internal site-search terms
questions asked during client discovery

Store the source with every phrase. A keyword without its origin, location, and date becomes difficult to validate later.

{
  "query": "emergency dentist near me",
  "source": "search-research",
  "market": "Doha",
  "language": "en",
  "observedAt": "2026-08-28"
}

2. Normalize without destroying meaning

Remove obvious duplicates, normalize capitalization, and separate language variants. Do not merge phrases only because they share words.

For example:

dentist near me
emergency dentist near me
cosmetic dentist in Doha
children's dentist

All concern dentistry, but they represent different needs. A useful cluster reflects intent, not only lexical similarity.

3. Assign intent before creating pages

A simple intent model is often enough:

Service intent: the visitor is evaluating or requesting a service.
Local intent: the visitor needs a provider in a specific place.
Informational intent: the visitor is learning or comparing options.
Navigational intent: the visitor is looking for a specific brand or resource.

Intent can be stored explicitly:

type SearchIntent =
  | "service"
  | "local"
  | "informational"
  | "navigational";

Review borderline queries manually. Automatic clustering is useful for speed, but the final page decision should reflect what a real visitor expects to find.

4. Build topic clusters, then choose page roles

Each cluster should map to a page role:

Cluster	Page role	Primary action
general dentistry	core service page	request appointment
emergency dentist	urgent service page	call now
dental implants	specialist service page	book consultation
cost and recovery questions	educational guide	continue to service

This prevents every keyword from becoming a separate URL.

5. Define a “one page, one job” rule

Every important page should answer:

Who is this page for?
What question or need does it resolve?
What evidence supports the claim?
What should the visitor do next?

If two proposed pages have the same audience, evidence, and action, they probably belong together. If one page tries to serve unrelated needs, it may need to be split.

6. Turn clusters into a route map

A route map makes the information architecture reviewable before design begins.

/
├── services/
│   ├── web-design/
│   ├── search-engine-optimization/
│   └── social-media-management/
├── industries/
│   ├── healthcare/
│   └── hospitality/
├── work/
├── insights/
└── contact/

Avoid repeating the same page under multiple folders. Navigation can link to one canonical route from several places without duplicating the content.

7. Design internal links around decisions

Internal links should help visitors take the next logical step.

Examples:

a guide about website speed links to the relevant web-development service
a case study links to the service that produced the result
a service page links to related questions and proof
a location page links to the services actually offered there

Anchor text should describe the destination naturally. Repeating one commercial phrase across every link creates a poor reading experience and an artificial pattern.

8. Connect the architecture to analytics

Define page roles and events before implementation:

type PageRole = "home" | "service" | "location" | "guide" | "case-study";

type ConversionEvent =
  | "form_started"
  | "form_submitted"
  | "phone_clicked"
  | "whatsapp_clicked";

This allows reporting to compare pages with similar jobs instead of treating every URL as an unrelated item.

9. Validate with real results

After launch, review:

queries and impressions by page
conversion actions by page role
navigation paths
pages competing for the same queries
searches that have no satisfying destination

The architecture is a hypothesis. Search and conversion data should be used to improve it over time.

Common mistakes

Creating one page per keyword

Minor wording differences rarely justify separate pages. This approach produces duplication and weakens maintenance.

Copying competitor navigation

A competitor's menu reveals its current structure, not necessarily customer demand or business priorities.

Mixing research with design decisions too early

A visually attractive template can pressure the team into keeping sections that have no clear user purpose.

Treating AI clusters as final truth

Clustering tools can accelerate analysis, but market context, language, and service reality still require human review.

A compact deliverable before design

Before moving to wireframes, produce:

a cleaned query and customer-question dataset
intent and topic clusters
a page inventory with one job per page
the route hierarchy
internal-link relationships
primary action and measurement event for each page

This gives designers, developers, writers, and stakeholders one shared model of what the website needs to accomplish.

The key idea is simple: a website should not begin as a collection of attractive sections. It should begin as an organized response to what customers need and how the business can help them.

For an example of a market-led approach to service websites, visit our website.

A Practical Core Web Vitals Checklist for Service Business Websites

Kreetive Digital Marketing — Fri, 28 Aug 2026 16:53:20 +0000

Service websites often look simple but load like large applications. A hero video, several font files, tracking scripts, chat widgets, sliders, maps, and oversized portfolio images can turn a small homepage into a slow experience.

Performance work becomes easier when it is connected to the three Core Web Vitals: Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS).

Start with field data

Lab tools are useful for debugging, but field data describes what real users experience across different devices and networks.

Use:

Chrome User Experience Report data when available
Search Console's Core Web Vitals report
Real User Monitoring for page-level diagnosis
Lighthouse for repeatable local investigations

Do not treat one Lighthouse score as proof that a site is fast. Record the page, device profile, network conditions, and test date.

1. Improve LCP by finding the real largest element

On a service homepage, the LCP element is commonly the hero heading or hero image. Inspect it before changing anything.

If the LCP element is an image:

<img
  src="/images/hero-1280.webp"
  srcset="/images/hero-640.webp 640w,
          /images/hero-1280.webp 1280w"
  sizes="100vw"
  width="1280"
  height="720"
  fetchpriority="high"
  alt="Team planning a website project"
>

Important rules:

Do not lazy-load the LCP image.
Serve the correct dimensions through srcset and sizes.
Include intrinsic width and height.
Prefer AVIF or WebP when the visual quality remains acceptable.
Avoid placing the hero image only in a late-loaded CSS background.

If the hero contains a video, use a lightweight poster and delay the video until the page is interactive or the user requests playback.

2. Reduce render-blocking work

The first screen needs very little CSS and JavaScript compared with the whole website.

Split styles by route or component, remove unused framework styles, and avoid loading slider or gallery assets on pages that do not contain those widgets.

Third-party scripts should have a business reason. Load analytics, chat, heatmaps, and ad pixels according to consent and interaction needs rather than placing every script in the document head.

<script src="/analytics.js" defer></script>

defer prevents classic scripts from blocking HTML parsing, but it does not make a large script cheap. Measure execution time as well as download size.

3. Protect INP from long tasks

INP measures how quickly the page responds to interactions. A site can display quickly and still feel slow when a menu, filter, or form triggers too much JavaScript.

Look for:

long main-thread tasks
large hydration costs
event handlers that perform layout reads and writes repeatedly
third-party widgets that initialize during the first interaction
form validation that runs across the entire document

Break expensive work into smaller tasks and update only the component that changed.

button.addEventListener("click", async () => {
  button.disabled = true;
  status.textContent = "Sending…";

  try {
    await submitForm();
    status.textContent = "Sent successfully";
  } finally {
    button.disabled = false;
  }
});

Immediate visual feedback does not replace performance work, but it prevents an interaction from feeling broken while asynchronous work completes.

4. Eliminate CLS at the source

Common layout-shift causes include images without dimensions, late cookie banners, injected form messages, font swaps, and sliders that calculate their height after JavaScript runs.

Reserve space explicitly:

.portfolio-card__media {
  aspect-ratio: 4 / 3;
  overflow: hidden;
}

.portfolio-card__media img {
  width: 100%;
  height: 100%;
  object-fit: cover;
}

Place validation errors inside reserved containers, and render consent interfaces in stable overlays instead of pushing the entire page downward.

5. Set a font budget

Fonts are often overlooked because each file appears small in isolation. A multilingual site may load multiple families, scripts, weights, and italics.

A practical starting budget is:

one body family per writing system
one or two critical weights
subset files for required character ranges
font-display: swap
preload only the font used above the fold

Measure whether a decorative display font is worth delaying the main message.

6. Load widgets only when needed

Maps, review embeds, booking tools, and chat widgets are useful, but they do not need to execute immediately on every page.

Use an interaction placeholder:

<button id="load-map">Show location map</button>

Load the heavy provider only after the user selects the action. This approach also gives consent controls a clearer boundary.

7. Create performance budgets

Without a budget, performance gradually degrades as each new tool adds “only one more script.”

Example limits for a service landing page:

Initial JavaScript: <= 150 KB compressed
Initial CSS:        <= 60 KB compressed
Hero image:         <= 180 KB
Third-party scripts: documented owner and purpose

The exact numbers depend on the project, but having limits creates an explicit decision when a new feature exceeds them.

8. Test representative pages

Do not optimize only the homepage. Test:

the homepage
the heaviest service page
a portfolio or gallery page
a blog article
the contact or lead form
Arabic and English variants

Averages can hide one route that performs poorly and receives valuable commercial traffic.

A repeatable workflow

Capture field and lab baselines.
Identify the actual LCP element and long tasks.
Remove unused assets before compressing everything.
Fix image dimensions and unstable components.
delay noncritical widgets and third-party scripts.
Retest with the same conditions.
Monitor real users after deployment.

The most effective performance work is usually not a clever optimization. It is removing unnecessary work from the critical path and protecting the result with budgets and monitoring.

You can see more web performance and digital experience work from Kreetive.

How to Build a Fast Bilingual Website with RTL and LTR Support

Kreetive Digital Marketing — Fri, 28 Aug 2026 16:31:14 +0000

Building a bilingual website is not the same as translating a few strings. The direction of the interface changes, typography behaves differently, components need to survive longer text, and search engines need a clear relationship between language versions.

This guide presents a practical architecture for websites that support both English and Arabic without duplicating the entire frontend.

1. Treat language and direction as document state

Set both lang and dir on the root element. Do not rely on CSS classes alone.

<html lang="ar" dir="rtl">

For English:

<html lang="en" dir="ltr">

This helps browsers, screen readers, form controls, punctuation, and bidirectional text behave correctly.

In a React application, derive both values from the active locale:

const direction = locale === "ar" ? "rtl" : "ltr";

return (
  <html lang={locale} dir={direction}>
    <body>{children}</body>
  </html>
);

2. Use CSS logical properties

Directional declarations such as margin-left and padding-right create avoidable RTL bugs. Logical properties describe the purpose of the spacing instead of a physical side.

.card {
  padding-inline: 1.25rem;
  margin-block-end: 1rem;
  border-inline-start: 4px solid #ff6b00;
}

.icon {
  margin-inline-end: 0.5rem;
}

The same component now adapts automatically when the document direction changes.

Use these replacements whenever possible:

margin-inline-start instead of margin-left
padding-inline-end instead of padding-right
inset-inline-start instead of left
border-start-start-radius for direction-aware corners

3. Do not mirror everything

Layout direction should change, but not every visual element should flip. Logos, photographs, media controls, phone numbers, code snippets, and many charts should preserve their original orientation.

For directional icons, flip only the icons that communicate movement:

[dir="rtl"] .directional-icon {
  transform: scaleX(-1);
}

Avoid applying scaleX(-1) to a whole container. It may reverse images and text rendering in surprising ways.

4. Keep translation content separate from components

A component should receive content rather than contain language-specific copy.

const messages = {
  en: {
    heroTitle: "Build a website around real customer demand",
    cta: "Start a project",
  },
  ar: {
    heroTitle: "ابنِ موقعك بناءً على طلب العملاء الحقيقي",
    cta: "ابدأ مشروعك",
  },
};

For production systems, validate message keys during the build so a missing translation cannot silently reach the interface.

5. Design for text expansion

Arabic and English strings rarely occupy identical widths. Navigation labels, buttons, cards, and validation messages should grow naturally.

Avoid fixed widths for text controls:

.button {
  min-inline-size: 9rem;
  inline-size: fit-content;
  max-inline-size: 100%;
  white-space: normal;
}

Test components with deliberately long labels. A layout that survives difficult content is more reliable than one tested only with short placeholder text.

6. Choose and load fonts carefully

A font may look excellent in Latin characters but offer weak Arabic glyphs. Choose a family with deliberate Arabic support, or define a compatible pair.

:root {
  --font-latin: "Inter", system-ui, sans-serif;
  --font-arabic: "Noto Sans Arabic", system-ui, sans-serif;
}

html[lang="en"] body { font-family: var(--font-latin); }
html[lang="ar"] body { font-family: var(--font-arabic); }

Subset font files, preload only the critical weight, and use font-display: swap. Loading five weights for two writing systems can quickly become one of the page's largest performance costs.

7. Give each language a stable URL

Use separate, indexable URLs such as:

/services/web-design/
/ar/services/web-design/

or:

/en/services/web-design/
/ar/services/web-design/

Do not change visible language only through JavaScript while keeping one URL. Separate URLs make sharing, analytics, caching, and search indexing more predictable.

Connect equivalent pages with hreflang:

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

Each page should also use a self-referencing canonical URL. Do not canonicalize the Arabic version to the English version; they are alternate language pages, not duplicates.

8. Test mixed-direction content

Arabic interfaces often contain English product names, email addresses, URLs, and numbers. Wrap isolated fragments when the browser may infer the wrong direction.

<p>راسلنا على <bdi>hello@example.com</bdi></p>

Test at least:

Arabic text containing an English brand name
phone numbers and prices
form validation messages
breadcrumbs and pagination
icons inside buttons
mobile navigation
copied URLs and email addresses

9. Make direction part of automated testing

A small end-to-end test can catch many regressions:

test("Arabic page uses RTL direction", async ({ page }) => {
  await page.goto("/ar/");
  await expect(page.locator("html")).toHaveAttribute("lang", "ar");
  await expect(page.locator("html")).toHaveAttribute("dir", "rtl");
});

Add visual snapshots for a few shared components in both languages. The goal is not pixel-perfect mirroring; it is consistent hierarchy, readable text, and correct interaction order.

Final checklist

Set lang and dir at document level.
Prefer CSS logical properties.
Mirror only directional UI elements.
Keep translated content outside components.
Allow labels and controls to expand.
Load fonts with strong Arabic support efficiently.
Give every language version a stable URL.
Implement reciprocal hreflang links.
Test mixed-direction content and keyboard navigation.

A bilingual website becomes much easier to maintain when direction is treated as a core system property instead of a late visual patch.

Kreetive applies these principles when planning and building multilingual service websites as a Digital marketing company in Qatar.``