Chapter 25: How Can Google Understand Your Page Better?

A monitor comparing an organized page structure with a messy pile of pages

Last updated: November 1, 2026.

In Chapter 21 we touched on structured data from the angle of enriching Google results. In this chapter, we’ll look at the same topic from a somewhat more technical side.

Because just as we need to tell Google what a page is, we also need to tell it which URLs really matter.

On one side, with schema we say “This is a product,” “This is a company,” “This is an event,” “This is the product’s price.” On the other side, if we open thousands of unnecessary or weak URLs to Google’s index, we present the search engine with a much more complicated structure.

So this chapter has two main topics:

  • Structured data (schema)
  • Index bloat

I think what the two have in common is this:

What matters isn’t giving Google more information, it’s giving it cleaner and more consistent information.

1. What is structured data?

When Google crawls a page, it tries to understand the text, links, images and other elements in the HTML. Using structured data, we can define what certain information means in a way that machines can understand more easily.

For example, a product page might have:

  • Product name
  • Brand
  • Price
  • Stock status
  • Rating
  • Review count

When a person looks at the page, they can easily understand what these are. With schema, we can also tell Google “This 14,900 TL is the product’s price,” “This phrase is the product’s brand,” “This information shows the stock status.”

2. What is Schema.org?

Schema.org is a shared vocabulary used to describe things on the web and their properties. This vocabulary has a large number of types. For example:

  • Product
  • Article
  • Organization
  • LocalBusiness
  • Event
  • Recipe
  • BreadcrumbList
  • Movie
  • Person

But there’s an important distinction here:

Something being in Schema.org doesn’t mean Google supports a special search feature for that schema type.

Schema.org is a much broader vocabulary. Google uses a certain part of it for special displays in its own search results. So when implementing it, you need to ask not just “Does it exist in Schema.org?” but also “How does Google use it?”

3. Can a page have more than one schema?

It can. In fact, that’s usually what’s normal.

For example, a product page can have these at the same time:

  • Organization
  • BreadcrumbList
  • Product

A news or blog page, on the other hand, might use:

  • Organization
  • BreadcrumbList
  • Article

What matters is that these structures are actually related to the page and don’t contradict each other. Adding every schema type we come across to the page isn’t an optimization method.

4. What is JSON-LD?

Structured data can be implemented in different formats. One of the methods we come across most often is JSON-LD.

A very simplified product definition might look like this:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Espresso Machine"
}
</script>

I don’t think an SEO specialist needs to memorize this code. But they need to know:

  • What type of page is this?
  • What information should Google be told?
  • Which fields are required?
  • Does the code actually represent the content on the page?
  • Can Google read it?

The developer can handle the code side. The SEO specialist’s job is to describe correctly what needs to be done and to check the result.

5. Does schema raise our rankings?

Thinking of schema directly as “We added this, our rankings will go up” isn’t right. The main purpose of structured data is to give Google clearer information about the content and, where appropriate, to make the page eligible for certain search features.

For example, a product page using Product schema can, if it meets the requirements, become eligible to have information like price, stock or rating used in richer displays. But even technically correct schema doesn’t mean Google will show that display.

6. Don’t put information in schema that isn’t on the page

I think this is one of the most important rules on the schema side.

For example, you don’t show users any rating on the page, but you write 4.9 / 5 in the code. Or the product is out of stock, but you define it as InStock in the schema.

In this case, you’re giving Google different information from what you show the user. The purpose of schema isn’t to secretly give the search engine information that isn’t on the page.

It’s to describe the information you show the user more clearly.

7. How do we check schema?

Google’s Rich Results Test is one of the basic tools here.

While checking, we can look at:

  • Does Google see the structured data?
  • Are there critical errors?
  • Are recommended fields missing?
  • Is it eligible for the relevant rich result type?
  • Is the URL actually accessible to Google?

After that, we can also track structured data errors and the related reports in Search Console.

Here I don’t just look at the total number of errors. This question matters more:

How many pages does this error affect, and which pages are they from a business point of view?

An error on 10 very important product pages can be far more critical than a warning on 10,000 unimportant URLs. In technical SEO, the scope of the impact matters as much as the count.

Index Bloat

Now let’s get to the other side of the topic.

Let’s say a site has 10,000 truly valuable pages. But Google has discovered or indexed hundreds of thousands of URLs. Are all of these URLs really necessary?

This is where index bloat comes in.

8. What is index bloat?

Put simply, we can think of index bloat as a large buildup of URLs that don’t need to be in Google’s index or carry very little value.

For example, these can multiply out of control:

  • Filter URLs
  • Sorting URLs
  • Parameters
  • Internal search results
  • Empty tag pages
  • Duplicate archives
  • UTM parameters
  • Print versions
  • Very similar category pages
  • Thin pages that don’t offer users enough value

The issue here isn’t just “there are too many URLs.” The real question is:

Does it actually benefit the user for these URLs to be in Google?

9. Is “the more pages I have in Google, the better” true?

I think this is one of the most dangerous ideas.

A site having 100,000 indexed pages isn’t a success on its own. If the site has 5,000 truly strong pages and the other 95,000 URLs are weak, repetitive, incomplete, meaningless pages, that number shouldn’t make us happy.

I think the better question is:

Not How many URLs are in the index? but Which URLs are in the index?

10. We applied this deliberately at Filmler.com

We saw a very clear example of this at Filmler.com, a Turkish movie and TV site. The site has about 450,000 person records, including cast and crew information.

Technically, it was possible to create a separate URL for all 450,000 people, add them to the sitemap and open them to Google’s index. But we asked this question:

Do all 450,000 of these pages really offer users enough value?

The answer was no. Some person pages had content, a biography or enough information. Others had only basic data.

So instead of opening every page to Google, we decided to index and add to the sitemap only the pages where content had been added and that actually offered users something. We applied the same approach in other sections of the site too.

In the end, we got fewer pages indexed, but we raised the average quality of the pages we sent to Google. And it paid off.

Fewer indexed pages, more successful pages.

I think it’s hard to find an example that explains index bloat better than this. In SEO, the goal isn’t to send Google as many URLs as possible.

It’s to send Google the truly valuable URLs.

11. Should we shut down every page with little content?

No. In the Filmler.com example too, the decision wasn’t made only on word count. A page having little text doesn’t mean the page is worthless.

For example, if an actor page has the following, the page can be valuable to users even if the amount of text isn’t very high:

  • Filmography
  • The productions the actor appeared in
  • Images
  • Career information
  • Biography
  • Related people
  • Frequently asked questions

The real issue is whether the page has a job.

Content length and page value are not the same thing.

12. How does index bloat happen on e-commerce sites?

Filters are one of the best examples. Let’s think of a shoe category: /shoes

Then the filters come in:

?color=black
?color=white
?size=42
?brand=x
?sort=price

When these combine with each other, a large number of URLs like ?color=black&size=42&brand=x&sort=price can be created. Even a few filters can mathematically produce thousands of combinations.

Some of these pages can be valuable for SEO. For example, a combination people actually search for, like “black men’s sneakers,” can be treated as a separate landing page. But we can’t conclude that every combination should be in Google.

Not all filters are worthless, but not all filters are SEO pages either.

13. Internal search pages

Another classic example:

site.com/search?q=coffee
site.com/search?q=red
site.com/search?q=abc123

If an infinite number of URLs can be generated as users use the site’s search box, Google discovering them can create a huge pool of URLs. In most projects, we don’t want to use internal search results as landing pages for organic search.

The main question here is the same again:

Does this URL really offer independent value to a Google user?

14. Are tag pages always bad?

No. This topic comes up a lot in WordPress projects.

A site might have 500 posts and 3,000 tags. A tag page has a single post on it. Some have nothing. Some are almost identical to other category pages.

In this case, we may have created thousands of low-value pages. But a well-planned tag system is different.

For example, on a movie site, if a “Christopher Nolan” page properly brings together related films, articles, news and information, it can be meaningful for users.

So the issue isn’t the URL type.

It’s the purpose and value of the page.

15. Date, author and archive pages

Some CMSs automatically create:

  • Daily archives
  • Monthly archives
  • Yearly archives
  • Author archives
  • Tag archives
  • Category archives

For example, on a single-author corporate blog, the /author/hasan page can show almost the same content as the main blog page. Here we’re not saying “author pages are bad.”

If it’s a meaningful page with the author’s profile, expertise and all their content, it can be very useful. But not every page the CMS automatically creates needs to be in Google.

16. UTM parameters and tracking URLs

Let’s think of a URL like this: site.com/product

The same page can be used as site.com/product?utm_source=instagram in a social media campaign, site.com/product?utm_source=newsletter in an email and site.com/product?utm_source=google in an ad.

These are useful for measurement. But the content is the same. What matters here is that Google understands these URLs as variations of the same content cluster and gets the right canonical signals.

17. Does a canonical solve index bloat?

Sometimes it helps, but it doesn’t solve every problem on its own.

For example, on the /shoes?color=black page you can use:

<link rel="canonical" href="https://site.com/shoes">

You’re telling Google our preferred main URL is /shoes. But generating millions of unnecessary URLs and saying “There’s a canonical anyway” isn’t good technical architecture. Where possible, you also need to control the generation of unnecessary URLs.

A canonical isn’t a cleanup tool. It’s a signal that says which version we prefer among similar URLs.

18. When can noindex be used?

Some pages may be necessary for users, but you may not want them in Google results. Depending on the project, these can be handled with noindex, for example:

  • Account pages
  • Certain filter results
  • Some archive pages
  • Thin internal lists

Here, the topic I covered in Chapter 23 matters again. Google has to be able to crawl the page to see the noindex tag. So it’s wrong to block a page with robots.txt, add noindex at the same time and assume Google will see the tag.

19. Is robots.txt a solution for index bloat?

Not on its own. robots.txt controls crawling. Blocking a URL with robots.txt doesn’t mean “Remove this from the index.”

So saying “Let’s block all the filters with robots.txt” without defining the problem correctly can be risky.

First you need to answer these questions:

  • Should the URL be created at all?
  • Should it be crawled?
  • Should it be indexed?
  • Should the canonical point somewhere else?
  • Should it stay accessible to users?

The technical tool should be chosen after the problem has been defined.

20. When should a 301 be used?

If two URLs really serve the same purpose and the old URL won’t be used anymore, a 301 can make sense.

For example, if /old-category no longer exists and /new-category has replaced it, a permanent redirect can be used.

But 301-redirecting 50,000 low-quality filter URLs to the homepage isn’t a solution for index bloat. A redirect should only be used if there’s a meaningful target.

21. The sitemap can give us an idea about index bloat

We usually prefer the sitemap to contain the main URLs we want to see in Google. Say the sitemap has 12,000 URLs. But on the Search Console side, Google has discovered far more URLs.

This gap doesn’t mean “there’s a problem” on its own, but it can definitely be a signal worth investigating. We can ask:

Where are these extra URLs coming from?

  • Parameters?
  • Filters?
  • Old URLs?
  • HTTP / HTTPS variations?
  • www / non-www?
  • Archives?
  • UTM?
  • Duplicate pages?

Sometimes you can spot big technical problems with simple comparisons like this.

22. Why was the sitemap important in the Filmler.com example?

If we had added all 450,000 cast and crew pages to the sitemap, we would actually have been giving Google this message: “All of these are important to us.” But in reality, they didn’t all have the same value.

When we put only the person pages with developed content into the sitemap, we gave a different message:

“These are the pages we especially want to see in Google.”

I think this explains the logic of a sitemap nicely too. A sitemap doesn’t have to be a dump of all the site’s URLs. It’s more accurate to think of it as a tool that tells Google about the main, valuable URLs we want to highlight for SEO.

23. How should we read the Search Console Page indexing report?

I think looking at the report only as “How many pages are indexed?” is wrong. You need to look at these separately:

  • Indexed URLs
  • URLs that aren’t indexed
  • The canonical Google selected
  • Crawled – currently not indexed
  • Discovered – currently not indexed
  • Excluded by ‘noindex’ tag
  • 404
  • Redirects

Here, not every URL in the “Not indexed” list is an error. For example, a page we deliberately set to noindex not being in the index is exactly the behavior we want. An old URL we 301-redirected dropping out of the index isn’t a problem either.

In technical SEO, a report looking red doesn’t automatically mean there’s an error. First we look at this question:

Is the behavior we expected the same as the behavior that happened?

24. Why does index bloat matter more on large sites?

On a 500-URL site, 100 unnecessary URLs are usually manageable. But on e-commerce, classifieds, news or database-heavy projects with millions of URLs, the same ratio can create a massive pool of URLs.

For example, there are 100,000 products. Because of filters, 8 million URLs are created. The area Google has to discover, crawl, evaluate for canonicals and keep track of for updates becomes much larger.

That’s why index bloat is also connected to the crawl budget topic we talked about earlier.

25. Should we noindex every page we see as “thin content”?

No. This is another of the automatic reflexes that can be dangerous in SEO. A page having 100 words doesn’t make it worthless.

For example, if a product page has the following, the amount of text may be small but the page can be very valuable to users:

  • Product images
  • Technical specifications
  • Price
  • Stock
  • User reviews
  • Video
  • Documents

We come back to the same point again.

We look at the page’s job, not the word count.

26. What do I look at when doing an index bloat analysis?

In general, we can check:

  • How many URLs are in the sitemap?
  • How many URLs does Google know about?
  • How many are indexed?
  • Are there parameter URLs?
  • How many different combinations do filter URLs produce?
  • Can internal search pages be crawled?
  • What state are tag and archive pages in?
  • Are there leftover HTTP / HTTPS or www variations?
  • Are canonical signals consistent?
  • Are UTM URLs being indexed?
  • Do old site URLs still exist?
  • Are there empty or very low-value pages?
  • Are there unnecessary URLs in the sitemap?

We can examine these together with Search Console, Screaming Frog, server logs and, when needed, other crawler tools.

27. The SEO specialist’s job here isn’t “cutting URLs”

I think this distinction matters. The goal of index bloat work isn’t “The fewer URLs, the better.” The goal is:

Making sure Google comes across truly meaningful URLs.

If a filter page brings in serious traffic, removing it can be a mistake. If a tag page has become a strong topic hub, setting it to noindex can be a mistake. If an actor page has become strong in terms of content, filmography and biography, opening it to the index can be the right call, as we did at Filmler.com.

In technical SEO, we’re not trying to reduce numbers; we’re trying to improve quality and architecture.

28. Why are schema and index bloat in the same chapter?

At first glance they may seem different from each other. But I think both answer the same problem:

Can Google understand our site correctly?

With schema, we answer the question “What’s on this page?” With index bloat control, we answer the question “Which URLs really matter?”

On the first side, we’re cleaning up the meaning of the content. On the second, we’re cleaning up the URL structure.

To sum up

Sending Google more pages isn’t always better. Adding more schema isn’t always better either.

At Filmler.com, choosing only the pages that had content and offered users real value, instead of opening all of the roughly 450,000 cast and crew pages to the index, was a good example of this. We sent fewer pages. But we raised the quality of the pages we sent to Google. And the result came back as more successful pages.

I think this sentence sums up a big part of technical SEO:

Reducing as much as possible the things Google has to guess.

Which URL is important? Which URL is the main one? What does this page represent? Is this information the product’s price? Should this page be indexed? Does this page have another version?

If we answer these questions as clearly as possible, we end up with a site that’s more manageable both for Google and for us.

In technical SEO, the goal isn’t to show Google more things.

It’s to show the right thing, at the right URL, with the right signals.

Previous: Chapter 24: Why Is the Site Slow? · Contents · Next: Chapter 26: How to Do SEO for Multiple Countries

This chapter was first published in Turkish on X (September 29, 2026).