Programmatic SEO · focused work
Programmatic buying guides
A buying guide answers the question that comes before the purchase, which is simply which of these should I get. Produced at scale, the version that works is not a template with a product name dropped into it. It is a page assembled from real specifications and real differences between the options, carrying a judgement that no template can generate on its own.
This is the right work if
- Shoppers ask which option to choose and no page on the site answers it
- A handful of guides were written years ago and most categories have nothing
- Comparison tables were typed by hand and the specifications in them are now wrong
- Guides recommend products without linking to them, so a decided reader searches again
- Nobody measures whether people who read a guide go on to buy anything
What it is
How guides are generated and where writing is still needed
The set usually covers four patterns: choosing within a category, choosing for a particular use or person, comparing two types of product, and choosing under a constraint such as a space, a skill level or a budget. Each of those can be assembled largely from catalog data. The options available, the attributes that separate them, the specification ranges across the range stocked, the price bands and the products themselves all come from the same source the store already maintains, which is what keeps the guides correct when the catalog changes.
The part that cannot be generated is the recommendation. Saying which option suits which situation, and why, is product knowledge, and a guide without it is a specification table with a heading. So the working model pairs a data-driven template with a short required contribution from somebody who knows the products, written once per guide or per guide family. That requirement doubles as the publication gate: a guide goes live when its category holds enough genuinely different options to be worth comparing and the editorial section exists. Everything else waits. After launch the data sections regenerate with the catalog and the editorial sections are reviewed on a schedule, because a guide recommending a discontinued product ages badly and visibly.
How it is done
The work, in order
What changes
- Every category has a page that helps somebody choose between the options
- Specifications inside guides stay correct because they come from the catalog
- A reader who has decided has a link to the product instead of another search
- The guide set is judged on the revenue it assists rather than on page count
Choose the guide patterns worth building
Validate each pattern against questions people actually ask, taken from support conversations, site search and the store's own query data. A pattern that produces a hundred pages nobody was looking for is worse than three patterns that answer real questions.
Assemble the comparison from catalog data
Generate the specification tables, the attribute ranges and the product sets from the catalog so they update when it does. Include the attributes that genuinely separate the options and leave out the ones identical across the range, which add length without helping anyone decide.
Add the judgement a template cannot produce
Require a short section per guide, written by someone with real product knowledge, saying which option suits which situation and what the trade-off is. This is the reason a reader stays, and it is what a summary of the page will quote.
Gate publication on both halves
Publish only where the category holds enough genuinely different options to compare and the editorial section has been written. Guides that fail either test stay unpublished rather than going live thin with a plan to improve them later.
Link the guide into the catalog
Every recommendation links to the collection or product it names, and the relevant category and product pages link back to the guide. A decision made on a guide should be one click from being acted on, not the start of another search.
Refresh and measure honestly
Regenerate the data sections when the catalog changes, review the written sections on a schedule, and measure the set on assisted revenue and on traffic sent into the collections it recommends, since guides rarely convert on the visit where they are read.
Platform notes
Shopify
Structured content objects can hold the editorial sections and the guide metadata so writers work in the admin rather than in code, with the comparison tables rendered from product data at request time.
Headless
A content system holds the written sections while the specification tables are composed from the commerce API at build or request time, which keeps the two halves separately editable and separately cacheable.
Does generated guide content count as low quality?
Not when each page carries information that could only apply to it and a recommendation somebody stands behind. What gets judged poorly is a set of pages saying the same thing with substituted nouns, which is a template problem rather than a consequence of generating pages.
How much writing does each guide really need?
Enough to carry the judgement, which is often a few hundred words rather than an essay. The tables, ranges and product sets do the informational work. The written part exists to say what the data cannot, which is which choice suits which reader and what they give up by making it.
Should guides live in the blog or in the catalog?
Close to the catalog, linked from the categories they describe and linking back into them. Guides parked in a blog archive tend to lose their internal links over time and end up disconnected from the products they are meant to sell.
How do you measure guides that rarely convert on the visit?
By the traffic and revenue they assist, the sessions they send into collections and product pages, and repeat visits from the same reader. Judging a guide on the conversion rate of its own page will always make it look like a failure and lead to it being deleted.
Related work and answers
Find the leak.
A free Growth Analysis ranks what your store should fix first, by revenue at stake.