A solid landing page builder data model starts with six core entities: pages, sections, blocks, assets, forms, and versions. Get those right, and features like drag and drop editing, publishing, A/B testing, reusable components, and analytics become much easier to build. Get them wrong, and every button style, form field, or image swap turns into a migration headache.
TLDR: A landing page builder needs a clean schema where each page owns ordered sections, each section owns blocks, and shared assets live outside the page tree. For example, a SaaS team running 50 campaign pages might cut editing time by 35% if reusable blocks and version history are modeled from the start. A user can update one testimonial component, publish it to 12 pages, and still roll back a single page if conversions drop from 8.4% to 6.9%.
The Core Entity Model
At the center sits the Page. It represents a complete landing page with a URL, title, status, metadata, and publishing rules. A page rarely stores all visible content in one large field. That approach feels simple at first, then ruins search, reuse, testing, and permissions.
A better model breaks the page into ordered parts:
- Page: the top-level object, such as “Spring Sale Signup.”
- Section: a major layout area, such as hero, pricing, FAQ, or footer.
- Block: a smaller content unit, such as headline text, button, image, form, video, or quote.
- Asset: uploaded media, including images, icons, PDFs, and videos.
- Form: a lead capture structure with fields, validation, and integrations.
- Version: a saved snapshot used for drafts, approvals, previews, and rollbacks.
This layered model mirrors how editors think. They do not “edit JSON.” They move a pricing section, swap a CTA button, or hide a logo strip. The database should support that mental model.
Pages: The Publishing Anchor
The Page table should hold information about ownership, routing, visibility, and lifecycle state. Typical fields include id, workspace_id, slug, title, status, created_by, published_at, and canonical_url.
Status values matter. A simple draft, published, and archived setup works for smaller tools. Larger teams may need review, scheduled, or paused. The catch is that publishing rules become messy if page state and version state are mixed. Keep them separate.
A page should point to its active published version. Editors can then work on a draft version without changing what visitors see. This single design choice prevents a surprising number of late-night “why did the homepage change?” incidents.
Sections and Blocks: Ordered, Nested, and Reusable
Sections define layout regions. They need order, visibility rules, style references, and sometimes device-specific settings. Fields might include page_version_id, section_type, sort_order, settings_json, and is_hidden.
Blocks sit inside sections. A block may store text, reference an asset, connect to a form, or define a button action. Blocks also need order. If your builder supports columns, grids, or containers inside containers, you may need a parent-child relationship on blocks.
There are two common schema options:
- Strict tables by block type: separate tables for text blocks, image blocks, form blocks, and button blocks.
- Flexible block table: one block table with a type column and a structured settings_json field.
The strict model gives stronger validation and cleaner queries. The flexible model ships faster and supports new block types with fewer migrations. Honestly, it feels like every builder starts flexible, then slowly adds stricter rules after one editor pastes invalid style data and breaks 300 pages.
Assets: Shared Files Need Their Own Home
Assets should not be buried inside block records. Store them as first-class entities. An Asset record can include filename, MIME type, dimensions, file size, storage path, alt text, owner, and usage count.
This makes it possible to answer basic but useful questions:
- Which pages use this image?
- Can this file be safely deleted?
- Which images are missing alt text?
- Which assets are larger than 500 KB and slowing load time?
Performance is not abstract here. A landing page that loads in 2.1 seconds may convert much better than the same page loading in 4.8 seconds. If asset data is organized, the builder can flag bloated images before publish, not after ad spend gets wasted.
Forms and Submissions: Separate Structure from Data
Forms are often more complex than they look. A form has fields, validation rules, hidden values, spam settings, consent copy, and post-submit actions. Then it has submissions, which may contain personal data.
Keep Form, FormField, and Submission separate. A form field describes what should appear. A submission stores what a visitor sent. This avoids painful problems when someone edits a form after 2,000 leads have already arrived.
A clean relationship may look like this:
- Form has many FormFields.
- Form has many Submissions.
- Submission has many SubmissionValues.
- Block may reference one Form.
This also helps with privacy controls. You can delete or anonymize submission data while keeping the landing page design intact.
Versions: The Safety Net Editors Expect
Versioning is not a luxury. It is basic survival for any serious builder. Editors expect previews, approvals, scheduled publishing, and rollback. Designers expect experiments. Managers expect audit trails.
A PageVersion can store a snapshot of all sections and blocks for one saved state. Some systems copy rows into versioned tables. Others store an immutable JSON snapshot. Both can work.
Row-based versioning is easier to query and compare. Snapshot versioning is easier to restore and render. For many teams, a hybrid model works well: normalized editable content for drafts, plus immutable snapshots for published versions.
Relationships That Matter Most
The most useful relationships are simple, but they must be enforced clearly:
- Workspace → Pages: one organization owns many pages.
- Page → PageVersions: one page has many saved states.
- PageVersion → Sections: one version contains ordered sections.
- Section → Blocks: one section contains ordered blocks.
- Block → Asset: blocks may reference shared media.
- Block → Form: form blocks connect content to lead capture.
- Page → Experiments: pages may have A/B test variants.
Schema Design Choices That Save Pain Later
Use stable IDs, not slugs, for internal relationships. Slugs change. Campaign names change. IDs should not.
Add sort_order fields to sections and blocks. Drag and drop editors depend on ordering. Expect reorder operations to happen often, so avoid schemes that require updating hundreds of rows for a tiny move.
Store style data carefully. A global Theme entity can define fonts, colors, spacing, and button styles. Blocks can reference theme tokens instead of storing raw values everywhere. This keeps brand updates sane.
Track authorship. Add created_by, updated_by, and timestamps to major tables. It drives me crazy that some tools show a broken layout but cannot say who changed it or when. That missing audit trail can turn a five-minute fix into a 40-minute guessing game.
A Practical Starting Schema
For a first production-ready model, start with these tables:
- workspaces
- users
- pages
- page_versions
- sections
- blocks
- assets
- forms
- form_fields
- submissions
- experiments
- analytics_events
Analytics deserves its own table or pipeline. Store views, clicks, form starts, form submits, variant IDs, referrers, and timestamps. Then the builder can report that Variant B had 12,400 visits, a 9.1% submit rate, and a 14% lift over Variant A.
Final Takeaway
A landing page builder is not just a visual editor. It is a content system, publishing engine, media manager, form tool, and analytics layer packed into one product. The best data models keep content modular, versions safe, assets shared, and relationships clear. Build around pages, sections, blocks, assets, forms, and versions, and the product has room to grow without turning the database into a junk drawer.
