DEV Community: Yunus Khan

How We Built an SEO System for a Small Website Using AI, Content Clusters & Technical SEO

Yunus Khan — Tue, 01 Sep 2026 10:06:49 +0000

When you launch a new website, SEO can feel like shouting into an empty room.

You publish an article.

Nothing happens.

You publish another.

Still nothing.

That was one of the challenges we faced while building SabrTime, a free Islamic digital companion focused on prayer, reflection, consistency, and useful Islamic tools.

Instead of treating SEO as simply "write more blog posts,"
We started building a repeatable system around technical SEO, search intent, content clusters, internal linking, and AI-assisted content production.

This is the workflow we are using and the lessons that can be adapted to almost any small website.

Start With the Website, Not the Blog

One of the biggest mistakes a new website can make is creating dozens of blog posts before understanding what the website actually offers.

We first looked at:

Website structure
Existing pages
Search intent
Important features
Existing content
Sitemap
Metadata
Internal links
Indexability
Structured data
Open Graph information
Canonical URLs

SabrTime isn't only a blog.

It is a web-based Islamic companion with tools and resources around prayer, Qibla, Tasbeeh, spiritual habits, and Islamic learning.

That meant the SEO strategy could connect informational content with actual useful tools.

The main website acts as the hub:

SabrTime → Tools → Resources → Blog → Educational content

This structure gave us many opportunities to build topical relevance.

You can explore the project here: "SabrTime" (https://sabrtime.in/).

Focus on Search Intent Instead of Just Keywords

Instead of targeting only highly competitive terms such as:

Islamic app
Prayer app
Quran app

we started looking at specific problems users might actually search for.

For example:

How to find Qibla direction
Does airplane mode affect a Qibla compass?
How to pray missed prayers
What does Adhan mean?
How to do Tasbeeh
What is the Qibla direction for a city?
How to build a daily Dhikr habit

These queries have much clearer intent.

For example, we created location-specific and educational Qibla resources rather than writing one generic article and stopping there.

The important part isn't simply putting a keyword into an article.

The article needs to actually solve the user's problem.

Build Content Clusters Instead of Random Articles

Instead of publishing unrelated articles, we started grouping content into topics.

For example, a Qibla content cluster can include:

Qibla

→ How to Find Qibla Direction
→ Qibla Direction in Degrees
→ Qibla Direction by City
→ Airplane Mode & Digital Qibla Compass
→ History of the First Qibla

For example, our "Qibla Direction in Dallas" (https://sabrtime.in/blog/qibla-direction-dallas-tx.html) article focuses specifically on the Qibla direction for Dallas.

We also created content around "airplane mode and Qibla compasses" (https://sabrtime.in/blog/airplane-mode-qibla-compass.html).

These aren't random articles.

They're different pieces of content supporting the same broader topic.

This approach can be used for almost any niche.

A fitness website could create:

Fitness

→ Home workouts
→ Beginner workouts
→ Push-up guide
→ Squat guide
→ Workout recovery

A SaaS website could create:

Email Marketing

→ Email marketing guide
→ Email subject lines
→ Open rates
→ Email automation
→ Newsletter strategy

The principle is the same:

«Build topical depth instead of publishing random keywords.»

AI Helped Us Scale the Content Workflow

Claude became particularly useful in our content-development workflow.

But we didn't simply tell AI:

«"Write me an SEO article."»

Instead, we used a structured process.

Topic

↓

Search intent

↓

Research

↓

Article structure

↓

How I Diagnosed and Fixed Keyword Cannibalization Between Two Nearly-Identical Blog Posts

Yunus Khan — Wed, 26 Aug 2026 15:48:01 +0000

I thought publishing more useful content would automatically give my website more opportunities to rank.

Then I noticed something uncomfortable.

Two articles on my site were covering almost the same subject.

Both were useful.
Both were properly indexed.
Both answered similar questions.
And both were competing for overlapping search intent.

I had accidentally created a small SEO architecture problem inside my own blog.

I'm building "SabrTime.in" (https://sabrtime.in/), a small Islamic companion app focused on practical digital tools for everyday worship. As a solo developer, I also manage the website, content, SEO, and product development myself.

While working on the site's content, I published two articles around Tasbeeh:

How to Do Tasbeeh — A Complete Guide
Digital Tasbeeh Counter: How It Works & Why Muslims Are Switching

The first article is about the practice itself.

The second is supposed to be about the technology and use case of digital Tasbeeh counters.

Sounds different enough, right?

At first, I thought so too.

But when I looked at the actual content and search intent, the overlap became obvious.

The Problem Wasn't Duplicate Content

This is where SEO gets misunderstood.

Keyword cannibalization doesn't necessarily mean you have two pages containing identical paragraphs.

The more interesting problem is intent overlap.

If two URLs are trying to satisfy essentially the same searcher's question, a search engine has less information about which page should be the primary result.

For example, imagine these two pages:

/page-a
"How to Do Tasbeeh"

/page-b
"Digital Tasbeeh Counter"

Their titles are different.

But if both pages explain:

what Tasbeeh means
how many times to recite it
common Tasbeeh counts
the same hadith
how to count Tasbeeh
why Muslims use a counter
FAQs about Tasbeeh

...then the distinction between the pages starts becoming blurry.

That was happening on my site.

The two articles were not technically duplicates.

But parts of their search intent were duplicates.

And that distinction matters.

How I Found It

I didn't start by running an expensive SEO crawler.

I started with the simplest question:

«"Why do I have two pages that could answer the same searcher's question?"»

I compared the pages manually.

Then I looked at the queries and pages appearing in Google Search Console.

The useful report here is:

Search Console → Performance → Search results → Queries → Pages

If you investigate a particular query and discover multiple URLs receiving impressions for it, that's worth investigating.

It doesn't automatically prove cannibalization.

Google can legitimately rank multiple pages from the same site for one query.

But when those pages also have highly overlapping content and intent, you've got a stronger signal that your information architecture needs work.

The Two Pages Had Different Jobs — But I Hadn't Made That Clear Enough

This was the key realization.

The solution wasn't simply:

«"Delete one article."»

The solution was:

«Give each article a clearly different job.»

I defined the two pages like this.

Page 1 — The Practice

Primary intent:

«How do I perform Tasbeeh correctly?»

This page should answer questions about the Islamic practice itself.

It can cover:

Meaning of Tasbeeh
Correct method
Common counts
Tasbeeh after Salah
Tasbeeh Fatima
Common mistakes
Relevant Islamic references
Building a consistent dhikr habit

This is the educational/pillar page.

Page 2 — The Tool

Primary intent:

«How does a digital Tasbeeh counter work, and should I use one?»

Now the content becomes more product and technology oriented.

It can cover:

What a digital Tasbeeh counter is
Physical vs digital counters
How a phone counter works
Advantages and limitations
Offline functionality
Privacy considerations
Tracking repetitions
When a digital counter is useful
How SabrTime implements the feature

The article still needs enough Islamic context to be useful.

But it shouldn't become another complete guide to Tasbeeh.

That's the important distinction.

I Removed Unnecessary Overlap

This was probably the most useful part of the exercise.

I went through the overlapping sections and asked:

«"Does this information belong here because it helps this page's primary intent, or am I including it because it's another keyword opportunity?"»

Those are very different reasons.

If a section existed only because I thought:

«"This keyword might help the page rank."»

I questioned it.

For example, the digital counter article doesn't need a massive standalone explanation of every aspect of performing Tasbeeh.

That's already the job of the Tasbeeh guide.

Instead, I can briefly explain the relevant concept and link to the detailed guide.

Conceptually:

Tasbeeh Guide
│
│ explains the practice
▼
Digital Tasbeeh Counter
│
│ explains the technology
▼
SabrTime Counter

Now the pages support each other instead of competing with each other.

Internal Linking Became More Important

Once I had separated the intent, internal links became much more meaningful.

Instead of randomly linking between articles, I could establish a relationship.

Tasbeeh guide → Digital counter

«If you prefer counting dhikr digitally, here's how digital Tasbeeh counters work.»

And:

Digital counter → Tasbeeh guide

«Before using a digital counter, learn the traditional method and recommended Tasbeeh practices.»

Now the relationship is obvious.

One page explains the practice.

The other explains the tool.

That's much cleaner than having two pages both trying to be the complete answer.

I Didn't Immediately Canonicalize One Page

Canonicalization was one of the first technical solutions I considered.

But I didn't want to use a canonical tag as a shortcut for a content architecture problem.

If two pages have genuinely different purposes, blindly canonicalizing one to the other can throw away useful search opportunities.

So my approach was:

Identify overlapping intent.
Decide which page owns the broader topic.
Give the second page a narrower purpose.
Remove unnecessary overlap.
Improve internal linking.
Monitor Search Console.
Only consider stronger consolidation if the pages still don't have a meaningful distinction.

In other words:

Fix the information architecture before reaching for a technical directive.

The Interesting Part: This Is Basically Refactoring

As a developer, this way of thinking made the problem much easier.

Imagine I had two functions:

function tasbeehGuide() {
// explains Tasbeeh
// explains counts
// explains methods
// explains how to count
}

function digitalTasbeehCounter() {
// explains Tasbeeh
// explains counts
// explains methods
// explains how to count
// explains digital counting
}

That's a code smell.

The functions have overlapping responsibilities.

You'd probably refactor them.

SEO content can have the same problem.

Instead of thinking:

«"I need another article targeting another keyword."»

Think:

«"What responsibility does this URL own?"»

That mental model changed how I approached my blog.

My New Rule for Creating Content

Before publishing another article, I now ask five questions.

What exact question does this page answer?

Not:

«"What keyword am I targeting?"»

But:

«"What does the searcher actually want?"»

Do I already have a URL answering this?

Search the existing site before creating a new article.

If I already have one, what is genuinely different here?

If the answer is just:

«"The title is different."»

That's probably not enough.

Can I describe the difference in one sentence?

For example:

«"This article explains Tasbeeh."»

versus:

«"This article explains digital Tasbeeh counters."»

If I can't clearly articulate the distinction, the pages probably aren't differentiated enough.

Where should the new article fit in my site's information architecture?

A blog shouldn't just be a collection of URLs.

It should behave more like a knowledge graph.

Related pages should have relationships.

What I'm Watching Now

I don't consider the problem "fixed" simply because I edited the pages.

SEO changes need to be measured.

I'm watching:

Which URL receives impressions for broader Tasbeeh queries
Whether the digital-counter page gains visibility for tool-related searches
Whether the Tasbeeh guide retains its educational queries
CTR changes
Average position
New queries appearing for each page
Whether impressions become less fragmented between the two URLs

The important thing is that I'm not expecting an overnight result.

The goal isn't:

«"Make one URL rank #1."»

The goal is:

«Make it obvious which URL should rank for which intent.»

That's a much more sustainable strategy.

What I Learned as a Solo Developer

The biggest lesson wasn't actually about SEO.

It was about content architecture.

When you're building alone, it's incredibly easy to think about every article independently:

«"This seems like a useful topic. I'll write it."»

Then six months later, you have 30 articles that individually look fine but collectively overlap.

That's exactly like accumulating technical debt.

A little duplication doesn't look dangerous.

But eventually:

Article A ──┐
├── overlapping intent
Article B ──┘

becomes a problem you have to untangle.

So now I'm treating SEO content more like software architecture.

Every URL needs a responsibility.

Every important topic needs a clear primary page.

Related pages should support each other rather than competing unnecessarily.

The Bigger Lesson

If you have a small website and your rankings aren't behaving the way you expect, don't immediately assume you need more backlinks, more articles, or more keywords.

Sometimes the problem is simpler:

You may have already written the answer — twice.

Before publishing your next article, search your own website.

Look at the existing URLs.

Compare their titles, headings, FAQs, and search intent.

Then ask:

«"If I were Google, which of these two pages would I consider the better answer?"»

If the answer isn't obvious, that's probably your next SEO task.

I'm still experimenting with this on "SabrTime.in" (https://sabrtime.in/), but this change has already altered how I plan content.

I don't want to build a blog with hundreds of pages.

I want to build a site where every page has a reason to exist.

And, like good code, good content architecture should make the system easier to understand — not harder.

The pages behind this experiment

"SabrTime.in" (https://sabrtime.in/) — the Islamic app I'm building
"Digital Tasbeeh Counter" (https://sabrtime.in/blog/digital-tasbeeh-counter.html) — the technology/tool-focused article
"Tasbeeh Guides" (https://sabrtime.in/blog/tasbeeh-guides.html) — the practice/educational side

If you're also building a content-heavy product as a solo developer, I'd be interested to know:

Have you ever discovered two of your own pages competing for the same search intent?

seo #webdev #indiedev #buildinpublic #devto

How I Built an Offline-First Qibla Compass for a PWA Without an Internet Connection

Yunus Khan — Sun, 09 Aug 2026 12:14:35 +0000

When you're travelling, one of the simplest problems can become surprisingly difficult: finding the Qibla direction without an internet connection.

I wanted to solve this problem while building SabrTime, an Islamic PWA focused on making everyday worship tools available with minimal dependencies, no mandatory login, and an offline-first experience.

The result was an offline-capable Qibla compass that can calculate the direction toward the Kaaba using the device's location and orientation sensors.

Why Offline Qibla Matters
Most web applications assume that the user has an active internet connection.

That isn't always true.

A person may be:

Travelling by airplane
In an area with poor network coverage
Abroad without mobile data
Inside a building with unreliable connectivity
Using airplane mode

A Qibla tool shouldn't necessarily stop being useful just because the network disappears.

This led me to an important design principle:

«Calculate what can be calculated locally, and use the network only when it is actually necessary.»

The Basic Architecture

The Qibla calculation itself doesn't require a server.

The basic flow is:

Device Location
↓
Latitude + Longitude
↓
Calculate Bearing to Kaaba
↓
Device Orientation Sensor
↓
Calculate Relative Direction
↓
Display Qibla Compass

The Kaaba's geographic coordinates are fixed, so the application can calculate the bearing locally once it knows the user's latitude and longitude.

Calculating the Bearing to the Kaaba

The first step is determining the initial bearing between the user's location and the Kaaba.

For two points on Earth, we can use the following formula:

const lat1 = userLatitude * Math.PI / 180;
const lat2 = kaabaLatitude * Math.PI / 180;

const deltaLon =
(kaabaLongitude - userLongitude) * Math.PI / 180;

const y = Math.sin(deltaLon) * Math.cos(lat2);

const x =
Math.cos(lat1) * Math.sin(lat2) -
Math.sin(lat1) * Math.cos(lat2) * Math.cos(deltaLon);

let bearing = Math.atan2(y, x);

bearing = bearing * 180 / Math.PI;
bearing = (bearing + 360) % 360;

The resulting value represents the initial compass bearing toward the Kaaba.

This is useful because the calculation happens entirely on the device.

There is no need to send the user's coordinates to a remote API simply to calculate a direction.

Getting the User's Location

The browser's Geolocation API can provide the user's current coordinates.

A simplified implementation looks like this:

navigator.geolocation.getCurrentPosition(
(position) => {
const latitude = position.coords.latitude;
const longitude = position.coords.longitude;

calculateQibla(latitude, longitude);

},
(error) => {
console.error("Unable to get location:", error);
}
);

Of course, a production application needs to handle permission denial, unavailable location data, low accuracy, and other edge cases.

Using Device Orientation

Knowing the Qibla bearing isn't enough for a compass interface.

We also need to know which direction the device is facing.

Modern browsers can expose device orientation information through sensor APIs, although implementation details and permission requirements can vary between browsers and operating systems.

The basic concept is:

Qibla Bearing
-
Device Heading
=
Relative Qibla Direction

For example, if the Qibla bearing is 280° and the device is currently facing 250°:

280° - 250° = 30°

The UI can then tell the user that the Qibla is approximately 30° to the right.

The Difficult Part: Sensors Are Messy

This sounds straightforward until you actually test it on physical devices.

A compass isn't perfectly stable.

The readings can be affected by:

Magnetic interference
Metal objects
Device hardware
Sensor noise
Indoor environments
Browser differences
Device calibration
Rapid device movement

So a good compass interface shouldn't simply trust one sensor reading.

Instead, the application needs to smooth readings and provide clear visual feedback.

Handling Sensor Noise

One simple approach is to maintain a rolling set of readings and smooth the result.

For example:

const readings = [];

function smoothHeading(newHeading) {
readings.push(newHeading);

if (readings.length > 10) {
readings.shift();
}

return readings.reduce((sum, value) => sum + value, 0)
/ readings.length;
}

This is only a basic example. Circular values such as 359° and 1° require special handling because a normal arithmetic average can produce incorrect results.

That's an important lesson when working with compass data:

Angles aren't ordinary numbers.

Building It as a PWA

The next challenge was making the experience work even when connectivity disappears.

A Progressive Web App can cache the application's static resources so that previously loaded functionality remains available offline.

The architecture becomes:

          ┌───────────────┐
          │    PWA UI     │
          └───────┬───────┘
                  │
    ┌─────────────┴─────────────┐
    ↓                           ↓

Local calculations Cached resources
↓ ↓
Qibla bearing Offline interface
↓
Device sensors
↓
Qibla direction

The key idea is that the compass calculation doesn't need a continuous internet connection.

Privacy Was Another Design Goal

Location data is sensitive.

For an Islamic utility like a Qibla compass, I wanted the architecture to minimize unnecessary data transmission.

If the calculation can happen locally, there is little reason to send the user's exact coordinates to a remote server merely to determine a bearing.

This is one reason I prefer a privacy-first, client-side approach wherever practical.

What About Airplane Mode?

This is where the offline-first approach becomes particularly useful.

With network connectivity disabled, a PWA can still provide functionality that doesn't depend on an external server.

The important distinction is:

Offline does not mean “everything works without hardware or permissions.”

The application may still require:

Previously cached application resources
Location permission
Device location capability
Orientation sensors
Browser support

The goal is to remove the unnecessary dependency on the internet, not to magically bypass device requirements.

Testing on Real Devices

One of the biggest lessons from this project was that browser-based sensor applications should be tested on actual phones.

A feature can appear perfect in desktop development tools but behave differently on a physical device.

I recommend testing:

With Wi-Fi enabled
With mobile data disabled
In airplane mode
Indoors
Outdoors
After rotating the device
On multiple browsers where possible

This catches problems that aren't obvious during normal development.

What I Learned

Building this feature taught me that an offline-first web application isn't simply about adding a service worker.

It requires thinking about the entire dependency chain.

For every feature, ask:

«Does this actually need the internet?»

If the answer is no, move the computation to the client whenever practical.

For a Qibla compass, this means location + mathematical calculation + device sensors can do most of the work locally.

The SabrTime Implementation

I built this approach into SabrTime, an Islamic PWA that includes prayer tools, Qibla, Islamic resources, and other everyday worship utilities.

You can explore the project here:

SabrTime: https://sabrtime.in/

I also documented the Qibla approach in more detail in this article:

Airplane Mode Qibla Compass: https://sabrtime.in/blog/airplane-mode-qibla-compass.html

If you're interested in the broader problem of maintaining useful Islamic tools while travelling, I also wrote about "missed prayers and Qaza" (https://sabrtime.in/blog/missed-prayers-qaza-guide.html) and practical guidance around making up missed Salah.

Final Thoughts

The web doesn't always need to depend on the cloud.

For many utility applications, calculations can happen directly on the user's device. This can improve:

Offline reliability
Privacy
Performance
Resilience
User experience

The Qibla compass was a good example of this principle.

Instead of asking a server:

«“Where is the Qibla from this location?”»

the phone can calculate the answer itself.

That small architectural decision makes the feature much more useful when the user is travelling — precisely when a Qibla compass may be needed most.

I'm continuing to experiment with offline-first and privacy-focused web development while building SabrTime, and I'll be sharing more of the technical lessons from the project.

What Google Search Console Is Teaching Me as a Solo Developer

Yunus Khan — Sat, 01 Aug 2026 07:29:13 +0000

When I launched SabrTime, I expected Google to discover my pages quickly.

That didn't happen.
Today, only 13 pages of my website are indexed,people are already discovering my content through Search.
Instead of chasing shortcuts, I've started trusting the data.

My Search Console Snapshot
Over the last few months, I've seen:
✅ 13 pages indexed
📈 Search impressions growing month after month
🔍 Hundreds of search queries triggering my pages
🌍 Visitors finding content from different countries
📱 Most traffic coming from mobile devices

That was enough to convince me that SEO is a long-term investment.

Lesson 1: Impressions Matter Before Clicks
One thing I misunderstood was impressions.
At first, I only cared about clicks.
Now I pay close attention to impressions because they tell me Google is beginning to understand my website—even if users aren't clicking yet.
Every impression is a sign that my content is entering the search ecosystem.

Lesson 2: Unexpected Keywords Are Opportunities
Some of my pages started appearing for search queries I never intentionally targeted.
That helped me discover new content ideas and improve existing pages around topics users were already searching for.
Instead of guessing what people want, I now let Search Console guide my content strategy.

Lesson 3: Technical SEO Matters
While reviewing Search Console, I found several technical issues that needed attention:
Improving internal links
Fixing indexing problems
Updating meta titles and descriptions
Making pages easier for Google to crawl
None of these changes created overnight success, but together they improved the health of my website.

Lesson 4: Publishing Consistently Beats Publishing Perfectly
Rather than waiting for the "perfect" article, I focused on publishing useful content consistently.
Every quality page becomes another opportunity for Google to understand what your website is about.

What I'm Working Toward
My next goals are simple:
Increase indexed pages beyond 13
Continue improving Core Web Vitals
Earn relevant backlinks naturally
Publish content people genuinely find useful
SEO isn't about gaming the algorithm.
It's about building something worth discovering.

Final Thoughts
I'm still at the beginning of my SEO journey, but Google Search Console has completely changed how I think about building websites.
The data has helped me stop guessing and start making better decisions.
If you're also building a website, what has Google Search Console taught you?

About My Project
I'm applying these lessons while building SabrTime, a privacy-focused Islamic web app with prayer times, Qibla direction, duas, an ibadah tracker, tasbeeh, and other daily Islamic tools.

🌐 https://sabrtime.in⁠�

Hello Dev Community! I'm Yunus Khan

Yunus Khan — Sat, 18 Jul 2026 08:13:34 +0000

👋 Assalamu Alaikum and hello everyone! 👋

My name is Yunus Khan, an independent developer from India who enjoys building products that solve real problems and make technology more meaningful.

My current passion project is SabrTime—a free Islamic web app designed to help Muslims stay connected with their faith through modern technology.

🌐 Try SabrTime: https://sabrtime.in

🌙 What is SabrTime?

SabrTime is more than just a prayer app. It's an all-in-one spiritual companion featuring:

🕌 Accurate Prayer Times
🧭 Qibla Compass
📿 Digital Tasbeeh Counter
🤲 Mood-Based Duas
📖 Prayer & Dua Library
📅 Islamic Calendar
📈 Ibadah & Streak Tracker
🧠 Islamic Quiz
🌍 Multi-language support

I'm constantly adding new features and improving the experience based on community feedback.

The project is also open source, and I'd love to hear your suggestions or contributions.

⭐ GitHub: https://github.com/Kyunus175/sabrtime

💻 What I'll Share Here

On Dev.to, I'll write about:

My web development journey
Building and scaling SabrTime
JavaScript, HTML, CSS, Firebase, and PWAs
SEO and performance optimization
Lessons learned while developing as a solo developer
Open-source experiments and side projects

I'm excited to learn from this amazing community, share my experiences, and connect with developers from around the world.

Thank you for reading my first post! If you have any feedback about SabrTime or ideas for future features, I'd love to hear them in the comments.

🌐 Website: https://sabrtime.in
⭐ GitHub: https://github.com/Kyunus175/sabrtime

webdev #javascript #pwa #opensource #indiedev #devjourney