How to Count Ranking Keywords in Search Console With Codex

To count ranking keywords in Google Search Console with Codex, export final Search Analytics rows for one exact page, remove branded and irrelevant queries with a documented rule, deduplicate the remaining query strings, and count how many have reported positions in the Top 3, Top 10, and Top 20. Keep those nested counts beside clicks, impressions, and an impression-weighted average position.

That produces a useful keyword footprint. A lone average-position number does not. It can improve because weak queries disappeared, or worsen because a useful page began appearing for more relevant long-tail searches.

This workflow uses Aident Loadout to give Codex bounded access to the current Search Console Action. The result is a reproducible report for one canonical page, not a claim that Search Console exposes every query where the page appeared.

The Five Metrics to Keep Together

For one canonical URL and one complete date window, record:

The buckets are nested. Every Top 3 query also belongs in Top 10 and Top 20. Do not add the three bucket counts together.

Search Console defines position as the topmost position of a property in search results for an impression. When you aggregate rows yourself, weight position by impressions:

average position = sum(position * impressions) / sum(impressions)

A lower number is better, but only when interpreted with footprint size and qualified clicks.

What You Need

Prepare:

• a verified Search Console property;

• the exact canonical URL you want to measure;

• a connected Google account with read permission;

• a written brand rule; and

• the public Aident CLI installed and authenticated.

Give Codex the canonical setup instruction:

Follow https://aident.ai/SETUP.md

Then confirm the account and Vault state:

aident account auth status
aident vault vault --action status

If Search Console is not connected yet, complete the bounded connection and first-read workflow in How to Connect Google Search Console to Codex With Aident Loadout.

Step 1: Discover the Current Search Analytics Action

Ask Codex to search the live Aident catalog for Google Search Console search analytics, inspect the current schema, and select the read that returns clicks, impressions, CTR, and position. Do not save an internal Action identifier in a permanent prompt because catalog versions can change.

The live schema should make these controls explicit:

• property identifier;

• start and end dates;

• query and page dimensions;

• final versus incomplete data;

• web, image, video, or another search type;

• page aggregation;

• row limit and pagination; and

• optional dimension filters.

Start with a small proof request. Confirm that the selected account can read the exact property and that the response keys match the inspected schema before requesting a larger window.

Step 2: Choose Equal Complete Windows

Search Console data normally lags by two or three days. End the current window on the latest complete date, then choose an immediately preceding window with the same number of days.

Keep all of these identical across both periods:

• property;

• canonical-page filter;

• search type;

• dimensions;

• aggregation type;

• country and device filters, if any;

• final data state;

• row limit and pagination method; and

• brand and relevance rules.

Record the extraction timestamp. A reusable report should never mean a moving phrase such as "last 28 days" without preserved dates.

Step 3: Export Query and Page Rows

Request the query and page dimensions with final data. Filter to the exact canonical URL, either in the Action input when supported or immediately after retrieval. Verify the filter with a small request because an invalid dimension or expression can return zero rows without an error.

Paginate until a page returns fewer rows than requested. The Search Analytics API can prioritize top rows and omit anonymized queries. Google documents a 25,000-row request size in the API guide and a 50,000-row daily export ceiling per search type, but the current Aident Action can impose a smaller runtime limit. Inspect the live schema and preserve the limit actually used.

Do not call this a complete keyword database. It is the reported, privacy-filtered Search Console footprint for the selected scope.

Step 4: Separate Brand and Relevance

Create one case-insensitive brand rule and use it in both periods. For example:

(^|[^a-z])(example brand|example product)([^a-z]|$)

Keep branded results in a separate table. They measure a different demand pattern and should not silently inflate broader discovery.

Then review the remaining query family for relevance to the page's reader job. Exclude obvious mismatches with a written rule, not a changing list designed to improve the score. Preserve the excluded count and a sample for audit.

For one exact page, each query normally has one row in the selected aggregation. If duplicates remain, collapse them to one normalized query and calculate its position with the same impression-weighted method. Do not count one query once per country, device, or landing page unless those are intentionally separate reports.

Step 5: Calculate the Nested Buckets

After filtering and deduplication:

rankingKeywordCount = count(distinct relevant non-branded query)
top3KeywordCount = count(query where position <= 3)
top10KeywordCount = count(query where position <= 10)
top20KeywordCount = count(query where position <= 20)

Also sum clicks and impressions for the same rows. Keep CTR as clicks divided by impressions, and calculate average position with impression weighting.

The report should make the nesting obvious:

Never replace the absolute values with percentage changes. A jump from one to two Top 3 queries is a 100 percent increase, but the denominator still matters.

A First-Hand Example From Aident

We ran the method across Aident's sitewide query-page rows for two equal, complete 28-day windows. This portfolio example uses a case-insensitive exclusion for explicit Aident, Aiden AI, and Loadout strings. It collapses matching query-page rows to distinct queries and uses impressions to weight position.

The direction is encouraging, but it is not a controlled SEO experiment. Aident added many pages, older pages had more time to index, search demand changed, and Search Console returned only its reported top rows. The result supports tracking keyword breadth and position buckets together. It does not prove that one content change caused the increase or that every added query was valuable.

Our broader agentic SEO pipeline case study keeps search discovery separate from activation and payment.

How to Read the Result

Use these patterns as diagnostics:

One good report should end with a bounded decision: protect the canonical, improve its answer, expand a missing section, consolidate cannibalizing pages, or create a new owner only when no existing page serves the job.

Common Mistakes

Treating Average Position as a Score

Average position changes with the query set. Always show keyword count and position buckets beside it.

Counting Irrelevant Variants

The goal is relevant non-branded coverage, not the largest possible number. Preserve the relevance rule and excluded sample.

Mixing Search Console With Ahrefs

The two sources model different universes. Search Console reports privacy-filtered first-party performance. Ahrefs estimates rankings from a third-party database. Keep their counts, dates, locations, and methods separate.

Comparing Unequal or Incomplete Periods

Use equal complete windows with the same scope. Search volatility is not evidence if the query contract changed between runs.

Creating a New Page for Every Query

Search the owned catalog first. Close variants that share one reader job usually belong in one canonical. Splitting them can create cannibalization instead of footprint growth.

Reporting Search Growth as Product Growth

Clicks and position measure discovery. Use tagged links and product analytics for setup, connections, successful Action execution, activation, users, payments, and revenue.

Reusable Codex Prompt

Paste this after setup and replace the bracketed values:

Use Aident Loadout to inspect the current Google Search Console Search Analytics schema and confirm my connected property. Run a small proof read, then measure the exact canonical [URL] across [current start] to [current end] and the immediately preceding equal period. Use final web data, query and page dimensions, the same page aggregation, and bounded pagination. Apply this case-insensitive brand rule: [regex]. Preserve branded rows separately, exclude only documented irrelevant queries, deduplicate normalized queries, and report ranking keyword count plus nested Top 3, Top 10, and Top 20 counts, clicks, impressions, CTR, and impression-weighted average position. State the row limit, extraction time, privacy and top-row limitations, and every filter. Check existing canonical ownership before recommending content. Do not submit a sitemap, perform another write, expose credentials, or combine Search Console counts with a third-party keyword database.

Set up Aident Loadout and run one Search Console keyword-footprint report.

For the general discovery, schema, and execution model, continue with How to Use Aident Loadout.

Sources

• Google Search Analytics query method

• Google guide to querying Search Analytics data

• Google guide to getting all available Search Analytics data

• Google explanation of Performance report dimensions and anonymized queries

• Google Search Console table reference and position calculation

• Aident Loadout setup

Refresh this guide when Google's Search Analytics limits or position definitions change, the live Aident Action schema changes, or comparable day-30 evidence changes how Aident interprets keyword breadth and qualified progression.