Skip to content

landing-page-schema.md

Latest commit

 

History

History
27 lines (26 loc) · 2.92 KB

landing-page-schema.md

File metadata and controls

27 lines (26 loc) · 2.92 KB
Raw

Landing Page Schema Rules

  • Product schema should express landing-page marketing logic first; editor, renderer, zod validation, and templates should adapt to the product model.
  • Schema may model visual attraction content such as pain points, result cases, galleries, proof metrics, and lead magnets when they serve consultation or lead capture.
  • Visual attraction fields must describe marketing material and proof, not renderer CSS, layout classes, spacing, animation, or low-code styling knobs.
  • Every landing page must have a primaryConversion.
  • primaryConversion must point to a real lead path through destination: URL, phone, email, or form.
  • primaryConversion.channel and primaryConversion.destination.type must describe the same lead path.
  • Do not model primary conversion as a loose optional url.
  • If any CTA or primaryConversion.destination.type is form, the page must include the matching single leadForm.
  • A page should have at most one leadForm.
  • Lead forms must collect at least one reachable contact field: phone, email, whatsapp, or telegram.
  • name may be collected, but name alone is not a valid lead.
  • Extra form fields should be lightweight qualification fields, such as service type, budget range, target country, appointment preference, or inquiry details.
  • Attribution means identifying which CTA, form, or channel produced the lead.
  • Analytics events for generated landing pages must stay lead-generation oriented, not purchase or checkout oriented.
  • Do not require a fixed market or visitor region in the schema.
  • locale may be optional and should fall back to English when runtime detection is unavailable.
  • Generic contact URLs should be modeled as lead-oriented consultation links only, and must not point to purchase, checkout, cart, order, subscription, refund, or payment pages.
  • The footer must include at least one compliance link or inline policy entry.
  • Footer privacy and terms text is also the source for the page's /privacy and /terms subpages; keep it substantive prose, not a placeholder title.
  • Company info is account-level (company_profiles), not page content: footer.companyProfileId holds a reference and the renderer receives an already-composed line. Do not add company name, address, or licence fields to the page schema.
  • Renderer components must not read company info from the draft or query the database; page routes resolve it and pass it in.
  • See docs/landing-page-compliance.md for the full footer compliance model and its traceability to platform policy.
  • Trust and compliance structures should support reviews, trust badges, authority story, FAQ, assurance, privacy policy, and disclaimers.
  • Result proof, before/after, health, beauty, finance, or other high-risk claims should support disclaimers and avoid guaranteed outcomes.
  • Assurance content must avoid transaction semantics such as refund guarantees or payment protection unless product scope explicitly changes.