One-Time Content Seeders That Respect Later Edits

Sometimes the best way to deliver a website is through code. When we rebuilt the Jag Journey site inside our own content system, every page, menu, theme setting and redirect was written as data and published by a script. The same is true of this blog's article library. Doing it in code means the work is reviewed, repeatable and released through the same pipeline as everything else.

But content is different from code in one crucial way: once it is live, the owner will edit it. A script that runs again later and resets their changes would be a disaster. So our content seeders follow a few strict rules.

Rule 1: Run once, through a migration

Our content seeders run from a database migration. Migrations run exactly once per environment, in order, as part of a release. That gives us a recorded moment when the content arrived and guarantees it does not run again on the next deploy.

Rule 2: Check the address before doing anything

Before a seeder writes a single row, it confirms it is looking at the right account and the right website. It checks the account's identifier, its expected name and status, and the specific website within it. If anything does not match, the seeder stops with an error rather than guessing.

That matters in a platform where many customers share one database. A seeder that assumed the wrong account could publish someone else's content into a stranger's site.

Rule 3: Scope every write explicitly

Data seeders run outside a normal web request, so the automatic filters that keep each customer's data separate may not be active. Our seeders never rely on them. Every lookup and every insert names the account and the website explicitly. Every "unset the old default" step is limited to that one account.

Rule 4: Never overwrite later edits

The heart of a respectful seeder is restraint. Ours use a few techniques:

• Skip what exists. If an article with the same address already exists, the seeder leaves it alone.
• Fill only missing settings. Settings the owner has already saved are not touched.
• Stop early when the work is done. If a marker of the finished build exists, such as the site's theme, the seeder exits without changes.

These rules mean a seeder can safely be part of history. If it ever ran again, it would add only what is missing.

Rule 5: Use the same paths as the admin screens

A seeder should create content the same way a person would. Our seeders save pages through the same content store the visual editor uses, so revisions are recorded. Images go into the same media library, so the owner can find and reuse them. People are added to accounts through the same membership service the admin uses. That keeps seeded content indistinguishable from content created by hand.

Rule 6: Leave the old content recoverable

When a seeder replaces old pages, it moves them to the trash rather than deleting them. Our trash keeps items restorable for a period of time, and old addresses are redirected to their new homes so visitors and search engines are not stranded. You can read more in keeping old links alive with redirect maps.

Rule 7: Prove it before it ships

Because a seeder runs during a release, a mistake in it can stop the release. So we check seeders before they ship: a syntax check against the same language version production runs, and a dry run that converts the real source content in memory and prints a summary without saving anything. Only when both look right does the seeder go out.

Why go to this trouble?

Because content is the customer's, even when we create it for them. A seeder that respects that boundary lets us deliver whole websites quickly through a reviewed process, and then hand the keys over completely. It is the same respect for ownership you will find across VoVo.

Frequently asked questions

What is a database seeder?

A seeder is a script that inserts data, such as pages, settings or sample records, into a database. Ours run once as part of a release and are written to protect existing content.

Why use a migration instead of running the seeder by hand?

A migration runs exactly once per environment, in order, as part of the reviewed release. Running a script by hand on a server would bypass review and leave no clear record.

What happens if a seeder finds unexpected data?

It stops with a clear error rather than guessing, so the release fails safely and the situation can be checked before anything is written.