How to Find Underperforming Pages in Search Console

Underperforming pages show one of four patterns in Search Console: healthy impressions with weak click-through rate at a decent position, an average position that improved while clicks stayed flat, a query list the page was never written to answer, or impressions on an intent the page cannot satisfy. Export the Pages tab, band the rows by position in a spreadsheet, then open each suspect page's own query list. Search Console can point at all four patterns. It can prove none of them, because every metric it holds is measured on the results page and stops at the moment of the click.

Most people open Performance, glance at the four big numbers, notice the line is up or down, and close the tab. That is reporting. Diagnosis asks a different question: which specific pages are being handed traffic they fail to convert into clicks, or clicks they fail to satisfy? That question needs the table rather than the chart, and filters rather than totals.

The model that makes the report useful is a funnel with three visible stages and one invisible one.

Three of those four rows live inside Search Console. The fourth does not, and the single most common mistake in this kind of audit is reading a Search Console number as if it covered the fourth row. We wrote up exactly where each tool's vision ends in click signal measurement limits, and it is worth knowing the boundary before you start assigning blame to pages.

Every underperforming page in a normal property falls into one of these. Learn to recognize the shape and the diagnosis is half done.

The first two are click problems. The last two are content problems that happen to look like click problems, which is why sorting by CTR alone sends you off in the wrong direction so often.

This is the classic case and the one most audits get wrong, because raw CTR is meaningless without a position to compare it against. A 2 percent CTR at position 3 is a problem. The same 2 percent at position 14 is unremarkable.

The path. Search Console, then Performance, then Search results. Set Search type to Web, because image and video results have completely different click behavior and will pollute the average. Set the date range to the last 3 months for a stable read, or the last 28 days if the site changes fast.

The filters.

• Add a filter: Query, doesn't contain, your brand name. Branded queries carry very high CTR and will hide every non-branded weakness on the same page. If your brand has variants and misspellings, use Custom (regex) with a pattern such as sparkcliks|spark cliks|sparkclicks and set it to "Doesn't match".
• Leave Country and Device unfiltered for the first pass, then repeat on Mobile alone. Mobile result pages have more above-the-fold competition, and the gap between desktop and mobile CTR on the same page is itself a finding.

The step almost every guide gets wrong. There is no position filter in the Search Console interface. The filter menu offers Search type, Date, Query, Page, Country, Device and Search appearance, and nothing else. Clicking the Position column header sorts the table, but sorting is not banding, so any instruction to "filter to positions 5 through 15" describes a control that does not exist. Position bands are a spreadsheet step after the export, or an API step. Never a Search Console step.

So export. Open the Pages tab, click Export, and take it into Sheets or Excel. Then:

1. Drop every row below a minimum impression floor. Something like 250 impressions in a 3 month window is a reasonable starting floor for a small site. Below that, one lucky week distorts the CTR beyond reading.
2. Add a Band column with a formula that buckets Position into 1.0 to 3.0, 3.1 to 5.0, 5.1 to 8.0, 8.1 to 10.0 and 10.1 to 20.0.
3. Compute the median CTR of each band from your own rows.
4. Add a CTR index column: the page's CTR divided by the median CTR of its own band. Anything at 0.6 or below is a candidate.

Here is what the finished worksheet looks like. These figures are illustrative and exist to show the shape of the output, not to serve as benchmarks. Your own bands will look nothing like them, which is the entire reason for computing them from your own data.

Two candidates fall out immediately, and they need different fixes. The guide at position 3.4 is probably losing the click to its listing text or to a feature sitting above it. The pricing page at 2.2 with an index of 0.39 is stranger, and that combination almost always means the query set reaching it is not actually a pricing query set. It is a Recipe 3 problem wearing a Recipe 1 costume.

For the mechanics of reading the CTR metric itself, including the anonymized query issue that makes your export disagree with the chart, see how to measure organic CTR in Search Console. For turning band medians into a target you can hold a page to, see how to set a realistic organic CTR benchmark.

This pattern exposes average position as a summary statistic rather than a fact, which makes it the most useful finding to bring to a review meeting.

The path. Performance, then Search results. Click the date control, choose Compare, and pick "Compare last 28 days to previous period". For a seasonal site, compare to the same period last year instead, or you will read Christmas as a content win.

Switch to the Pages tab and export. The comparison export gives you paired columns for clicks, impressions, CTR and position across both windows. Add two derived columns, position delta and clicks delta, then keep only rows where position improved by at least 1.0 and clicks did not rise.

Now read the impressions column, because it decides which of four very different stories you are looking at.

That first row is the finding worth having. Average position is calculated over the impressions your site actually received, so when a batch of position 40 queries drops out of the set, your average improves while your click reality gets worse. A dashboard reporting position as a headline number shows that as a green arrow. It is a red one.

To read the per-query story, filter to the single page (Page, URL is exactly, paste the URL with its trailing slash), keep the comparison window, and switch to the Queries tab. You will see which queries moved and which of them ever had volume worth moving.

Search engines retrieve pages for queries their authors never considered. Sometimes that is free traffic. Often it is a page collecting impressions on demand it cannot serve, which drags its CTR down and, for the people who do click, produces a visit that ends back on the results page.

The path. Filter to one page: Page, URL is exactly, paste the full URL. Open the Queries tab and sort by impressions descending. Read the top twenty and ask one question about each: does the first screen of this page answer that?

The fast way to surface drift is the negative query filter. Stay filtered to the page, add Query, doesn't contain, and type the page's core noun. Whatever survives is demand arriving at a page that never names the thing being searched for.

Regex makes this systematic. The Custom (regex) filter uses RE2 syntax and offers a case-sensitivity toggle, so these are safe to paste in.

Run the commercial pattern with no page filter at all and look at the Pages tab. You will usually find at least one explainer article quietly collecting the pricing queries that a product page should be getting. That page is failing its visitors and taking the impression from a page that would have satisfied them.

The repair is almost never "write more". It is usually one of three moves: change the first screen so it answers the dominant query directly, split the page so each intent gets its own destination, or link prominently to the page that can finish the job. Our write-up on satisfying search intent above the fold covers what that first screen has to contain.

Recipe 3 finds queries that do not match the page. Recipe 4 is the sharper version: queries where the page could not satisfy the searcher even if the copy were perfect, because the job requires something the page structurally does not have.

Structural mismatch looks like this:

• A comparison query lands on a single-product page. There is nothing to compare against, so the searcher leaves to build the comparison somewhere else.
• A "how much" query lands on a page with no number anywhere on it. No amount of copywriting fixes an absent price.
• A "near me" query lands on a national page with no locations, hours or map.
• A troubleshooting query lands on a marketing page that describes benefits.
• A download or template query lands on an article about the concept.

How to find them at scale. Run each intent regex from the table above with no page filter, switch to the Pages tab, and export. You now have, for each intent class, the pages absorbing that demand. Compare that list against the pages you would have chosen. Every disagreement is a candidate.

Then apply the satisfiability test, which is a content question rather than a metrics question.

1. Can this page do the thing the query asks for, at all? If no, the fix is routing, not optimization.
2. Can a visitor tell within one screen that it can? If no, the fix is layout.
3. Does the page's own title promise the thing the query asked for? If no, the fix is the listing, and matching the title tag to the landing page headline is where to start.

Failing test one and calling it a CTR problem is how teams end up rewriting title tags for six months with nothing to show for it. The listing was fine. The destination was wrong.

A repeatable triage you can run monthly on a single property. The timings are realistic rather than optimistic.

Minutes 0 to 5. Set the frame. Performance, then Search results. Search type Web. Date range last 3 months. Add Query, doesn't contain, brand. Write the four totals down, because next month you will want the before picture.

Minutes 5 to 12. Build the band sheet. Pages tab, Export, into a spreadsheet. Drop rows under your impression floor. Add Band, band median CTR and CTR index columns. Sort ascending by CTR index. The top fifteen rows are your suspect list. Do not act on them yet.

Minutes 12 to 18. Run the comparison. Change the date control to Compare, last 28 days against the previous period. Export Pages again. Keep rows where position improved by 1.0 or more and clicks did not. Cross-reference against the suspect list. A page on both lists is your first job of the month.

Minutes 18 to 27. Open the top five suspects individually. For each: filter to the exact URL, open Queries, sort by impressions, read the top twenty. Classify what you see as click gap, query drift or intent mismatch using the pattern table above, and write the classification next to the URL. This part cannot be automated, and it is where the insight actually comes from.

Minutes 27 to 30. Write the ticket. One page, one classification, one change, one date. Everything else waits until you can read the result of that one.

What to record so next month is readable. The baseline window, the change window, the exact change made, and a control set of three to five comparable pages you deliberately do not touch. Without the control set, a site-wide fluctuation looks like your win. Give the change two full weeks of post-change data before you look, and expect to need four weeks on a small property.

Search Console data is real, but it is delayed, thresholded and aggregated in ways that make individual rows unreliable. Knowing which rows to ignore is most of the skill.

A practical floor: do not read a page's CTR on fewer than a couple of hundred impressions, and do not read a single query's CTR on fewer than a few dozen. Under those, you are measuring variance. A page with 40 impressions and no clicks is not an underperforming page, it is an unmeasured one.

One more caution. If you make several changes in the same week across the same section, you have destroyed your own ability to attribute the outcome. Stagger them.

Every metric in the Performance report is collected on the results page. The moment a visitor arrives on your site, Search Console goes blind. It does not know whether they read the page, scrolled, converted, or hit back within four seconds.

That matters, because the failures in this article are half pre-click and half post-click, and Search Console sees only the first half directly. A very low CTR at a strong position is evidence of a listing problem or a features problem. It is not evidence of a bad page, and it is certainly not evidence of what visitors did after arriving.

Terms like pogo sticking and dwell time are industry coinages, not published metrics. No search engine reports either one, and no tool can hand you a clean number for them. What you can do is build reasonable proxies, which is what pogo sticking walks through. Treat those proxies as directional, and never present one as a measured search engine metric in a report, because a technical reader will correctly stop believing the rest of the document.

Since SparkCliks sells search clicks, a straight answer belongs here rather than a soft one.

Clicks delivered by SparkCliks SERP Clicks show up in your own Search Console Performance report the same way any other search click does, on the keyword and the listing you configured. That is a statement about what the service does and what you can verify in your own reporting. It is not a claim about what a search engine will conclude from those clicks, and nobody honest can make that second claim, because search engines publicly deny using some behavior signals as direct ranking factors.

The consequence for this workflow is a measurement one. Any page receiving campaign clicks has stopped being a clean diagnostic subject: its CTR is now partly a function of your campaign, so it cannot sit in the control set of a before and after test, and its CTR index is not comparable to the rest of its band. Keep a list of campaign pages and exclude them from the band medians you compute in Recipe 1. Otherwise you raise your own benchmark and then judge every untouched page against it.

Run this against your own property. Anything you answer no to is a gap in your reading, not necessarily a problem with the site.

• [ ] Search type is set to Web, so image and video click behavior is not diluting the average.
• [ ] Brand queries are excluded with a "doesn't contain" filter or a negated regex.
• [ ] The date window ends at least three days before today.
• [ ] Position bands were computed in the spreadsheet after export, because the interface has no position filter.
• [ ] Every page under the impression floor was dropped before anything was ranked.
• [ ] CTR is judged as an index against its own band median, not as an absolute number.
• [ ] Any page with an improved position and flat clicks was checked against its impressions delta first.
• [ ] Each suspect page had its own query list opened and read before a fix was chosen.
• [ ] Each fix was classified as listing, layout or routing before anyone wrote a word of copy.
• [ ] A control set of untouched comparable pages exists and is written down.
• [ ] Pages receiving bought clicks are excluded from the band medians and from the control set.
• [ ] No conclusion in the write-up claims to know what a visitor did after the click.