SEO for Marketplaces and Large Database Sites

Last updated: November 1, 2026.

Managing a 500-page site and managing a site that can generate 10 million URLs are not the same thing.

On corporate or B2B sites, a few hundred pages can be perfectly normal. But on marketplaces, classifieds, real estate, automotive, news, travel, movie, product comparison or any project fed by a large database, the number of URLs can reach the millions.

Here, a big part of SEO is no longer “How do we create more pages?” It turns into the question “Which pages should we actually create, which should we open to Google, and which should we never create at all?”

On large sites, sometimes the best SEO work isn’t opening new pages, but never generating millions of unnecessary URLs in the first place.

1. On large sites, the real problem isn’t generating URLs, it’s controlling them

A corporate site might have a few hundred URLs like these:

Homepage
Services
Products
Blog
About us
Contact

But on a marketplace or classifieds site, the number of URLs grows much faster. For example, once these start combining with each other, millions of different URLs can appear in theory:

100 categories
81 provinces
Hundreds of districts
Brand
Model
Color
Price
Year
Size
Features
Sorting

That’s why on large sites my first question isn’t “How many URLs do you have?” but “How many different URLs can you generate?”

Because they’re not the same thing.

2. Not every database record has to be a page on Google

We experienced this very clearly at Filmler.com, a Turkish movie site. Our database had about 450,000 cast and crew records.

In theory, we could have thought:

“If we have 450,000 records, let’s put 450,000 person pages in the sitemap. Even if each page gets just 1 visitor, that’s 450,000 visitors.”

That math sounds nice. In fact, this calculation is made a lot on large database projects. But in practice it doesn’t always work that way. Because as the number of pages grows, traffic doesn’t always grow.

On the contrary:

Thin pages can multiply.
Crawl resources can get spread thin.
The index can bloat.
Strong pages can lose weight.
Google can run into too many low-value URLs.

So there’s no linear equation like More pages = more traffic. Sometimes fewer but stronger pages can produce a much better result.

At Filmler.com, instead of getting every record indexed, we chose to index and add to the sitemap only the person pages with enough content. We used the same approach in other sections of the site.

Instead of telling Google “Index whatever we have,” we tried to say “These are our truly valuable pages.”

3. More indexed pages is not always better

One site gets 1 million URLs indexed. Its competitor gets 200,000 URLs indexed. From this we can’t say the first site is stronger in SEO terms.

Maybe 800,000 of the first site’s pages don’t have enough value. Google:

Crawls similar pages again and again.
Reaches empty pages.
Sees unnecessary filter combinations.
Runs into very thin content.

The second site offers fewer but stronger pages.

On large projects, sometimes:

Reducing the number of indexed pages can be an SEO win.

4. Index bloat is much more dangerous on large sites

We talked about index bloat in Chapter 25. On large database projects, it becomes much more critical.

For example, on a car classifieds site, /cars/ is valuable. /cars/bmw/ can be valuable. /cars/bmw/3-series/ can be valuable.

But then increasingly specific combinations start to appear, like /cars/bmw/3-series/black/automatic/2019/100000-120000-km/.

For each combination, you need to ask these questions:

Is there search demand?
Are there enough listings?
Is it a lasting need?
Does it offer the user different value?
Does it overlap with the main category?

Just because the system can generate a URL doesn’t mean we have to index every URL.

On marketplaces and classifieds sites, users want to use filters. That’s completely normal.

For example, these filters are very useful for user experience:

Brand
Model
City
Price
Color
Size
Gender
Year
Mileage
Number of rooms

The SEO problem isn’t using filters. The problem is:

Every filter combination becoming a separate, crawlable and indexable URL.

Because as the number of filters grows, the number of combinations grows exponentially.

6. Which filter pages should be indexed?

There’s no single answer. I look at these questions:

Is there real search demand?
Are there enough results on the page?
Does it make sense for the user?
Can it work like a permanent category?
Can we add unique value?
Can we link to it internally?
Is there a chance it will stay empty most of the time?

For example, “apartments for rent in Istanbul” is a very meaningful landing page. “Apartments for rent in Kadıköy, Istanbul” is still meaningful. “3-bedroom apartments for rent in Kadıköy, Istanbul” may also have real search demand.

But we don’t have to index a page for “Kadıköy, Istanbul, 3-bedroom, third floor, south-facing, with combi boiler, building 15-20 years old” just because we can technically create the URL.

7. Opening a separate page for every color or feature may not make sense

We see this a lot in e-commerce too. For example, a fashion site may create separate pages like these:

red prom dress
black prom dress
white prom dress

But this doesn’t mean We must open a separate SEO page for every color.

It’s better to decide based on this data:

Is there search volume?
Is the user actually searching for this combination?
Do we have enough products?
Will the page be permanent?
Is there enough product variety?
Does it overlap with the main category?

For example, if “red prom dress” gets real searches and we have enough products, a separate page can make sense. But if “mint green prom dress” is barely searched and we only have one product, a separate page may be unnecessary.

Sometimes search volume decides the strategy. Sometimes the number of products we have. Sometimes both together.

What matters on large sites:

Not that the system can generate a URL, but that the URL is actually worth being an SEO page.

8. Filters are the user’s right, indexing is not Google’s right

We can let users apply as many filters as they want. But:

We don’t have to show Google every filter result we show the user.

These two are different. A filter URL:

Can be noindex.
Can have its canonical point to another page.
Can have its crawling restricted.
Some filters can be turned into controlled SEO landing pages.

The technical solution depends on the site’s architecture. What matters is that the decision is made deliberately.

9. Generating pages programmatically is not a bad thing

Programmatic SEO is sometimes used as a synonym for bad content. I think that’s wrong. Generating thousands of pages from a template is not a problem on its own.

For example, thousands of location pages like “Istanbul weather,” “Ankara weather” and “Antalya weather” can be generated automatically.

If each page offers these, programmatic generation can make perfect sense:

Real data
Accurate information
A user need
Enough content

The problem starts here:

Generating millions of pages just because we have the data, without thinking about any user need.

10. A database page and a content page are not the same thing

Having a record in a system doesn’t mean the page has enough content.

For example, an actor page might only have:

Name
Photo
Date of birth
A few movies they appeared in

Technically the page exists. But is it valuable enough for the user?

At Filmler.com, for our “Who is…?” biography pages, we don’t want to just repeat the filmography. The filmography is already in the system. On top of that, we want to add genuinely new value like:

Career
Personal life
Interesting facts
Notable productions
Frequently asked questions

Printing database information into HTML and creating a useful page are not the same thing.

11. Empty category pages can be a big problem

This is very common on marketplaces. For example, an “Antalya / Electric Cars / 2025” page has been created. But there are no listings.

Google can still reach the URL. Thousands of different combinations produce “No results found.” pages. Not all of them need to be indexed.

Especially if the data changes constantly, it can help to define:

A minimum number of results
Indexing criteria
Sitemap criteria

12. Setting a minimum content or results threshold can work

For example, you can set up a system like this:

0 results → don’t index
1 result → don’t index
Enough results → can be indexed

There’s no universal number here like “There must be at least 20 results.” Depending on the project, it could be 5. It could be 10. It could be 50.

The real point:

Turning the decision into a rule.

On large sites, since it’s impossible for a person to review every URL one by one, you need to turn SEO decisions into an algorithm.

13. SEO rules should become part of the code

On a small site, the SEO specialist can say, “Let’s set this page to noindex.” The developer does it.

On a large site with millions of URLs, you can’t work that way. It needs to turn into:

“Pages that meet these conditions can be indexed.”

For example, a page can be indexed if:

It has at least X results
It has enough information
There is user demand
It is a certain category type
It receives internal links

From this point on, the SEO decision moves into the product and software system.

14. We don’t have to put every URL in the sitemap

A sitemap shouldn’t be a URL dump. I prefer to see the sitemap as a controlled list where we show Google our important URLs.

On large projects, you can split them like this:

Product sitemap
Category sitemap
Listing sitemap
Profile sitemap
Content sitemap

This structure also makes it easier to diagnose problems. For example, we can separately investigate “Why is the indexing rate of listing pages low?”

15. A sitemap can also be a quality filter

Like we did at Filmler.com. If a person page doesn’t meet enough criteria, it doesn’t go into the sitemap. Once it has enough content, it can be added to the system automatically.

That way the sitemap becomes “What we want indexed” rather than “Everything in the database.”

I think this is a very important distinction on large sites.

16. On news sites, when a page gets indexed is also strategy

On news sites, some pages bring serious traffic only during certain periods. One of the clearest examples is elections.

As an election approaches, almost everyone starts preparing:

Province results
District results
Candidate pages
Party pages
Vote shares
Live results pages

The important thing here isn’t just creating the pages.

When you get them indexed can also be part of the strategy.

Because if you open your entire page structure months in advance, competitors can see:

Which pages you’ve prepared
Your URL structure
Which provinces and districts you’re focusing on
Which queries you’re targeting

In a sense, you’ve shared your strategy too.

That’s why on some projects this approach may be better:

Get some pages indexed early
Keep some ready
Hold others back until a point when it will be hard for competitors to take positions

Especially with seasonal traffic, it’s not just technical preparation: the timing of publishing and indexing also becomes an SEO decision.

This is another version of the preparation and timing logic we covered in news SEO in Chapter 36.

17. When does crawl budget really start to matter?

For a small site, “I have a crawl budget problem” is usually not a priority. But on a marketplace that can generate millions of URLs, the topic can become truly meaningful. I covered crawl budget in Chapter 23.

If Googlebot spends its time on these, we may want to direct it more efficiently to important pages:

UTM URLs
Endless filters
Empty pages
Parameters
Duplicate URLs

The goal here is not to think of a fixed number like “Google only crawls X pages a day.”

It’s to reduce how much time Googlebot spends on unnecessary URLs.

18. Internal link architecture is very important on sites with millions of pages

A new listing was added to the site. A URL was created. So how will Google find that URL? Is the sitemap alone enough?

I think important pages also need to have a place within the site architecture. For example, a structure like Homepage → Main category → Subcategory → City → Listing gives Google and users a logical path.

Generating millions of pages that just sit in the database and get no links from anywhere is not a good strategy.

19. Orphan pages can quietly multiply on large sites

A page is in the sitemap, Google knows about it, but it gets no internal links from anywhere on the site. In large databases this happens very easily.

In particular, these can end up orphaned:

Old listings
Old products
Profile pages
Programmatic pages

This structure should be checked separately with crawl tools.

20. Pagination still matters

A category has 50,000 products. We can’t put them all on one page. We need pagination. For example, ?page=2, ?page=3.

What matters here is that Googlebot can reach products deeper down. A setup that only loads products with JavaScript when a “Load more” button is clicked, without offering crawlable links, can cause problems.

Infinite scroll can be used for users. But it helps to have a crawlable pagination system behind it.

21. Infinite scroll looks like a design decision, but it can affect SEO

New listings appear as the user scrolls down. Nice experience. But Googlebot doesn’t have to behave like a human.

That’s why you should check whether content loaded later with JavaScript has its own crawlable URL or link structure.

Same principle again:

User experience and search engine accessibility should be thought about together.

22. Should internal search pages be indexed?

On marketplaces, users search within the site. For example, ?q=iphone. Thousands of different user searches can be generated. Getting all of them indexed is usually not healthy.

Because even bad actors can create indexable URLs on your site by generating:

Spam queries
Brand names
Inappropriate words

But some queries with real search demand can be turned into controlled category or landing pages.

So it’s possible to create SEO pages from user searches. But it shouldn’t be automatic.

23. Duplicate content may be unavoidable on a marketplace

The same product is sold by 10 different sellers. Every seller uses the manufacturer’s same description. You end up with 10 pages with the same text.

It’s not right to think Google applies an automatic “duplicate content penalty” for ordinary duplicate content. But from our side there’s another question:

Why should the user choose one of these pages?

The value a marketplace can add might be:

Price
Stock
Seller rating
Delivery
Reviews
Q&A
Comparison
Product specifications

24. User-generated content can be a big advantage

On classifieds and marketplace sites, content isn’t produced only by editors. Users produce:

Listing descriptions
Reviews
Questions
Answers
Ratings

This can be very powerful. But it needs quality control. Because a user might write a title like “URGENT SALEEE!!!” Or add nothing to the description except a phone number.

The system can guide users toward better content with:

Required fields
A minimum description
Structured attributes
Moderation

25. Structured data (schema) is very valuable on large projects

Depending on the marketplace or listing type, different schema types can be used:

Product
Offer
Review
AggregateRating
JobPosting
Event
BreadcrumbList

But if there’s schema on millions of pages, an error can also spread to millions of pages. On a small site, a template error affects 20 pages. On a large site, 2 million.

That’s why template changes need to be tested much more carefully.

26. There’s no such thing as a small error on a large site

A developer changes the canonical in a template. One line of code. But that code affects 5 million URLs.

Another developer accidentally adds noindex to category pages. Hundreds of thousands of URLs are affected overnight.

That’s why on large sites you need to measure the size of a change not by “How many lines of code changed?” but by “How many URLs were affected?”

27. Pre-deploy SEO testing matters much more here

On large sites, the SEO team shouldn’t find out after development is done. For example:

The URL changes.
The filter system changes.
Pagination changes.
The canonical changes.
A new category is opened.
How old listings behave changes.

SEO should be part of the process before development even starts.

The checklist and standard operating procedure (SOP) I described in Chapter 34 come directly into play here.

28. What happens to old listings?

This is one of the important decisions on a classifieds site. The house sold. The car sold. The job posting closed. So what happens to the URL?

There’s no single answer. In some cases, the page can stay up for a while as “This listing is no longer active.” And the user can be shown:

Similar listings
Listings in the same area
The same make / model

In some cases the URL can be removed. In some cases it can be redirected to a truly equivalent page.

But sending every closed listing to the homepage with a 301 is not a good solution.

29. The same logic applies to old products

We talked about this in e-commerce SEO in Chapter 35.

For example, the old “AyPhone 8” model is no longer sold. The new “AyPhone 9” has arrived.

On some projects, redirecting the old product to the new one can make sense. On others, keeping the old product page up as “This product is no longer sold, the new model is here” can be more useful.

On marketplaces, this decision has to be systematized based on the number of products and user demand. You can’t do it manually one by one.

30. An out-of-stock product and a discontinued product are not the same thing

A product may be out of stock today. It will come back tomorrow. In that case, deleting the page or setting it to noindex is usually unnecessary.

The user can be offered these options:

Out of stock
Notify me when available
See similar products

But if the product has been fully discontinued, a different decision may be needed.

On large sites, the product life cycle should be part of the SEO strategy.

31. Getting new listings discovered can be very important

In areas like real estate or cars, new listings matter. A listing went live today. Google discovered it 10 days later. By then, the listing may even have sold.

That’s why these become important:

Sitemap updates
Category internal links
Homepage / new listings sections
Crawl access

Something similar to the fast discovery logic we covered for news sites applies here too.

32. A marketplace’s own sorting algorithm can affect SEO

Which products are at the top of the category page? How does the system work?

Newest
Most popular
Sponsored
Cheapest
Best-selling

If Google sees a completely different product order every time it crawls, the page structure can keep changing. Or if important products never make it to the first pages, they may not get internal link strength.

The on-site sorting system isn’t just the product team’s concern. It should be considered from an SEO perspective too.

A marketplace needs to make money. Sponsored listings are natural.

But if 25 of the first 30 results are sponsored and the same listings keep repeating, the user experience can suffer. If SEO brings traffic but users can’t find what they’re looking for, the whole system takes a hit.

This needs a balance between SEO and the business model.

34. A category page doesn’t have to be just a list

For example, an “apartments for rent in Istanbul” page might only have a list of listings. But if it’s useful for the user, it can also offer real data like:

Regional price information
Average price per square meter
Number of listings
Popular districts
Current trends

This is one of the big advantages of large database sites.

You can produce content from your own data that others can’t write.

35. First-party data is a big advantage

A marketplace can have very powerful data. For example:

The most searched car model
Rent changes by city
The average used price
The fastest-selling products
The most searched positions in job listings

From this you can produce:

Reports
News
Research
Charts
Content

This isn’t only valuable for users. It’s also strong for backlinks and digital PR.

If you have a large database, SEO content shouldn’t just be rewriting information that already exists on the internet.

Your own data should turn into content too.

36. User demand can create new categories

Internal site searches are very valuable data. For example, users keep searching for “electric SUV.” But there’s no such category on the site.

This data might be telling us, “Maybe we should create an electric SUV landing page.”

So on-site search data can be used for:

Product development
Category architecture
SEO

37. Search volume shouldn’t be the only decision criterion

A filter combination may show no search volume in SEO tools. But 20,000 people a month may be using that same filter on the site.

In that case we have data that’s much stronger than tools outside Google:

Real user behavior.

Especially on large marketplaces, your own user data can sometimes be more valuable than a keyword research tool.

38. On very large projects, log analysis delivers real value

Screaming Frog can show us what’s on the site. Search Console shows some of Google’s behavior. But server logs can answer the question Where does Googlebot actually go?

For example, if most of Googlebot’s crawling goes to these, we can see it in the logs:

Parameter URLs
Old filters
Empty pages
Worthless combinations

On sites with millions of URLs, log file analysis becomes much more meaningful. I also touched on log analysis in Chapter 24.

39. You need to split Search Console data by URL type

Total site performance: “10 million impressions.” Nice. But which section?

Categories
Products
Listings
City pages
Brand pages
Blog
Profile pages

Analyzing each URL type separately is much more useful. One template may be rising while another is falling. The total chart can hide that.

40. Judging the index rate against the total number of URLs can be misleading

For example, there are 500,000 product URLs. 400,000 are indexed. At first glance we say, “We have an 80% index rate.”

But that alone is neither good nor bad. Maybe all 100,000 unindexed pages are empty and we don’t want them indexed anyway.

The better question:

“How many of the URLs we want indexed are actually indexed?”

This distinction is very important on large sites.

41. You need to turn quality criteria into data

Let’s go back to the Filmler.com example. We can set criteria for whether a person is worth indexing. For example:

Is there a photo?
Is there a biography?
Are there enough production links?
Is there additional information?
Is there search demand?

A page that passes a certain quality level:

Goes into the sitemap.
Becomes indexable.
Is included in the internal linking system.

On large sites, an important part of SEO expertise is:

Turning SEO decisions into scalable rules.

42. On large sites, SEO is a team effort

An SEO specialist can’t do marketplace SEO alone. Teams you may need:

Software
Product
UX
Data
Content
Analytics
Marketing
Operations

For example, indexing filters may look like an SEO topic. But implementing it can be a shared decision of these teams:

Backend
Frontend
Product
SEO

That’s why on large projects, communication skills matter as much as technical knowledge in SEO.

43. Checklists and automation become mandatory here

If a site has 5 million URLs, you can’t check it manually every morning.

It’s very valuable for systems to raise alerts when:

The sitemap throws errors
The number of indexable pages suddenly jumps
The canonical changes
noindex spreads
The number of 404s rises
Server response times degrade

On a small site, a checklist is a convenience. On a large site:

It’s a requirement for the operation to work at all.

44. The summary of large database SEO is really “choosing”

I think this is the summary of the whole topic.

We have 450,000 person records. We don’t have to index them all.

There are 5 million filter combinations. We don’t have to make them all landing pages.

We can generate 10 million URLs. We don’t have to show those 10 million URLs to Google.

SEO sometimes isn’t about producing more content.

It’s about choosing the right pages.

And in some industries, it’s not only which page we choose:

When we get it indexed is also part of the strategy.

In short

The more SEO you do on marketplaces, classifieds and large database sites, the more important this question becomes: not “What else can we show Google?” but “What should we actually show Google?”

On small sites, we work hard to create pages. On large sites, we work hard to control page creation.

Having about 450,000 cast and crew records at Filmler.com didn’t mean we had to get all 450,000 pages indexed.

In the same way, a fashion site having 30 colors doesn’t mean it should open a separate category for each of the 30 colors.

A news site being able to prepare thousands of pages for an election doesn’t mean it should get all of them indexed months in advance either.

One of the most dangerous ideas on large sites is:

“The more pages, the more traffic.”

Sometimes it can be true. But sometimes it’s the exact opposite.

That’s why SEO on large sites is partly the job of asking these two questions:

“Should this page really exist?”

and

“If so, when should I show it to Google?”

I think an important part of large-scale SEO starts exactly here.

Previous: Chapter 39: How to Do SEO on WordPress Sites · Contents · Next: Chapter 41: How to Manage SEO Work

This chapter was first published in Turkish on X (October 20, 2026).

Chapter 40: SEO for Marketplaces, Classifieds and Large Database Sites