What the simpler output dropped
The old version described templates. This one decides between them.
Nothing in the old output was wrong, it was just work you had to do yourself. A count of 1,500 to 3,000 meant picking a number. A risk rating of medium meant converting a label into a go or no-go. A pattern like /best-{tool}-for-{use-case}/ meant substituting your own data in your head to see whether the result was a page anyone would want.
Those steps now happen before the output reaches you. What is left per idea is a name, 1 example URL, 1 page count, 2 one-line facts, a verdict and 1 sentence of reasoning.
The 3 inputs for better SEO ideas
Business type. One line, specific. "B2B SaaS for field service scheduling" produces different ideas than "software company".
What you already have a list of. This decides everything, and the counts are the part people leave out. "400 integration partners, 60 industries we serve, pricing for 12 plans, 3,000 customer reviews, the 48 states we cover" is usable. "We have a database" is not. The counts decide whether an idea makes 50 pages or 50,000, and whether those pages carry anything of their own.
Audience. Optional, 1 line. It changes which ideas rank highest, because the same inventory serves a buyer and a practitioner differently.
Ideas are only proposed for data you described. If the inventory is thin, that shows up in the verdicts rather than in invented templates.
What each generated idea carries
- A plain-English name. "A setup guide for every integration", not "Programmatic comparison matrix". If you would not say it out loud to a colleague, it is not the name.
- One real example URL, with the variables already filled in from your own data:
/integrations/quickbooks-online-setup/, never/integrations/{partner}-setup/. The brace pattern comes too, for whoever builds the pipeline. - A single page count. Not a range. A whole number of pages your data would produce.
- You need. One line naming the exact data each page requires, and saying plainly when you do not have it yet. "Your partner list, which you have" reads very differently from "a list of cities, which you would have to build".
- Each page differs by. One line naming the specific thing that varies per page: real per-row prices, actual review text, spec numbers, a computed comparison. If nothing can be named there, the verdict is Skip.
- A verdict, 1 of 3.
- One sentence of reasoning. Concrete, not "this could rank well".
Build this, Only if, Skip
Build this means the data supports it and each page is genuinely different from its siblings.
Only if means the idea works, but only once you add the unique element named in "Each page differs by". It is a conditional yes with the condition attached.
Skip means the pages would be near-duplicates whatever you do, and the honest move is not to build them.
The model is told not to rate everything Build this, and to use Skip freely. It is also told that at least 1 idea has to be something you could start this week, so 5 skips is not an available answer either. Between those 2 constraints, the count at the top is doing real work rather than flattering you.
A programmatic SEO run for a field service SaaS
Business type "B2B SaaS for field service scheduling", audience "operations managers comparing scheduling tools", 400 integration partners in the inventory. Run live, the top idea came back Build this at 400 pages, the pricing idea Only if at 12:
A setup guide for every integration [BUILD THIS]
/integrations/quickbooks-online-setup/ x 400 pages
pattern /integrations/{partner}-setup/
You need Your partner list and the setup docs you
already maintain for each one
Each page differs by The real auth steps, synced fields and
known limits for that partner
A page for every pricing plan [ONLY IF]
/pricing/field-service-scheduling-for-5-technicians/ x 12 pages
pattern /pricing/{plan}-plan/
You need Your 12 plans, which you have
Each page differs by Seat count and price, and not much else
until you write what each tier is for
A page for every city you cover [SKIP]
/field-service-scheduling-phoenix-az/ x 1,200 pages
pattern /field-service-scheduling-{city}/
You need Per-city data you do not have. Covering
48 states is 1 fact, not 1,200 facts
Each page differs by The city name
The city idea is the one worth staring at. It has the largest page count on the list and it is the one that would sink the project, because state coverage is 1 fact stretched over 1,200 URLs. The old output called that a high risk rating with a mitigation. Now it says Skip.
Page counts are counts, not forecasts
A page count is the number of pages your own data could fill. Multiply the cardinalities and that is the figure. It tells you the size of the build and nothing else.
It is not traffic. There is no keyword API behind this tool, so nothing in the output carries search volume, keyword difficulty, CPC or a traffic estimate, in any form, not even as a range with a tilde in front of it. A model asked for a monthly volume will produce one, formatted convincingly, derived from nothing, and you would sort by that column.
So take the ideas that came back Build this and check demand in a tool with a real data source first. That check costs an afternoon. The pipeline costs a quarter.
Where the answer will be no
A common outcome for a young company is 1 buildable idea, sometimes zero, and a first line opening with "No". That is the tool working. Most programmatic SEO projects that fail were not badly built. They were built on an inventory with 1 interesting column and 9 decorative ones, and no template design fixes that. Collecting the missing data is slower and it is the only thing that works.
2 other limits. The tool cannot see your site, so an idea may overlap pages you already published. And it judges your description of your data rather than the data itself, so a vague inventory gets vague ideas.
Once an idea survives that, the per-page content is still the work. BlazeHive automates SEO content end to end if you want that half running on its own.