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 your dataset can make almost any template look good. We design for the awkward records too (sparse, long, duplicate, multilingual, and simply not good enough to publish).

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

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.

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

    AI assist
    The approved opportunity data gets scanned for every distinct record class and intent the template might have to serve.
    Human gate
    The product owner settles which single audience decision the page exists to answer, and where the other intents get routed. Single-intent charter sign-off

  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 content contract where missing truth leads to omission, hold, or another module (never confident filler).

    AI assist
    It can populate private prototypes from the approved fields and flag every module that renders empty, repetitive, or inconsistent with its stated rule.
    Human gate
    A person decides the actual empty-state behavior for each field, omit, hold, or reroute. Field-rule and fallback approval

  3. Assemble the page in semantic order

    We map fields into headings, summaries, evidence blocks, comparisons, links, media, actions, disclosures, and responsive states.

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

    AI assist
    It can compare hundreds of field-to-module arrangements at once and flag any sequence that breaks for a screen reader or a narrow viewport.
    Human gate
    A person decides the final reading order and which disclosures or comparisons actually belong on this page. Semantic anatomy walkthrough

  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 prototype set that exposes bad assumptions before they become production rules.

    AI assist
    It can render the full battery of hostile records, sparse, duplicate, stale, multilingual, prohibited, across device and assistive states faster than a person could stage them by hand.
    Human gate
    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. Hostile-record prototype review

  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.

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

    AI assist
    Template branches that keep needing a one-off patch across the prototype run get flagged, which points at the recurring pattern behind the individual incidents.
    Human gate
    Either that pattern becomes an explicit rule or the branch comes out of the template. Somebody has to choose. Template acceptance sign-off

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

    Accepted when

    Defines page purpose, semantic sequence, field-to-module mapping, responsive states, internal links, disclosures, and prohibited combinations.

  • Decision matrix

    Content & fallback contract

    Accepted when

    Every field has a source, type, owner, validation rule, localization behavior, length limit, and honest empty state.

  • Evaluation sheet

    Template eligibility rules

    Accepted when

    Representative records receive inspectable pass, hold, enrich, consolidate, reject, or expire outcomes.

  • Brief

    Edge-case prototype pack

    Accepted when

    Covers complete, typical, sparse, long, duplicate, stale, multilingual, sensitive, error, and prohibited states with reviewer decisions.

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

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.