Guest Post by Sumit Kapoor
I did not conceive of LyfSkills as a grand marketplace or an SEO project. I simply wanted to solve a problem I kept encountering as a parent: finding the right activities for children beyond school.
We started as a service provider in the extracurricular activity ecosystem. Working with parents, coaches and academies gave me a close view of both sides. Parents found it difficult to discover trustworthy options nearby. Many excellent coaches and academies still managed their work through calls, WhatsApp messages, spreadsheets and memory.
The next problem was on the provider side. At LyfSkills, we began building software that helps coaches and academies plan sessions, record notes and track a child’s progress. Once the supply side became better organised, the next question was obvious: could we make the same supply easier for a parent to discover?
That is how LyfSkills Discover came about.
Today, the marketplace has reached 300,000 users, entirely through organic search and without paid acquisition. We continue to rebuild parts of the product because a page that looks fine to us may still confuse a parent, perform poorly on an average phone or make little sense to a search engine.
Through this journey, I have come to see SEO through three basic principles:
- Understand what people are looking for and provide the right answer.
- Package that answer so people and search engines can find, understand and use it.
- Build enough trust for the market to believe that your answer deserves attention.
The format may change from blue links to maps, rich results or AI overviews. The basics remain the same.
Principle 1: Start with the question, not the keyword
My first SEO lesson came long before we started calling the work SEO.
As a service provider, I heard how parents described their needs. Even today, parents rarely ask for a broad category alone. Their questions are usually specific:
- Is there a good swimming class near my home?
- Will this academy take a five-year-old beginner?
- Can my child attend a trial before we pay for the term?
- Is this football class serious training or mainly recreational?
- What should I check before choosing a coach?
Providers describe the same activity through class type, age group, location, fee, batch timing and teaching format. At LyfSkills, our job is to translate between the language a parent uses and the way a provider structures the service.
For me, SEO begins here. A keyword tool can estimate demand, but it cannot explain the decision behind the search. “Tennis classes” is a keyword. “Tennis classes for a seven-year-old near Whitefield, a neighbourhood in Bengaluru” is a parent trying to decide what to do next.
The right answer is not always a blog post. It may be a category page, a locality page showing what is nearby, a provider profile with the right decision-making details or a practical guide about the first class.
At LyfSkills, we organise the marketplace around questions parents actually ask. We structure supply by activity, city and locality because these are the first filters that come up in most conversations. We show ratings, review depth, age suitability, trial options and provider details because these are the signals parents use while shortlisting.
This also stops us from creating a page merely because a keyword combination exists. “Dance classes in Bengaluru” and “dance classes in Whitefield” answer two different location needs. Ten pages that repeat the same content with minor wording changes do not help anyone. A URL earns its place only when it answers a distinct need and carries enough useful information.
I follow this sequence:
- Listen to the questions users actually ask.
- Understand the decision behind each question.
- Decide what kind of page or product experience answers it best.
- Map that answer to search demand.
If the answer is weak, SEO only makes a weak page easier to find.
Principle 2: Package the answer for the user and the machine
Finding the answer is only the first part. I still have to package it in a way that a parent can use and a search engine can retrieve and understand.
That has not changed as AI Overviews have become part of search. Search systems still need source material. They need to know what a page represents, how it connects with other pages and whether the useful information is available when the page is fetched.
For a marketplace, packaging goes far beyond writing copy. It starts with the data model and continues through taxonomy, metadata, structured data, rendering, performance and internal navigation.
Give the data a clear hierarchy
One large provider database may be convenient for us internally, but it is of little use to a parent. At LyfSkills, we organise the marketplace around the way people narrow a choice:
- the main discovery layer;
- verticals such as classes, sports facilities, gyms and trainers;
- cities;
- activities within cities;
- localities where enough supply exists; and
- individual listings.
Each layer has a job. A city page explains what is available. An activity page brings together providers, localities and comparison signals. A locality page helps a parent judge proximity. A listing page answers questions about one provider. I do not see value in creating a thin page that simply sends the visitor somewhere else.
Provider data is naturally messy. One business may call itself a dance school, another a performing-arts studio and a third may list only Bharatanatyam, hip-hop and contemporary dance. At LyfSkills, we map these descriptions into a common activity taxonomy while retaining the specific services that make each listing useful.
We apply the same discipline to location. Bengaluru, Bangalore and neighbourhood names cannot sit as unrelated strings. Our geographic hierarchy, URLs and parent-child relationships stay consistent. Without this, a user and Google both see fragments instead of one local marketplace.
Present the same data clearly at every layer
At LyfSkills, we present the same underlying data in three places.
First comes the visible page: the heading, description, location, activity, provider information, reviews and links that a parent can read.
The same data then feeds the title, meta description, canonical URL and indexing directives. These tell Google what the page covers, which URL is the main version and whether it should be indexed. Metadata cannot rescue a poor page, but generic or incorrect metadata can weaken thousands of otherwise useful pages.
We also present relevant facts as structured data, usually through JSON-LD. This gives Google a clearer view of the organisation, place, service, breadcrumb path, reviews and their relationships. The JSON does not carry a claim that is absent from the page. It simply gives structure to information that is already visible.
The database cannot say one thing, the title another and the JSON a third. Our marketplace data model is the common source for the page, metadata and structured data. This becomes important when the same system produces thousands of pages.
Deliver the answer before hydration
The next question is how this information reaches the browser and the crawler.
A client-rendered application can first return an almost empty HTML shell. JavaScript then fetches the headings, listings, filters and links. Someone on a fast laptop may not notice the delay. Google has to render the JavaScript before it sees the answer, while a parent on an average phone or an inconsistent mobile network feels the delay directly.
At LyfSkills, we make the core answer available in pre-rendered or server-produced HTML. The title, summary, listing data, important links, metadata and structured JSON arrive with the initial response. JavaScript then hydrates the page and adds filters, maps, sorting, saved lists and other interactions.
I see hydration as a way to make an already useful page interactive, not as the step that creates the page itself. The server output and hydrated application must also show the same city, activity, locality and listing relationships. Otherwise, Google sees one version while the user gets another.
This allows a parent to see useful content sooner. Important links work without waiting for a large JavaScript bundle, and a slow third-party map does not delay the whole page.
Treat Core Web Vitals as a product lever
I consider Core Web Vitals one of the strongest technical SEO levers because they connect what Google measures with what a user actually experiences.
Google does not look only at a synthetic test run on a perfect device. Through the Chrome UX Report, or CrUX, it receives aggregated field performance from eligible Chrome users. This shows how a page behaves across real devices and networks. Core Web Vitals are one set of signals within Google’s broader ranking systems. Strong scores do not replace relevance or guarantee rankings, but the metrics are too useful for me to treat as a technical hygiene item.
The three measures are also easy to relate to the product:
- Largest Contentful Paint (LCP) asks how quickly the main content becomes visible. A good target is within 2.5 seconds.
- Interaction to Next Paint (INP) asks how responsive the page feels when someone taps, types or changes a filter. A good target is under 200 milliseconds.
- Cumulative Layout Shift (CLS) asks whether content remains visually stable instead of jumping as images, ads or widgets load. A good target is 0.1 or lower.
The recommended Core Web Vitals thresholds are evaluated at the 75th percentile of page visits. A page is therefore not good merely because it works on our development devices. It needs to work for most users, including a parent opening a listing on an average Android phone over mobile data.
A marketplace makes this harder. Image-heavy cards can delay the largest paint. Maps, filters and large JavaScript bundles can block the main thread and slow an interaction. Missing image dimensions, late-loading banners and dynamic widgets can shift a button just as a parent tries to tap it.
At LyfSkills, this means correctly sizing and compressing images, reserving their layout space, prioritising the actual above-the-fold content, loading maps only when needed, splitting JavaScript by route, reducing main-thread work, caching stable responses and sending useful HTML from the server. We look at both lab and field results. Lighthouse helps diagnose a page; CrUX shows what eligible Chrome users experience over time.
I keep the Google outcome and the user outcome separate. Google can reward a strong page experience alongside relevance and other signals. Parents reward it in a more visible way: fewer exits from slow pages, more listings viewed, more filters used and more people reaching the next action. These engagement measures are product outcomes; I do not assume that our Analytics numbers are direct Google ranking factors.
For me, this is the real value of Core Web Vitals. A better LCP shows the parent useful choices sooner. A better INP makes filters and comparisons respond faster. A better CLS avoids misclicks. The same work that helps search also improves engagement because the marketplace becomes easier to use.
Use internal links as product navigation
Internal linking is often discussed only in terms of moving authority around a website. I first see it as a way to help the user make the next decision.
At LyfSkills, a city page leads to relevant activities, an activity page to useful localities and a locality page to suitable providers. A listing also leads back to comparable options rather than becoming a dead end.
These paths help Google discover inventory and understand relationships, but they also save a parent from restarting every search. If the internal-link structure follows the user’s natural path, it generally works for both.
Control duplicate and low-value URLs
A hyperlocal marketplace can produce countless combinations of categories, cities, localities, filters and sort orders. Most do not deserve a place in Google’s index.
We separate useful landing pages from temporary filter states. Stable canonical URLs, clean parameters, focused sitemaps and rules for low-supply combinations prevent empty or duplicate pages from competing with the useful ones.
My objective across all of this is straightforward: the answer should be clear in the data, correctly represented in the metadata and JSON, present in the initial HTML, fast on a real device and easy to reach through the site.
Principle 3: Earn trust inside and outside the product
I think of trust through a simple example. One hundred websites may have the right answer. Perhaps 30 know how to package it properly. The top three are usually the ones that have also given the market enough reason to trust them.
At LyfSkills, trust starts with what we put on the page: a clear address, the right category, ratings, review counts, service details and an honest indication of what we know and what we do not. A polished listing with unreliable information eventually loses both the parent and Google.
We are careful with provider claims. If a fact comes from a reliable public source or directly from the provider, we can structure it. If we cannot verify it, we do not present it as a certainty. A missing detail should remain missing rather than turn into marketing copy because a template needs another paragraph.
The product experience contributes as well. A stable page, a working filter, a clear provider identity and a consistent location build confidence one interaction at a time. This is why I do not see technical SEO and brand trust as separate workstreams.
External trust follows the same logic. Links and mentions show that someone outside the company recognises the source. Link building loses its meaning when it becomes a contest to collect the largest number of domains.
A parenting publication can naturally refer to LyfSkills while discussing how to choose a children’s class. A sports publisher can refer to us in an article about starting tennis. A random backlink from an unrelated website does little to establish our relevance to activities, coaching or local discovery.
My test for a link is straightforward:
- Would a real reader plausibly encounter and follow it?
- Is the surrounding article related to the destination?
- Does the publisher have an editorial reason to mention us?
- Is the linked page useful enough to deserve the reference?
For this reason, I value editorial collaborations, original research and useful resources more than mass submissions. A focused publication may be smaller, but the context of its mention is clearer. It can introduce real users and lead to further citations.
The same principle applies more broadly to coordinated marketing: channels work better when they support one another rather than becoming isolated tactics. Cassus Media's 360° Marketing Program is one example of that integrated approach.
At LyfSkills, this works as a cycle. A useful marketplace earns references. Better discovery brings more users, feedback and provider participation. Better supply and data then improve the answer we can give the next parent.
The three principles work together
I now bring most SEO discussions back to three questions:
Do we have the right answer? This comes from understanding the parent’s real need rather than matching a phrase.
Have we packaged it properly? At LyfSkills, this includes the data model, taxonomy, visible content, metadata, JSON-LD, pre-rendered HTML, Core Web Vitals, internal links and information architecture.
Have we earned trust? This comes from accurate information, a useful product, a dependable experience and relevant references from outside LyfSkills.
Missing any one of the three creates a problem. A trusted domain with a poor answer disappoints users. A strong answer hidden behind weak rendering may not be found. A properly built page without trust may remain below a better-known source. Speed cannot compensate for irrelevant content, but relevant content on a painfully slow page also falls short.
AI Overviews may answer more questions directly, and search may send fewer clicks for simple queries. The source still needs to understand the question, structure the answer and earn trust. Clear information architecture and dependable data remain relevant in either format.
This is what building LyfSkills continues to teach me. SEO is not something I add after the product is complete. It affects what we build, how we organise the data, how we deliver the experience and why a parent or Google should believe the answer.
