Template design: turning data into genuinely useful pages

Transcript of the narration, chapter by chapter.

0:00 Template design

A programmatic page template isn't an SEO container. It's a product decision that gets multiplied by a thousand. Get it right and every page helps someone. Get it wrong and you've published a thousand problems at once. In this lecture you'll learn the anatomy of a strong programmatic page, how conditional logic and quality gates make pages adapt to their data, how to write the text parts responsibly, and the rendering and performance rules that matter.

0:33 Why it matters

Why does this matter? Because a template decision is multiplied by every page in the system. A small improvement helps thousands of pages, and a small mistake harms thousands. Here's an analogy. A template is like a form at a government office. If the form asks the right questions in the right order, every application goes smoothly. If it's confusing, every single applicant struggles. Design the template once with care, and every page inherits that care.

1:06 Page anatomy

Start with the user's question for the pattern, then design blocks in order. Answer first: satisfy the query immediately, like how many verified tutors, the typical rate range, and the next available slot. Then the primary data module: the listing, table or calculator. Then computed insight, what the data means. Then guidance to help the decision. Then trust and methodology: how data is verified and when it was updated. Then related navigation, the conversion action, and an FAQ built from real questions.

1:42 Conditional logic

Now the secret to avoiding near-duplicates: conditional logic. Show a price trend chart only when there are enough data points. When inventory is below your threshold, show a helpful notify-me module and set the page to noindex. Vary insight sentences based on real comparisons, above or below average, rising or falling. And include local notes only where they actually exist. Pages should differ because their data differs.

2:11 The Jinja example

The lesson includes a Jinja template that does exactly this. It checks whether there are at least eight tutors and sets the robots tag accordingly. It writes an answer-first sentence from counts, rate percentiles and next availability. It adds a comparison sentence only when the national comparison exists, citing the number of bookings behind it. And it includes local notes only for cities that have them. Keep thresholds and statistics in the data layer, and presentation in the template.

2:45 Simple example: 'plumber in Jumeirah' (illustrative)

Here's a simple worked example of answer-first design. Someone searches plumber in Jumeirah. Version one of the page opens with three paragraphs about the importance of reliable plumbing. Version two opens with: fourteen verified plumbers in Jumeirah, typical call-out fee range, and three available today. Then the list, filterable by emergency service and language spoken. Then a short guide on what to ask before booking. Version two answers the question in the first line, shows unique data immediately, and gets the user to the action faster. Same keyword, same site, completely different experience.

3:25 Writing the text

How should the text be written? Three kinds. Data-driven sentences generated from computed fields, which are accurate by construction. Evergreen guidance written once by an expert per page type or meaningful segment, like per subject, kept short and supportive of the data rather than duplicated filler. And AI-assisted text only where it adds meaning, like summarizing reviews for this specific entity, always with human quality checks.

3:54 Rendering and performance

Rendering matters. Server-side render or statically generate pages, so the main content is in the HTML, not loaded later by JavaScript. Meet Core Web Vitals: loading, interactivity and layout stability. Long lists need pagination or load more with crawlable links. And build accessibility in: headings in order, proper table markup, text alternatives for charts, and right-to-left support for Arabic pages.

4:20 Example: Jeddah restaurants (illustrative)

Here's an illustrative example. A Jeddah restaurant directory with cuisine in district pages. Answer first: how many restaurants, price bands, and which are open now. Then a map and list with halal certification status, family sections and delivery options. Computed insight like most popular for late-night dining, based on reservations. Methodology and last updated. Related districts and cuisines. And districts with fewer than six listings show a notify-me module and stay out of the index.

4:53 Pitfalls and metrics

Three pitfalls. Templates where ninety percent of the text is identical across pages. Main content loaded only by client-side JavaScript. And inconsistent behavior, like hiding thin pages from users but not from crawlers. Measure template versions on engagement, scroll depth, interactions and conversions, keep similarity scores within threshold, pass Core Web Vitals, and watch user error reports decline.

5:18 Mistakes + try this now

Common template mistakes. Ninety percent identical text across pages. The main data loaded by JavaScript after the page renders. Ignoring right-to-left layouts for Arabic pages. Huge lists with no pagination. And no conditional logic, so thin pages look like broken rich pages. Try this now: sketch your template on paper as a stack of boxes from top to bottom. Next to each box, write the data field that fills it and what happens when that field is empty. Any box without an empty-state rule is a thin-page risk.

5:56 Quick self-check

Quick self-check. Your template shows a price trend chart on every page, but for small areas it's based on only three data points and swings wildly. What should the conditional rule be? Pause. Show the chart only when there are enough data points to be meaningful, say a minimum number of transactions over a defined period that you calibrate, and otherwise show the current range without a trend. A misleading chart is worse than no chart, because users and AI systems may repeat it.

6:33 Watch me do it: venue template redesign (illustrative)

Watch me do it. Let's redesign one illustrative template for a Karachi wedding venue directory, block by block. The current page opens with a hero image and three paragraphs about weddings in Karachi. Step one, answer first: I replace that with a summary generated from data, twenty-three venues in Clifton, capacity from one hundred and fifty to one thousand guests, per-head price range, and how many have dates free next month. Step two, the primary module: a filterable list with capacity, separate family and ladies' sections, catering in-house or outside, parking, and verified photos. Step three, computed insight: most bookings in this area are for events over five hundred guests, calculated from our enquiries. It only appears when there are enough enquiries. Step four, guidance: a checklist written by our events team, what to confirm about generator backup, parking and catering permits. Step five, trust: last verified dates per venue and a methodology link. Step six, conversion: check availability for your date. Step seven, the empty state: areas under five venues show notify me and carry noindex. Same keyword, but now every block earns its place.

7:54 Recap and next step

Recap. Design the template from the user's question, answer first. Use conditional logic and quality gates so pages adapt to their data. Generate accurate sentences from data, write expert guidance once, and use AI only where it adds meaning. Render in HTML, fast and accessible. Your next step: sketch the template for one page type, with blocks in order, the data field behind each, the conditional rules, and your noindex threshold.

A template is a product decision

The template determines what every page in the system says and does. Design it like a product page, not an SEO container: start from the user's question for the pattern, then decide which data answers it, in what order, with what interaction.

Anatomy of a strong programmatic page

Block	Purpose	Example (tutors in [subject] in [city])
Answer first	Satisfy the query immediately	Count of verified tutors, rate range, next availability
Primary data module	The core listing/table/calculator	Filterable tutor list with ratings, languages, online/in-person
Computed insight	What the raw data means	"Rates in Lahore are typically lower than Karachi for O-Level Physics" (computed from bookings)
Contextual guidance	Help the decision	How to choose a tutor; questions to ask; typical session lengths
Trust and methodology	Why believe it	How tutors are verified; data freshness; review policy
Related navigation	Next steps and discovery	Nearby areas, related subjects, levels
Conversion	The action	Book a trial lesson
FAQ from real questions	Remaining doubts	Pulled from support tickets and on-site search

Conditional logic: pages should not all look the same

Use conditional blocks so content adapts to the data:

Show a price-trend chart only when there are enough data points.
Show "no providers yet — get notified" and noindex when inventory is below threshold.
Vary insight sentences based on computed comparisons (above/below average, rising/falling).
Include local rules or notes only where they exist.

Hands-on: a Jinja2 template with quality gates

{# templates/tutors_city.html.j2 #}
{% set enough = tutors|length >= 8 %}
{% if not enough %}{% set robots = "noindex,follow" %}{% else %}{% set robots = "index,follow" %}{% endif %}
<meta name="robots" content="{{ robots }}">
<h1>{{ subject.name }} tutors in {{ city.name }}</h1>
<p class="answer">
  {{ tutors|length }} verified {{ subject.name }} tutors in {{ city.name }}.
  Typical rate: {{ stats.p25_rate|money(city.currency) }}–{{ stats.p75_rate|money(city.currency) }} per hour.
  {% if stats.next_available %}Earliest trial: {{ stats.next_available|humandate }}.{% endif %}
</p>
{% if stats.rate_vs_country is not none %}
<p>
  Rates here are {{ "above" if stats.rate_vs_country > 0 else "below" }} the national median
  by about {{ (stats.rate_vs_country|abs * 100)|round|int }}% (based on {{ stats.bookings_n }} bookings in the last 12 months).
</p>
{% endif %}
{% include "partials/tutor_list.html.j2" %}
{% if city.local_notes %}<section><h2>Good to know in {{ city.name }}</h2>{{ city.local_notes|markdown }}</section>{% endif %}
{% include "partials/methodology.html.j2" %}

(This is template code for the rendering system; the page content itself is generated HTML.) Keep business logic (thresholds, stats) in the data layer and presentation in the template.

Writing the text parts

Data-driven sentences from computed fields (as above) — accurate by construction.
Evergreen guidance written once by an expert per page type or per meaningful segment (e.g., per subject), not duplicated verbatim across thousands of pages without reason; where shared, keep it short and supportive of the data.
AI-assisted variation only where it adds meaning (e.g., summarizing reviews for this entity), with human QA (Module 5).

Performance and rendering

Server-side render or statically generate pages so content is in the HTML — do not rely on client-side JavaScript to load the main data.
Meet Core Web Vitals (LCP, INP, CLS); large lists need pagination or "load more" with crawlable links.
Keep templates accessible: headings in order, table semantics, alt text for charts, RTL support for Arabic.

Worked example: a Jeddah restaurant directory

Template for "[cuisine] restaurants in [district]": answer-first summary (count, price bands, open now), map and list with halal certification status, family sections, delivery options; computed insight ("most popular for late-night dining based on reservations"); methodology and last-updated; related districts and cuisines. Districts with fewer than 6 listings show a notify-me module and are noindexed.

Pitfalls

Templates where 90% of text is identical across pages.
Main content loaded client-side only.
Hiding thin pages from users but not from crawlers (or vice versa) — keep behavior consistent.

How to measure success

Engagement per template version (scroll, interactions, conversions), similarity scores within thresholds, Core Web Vitals passing, and user feedback or error reports declining.

Template design: turning data into genuinely useful pages