The temptation when launching a new directory site is to start writing immediately. Resist it. The cost of onboarding a site badly is not one bad page, it is hundreds of pages that all inherit the same broken template, the same missing schema, or the same muddled cluster plan. Onboarding is the cheapest moment to get the foundations right, because every page that follows is built on them.
This is the practical sequence we follow when a property joins the production model. It assumes you already understand the wider system, so if you have not read it, start with the content operations pillar and the content operations stack before you onboard anything.
Step one: agree the cluster plan
Before any tooling, you settle what the site is actually about. A directory site is not a pile of pages, it is a small number of topic clusters, each with a pillar and a defined set of supporting articles. The onboarding job is to map those clusters, assign one primary keyword to each planned page, and order them so the most valuable, most defensible pages come first.
This is where you enforce the one keyword to one page rule from the very beginning. It is far easier to prevent two pages competing for the same search than to untangle them after both are live. The output of this step is a queue: an ordered list of rows, each with a title, a keyword, an intent, a cluster, and a named author.
Step two: wire the template and builder
Every site in the model uses a template supplied by the operator, applied without alteration. Onboarding is where you confirm that template renders correctly: the navigation, the footer line, the newsletter form posting to the right endpoint, the breadcrumb, the author card, and the full SEO head with canonical tag and structured data. You do this once, centrally, so that every page the builder produces is correct by construction.
The reason we automate the build rather than assemble pages by hand is consistency. A builder cannot forget the canonical tag or the last reviewed date. It applies the same head and the same schema to page one and to page five hundred. During onboarding you verify the builder against the new site's paths and confirm the output validates. Get this right and an entire class of technical defects simply never appears.
Step three: load the queue
With the cluster plan agreed, you load it into the production queue as real, ordered rows. Each row carries everything the brief layer needs to begin: the title, the keyword, the intent, the cluster, the funnel stage, and the assigned author. A loaded queue is what lets work flow without anyone stopping to ask what comes next.
We deliberately load more than the first run will consume. A queue that runs dry mid week is a queue that causes idle handoffs. Loading depth up front means the planning layer can stay ahead of drafting without constant attention.
Step four: assign credentialed authors
Every page needs a named, real author with a genuine credential and an author page. During onboarding you confirm the roster: who writes which clusters, and whether their expertise actually matches the subject. This is not a formality. The author is the reason a page can be trusted, and assigning the wrong author to a cluster is a quality defect you will pay for in every page they touch.
Set up the author pages with proper Person schema as part of onboarding, not as an afterthought. A page that links to a real author who links back through structured data is doing the trust work that a faceless page cannot. This is the backbone of the whole approach, and it is worth the time.
Step five: run the first two pages end to end
Here is the rule that saves the most pain. Before you open the queue to volume, push exactly two pages through every single layer: planning, brief, draft, build, and review. Do not write twenty drafts and then discover the template is broken. Take two pages all the way to a clean review pass first.
Those two pages are your proof that the whole pipeline works on this site. If the builder mangles a path, you find it now, on page two, not on page two hundred. If the cluster plan produces a brief that fights itself, you catch it before the queue has multiplied the error. We call this the First Two Pages rule, and it is the single highest leverage check in onboarding. Once both pages pass review cleanly, and only then, you open the queue to full volume.
Step six: confirm the review loop and freshness
Onboarding is not finished when the first pages publish. You confirm that the review layer is scheduled, that pages carry a last reviewed date, and that there is a clear path for a page to come back around. A site that has no freshness loop will slowly rot, and the time to install that loop is at the start, while the site is small enough to reason about.
You also confirm the internal link graph is wired so no page is born an orphan. Every new page links up to its pillar and across to siblings, and the pillar links down to its children. Establishing this habit during onboarding means you never have to run an expensive orphan cleanup later. For the measures that tell you the loop is healthy, see the content factory metrics.
What good onboarding feels like
When a site is onboarded well, the first month is quiet. Pages move through the layers without drama, the builder produces correct output every time, reviews pass on the first read, and nobody is firefighting template bugs. That quiet is not luck. It is the dividend of doing the setup before the scaling.
When onboarding is rushed, the opposite happens. The team writes fast, then spends weeks reworking pages because a decision that should have been made once, at the start, was instead made differently on every page. Onboarding is the moment to be slow so that production can be fast. It is the same philosophy that runs through our wider portfolio: get the foundation right and let volume take care of itself.
Onboard deliberately, prove the pipeline on two pages, and only then open the taps. A site that joins the factory this way starts producing trustworthy pages on day one and keeps producing them long after launch.
Kings Hospitality Group runs a First Two Pages rule when onboarding any site: we push two pages through every layer end to end before opening the queue to volume. Directionally, this single rule catches the large majority of template and process defects while they are still cheap to fix.
Common questions
How long should onboarding a new site take?
Plan for a short, focused setup rather than a fixed number of days. The work is done when two pages have passed review cleanly and the queue is loaded. Rushing past that point is how defects scale.
Can you reuse a stack across very different sites?
Yes, the layers and handoffs stay the same. What changes per site is the cluster plan, the author roster, and the template the operator supplies. The operating model travels well.