A SaaS site has two readers: the buyer who is deciding and the user who has just signed up. The buyer needs pricing, product, use cases, comparisons and proof. The user needs the first result fast. Most redesigns spend on the home page and neglect both.
If you can change only three pages this quarter, change the pricing page, the sign-up flow and the first screen after sign-up. They decide more revenue than everything else on the site combined.
Who a SaaS website is for
Two kinds of visitor matter and they want different things. The buyer, whether a founder choosing a tool alone or a team lead comparing three vendors for a committee, wants to know in a minute what the product does, whether it fits their case, what it costs, whether it is safe, and who else uses it. The new user, who has just signed up, wants to reach a first result before the trial ends and the memory fades.
Our SaaS marketing page describes the two kinds of software this serves: self-serve products, where search, the pricing page and the first week of use do the selling, and sales-led products, where a qualified demo is worth more than a hundred sign-ups. The site structure is the same for both; the primary button changes from “Start free” to “Book a demo”.
The home page: what it does, for whom, shown
The first screen carries a plain statement of what the product does and for whom, a real view of the product doing it (a screenshot or a short, silent, captioned clip, never an abstract illustration), and the primary button. A second line can name the outcome in the customer's terms. Nothing else needs to sit above the fold.
Below it: the three or four jobs the product does, each linking to a use-case page; logos or names of customers you may name, with permission; a short section on how it works in three steps; pricing in brief with a link; and the primary button again. Keep the home page a map of the site rather than a copy of it.
The pricing page: the most-read page on the site
Buyers open pricing before they read anything else, and they leave when it confuses them. Build it like this:
- Every plan, with its price, billing period and what is included, in a table a phone can show.
- The unit the price is based on (seats, usage, projects), explained in a sentence, with an example bill.
- Limits stated plainly, including the ones that will push a customer to the next plan.
- The trial or demo button on every plan, and a plain answer to “what happens when the trial ends”.
- A short FAQ on billing, cancellation, currencies, taxes and invoices.
- Enterprise or custom plans with what is different about them, and a contact route with a named response time.
Product and feature pages: show the job, not the feature list
One page per major capability, written around the task a user does rather than the feature's name, with the product shown doing it. Screenshots from the current version, annotated; a two-minute clip where the task is hard to picture; the integrations involved; and the limits. Each feature page links to the use cases it serves and to pricing. When a feature changes, the page changes the same week, or the screenshots become a reason to distrust the whole site.
Use-case, comparison and integration pages: where buyers land
The pillar guide explains why these page types drive sign-ups, so this section covers the design. A use-case page is written for one kind of team and one job (“for agencies reporting to clients”), with the workflow shown step by step in the product, the proof you have in that kind of team, and the primary button at the end of the workflow. A comparison page is a fair, factual table against one named competitor, with your honest weaknesses included, because buyers check. An integration page shows the two products working together, with the setup steps and what the integration does and does not sync.
Design these as a family: the same layout, the same table style, the same place for the button, so that a buyer who has read one can read the next in half the time. They are the pages most of your search and paid traffic will land on, so they carry the speed targets below as strictly as the home page.
Security, legal and company pages: the trust layer
A security page lists the certifications you hold (with the certificate or report available on request), where data is hosted, how it is encrypted, your backup and incident process, and who to contact. A legal section carries terms, privacy and data processing documents in readable form. An about page names the people and where they are. A status page shows real uptime, including the bad days. None of these pages sells anything, and a buyer's security or procurement team will read all of them before a contract is signed.
Documentation and the help center
Documentation is part of the website, not an afterthought behind a login. It should be public, searchable, written in the user's words, honest about limits, and linked from the screen where each task happens. Public documentation also answers buyers' detailed questions before a trial and ranks for long, specific searches that no marketing page would. Our guide to SaaS content marketing covers what to publish there.
The sign-up flow and the first screen after it
The sign-up flow is the most expensive page you own, because every channel ends there. Ask for the least you need to start: usually an email and a password, or a single sign-on button, with company details collected later or inferred. Say what happens next, and how long the trial is. Confirm by email and let the user into the product at once rather than making them wait for the link.
The first screen after sign-up decides the trial. Show one task that leads to a first result, with sample data already loaded so the screen is not empty, a short checklist of the three steps to that result, and a link to the getting-started guide for the use case the user picked. Test this flow with people who have never seen the product, before and after every redesign.
Speed and mobile targets for marketing pages
Buyers read SaaS sites on phones and on corporate laptops with many tabs open, and Google measures page experience. Its Core Web Vitals set three targets for a good experience: a Largest Contentful Paint of 2.5 seconds or less, an Interaction to Next Paint under 200 milliseconds and a Cumulative Layout Shift under 0.1. According to web.dev, LCP marks when the largest image, text block or video in view has rendered, and the targets should be met at the 75th percentile of page loads across mobile and desktop.
SaaS marketing sites miss these targets for predictable reasons: large product screenshots and hero videos, animation libraries, chat widgets and analytics scripts loaded before the content, and marketing pages built inside a heavy application framework. Size and compress images for the screen, defer scripts that are not needed for the first screen, drop auto-playing video from the top of the page, and check the pricing and use-case pages, not only the home page, in Search Console's Core Web Vitals report after launch.
Search basics the design must not break
Google's SEO starter guide is plain about the basics: pages the crawler can read, a logical structure with links between related pages, a unique and descriptive title and a meta description for each page, descriptive text around images with alt text, and no duplicate content under several addresses. Two traps catch SaaS sites. Marketing pages rendered only by a script that the crawler does not run, so the text is invisible to search; and documentation on a separate subdomain with no links to the product pages, so its authority never reaches them. Serve marketing pages as plain HTML and link documentation, use cases and features to each other.
Landing pages for ads, in one paragraph
A paid click from a category or competitor search should land on the matching use-case, comparison or pricing page, built to the same standard as above, with the one message the ad promised at the top. Stand-alone landing pages for campaigns follow the same rules with fewer links. Our guide to PPC for SaaS covers which searches to buy and where to send them, and our landing page design page covers the single page in detail.
Questions to ask before a SaaS redesign
Ask for written answers to these seven questions:
- Which pages will exist, and which buyer question does each answer?
- What will the pricing page say about limits and what happens when the trial ends?
- How will product screenshots be kept current when the product changes?
- What are the measured Core Web Vitals of the pricing and use-case pages on a phone before launch?
- How do the old addresses map to the new ones, so that rankings and bookmarks survive?
- Who tests the sign-up flow and the first screen with people who have never seen the product?
- What tracking shows which pages produced trials, demos and paid plans, and who reads it monthly?
If you want it built for you
PromotEdge International is an international strategy, technology, marketing and design company, and our delivery team is in India. Our web design and development page explains how we plan, design and build sites tested for speed, tracking and sign-up flows before launch, our SaaS development page covers the product side where a site and an application share a codebase, our UI and UX design page covers the screens themselves, and our SaaS marketing page explains how we work with software companies.
Facts we rely on: see our company facts for what we state about ourselves and where each fact comes from.