SSR for Marketplace SEO: A Practical Playbook

TL;DR: Marketplaces win organic traffic when every listing and every search-intent page returns real HTML. On Yatty, a tattoo artist marketplace, organic traffic rose 45% after portfolio galleries were server-rendered, artists were indexed in Elasticsearch for proximity search, and routes were structured around city and style. The trap to avoid: thousands of empty city + style combinations that Google treats as thin pages.

Yatty is a tattoo artist marketplace. People search the way they think: a style, a place, a person. “Fine line tattoo artist near me.” “Japanese tattoo Lahore.” The product had to answer those searches, and a client-side shell that loads portfolios after the page is “done” can’t do that.

After server-rendered galleries and proximity search went live, organic traffic rose 45%. Here’s what changed, and what I’d tell anyone running a marketplace.

Why client-rendered marketplaces struggle in search

Google can render JavaScript. But rendering is queued, it costs Google more, and anything that depends on client-side fetches, scroll events or clicks may never be seen. For a marketplace with thousands of listings, “Google will probably render it eventually” isn’t a strategy.

Then there’s the user. A gallery page that paints a spinner first has a poor Largest Contentful Paint. On an image-heavy site, LCP is usually the hero image, so how fast that one image shows up affects both rankings and bounce.

What we built

1. Server-rendered portfolio galleries

Each artist’s portfolio page now returns complete HTML: name, styles, location and the gallery markup. A crawler sees the same page a person sees. No waiting for JavaScript.

With images, the details matter:

Give the first, above-the-fold image priority (no lazy loading on the LCP image).
Lazy-load everything below the fold.
Write real alt text that describes the piece (“fine line floral forearm tattoo”), not “image 1”. Image search is a real traffic source for visual marketplaces.

2. Proximity search with Elasticsearch

Artists were indexed in Elasticsearch with their location as a geo_point, so “near me” and “in this city” searches run as geo_distance queries and sort by distance. That’s the product side of local intent. The SEO side is making those results reachable at stable URLs.

3. Routes built around search intent

Routes were structured around city and style, the two ways people actually search. A page for one city and one style gives Google a clear match for queries like “realism tattoo artists in [city]”, and it gives users a page that’s useful on its own.

The trap: thin combination pages

City × style routes multiply fast. Fifty cities and twenty styles is a thousand pages, and most of them will have zero or one artist. Google sees those as thin or duplicate, and a lot of thin pages can drag down how it treats the whole site.

Rules I’d hold to:

Only index combinations with enough real listings. Set a minimum, and put noindex on pages below it until they fill up.
Put the combinations that have listings in the sitemap, not every possible one.
Add something unique to each page. Even a count, a short local intro and the top artists makes it more than a filtered list.
Keep one canonical URL per combination. Filter parameters like sort order shouldn’t create new indexable URLs.

What to measure

Indexed pages vs submitted pages in Google Search Console. A growing “Crawled, currently not indexed” count means thin pages.
Impressions by page template (artist, city, city + style), so you know which template is earning traffic.
LCP on gallery pages, on mobile.

FAQ

Is SSR necessary for SEO?

Not always, but for marketplaces with many listings it’s the safest choice. Static generation works too for pages that don’t change often. What matters is that the HTML contains the content before any JavaScript runs.

How do you avoid thin content on location pages?

Only index location or category pages with enough real listings, add unique content to each, and leave empty combinations out of the sitemap with noindex.

Does Elasticsearch help SEO directly?

No. Elasticsearch makes proximity and filtered search fast for users. The SEO gain comes from exposing those results as crawlable, server-rendered pages at stable URLs.

Full context in the Yatty case study. Want this for your marketplace? See hire a Next.js developer.