Programmatic SEO keyword research: from a head term and modifiers to a list of pages worth building
Programmatic SEO keyword research finds a search pattern, a head term plus a changing modifier, and tests it before you build: list the modifiers, search a sample to see what ranks, add up demand across the whole set, mine Search Console with a regex filter, and give each distinct intent one page.
Key takeaways
- Research the pattern, not the keyword: one head term, a list of modifiers, one page per real intent.
- Keyword Planner can't show keywords with very low volumes, so judge demand across the set, not row by row.
- Search Console's Custom (regex) filter uses RE2, matches partially and ignores case unless you add (?-i).
- If two phrasings return mostly the same top results, they share an intent and belong on one page.
- Search Console omits anonymised queries, so a regex export is a strong sample, not a full census.
What are head terms and modifiers?
A programmatic pattern has two parts. The head term stays the same in every search: integration, cost of living in, salary. The modifier changes: the tool, the city, the job title. Together they make a pattern such as [tool] integration or [role] salary in [city], and every value of the modifier is a candidate page.
People rarely phrase a pattern one way. [tool] integration, connect [tool] to [product] and [product] [tool] sync are usually one need in different words, so the unit you research is the modifier, not the phrasing: one page per tool, written to answer all three. Patterns with two modifiers, such as role and city, multiply fast, which is why they need the checks below before any page exists. The guide to programmatic SEO explains where these patterns fit in the wider method.
How do you build a modifier list?
Start with the values you can actually serve, then widen. The useful sources, roughly in order of how far you can trust them:
- Your own data. The integrations you support, the areas you deliver to, the products in your catalogue, the questions customers send to support.
- Your Search Console queries, which show the modifiers people already type next to your head term (the method is further down).
- The search box and the results page. Autocomplete and related searches for the head term suggest values you had not listed.
- Reference lists for closed sets: countries, currencies, cities above a population threshold, units.
- Competitors' URL patterns, often readable in their sitemaps, which show the modifiers they chose to build.
Then clean the list. Merge aliases and spellings (NYC and New York, Google Sheets and Sheets) into one value with its variants stored beside it, because they are one page. Drop values you cannot back with data or cannot serve: a removals firm needs no page for a town it does not cover.
How do you check a pattern on the results page?
Before you trust any volume figure, search a sample of 10 to 20 variations, spread between popular and obscure values, in the country you target. For each, note three things:
- What type of page ranks. If the top results are pages of one kind, one per variation (an integration page, a city page, a converter), the pattern wants a page per value. If they are long guides or forum threads, a templated page will struggle.
- Whether one page ranks for many variations. When the same general page appears across the sample, searchers are content with a single page, and your set would compete with it rather than fill a gap.
- Whether the results change with the modifier. Different results for Cardiff and for Glasgow mean the answers differ; near-identical results mean one page should serve both.
Note, too, when the results page answers the search itself, with a figure in a box or a short AI summary. Those variations can still deserve a page, but only if yours adds the detail the summary leaves out.
How do you measure demand across a whole set?
If a keyword tool shows zero or no data for most of your variations, it is tempting to conclude that nobody searches them. Often that is the tool, not the demand. This section explains how to read volume figures for a set and what to trust instead. Two details in Google's own Keyword Planner explain many of the gaps:
- Keywords with very low search volumes are not discoverable or forecastable in Keyword Planner at all, so most long-tail variations return nothing.
- Average monthly searches count a keyword and its close variants, averaged over 12 months by default. Two near-identical phrasings can show the same demand, so adding both counts it twice, and a 12-month average hides seasonal peaks.
So measure the set, not the row. Add up the volumes for the values that have them, treat zero-volume values as unknown rather than worthless, and compare the total with what one page per value will cost to build and keep accurate. Where you already appear for the pattern, Search Console impressions are better evidence than any estimate, because each one is a real search that showed your site.
How do you find patterns in your Search Console data?
The Performance report already lists searches that show your site, including variations of patterns you have no page for. Its regular expression filter turns that list into a pattern finder:
- Open the Performance report, click + Add filter, choose Queries, then Custom (regex).
- Enter a pattern such as
(integration|integrate|connect|sync)or(salary|salaries|pay) in: alternatives separated by a vertical bar, the whole set in parentheses. - Matching is partial by default, so anchor with
^or$when you mean the start or end of the query, and it ignores case unless you begin with(?-i). The syntax is RE2. Switch to Doesn't match regex to keep brand searches out of the way. - Export the result and add a column for the modifier each query contains; impressions per modifier give you a demand list built from real searches.
Two limits matter. Search Console omits some queries to protect privacy, and Google notes that filtering by query can change the report's totals because of those omissions and data truncation; the table also shows only the most important rows, with bulk data export as the route to the fullest list. Read the export as a strong sample, not a census. The guide to keyword research in Search Console covers the report's other filters.
Say you sell bookkeeping software to tradespeople and filter for (software|app) for. The export shows impressions for 31 trades, from electricians to dog groomers, mostly landing on your homepage below position 20, and nine trades account for most of the impressions. Those nine are your first rows; the other 22 wait until you have something specific to say about each trade.
How do you keep one intent per page?
A pattern can hide two intents behind one modifier. [tool] pricing and [tool] alternatives share a modifier but want different pages; [tool] integration and connect [tool] share an intent and want the same one. The quickest test is overlap: search both phrasings and compare the top ten results. If half or more are the same pages, one page should answer both. If they barely overlap, they are separate intents and need separate pages, or one of them belongs to another pattern altogether.
Watch for words that switch intent inside any pattern: free, template, vs, alternative, near me, how to. Give each its own pattern rather than a paragraph on the main page. Once pages are live, look in Search Console for queries where two of your pages take turns appearing: that usually means two pages answer one intent and should be merged.
Which patterns and rows should you build first?
Score each pattern from 1 to 5 on five questions, with 5 always the better case (for competition and effort, the lightest), and build the highest total first:
- Demand: the set's total from tools and impressions, not its best single row.
- Data: whether you hold, or can build, what each page needs.
- Value: how close a visitor is to becoming a customer; an integration page usually beats a glossary entry.
- Competition: whether the results are already full of strong pages of the same kind.
- Effort: the cost of building every page and keeping it accurate.
Within the winning pattern, publish the rows with the best data and the clearest evidence first, a few dozen rather than the whole list, and let Search Console show you which are indexed and earning impressions before you add the rest. The guide to programmatic SEO templates sets the data threshold each row must pass.
AutoPSEO's content engine does the Search Console side of this research for you: it reads three months of your Search Console data, finds searches your site appears for with no page about them, sets aside brand searches and anything your pages already cover, and reviews each remaining topic against your closest pages before writing. The topics documentation describes each source and check.
Frequently asked questions
How is this different from normal keyword research?
The tools are the same; the unit is different. Normal research picks individual keywords for individual articles. Programmatic research picks a pattern and judges the whole set of variations, so a pattern can be worth building even when no single variation looks big.
What if my site is new and has no Search Console data?
Use your own data for the modifier list, the results-page check for the format, and tool volumes for the head term and the bigger variations. Publish a small first batch, then let the impressions it collects decide what comes next.
Should I build pages for zero-volume variations?
Only when the page has real data to show and the variation belongs to a pattern with proven demand. A zero in a keyword tool often means the volume is too low to report, not that nobody searches. A page with nothing specific to say is the problem, not the zero.
How many modifiers are too many?
As many as you can no longer keep accurate. Fifty maintained pages are worth more than five thousand drifting out of date, and two-modifier patterns grow so fast that most combinations should be left out.
Can AI help with the research?
It is useful for expanding and cleaning modifier lists and for tagging exported queries with their modifier. Check its groupings against the results pages, since a model can merge two intents that look alike or suggest modifiers nobody searches.