How to Brief a Programmatic SEO Page: Decide Which Rows Deserve a Page

By Jascha Kaykas-Wolff, former CMO of Mozilla and BitTorrent ·

Brief a programmatic SEO page as one template plus a dataset, and put a publish rule in the brief: a row becomes a page only when it carries enough data of its own to change what a reader does. Integration pages and live data pages usually pass that rule, because the data differs by row. Location pages usually fail it, so the brief should name the sample rows the editor will check and what happens to every row that falls short.

A 40-person company that sells shift-scheduling software decides to build a page for every combination of industry and city it can think of. Restaurants, retail, warehouses and clinics, times 600 cities. The spreadsheet runs to 2,400 rows, the CMS builds them in an afternoon, and a writer spends a week on the template copy. Ninety days later Search Console shows 310 of the pages indexed, and almost all the clicks going to about 60 of them.

The 60 were cities with a fair workweek or predictive scheduling law. Most were in Oregon, whose statewide scheduling law took effect in 2018, and the rest were places like Seattle, Chicago, Philadelphia and New York City. Those rows had a real rule to explain, with real notice periods and real penalties, and a restaurant manager searching from one of those places had a reason to read past the first paragraph. The other 2,340 pages said the same thing with a different city name in the H1.

Nobody wrote a brief that could have caught it.

Most programmatic SEO guides spend their length on the build: which spreadsheet feeds which CMS, how to sync Airtable to Webflow, how to template a title tag. That part is now easy, and it is easy in a way that makes the expensive mistake cheaper to repeat. Our view is that a programmatic page needs a brief at least as carefully argued as a hand-written one, written against the data instead of the prose, and that the most valuable line in it is the one saying which rows should never become pages. Google has had a name for the alternative since March 2024, when its spam policies added “scaled content abuse.”

What makes a programmatic brief different

A normal content brief describes one page for one reader searching one phrase. A programmatic brief describes a pattern (“shift scheduling for [industry] in [city]”), and the writer will never see most of the pages it produces. So the brief has to do two jobs a normal brief skips. It has to say which parts of the page are written once, by a person, and which parts come from a column. And it has to set the bar a row must clear before anyone builds it.

Programmatic page types compared

The page type mostly decides whether the publish rule will be easy to pass. Teams tend to start from the pattern with the most search volume and only then ask what data they have, which is backwards.

Page typeFamiliar exampleUnique data each row needsWhere the data comes fromKey trade-off
Integration pagesZapier’s “connect App A to App B” pagesReal triggers and actions for that pair, setup steps, limitsYour product’s own integration catalogThe safest type, because the data is yours and differs by row. Pairs nobody uses still produce thin pages.
Conversion and data pagesWise’s “USD to EUR” currency pagesA live number, its history, fees for that pairA feed you license or produceRanks well when the number is fresh. A stale feed makes every page wrong at once.
Location pages“Shift scheduling software in Seattle”Local rules, local prices, local customers you can namePublic records, your sales data, field teamsThe type most likely to fail. Most cities have nothing local to say about most products.
Glossary pages“What is a fair workweek law”A definition plus an example from your own fieldYour editors, one entry at a timeProgrammatic only in the template. Each entry needs a person, so volume stays in the low hundreds.
Generated comparisons“Tool A vs Tool B” for every pair in a categoryPrices, features and a verdict for that specific pairA maintained competitor spreadsheetFast to build and fast to go stale. The verdict is the part a template cannot write.

Where each type fits (and where it does not)

Integration pages. Build these first if you have an integration catalog, because every row already holds facts nobody else can publish. Leave out pairs with no real users. A page for connecting your product to a tool three customers have ever asked about is a support article, and should probably live in the help center.

Conversion and data pages. Only when you own or license the feed and someone is paid to notice when it breaks. One outage means every page shows the wrong number on the same morning.

Location pages. Brief them city by city in your head before you brief them as a template. If you cannot name something true about Tulsa that changes the advice, Tulsa does not get a page. Expect the set to shrink hard. The shift-scheduling company above would have gone from 2,400 rows to about 60, and those 60 were the pages that worked anyway.

Glossary pages. Use the template for layout and schema, then have an editor write each entry. The editorial style guide should already hold half the definitions; our guide to building an editorial style guide covers where that list lives.

Generated comparisons. Tempting, and the type we would build last. A comparison is useful because of its verdict, which a template cannot write, so generate the price and feature grid and then brief the top 20 pairs by hand, the way our guide to briefing a comparison page describes.

Fields a programmatic brief needs

  • The query pattern, with three sample rows. Pick a head row (Seattle restaurants), a middle row (Columbus warehouses) and a tail row (Tulsa clinics). Every decision in the brief gets checked against all three, and the tail row is the one that tells the truth.
  • The publish rule. Ours: a row needs at least two non-empty data fields that would change what a reader does next. A city name, a state name and a population figure count as zero. A local scheduling law and a typical shift length for that industry count as two.
  • What happens to rows that fail. Don't build them, fold them into a parent page (“shift scheduling for restaurants”), or build them with a noindex tag for users who arrive from inside the product. Pick one before launch, in writing.
  • A block map. List every section of the template and mark it fixed (written once), filled (pulled from a column) or per row (written by a person for each page). The per-row blocks are where the cost is, and where the ranking usually comes from.
  • The data source, its owner and its refresh date. If nobody's job includes updating the spreadsheet, the pages start going stale on launch day.
  • The linking pattern. Each row page links up to its parent and across to a few siblings, and the parent links down to every page that passed the rule. Our piece on content cluster strategy covers the hub side of that.
  • The success measure. Indexed pages divided by published pages, read in the Search Console Pages report 90 days after launch. Blunt, and very hard to spin.

Check the tail row before you write the template

Run the SERP check on all three sample rows, the tail especially. Paste each phrase into the ContentBrief.io brief generator, which reads the top 10 results and returns their headings and word counts, the People Also Ask questions and a recommended length, in about 30 seconds and for free. Then compare the three. If the tail row's results are the same national pages as the head row's, Google is telling you the city does not change the answer, and your 600 city pages will compete with each other for one result. If the tail row returns local businesses, local news and forum threads, the pattern has real local intent and the template has a chance. Our guide to SERP analysis for a brief covers what to look for in each set.

We should be plain about the limit. Our generator makes one brief per keyword, and it has no way to build or check 2,400 pages. For the build you need a spreadsheet and a CMS that can template from it, and for the publish rule you need a person reading rows. What a brief generator does well here is the three-row comparison above, before anyone writes a line of template copy.

Who writes the per-row copy

Some of it will be drafted by a language model. That is fine for filled blocks with tight inputs, such as a two-sentence summary of a local law written from the statute's own text. It goes badly when the model is asked to say something interesting about a row that has no data, because it will say something anyway, and the something will be made up. Give the model a fact sheet per row and nothing else, as our guide to a content brief for AI writing describes, and have an editor read the head, middle and tail rows in full before anything ships.

After launch

Read the indexed ratio at 90 days. Our rough line is half. Above it, the rule worked and you can add rows that pass it. Well below that, Google has looked at your pages and decided most of them do not need to exist, and it is usually right. Treat that as an input to a content audit: sort the pages by clicks, keep the rows that earned them, and fold or remove the rest instead of waiting another quarter.

Before the first launch, run the three sample rows through the same pre-publish QA as any hand-written page, plus one check a template makes necessary. Open a row with an empty column and look at the rendered page. Somewhere on it there will be a sentence like “Employers in Tulsa must post schedules days in advance,” with nothing where the number should be.