Design the layout of generated pages

Design generated pages from your worst row of data. Most templates look great in the mockup because the mockup uses the best example in the database, then break on the row with a 60-character name, no image and two lines of content.

Say you are building integration pages for a SaaS product called Acme: one page per app it connects to, 400 pages in all, from “Connect Slack to Acme” to apps with far less information available. The structure itself comes from the zoning chapter. This chapter is about turning those zones into a layout that survives real data.

Start with what changes from page to page

Put two generated pages side by side and cover everything that comes from a variable. Whatever is left is your fixed template. If what is left takes up most of the screen, you have a thin page problem that no amount of styling will fix, and Google’s scaled content abuse policy exists for exactly this pattern: many pages, little value of their own.

So the layout should give its most visible space to the data that differs. On our integration page, the fixed marketing paragraph about Acme goes low on the page. The top goes to what is specific to that app: what can be automated with it, how long setup takes, what a real workflow looks like.

The same test applies to AI answers. A system summarizing your page can only reuse facts that are specific and clearly placed in the text.

Stress-test every variable before drawing the module

For each field, write down the extremes and decide the behavior in advance. I do this in a table before opening a design tool.

Field	Short case	Long case	If absent
App name	Jira	Microsoft Dynamics 365 Business Central	Page is not generated
Intro text	180 characters	900 characters	Page is not generated
Automations list	2 items	40 items	Hide the section, heading included
Screenshot	Wide	Tall and narrow	Show a fixed-ratio illustration
Video tutorial	1 minute	30 minutes	Hide the section
Customer quote	1 line	6 lines	Hide the section

The “if absent” column is the one that matters. A heading sitting above nothing is the signature of a badly generated page. Each optional module needs its own condition, and required fields need a rule that stops the page from being published at all.

Build modules with conditions

In component form, a conditional module is a few lines. This example is in Astro, and the logic is the same with Webflow conditional visibility or a WordPress template.

---
const { app } = Astro.props;
---
<section class="hero">
  <h1>Connect {app.name} to Acme</h1>
  <p>{app.intro}</p>
  <a class="cta" href={`/signup?from=${app.slug}`}>Try it with {app.name}</a>
  <img
    src={app.screenshot}
    alt={app.screenshotAlt}
    width="1200"
    height="675"
    fetchpriority="high"
  />
</section>

{app.automations.length > 0 && (
  <section>
    <h2>What you can automate with {app.name}</h2>
    <ul>
      {app.automations.map((item) => <li>{item.label}</li>)}
    </ul>
  </section>
)}

Three small CSS rules handle most variable content:

.hero h1 {
  font-size: clamp(1.75rem, 4vw, 3rem);
  overflow-wrap: anywhere;
}

.hero img,
.video-frame {
  aspect-ratio: 16 / 9;
  width: 100%;
  height: auto;
  object-fit: cover;
}

.quote p {
  max-width: 65ch;
}

The clamp() keeps long titles from taking over a phone screen, overflow-wrap stops long words from breaking the layout, and the fixed aspect ratio reserves space before images load.

Keep the important content high and the visitor on track

The H1 must be visible immediately and say what the page is about using the variable. The main content should start above the fold on both desktop and mobile, with no full-screen banner pushing it down. Then give each template one primary action and strip out what competes with it. On a generated landing page, a mega menu and three different offers will mostly send people away from the one thing they came for.

Navigation still needs to be clear, and the related links should be real, styled links rather than an afterthought in the footer.

Speed is a template decision

Every performance fix you make on a template applies to all 400 pages, which makes this the highest-return optimization work on the project. Speed will not rescue weak content, but a slow template penalizes every visitor on every page.

Google’s Core Web Vitals give you three targets at the 75th percentile of real visits: Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint within 200 milliseconds, Cumulative Layout Shift below 0.1. They map directly onto layout decisions.

For LCP, identify the largest element at the top of the template, usually the hero image or the H1, and make sure it loads first. Lazy loading is right for images and videos further down, and wrong for that hero image, which is why it has fetchpriority="high" above and no loading="lazy".

For CLS, always declare width and height or an aspect ratio on images, and reserve room for anything injected late. Variable content makes this worse than on hand-built pages, because one row’s text may be three times longer than another’s.

For INP, defer whatever is not essential: chat widgets, heatmap scripts, consent tools loaded carelessly, third-party embeds.

Video is the usual offender. I integrated videos into the Derrick pages, and video is worth having because it adds something specific to each page. Just avoid loading a full player on arrival. Show a thumbnail with a real button, and create the iframe when the visitor clicks. If you do embed directly, at least set loading="lazy" on the iframe.

Mobile and accessibility, on the generated output

Google indexes the mobile version of your pages, so anything you remove on small screens is removed for search as well. Hide decoration if you like, and keep the content.

Accessibility has real SEO overlap and is simply how a usable page gets built. On templates, watch for the problems that data introduces:

• alt text must come from a real description column. An alt that reads “image” on 400 pages, or a stuffed list of keywords, helps nobody.
• Headings should follow the order of the page, including when a module disappears.
• Link text must make sense alone, so “Try it with Slack” beats “Click here”.
• Color contrast must hold when a brand color comes from the database. Text placed on a per-app color needs a computed or fixed foreground.

The HTML markup chapter goes through the semantic structure in more detail.

Test on bad rows and real visits

Lighthouse is a lab test and a good one for catching problems during development. Run it on the row with the heaviest page, as well as the prettiest. Field data then tells you what visitors actually get, and Search Console’s Core Web Vitals report helps a lot here because it groups similar URLs together, which is close to how a template behaves. Pages with little traffic may not have field data of their own, so judge them through the group.

A Screaming Frog crawl surfaces what design choices can hide: thin templates, missing tags, duplicate titles, content that only appears after JavaScript runs. Microsoft Clarity or Hotjar then shows how people use the page. On a template, I look at whether visitors reach the CTA and which modules they scroll past, then change the module once for all pages.

Your next step: pick the three hardest rows in your database, usually the longest, the emptiest and the one with the strangest characters, and build your prototype with those. When that holds, move on to integrating and automating the template.