Zeo delivery method

Page Templates & Content Models

A template that produces a complete page from a strong record, fails honestly on a weak one, and leaves no empty-field behavior for engineering to invent.

The best record in a dataset can make almost any template look good, which is exactly why we design for the awkward ones, the sparse record, the duplicate, the one barely good enough to publish. We give every field a defined rule, assemble the page in semantic order, and try to break the template with real records before it ever meets a live one. You get a template that works when the data is strong, behaves honestly when it isn't, and knows when no page is the right answer.

Review the template with ZeoProgrammatic SEO
Two Zeo specialists assemble a large page template from labeled content blocks while thin and duplicate records wait outside the frame.

Some of the 500+ brands we've worked with

See all references
  • Acıbadem Sağlık Grubu
  • Kuveyt Türk
  • Watsons
  • Marks & Spencer
  • Sporjinal
  • Bernardo
  • Eureko Sigorta
  • Amazon
  • BMW
  • Shell
  • Hyundai
  • PepsiCo
  • Red Bull
  • Decathlon
  • MediaMarkt
  • Bayer
  • Sanofi
  • EY
  • KPMG
  • GE
  • 3M
  • Domino’s
  • Lexus
  • Trendyol

Stages and gates

How we do it

We define the decision the page must support before choosing components or modules.

  1. Define what this page must help someone do

    We turn the approved opportunity into one clear audience decision, then name the record classes, required truth, and no-page cases that belong around it. The product owner settles which single audience decision the page exists to answer, and where the other intents get routed.

    A template charter that prevents one URL pattern from trying to answer three different intents.

  2. Give every field a defined rule

    We mark fields required, conditional, optional, derived, localized, repeatable, or prohibited, with source, validation, ordering, and empty-state behavior. A person decides the actual empty-state behavior for each field, omit, hold, or reroute.

    A content contract where missing truth leads to omission, hold, or another module (never confident filler).

  3. Assemble the page in semantic order

    We map fields into headings, summaries, evidence blocks, comparisons, links, media, actions, disclosures, and responsive states. A person decides the final reading order and which disclosures or comparisons actually belong on this page.

    A template anatomy that makes sense to a reader, a screen reader, and the CMS implementing it.

  4. Try to break it with actual records

    We render complete, sparse, long, duplicate, stale, multilingual, sensitive, error, and prohibited records across device and assistive states. A person reviews each rendered failure and decides whether it reveals a genuine edge case worth a rule, or an assumption the template still gets wrong.

    A prototype set that exposes bad assumptions before they become production rules.

  5. Cut the paths that need constant rescue

    We turn legitimate recurring edge cases into explicit rules and remove template branches that only work after manual patching. Either that pattern becomes an explicit rule or the branch comes out of the template. Somebody has to choose.

    An accepted package with tests, exclusions, owners, and clear records that will never enter generation.

AI renders the awkward records at volume; people decide what the template promises.

AI scans the approved opportunity data for every distinct record class and intent the template might serve, populates private prototypes from the approved fields and flags modules that render empty, repetitive, or inconsistent with their stated rule, compares hundreds of field-to-module arrangements and flags sequences that break for a screen reader or a narrow viewport, renders the full battery of sparse, duplicate, stale, multilingual, and prohibited records across device and assistive states, and flags template branches that keep needing a one-off patch. The rules are ours to set. We do not write generic fallback paragraphs to conceal a record missing the facts the page promises, swapping adjectives or sentence order is not meaningful variation, and accessibility is tested before the template enters production rather than cleaned up after scale.

Deliverables and acceptance

What you get

You leave with an implementable content system built for actual, imperfect data.

  • Architecture map

    Template anatomy

  • Decision matrix

    Content & fallback contract

  • Evaluation sheet

    Template eligibility rules

  • Brief

    Edge-case prototype pack

We call it done when: The anatomy, content contract, eligibility rules, and prototype pack are done when page purpose, semantic sequence, field-to-module mapping, responsive states, internal links, disclosures, and prohibited combinations are defined, every field has a source, type, owner, validation rule, localization behavior, length limit, and honest empty state, representative records receive inspectable pass, hold, enrich, consolidate, reject, or expire outcomes, and the pack covers complete, typical, sparse, long, duplicate, stale, multilingual, sensitive, error, and prohibited states with a reviewer decision on each.

Fit and readiness

When you need this

A template is ready when difficult records receive outcomes that are as deliberate as those for ideal records.

A good fit when

  • The opportunity and entity model is approved, and you need to turn source fields into a reusable page without forcing every record into the same narrative.
  • Before generation starts, you need explicit rules for missing, long, stale, multilingual, sensitive, and duplicate data.
  • Content, design, accessibility, and engineering teams need one shared contract for what each module can display.

Better handled as other work when

  • The available fields are too sparse or repetitive to support a meaningfully useful page.
  • No one owns source truth, editorial rules, accessibility, localization, or template exceptions, so the method cannot settle how the template should behave.

If one of these is closer to your situation, start here instead: Programmatic SEO

We call it done when: A strong record produces a complete page, a weak record fails honestly, and engineering can implement every empty-field decision without inventing behavior.

The specialists behind this SEO work

Zeo's SEO work goes back to 2006, when we started what we call the first SEO blog in the MENA region. The consultants shown here are doing that work today, matched to what this page covers.

Tools we use

Tools behind this work

  • Screaming Frog

    renders hostile records and exports every field-level template failure

  • Sitebulb

    maps template failures back to components and record classes

  • Schema App

    validates structured data across complete and incomplete record states

  • PageSpeed Insights

    checks whether difficult content states damage template performance

  • Copyscape

    checks whether different records produce materially repeated page copy

  • Weglot

    exposes localization gaps in fields, fallbacks, and page structure

Next step

Test the template with the hardest records

Send the entity model, and pick out several records you do not trust. Those are the ones that will tell us whether the template is ready.
Review the template with Zeo

Before we start

Questions we hear

What happens when a required field is missing?

The field contract decides. We may hold the record, send it for enrichment, omit an optional module, consolidate it elsewhere, or choose no page. Generated filler is not one of the options.

How many records should the prototype cover?

There is no universal number. The set must cover every meaningful field, cohort, language, component state, and failure mode. Ten carefully selected hostile records may reveal more than a hundred ideal ones.

Can AI design the template directly from the data?

Profiling fields, populating prototypes, comparing outputs, and spotting repetition. It does not define the page purpose, approve a claim, waive accessibility requirements, or invent behavior for missing facts.

What if our design team already has a template they like?

We test it against the same hostile records (sparse, duplicate, stale, multilingual. If it holds up, we keep it and write the field contract around it. If a specific module breaks on actual data, we tell you which one and why rather than replacing the whole design).