Don't assume every segment needs a separate page. Segments can share pages when belief gaps are close, even if segment names are different.
Share pages when: Doubts are similar (both segments doubt effectiveness, just for slightly different reasons), proof type is the same (both need data and metrics, or both need testimonials), awareness stage is the same (both are solution-aware comparing vendors), deal size is similar (both are £10K deals, not one £5K and one £50K).
Example: Compliance-driven and breach-reactive both need fast deployment. Compliance-driven wants "complete training in 30 minutes". Breach-reactive wants "set up today, team trained tomorrow". These are close enough to share a page focused on speed, with sections addressing both situations.
Separate pages when: Doubts are fundamentally different (one doubts if solution works at all, other doubts if they can afford it), proof type differs significantly (one needs data, other needs process walkthrough), awareness stages differ (one is problem-aware needing education, other is product-aware needing feature comparison), messaging that convinces one segment actively repels the other.
Example: Compliance-driven and proactive cannot share a page. Compliance-driven doesn't care about behaviour change (sees training as checkbox). Proactive cares deeply about behaviour change (building business case on ROI). A page emphasising behaviour metrics bores compliance-driven. A page emphasising speed and compliance checkbox annoys proactive ("that's not the point"). These segments need separate pages.
Test shared pages first: if you're unsure whether two segments can share, start with one page serving both. Track conversion rate by segment. If both segments convert at similar rates (within 20% of each other), they can share. If one segment converts at 5% and the other at 1.5%, they need separate pages.
For each segment-specific page, structure content to address that segment's specific doubt with appropriate proof type.
Compliance-driven page structure: Headline emphasising speed ("Complete SOC 2 training in 30 minutes"). Above-the-fold value prop about ease and compliance satisfaction. Social proof: "Used by 230 financial services firms" (peer validation). Proof type: compliance certifications and auditor acceptance ("Satisfies SOC 2, ISO 27001, GDPR requirements"). Objection handling: "Zero IT setup", "Works in any browser", "Integrates with your SSO". Detail level: low (they don't want lengthy explanations, they want fast checkbox solution). CTA: "Start free trial" or "Book setup demo" (hard CTA, they're ready).
Proactive page structure: Headline emphasising measurable impact ("Reduce breach risk with data-driven training"). Above-the-fold value prop about behaviour change and ROI. Social proof: "Reduced security incidents 47% for companies like yours" (outcome validation). Proof type: data and metrics ("Track risky behaviours, measure improvement, prove ROI"). Include behaviour tracking dashboard screenshot, before/after graphs, ROI calculator. Objection handling: "Measure behaviour, not just completion", "Real-time risk scoring", "Executive reports that justify budget". Detail level: high (they want comprehensive understanding to build internal case). CTA: "Download ROI guide" or "See behaviour tracking demo" (softer CTA, they're building case before buying).
Breach-reactive page structure: Headline emphasising urgency ("Deploy security training today"). Above-the-fold value prop about immediate deployment. Social proof: "Set up in under an hour" (speed proof). Proof type: process walkthrough showing "Upload users → Send invite → Trained by tomorrow" (implementation proof). Objection handling: "No IT involvement", "Instant compliance certificates", "Works on any device". Detail level: medium (they need to see it's truly fast, but don't want lengthy education). CTA: "Start now" or "Book demo today" (hard CTA with urgency).
Match proof placement to reading pattern. Above-the-fold proof (testimonial, stat, logo bar) for credibility. Mid-page proof (case study, data) for those who need convincing. Bottom-page proof (FAQ, detailed specs) for those doing thorough evaluation.
Aim for 3-12 landing pages total. This is the sweet spot where you have enough pages to serve different segments, but few enough to maintain properly and test systematically.
Why not more than 12 pages: Traffic gets too split (if you have 5,000 visitors/month across 15 pages, that's 333 visitors per page, too low to run meaningful tests). Maintenance burden increases (every page needs regular updates, fresh proof, testing). Creative production burden (need unique images, copy, examples for each page). Difficult to keep messaging consistent (15 pages saying slightly different things, message drift).
Why not fewer than 3 pages: Too generic (one page trying to serve compliance-driven, proactive, and breach-reactive segments ends up convincing none of them). Miss segment-specific opportunities (compliance-driven would convert at 6% with dedicated page, but converts at 2% on generic page). Can't match campaigns to segments (LinkedIn ads to compliance segment landing on same page as content marketing to proactive segment, message mismatch).
The 3-12 range typically maps to: 1 page per major segment (3-5 segments) + 1-2 campaign-specific pages (like remarketing page different from cold traffic page) + 1 pricing page + 1 demo/trial page = 6-10 pages. This covers most situations.
Maintain pages systematically: quarterly review of all landing pages (update proof, refresh testimonials, check for broken elements), monthly performance review (which pages converting well, which need optimisation), continuous testing (always have 1-2 tests running on highest-traffic pages). Don't build pages then abandon them. Treat them as living assets.
Version control: when you update a page, document what changed and why. Track performance before and after updates. If you update proof section and conversion drops, you can revert. If you update headline and conversion improves, you've learned something to apply elsewhere.
.svg)
