Content and Editorial
Content production at volume
One part of Content and Editorial, described on its own: publish a lot without publishing the same page forty times.
Content production at volume, defined
Publish a lot without publishing the same page forty times. In practice that means research per page rather than per project, which is what makes bulk pages genuinely different from one another, and then the harder half: a writing standard that survives being scaled: facts stated once, claims attributed, numbers with their sources.
Why this work exists
This is the piece teams assume somebody else is handling. Usually nobody is.
It sits inside Content and Editorial, which is the broader discipline, and it is the part people most often ask for by name.
The nearest piece of work to it is publishing who is responsible rather than which tool was used. Where that is already handled, this moves faster than the estimate; where it is not, the two get done together or neither of them holds.
What good looks like
Success looks like fewer meetings about this, not more reporting on it.
The gap between that and where most accounts start is why this is scoped as content production at volume rather than as a line inside something larger. Deciding what this business is actually qualified to write about is the usual second step once it is in place.
When this is the right work
What tells you to start here:
- You need hundreds of pages and dread what they will read like
- Your existing bulk pages are the same page with a place name swapped
- Production outpaced review months ago
If none of those is true, something else is probably the constraint, and the Content and Editorial overview maps the alternatives. The usual neighbours are finding the page that gets traffic and convinces nobody and building a calendar from what sales get asked rather than from a keyword tool.
What the work covers
The scope, stated plainly:
- Research per page rather than per project, which is what makes bulk pages genuinely different from one another. Usually scoped at half the size it turns out to be.
- A writing standard that survives being scaled: facts stated once, claims attributed, numbers with their sources, done before anything downstream is committed to.
- Overlap measurement between sibling pages, so near-duplication is caught before publication rather than by a search engine. Usually scoped at half the size it turns out to be.
- Review built into the schedule rather than appended to it, done before anything downstream is committed to.
How it runs
What happens, in the order it happens.
Handing it over
Whatever is left running ends up with a named owner and a schedule, or it stops happening within two months.
Agreeing the measure
The number this will be judged on is fixed before the work starts. Agreeing it afterwards is how both sides end up disappointed.
Finding the constraint
Most of the available gain sits in one or two places. The first job is working out which, rather than improving everything by a little.
What each part runs into
Where each part tends to meet resistance:
- Research per page rather than per project, which is what makes bulk pages genuinely different from one another, where a Houston engagement contends with an enquiry path that runs through a messaging app rather than a form
- A writing standard that survives being scaled: facts stated once, claims attributed, numbers with their sources – working in Sydney this means accounting for a catchment smaller than the ambition on the website
- Overlap measurement between sibling pages, so near-duplication is caught before publication rather than by a search engine, and in Kota the constraint on it is an incumbent whose position comes from presence rather than effort
- Review built into the schedule rather than appended to it, harder in Mumbai because of a buying pattern that resolves faster than the reporting cycle
The trap
Scaling production before review capacity. The queue gets cleared by reviewing less, and the clean-up costs more than the pages were worth.
It is the reason this work sometimes looks like it does not work.
How it is measured
Shingle overlap between sibling pages, and the share of published pages a reviewer signed off. That measure is agreed before the work starts, so there is no argument about the result afterwards.
Two people should be able to calculate it independently and get the same answer. If they cannot, it is the wrong measure.
What you end up with
What gets handed over: a production system with a measured distinctness check, and pages that pass it before they ship.
It is yours, in a format you can edit, whether or not the engagement continues.
How it differs by sector
The sector decides what the constraint actually is:
- In Nonprofit and NGO the binding constraint is that two audiences with nothing in common: donors and the people served.
- Legal and professional services: the thing that changes the scope here is that high-value, high-intent local search under advertising rules that vary by jurisdiction.
- For Education and training, admission cycles, a parent paying for a student’s decision, and course-level demand. and that shapes how far this can go.
The industry pages carry the rest of that detail. Nonprofit and NGO and Legal and professional services are the two where this piece of work most often decides the outcome.
Common questions
How do you stop bulk pages reading the same?
Give each page something only it can say, which means research per page. Everything else is rearranging the same sentences.
What is an acceptable similarity between similar pages?
We hold sibling pages below thirty per cent on a five-word overlap measure, and we check it rather than assume it. The evidence is in Kota. The argument about what it means is in Leeds.
What do we actually get at the end?
A production system with a measured distinctness check, and pages that pass it before they ship. Documented, so it survives whoever was in the room, and specific enough to act on without a follow-up conversation. This connects directly to Automotive, and less obviously to B2B services.
What if this is not our problem?
Then we say so. The signals on this page are the honest filter, and work sold against the wrong diagnosis wastes a quarter. For the decision, Website Design and Development. For the implementation, Agentic Commerce.
What could go wrong with this work?
The usual risk is acting on a finding before it is solid. The diagnostic phase exists to avoid that, and where the data is too thin to be conclusive we will say so rather than proceed. Two pages carry the detail this one summarises: Server-side rendering or Client-side rendering, and then Subdirectory or Subdomain.
Ask about content production at volume
Send the site and the symptom. The reply names the first thing we would look at and why.
Get a straight answer before you commit
We would rather tell you the work is not worth the money than take it and report on activity.