Web & SoftwareUpdated 7 min read

SaaS Website Redesign: When Marketing Outgrows the Current Site

SaaS website redesign when a brochure cannot hold pricing, docs, changelog, and persona pages. Page types first, campaign patterns second.

Product marketing sitemap sketch with pricing, docs, and changelog pages beside a simple brochure homepage
Product marketing sitemap sketch with pricing, docs, and changelog pages beside a simple brochure homepage

For SaaS founders, Product marketers, Growth leads · Intermediate · Commercial · Solves: Product outgrew a five-page marketing site, Pricing and docs live in decks or Notion, Every launch is a one-off landing page

Key takeaways

  • A brochure cannot host a real GTM motion. You need page types, not a nicer blob.
  • Pricing, docs, and changelog are durable URLs with owners, not leftover categories.
  • Persona pages only exist when the job, proof, and language are actually different.
  • Campaign landing patterns are for campaigns. Do not strip the whole product site down to a form.

A SaaS website redesign becomes necessary when marketing outgrows a brochure. The product shipped. Pricing got real. Docs exist. A changelog exists. Sales wants persona pages. The site is still five marketing URLs and a 'request demo' form that dumps everything into one inbox.

This is not a landing page problem. Campaign pages can convert a single offer with a tight pattern. A product marketing site has to host the product in public: plans, documentation, release notes, use cases, and the commercial path, without turning into a junk drawer.

I look at SaaS sites as operating systems for GTM, not as a hero animation. If the CMS cannot express pricing, docs, and changelog as durable URLs with owners, the redesign will be a new coat of paint on the same bottleneck.

Brochure sites versus product marketing sites

A brochure explains the category and asks for a meeting. A product marketing site lets a serious buyer self-serve enough to decide whether a meeting is worth it. That includes current pricing logic (even if you do not list every number), a way to see the product, and a place where changes are recorded.

Brochures fail as the company grows because marketing has nowhere to put new truth. So they put it in a Notion doc, a PDF, a Loom, or a sales deck. The public site stays frozen. Paid campaigns still hit the frozen homepage. Support still answers questions the site should answer.

If your best product explanation lives in a deck, the website is not the product's website yet.

The redesign should make the public site the source of truth marketing can update without a developer for every sentence. That is a content model decision before it is a visual one.

Signals marketing has outgrown the current site

You do not need a survey. You need symptoms.

Those symptoms show up in operations before they show up in a redesign brief. Marketing asks engineering for a one-off page every launch. Sales keeps a private Notion of 'the real pricing.' Support macros answer questions that should be docs. The blog becomes a dumping ground for product updates because changelog never got a template. If you recognize that pattern, you already outgrew the brochure. The visual system is the last thing to change.

  • Pricing questions still dominate demos because the pricing page is vague or missing.
  • Docs live on a subdomain or a different tool with no serious internal linking from marketing URLs.
  • Changelog is a Twitter thread or a messy blog category.
  • Persona or industry pages were promised two quarters ago and never got a template.
  • Campaign landing pages cannot share components with the product site, so every launch is a one-off.
  • Legal, security, and status information is a footer PDF.
  • The CMS has one 'page' type and everything else is a rich-text blob.

Any three of those means the site is slower than the GTM team. A visual refresh without new page types will not fix it. You will just have a nicer blob.

The page types a SaaS site actually needs

Start with types, not with screens. Types are what the CMS and the nav have to support for the next year.

  1. Home: who it is for, what the product does, where to go.
  2. Product or platform hub: the system, not a feature dump.
  3. Use-case or persona pages: one job per URL.
  4. Pricing: plans, limits, and the honest next step.
  5. Docs: task-oriented, crawlable, linked from product pages.
  6. Changelog or releases: dated, indexable, not a screenshot dump.
  7. Compare or alternatives pages only if you will maintain them.
  8. Blog or resources as a hub, not as a substitute for product pages.

You may not ship all of these in week one. You should not pretend a single landing-page template can impersonate all of them. That is how SaaS sites become a homepage, a pricing table screenshot, and 200 undifferentiated posts.

Docs and changelog are marketing surfaces

Engineers often own docs. Marketing often ignores them. Buyers do not. Docs rank for task queries. Changelogs show momentum. If those URLs are noindexed, unlinked, or trapped in a widget, you donated the evaluation to sales calls and community threads.

A redesign is the moment to put docs and changelog in the IA. Same design system, separate templates, real titles, real internal links from use-case pages to the tasks those pages claim the product does.

Pricing as a durable URL, not a modal

Hiding pricing behind a demo form can be a strategy. It is also a leak if every competitor publishes plans and your sales team repeats the same ranges on every call. I am not going to tell you to publish a number you cannot stand behind. I will tell you the pricing URL needs to exist as a page with a job: qualify, explain packaging, and route the right buyer.

If packaging changes quarterly, the template must let marketing edit plans without breaking layout. If you cannot do that in the current CMS, that is a replatform signal, not a Figma problem. A redesign that still requires a developer to change a seat limit is a brochure with extra steps.

Persona and use-case pages without cannibalization

Persona pages fail when they are the same article with a different headline. Use-case pages fail when they repeat the homepage feature grid. Each URL needs a different job-to-be-done, a different proof object, and a different primary action if the buyer is actually different.

Before you add six industry pages, look at Search Console and sales notes. If you do not have distinct language, distinct integrations, or distinct outcomes, you are about to publish duplicates. Merge until the difference is real.

Google consolidates similar URLs. See duplicate URL handling. Six thin persona pages that canonical-fight the product hub help nobody.

Do not copy campaign landing page patterns onto the whole site

Campaign landing pages should be ruthless: one offer, stripped nav, form or demo, objections on the page. The product site cannot live that way. People need to move from use case to docs to pricing to a story. If you strip global navigation off every URL, you will convert a campaign and orphan the rest of the evaluation.

Keep campaign URLs as campaign URLs. The patterns I use there are in SaaS landing pages built for a single job. This redesign article is about the durable site those campaigns should sit next to, not replace.

Pipeline architecture, then visual system

SaaS redesigns love product UI in the hero. Motion is optional. The path is not. A visitor should be able to understand packaging, see a relevant use case, and take one commercial action without hunting. That is the same conversion structure I use on B2B marketing sites, applied to a product with more surfaces.

If the company sells to a committee, do the strategy work first: jobs, hubs, proof. That is B2B redesign strategy before anyone shops a template. Then apply pipeline-first page structure on home, pricing, and use-case templates.

Performance still counts. Heavy product videos in the hero, three font families, and a live demo iframe on every page will punish LCP. Treat Core Web Vitals as a template budget, not a post-launch surprise.

Use Core Web Vitals guidance on the templates that get paid traffic, not only on a marketing mock that never ships.

Sequence the rebuild so marketing can still ship

Do not freeze GTM for four months while a new brand system is born. Ship page types in order of bottleneck. If pricing questions are blocking demos, pricing ships first. If docs are embarrassing, docs get a template and a link from the product hub before the homepage animation is debated.

Migration of content into new types is the unglamorous middle. Old blog posts that are actually product explainers should become use-case or docs URLs, with redirects, not a new coat of category tags. Feature pages that repeat the hub should merge. Keep a spreadsheet: old URL, new type, new URL, owner. If nobody owns changelog, it will rot in a week.

Analytics should follow the types. A use-case page and a campaign landing page should not share one 'marketing page' event if you intend to learn anything. Name the page type in a data attribute or a content group. Then you can see whether the product site is doing its job or whether all of the conversions still come from one paid URL.

  1. Content model and URL policy (what stays, what merges).
  2. Templates for the bottleneck pages.
  3. Internal links between product, use case, docs, and pricing.
  4. Visual system on those templates.
  5. Homepage last if the homepage is not the bottleneck.

The CMS fields should match those types. A use-case item needs audience, job, proof, related docs, and a primary CTA. A changelog item needs date, summary, and optional deep link into docs. A pricing plan needs limits you can edit without breaking the grid. If everything is a freeform rich-text page, marketing will paint over the same blob forever and call it a redesign every year.

SEO on a SaaS product site is mostly uniqueness and internal links. Feature announcements should not clone the product hub. Comparison pages should not clone each other with the competitor name swapped. Changelog entries can be indexable if they are real notes, not 'bug fixes and improvements' fifty times. Docs should use task titles a practitioner would search, then link up to the use-case page that sells that task.

If you want a read on whether you need a brochure refresh or a product-site rebuild, send the current sitemap plus pricing and docs URLs. I will tell you which page types are missing before anyone opens a theme.

Implementation table

FixProblemWhat to changeMetricTool
Page-type inventoryOne CMS page blob for everythingList required types: product, use case, pricing, docs, changelogEach type has a template ownerCMS + sitemap
Link docs from product claimsDocs orphaned on a subdomainFrom each use-case claim, link the task docInternal links from marketing URLs to docsCrawl
Pricing as source of truthDecks, ads, and site disagreeOne pricing URL; other surfaces point to itFewer packaging questions on first callsSales notes

Is this a new hero, or a product site you can finally update?

Send the sitemap plus pricing and docs URLs. I will tell you which page types are missing before you buy another theme.

Book a SaaS site review

Sources & references

Related links

Zlatko Marjanovic — founder of ZedNova Studios

Zlatko Marjanovic

Founder, ZedNova Studios

I am Zlatko Marjanovic, founder of ZedNova Studios and an AI product engineer. I take over Next.js, Supabase, and Stripe codebases, fix what is actually broken, and keep shipping.

On GitHub I work in public with Cursor, Claude Code, Next.js, and Supabase. On Upwork I help founders who already have a product, often one built fast with AI tools, and now need someone to stabilize auth, billing, and deploys.

I have been doing this for 7+ years and have shipped 120+ projects for US and EU teams. The work I care about is the layer after the demo: RLS, webhooks, Vercel, and the next version.

If you want help with a build, a messy repo, or a site that should rank and convert, email me at zlatkomarjanovic.zm@gmail.com.

LinkedInX / TwitterGitHubWebsiteUpwork
Older articleB2B Website Redesign: Strategy Before TemplatesNewer articleWebsite Replatforming: When to Leave Webflow, WordPress, or Wix

Related