--- title: "How to structure a SaaS landing page, section by section" description: "A section order for a SaaS landing page, the reasoning behind each position, and how to assemble the page from shadcn blocks without padding it." slug: saas-landing-page-structure date: "2026-08-05" tags: - landing-pages - shadcn author: Initium Team --- Most section-order advice arrives as a list: hero, logos, features, testimonials, pricing, FAQ, CTA. The list is roughly right and almost useless, because it tells you nothing about why a section sits where it does, or what to do when your page doesn't have the ingredients the list assumes. This is the same order with the reasoning attached, plus the part that guides usually skip — how to actually assemble it, and how to know when you've added a section too many. ## What sections does a SaaS landing page need? A working default, top to bottom: 1. **Navbar** — product name, three or four links, one CTA. 2. **Hero** — what the product does, who it's for, primary action. 3. **Credibility strip** — logos, or a single stat you can actually stand behind. 4. **Problem** — the situation the reader is in before your product. 5. **How it works** — three to five steps, in the reader's order of operations. 6. **Features** — two or three sections, each carrying one benefit. 7. **Proof** — testimonials or a case study. 8. **Pricing** — or a pricing summary that links to the full page. 9. **FAQ** — the objections that survived everything above. 10. **Closing CTA** — the same action as the hero, worded the same way. 11. **Footer**. Eleven entries, but not eleven equal sections. The hero and the first two below it do the heavy lifting; the rest exists to catch readers who need more before they act. ## Why this order? The sequence is not aesthetic. It's the order in which a reader's objections arrive. Someone landing from a search result or a shared link is asking, in order: *What is this? Is it for someone like me? Do other people use it? Do you understand my problem? How does it work? What does it cost? What's the catch?* Each section answers one of those, and answering out of order costs you the reader. Pricing before "how it works" asks for a purchase decision before the reader knows what they'd be buying. Testimonials before the problem section are testimonials about a product the reader hasn't understood yet — they read as noise. The FAQ sits second-to-last because an FAQ near the top is an admission that the page above it failed. The one position worth defending in every version of this page: the closing CTA repeats the hero CTA verbatim. Same verb, same object. A reader who scrolls the whole page and finds a differently-worded action at the bottom has to re-decide what they're agreeing to. ## Where does attention actually go? The order matters more at the top than the bottom, and that's measurable rather than folkloric. Nielsen Norman Group's eyetracking analysis of over 130,000 fixations found that 57% of page-viewing time falls above the fold, and 74% falls within the first two screenfuls — with users rarely going beyond the third ([Scrolling and Attention](https://www.nngroup.com/articles/scrolling-and-attention/)). Attention past that point follows a long tail. Two consequences for structure: Your hero and the section immediately after it carry most of the page's total attention. That's where the specific claim goes — not the generic one, not the one you're saving for the features section. And the sections in your third screenful and beyond are for readers who are already interested. They're not persuading anyone from cold. That changes what belongs there: depth, specifics, objection handling — not another restatement of the value proposition in different words. ## How many sections is too many? Blocks are cheap to add, which is exactly the problem. A library of sections makes it easy to build a fourteen-section page where a seven-section page would have said the same thing. Two tests. **The distinct-claim test.** Every section must make a claim no other section makes. If you can delete a section and lose nothing but length, it was padding. Three feature sections that each say "it's fast, flexible, and easy" in different layouts are one feature section wearing three costumes. **The weight test.** Sections are not free. Largest Contentful Paint measures the render time of the largest image, text block, or video in the viewport, and the target is 2.5 seconds or less at the 75th percentile of loads ([web.dev](https://web.dev/articles/lcp)). A hero image competing with three below-the-fold images for bandwidth is a structural problem, not a tuning problem. Fewer sections above the fold, lazy-loaded media below it. Seven to nine sections covers most SaaS products. Past that, you're usually solving a copy problem by adding layout. ## What if you don't have proof yet? This is where the standard section list breaks down for early products, and where most pages go wrong in a way that's hard to recover from. The advice implicit in every landing page guide is: put logos here, put testimonials there. If you don't have customers yet, the temptation is to fill the slot anyway — placeholder logos, a composite testimonial, a metric you extrapolated. Every one of those is detectable, and being caught costs more than the empty section would have. The alternative is to change what goes in the slot rather than fake its contents. Proof doesn't have to be social: - A short demo video or an interactive sandbox is product proof. - Documentation depth is proof — a link to real docs signals a real product. - Open metrics you genuinely have (GitHub stars, downloads, changelog cadence) are proof. - Specificity is proof. A page that describes the reader's workflow precisely enough demonstrates understanding no testimonial conveys. And when none of those exist yet, delete the section. A seven-section page with nothing invented reads better than a nine-section page with two hollow ones. ## How do you assemble it from blocks? The structure above maps onto section blocks directly. In a shadcn project with the Initium registry configured, each section is one install: ```bash npx shadcn@latest add @initium/lp-navbar-1 npx shadcn@latest add @initium/hero-section-1 npx shadcn@latest add @initium/logo-section-1 npx shadcn@latest add @initium/feature-section-3 npx shadcn@latest add @initium/pricing-section-2 npx shadcn@latest add @initium/faq-section-1 npx shadcn@latest add @initium/cta-section-4 ``` The CLI writes the source into your project along with its dependencies, so the sections are yours to edit rather than a component you configure from outside. The [blocks documentation](/docs/blocks) covers registry setup and the license key for pro items; the Blocks browser is the source of truth for exact names. Two assembly notes that matter more than block choice. Pick blocks for the story, not individually. A block that looks strongest in isolation often fights the section above it — two consecutive centered sections with the same visual weight flatten into one long stretch. Alternate: centered hero, left-aligned feature, split feature, centered CTA. And size your copy to the block before you write the page. Each block has a headline length it was designed around. Copy written first and pasted in second is how you get headlines that wrap to three lines in one section and leave a gap in the next. ## How do you keep the structure once an agent edits the page? The structure survives the first build and then degrades. Someone asks a coding agent to "add a section about the new integration," and the agent adds it wherever it fits syntactically — often between the problem section and how-it-works, breaking the sequence you reasoned about. The fix is to make the structure legible to the agent instead of holding it in your head. Initium's workflow uses two files in the project root: `DESIGN.md` for visual direction and `STRATEGY.md` for audience, offer, objections, and page structure. An agent that reads both before writing code has your section order as an input rather than a pattern it has to infer from the existing markup. The [AI workflow docs](/docs/ai-workflow) cover the prompts and per-tool setup. Encoded further, this becomes an [agent skill](/blog/what-are-agent-skills) — the section-order logic, the headline budgets, and the no-invented-proof rule as instructions the agent loads whenever it touches UI code. That's the difference between a page that was structured once and a page that stays structured. If you want the blocks with those rules already attached, [getting started](/docs/getting-started) walks through registry setup and the first page.