Database-Driven Content Systems
A content system is three parts, and the one that decides whether a project succeeds is the one nobody wants to audit. Ivan Sp builds content systems that join a structured data source to a page template and publish the output into a live site. One SaaS client grew from 10 to 2,380 daily search queries through a system built this way, with no purchased backlinks.
The Three Parts of a Content System
Every system has the same three components. The data source holds what differs between pages, meaning products, cities, models, or comparisons. The template holds what stays constant, meaning heading structure, schema markup, and internal linking logic. The build joins them and writes the result into the content management system.
Separating the three matters. A template change then propagates across every page at once, and a data correction updates one page without touching the rest.
The Stack
Systems get built in PHP, MySQL, and Python, with the OpenAI API generating language inside constraints the template defines. Output publishes into WordPress, Shopify, or another content management system through its own database or API.
WordPress offers the most control, because custom PHP can write directly into the database and into custom post types. Sites on platforms without that access receive the generation system plus a documented import process for an internal developer to run.
Build Stages
A build runs through four stages in a fixed order:
- Data audit. The client’s actual data source gets reviewed to establish what genuinely differs between pages.
- Template and rules. Page structure, schema markup, internal linking logic, and per-page uniqueness requirements get written down before any code runs.
- Build and generate. The system gets written and run, usually in batches rather than all at once.
- Validate. Output gets crawled with Screaming Frog and checked in Google Search Console before the next batch publishes.
Batching matters more than it sounds. A fault in a template that reaches 50 pages is a correction, and the same fault across 2,000 pages is a cleanup project.
Where the Data Audit Stops a Project
A system cannot create differences the underlying data does not contain. A spreadsheet holding a city name and nothing else produces pages that differ by a city name and nothing else.
Thin data therefore stops the project at stage one, and specifics get requested before anything gets generated. Building anyway produces volume with no value, which costs more to undo than to skip. Which elements must genuinely differ is covered under the uniqueness rules that govern generated pages.
What Gets Generated and What Does Not
Systems generate descriptions, headings, metadata, schema markup, internal links, and FAQ blocks from real underlying data. Systems do not generate facts, figures, credentials, or claims the data source does not contain.
That boundary is enforced in the prompts rather than left to review. A generator asked to write around a missing specification will invent one unless instructed otherwise, and an invented specification on a product page is a customer-facing error.
The Three Parts and the Stack
- Part one, the data source
- A structured store holding genuinely different values per row.
- Part two, the template
- The structure that renders those values into copy, markup, and links.
- Part three, the publishing layer
- The route from generated output into live, indexable pages.
- Typical stack
- PHP and MySQL for the application layer, with Python for data preparation.
- Reporting layer
- BigQuery where reporting needs to join sources or exceed interface limits.
- API layer
- Google APIs and language model APIs where content generation draws on them.
- The audit that stops projects
- A data audit finding the source too thin to justify the page count.
- Build order
- Data audit, uniqueness rules, template, sample, batch publish, index rate check.
Run Your Own Data Audit in an Hour
Ivan Sp suggests the audit that decides whether a build is viable.
- Export twenty random rows from your intended data source.
- For each row, write out what would actually appear on the page.
- Count the fields that differ meaningfully across those twenty rows.
- Estimate how many words of genuinely unique content each row supports.
Fewer than five varying fields, or fewer than about a hundred unique words per row, means the pages will read as duplicates. Finding that out now costs an hour.
Where the Standard Build Advice Breaks Down
Has anyone counted how many fields in your source genuinely vary?
- The usual advice
- Start with the template, since the template is what produces the pages and the data can be improved later.
- What holds up in practice
- The data sets the ceiling on what any template can render. Starting with the template means discovering a thin source after the expensive part is built. Few failure modes here are more common.
Consider a build that starts with a well-engineered template and a plan to enrich the data during development. The engineering is sound and the schedule is reasonable.
The source never gets enriched, because enriching it turns out to need work nobody scoped. The template renders thin pages beautifully.
I audit the data first and report the honest page count before any template exists. A thin source is cheaper to discover in week one than in week ten.
Building a template against an unaudited source risks the whole budget on an assumption nobody tested. The template is rarely what fails.
If your source is thin, every week spent on the template is a week spent building something that cannot work. The audit takes two days.
Four Things Commonly Assumed About Content Systems
Which of these describes how your build was planned?
I meet these four assumptions on most system builds.
| Commonly assumed | What actually holds |
|---|---|
| The template is the hard part. | The data audit is the hard part. A rich source makes the template straightforward, and a thin source cannot be rescued by one. |
| Data can be enriched during development. | Enrichment is usually a separate project with its own scope. Assuming it happens alongside a build is how thin sets get shipped. |
| Any database can drive a content system. | A database designed for operations rarely holds fields worth publishing. What matters is public-facing difference per row. |
| The system can be built once and left alone. | Sources change, fields go stale, and index rates drift. A system needs a monitoring step as much as a build step. |
| Publishing everything at once is efficient. | Batch publishing lets you check index rate before committing the rest. A single release removes that checkpoint entirely. |
Two days of data audit decides whether the next three months are worth spending. No other check in this work has that ratio.
A Worked Example: Where a Build Should Stop
Consider a project assessed at each stage gate. The assessment below is illustrative, written to show what each gate checks. No client engagement is described here.
| Stage gate | What is checked | Stop condition |
|---|---|---|
| Data audit | How many fields genuinely vary per row | Fewer than about five varying fields |
| Uniqueness rules | Whether the source can satisfy the rules | Rules cannot be met by the data |
| Sample of twenty pages | Whether a reader could distinguish them | Pages read as near-duplicates |
| First batch index rate | What share of the batch got indexed | Index rate well below expectation |
| Later batch index rate | Whether the rate is holding | Rate falling as the source thins |
I treat each row as a place the project can honourably stop. Most builds have no gates at all, which is why they discover the problem at launch.
Building without stage gates is driving without checking the fuel gauge. The journey works right up until it does not, and always at the worst point.
The final row matters on large sources. Data quality usually varies across a source, so a rate that held on batch one can fall on batch four.
How a System Build Runs
I work through stage gates rather than straight through to launch.
- Audit the data source and count the fields that genuinely vary between rows.
- Report the honest page count the source supports, which is often far below the row count.
- Define the uniqueness rules, and confirm the source can actually satisfy them.
- Design the template so markup, internal links, and metadata generate with the page.
- Build the publishing layer, including the route back out for pages that need removing.
- Generate a sample of twenty pages and read them side by side.
- Stop the project at the sample gate if a reader could not distinguish the pages.
- Publish the first batch and check the index rate before releasing anything further.
- Publish in batches, checking index rate at each one rather than at the end.
- Monitor index rate over time, since a falling rate signals the source running thin.
How This Engagement Is Scoped
I scope system builds by data richness and by the number of page types.
- What arrives
- A data audit, uniqueness rules, a template, a publishing layer, and index rate reporting per batch.
- Typical duration
- Eight to sixteen weeks, with the data audit delivered in the first two.
- What the client supplies
- The data source, platform access, and subject review of the sample batch.
- Included
- Audit, rules, template, publishing layer, batch releases, and monitoring.
- Not included
- Building or enriching the data source, which is scoped separately.
- What changes the estimate
- Sources needing cleaning, several page types, or a headless front end.
- How it is quoted
- After the data audit, since the audit determines what is worth building.
Tools and Primary Sources
The references below cover the policy and the reporting. Each opens in a new tab.
- Google spam policies defines scaled content abuse, which a thin source will produce regardless of engineering quality.
- Search Console Page Indexing report reports the index rate each batch gate is checked against.
- Search Console API returns per-URL performance data at a volume the interface cannot show.
- BigQuery is where reporting joins sources and exceeds interface row limits.
- Google structured data introduction documents the markup a template generates with each page.
Common Questions
How large does a catalogue need to be to justify a system?
Roughly 50 pages is where a build starts paying back, because below that hand-writing costs less than the system. Value rises sharply past a few hundred pages.
Can the system update pages when the source data changes?
Yes. A system connected to a live data source can regenerate affected pages on a schedule, which keeps prices, stock states, and specifications current without manual editing.
Who owns the system afterwards?
The client owns the build. Code, templates, and prompts get delivered with documentation so an internal developer can run and extend the system.
What makes a data source good enough for a content system?
Enough fields that genuinely vary between rows to support content a reader would find different. Row count is close to irrelevant, and per-row difference is what decides everything.
Discuss This Work
The first call is a free 30-minute consultation with no pitch attached. You receive an honest assessment of where the site stands and what can realistically be built.