How to Use Codex AI to Choose SEO Keywords With Evidence

Build a keyword decision packet, not a keyword dump

Codex can make keyword research much less tedious. It can clean a messy export, spot overlapping queries, compare a content inventory with a SERP sample, and write the brief for the page you actually decide to make.

It cannot know whether a keyword is good for your business unless you give it evidence. It also cannot turn a difficulty score into a ranking forecast. The useful outcome is a keyword decision packet: a short record of the few queries you considered, the evidence behind each choice, the page that should serve the searcher, and the candidates you rejected.

Who this is for: an SEO lead, content marketer, or founder who needs to choose the next page or refresh without turning keyword research into a spreadsheet graveyard.

What you will finish with: one approved primary keyword, supporting queries, a page decision (new page, refresh, or no page), and an evidence-backed content brief.

You need: Codex, a small brand brief, an existing-URL export or sitemap, and either Search Console/authorized SEO-tool data or a documented reason that a metric is unavailable.

Allow: 60 to 90 minutes for a first pass. Done means: another teammate can understand why this keyword won without rerunning your entire research process.

The workflow below deliberately separates four questions that are often mashed into one number:

Search volume and keyword difficulty can inform the last question. They cannot answer the other three.

Set up a small research workspace

Create a folder that keeps source data separate from Codex's interpretation. Do not put API keys, browser tokens, or customer data you are not allowed to share into the project.

keyword-decision/
  context/
    brand-brief.md
    existing-urls.csv
  inputs/
    customer-language.csv
    search-console-queries.csv
    provider-export.csv
    serp-notes.md
  working/
    candidate-ledger.csv
  output/
    keyword-decision-packet.md

Your brand-brief.md can be one page. It should name the audience, offer, conversion event, target country and language, topics you can prove, and topics you should not pursue. The last two are more important than they sound. A high-volume query that needs product claims you cannot substantiate is not an opportunity; it is a future argument with your legal or product team.

Use this minimum structure:

# Brand brief

Audience: Operations leaders at 20-200 person ecommerce brands
Offer: Returns-management software
Primary conversion: Start a product trial
Target market/language: United States / English
We can prove: Supported platforms, setup requirements, published feature limits,
approved customer stories
Do not pursue: Legal advice, tax advice, competitor claims without a current source
Existing topic strengths: Shopify returns, exchanges, return-policy templates

Quality check: A reader who knows nothing about the company can tell which visitor decisions the site can help with. If Codex receives only a domain name and a wish for "high-traffic keywords," stop here and improve the brief first.

Give Codex a clean evidence ledger

Start with customer phrasing, not a tool's idea list. Collect questions from sales calls, support tickets, product demos, internal site search, reviews, and Search Console. Preserve the original wording and add where it came from. A query such as shopify return exchange rules is more useful when you know it came from a merchant trying to configure exchanges, rather than from a random autocomplete suggestion.

Make customer-language.csv with these fields:

phrase,source,searcher_context,possible_next_action
can customers exchange instead of return,support ticket,Merchant configuring returns,Read exchange setup guide
shopify return exchange rules,sales call,Merchant comparing workflow options,Start trial
how to reduce return emails,site search,Support manager looking for a process,Read operations guide

Then ask Codex to create candidates without pretending that it has measured demand:

You are preparing a keyword research ledger, not selecting a winner yet.

Read:
- context/brand-brief.md
- context/existing-urls.csv
- inputs/customer-language.csv
- inputs/search-console-queries.csv, if present

Create working/candidate-ledger.csv with one row per distinct searcher job.
Keep the original phrases, merge only genuine duplicates, and propose 1-3 query
variants per job. For every row, include:

- candidate query
- underlying searcher job in one sentence
- likely intent (learn, solve, compare, buy, or navigate)
- evidence source
- existing URL that may already serve the job, or NONE
- probable page route (new, refresh, consolidate, or no page yet)
- data fields still needed
- uncertainty note

Do not invent search volume, difficulty, rankings, competitor coverage, or
product capabilities. Do not edit source files or publish anything.

Expected output: a finite ledger, not 500 loosely related phrases. Twenty to forty well-labelled candidates are enough for a first pass.

Recovery path: If Codex produces one row for every word-order variation, tell it: Merge variants that would be satisfied by the same page and the same primary answer. Preserve the variants in a supporting_queries field.

Codex should retain the source and uncertainty for every candidate, rather than turn a query list into assumed facts.

Add demand and competition signals without worshipping them

Next, enrich only the candidates that match a real searcher job and your business boundary. You can use Search Console for your existing query exposure and an SEO provider you are authorized to access for estimated demand and SERP data. Record the provider, market, language, retrieval date, and exact field name beside every metric.

For a structural view of difficulty, inspect the live result page rather than relying on a score alone. Note whether top results are homepages or internal pages, how strong the domains appear, whether the page types are specialized, and whether a branded result set leaves any realistic third-party positions. Use any difficulty output as a documented estimate, not a promise that you can rank.

For each surviving query, save a short SERP note. It should answer:

Do not make up a numeric difficulty score if you have not run a tool or saved a SERP sample. Mark it unavailable and explain what needs checking.

Use this prompt after pasting or saving the data:

Read working/candidate-ledger.csv and the files in inputs/.

For each candidate with supplied metrics or SERP notes, add these columns:
- market and language
- data provider and retrieval date
- demand evidence (keep the original metric and source)
- SERP format pattern
- structural-feasibility note
- brand-lock risk (low, medium, high, or unknown)
- evidence gaps

Interpret the supplied data only. A difficulty metric is one signal, not a
ranking prediction. Do not convert paid competition, CPC, or a provider's KD
into an organic-traffic promise. If a candidate has no market, language, or
data source, flag it as NOT READY FOR PRIORITIZATION.

Quality check: Codex can point to the exact input that supports every number. If it cannot, the number does not enter the decision packet.

Make Codex test intent against the actual search results

The same words can mask different jobs. Return policy template usually asks for a reusable asset; return policy software asks for a category or product decision. A volume field cannot tell you whether your planned page will satisfy either search.

Choose the five to ten candidates that still look useful, open the result pages in your target market, and save a plain-text serp-notes.md. You do not need to copy the pages. Write down the result format, recurring headings, apparent audience, gaps, and whether a local answer, product page, forum, or brand result changes the job.

Then run this intent check:

You are an SEO content strategist checking page fit.

Read the brand brief, existing URL inventory, candidate ledger, and SERP notes.
For each candidate, return:

1. The searcher's decision or task, in plain language.
2. The page format most likely to satisfy it now.
3. The existing URL to refresh or consolidate, if one already serves that job.
4. The one piece of first-party information our page needs to add to be useful.
5. A REJECT decision when the query is brand-locked, outside our scope, or
   would create a duplicate page.

Quote the evidence file and row or note for every decision. Do not recommend
a new article merely because a query has volume.

This is the moment where a keyword list becomes a content strategy. If the same existing URL can answer three variants, choose one primary query and keep the others as supporting language. Creating three new pages is not a sign of thoroughness. It is often the beginning of cannibalization.

Score the candidates, then read the contradictions

Codex is helpful when it puts comparable evidence into a table. It is less helpful when it hides judgment behind a magic formula. Use a five-point scale, but require a reason and source for every score.

Run the final selection prompt:

Create output/keyword-decision-packet.md from the research files.

First apply hard stops. Reject a candidate if:
- its searcher job is unclear;
- it is outside the brand brief or needs unsupported claims;
- an existing URL already answers the same job and should simply be refreshed;
- the SERP is brand-locked with no useful third-party angle; or
- the page would add no verified information advantage.

For the remaining candidates, score business fit, intent/format fit, evidence
strength, relative feasibility, and information advantage from 1-5. Cite the
file, row, or SERP note supporting each score. Do not average away a hard stop.

Return, in this order:
1. A ranked decision table with one-sentence rationale per score.
2. The recommended primary keyword and supporting queries.
3. The page decision: new page, refresh, consolidate, or no page.
4. The exact searcher job and proposed page format.
5. A content brief: promise, outline, verified facts required, internal-link
   candidates, conversion action, and measurement note.
6. Rejected candidates and why they lost.
7. An evidence-gap list for the human owner.

Use UNKNOWN where evidence is absent. Do not change site files, create pages,
or publish content.

A fictional decision-table fragment

The numbers below are examples of a scoring conversation, not real keyword metrics:

A candidate is approved only when it clears the hard stops and the page can add something the current SERP lacks.

The middle row might be the best work even if the template has more apparent demand. It has a clear existing home, a focused gap, and a lower risk of creating a duplicate. That is why you need the decision packet.

Verify the winner before assigning a writer

Before a page enters the content calendar, run a short owner review. Codex has done the sorting; it has not replaced the person accountable for the claim, the budget, or the product decision.

• [ ] The primary keyword matches one clear searcher task.
• [ ] Target country and language are stated for every external metric.
• [ ] Every number has a provider, date, and original field name.
• [ ] The proposed page matches the current SERP format without copying competitors.
• [ ] An existing URL was considered before creating a new one.
• [ ] The brief names the first-party facts, examples, or template material that make the page worth reading.
• [ ] A relevant conversion action exists, but it does not distort the answer.
• [ ] A human owner has approved the final page route.

If any of the first five boxes is unchecked, send the packet back to research. If the last three are unchecked, the keyword may still be promising, but it is not ready for production.

Keep the research useful after publishing

Save the packet with the page brief and note the release date. After one comparable reporting period, check the page-query relationship rather than celebrating a sitewide traffic change. Look for impressions, clicks, average position, qualified next actions, and feedback that shows whether the page solved the intended job.

If a page earns impressions for a different but related question, do not automatically publish another article. Ask Codex to compare that query with the approved page's scope. It may reveal a section to add, a supporting page that genuinely serves a different job, or a query that should remain unaddressed.

That restraint is part of choosing keywords well. Good research narrows the next move.

FAQ

Can Codex find keywords without an SEO API?

Yes, it can organize customer language, Search Console exports, site-search terms, and manual SERP notes into a candidate ledger. It should label search volume, difficulty, and competitor metrics as unknown when no authorized data source supplies them. A neat table of invented numbers is worse than no table.

Should I choose the keyword with the lowest difficulty score?

No. A low score can still represent a poor business fit, a misleading SERP, a brand query, or a topic your site cannot answer better than the current results. Use difficulty to inspect the route into the SERP, then weigh that against intent, page fit, and your available information advantage.

When should a keyword become a refresh instead of a new article?

Choose a refresh when an existing URL already answers most of the searcher's job and can be made materially better with a missing section, first-party proof, clearer format, or better internal connection. A new article is appropriate only when it serves a distinct task or decision.

Can Codex choose the final keyword automatically?

It can recommend a winner from explicit rules and evidence. Keep a human approval step for claims, brand boundaries, opportunity cost, and the decision to create or change a page. Keyword research is a prioritization task, not a fully automated publishing command.

Author: Simon Vale, 11-Year Search Intent Researcher at Auspia. Simon writes about buyer queries, SERP patterns, and content decisions that match what searchers are actually trying to do.