KittenPlein After Launch

When I wrote How I Built KittenPlein on May 11, 2026, the story was mostly about building the product. The marketplace foundation was there: listings, accounts, search, breeder profiles, moderation, payments, chat, emails and the first version of the SEO structure.

Since then, the project has moved into a more interesting phase. KittenPlein is no longer only something I built. It is something people are beginning to use.

The platform now has its first real users and listings, which changes the work completely. Building a marketplace is one kind of challenge. Growing one is another. The focus is now on SEO, discoverability, content quality and making sure every new listing strengthens the overall marketplace.

The Shift After Launch

Before launch, most decisions were about product completeness. Could a seller create a listing? Could a buyer browse kittens? Could messages, payments, moderation and emails work reliably?

After launch, the questions became different:

• Can buyers actually find KittenPlein through Google?
• Are the public pages clear enough to rank and convert?
• Do listings create useful search pages instead of isolated detail pages?
• Do breeders understand why they should publish on KittenPlein?
• Does the product feel alive when supply is still early?

That last point matters a lot. Early marketplaces have a cold start problem. You need buyers to attract sellers, and sellers to attract buyers. SEO is one of the best ways to break that loop slowly and honestly, because it creates durable entry points before the marketplace has large paid acquisition budgets or brand recognition.

This is also where the work starts to look less like feature delivery and more like product operations. A marketplace needs supply, demand, trust, search visibility and useful feedback loops. The code still matters, but the real question becomes whether the system is compounding in the right direction.

SEO Is Now The Main Growth Channel

The current focus is organic search. KittenPlein is a vertical marketplace, so the search opportunity is not only one big keyword like "kitten kopen". The real surface is much wider.

People search by breed, location, safety questions, price expectations, breeder trust, documents, age, vaccination, pedigree and whether a kitten is available now. That means the site needs more than a homepage and a listing grid. It needs a structured search ecosystem.

The most important page types are now:

• Current kittens for sale
• Breed pages such as Ragdoll, Maine Coon, Britse Korthaar and Siberische kat
• Location pages for province and city based searches
• Seller and breeder profile pages
• Guides around safe kitten buying
• Knowledge centre articles for long tail questions
• Seller focused pages like kittens verkopen via KittenPlein

The goal is not to create thin programmatic pages. The goal is to make every page useful enough to deserve traffic. A breed page should help someone understand the breed, see available listings when they exist, navigate to related searches and continue into buying guidance. A location page should help people browse locally without pretending there is supply where there is not.

From a portfolio perspective, this is the part of the project that connects product engineering with technical SEO. I like building systems where the same data model improves the user experience, the search experience and the operational workflow. That is the kind of product thinking I try to show through my projects.

Designing Pages Around Search Intent

The biggest practical change after launch is that every public route needs a clearer job. A listing detail page has a different purpose from a breed page. A breed page has a different purpose from a seller profile. A safety guide has a different purpose from a location page.

That sounds obvious, but it affects the code. If every page only receives a generic list of listings, the marketplace cannot explain itself well. The page needs to know its own intent, the inventory it can truthfully show and the next route a user should visit.

Here is a simplified TypeScript shape for the kind of route model that now matters more:

type MarketplaceRouteIntent =
  | "national-listings"
  | "breed-listings"
  | "location-listings"
  | "seller-profile"
  | "buying-guide";
 
type DiscoveryRoute = {
  intent: MarketplaceRouteIntent;
  canonicalPath: string;
  primaryKeyword: string;
  relatedPaths: string[];
  inventoryScope?: {
    breedSlug?: string;
    provinceSlug?: string;
    citySlug?: string;
  };
};
 
export function shouldIndexRoute(route: DiscoveryRoute, listingCount: number) {
  if (route.intent === "buying-guide") return true;
  if (route.intent === "seller-profile") return listingCount > 0;
  return listingCount > 0 || route.relatedPaths.length >= 3;
}

The exact production code is more specific, but the principle is the same. Routes should not be indexable just because they exist. They should be indexable when they have enough purpose, content and internal context to help a real user.

That distinction matters for a marketplace with filters. Breed, province, city, sorting, price and trust filters can create many URL combinations. Some are useful. Many are not. The job is to expose the pages that match real search intent while keeping noisy variations under control with canonical URLs, metadata and route design.

First Users Change The Product

The first users and listings are small in absolute numbers, but they are very valuable. They expose what a product actually is, not what it looked like in my head.

Real listings make the browsing experience feel different. Listing cards are no longer placeholders for a system. They are the system. Suddenly small details matter more: how the title reads, how trust signals are ordered, what the empty states say, how quickly a buyer can understand location and availability, and whether sellers have enough guidance while creating an ad.

The same is true for onboarding. A seller does not care that the database model is elegant. They care whether the form is understandable, whether image upload works, whether the listing looks professional and whether they feel the platform can bring serious buyers.

That feedback loop is now more important than adding large new features. At this stage, every real listing is also product research.

This is where a marketplace starts teaching you what to build next. Not through a roadmap document, but through friction. Which fields do sellers skip? Which trust signals do buyers notice? Which listings get views but no conversations? Which pages get impressions in search but no clicks? Those answers are more useful than another speculative feature.

Listings As SEO Assets

One of the biggest lessons from working on KittenPlein is that marketplace SEO should be designed around inventory quality. A listing is not only a product object. It is also a search asset.

A good listing can support:

• The individual kitten detail page
• Breed search pages
• Province and city pages
• Recently added listing sections
• Internal links from knowledge articles
• Seller or breeder profile pages

That only works if the data is structured. Breed, province, city, vaccination status, chip status, pedigree, seller type and availability all need to be fields the system can understand. If everything is buried in a free text description, the site cannot build strong discovery paths from it.

This is why the original data model around trust is starting to pay off. The same fields that help buyers compare kittens also help the site create clearer pages for search engines.

One useful mental model is to treat every approved listing as a set of discovery signals:

type ListingDiscoverySignal = {
  listingSlug: string;
  breedSlug: string;
  provinceSlug: string;
  citySlug: string;
  sellerSlug?: string;
  trustSignals: string[];
};
 
export function getDiscoveryLinks(signal: ListingDiscoverySignal) {
  return [
    `/kittens/${signal.breedSlug}`,
    `/kittens-te-koop/${signal.provinceSlug}`,
    `/kittens-te-koop/${signal.citySlug}`,
    signal.sellerSlug ? `/fokker/${signal.sellerSlug}` : null,
  ].filter((href): href is string => Boolean(href));
}

The point is not that every page needs a huge graph algorithm. The point is that good marketplace pages come from structured, reusable facts. Once those facts are explicit, they can improve cards, filters, breadcrumbs, related links, sitemap coverage, metadata and internal search.

What I Am Improving Now

The current work is less glamorous than building a payment integration, but probably more important for the next stage.

I am improving internal linking so that important pages are easier to discover from multiple paths. I am tightening metadata and page copy so each route has a clearer search intent. I am expanding useful content around buying safely, comparing breeds and understanding what responsible sellers should provide.

I am also paying more attention to crawl quality. A marketplace can accidentally create too many low value URL combinations through filters, sorting and search parameters. The goal is to expose the pages that should rank, while keeping noisy variations under control with canonical URLs, sensible metadata and route design.

The work looks like SEO, but it is really product architecture. Search engines need to understand the same thing users need to understand: what is available, where it is available, why it is trustworthy and what someone should do next.

The other priority is measurement. Search impressions are useful, but they are not the whole story. I want to know which pages lead to seller signups, which listings generate conversations, which content reduces buyer uncertainty and where the marketplace feels empty. That is the difference between ranking for a keyword and building a product that deserves the traffic.

Tradeoffs And Risks

The main tradeoff is that SEO led marketplace growth can tempt you to publish too many pages too quickly. It is easy to create every breed and every location route. It is harder to make each route useful, accurate and honest about supply.

That matters more in a pet marketplace than in many other categories. Growth is not useful if it encourages rushed decisions or low quality listings. KittenPlein has to balance acquisition with moderation, education and responsible seller presentation.

There is also a technical tradeoff. More public routes mean more metadata, more sitemap logic, more canonical decisions and more testing. A small application can become messy if every filter combination turns into a page with unclear ownership.

The safest path is to let real inventory and real user behaviour guide what becomes indexable. Strong breed pages, useful guides and trustworthy listing pages should come first. Very specific route combinations should earn their place over time.

The Marketplace Is Becoming More Real

The most satisfying change is that KittenPlein now has signs of life. Users are signing up. Listings are appearing. The product is moving from "can this work?" to "how do I make this grow carefully?"

That also makes the responsibility clearer. Pet marketplaces need more trust than many other categories. So the product still has to balance acquisition with moderation, education and responsible seller presentation.

The aim is not to become the loudest kitten marketplace. The aim is to become the clearest and most trustworthy place to start the search.

This is the phase where full-stack product work becomes especially satisfying. The backend fields, public pages, admin flows, emails, analytics and deployment choices all start to affect each other. If one part is weak, the marketplace feels weaker. If they reinforce each other, every new listing makes the system more useful.

What Comes Next

The next phase is about compounding. More indexable pages, better content, stronger internal links, clearer seller onboarding and more useful listing pages. I want KittenPlein to become better every time a new seller joins or a new guide is published.

The product foundation is already broad: listings, accounts, chat, payments, moderation, breeder profiles, favourites, emails and analytics. Now the priority is making that foundation visible to the right people.

I also want the seller side to become clearer. Breeders and private sellers should understand what a complete listing looks like, why structured trust signals matter and how KittenPlein can help serious buyers find them. That is part UX, part content, part SEO and part operations.

That is a very different kind of building. Less "ship the feature", more "strengthen the system". It is the same engineering mindset I bring to my services: make the product understandable, reliable, measurable and easier to improve over time.

Summary

The first KittenPlein post was about building a real marketplace with Next.js, PostgreSQL, Auth.js, Mollie and a full product backend. This follow up is about what happens after that foundation exists.

KittenPlein now has its first users and listings, and the work has shifted toward SEO led growth. The challenge is to turn structured marketplace data, buying guidance, breed pages, location pages and seller profiles into a discovery engine that brings buyers and sellers together over time.

That is the phase I am in now: not just building KittenPlein, but growing it.