Search Console Regex for Pages: Filter URLs and Site Sections

So far most of our work has been on queries: we were asking "what do people search for?". But Search Console has another very important dimension: pages. And here the question changes. Instead of "what do people search for?", we can ask "which part of the site is actually showing up in Google?" The articles, the products, the services, the categories, the English or Spanish version, PDF files, pagination pages, URLs with parameters, pages from a particular year.

Search Console lets you use Custom (regex) on both queries and pages, and either show what matches or leave it out. And the default is a partial match, unless you use ^ or $ to control the start and end of the text.

Let's start from a real SEO question

Say you have the site https://example.com/, and your question is: how do the articles perform compared with the rest of the site? There's a clear pattern: every article page starts with https://example.com/blog/. We use the ^ we know from query filtering, but on the site's structure, and we use \. so the dot in example.com is a real dot:

Now you can see the clicks, impressions, CTR and average position of the articles section. Why did we use ^? Because /blog/ on its own means "any URL with /blog/ inside it", but ^https://example.com/blog/ means "URLs that start with exactly this path", which describes the site's structure more clearly.

Say you don't want the articles inside the blog; you want the section page itself. With ^ alone, /blog/seo/ and /blog/python/ show up too. We learned the fix: add $:

Two sections together, and languages

If the informational content lives under /blog/ and /guides/, and you want to analyze both as one group, we use the () and | we've known since lesson 1:

Exactly the same idea if the site has two versions, English and Spanish: ^https://example.com/es/, or ^https://example.com/(en|es)/ if you want both out of several subdirectories. But you can't stop at "the Spanish version gets more impressions". Look at the number of pages in each language, the countries, the queries, the CTR and the time period: the Spanish version might have more clicks, but ten times as many pages.

The same split works for page types in e-commerce: /product/, /category/ and /brand/, each its own segment, so you can ask: who takes most of the non-brand visibility? Product pages? Category pages? The blog?

PDF files

Want to know whether PDF files get visibility in Google? We want URLs that end in .pdf. The dot has a special meaning, so we escape it: \.pdf$: a real dot, then pdf, then the end of the URL.

Pagination and parameters

Pages like /blog/page/2/ and /blog/page/15/: the shape is clear, /page/ plus a number. We know a number is \d+, so we can write /page/\d+/. And if some URLs have a trailing slash and some don't, we add the ? we know: /page/\d+/?$.

Not so you can say "I have 17 pagination pages": we're not crawling at all. But if pages like these show up in the performance data, you can ask: do the pagination URLs themselves get impressions? Do they compete with a category or an article?

Want to know which URLs have a query string? What they share is ?, but we learned that ? has a special meaning in regex, so we escape it: \?.

Years, and numeric IDs

You have a news site or older content, and you want three years: /(2024|2025|2026)/. Or 2026 only: /2026/. Then you ask: does the older content from 2024 still get impressions?

Say the system generates /product/12345/ and /product/876/. The shape is /product/ plus a number: /product/\d+/. And if we want the URL to end after the number: /product/\d+/?$.

HTTP versus HTTPS, and www

We learned that ? means the previous part is optional. If we write ^https?://, the ? applies to the s, so it matches both http:// and https://. But if your goal is to find the old HTTP pages only, it's better to be explicit: ^http://.

If you have https://www.example.com/ and https://example.com/, a pattern can accept both: ^https://(www\.)?example\.com/. The part (www\.)? means "www. is there or isn't".

Letter case in URLs

Search Console regex is case-insensitive by default. So [A-Z] on its own isn't enough if you really want to tell uppercase from lowercase. Here we put (?-i) at the start of the pattern: it means "make the matching case-sensitive from here on".

Let's take the pattern apart: (?-i) makes the matching case-sensitive, ^https://example\.com/ starts with the domain, .* is any number of characters, and [A-Z] means there has to be at least one capital letter. But don't turn Search Console into a crawler: if the regex finds no uppercase URLs, you only learned that no URLs like that showed up in the performance data matching the filter, not that there are no uppercase URLs on the server.

Combining a page regex with other filters

This is where it really gets powerful. Search Console lets you filter on more than one dimension at the same time: Page = the blog regex, Country = United Kingdom, Device = Mobile. Then the question becomes "how did the blog articles perform on mobile in the UK over the last 3 months?", not "how is the site doing?"

And careful: don't look only at clicks. The blog having more clicks than the products doesn't mean it's better. Maybe the blog has 50,000 URLs and the products only 500, and maybe the two sections have completely different goals. Regex helps you segment, but the comparison has to make sense.

An optional advanced part: URL depth

Say you have /about/, /blog/, /blog/seo/ and /blog/seo/technical/, and you want to pick out the URLs with only one segment after the domain. Here we need a new character class: [^/]. When ^ comes first inside square brackets, it means "any character except", so [^/] means "any character except /", and with +, [^/]+ means "a whole piece with no slash in it".

That can help with URL depth analysis, but don't start using it for everything: URL depth is a signal, not a verdict on a page's quality on its own.

The practical test

You have an e-commerce site with this data, and you want the product pages whose slug is only a number:

Before you run any pattern like this, ask yourself: if the regex shows no results, does that mean the site has nothing of this kind? No. You only found no matching results within the performance data Search Console shows you.

A real test of understanding

Say you open Search Console for a new site and find /blog/, /product/, /category/, /services/ and /tag/. Don't immediately write five patterns. First ask: what do I want to know? If the problem is "does the site's traffic come from the content or from the commercial pages?", you might need the blog versus products + categories + services. If the problem is "are tag pages showing up in Google by accident?", focus on /tag/. Even in URL analysis, the rule is the same as in lesson 0: an SEO question → define the group of pages you need → understand the shape of the URLs → build the simplest regex → predict the result → review samples → analyze the metrics → make a decision.

Before the next lesson

So far we can use regex on two very big sides of Search Console: queries and pages. But the bigger the patterns get, the more a new danger shows up: you can write a regex that works, Search Console accepts it, it returns results, and the regex itself is still wrong for the question you're trying to answer. In the next lesson we focus on that: how to test and fix a regex instead of trusting it because it ran. False positives and false negatives, the limits of RE2, lookahead and lookbehind, and when to use several filters instead of one complex regex.