Keyword and Competitor Research

A browser workspace for exploring search demand, competing pages and paid research data.

This keyword research tool case study covers a browser workspace that ties keyword discovery to competitor reports. A user can narrow a list of terms, open a promising keyword, study the pages that compete for it and export what they find.

Each user connects their own search-data account. The provider supplies the metrics and charges for every live request, while our application handles the exploring and keeps the account balance in view.

The challenge

Refreshing a report can mean paying for another request. Reusing a saved result avoids that charge, but it leaves the user on older data. We wanted that choice to be a deliberate one.

Moving between reports should also hold on to the subject. A domain entered for traffic research still matters when the next question is about its ranked keywords or its leading pages.

What we built

A keyword report brings together search volume and intent so a user can size up a term quickly. It then adds difficulty, competition and trend data beside them. Filters narrow the list by volume, difficulty and intent. A user can also include specific words or exclude the ones that do not fit. A detail panel opens one keyword for a closer look, and competitor views reuse the selected domain so the research stays on one subject.

Settings control the market, the language and report limits, and caching is an option on top. Sandbox mode runs on test data instead of paid calls. A CSV export carries the chosen results into other work, while autocomplete and bulk domain-rating tools add further research paths.

Technical approach

Typed services keep the provider calls apart from the report components, and paid reports go from the browser straight to the connected service. The domain-rating integration is the exception, and it runs through a server action.

An optional Redis cache builds its key from several parts of each request before any paid lookup. The key takes in the tool, the query and the location. It also takes in the language, the filters and the page. Before making any paid call, the application checks that cache and reuses a stored answer when one is still valid. A refresh request or sandbox mode skips the check. A saved response carries an expiry and shows when it was cached. That timestamp describes when the response was saved, and the provider's own metrics may be older than that.

Routes carry the keyword or the domain in their query parameters, so opening a route restores the subject. Even so, the application does not keep a lasting report history. Provider and cache credentials live in the browser's own storage, because this is a workspace built for a single person. Shared accounts and scheduled monitoring would call for a different, server-side design. Balance figures refresh after each call, while the real billing stays with the provider.

Project success

A user can follow one research question across keyword and domain views without typing the same subject again. Filters and exports make the results useful outside the application. The cached-report timestamp, the deliberate refresh and the visible balance give a user the context to judge when another paid request is worth it.

Technology stack

Application

TypeScript, Next.js, React

Interface

HeroUI, MUI Data Grid, Tailwind CSS

Charts and state

Recharts, Jotai

Integrations

Typed search-data services, HTTP APIs

Optional cache

Redis over an authenticated HTTP interface