DEV Community: Osama Khattak

How to Build a Time Tracking App Like Hubstaff: Lessons from Staffvertex

Osama Khattak — Tue, 27 Oct 2026 11:39:51 +0000

Every team that bills by the hour ends up with the same argument sooner or later: someone says they worked six hours, the report says four, and nobody can prove which is right. A time tracking app exists to end that argument. That's a harder job than it sounds.

I build and maintain Staffvertex, a time tracking and project management product in the same category as Hubstaff, made at Alphinex Solutions. This article is what I'd tell anyone who wants to build a time tracking app of their own: what matters, what looks important but isn't, and where the real work hides.

What a time tracker has to get right

Strip away the dashboards and a time tracker makes three promises:

The hours are correct. Not roughly correct. Correct enough that a client will pay an invoice built on them.
Tracking costs almost no effort. If starting the timer takes more than one click, people forget, and then they fill in timesheets from memory on Friday.
It's fair to the person being tracked. If the team feels watched, they'll resent the tool and find ways around it.

Every feature decision comes back to one of those three. When I'm unsure whether something belongs in the product, I ask which promise it serves. If the answer is none, it waits.

Staffvertex leads with one action: start the timer in one click.

The timer is the product

It's tempting to treat the timer as a solved problem and spend your energy on reports. That's backwards. People touch the timer dozens of times a day and open reports once a week. If the timer is slow, fiddly or unreliable, nothing else you build will matter.

A good timer does a few things without being asked:

Starts from wherever the person already is: the desktop app, the browser, or a global keyboard shortcut.
Remembers the last project and task, because most people switch far less often than you'd expect.
Never runs twice. Starting a timer on the laptop should stop the one left running in the browser.
Shows the running time somewhere visible, so a forgotten timer gets noticed in minutes, not days.

That last point saves more support tickets than any feature I can think of. A timer left running overnight is the most common way hours go wrong, and the fix is mostly visibility.

Offline first, or the hours are wrong

Here's the mistake I see in most first attempts: the app sends a request to the server when the timer starts and another when it stops, and treats the server as the source of truth for everything in between. Then someone tracks a flight, a train ride or just a bad afternoon of Wi-Fi, and their hours disappear.

The Staffvertex desktop app keeps counting when the connection drops and syncs about once a minute when it comes back. That behavior is the difference between a tracker people trust and one they double-check against a notebook.

If you're designing this yourself, the pieces are:

Record time on the device as small, timestamped intervals, written to local storage before anything else happens.
Send those intervals to the API in batches, each with an id the server can use to ignore duplicates.
Let the server accept late data. An interval that arrives three hours late is still a real interval.
Never trust the device clock on its own. Compare it with server time when you can, so changing the computer clock doesn't change the hours. Staffvertex calls this a trusted clock.

Rule of thumb

Design the sync so that sending the same batch twice is harmless. Networks retry, apps crash mid-request, and laptops sleep at the worst possible moment.

Idle time is a policy, not a feature

Detecting that nobody has touched the keyboard or mouse for ten minutes is the easy part. Deciding what to do about it is not, because the right answer depends on the team. A design agency might want idle time thrown away. A support team on calls might want it kept, because talking on the phone looks idle to a computer.

So don't hard-code a rule. Staffvertex lets each team choose whether idle time is kept, discarded, asked about, or whether the timer simply stops. Ask the person first whenever you can. "You were away for 14 minutes, keep this time?" is fair, and it catches the meeting that happened away from the desk.

Screenshots and privacy

Screenshots are the feature buyers ask about and employees dread. I'd build them, because some clients genuinely need proof of work, but I'd build them carefully:

Off by default. A team turns them on deliberately, and everyone tracked can see that they're on.
Blur options, so a screenshot can show that work happened without showing private messages or client data.
Clear retention, so old screenshots are deleted on a schedule instead of piling up forever.
Honest operating system permissions. On macOS, screen capture requires the Screen Recording permission, so only ask for it when screenshots are actually enabled.

Staffvertex follows that pattern: screenshots are optional and off by default, with blur controls. Activity and app tracking sit in the same bucket. Useful for some teams, invasive for others, so they should be settings, not assumptions.

Explaining a tracked day step by step does more for trust than any privacy policy.

From hours to timesheets to invoices

Tracked time is raw material. The value shows up when it turns into something a manager or client acts on, and the chain usually looks like this:

Timesheets. A week of intervals grouped by person and day, with overtime calculated and a way to approve or send back.
Reports. The same data cut by project, client or task, exportable, and ideally emailed on a schedule so nobody has to remember to run them.
Invoices and pay. Hours multiplied by the right rate. Rates differ per person, per project and sometimes per client, so model them as their own records with start dates, not as one number on the user.

Staffvertex covers all three, along with project expenses. If you're building a smaller tool, I'd still design the data with invoices in mind from day one. Retrofitting rates onto months of existing time entries is painful.

A data model that survives edits

People edit their time. They forget to start the timer, they log a meeting after the fact, they split two hours across two projects. Your data model has to handle that without losing what originally happened.

Whether you use MongoDB or a relational database, a few decisions hold up well:

Store intervals, not totals. Each time entry has a start, an end, a user, a project and optionally a task, all in UTC. Durations are calculated, never stored as the only record.
Record the source. Desktop, web, mobile or manual entry. Managers reasonably want to know which hours were added by hand.
Keep an edit history. When someone changes an entry, keep the old values. It settles disputes and it catches bugs.
Index for the questions you ask most. In MongoDB, a compound index on user and start time covers "my week", and one on project and start time covers project reports.
Store the user's time zone with the entry. A day boundary means midnight where the person is, not midnight on the server.

Choosing the stack

A time tracker is really three apps that share one API: the web app where people plan work and read reports, the desktop app that does the tracking, and the API with its database in the middle.

For the web app and API, the MERN stack is a natural fit. Time entries, projects and teams map cleanly to MongoDB documents, Express and Node.js handle a busy API comfortably, and React is a good match for the timer and board interfaces. Staffvertex's web app runs on Next.js, which adds server rendering for the public marketing and pricing pages, the pages that need to rank on Google.

The desktop app is its own project. Browser tabs get throttled and closed, so serious tracking needs a desktop client. Staffvertex ships for Windows and macOS. Plan for code signing, auto-updates and the operating system permissions from the start, because each one takes longer than it looks.

Should you build your own?

If you just need your own team to track hours, don't build anything. Use an existing tool. Staffvertex has a free plan for a single user, and so do several of its competitors.

Building makes sense when one of these is true:

Time tracking is the product you want to sell.
Your workflow is unusual enough that existing tools fight you, such as a specific approval chain or payroll rule.
You need tracking built into a product you already have, for example a marketplace that bills clients by the hour.

In those cases, start small: the timer, offline sync and a weekly timesheet. Get those trusted first. Screenshots, invoices and integrations can follow once people rely on the core.

If you're planning a SaaS product like this and want someone who has built one end to end, see how I work on MERN stack projects or tell me what you're building. You can also look at Staffvertex itself to see these ideas running in production.

Originally published on my portfolio. I'm Osama Khattak, a MERN stack and Next.js developer in Islamabad. See my work at osama-s-porfolio-beige.vercel.app.

Contractor Website Design: How an Instant Quote Form Wins More Leads

Osama Khattak — Tue, 27 Oct 2026 11:39:38 +0000

Picture a homeowner on their phone at 10 pm, wondering what a carport would cost. The website says "Call us for a free quote". It's 10 pm. They close the tab, and by morning they've found someone else.

That's the problem an instant quote form solves. I built the website for Carports Hawaii, an aluminium carport, patio cover and pergola company that serves the Hawaiian islands, and gave it an instant-quote form: enter the width and length, see the square footage and a price range. This article covers how I'd design a contractor website around that idea.

The one job of a contractor website

A contractor's website isn't a brochure. Its job is to turn a stranger into a quote request, and everything on the page either helps with that or gets in the way. That makes the plan simple:

Say what you do and where, in one line, above the fold.
Show proof: photos of finished jobs, reviews, licence details.
Make asking for a price effortless, at any hour.

The offer, the area served and the next step, all on the first screen.

Why an instant quote works

Price is the first question everyone has and the last thing most contractor sites answer. Visitors assume the worst when a price is hidden. An instant estimate does three useful things at once:

It answers the question right away, so the visitor stays on the page.
It filters out people whose budget is far off, which saves the sales team wasted site visits.
It gets the visitor to take a small action, entering two numbers, which makes the next step easier.

Someone who has just seen that their carport falls inside their budget is far more likely to fill in their name and phone number than someone who has seen nothing.

Designing the quote form

The original Carports Hawaii form was four boxes in a single row: width and length to fill in, then the square footage and a price range worked out from them. A few principles make a form like that work:

Ask for measurements before contact details. Give the estimate first. Asking for an email before showing anything feels like a trap.
Use the words customers use. "Width" and "length" in feet, not "span" and "projection".
Calculate as they type. Square footage should appear the moment both numbers are in, with no button to press.
Place it high on the page. On Carports Hawaii it sat directly under the headline. Don't make people hunt for it.
Make it work with a thumb. Numeric keyboards on phones, big tap targets, and labels that stay visible while typing.

Keep the first step tiny

Two inputs and an answer. Anything more, such as roof style, colour or installation date, belongs in the follow-up form after the visitor has seen a number.

Show a range, not a promise

Contractors worry, reasonably, that a website price becomes a promise. The answer is a range plus a clear next step. The live Carports Hawaii site does this well today: its cost estimator gives a low and high figure per square foot, which differs by island, and says the final price is set after a free site inspection.

That pattern is worth copying:

Show a low and a high estimate, not one number.
Adjust for the factors that really change price, such as location or material, and nothing more.
State what the final price depends on, in one sentence.
Offer the next step right there: book a free inspection or request an exact quote.

Put trust next to the form

The moment before someone submits their phone number is the moment they wonder whether you're legitimate. Put the proof right beside the form, not on a separate About page:

Licence number and years in business.
Your Google review rating and count, linked to the reviews.
Three or four photos of real installations, ideally local ones.
Warranty terms in one line.

Carports Hawaii backs this up with a full photo gallery of finished installations. For a visual product like a carport, the gallery is often the most visited page after the home page.

Product types and a structure guide answer the next questions before a visitor has to ask.

Service-area pages for local search

Contractors win most of their search traffic from local searches like "carport installation Maui". A single page that lists every area you serve rarely ranks for any of them. Give each real service area its own page with:

The area in the title, heading and URL.
Real local details: jobs completed there, local permit or weather considerations, a local photo.
The same quote form, so a visitor who lands there can act straight away.

Avoid copying one page and swapping the place name. Google treats near-identical pages as one, and visitors notice too. Pair the pages with a complete Google Business Profile, and ask every happy customer for a review. For a deeper look at the technical side, see my technical SEO checklist.

Building it in WordPress

Carports Hawaii runs on WordPress, which suits most contractors: the team can add gallery photos and edit pages without a developer. For the quote form itself there are two routes:

A form plugin with calculated fields. Fine for simple rules such as area multiplied by a rate. Quick to build and easy for the owner to adjust.
A small custom script. Better when pricing depends on several factors, such as location, size bands and add-ons, or when you want the estimate to update instantly as people type.

Either way, keep the rates somewhere the owner can change them. Material costs move, and a form that quotes last year's prices does more harm than no form at all. This is the kind of build my WordPress development service covers, and I design the flow in Figma first when the form is complex, as part of my UI and UX design work.

Measure what the form brings in

A quote form is only worth what it produces, so measure it from day one:

Track estimate views and form submissions as separate events in Google Analytics.
Record where each lead came from: which page, which search, which campaign.
Ask the sales team which leads became jobs, and compare the form against phone calls.

Then improve one thing at a time. Move the form higher, cut a field, change the button text, and watch the numbers.

You can see the live site at carportshawaii.com. If your own website gets visitors but not enquiries, tell me about it. The fix is often smaller than you'd expect.

Originally published on my portfolio. I'm Osama Khattak, a MERN stack and Next.js developer in Islamabad. See my work at osama-s-porfolio-beige.vercel.app.

How to Build a Furniture Ecommerce Website in Pakistan

Osama Khattak — Tue, 27 Oct 2026 11:39:29 +0000

A sofa can cost more than a phone, it takes two people to carry, and nobody wants to send one back. That's why furniture is one of the hardest categories to sell online. Buyers need far more reassurance than they do for a t-shirt, and the website has to give it to them.

I built Timbera.pk, an online furniture store based in Islamabad, on WordPress and WooCommerce. This guide is how I'd plan a furniture ecommerce website for buyers in Pakistan today, from choosing the platform to the checks I run before launch.

Timbera.pk opens with one clear promise and one button.

Why furniture is different online

Three things set furniture apart from most ecommerce:

High price, low frequency. People buy a bed every few years. They research for longer, compare more, and often visit the site several times before ordering.
It has to fit. Dimensions matter as much as looks. A dining table that is 10 cm too long for the room is a return, and returns of bulky items are expensive.
Delivery is part of the product. Buyers want to know when it arrives, whether it comes assembled, and who carries it up the stairs.

Every page on the site should answer at least one of those worries.

Choosing a platform: WooCommerce or Shopify

Timbera runs on WordPress with WooCommerce, with Elementor for page layouts. For a Pakistani furniture business, that combination has real advantages:

No monthly platform fee and no transaction fee from the platform itself.
A wide choice of local payment and courier plugins.
Full control over product attributes, which you need for filters such as fabric and colour.
WordPress for content, so buying guides and room ideas live on the same domain as the shop.

Shopify is faster to start and needs less maintenance. The catch for Pakistan is payments: Shopify's own payment service isn't offered in Pakistan, so you depend on third-party gateways and pay Shopify's extra fee on top. If you choose WooCommerce, budget for hosting, backups and plugin updates instead. If you want help choosing or building, that's exactly what my WordPress development service covers.

Payments that work in Pakistan

Most stores here end up offering a mix:

Cash on delivery. Still expected by many buyers. For expensive pieces, consider asking for a deposit before dispatch, and say so clearly on the product page rather than at checkout.
Mobile wallets. JazzCash and Easypaisa are widely used and both offer online merchant payments that can be connected to WooCommerce.
Cards and bank transfer. Through a local payment gateway or your bank. Bank transfer with a screenshot of the receipt is common for big orders.

Before you go live

Place a real order with every payment method, on a phone, on mobile data. Payment pages that work on office Wi-Fi and fail on a 4G connection are more common than you'd think.

Structure the catalogue around how people shop

People shop for furniture by room and by type: "sofas", "beds", "dining tables". Timbera's categories follow that: sofas, beds, dining tables, chairs, tables and consoles, mirrors, and book racks and shelves. Keep the top level short and obvious.

Then use product attributes, not more categories, for the things people filter by. Timbera's shop filters by price, colour and fabric. Set attributes up properly in WooCommerce from the first product. Adding them to 80 products later is slow, manual work.

Category rows with real prices in rupees let people judge the range before clicking.

Product pages that answer the real questions

A furniture product page needs more than a photo and a price. Before someone pays, they want to know:

Exact dimensions in centimetres or inches: width, depth, height, and seat height for chairs and sofas.
Materials, written plainly: solid wood or engineered board, which wood, which fabric.
Delivery time and cost for their city, not hidden until checkout.
Assembly: does it arrive assembled, and if not, who does it.
Care and warranty, plus what happens if it arrives damaged.

Photos come next. Show the piece from several angles, one close-up of the material, and one photo in a real room for scale. Use the same background and lighting across the catalogue, because a consistent catalogue looks like a business that can be trusted with a large order.

Keep it fast on a phone

Most furniture browsing in Pakistan starts on a phone, often on mobile data. Large product photos make that the biggest risk to a furniture store's speed. The fixes are well known:

Serve images as WebP, sized for the slot they appear in, and lazy-load everything below the first screen.
Use page caching, and a CDN in front of the site.
Keep the plugin list short. Each plugin adds scripts to every page, including the ones that don't use it.
Test on a mid-range Android phone, not only on your laptop.

The storefront on a phone: the screen most buyers actually see.

SEO for a furniture store

Category pages are where a furniture store wins search traffic. Someone searching "sofa set price in Pakistan" wants a page of sofas, not one sofa. So give each category page a short, useful introduction, a descriptive title and a clean URL such as /product-category/sofas/.

Write your own product descriptions. Copying the supplier's text gives Google nothing new to rank.
Add Product structured data with price and availability so search results can show them.
Name image files and write alt text that describes the piece: "walnut king size bed with upholstered headboard".
Publish buying guides, such as how to choose a sofa size for your lounge, and link them to the right categories.

If you already have a store that isn't getting found, my SEO service starts with exactly these checks.

A launch checklist

Before announcing the store, I go through this list:

Every page has your own business name, address and policies. Search the whole site for any text left over from the theme's demo content.
Shipping, returns and payment policies are written for Pakistan, in plain language.
Every button and link points to the live domain, not a staging copy.
Test orders with each payment method, on a phone.
Order emails reach the customer and the shop, and don't land in spam.
Google Search Console and analytics are set up, and the sitemap is submitted.

A furniture website is never really finished. New collections arrive, prices change, and seasonal sales come and go. Build it so the owner can manage all of that without a developer, and keep the developer for the things that matter: speed, payments and search.

Planning a store of your own? See Timbera.pk live, read the Timbera case study, or send me the details of your project.

Originally published on my portfolio. I'm Osama Khattak, a MERN stack and Next.js developer in Islamabad. See my work at osama-s-porfolio-beige.vercel.app.

How to Hire a MERN Stack Developer: A Practical Checklist

Osama Khattak — Tue, 27 Oct 2026 11:39:17 +0000

I'm a MERN stack developer, so I'm writing this from the other side of the table. I've seen how clients find developers, what they check, and more often what they forget to check. The good news is that most bad hires are avoidable with a few hours of homework before the first call.

Here's the checklist I'd use if I were hiring a MERN stack developer myself.

What a MERN stack developer actually does

MERN stands for the four pieces of a JavaScript web application:

MongoDB, the database, which stores data as flexible JSON-like documents.
Express, the web framework that defines your API routes on the server.
React, the library for building the interface people click on.
Node.js, the runtime that runs JavaScript on the server.

A MERN stack developer can build all four layers, which means one person can take a product from the database to the button. That's the main reason to hire one: fewer handoffs, and nobody saying "that's a back-end problem".

Is MERN the right stack for your project?

MERN is a strong choice for:

SaaS products and dashboards behind a login.
Marketplaces, booking systems and internal tools.
Apps with real-time features such as chat, notifications or live updates.

It's not always the best choice:

Public pages that must rank on Google. A plain React front end renders in the browser. Use Next.js for those pages, which keeps the same JavaScript skills but renders on the server. I explain the difference on my Next.js development page.
Content sites and simple stores. A well-built WordPress site is often faster to launch and easier for your team to edit.
Heavily relational data, such as complex accounting, may suit a relational database better than MongoDB.

A good developer will tell you when your project doesn't need their favorite stack. Treat that as a point in their favor.

Freelancer, agency or full-time hire

A freelancer suits a defined project or a first version. You get one accountable person and usually a faster start. The risk is availability, so ask how many projects they run at once.
An agency suits work that needs several specialists in parallel. You pay more for coordination, and the person who sold you the project may not be the person writing the code.
A full-time hire suits a product you'll develop for years. The hiring process is slower, but knowledge stays in the company.

Many teams start with a freelancer to ship the first version, then hire full-time once the product has proven itself.

How to read a developer's portfolio

A portfolio is only useful if you check it properly:

Open the live sites. Are they still up? Do they load quickly on your phone? A broken project in a portfolio is worth asking about.
Ask what the developer actually did. "Worked on" can mean anything. On my own projects page I spell it out per project. For example, on NetworkUstad my work was SEO, not the design, and the page says so.
Look for something close to your project. If you're building a SaaS product, a time tracker like Staffvertex tells you more than ten landing pages.
Check the code if you can. A GitHub profile shows how someone names things, structures a project and writes commit messages. Client code is often private, so personal projects count too.

Questions that separate good from good-looking

You don't need to be technical to ask these. Listen for specific, concrete answers rather than buzzwords.

"How would you design the database for my app?" A good answer starts with how the data will be read, not just what fields exist, and mentions indexes.
"How do you handle logins and passwords?" Listen for hashed passwords, secure sessions or tokens, and role checks on the server, not only in the interface.
"What happens when the API gets bad input?" Validation, clear error messages and no crashes.
"How will you deploy it, and how do we release updates?" There should be a plan, not "we'll see".
"What would you build first, and what would you leave out?" Good developers cut scope to ship sooner.
"How will I know how the project is going?" You want a rhythm: weekly updates, a preview link, a shared task board.

A useful test

Ask them to explain a past project's architecture in plain English. If they can make it clear to you, they'll be able to explain problems to you during your project too.

Run a small paid trial

Before committing to a large project, pay for one small, real piece of work that takes a few days: a single feature, an API endpoint with its screen, or a bug fix in your existing code. You'll learn more about code quality, communication and reliability from that than from any interview. Pay for it. Good developers rarely do unpaid test projects.

Working with a developer in Pakistan

Pakistan has a large pool of experienced JavaScript developers, and many work with clients in the US, UK, Europe and the Gulf. I'm based in Islamabad and work with clients remotely over Zoom, Trello and GitHub. A few practical points:

Time zones. Pakistan Standard Time is UTC+5. Afternoons in Pakistan overlap with mornings in the UK and Europe, and Pakistani evenings overlap with mornings on the US East Coast. Agree on a daily window when both sides are online.
Communication. Written updates matter more when you're not in the same room. Ask for a short summary at the end of each week: what shipped, what's next, what's blocked.
Payments. Freelance platforms such as Upwork handle payment and escrow. For direct contracts, services like Payoneer and Wise are widely used.

Contracts, milestones and handover

Write down the scope as a list of features and pages, and agree what "done" means for each.
Split payment into milestones tied to working software you can click through.
Make sure the code lives in a repository you own, from the first day.
Agree who owns hosting, domains and third-party accounts. They should be in your name.
Ask for a handover: how to run the project, how to deploy, and where the important settings live.
Agree on support after launch, because there will be bugs to fix.

Red flags

They agree to everything and never ask a question about your business.
They want full payment up front for a large project.
Portfolio links are broken, or they can't say what their part was.
They want to host your code in their own account with no access for you.
Estimates come back within minutes, before they've understood the scope.

If you're looking for a MERN stack developer for a SaaS product, marketplace or internal tool, here's how I work on MERN stack projects, and you can read about my background. When you're ready, tell me about the project. I'll tell you honestly whether MERN is the right fit.

Originally published on my portfolio. I'm Osama Khattak, a MERN stack and Next.js developer in Islamabad. See my work at osama-s-porfolio-beige.vercel.app.

Technical SEO Checklist for Blogs and Content Sites

Osama Khattak — Tue, 27 Oct 2026 11:38:57 +0000

I started my career in SEO, before I wrote much code. At Nausal Technologies, the work I did on client sites grew their traffic by 60%, ranked more than 50 target keywords and lifted organic leads by 35%. Very little of that came from clever tricks. Most of it came from fixing the unglamorous technical problems that stop good content from ranking.

This is the checklist I work through on blogs and content sites, including NetworkUstad, an IT certification publication I did SEO for, and EditorialDiary, a multi-topic blog. It's ordered by impact: if step one is broken, nothing after it matters.

1. Crawling and indexing

Before anything else, confirm Google can reach and store your pages.

robots.txt allows the pages you want indexed, and doesn't block the CSS and JavaScript Google needs to render them. Blocking a whole assets folder is a surprisingly common mistake.
An XML sitemap lists every indexable URL and nothing else: no redirects, no 404s, no pages marked noindex. Submit it in Google Search Console.
Every important page returns a 200 status and has a canonical tag that points to itself.
Noindex is only where you mean it: thank-you pages, internal search results, thin tag archives. A leftover noindex from a staging site can hide an entire website.

2. When pages are discovered but not indexed

The Page indexing report in Search Console tells you why pages aren't indexed. The reason that confuses people most is "Discovered - currently not indexed". Google knows the URL exists but hasn't bothered to crawl it.

I saw it on my own portfolio a few weeks after launch: 11 pages indexed, 9 discovered but never crawled, including the service page I most wanted to rank. Nothing was technically broken. The site was new, it had no links from elsewhere, and several pages were short. Google simply didn't see enough reason to hurry.

The fixes for that status are rarely technical:

Make the pages worth crawling. Expand thin pages with real, specific content, or merge them.
Link to them from pages Google already crawls often, such as your home page and your best-performing articles.
Earn a few links from other sites, which tells Google the site matters.
Use URL Inspection to request indexing for the most important pages, then give it time.

Don't panic about it

Requesting indexing over and over doesn't help. Improve the pages and the links pointing to them, then wait a week or two before checking again.

3. Site structure and topic clusters

Content sites rank best when related articles are grouped and linked as a cluster: one broad guide, surrounded by detailed articles that link back to it.

NetworkUstad is a good example. Its CCNA material is split into guides by exam domain, each with its own set of articles, so a reader and a search engine can both see how the topics fit together. A random stream of posts on the same subjects would rank far worse.

Study guides grouped by certification: a clear cluster for readers and for Google.

For a multi-topic blog like EditorialDiary, which covers ten categories, the structure question is different: which categories deserve real depth? Keyword research answers it. Pick the topics where you can realistically rank, build those out properly, and stop spreading effort evenly across everything.

4. Internal links

Internal links are the cheapest ranking factor you control.

Link from every new article to two or three older, related ones, and go back and link older articles to the new one.
Use descriptive anchor text, such as "subnetting cheat sheet", never "click here".
Make sure no important page is an orphan, with no internal links pointing at it.
Keep important pages within three clicks of the home page.
Use breadcrumbs, which help users and give search engines the site hierarchy.

5. Titles, descriptions and headings

One unique title per page, under about 60 characters, with the main keyword near the start.
A meta description of about 150 to 160 characters that reads like a reason to click.
Exactly one H1 per page, matching what the page is about.
H2s and H3s in order, describing sections the way a reader would scan them.
Descriptive alt text on images, written for someone who can't see them.

On WordPress sites, an SEO plugin makes these easy to manage at scale. On custom sites, build them into the templates so no page ships without them. I set up every new post on Mindsieves this way, so it was search-ready the moment it was published.

6. Structured data

Structured data, usually JSON-LD, tells search engines what a page is: an article, a breadcrumb trail, a product, a person. It can earn richer search results and it helps search engines and AI tools understand your content.

Add Article or BlogPosting markup with the headline, author, dates and image.
Add BreadcrumbList markup that matches the visible breadcrumbs.
Add Organization or Person markup once, and link it from everything else.
Test with Google's Rich Results Test and the Schema.org validator after every template change.

7. Page speed and Core Web Vitals

Speed is a ranking factor, and it matters even more for keeping readers. When I worked on WordPress sites, the fixes that helped most were consistent: caching, compressing and resizing images, and cutting the plugin list down. On the HTML and CSS builds I did, trimming what each page loaded cut average load time by more than a second.

LCP (largest contentful paint): serve the main image or headline fast. Preload it, size it properly, and don't fade it in.
CLS (layout shift): give images and ads fixed dimensions so the page doesn't jump while loading.
INP (responsiveness): cut heavy scripts, especially third-party widgets that run on every page.

If you're building something new, a framework that renders pages on the server, such as Next.js, makes good scores far easier to reach and keep.

8. Duplicate and thin content

Content sites generate duplicate pages without anyone noticing. Check for:

Tag and date archives that repeat the same posts. Noindex them or remove them.
The same page available with and without www, or with and without a trailing slash. Pick one and redirect the rest.
Paginated archives with missing or wrong canonicals.
Old, thin posts that get no traffic. Update them, merge them into a stronger article, or remove them with a redirect.

9. Links from other sites

Technical SEO gets a site ready to rank. Links from other sites are what convince Google it deserves to. For a content site, the links that work are the ones you earn: original guides people cite, useful tools, data nobody else has published. Relevant guest articles and outreach help too. Paying for bulk links from unrelated sites doesn't, and it can get you penalized.

10. Monitoring

Check Search Console weekly for new indexing errors and drops in impressions.
Watch which queries are climbing, and give those pages more internal links and fresher content.
Re-test structured data and speed after every theme, plugin or template change.
Run a full audit every few months, and always before and after a redesign or migration.

If your content is good but your traffic isn't, the problem is usually somewhere in steps one to four. That's where my SEO service starts, and because I'm also the developer, the fixes get made in the code instead of sitting in a report. Send me your site and I'll tell you what I'd look at first.

Originally published on my portfolio. I'm Osama Khattak, a MERN stack and Next.js developer in Islamabad. See my work at osama-s-porfolio-beige.vercel.app.