A Search Console method to decide which SEO tasks to keep

September 28, 2026 · by Plori Engineering

A small site collects SEO tasks faster than it can measure them. Keyword tools suggest low-difficulty terms, audits suggest outreach, and every page looks like it could rank with one more rewrite. We had 21 open SEO tasks when we stopped to check which ones had evidence behind them.

The method puts Google Search Console at the center. It joins Search Console to four other sources: the search results page, the deploy history, Google's URL Inspection, and the first-touch attribution in our own database. Each source answers one question that Search Console cannot answer alone. Below are the eight steps in order, the error each step prevents, and what it showed on our site. Of our 21 tasks, five had already shipped, we closed ten, and we kept five, four of them with a smaller scope.

Which sources answer which question?

Source	Question it answers	What it cannot tell you
Search Console, property totals	How much search traffic does the site get?	Which queries or pages produced it
Search Console, query and page rows	Which disclosed queries show which pages, at which position?	Anything about rare queries, which Google omits
The search results page for a query	What do searchers want when they type this query?	How many people search it
Deploy history	When did a change go live?	When Google saw it
URL Inspection	When did Google last crawl the page, and which URL is canonical?	When Google started to use the new version in results
First-touch attribution in the product database	Where did new users arrive, and what did they do next?	Which search query brought them

Third-party keyword tools are not in the table. We use their volume and difficulty estimates only to choose which terms to check. They do not decide whether a task stays.

Step 1: How do you get totals you can trust?

Ask Search Console for the property total with no dimension and no filter. Use final data only. Do not add up page rows or query rows to get a total.

The reason is how Google counts. In property totals, two results from the same site for one query count as one impression. In page totals, each page counts. Also, for privacy, Google omits rare queries from query rows, but it keeps them in property totals (Search Console performance data). So the three views of the same days do not match, and each one is correct for its own question.

Our example, for one 28-day window:

The property total and the page view had the same clicks.
The page view had about twice as many impressions as the property total (1.98 times).
The United States property total had clicks. With a filter for our main host, the United States showed 0 clicks and only 44% of its impressions.

With the filtered view, we would conclude that no one in the United States clicked. That conclusion is wrong. A filtered result is a subset with its own counting rules, not a total.

Step 2: How do you split queries without guessing?

Put every disclosed query row in one of three groups, then calculate a fourth:

Brand: your product name and misspellings that you checked by hand.
Diagnostic: site: searches and other search operators. These are mostly your own team checking the index.
Other disclosed queries: the topics your pages target.
Undisclosed: the property total minus the sum of the three groups.

Check the diagnostic group before the brand group. Our brand pattern matched the domain inside site:plori.ai, so our own index checks counted as brand interest. On one page that we planned to optimize, about one impression in five (20%) came from site: searches.

Report the undisclosed group as unknown. Do not move it to brand or topic. In our latest window, the undisclosed group held 42% of all clicks. Those clicks can be brand or topic searches, and nothing in the data tells which. Our disclosed topic queries had 0 clicks. So the correct statement is "topic search traffic is unknown and at most 42% of clicks". That is neither zero nor evidence of growth.

Step 3: How do you check a keyword tool's claim?

For each task that cites a keyword estimate, find the target page and read its query rows in Search Console. Compare the claim with what Google recorded for that page.

Task premise	What the query rows showed
A term with 50 searches per month and difficulty 4. The page ranks at position 16.	Position 16 was a page average, and 20% of the page's impressions came from `site:` searches. The two commercial queries together had 3% of the page's impressions, at positions 64 and 83.
Two terms with 260 searches per month and difficulty 10 to 12	Each term had less than 3% of the page's impressions, at position 85.
An example page is a good place to test a new sign-up flow	The page had less than 0.2% of the site's page impressions in 28 days.

A difficulty score estimates how hard a term is for an average site. Your own rows show where your page ranks now. When the two disagree, the query rows win. A page's average position is also a poor guide. It mixes every query that showed the page, including diagnostic ones. In our case, one example page started to appear at positions 43 to 87, and it now has 26% of the site's page impressions. In the same period, the site's average position went from 15 to 30. A lower average after new low-ranked impressions arrive does not mean that existing rankings fell.

Step 4: How do you check search intent?

A query row tells you that people search a term. It does not tell you what they want. Search the term and read the first page of results. Ask one question: would a searcher who wants these results want our page?

Three examples from our tasks:

"ai agent hosting": every result was infrastructure to deploy an agent that you wrote yourself. The results included Microsoft's agent hosting guide, Mastra, Northflank, Google Cloud Run and Bluehost. Our product runs its own agent for the user, which is the opposite. We kept one short section that says so, and we stopped optimizing the page for the term.
Google Sheets webhooks: one of our example pages became the page with the most impressions on the site, with 0 clicks. The queries had the form "connect google sheets [service] webhook", and the results were integration pages from Zapier, Make, n8n and Svix. Searchers wanted an integration template. We closed the task that planned to expand the page.
"claude code alternative": the results were lists of coding tools. Our product is something Claude Code can call, not a replacement for it. We did not write the page.

This step takes a few minutes per term. A term with real volume and low difficulty is still a poor target if the results show a different product category.

Step 5: How do you date a change?

Search data before a change is live cannot show the effect of that change. Record two dates for every changed page:

Live date: the completion time of the first production deploy that included the change and deployed the web app successfully. The merge date is not enough.
Crawl date: the last crawl time from URL Inspection, read after the live date. It shows that Google fetched the new version. It does not show when Google started to use that version in results.

In our case, a set of page changes merged on September 9. The next eight production deploys skipped the web app, so the pages went live on September 12 at 23:59 UTC. A measurement from the merge date would include three days in which Google could not see the new text.

Before you measure, use URL Inspection to check two more conditions: Google indexed the page, and Google chose the page's own URL as canonical. We inspected ten pages. Google crawled every changed page after its live date, except one documentation page, which Google last crawled two months earlier. We measure a page only after one full 28-day window passes after its crawl date.

Step 6: What happens after the click?

Search Console stops at the click. To see what visitors did next, compare by date and landing page, never person by person. Use the first-touch source and landing page that your product records at signup, and count only real accounts. Exclude test and benchmark accounts.

For each signup source, we count five numbers:

New users.
Users who ran a task.
Users with a completed run.
Users whose first run was at least seven days ago.
Users who ran a task again on days 1 to 7.

A completed run shows that the task finished. It does not show that the result was useful, so check a sample of outputs before you use that word.

Two results from this step changed our plan:

Content pages did not bring signups yet. About 2% of new users in the window first arrived on a blog post, example page or benchmark page. A new sign-up flow for example pages would change the path of almost nobody, so we closed that task.
A free directory listing brought about a quarter of new users (24%). Three quarters of those users ran a task, compared with 57% of all new users. Earlier, we stopped directory submissions because their links do little for rankings. That rule is still correct for search. As a source of users, the one listing brought more signups than our blog, example and benchmark pages together.

Keep the table coarse. With a few dozen new users, a split by landing page, entry path and outcome puts zero or one person in most cells. In your own reports, use counts, not percentages, until each cell has enough people to mean something. The percentages in this post come from a sample of a few dozen users.

Step 7: What test does each task have to pass?

After steps 1 to 6, give each task one of four results:

Already shipped: the work is live, and only the task status is open. Close it, and record the live date and crawl date.
Keep: the task can move a number that you can measure at your current size. Examples are topic search clicks, task starts, completed runs and return visits.
Keep with a smaller scope: part of the task fixes a verified error at low cost. Keep that part and drop the rest.
Close: the task fails both tests, or a primary source contradicts its plan.

Two closures in our list came from primary sources, not from traffic data. One task planned to ask authors of comparison articles to list us. Vendors wrote all three target articles, and two of them ranked their own product first. For the chance of a reply, we used Backlinko's study of 12 million outreach emails, in which 8.5% got any reply (Backlinko). At that rate, ten pitches produce less than one expected reply, and a reply is not a link. The other task planned to submit generated directory pages through Google's Indexing API. Google allows that API only for job posting and livestream pages (Indexing API quickstart).

For us, the result was 5 tasks already shipped, 10 closed, and 5 kept. Four of the five kept tasks have a smaller scope than before.

Step 8: How often should you review?

Match the review interval to the volume. We planned a weekly review, and the weekly export ran every Monday. With a few dozen clicks in 28 days, a weekly change of a few clicks is mostly noise. For three weeks, nobody read the export. We now review every 28 days with fixed windows: the latest 28 days of final data, the 28 days before, and 90 days for context.

Each review answers the same five questions:

Did the data export run, and what is its last date?
What are the property totals, for all countries and for the main market?
How do the four query groups compare with the previous window?
For each changed page, what are the live date, the crawl date and the post-change numbers?
What happened after the click, by signup source?

A review creates new work only for a finding that someone can act on. If nothing changed, the result is "no change".

What can this method not tell you?

Cause. Our brand clicks grew at the same time as signups from a directory and from ChatGPT. The data shows that the two happened together. It does not show that one caused the other.
What the undisclosed queries were. A large undisclosed group can hide real topic traffic. The method keeps that group visible, but it cannot open it.
Early results. A page that went live last week has a handful of impressions. The method tells you to wait for a full window after the crawl date. It does not make the wait shorter.
Whether the output helped the user. Run counts show activity. Only a sample of real outputs shows value.

One page in our check shows why the wait matters. An article on OpenAI prompt caching had 3.3 times as many impressions after four overlapping 28-day windows as at the start. Over the same windows, its average position moved from 15.5 to 11.0, and it is now at 8.7. It still has 0 clicks. The only change we plan is one link from the article to the product. The next 28-day review after that link goes live will show whether it changes anything.